Version. 0.1
Date. 2026-07-29
Companion document. loomworks-walk-audit-report-v0_1.md — this checklist resolves that report's OPERATOR-VERIFY items. Results merge into the report's break list as amendments (W-17 onward), not as a second audit.
Time needed. About 15 minutes once the stack is up.
The walk-audit stack was torn down at the end of the audit. The database survives; the two processes do not. These tasks run against http://localhost:3005 — a localhost-only port that the Cloudflare tunnel does not route (~/.cloudflared/config.yml has no 3005 rule). Nothing you do here is publicly reachable, and none of it touches app.dunin7.com, the launchd-supervised live engine on :8000, the live Operator Layer on :3002, or the playground_dev database.
Terminal 1 — the dev engine on :8001:
/private/tmp/claude-501/-Users-dunin7-foray-api/2fe3eba1-f3e0-4bfd-a7ae-e3c0747ad80f/scratchpad/start-dev-engine.sh
If that scratchpad has been cleaned up, the script is four lines — it sources ~/loomworks-engine/.env for the two secrets, then overrides everything that matters:
cd ~/loomworks-engine
set -a; source ./.env; set +a
export DATABASE_URL="postgresql+asyncpg://playground@localhost:5432/playground_walkaudit"
export LOOMWORKS_ENV=development
export WEBAUTHN_RP_ID=localhost
export WEBAUTHN_RP_ORIGIN="http://localhost:3005"
export WEBAUTHN_ADDITIONAL_ORIGINS=""
export LOOMWORKS_DATA_DIR="/tmp/walkaudit-data" # any path not under ~/loomworks-engine/data
.venv/bin/uvicorn loomworks.api.app:create_app --factory --host 127.0.0.1 --port 8001
Wait for Application startup complete. Sanity check — it must say development, and it must be the walkaudit database:
curl -s http://127.0.0.1:8001/healthz
# {"version":"0.1.0","database_reachable":true,"administrative_engagement_present":true}
Terminal 2 — the dev Operator Layer on :3005:
cd ~/loomworks
ENGINE_ORIGIN=http://127.0.0.1:8001 NEXT_PUBLIC_API_URL=/api ./node_modules/.bin/next dev -H localhost -p 3005
> Note on what you will be looking at. ~/loomworks is currently checked out on branch feat/foray-sales-generator (8c5ec15), which is 10 commits ahead of OL main (99f7f64). It contains all the merged Companion-surface work, so these tasks are valid — but if any result surprises you, check whether it is branch-local before filing it.
Terminal 3 — sign in. The dev principal has no passkey, so use the dev-auth affordance through the OL origin (this is what makes the cookie first-party to :3005):
curl -s -c /tmp/walkaudit-cookies.txt -X POST \
http://localhost:3005/api/auth/dev/issue-session \
-H 'Content-Type: application/json' \
-d '{"person_id":"910c64ec-d52b-47a7-bb0c-cde76173d3c2"}' -w '%{http_code}\n'
# expect 204
**Then, to sign the browser in** (the curl above authenticates curl, not Chrome), open http://localhost:3005, open DevTools → Console, and run:
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) // expect 204
Reload. You should be signed in as Walk Audit Operator.
Tear-down when you are done: Ctrl-C in terminals 1 and 2. Leave the database.
| Name | Id | What it is |
|---|---|---|
| WALK-AUDIT-2026-07-28 | 89caf855-2955-4d8f-8030-fed4290b4a2d | The synthetic engagement, created through door 3. Six assertions, one corrected, one retracted, one redirected. Cannot derive a Manifestation — this is W-1. |
| WALK-AUDIT-2026-07-28-CONTROL | 5bbdd348-2b70-4772-b751-c0b8a5d62951 | The control, created without the door-3 extract step. Carries the full chain: Manifestation v2, two confirmed shapes, two renders. |
Each task: where to go, what to do, what CLEAN looks like. Note anything that differs — especially anything that works better in the browser than it did headlessly, which is exactly what these tasks exist to catch.
Resolves: OPERATOR-VERIFY on walk-table rows 0.1, 0.6
Go to: http://localhost:3005/operator/create-engagement
The door picker is client-rendered, so headless HTTP could only confirm the page returns 200 — not that the picker works.
Do: Look at the landing state. Click "Talk it through", go back; click "I'll tell you", go back; click "Here's my spec".
CLEAN looks like: three clearly distinguished doors (door-talk-it-through, door-ill-tell-you, door-heres-my-spec), each opening its own surface, each returnable-from without losing the page.
Watch for: door 1 and door 2 both end at a commit step the audit found uncallable (W-2 — create-from-conversation returns 422 for every request). If you can drive either door all the way to a created engagement in the browser, that is a significant correction to W-2 and worth recording carefully. If they dead-end at the final step, W-2 stands and you have confirmed its user-visible shape.
Resolves: OPERATOR-VERIFY on rows 0.2–0.5
Go to: /operator/create-engagement → "Here's my spec"
Do: Upload a Markdown specification — reuse the audit's if you like, it is Meridian Credit Union — Member Onboarding Assessment, or any two-page brief. Let it extract. Read the five commitments it returns. Change one of them. Continue to the commit step and tap your passkey.
CLEAN looks like: extraction returns all five commitments populated from your document (it did, headlessly, in 13 seconds with no gaps); your edit persists; the commit step raises a real WebAuthn prompt; after the tap the engagement is active.
This is the one task that tests the real ceiling. The audit bypassed it (CEILING-BYPASSED-DEV) and the resulting engagement carries attestation_recorded: false. Your tap should produce attestation_recorded: true — worth confirming, because it is the only end-to-end proof that the attestation path works.
Then, immediately: try to view the Manifestation for the engagement you just created. It should fail — that is W-1, and this is its cleanest reproduction from the surface.
Resolves: OPERATOR-VERIFY on row 1.1
Go to: the Companion, with WALK-AUDIT-2026-07-28 open
Do: Tell the Companion two or three facts in one message. Then say "show held".
CLEAN looks like: each contribution acknowledged with a display number; the held tray shows them with the same numbers; attribution is legible and correct.
Watch for two things the audit saw headlessly: (a) two facts in one message were held as a single assertion — check whether the surface makes that granularity visible before you commit; (b) the converse response's held_items array came back empty even while the message said "held 1" — check whether the tray populates immediately or needs a refresh.
Resolves: W-4 (confirm the negative)
Go to: the Memory room for WALK-AUDIT-2026-07-28
Do: Find a committed assertion. Look for any way to retract it — button, menu, or by asking the Companion in plain words ("retract that", "withdraw finding 2").
CLEAN would look like: a retract action exists and works.
Expected: it does not. The audit found no retract in lib/api/assertions.ts, and no retract intent in the Companion's vocabulary. If you find one, W-4 is wrong and should be struck. If the Companion responds to "retract that" by discarding or changing the assertion instead, note that precisely — silently doing a different lifecycle operation than the one asked for is a worse finding than not offering it.
Resolves: W-8 (confirm the negative)
Go to: the Memory room for WALK-AUDIT-2026-07-28
Assertion #3 is the corrected one. It has four versions: it started at "three of the eleven branches", was corrected to "four of the eleven branches (corrected from three; the Kendall branch printer was reinstalled in 2025)", and was re-committed.
Do: Try to see the earlier text from the surface. Try the Companion too — "what did finding 3 say before I corrected it?"
CLEAN would look like: the trajectory is walkable — you can see v1, v2, v3, v4 and what changed.
Expected: it is not. at-version appears nowhere in the Operator Layer. The substrate retains everything (/history returns all versions correctly); the surface exposes none of it.
Resolves: W-5 — the most important item on this list
Go to: the Companion, with WALK-AUDIT-2026-07-28 open
Do: Ask, in your own words: "How many of the eleven branches have instant-issue card capability?"
Ground truth: assertion #3 is at version 4, state committed, and reads "four".
What the audit got: "Based on what you've told me, three of the eleven branches… though that note is still waiting for your okay, not saved yet." — wrong value (the superseded one) and wrong lifecycle state, stated confidently.
CLEAN looks like: "four", described as committed.
Please try two or three phrasings. This is a six-assertion engagement, so it is not the known §18.2 wholesale-recall limit — it is recall reading a superseded version and misreporting state. If it reproduces across phrasings, W-5 is solid and it bears directly on the standing "no live recall demonstration in front of a prospect" conduct rule, because that rule was written about the early-input case and this is a different failure.
Resolves: W-9 (confirm the negative)
Go to: WALK-AUDIT-2026-07-28-CONTROL — use the control, because it genuinely has a Manifestation (v2), two confirmed shapes and two renders
Do: Navigate to the Manifestation room and the Shaping room.
CLEAN would look like: the Manifestation's organized knowledge, and the two confirmed shapes with their content.
Expected: both rooms show an empty state — "No shapes waiting on you yet. Shapes appear here once there's settled memory to shape." — even though there is settled memory, a derived Manifestation, and two confirmed shapes sitting in the engagement. The rooms are hardcoded placeholders (RoomView.tsx:56-66). Confirm the copy you actually see, since misleading empty-state text on a non-empty engagement is its own finding.
Resolves: W-12, W-13
Go to: WALK-AUDIT-2026-07-28-CONTROL — Rendering room, and the Companion
There are two real HTML renders. The first is 454edb9c-5e24-4d40-bef7-8c90d7d8f32d ("four of the eleven"); the second is the post-change re-render ("5 of the credit union's 11 branches", mentions the Doral branch).
Do, in this order:
GET /renders/{id}/download, though that route works perfectly and returns a correct content-disposition filename.CLEAN looks like: the Companion finds the brief by name and gives you the file.
What the audit got: "No artifact with a title matching 'Board brief' turned up… There are two HTML documents saved to the project: 1. 1bad53b2-… 2. 454edb9c-… Do either of those IDs mean anything to you?" — two raw UUIDs and a question, with no download affordance, even though the render carries source_shape_title: "Meridian onboarding — Board brief (walk audit)".
Check specifically: can you tell the two renders apart from the surface? The dashboard labels both #1 — html_document.
Resolves: W-10
Go to: the Companion, with WALK-AUDIT-2026-07-28-CONTROL open
Do:
CLEAN looks like: step 3 grants the delegation and step 4 produces the draft.
What the audit got: step 3 was classified remember_about_me and stored as a personal-memory note — "Got it — 'Can draft board briefs for this engagement.', held.", side_effects: []. No delegation granted. Step 4 refused again, and added "'shape' and 'Manifestation' are terms I don't use."
Try a couple of phrasings before concluding. If some phrasing does grant it, capture the exact wording — the finding then becomes "the Companion suggests wording that does not work" rather than "the delegation cannot be granted", which is a materially different fix.
Resolves: W-15 Go to: the dashboard, the library, the engagement's own surfaces
Do: Try to answer, from the product alone: what happened in this engagement, in order? The control engagement has a full chain — assertions contributed and committed, one revised, a Manifestation derived twice, two shapes produced and confirmed with a completeness override, two renders.
CLEAN looks like: one place that shows that sequence.
Expected: activity-summary is an in-flight counter reading all zeros; room-summary is totals; /me/dashboard/recent lists the two renders with download_url: null and identical labels. Note whether any surface you find does better than those three.
For each task, one line is enough:
Task N — CLEAN | as-audited | differs: <what you saw>
Anything marked differs becomes an amendment to the report's break list (W-17 onward). Two kinds of difference matter most, in this order:
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — seed-to-render walk audit — Operator browser checklist — v0.1 — 2026-07-29