Phase 5b — The Operator's Console: Studio fact authoring

Phase 5 built the door; Phase 5b is the console a human sits at to use it. The maintainer creates, edits, supersedes, retracts, and merges assertions right in Studio — the read view flips into an edit view on the same post page. You write a fact as a sentence: a governed-predicate picker, a reuse-first object picker, a block picker for grounding, and validity checks, all inline off the panel.

The load-bearing constraint: a claim is immutable — the schema says supersede, never edit. So an existing fact's claim can only change by filing a successor (Supersede) or marking it wrong (Retract); only its date and source are edited in place. A dispute (two contradictory currents) resolves by superseding the loser with the winner; a same_as candidate resolves by a reversible, non-deleting merge. Two registers, one substance — the same facts a reader sees as sentences, an editor maintains as structure.

1. The composer — an inline-off-the-panel affordance to write a brand-new fact as tokens.
2. The predicate picker — the nine governed verbs (about, same_as, owned_by, works_on, decides, status, depends_on, blocks, supersedes), each in humane phrasing.
3. The reuse-first object picker — find an existing thing before you make a new one (the anti-duplication default).
4. The block picker + validity — grounding is checked at author time: the object must resolve to a real, visible block.
5. Supersede + retract + close — the lifecycle actions on an existing fact: supersede files a successor and links it; retract says "we were wrong"; close says "no longer true, no successor."
6. The merge affordance — promoting a confirmed same_as candidate to a merge, one endpoint that dispatches on the stored row (block→block or post→post).
7. Metadata-update (Slice 7, D1) — correct a fact's provenance in place. Because the claim is immutable, a mistyped date should never force a false "we were wrong" retract — so fixing the date/source is its own guarded operation. It was added after the pre-commit review found it missing entirely.

5b is the clearest case for the pre-commit gate. The review closed seven would-have-shipped defects before a line reached prod, including:

• a stored XSS in the text mint — also fixed in the API v1 copy;
• an un-mergeable same_as a test had quietly codified as acceptable;
• a missing archived-guard (create-only) on the authoring path;
• an invisible-but-clickable Close/Retract control;
• an audit item half-done, and its API v1 half missing entirely;
• four false-green tests that passed without proving anything.

And the whole of Slice 7 — metadata-update (D1) — existed only because the review noticed it was absent. This is the duplication ruling in practice: the same invariant lives in the Studio module and the API v1 module as separate copies, so the review has to check both — divergence is the design goal, and undetected divergence is the defect the review exists to catch.