Date. 2026-08-12 · Author. Claude Code (read-only, from the Operator's post-deploy walk on app.dunin7.com). Operator: Marvin Percival. Nothing built, nothing fixed.
Read at. Engine cd91176, surface 7ac3cb2 (the CR-2026-206 deploy).
The Operator's finding, mechanism established. "Your project is ready — tap your passkey to make it official." is server-composed (_creation_seam_http_error_response, router.py:3324) and carried on the wire as request_action="commit_step_up" — a live-response signal only. The text is persisted as a companion turn; the request_action is not persisted anywhere.
The affordance (CommitCeremony) mounts in exactly two components:
ChatView (the creation chat) — from ephemeral React state set by the live response, which deliberately does not append the step-up turn to its own transcript ("present the ceremony…; don't append a turn"). A remount of the same surface loses the ceremony.DocumentCreateFlow (door 3) — its own flow, its own candidates.
The in-engagement surface has zero commit_step_up handling — no ceremony component, no candidate-state affordance, nothing keyed on the persisted turn. The three header controls are exactly what the Operator found by exhaustion: Foundation panel, Contributor access, sort toggle. So the structural answer to "where is it supposed to render from this path": it isn't — no component on the in-engagement page can render it.
The orphaning, stated as a mechanism: the instruction outlives the only surface that can honor it. The engine persists the imperative sentence into the transcript, where it re-renders forever on a page that has no ceremony; the signal that arms the ceremony dies with the HTTP response. E0128 is committable today only through the still-open creation-chat tab from the eye-test (whose ceremony state is live) — close that tab and no conversational-path candidate has any route to commit anywhere in the product. As the Operator ruled: not the unarmed-promise shape — an instruction to act NOW naming an affordance the surface does not have. (The truthfulness standing note v0.2 covers it: a composed instruction must be composed against the wiring that fulfills it — here the wiring exists but only on a surface the reader has left.)
Fix directions visible, reported not decided: (a) render the ceremony on the in-engagement surface for a candidate the viewer created — the candidate's own page is where the instruction strands them; (b) derive the pending-commit state structurally (a candidate engagement IS the state — no new persistence needed to know a commit is pending); (c) stop persisting the imperative sentence and persist a state-honest one, with the ceremony living wherever the affordance actually is. (a)+(c) compose; (b) is what makes (a) cheap.
Half the ruling is built. conversation.message_order is a server-persisted per-user setting (/me/settings), written by BOTH the header sort toggle the Operator found AND the conversational tune_setting path; newest_first is a supported value; the transcript's scroll discipline follows the order. What is NOT built: the composer is fixed at the bottom of the pane regardless of order (ConversationPane owns the bottom bar; nothing is order-conditional) — so newest_first today is exactly the "internally contradictory" state the batch filing named: newest at top, composer at bottom.
One discrepancy needing a ruling before any draft: the surface baseline when nothing is stored is oldest_first (ORDER_DEFAULT, per the companion-surface mockup), while the code comment records the engine-side default key value as newest_first — and the Operator's ruling named "newest-first with the composer at the TOP" as the intended design. The open question the CR must not decide alone: is newest-first-with-top-composer the DEFAULT for everyone, or the shape the newest_first option takes when chosen? The remaining build is small either way (order-conditional composer placement + the default alignment); the ruling decides which.
Mechanism: derive_title_from_seed runs only inside _create_engagement — at insert for fresh creates, and at promote (COALESCE(NULLIF(title,''), :derived)) when a candidate instantiates. Candidates therefore carry NULL titles for their entire candidacy — E0128 and E0129 show "Untitled engagement" in the chip and bare IDs in the list by construction, on every surface, including the very walk the step-up instruction sends the Operator on. After the passkey they would receive the derived title — which is the truncated what_the_work_is text, the defect E0089 already shows.
The item, restated with both failure modes: one derivation gap, two faces — the specification door names engagements with the whole description (truncation at commit); the conversational path names them not at all until commit (NULL through candidacy), then falls into the same truncation. A fix that only improves derive_title_from_seed fixes the first face and leaves every candidate untitled; a fix that only titles candidates inherits the truncation. The item covers both or it isn't the item.
DUNIN7 — Done In Seven LLC — Miami, Florida — v0.1 — 2026-08-12 The instruction outlives the only surface that can honor it.