docs: define the profile memory experiment

docs/creative/04-prototype.md

@@ -756,3 +756,79 @@ anchors (Film, AI Usage, Open line), two plain images (Cover, Process), alt text
 fallback copy, and the necessary verifier in `BrickerP/BrickerP` only. A new
 route, a dynamic service, standalone text-link rows, and product changes to
 Loop / Endless Second Ring / AI Usage remain out of scope.
+
+## 2026-08-10 — A Profile with Memory
+
+Status: **Step 4 approved by the user on 2026-08-10.** This section supersedes
+the clickable-portal correction as the current next-loop direction. The shipped
+five-spread Human Zine and its evidence remain a dated, inspectable baseline;
+they are not rewritten or treated as the new architecture.
+
+### Approved architecture
+
+The Profile gets one free-form **current intrusion** and a durable
+`experiments/` archive. The intrusion may change shape with the question; it is
+not a fixed `CURRENT OBSESSION` card, reusable component, or issue template.
+Clicking the intrusion opens the current issue at
+`experiments/001-a-profile-with-memory/`.
+
+`PAST FIXATIONS` does not appear in the first issue. It becomes useful only when
+a second issue exists and there is real past work to point to. There is no empty
+archive theatre and no placeholder history.
+
+The archive is editorial, not scheduled infrastructure. Do not add a template,
+publishing cadence, API, cron job, generator, dynamic service, or migration
+layer. `experiments/README.md` is a small evolving index; each issue owns its
+question and evidence in its own directory.
+
+### Approved first issue
+
+- **Issue:** `A PROFILE WITH MEMORY`
+- **Question:** `HOW MANY PAST SELVES SHOULD A PROFILE REMEMBER?`
+- **Portal:** the whole current-intrusion image links to
+  `experiments/001-a-profile-with-memory/`.
+- **Evidence:** four real commits in `BrickerP/BrickerP` `main` ancestry, in
+  chronological order:
+  - `91a7a77` — recruiter-scan profile;
+  - `35aa305` — Loop / Ledger profile;
+  - `b130094` — Human Zine profile;
+  - `d71f9f3` — clickable visual portals.
+- **Visual:** torn, deliberately misregistered profile fragments are visibly
+  stitched into one history. The composition should feel repaired and revised,
+  not like four matched cards or a clean timeline.
+
+The image-generation preview is mood and composition reference only. It is not
+release evidence and must not be copied into the product as invented history.
+The shipped intrusion and issue use evidence read from the four commits above;
+any crop, label, or fragment must be traceable to those real Profile states.
+
+### Self-questioning
+
+#### Why reject a permanent `CURRENT OBSESSION` card?
+
+Because the first issue would prematurely harden an editorial experiment into a
+component system. The current question should determine the form; the form must
+not determine every future question.
+
+#### Why make memory the first issue?
+
+The Profile already has multiple materially different, verifiable selves on one
+`main` ancestry line. That makes revision history the strongest available
+subject, not a fabricated theme.
+
+#### Why omit `PAST FIXATIONS` now?
+
+With one issue, it would be an empty label or a duplicate link. The second issue
+creates the first honest contrast between current and past.
+
+#### Why keep the system manual?
+
+The value is selection and interpretation, not publishing frequency. Automation
+would add machinery before there is a repeated workflow to justify it.
+
+### Step 4 approval gate
+
+The user has approved the architecture, first issue, question, evidence chain,
+and torn/misregistered/stitched-history direction. Step 5 is authorized only
+within the five-file boundary recorded in the 2026-08-10 section of
+`05-mvp-prompt.md`.

docs/creative/05-mvp-prompt.md

@@ -234,3 +234,45 @@ rewrite an asset.
   merge/publication, read back the rendered GitHub Profile, verify all native
   destinations, and confirm the fixed paper and readable layout in light and
   dark themes before claiming the Human Zine live.
+
+## 2026-08-10 Step 5 override — A Profile with Memory
+
+Status: **implementation authorized by the user on 2026-08-10.** This section is
+the sole active Step 5 source. It supersedes the seven-file clickable-portal
+implementation above as the next change while retaining that shipped contract
+as history.
+
+### Exact implementation boundary
+
+Implementation happens only in `BrickerP/BrickerP` and changes exactly these
+five files:
+
+| File | Responsibility |
+| --- | --- |
+| `README.md` | Present one free-form current intrusion and wrap the whole image in one native relative link to `experiments/001-a-profile-with-memory/`. Do not add a fixed `CURRENT OBSESSION` card or `PAST FIXATIONS` in issue 001. |
+| `assets/a-profile-with-memory.svg` | One static, pure-display intrusion for issue 001, using torn, misregistered, visibly stitched fragments grounded in the four approved Profile commits. |
+| `experiments/README.md` | Keep the evolving experiment index and link issue 001. It is not a template, feed, schedule, or generated manifest. |
+| `experiments/001-a-profile-with-memory/README.md` | Record `A PROFILE WITH MEMORY`, the question `HOW MANY PAST SELVES SHOULD A PROFILE REMEMBER?`, and the real evidence chain `91a7a77` → `35aa305` → `b130094` → `d71f9f3`. |
+| `scripts/verify-profile.mjs` | Verify the README portal, issue path, one-SVG boundary, exact question and commit identifiers, and prohibited automation/template paths. It remains a verifier, never a generator. |
+
+No other README asset, product repository, runtime, or deployment mechanism is
+in scope. Do not add a compatibility layer for the five-spread layout, a second
+current-entry path, a template, publishing cadence, API, cron job, generator, or
+dynamic service. `PAST FIXATIONS` is deferred until issue 002 creates a real
+past/current distinction.
+
+### Evidence contract
+
+The product must derive its visible history from the four real commits on the
+Profile repository's `main` ancestry:
+
+- `91a7a77faf8492d1aaedd975cca404dc3890657e`;
+- `35aa3052a2765879a5c0973260f11042b81ca55e`;
+- `b130094cb5f273bbb20cec5cff163eafb511f638`;
+- `d71f9f3c92a1c615d6b49a59da9bf1f40ddfffb1`.
+
+The torn/misregistered/stitched treatment may edit scale, crop, overlap, and
+registration, but it must not invent a Profile state, commit, sequence, or
+receipt. The image-generation preview is mood/reference only and is neither a
+release asset nor proof. The issue README names the evidence plainly enough for
+a visitor to inspect it.

docs/creative/06-dogfood.md

@@ -168,3 +168,23 @@ call the Human Zine ready for participants until the exact remote Profile
 commit proves five spreads, three whole-image outer anchors, two plain images,
 keyboard focus, image-failure alt fallback, exact destinations, and no
 standalone action-link rows.
+
+## 2026-08-10 five-person feedback readback
+
+Five people saw the shipped Profile. The common reaction was positive, with a
+recurring qualification that it felt slightly simple or sparse. This is useful
+directional feedback: the visual portals work well enough to preserve as a
+historical issue, while the next experiment needs a richer idea rather than more
+decoration on the same layout.
+
+This was informal qualitative feedback, not the queued 90-second protocol. No
+per-participant answers, evidence citations, task outcomes, or scored counts were
+recorded. Therefore it does **not** satisfy the earlier `4/5` recall or `3/5`
+specific-action thresholds, and it must not be reported as quantitative
+acceptance. “Generally liked, but slightly simple” is the complete supported
+claim.
+
+The feedback closes the need to keep waiting before choosing a next creative
+question; it does not validate a permanent layout. The approved response is the
+`A PROFILE WITH MEMORY` current intrusion and `experiments/` archive recorded in
+Steps 4 and 5, not a fixed `CURRENT OBSESSION` card.

docs/creative/07-next-loop.md

@@ -97,3 +97,47 @@ spread**—not additional prose and not shared branding across the works.
 
 These remain deferred backlog observations and must not displace the clickable
 portal recovery gate or the participant-recall test that follows it.
+
+## 2026-08-10 superseding next loop
+
+Status: **approved by the user.** The clickable visual portals shipped on
+`BrickerP/BrickerP` `main` at `d71f9f3`, and five people subsequently gave
+informal feedback. This section supersedes the current-next-knife and queued-test
+ordering above while preserving both as historical context.
+
+The supported feedback is deliberately narrow: people generally liked the
+Profile but found it slightly simple or sparse. Because the session was not the
+documented 90-second protocol and did not capture participant-level scores, it
+is not a formal quantitative pass and does not meet or falsify the old `4/5` and
+`3/5` thresholds.
+
+### Approved opportunity
+
+Turn revision itself into the next subject. The Profile presents one free-form
+current intrusion and keeps an evolving `experiments/` archive. It does not
+install a permanent `CURRENT OBSESSION` card. `PAST FIXATIONS` first appears
+with issue 002, when a genuinely past fixation exists.
+
+The first issue is **A PROFILE WITH MEMORY** and asks:
+
+> **HOW MANY PAST SELVES SHOULD A PROFILE REMEMBER?**
+
+Its visual language is torn, misregistered, and stitched history grounded in
+four real Profile `main` ancestors: `91a7a77`, `35aa305`, `b130094`, and
+`d71f9f3`. The complete current intrusion links to
+`experiments/001-a-profile-with-memory/`. Image-generation output remains
+mood/reference only; release material must use real evidence from those commits.
+
+### The one next knife
+
+Implement only the five-file Step 5 boundary: `README.md`, one
+`assets/a-profile-with-memory.svg`, `experiments/README.md`, the issue README at
+`experiments/001-a-profile-with-memory/README.md`, and
+`scripts/verify-profile.mjs`.
+
+Do not add a template, issue schedule, API, cron job, generator, dynamic service,
+compatibility layer, or second current-entry mechanism. The implementation is
+complete only after remote CI verifies the pushed commit and the exact remote
+README, SVG, archive index, issue, and portal destination are read back. That
+remote implementation and verification are outside this documentation-only
+update.