CI / extension-version (push) Successful in 3s
CI / lint (push) Successful in 3s
Build images / sign-extension (push) Successful in 4s
Build images / build-agent (push) Successful in 7s
Build images / build-ml (push) Successful in 8s
Build images / build-web (push) Successful in 6s
Build images / smoke-web (push) Skipped
Build images / promote (push) Skipped
CI / frontend-build (push) Successful in 24s
CI / backend-lint-and-test (push) Successful in 32s
CI / integration (push) Successful in 2m12s
C0 characterized Patreon's `/api/members` from a live capture of the operator's own session. That capture is worth keeping — re-capturing means re-authenticating by hand, and it is the ground truth the characterization (Scribe note #3886) gets re-checked against when a platform's shape is suspected to have drifted. It cannot be committed. It carries the operator's creator list, pledge amounts, and — inside the `card` resources the web app's include set pulls — the account's own email address. So: a directory that is ignored wholesale rather than by filename, so the next capture is covered by this rule instead of needing a line somebody has to remember to add. Two details that are the point rather than incidental: * The ignore is written as `captures/*` plus a negation for README.md, NOT as `captures/`. Git does not descend into an excluded DIRECTORY, so a negation for a file inside one never takes effect — the README would have been silently ignored along with everything else, and the convention would not have survived a fresh clone. * The README states plainly that SANITIZED fixtures belong in git, elsewhere under tests/fixtures/. The raw capture exists to derive those from and to re-check against; it is not the thing tests should load. The ignore rule landed before the capture file did, deliberately: a payload with an email address in it should never be sitting in the working tree un-ignored, however briefly. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LNXXULQDjVZmbuNa2G9mD9
44 lines
1.8 KiB
Markdown
44 lines
1.8 KiB
Markdown
# Raw platform captures — local only, never committed
|
|
|
|
This whole directory is gitignored (see `.gitignore`). Nothing in here should
|
|
ever be staged.
|
|
|
|
## What lives here
|
|
|
|
Real authenticated API responses, captured by hand from the operator's own
|
|
browser session, kept as the ground truth a characterization note gets
|
|
re-checked against. Re-capturing is manual and requires re-authenticating, so
|
|
these are worth keeping locally even though they can't be committed.
|
|
|
|
They carry live account data. The Patreon members capture, for example,
|
|
contains the operator's creator list, pledge amounts, and — inside the `card`
|
|
resources the web app's include set pulls — the account's own email address.
|
|
That is exactly why the directory is ignored wholesale rather than by filename.
|
|
|
|
## What does NOT live here
|
|
|
|
**Sanitized fixtures belong in git**, under `tests/fixtures/`, not in this
|
|
directory. A fixture with the account data stripped is the thing tests should
|
|
load; the raw capture is only for deriving it and for re-checking a
|
|
characterization when a platform's shape is suspected to have drifted.
|
|
|
|
## Current contents expected
|
|
|
|
| file | characterized in | step |
|
|
|---|---|---|
|
|
| `patreon_members_<YYYYMMDD>.json` | Scribe note #3886 | milestone 387 C0 |
|
|
|
|
## How to (re-)capture the Patreon members response
|
|
|
|
1. Log in, go to `patreon.com/settings/memberships`.
|
|
2. DevTools -> Network, filter `api`, reload.
|
|
3. Find the `members?include=...` request (it self-identifies: its query string
|
|
ends `members_request_source=settings_memberships`).
|
|
4. Right-click the request -> **Save Response As...** -> save it here.
|
|
|
|
Save the response, not a HAR: a HAR bundles the request headers, which means
|
|
the session cookie ends up in the file.
|
|
|
|
Note that the response's own `links.first` is built WITHOUT the `/api/` prefix
|
|
and is not a usable URL — see note #3886 before writing a client against it.
|