Version. 0.1
Date. 2026-08-25
Author. Claude Code on DUNIN7-M4. Operator: Marvin Percival.
Status. OWED — two acceptance walks, both requiring the Operator's own authenticator. Not commissioned work; a tracked obligation. Neither walk can be performed by any headless session, now or later.
Provenance. The passkey-commit half has been outstanding since 2026-07-22 (manifest v0.71) and is named in current-status/loomworks-state-of-the-build-report-v0_1 §7 #16. The Foundation-redirect half arrives with cr-create-stage-polish Decision C, merged to Operator-Layer main at 39cee7f on 2026-08-25.
The passkey-commit acceptance drifted for five weeks because it was never an item — it was a sentence inside a status manifest.
It lives today at current-status/current-status-manifest-v0_78.md line 9, as prose: "the browser passkey-commit remains the one pending step across all three doors (the passkey tap is the Operator's)." A manifest is a snapshot of what was true when it was written. It is not a tracker, nothing re-reads it looking for open obligations, and each new manifest version carries the sentence forward unchanged — which is exactly what happened, six versions running.
Decision C's redirect now owes a walk of the same kind, for the same reason. Filing it as a second sentence in a second document would reproduce the failure. Both are here, in one item, so they are walked together — they are the same ceremony, one after the other, on one screen.
What must be shown. An engagement created through each of the three create doors reaches the commit ceremony and the Operator's passkey tap completes the commit — the engagement goes candidate → active with the seed committed.
Doors: 1 "talk it through", 2 "I'll tell you", 3 "here's my specification". All three converge on one compose→commit terminal, so the ceremony is the same at the end of each; what differs is the path to it.
Why headless cannot do it. commit_engagement calls _assert_commit_step_up → assert_commit_presence, which requires a fresh presence proof per the committer's organization policy — for an always-tap org, a commit-time WebAuthn attestation. That attestation is a physical touch on the Operator's authenticator. There is no bypass that is not the dev-endpoint exposure closed as a security incident on 2026-07-19.
Prior evidence, so this is not started from zero. Door 1 was live-verified headless to the WebAuthn gate and the greeting render was browser-confirmed by screenshot (manifest v0.71). Everything up to the tap is proven; the tap is what is owed.
What must be shown. On a real commit, the Operator lands inside the new engagement with the Foundation document open — not on a confirmation screen. Then: closing the Foundation panel strips ?foundation=open from the URL, and a refresh does not re-open it, because the dismiss is an Operator-authority act that must hold.
What is already proven, and what that does not cover. Unit tests pin both halves — DocumentCreateFlow pushes /operator/engagement/{id}?foundation=open on commit, and InEngagementSurface opens the panel from that flag and calls router.replace(pathname) on close (tests/components/chat/DocumentCreateFlow.test.tsx, tests/components/engagement/InEngagementSurface.test.tsx). The production build also succeeds, which is real evidence for the Suspense boundary specifically: Next.js fails the build when useSearchParams is used without one in an App Router route.
None of that is the walk. Mocked router.push proves the call was made, not that the Operator arrives anywhere. The redirect target resolves a candidate UUID through fetchProjectByAddress's UUID fall-through once the engagement is active — a live-data behaviour no mock exercises.
Why it must follow Walk 1 rather than run beside it. Walk 2 begins where Walk 1 ends: it needs a real commit to redirect from. The passkey tap is the entry condition for the redirect, so the two walks are one continuous sequence and splitting them would mean performing the ceremony twice.
main at 39cee7f or later. The merge is pushed but not deployed; the running service still serves a .next build from 2026-08-14. The redirect does not exist in what is currently served. See the deploy request accompanying this filing.Both walks recorded with what was observed — not "tests pass", but what appeared on the screen at each step, including the URL after the redirect and after the dismiss. On success this item closes and the manifest sentence retires with it. On failure, whatever is found is a defect filed against Decision C or against the ceremony, and this item stays open.
This item does not cover the wider surface-vocabulary conflict — that is B-117 in standing-notes/dunin7-build-list-v1_06. It does not cover the engagement-creation flow's design, only its acceptance. And it commissions nothing: it records an obligation that already existed and adds the one that just arrived beside it.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Create-Stage Browser Acceptance — Work Item — v0.1 — 2026-08-25