DUNIN7 · Loomworks · walk audit
You don't start anything. v0.1 gave three terminals and a start-up script at a scratchpad path that has almost certainly been cleaned up. Claude Code brings the stack up and tells you when it's ready.
Task 2's Manifestation expectation is reversed. v0.1 said: create an engagement, try to view its Manifestation, and it should fail. CR-2026-158 fixed that on 2026-07-30 and the fix is deployed — it should now succeed. Following v0.1 as written, a pass would have been recorded as a failure.
Task 1's expectation is now uncertain, deliberately. v0.1 said doors 1 and 2 dead-end at a commit step returning 422. CR-2026-158 resolved that by removing the route, so the shape of the dead-end has changed and this version doesn't tell you what to expect. Record what you see.
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.
The three ways to create an engagement
Go tohttp://localhost:3005/operator/create-engagement
DoLook at the landing page. Click "Talk it through", go back. Click "I'll tell you", go back. Click "Here's my spec", go back.
Should beThree clearly different choices, each opening its own screen, each returnable-from without losing your place.
Tell meWhether all three open and return cleanly. If any 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.
Create a real engagement from a document, and tap your passkey
Go tocreate-engagement → "Here's my spec"
DoUpload any two-page brief. 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 beAll 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 meDid the passkey prompt appear and did the tap complete; did your edit survive; did the Manifestation come up.
Tell the Companion some facts
Go toThe Companion, synthetic engagement
DoTell it two or three separate facts in one message. Then say "show held".
Should beEach thing you said acknowledged with a number, and the held tray listing them with the same numbers, correctly attributed to you.
Watch forWhether two facts in one message become one item or two — and whether the tray fills in immediately or only after a refresh.
Tell meHow many items your multi-fact message produced, and whether the tray needed a refresh.
Try to withdraw something you already committed
Go toThe Memory room, synthetic engagement
DoFind a committed note. Look for any way to withdraw it — a button, a menu, or just asking the Companion: "retract that", "withdraw finding 2".
ExpectThere isn't one. That's the known finding.
But watchIf 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 meWhether you found any way to do it, and exactly what the Companion did if you asked it.
Try to see what a note said before you corrected it
Go toThe Memory room, synthetic engagement
ContextNote #3 is the corrected one. It started as "three of the eleven branches" and was corrected to "four of the eleven branches."
DoTry to see the earlier wording from the screen. Then ask the Companion: "what did finding 3 say before I corrected it?"
ExpectYou can't. The system keeps every version; no screen shows any of them.
Tell meWhether anything at all showed you the earlier text.
Ask the Companion the question that got the wrong answer
Go toThe Companion, synthetic engagement
DoAsk, in your own words: "How many of the eleven branches have instant-issue card capability?"
The truthFour — and that note is committed, settled, not pending.
Last time"three… though that note is still waiting for your okay, not saved yet." Wrong number, wrong status, said with confidence.
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 meThe exact answer for each phrasing you tried. Word for word if you can.
Look for the summary view and the shapes
Go toThe control engagement — Manifestation room, then Shaping room
DoJust look at both.
ExpectBoth say something like "No shapes waiting on you yet." — even though this engagement genuinely has a summary view and two finished shapes in it. Those two rooms are placeholders.
Tell meThe 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.
Try to get the finished document out
Go toThe control engagement — Rendering room, then the Companion
ContextTwo real finished documents are in there. One says "four of the eleven branches"; the newer one says "5 of the 11 branches" and mentions the Doral branch.
Do(1) In the Rendering room, open one — expect it to open in a new tab rather than download. (2) Look for any download button — expect none. (3) Ask the Companion: "Can I download the finished Board brief for Meridian?"
Last timeIt couldn't find anything called "Board brief", offered two raw ID strings, and asked whether either meant anything to you.
Tell meWhether 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.
Ask the Companion to do the work, then try to give it permission
Go toThe Companion, control engagement
Do(1) Ask it to produce a new draft of the Board brief from the current content. (2) It should refuse for lack of permission and suggest wording for granting it. (3) Say exactly what it suggested. (4) Ask again.
Should beStep 3 grants the permission and step 4 produces the draft.
Last timeStep 3 was misread as a personal note about yourself and filed as one. No permission granted. Step 4 refused again.
Tell meWhat it suggested, what happened when you said it, and whether anything worked. 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".
Free look: can you see what happened, in order?
Go toAnywhere — dashboard, library, the control engagement's own screens
DoTry to answer 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.
ExpectNothing shows you that. There are counters reading zero and a list of two identically-labelled documents.
Tell meWhether 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?>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.