Version. 0.2
Date. 2026-07-30
Author. Claude.ai. Operator: Marvin Percival.
Supersedes. loomworks-walk-audit-operator-checklist-v0_1 (2026-07-29), which stands as a sibling. v0.1 is not wrong about what it was written for — it was written for a session to hand the Operator, and it assumed the Operator would bring the stack up himself and read expectations against the walk-audit report's W-numbers. This version removes both assumptions and corrects two expectations that CR-2026-158 changed.
Time. About fifteen minutes in the browser, once the stack is up. Bringing the stack up is a session's job, not yours.
1. You don't start anything. v0.1 gave three terminals and a start-up script at a scratchpad path (/private/tmp/claude-501/…) that has almost certainly been cleaned up. Claude Code brings the stack up and tells you when it's ready. See "Getting the stack up" below — it's one paste.
2. Task 2's Manifestation expectation is reversed. v0.1 said: create an engagement, then try to view its Manifestation, and it should fail — that is W-1. CR-2026-158 fixed W-1 on 2026-07-30 and the fix is deployed. On the current engine that view should now succeed. Following v0.1 as written, a pass would get recorded as a failure. This is the single most important correction in this version.
3. Task 1's expectation is now uncertain, deliberately. v0.1 said doors 1 and 2 both dead-end at a commit step returning 422. CR-2026-158 resolved that rider by removing the route, so the shape of the dead-end has changed and this version does not tell you what to expect. Record what you see.
4. The W-numbers are gone from the body. They're in the appendix if a session needs them. You shouldn't have to decode a break list to click through a product.
Paste this to Claude Code. Wait for it to report ready.
Bring up the walk-audit dev stack for the Operator's browser pass. This is dev-only and must not touch the live :8000 engine, the live Operator Layer, the launchd services, or playground_dev.
1. Confirm the playground_walkaudit database exists and both walk-audit engagements are present.
2. Start the dev engine on 127.0.0.1:8001 from ~/loomworks-engine, inline env only, never writing .env:
DATABASE_URL=postgresql+asyncpg://playground@localhost:5432/playground_walkaudit
LOOMWORKS_ENV=development
WEBAUTHN_RP_ID=localhost
WEBAUTHN_RP_ORIGIN=http://localhost:3005
WEBAUTHN_ADDITIONAL_ORIGINS=
LOOMWORKS_DATA_DIR=/tmp/walkaudit-data
Sourcing ~/loomworks-engine/.env first for secrets only is fine; every value above overrides it.
Confirm /healthz returns database_reachable true and the environment reads development.
3. Start the dev Operator Layer on localhost:3005 from ~/loomworks:
ENGINE_ORIGIN=http://127.0.0.1:8001 NEXT_PUBLIC_API_URL=/api next dev -H localhost -p 3005
4. Report, before I start clicking:
- which branch and commit ~/loomworks is on, and how far it sits from OL main
- which commit ~/loomworks-engine is on, and whether CR-2026-158's registry fix is present in this tree
- whether the create-from-conversation route appears in the dev engine's OpenAPI
- whether /api/auth/dev/issue-session is available on this build
- confirmation that nothing you started is reachable through the Cloudflare tunnel
Leave both processes running. Do not tear down until I say.
Then sign the browser in. Open http://localhost:3005, press F12 for DevTools, click Console, paste this one line, press Enter:
await fetch('/api/auth/dev/issue-session',{method:'POST',headers:{'Content-Type':'application/json'},credentials:'include',body:JSON.stringify({person_id:'910c64ec-d52b-47a7-bb0c-cde76173d3c2'})}).then(r=>r.status)
It should print 204. Reload the page. You should be Walk Audit Operator.
If it doesn't print 204, stop and tell Claude Code what it printed — don't work around it.
| Which | Name | What it has |
|---|---|---|
| The synthetic one | WALK-AUDIT-2026-07-28 | Six notes. One was corrected, one withdrawn, one moved. |
| The control | WALK-AUDIT-2026-07-28-CONTROL | The full chain — a summary view, two shapes, two finished documents. |
Tasks 1–6 use the synthetic one. Tasks 7–10 use the control, because it's the only one with finished work in it.
For each task: where you go, what you do, what to tell me. Where I know what to expect, I say so. Where I don't, I say that too — and those are the interesting ones.
Go to: http://localhost:3005/operator/create-engagement
Do: Look at the landing page. Click "Talk it through", then go back. Click "I'll tell you", go back. Click "Here's my spec", go back.
Should be: three clearly different choices, each opening its own screen, each returnable-from without losing your place.
Tell me: whether all three open and return cleanly. If any of them dead-ends or errors when you try to finish, describe what you saw on screen — not a guess at the cause. The behaviour of doors 1 and 2 changed yesterday and I don't know what they do now.
Go to: create-engagement → "Here's my spec"
Do: Upload any two-page brief — a Markdown or Word file, whatever's to hand. Let it extract. Read the five commitments it pulls out. Change one of them. Continue to the commit step and tap your passkey when prompted.
Should be: all five commitments come back filled in from your document; your edit sticks; a real passkey prompt appears; after the tap, the engagement exists.
This is the only task that tests the real ceiling. The audit skipped the passkey tap, so no one has ever proved the attestation path works end to end from a browser. Your tap is the proof.
Then, straight away: open the new engagement's Manifestation — the "organize what we know" view. It should now work. Yesterday it couldn't; B-1 fixed exactly that and the fix is live. If it fails, that's important and I need the exact error.
Tell me: did the passkey prompt appear and did the tap complete; did your edit survive; did the Manifestation come up.
Go to: the Companion, with the synthetic engagement open
Do: Tell it two or three separate facts in one message. Then say "show held".
Should be: each thing you said is acknowledged with a number, and the held tray lists them with the same numbers, correctly attributed to you.
Watch for two specific things: whether two facts in one message become one item or two — and whether the tray fills in immediately or only after you refresh.
Tell me: how many items your multi-fact message produced, and whether the tray needed a refresh.
Go to: the Memory room, synthetic engagement
Do: Find a committed note. Look for any way to withdraw it — a button, a menu, or just asking the Companion in plain words: "retract that", "withdraw finding 2".
Expect: there isn't one. That's the known finding.
But watch closely: if the Companion responds to "retract that" by discarding or changing the note instead, that matters much more than the missing button. Quietly doing a different thing than the one you asked for is a worse problem than not offering it at all.
Tell me: whether you found any way to do it, and exactly what the Companion did if you asked it.
Go to: the Memory room, synthetic engagement
Note #3 is the corrected one. It started as "three of the eleven branches" and was corrected to "four of the eleven branches."
Do: Try to see the earlier wording from the screen. Then ask the Companion: "what did finding 3 say before I corrected it?"
Expect: you can't. The system keeps every version; no screen shows any of them.
Tell me: whether anything at all showed you the earlier text.
Go to: the Companion, synthetic engagement
Do: Ask, in your own words: "How many of the eleven branches have instant-issue card capability?"
The true answer is four, and that note is committed — settled, not pending.
What it said last time: "three… though that note is still waiting for your okay, not saved yet." Wrong number, wrong status, said with confidence.
Please ask two or three different ways. This is the most important item on the list. It's a six-note engagement, so this isn't the known "too much to search through" limit — it's the system reading an out-of-date version and misdescribing its status.
Tell me: the exact answer for each phrasing you tried. Word for word if you can.
Go to: the control engagement — Manifestation room, then Shaping room
Do: Just look at both.
Expect: both say something like "No shapes waiting on you yet." even though this engagement genuinely has a summary view and two finished shapes sitting in it. Those two rooms are placeholders.
Tell me: the exact wording of the empty message you see. Misleading empty text on a non-empty engagement is its own finding, separate from the rooms being unbuilt.
Go to: the control engagement — Rendering room, then the Companion
There are two real finished documents in there. One says "four of the eleven branches"; the newer one says "5 of the 11 branches" and mentions the Doral branch.
Do, in order:
What it said last time: it couldn't find anything called "Board brief", offered two raw ID strings, and asked whether either meant anything to you.
Tell me: whether you could get the file, and — importantly — whether you could tell the two documents apart from the screen. Last time the dashboard labelled both identically.
Go to: the Companion, control engagement
Do:
Should be: step 3 grants the permission and step 4 produces the draft.
What happened last time: step 3 was misread as a personal note about yourself and filed as one. No permission granted. Step 4 refused again.
Try a couple of phrasings. If some wording does work, capture it exactly — "the Companion suggests wording that doesn't work" is a very different problem from "permission can't be granted", and they get fixed differently.
Tell me: what it suggested, what happened when you said it, and whether anything worked.
Go to: anywhere — dashboard, library, the control engagement's own screens
Do: Try to answer this from the product alone: what happened in this engagement, in order? The control has a full history — notes added and committed, one revised, a summary derived twice, two shapes made and confirmed, two documents produced.
Expect: nothing shows you that. There are counters reading zero and a list of two identically-labelled documents.
Tell me: whether any screen did better than that.
One line each is plenty. Anything longer only if something surprised you.
1 — fine / broke: <what you saw>
2 — passkey: yes/no · edit stuck: yes/no · Manifestation: worked/failed
3 — one item or two · tray needed refresh: yes/no
4 — <what the Companion did>
5 — <anything showed the old text? >
6 — <the answers, word for word>
7 — <the exact empty-state wording>
8 — got the file: yes/no · could tell them apart: yes/no
9 — <suggested wording, and whether it worked>
10 — <anything better than counters?>
Two kinds of answer matter most, in this order.
First: anything that works now that didn't before. Several of the "expect it doesn't work" items above were established by reading source code, not by watching the product. A browser can prove them wrong, and that's the point of you doing this rather than a session.
Second: anything worse than described. Silent wrong behaviour — the Companion doing a different operation than the one you asked for, an out-of-date document presented as current — outranks a missing button every time.
Tell Claude Code to stop the two dev processes. Leave the database — the engagements should survive for the next pass.
Task-to-finding map against loomworks-walk-audit-report-v0_1: 1 → rows 0.1/0.6 and W-2 (W-2's shape changed at CR-2026-158; expectation deliberately withdrawn); 2 → rows 0.2–0.5, the CEILING-BYPASSED-DEV attestation gap, and W-1, which is fixed and expected to pass; 3 → row 1.1; 4 → W-4; 5 → W-8; 6 → W-5; 7 → W-9; 8 → W-12, W-13; 9 → W-10; 10 → W-15.
Results merge into the report's break list as amendments from W-17 onward, not as a second audit. Standing caveat carried from v0.1: ~/loomworks was last seen on feat/foray-sales-generator (8c5ec15), ahead of OL main — the stack-up block asks Claude Code to report the current branch before the pass, so any surprising result can be checked for branch-locality before it's filed.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — walk audit — Operator browser checklist — v0.2 — 2026-07-30 Browser-only. The stack comes up by session; the Operator clicks.