C3: consent keeps a record, on the Ora row that already had the switch

[matthewpmunger]

Base sha 95d77a9, verified green before building: lint, typecheck, test (1335), build.
This branch: lint ✓ typecheck ✓ 1357 tests (105 files) ✓ build ✓

Merge after #94 (chunk-f6). Both branches add an entry to REPAIRS.md, so this one will need that one conflict resolved by keeping both entries. Nothing else conflicts.

What this does

Item 1 of the brief was withdrawn before building: a consent control already existed inside Connected systems, so a sixth Settings group would have put two controls and two public-scan disclosures over one boolean — the duplication this chunk exists to prevent. The Ora row is the control. Its heading, note and inline "Connected" / "Not connected" are untouched.

What it gains:

• the retention sentence its disclosure did not say, rendered above the control because that is what somebody needs before deciding;
• beneath it, an append-only history of who changed the setting and when.

The gate is untouched

agent-audit-isolation.test.ts and api/agent-audits/refresh are byte-identical to base, and the consent-defaults-closed line in normalize.ts is unchanged. The consent check still precedes the first target resolution.

Consent moves as one thing

The boolean and the history are written in a single withState; there is no path that writes either alone. A call that does not change the value appends nothing — an entry says what was decided, and re-selecting the position a project is already in is not a decision.

Withdrawal is not a retraction: every stored reading stays present and legible, and one predating the current withdrawal gains a clause the ledger imports rather than restates. The clause is computed against the history, not the boolean, because a project that connected, disconnected and reconnected has readings on both sides of the question — asserted both ways.

Two things corrected after review

• consent.unrecorded (approved seventh string). A project connected before this record existed has a grant with no date. Suppressing the block treated that absence as nothing to report, which is rule 18. Two empty states now get two lines.
• The Ora card is stacked. .settings-system is a flex row, so the history first rendered as a third column beside the toggle. Every structural test passed while it did; only opening the page showed it. Fixed with S8's existing --stacked modifier, with the original row reproduced inside so the Ora row itself is unchanged, and guarded by a test.

Verified against a running app

Grant appends with the verified identity rather than the request body; a repeat of the current value appends nothing; a withdrawal keeps the grant; both lines render beneath the control with absolute dates.

Not verified live: the ledger clause. The demo seed stores no Ora reading, so that path cannot be reached from the seeded app — it rests on unit tests, which assert both sides.

A scope note

The brief's "no src/ path outside Settings" cannot hold alongside its own item 3: an append-only history is storage, so types.ts, normalize.ts and mutations.ts necessarily move. Outside those and Settings, the only change is the one ledger clause and the prop feeding it. Confirmed as correct by the brief's author.

Not a repair

The REPAIRS.md entry records a finding — the retention doc-comment in mutations.ts sits above the wrong function — as explicitly not claimed and not fixed. No repair label, so the base-branch-green gate applies normally.

🤖 Generated with Claude Code