Finish the Add-Matter stepper: the editable Step-5 frame drives matter create

Bug-1379 first: why the frame never even appeared

Wiring the editable frame is moot if it never settles. Step 5 hung in the skeleton because of a wire contract mismatch, not StrictMode (the rail was healthy). The brain (runtime.py::_turn_event → _wrap_proposal) puts the proposal on the wire as a nested object — turn.proposal.{description, core_dispute, prayers, value_amount_minor} plus the truth-boundary envelope. But the app's proposalFromWire (src/lib/agents/atlas-rail.ts) read them flat (turn.proposal_description). The #85 flatten only flattened the brain's generation DTO; the wire AtlasTurn still nests.

• next_message_md is top-level → the chat drawer rendered "the frame is ready".
• proposalFromWire read undefined → proposal = null → the card stayed in ThinkingState forever.
• Broker passes frames through verbatim — the runtime's nested shape IS the wire. App-side bug.

Fix: proposalFromWire reads the nested proposal. The rail tests were rewritten to the real nested wire shape — they were green before only because they mirrored the app's wrong assumption ("fixtures lie in your favor").

The gap: done at the component boundary, not the system boundary

The wiring

• add-matter-wizard.tsx — builds editableSnapshot (the same scope the rail uses), and passes it + matter-type / forum / label options + onCommit to Step5ReviewForm. onCommit maps the committed editable frame to the create payload and calls onCreate.
• New editable-frame-commit.ts — commitPayloadFromEditableFrame(edited, ctx). The edited prose / value / matter-type / forum drive create (matter-type & forum NAME resolved back to the firm-catalog id, with a wizard fallback). clientId + parties + team + openedOn/caseRef come from wizard state — the editable model drops entity ids (toEditableMatterFrame seeds client.id = "client").
• add-matter-chrome.tsx — a showNext flag; the wizard passes showNext={!isLast} so Step 5 shows exactly one commit control.

Edit-now, persist-later decided

prayers, proceeding / filing types, the separate coreDispute, and party renames are editable but NOT sent to create — WizardMatterInput has no field for them yet (same precedent as the Team step, which already isn't persisted). A backend follow-up.

The proof: the full chain, tested two ways

• Integration test (edit-to-create-chain.test.ts) walks that whole chain and asserts the edited narrative + value land in coreDisputeText / valueAtStakeAmount — the exact cross-hop boundary #1379 hid in. Plus a unit test for the mapper. 20+ tests green.
• Live, real wizard, LIVE DB — all 5 steps, Step 5 settled into the editable frame, footer showed only "Back" (one commit button), edited the description to a marker, "Save & Next" → POST /app/matters 201. The server action received coreDisputeText = the edited marker (not the Step-2 draft); the marker is present in the refetch (persisted), and M-0004 appeared in the register.

Files

Files changed

8 file(s), +427 / -48 lines