[TheAnswerManIsHere]

Workstream: #840

What & why

This is the Launch Phase 5 documentation harvest and sweep. It is the docs half of Increment 7, split out in PR #837 — Launch Phase 5, Increment 7a: retire the admin soft delete and set-inactive edit. The docs now describe what Phase 5 built: the verify, onboard, act gate; Turnstile; suspension; the account deletion engine and what it keeps; the withdrawn NSFW opt-in; and the retirement of the soft delete and reinstatement. Every other doc that still described the retired rules has been swept.

Parent workstream: Issue #795 — Launch Phase 5 — Account and identity. This PR is docs only and changes no product code. The in-app help modules under artifacts/overhype-me/src/generated/help/ are regenerated from the edited Manual chapters, as check:help-content requires.

Routed (the /document harvest):

• docs/ai-context/accounts-and-auth.md — the account states and the gate (GATE_EXCEPTIONS, Express-style matching), Turnstile, captcha_verified → 0122. It has a new Account lifecycle: suspension and deletion section (suspension's two layers and createSignInSession, the engine's stages, billing fences, the purge and what it keeps by who asked, the callers, the never-onboarded cleanup, and the My content restore window). Also a new Age, audience and the NSFW opt-in section, and updated session revocation paths and the files list.
• docs/ai-context/security-model.md (auth section) — the gate as a trust boundary, anonymous auth routes reading their target's state, the session created under a share lock, the last-admin rule for suspension and deletion, re-authenticated deletion, and the unverified provider claim.
• docs/manual/9-accounts-and-auth.md — rewritten for Phase 5.
• docs/ai-context/glossary.md — Onboarding, Email verification and Remove rewritten. Suspend, Account deletion and Former member added. Deactivate and Reinstate marked retired, with their anchors kept.
• docs/ai-context/decisions.md — three entries: what deletion keeps (2026-11-02); joining and leaving (2026-10-30); suspension and the engine replace deactivation, and the NSFW opt-in is withdrawn (2026-10-30).
• docs/engineering/migrations-and-backfills.md — CHECK in the dump-and-restore form, a NOT NULL DEFAULT column classified "drop" in the legacy fixture, no marking default on a column a publish may add first, and information_schema scoped to public.
• docs/tests/TESTING.md — the local orval and codegen restore, the production-mode launcher in a cloud container, and four troubleshooting rows.
• .agents/memory/ — two notes: a Drizzle correlated subquery binds the outer column to itself; and two CodeQL alerts that a test file trips.

Not routed, and why: the fleet-level gotchas from the harvest notes ("making a field mutable exposes every early read", "chain a commit after tests with &&", "check-uat-format needs both Setup and Regression") belong in KITT-synced files (known-failure-patterns.md, running-long-test-suites.md, uat-doc-format.md), which a consumer does not edit. A stale code comment in artifacts/api-server/src/lib/membershipRefresh.ts (line 7, "admin soft-delete, reinstatement") is product code and outside this PR. It is recorded as next on Issue #795.

Approved-plan oracle

Oracle source: Issue #795, its harvest-notes comments for PRs #798, #801, #815, #820, #833, #834, #835 and #836 and the "Handoff — 2026-11-02" comment; the plan docs/plans/PLAN_PHASE5_ACCOUNT_IDENTITY.md on main (sha256 52a059b6fccc0836d2c5293fdf0680e0376524bcc4d293113bffb73cdfa844af). Documentation class.

The decisions the prose records, quoted:

• "Admin "deactivation" (is_active=false) becomes suspension; deletion is its own state machine. One state machine for leaving, one flag for being removed." (plan, settled decisions)
• "The soft delete and set-inactive edit are retired. Nothing writes users.is_active = false any more (verified by git grep at 54f5b2f)." (Handoff — 2026-11-02)
• "Every sign-in door creates its session through createSignInSession (lib/auth.ts). It reads suspended_at FOR SHARE and inserts the session in one transaction, so it serializes with suspendAccount's FOR UPDATE plus revoke." — "Two layers. Each sign-in door refuses a suspended account, and the gate refuses every write by a session it still holds except logout. Reads by a held session are the approved design" — "Recovery is closed while suspended. Forgot-password silently issues nothing … Reset refuses before claiming" — "Recorded gap: a stored-field write that lands in the instant a suspension commits" (harvest notes, PR Launch Phase 5, Increment 6a: account suspension #835)
• "What deletion keeps is split by who asked, not by data type (David, 2026-11-02 …). On self or unfinished-sign-up deletion, votes and hearts are anonymised (reactions.user_id null), and comments, submissions and links are credited to a former member. An admin removal deletes them as the abuse case." — "Every kept contribution carries a "former member" marker, never a bare null." (harvest notes, PR Launch Phase 5, Increment 5b: leaving and staying from the screens, and what deletion keeps #833)
• "One engine (lib/accountDeletion.ts) owns every account-deletion transition. Its stages advance by compare-and-set, fenced to the request's generation" — "Lock order is population lock → owner content lock … → user row." (harvest notes, PR Launch Phase 5, Increment 5a: an account can leave cleanly — the deletion engine #820)
• "The NSFW opt-in is withdrawn: both classifier callers pass a literal false. The classifier keeps its parameter for when adult content ships, and the column stays until a contract step." — "beta_overlay … is a declared exception in the "every grid key is consulted" test rather than a FEATURE_KEYS entry" (harvest notes, PR Launch Phase 5, Increment 6b: NSFW readiness, and the NSFW opt-in withdrawn #836)
• "The captcha column dies in two releases. Increment 3 stops every read and write of captcha_verified … Increment 7 drops it" (plan S23); 7b is migration 0122, "only after David's next publish" (Handoff — 2026-11-02)
• "A varchar IN (...) CHECK is not a fixed point of Postgres's deparse … a new varchar CHECK must be written in the restored form" — "A new NOT NULL DEFAULT column … Classify the column drop" — "The local orval is older than CI's … hand-edit only the affected generated lines" (harvest notes, PR Launch Phase 5, Increment 6b: NSFW readiness, and the NSFW opt-in withdrawn #836)
• David's decisions (2026-10-30/31; plan David's answers): date of birth required; 14-day cooling-off; deletion re-authenticates, "it should be HARD to do without really meaning to"; subscription cancelled at the deletion request; under-13 refused with nothing stored and nothing destroyed; never-onboarded registrations cleaned up after 30 days; a "Keep my account" button; everything in My content undoable for 30 days.

In scope: routing correctness against documentation-workflow.md; factual accuracy against the merged diffs and the code at 54f5b2f; contradiction or duplication with existing docs. Out of scope: prose style, structure preferences, completeness beyond the phase's actual learnings.

Prose sweep record

Spec as swept (pass 2, as amended after pass 1):

• Rule: the pre-Phase-5 lifecycle is retired — deactivate/reinstate, no self-service deletion, the uniform-orphaning hard delete, email verification gating nothing, onboarding as captcha_verified, and the NSFW opt-in. It is replaced by suspension, the deletion engine, the gate, onboarding with Turnstile, and the withdrawn opt-in.
• Home: docs/ai-context/accounts-and-auth.md#account-lifecycle-suspension-and-deletion.
• Sub-shapes: a deactivate as an admin lifecycle state · b reinstate/reactivate · c no self-service deletion · d uniform orphaning · e verification gates nothing · f onboarding as a captcha flag · g a member NSFW setting · h sign-out-everywhere lists naming deactivation · i a wrong drop migration or increment · j a bare-null author, or attribution "only for active accounts" · k (added, pass 1) a retention or compliance table restating deletion · l (added) a pointer naming the retired operations · m (added) a retired action as a tool for another purpose (billing repair, a designed exception, a lock example).
• Not in class: facts.is_active and fact deactivation; subscription, engine and feature active states; meme soft-delete and Recently deleted; fact takedown; historical records (dated decisions, plans, retired, UAT/Replit run records); the NSFW classifier and quarantine; live per-action Turnstile; users.is_active as still read.

Scope and inventory: scripts/sweep-scope.mjs over the payload plus docs/ai-context, docs/manual, docs/engineering, docs/tests/*.md, docs/*.md and replit.md: 266 files, 4 workers per pass, two passes, plus one re-run (all six files read in full) over batches 2–4's files. Batch 5 only annotated four table rows in a file that re-run had just read in full. Read in full: accounts-and-auth.md, security-model.md, Manual chapters 9, 10 and 11, glossary.md and membership-entitlements.md. Every other file was swept, with hits read in context.

Fixed (batches 1–5):

• docs/manual/10-payments-and-membership.md — reinstatement as the designed exception, the deletion and history passage, and the "deactivate then reinstate" billing repair (shapes b, d, m).
• docs/ai-context/membership-entitlements.md — the reinstatement exception, the lock-order example, the soft-delete billing paragraph, and the reinstatement mechanics (a, b, d, m).
• docs/ai-context/glossary.md — the Membership tier and Reactivate entries (b, m).
• docs/manual/2-content-lifecycle.md — onboarding as a step before the first submission that admins and Legendary skip (f, e).
• docs/manual/11-admin-console.md and docs/ai-context/admin-console.md — the deactivate and reinstate pointers (a, b, l).
• docs/ai-context/community-and-engagement.md — the "no live path nulls a comment author" claim (j).
• docs/ai-context/meme-and-video-studio.md — the hard-delete cleanup paragraph and the files pointer (d, l).
• docs/ai-context/current-roadmap.md — the lockout guard's "deactivation" (h).
• docs/data-lifecycle-retention-matrix.md — the two-phase soft → hard rows (a, c, d, k).
• docs/ai-context/security-model.md — cross-links to the home.
• docs/tests/TESTING.md — the seeded accounts are onboarded, not only verified (e).
• docs/engineering/migrations-and-backfills.md — "data deletion is two-phase (soft → hard)" (k).
• docs/ai-context/legal-safety-moderation.md — evidence survives every deletion, not only an admin hard delete (d, k).
• docs/ai-context/launch-feature-inventory.md — the Users, B10, B11, B24 and J8 decision rows marked done in Phase 5, each citing the home (a, b, c, e, f; batch 5, after the re-run reader found the siblings of the first annotated row left bare).

Declined, with the exclusion that applies:

• known-failure-patterns.md (PR feat(moderation): NCMEC phase 3 — isSubmittable + classifyWaitingState #349 and Derive membership from entitlements, don't assign it per-event #287 examples) and launch-feature-inventory.md's dated "Verified 2026-10-05" note — dated history (5), or KITT-synced.
• glossary.md Legendary "no CAPTCHAs", product-brief.md, replit.md and overhype-design SKILL — the live per-action captcha (7).
• launch-definition.md and architecture-map.md Turnstile lines — agree with the home; scope lists.
• Manual chapter 10's retired-as-retired notes, and Manual pointers to chapter 9 rather than ai-context — a Manual cites its sibling chapter.
• The glossary's Onboarding and Submitter entries — they cite #account-creation, the section that states the gate.
• manual/3-moderation.md evidence lines — agree (NCMEC rows survive with the person nulled).

Decisions taken on my recommendation

• The docs sweep is tracked as its own sub-issue (Issue Launch Phase 5 docs sweep — accounts, suspension, deletion, and the retired rules #840 — Launch Phase 5 docs sweep — accounts, suspension, deletion, and the retired rules), per documentation-workflow.md's ad-hoc harvest rule. Undo: close Launch Phase 5 docs sweep — accounts, suspension, deletion, and the retired rules #840 and point the Workstream: line at Launch Phase 5 — Account and identity #795.
• Manual durations are stated as intent ("a cooling-off period", "a month or so"), with the figures left to the spec, because the Manual's tuning-language guard reserves values for docs/ai-context/. Undo: mark the lines <!-- tuning-ok --> and restore the figures.
• Fleet-level gotchas were not routed, because their homes are KITT-synced. Undo: route them in KITT.
• The two retired glossary entries keep their headings and anchors, marked retired, so the existing links still land. Undo: delete them and repoint the links.

Latitude granted to me: none.

Verification

• node scripts/check-docs-accuracy.mjs → ✓ docs-accuracy: 164 files, all relative links resolve and all cited repo paths exist.
• node scripts/check-manual-tuning-language.mjs → ✓ manual tuning-language: 13 file(s), no values or magnitude stand-ins outside docs/ai-context/.
• pnpm --filter @workspace/overhype-me run check:help-content → generate:help --check: up to date (16 files).
• I checked every code claim against 54f5b2f's source: the routes, the eligibility order, GATE_EXCEPTIONS, createSignInSession, the purge's keep/delete branches, the cancellable statuses, FRESH_SIGN_IN_MS, the rate limit, and the classifier callers.

Post-merge verification (live environment)

none needed (docs only; the regenerated help is checked by CI's check:help-content)

Checklist

• Docs stay true — pnpm run check:docs passes.
• Build gate reproduced when relevant n/a (docs and generated help only)
• General fix, not one example n/a
• Ship the surface n/a
• Async shows status n/a
• Human decisions preserved n/a
• Migration safety n/a
• In scope — docs only.

---

Generated by Claude Code

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-02T06:10:18.162745Z	65b1d7f	PR opened
🔒 Security Review	✅ Completed 2026-11-02T06:10:57.477496Z	65b1d7f	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[TheAnswerManIsHere]

Astra — round 1

Assessed at 65b1d7f95ee6d2ca429df76a7465224b60741b91 · documentation pass over 54f5b2fc84b164afa40a38bfed3a8292986b50fc..65b1d7f95ee6d2ca429df76a7465224b60741b91 · Codex's automatic pass: clean · requested gpt-6-astra at xhigh

Oracle met at this head: no

The harvest captures the main change correctly: suspension blocks an account, while deletion follows a separate process. I recommend one documentation correction batch. Four claims would give David or a future agent the wrong understanding of what happens. The corrections below preserve the approved behavior; they do not require a new product decision.

D1 — Correct the guarantee that billing stops at the instant deletion is requested.

The manual says subscriptions are cancelled “at the same moment, so nothing bills again.” Direct inspection shows that acceptance commits first, then starts billing cancellation without awaiting completion; failures are recorded for retry. See acceptance and the asynchronous kick.

The bounded problem is presenting a requested external operation as an accomplished guarantee. A reader could believe a successful deletion request proves cancellation succeeded. The technical spec’s retry explanation does not repair that promise for someone reading the manual alone.

Recommend explaining that cancellation starts immediately and is retried if it fails. This follows the approved plan’s S14 recovery design. Success means the manual and current-state summaries distinguish acceptance from successful cancellation, without suggesting cancellation waits for the cooling-off period.

D2 — Limit the visibility claims to personal media and preserve the accepted cache limitation.

The same manual paragraph, and the account spec, say the person’s content becomes hidden immediately. But liveContent covers memes, uploads and generated images. Published facts and approved comments remain readable; the comment listing does not exclude authors awaiting deletion.

The manual also says only the owner can see Recently deleted content, without acknowledging previously loaded copies. David already accepted that residue in the plan’s answer 5(b), and the existing deletion screens disclose it.

Recommend naming the affected personal media explicitly, distinguishing community contributions, and explaining that previously loaded copies can remain visible. Keep the precise cache duration in the technical spec. This is worth correcting because the current prose promises disappearance that a person can directly observe has not occurred. Success means the account-deletion and My content descriptions match S2’s scope and the settled cache decision.

D3 — Remove the retention guarantee contradicted by the purge.

The retention matrix still promises seven-year retention through anonymization, and its “Legal hold path” says payment records are not dropped. The purge explicitly deletes the account’s membership history; entitlement rows cascade with the user. The newly revised membership documentation correctly describes that removal.

These sentences predate this change, but they directly contradict the lifecycle this harvest now documents and references. Someone consulting the matrix could wrongly believe those records remain recoverable.

Recommend updating the payment row and operational-control statement to describe the implemented behavior, including the actual dispute hold, and replacing the retired table names. This establishes no new retention policy. Success means the matrix and deletion spec agree about which local records survive.

D4 — Correct the Drizzle example and narrow the diagnostic rule.

The new memory note demonstrates the problem inside .where(...). I compiled that example with the installed Drizzle library: it produces "memes"."storage_path", correctly qualified. Moving the expression into the selected fields produces bare "storage_path" and demonstrates the actual problem.

The real content-purger query uses that selected-expression shape. The learning is useful, but its current example would send future debugging toward working queries.

Recommend using the actual selected correlated-count shape and narrowing the note’s description and MEMORY entry accordingly. Success is a small .toSQL() demonstration that reproduces the unqualified reference and shows the qualified correction; no new checker or test suite is warranted.

Recommend Claude make these prose corrections together, regenerate the affected Help content, and run the existing documentation checks. The supplied clean automatic review does not resolve these directly observed discrepancies.

---

Generated by Claude Code

[TheAnswerManIsHere]

Fable — round 1

Assessed at 65b1d7f95ee6d2ca429df76a7465224b60741b91 · documentation pass over 54f5b2fc84b164afa40a38bfed3a8292986b50fc..65b1d7f95ee6d2ca429df76a7465224b60741b91 · Codex's automatic pass: clean · expected claude-fable-5-1 · instructed alias fable · definition effort xhigh

Oracle met at this head: yes
Running as: Claude Fable 5.1 (claude-fable-5-1) at reasoning effort 80, as the harness tags it.

David's readout

The write-up of Phase 5 is accurate. I checked the account-lifecycle claims the new text makes — who may do what while unverified, un-onboarded, suspended or leaving; how a sign-in and a suspension are kept from crossing; the deletion engine's stages, timings, locks, what it keeps and what it deletes by who asked; the retired admin "deactivate" — against the code at this head, and every one held. The retired mechanism is gone from the prose everywhere I looked, and each learning landed in the home the documentation contract names.

Three small things are worth the one batch this class allows, none of which changes what was built:

1. The glossary and the spec name an admin button that doesn't exist. They call it "Delete permanently"; the screen says "Delete User" and confirms with "Confirm Hard Delete". Someone following the manual would look for the wrong label.
2. Two rows of the launch inventory still say Phase 5 hasn't happened. The inventory marks four account rows done, but still lists "single-use reset links" and "password change signs out other devices" as things to do next, and a note still says there is no age gate. All three shipped in this phase, and the chapter you'd read beside the inventory now says the opposite.
3. The data-retention table says payment history is kept seven years and anonymised. The deletion engine deletes it with the account, which the manual's payments chapter — rewritten in this same pass — now says plainly. The table's row should say what the product does; whether a seven-year obligation requires anything beyond Stripe's own records is a compliance question I can't settle, so the row should carry the documentation contract's Needs David confirmation marker rather than an invented answer. Nothing needs your decision to merge this — the marker is the honest state, and you can answer it whenever the compliance phase reaches it.

Recommendation: write the one batch for these three and merge. Nothing here reaches outside this pull request.

Assessment and recommendations

Codex's automatic pass returned nothing, so the concerns below are mine, from reading the diff against the oracle and the checkout. What I inspected directly is marked; nothing here rests on the builder's account (none was supplied).

D1 — Two documents quote an admin control by a label the screen does not carry

Where. docs/ai-context/glossary.md, Remove: from the user editor ("Delete permanently"). docs/ai-context/accounts-and-auth.md, The callers: the user editor's "Delete permanently" (DELETE /admin/users/:id?hard=true).

What the checkout says (direct inspection). The button that opens the hard-delete dialog in artifacts/overhype-me/src/pages/admin/users.tsx:1329-1335 reads <Trash2 … /> Delete User; the dialog's heading at :513 is Confirm Hard Delete, and its body says "permanently delete all data for …". git grep -n "Delete permanently" -- artifacts/overhype-me/src returns nothing, so no surface carries that label.

Class and worth. A UI label quoted in prose that the UI does not show. The glossary is human-facing: an admin reading it looks for a button that is not there. For a model reader the consequence is concrete too — this repo's E2E convention finds elements by visible name (removal-e2e-sweep-by-label-not-only-testid.md), so a test written from the spec's label would never find the control. Cheap to fix, and the sweep is bounded: these two sentences are the only places in the batch that quote the label (the manual's chapter 9 says "from the user editor" without naming it; chapter 11 says "removing it").

Correction. Name the control as the screen does in both sentences — "Delete User", confirmed by "Confirm Hard Delete" — or drop the quoted label and keep the route. Observable: git grep -n '"Delete permanently"' docs/ returns nothing, and the two sentences match users.tsx's strings.

D2 — Inventory rows still describe Phase 5 deliveries as pending, beside a chapter that says they shipped

Where. docs/ai-context/launch-feature-inventory.md:

• B13 Password reset | … | ship; single-use hardening \next``
• B14 Set / change password | … does not log out other sessions | doc | ship; session logout on change \next``
• the notes line 146: **Age gate:** none exists (registration asks nothing). Proposed for launch: 13+ attestation at sign-up, 18+ for photo upload …

What the checkout says (direct inspection). Both B13 and B14 items landed in one Phase 5 commit: git log -S'revokeUserSessions(tx, userId, currentSid)' names 3928c87 Launch Phase 5, Increment 2: single-use reset links, password changes end other sessions, provider-verified email (#798). The reset claim is a conditional UPDATE … SET used_at (localAuth.ts:453-459, refusing "used" at :436); the member's set-password revokes every session but the caller's (localAuth.ts:765). The age gate: eligibility.ts derives is13Plus/is18Plus from date_of_birth, and onboarding.ts's purpose line says onboarding requires it with under-13 refused. This same PR writes all three as current truth — accounts-and-auth.md § Session management ("a member's own set-password (all but the caller's)"), manual chapter 9 ("Every password change signs your other sessions out", "A reset link works once", "Under 13 is refused").

Class and worth. Two live statements of one fact that now disagree, in the one file David reads to see what is still owed for launch. The batch's own commit 65b1d7f is titled mark the inventory's B10, B11, B24 and J8 rows done in Phase 5, so this is the same correction applied incompletely, not a new kind of edit. The failure is reversible but recurring: every /maintenance or launch-readiness read of the inventory re-derives "still to do" from these rows. Worth the one batch.

Correction scope. The class is inventory rows and notes whose next / "fix for launch" / "none exists" statement Phase 5 delivered, not the three members I found. Two more Claude should check before closing the class rather than take from me: B17 ("OAuth accounts silently default to he/him — fix for launch": onboarding now confirms pronouns for every sign-in method, but I did not verify what the OAuth upsert writes before onboarding) and B1's description ("optional pronouns; logged in at once" — still true at the API, localAuth.ts:106-162, but pre-Phase-5 in shape; a judgement whether it misleads). Line 156's "NSFW mode is a post-launch feature: design for it now … without shipping it" is the decision 6b enacted and reads correctly as a decision; leave it. Observable: each affected row carries the same italic Done in launch Phase 5 (#795): … — link annotation B10/B11/B24/J8 received, pointing at the spec section that now states the behaviour.

D3 — The retention matrix's Payments row asserts a lifecycle the engine does not perform

Where. docs/data-lifecycle-retention-matrix.md, row Payments: \subscriptions`, `lifetime_entitlements`, `membership_history` | 7 years (tax/accounting baseline) | irreversible anonymization instead of deletion where financial audit integrity is required`, and the bullet Legal hold path: payment-domain records are anonymized, not dropped, when deletion would break fiscal obligations.

What the checkout says (direct inspection). The purge's final transaction (artifacts/api-server/src/lib/accountDeletion.ts:627-640) runs tx.delete(stripeCheckoutRequestLedgerTable), tx.delete(membershipHistoryTable) and tx.delete(activityFeedTable) for the user, then tx.delete(usersTable) whose cascades take membership_entitlements. Nothing anonymises, and nothing is retained locally for seven years. The same PR says so two chapters over: manual 10 now reads "removes the history at the purge, in the same final step that removes the account itself", and membership-entitlements.md "in the same transaction that deletes the user row" — both of which I confirmed against those lines. The row's table names also match no schema table (membership_entitlements is the real one).

Class and worth. A human-facing compliance statement the code contradicts, left standing in a file the batch rewrote around it: the Auth, Profile, Social and Uploads rows and the One deletion engine bullet were all brought to the engine's truth; this row and its bullet were not. The contradiction predates the PR, but the sweep made it adjacent and more visible. Lower than D1 and D2 — the matrix has been aspirational in places for a long time — and still a one-row edit while the file is open.

Correction. State what the product does: payment-domain rows go with the account at the purge; the financial record of a charge is Stripe's. Whether a seven-year retention obligation requires anything local is a compliance question outside this PR and not a technical fact — carry it as Needs David confirmation on the row, the marker documentation-workflow.md Step 4 already prescribes for an unverifiable product claim, rather than either leaving the false row or inventing a policy. Observable: the row names the real tables and the purge's action, the Legal hold path bullet no longer claims anonymisation the code does not do, and the open compliance question is marked, not asserted.

Checked and not raised

Listed so the batch knows these were read, not missed; none would change what a reader does.

• The deleted_at IS NULL class guard. The spec says the test fails "if any file outside contentVisibility.ts" spells it. The test (phase5.contentVisibility.test.ts:324-325) also allows lib/seed.ts's legacy DDL, skips __tests__, and catches Drizzle's isNull(x.deletedAt) form too. A reader adding a new spelling is refused either way, and the test names its own allowlist. Optional precision if the paragraph is being edited anyway.
• Suspension reason "under 500 characters": the route refuses > 500 with that very wording (routes/accountSuspension.ts:18); consistent with the product's own message.
• Migration 0122 named before it exists. lib/db/migrations/ stops at 0121. The prose says it "runs only once the release that stopped using it is the published one" and decisions.md says "after the next publish"; the Handoff in the oracle fixes the number. Future tense is clear enough.
• security-model.md restates the share-lock mechanism beside accounts-and-auth.md. It is a trust-boundary summary that links to the spec for the two layers and the recorded gap, not a competing statement of the rule.
• decisions.md places two 2026-10-30 entries above an existing 2026-11-02 one. Structure, which the oracle puts out of scope.
• The generated help bundle under artifacts/overhype-me/src/generated/help/ is produced by generate-help-content.ts and checked in CI by check:help-content (.github/workflows/build.yml:249-250) — mechanical.
• The deferred-work.md pointer for the missed-webhook gap resolves (deferred-work.md:557-579, the Stripe↔local reconciliation entry) and that file contains no deactivate/reinstate prose to go stale.
• Routing follows documentation-workflow.md Step 2 as read: the two gotchas are memory notes with their MEMORY.md lines; decisions in decisions.md with Decision/Why/Reference/Revisit; terms in the glossary; engineering gotchas in migrations-and-backfills.md and TESTING.md; subsystem truth in the subsystem docs; no new context doc (so no AGENTS.md change owed) and no new Manual chapter (so no TOC change). The manual chapter cites the head it was verified against.
• Factual claims verified against the checkout and found as written: eligibilityOf's order; GATE_EXCEPTIONS per state including POST /users/me/deletion for an un-onboarded account; createSignInSession's .for("share") in one transaction; the 400 text on a soft delete; PATCH ignoring isActive; 0120 moving legacy is_active=false rows to suspension; 0118's column with no default; 0121's audience CHECK and adult_verified_at; the stage list and requested_by values; DELETION_COOLING_OFF_DAYS = 14, FRESH_SIGN_IN_MS ten minutes, 5-an-hour rate, panel limit 200, batch 100, the six cancellable statuses, billing_version and the ten-minute cancel bound; the OAuth suspension decided before the upsert with redirect /login?error=account_suspended; email_verified as true or "true"; the captcha flag gone from authMiddleware; loadSourceStateVersions still exported and refreshSourcesForReinstatement gone; single-use reset claim; onboarding draft; US pre-tick from cf-ipcountry; never-onboarded selection with NOT EXISTS on prior requests; panel ordering errors-first; restore window default 30 days; the profile-photo refusal and the meme 410; submitterDeletedAt carried by the staging path; beta_overlay as a declared test exception; the launcher's Turnstile test-secret refusal (productionModeGuard.ts:31-63); the seeded E2E accounts' onboarding and date of birth; assertNotSelfDemotion on suspend; the admin removal's 500 naming the stage.

Limits. I read the plan file at its digest and the quoted oracle; I could not fetch Issue #795's comments from this container, so where the prose cites a David decision I checked it against the plan's David's answers (the Phase 9 comment-delete button, the Phase 14 Terms override, the US pre-tick, under-13 refusal are all there) rather than the issue. I did not run the test suite; claims about what a test does rest on reading the test.

Questions and next action

For Claude. D1 and D2 are supported and bounded; D2's class has two candidate members (B17, B1) to check before the sweep is called complete. D3's prose fix is supported; its Needs David confirmation marker is the right state for the compliance question, not a request to settle it now.

For Astra. Nothing disputed that I can see; if Astra reads D3 as out of the phase's scope, I would still write it, since the batch rewrote the rows on either side of it and the manual it contradicts — but it is the one of the three I would drop first.

For David. Nothing blocks. The one item surfaced for later is whether any local seven-year retention of payment history is required; the marker holds the question until the compliance phase.

Next action: write the one Documentation batch — D1, D2 (with the class check), D3 — and merge on green CI. Recorded gap: none; all three fit the single batch this class allows, and none reaches outside this pull request.

---

Generated by Claude Code

[TheAnswerManIsHere]

round: 1 (Documentation class: one pass, one batch)
head assessed: 65b1d7f
decision: write one batch covering every finding from both assessments, then merge on green CI (no further review in this class)

Astra D1 — class: a requested external operation (Stripe cancel) presented as accomplished. Fixed in Manual ch. 9, ch. 10, accounts-and-auth.md (Accepting a request), glossary (Account deletion), decisions.md (2026-10-30 entry) and the retention matrix (One deletion engine). Sweep: `grep -rn -i "nothing bills again\|cancels the subscription at once\|cancels billing\|at the moment it is asked" docs/` over the live docs, so each instance is reworded to "starts cancelling … retried until Stripe confirms".
Astra D2 — class: "content hidden" claims broader than liveContent (memes, uploads, generated images), plus the accepted cache residue. Fixed in Manual ch. 9 (account deletion and My content), accounts-and-auth.md, glossary, decisions.md and the matrix. Sweep: `grep -rn -i "hidden at once\|hides content\|hides their content\|content is hidden" docs/`, which leaves only the corrected ch. 9 line. Facts and approved comments are now said to stay readable until the purge (verified: routes/facts.ts's comment listing has no leaving-author filter).
Astra D3 + Fable D3 — class: a local payment-retention claim the purge contradicts. Fixed in the matrix: the Payments row names the real tables (membership_entitlements, membership_history, stripe_checkout_request_ledger — verified in lib/db/src/schema) and the purge's action, and the Legal hold bullet describes the dispute hold. The 7-year question is marked **Needs David confirmation**, not decided.
Astra D4 — class: a memory note's example that does not reproduce its bug. Reproduced with `.toSQL()` at this head: a selected-field interpolation renders bare `"storage_path"`; the WHERE form renders `"user_ai_images"."storage_path"`. The note and its MEMORY.md line are rewritten around the measured selected-field shape and contentPurger.ts's real query.
Fable D1 — class: a UI label quoted in prose that the UI does not carry. Fixed in glossary (Remove) and accounts-and-auth.md (The callers): "Delete User", confirmed by "Confirm Hard Delete" (users.tsx:1334, :513). Sweep: `grep -rn "Delete permanently" docs/` returns nothing.
Fable D2 — class: inventory rows or notes whose `next` / "fix for launch" / "none exists" Phase 5 delivered. B13, B14 and B17 and the age-gate note are annotated "Done in launch Phase 5 (#795)" with a spec link, joining Users, B10, B11, B24 and J8. B1's description ("optional pronouns; logged in at once") is still true at the API, so it is left as is.
checks: check-docs-accuracy ✓; check-manual-tuning-language ✓; help regenerated, check:help-content ✓

---

Generated by Claude Code