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

2026-09-10 21:07:48 -04:00

README.md

chore: a gitignored home for raw platform captures (milestone 387 C0)

2026-09-10 21:07:48 -04:00

README.md

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

Log in, go to patreon.com/settings/memberships.
DevTools -> Network, filter api, reload.
Find the members?include=... request (it self-identifies: its query string ends members_request_source=settings_memberships).
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.