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

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

.gitignore

@@ -70,3 +70,22 @@ alembic/versions/__pycache__/
 *.sqlite
 *.sqlite-journal
 .superpowers/
+
+# Raw platform captures (milestone 387 C0 and successors). These are real
+# authenticated API responses taken from the operator's own account, so they
+# carry account data — creator lists, pledge amounts, and (in Patreon's case)
+# the account email inside the `card` resources. They are kept locally because
+# re-capturing means re-authenticating by hand, and they are the ground truth a
+# characterization gets re-checked against.
+#
+# The whole directory is ignored, not one filename, so a future capture is
+# covered by this rule instead of needing a new line somebody has to remember.
+#
+# SANITIZED fixtures derived from these DO belong in git — put them somewhere
+# else (tests/fixtures/, not here), with the account data stripped.
+# Ignore the CONTENTS, not the directory: git does not descend into an
+# excluded directory, so a negation for a file inside one never takes effect.
+# Writing it this way lets README.md be committed while everything else here
+# stays out.
+tests/fixtures/captures/*
+!tests/fixtures/captures/README.md

tests/fixtures/captures/README.md

@@ -0,0 +1,43 @@
+# 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.