Loomworks — seed-to-render walk audit — CC brief — v0.1

Version. 0.1 Date. 2026-07-28 Status. Walk-audit brief. Hands to Claude Code on DUNIN7-M4. Markdown primary (technical consumer). Author. Claude.ai. Operator: Marvin Percival. Purpose. The Operator's direction: complete the Companion and the pipeline so an engagement can be followed from seed through render completion as one unbroken thread. Before anything is scoped, the thread must be walked — this brief drives one synthetic engagement through the entire pipeline and reports every point where the thread breaks, needs a workaround, or forces the Operator out of the Companion into raw mechanics. The break list, not assumption, becomes the completion backlog. Grounding. Current-status manifest v0.74 (create stage complete, three doors); the render-download, content-kinds, and incremental-rerender CRs; the Companion build queue as filed. CC reads the highest manifest actually present before starting — do not assume v0.74 is still highest.

1. What this is and is not

This is an audit of the walk, not a test run of features. The suite may pass on every feature individually and still fail the walk — the walk fails wherever the Operator must stop being an Operator and become a mechanic. CC observes and classifies; CC does not fix anything, does not file issues in code, does not draft CRs. Every finding is evidence-cited (endpoint or surface, file path + line where relevant, and the exact response or behavior observed).

Two lanes, walked in parallel at each stage:

• Lane A — substrate walk. The API level: does the machinery exist and complete end to end over HTTP against the real dev stack (engine :8000, real Anthropic where the step needs it)?
• Lane B — Operator walk. The Companion/Operator Layer level: can this step be done from within the Companion conversation or the Operator Layer surface without dropping to curl, SQL, or file juggling? Lane B is assessed by HTTP-driving the Operator Layer (:3001 / localhost preferred) plus code inspection of the surfaces; anything whose real usability is unverifiable headlessly is marked OPERATOR-VERIFY and added to the browser checklist (Section 5), not guessed at.

2. Classification vocabulary

Every step in both lanes gets exactly one:

• CLEAN — works, from where the Operator actually is, no workaround.
• LEAVES-COMPANION — works, but only by leaving the Companion/Operator surface for a raw mechanism (a direct API call, a manual file move, a database read). The step exists; the thread through the Companion does not.
• MANUAL-WORKAROUND — completes only with an improvised sequence that no surface offers (chained calls, hand-edited payloads, out-of-band state).
• BROKEN — cannot be completed at all against the current tree, or completes with wrong/lost data.
• OPERATOR-VERIFY — Lane B only: substrate works, surface exists, headless assessment cannot judge the experience; queued for the Operator's browser pass.

Plus, wherever it applies: CEILING — the step requires the Operator's physical act (the WebAuthn passkey tap). Not a defect; CC pauses, requests the tap in its running log, and the Operator performs it live if driving alongside, or CC uses the established dev-auth affordance where one exists and marks the step CEILING-BYPASSED-DEV. Never mark a CEILING as BROKEN.

3. The walk

Synthetic engagement only. Name it unmistakably (e.g. WALK-AUDIT-2026-07-28). Never touch E0060, E0007, E0030, or the shared E0006 fixture. The engagement is left standing at the end for the Operator's browser pass; destruction is a separate later instruction.

Content. CC authors a small, realistic specification document before starting — a two-page consulting-engagement brief (any plausible domain) with enough substance to exercise extraction: what the work is, who reads it, voice, constraints, success conditions, plus a handful of body sections. Realistic content matters because the walk's later stages (shaping, rendering) are meaningless against lorem ipsum.

Stage 0 — Creation (door 3)

Drive the shipped door-3 path: draft-candidate allocation → upload the authored spec → extract (the five commitments) → adjust one extracted value → amend → instantiate to the WebAuthn gate (CEILING). Also probe, without fully walking them: do doors 1 and 2 still open (routes respond, surfaces render)? Classify each sub-step in both lanes.

Stage 1 — Memory

1. Text contribution through the Companion converse path (Lane B primary — this is the Companion's home ground): contribute several assertions conversationally; verify held state, attribution, display numbers.
2. Structured contribution via the contribution surface.
3. File contribution: upload a small file of an accepted type; verify extraction produced assertions (not just a stored file); note which of the walk's own document types would have been refused (tie to the known ingestion gaps — cite, don't re-derive).
4. Lifecycle: commit several held assertions (CEILING where the gate requires it); supersede one with a correction — verify the superseded assertion remains and the trajectory is walkable from the surface, not only in the database; redirect one; retract one.
5. Ask the Companion one question about a committed contribution (recall exercised small — the known §18.2 limit is cited context, not a finding to rediscover; what is being audited is whether the ask-path works at this scale from the surface).

Stage 2 — Manifestation

Produce/refresh the Manifestation; view it as the Operator would; verify it reflects the committed state at this moment including the correction from 1.4 (the superseded-and-corrected pair handled per the corrections-preserved commitment). Can the Operator get here and read it without leaving the surface?

Stage 3 — Shaping

Declare or select a shape-type for one named reader (whatever the shipped shaping surface offers — record what it offers); produce a shape from the current Manifestation; note grammar/completeness behavior if it fires. The audit question: is shaping something the Operator does from the surface, or something that exists in the engine and is reached by mechanics?

Stage 4 — Rendering

Produce at least one Mode A render from the shape; exercise the content-kind path that applies; download the artifact through the render-download path; open/verify the downloaded file is the render (not a stub). If incremental re-render is reachable: change one contribution, re-render, verify the change surfaced. Classify the full loop in both lanes.

Stage 5 — The thread as a whole

1. Observability: does the activity/observability surface show the walk as a coherent history?
2. Companion continuity: across stages 1–4, tally how many times the walk left the Companion — the single number that measures the Operator's actual experience.
3. Provenance spot-check: pick one rendered claim and walk it backward — render → shape → Manifestation → assertion → contributor. Report whether that walk is possible from surfaces, possible only via API/database, or not reconstructable.

4. Report

loomworks-walk-audit-report-v0_1.md to /Users/dunin7/Downloads/. Structure:

1. Engine + OL SHAs at top; manifest version read; dev-stack state.
2. The walk table — every step, both lanes, classification, one-line evidence pointer.
3. The break list — every non-CLEAN finding as its own numbered entry (W-1, W-2, …) with: stage, lane, classification, exact evidence (request/response or path+lines), and a one-sentence statement of what "fixed" would mean — stated as the observed gap, not as a proposed design.
4. The continuity number (Stage 5.2) and the provenance-walk verdict (5.3).
5. Anything observed that the brief did not anticipate — surfaced, not resolved.

No repo commits; the dev database gains the synthetic engagement and its data, left standing; nothing else is written anywhere except the report and the checklist below.

5. Operator browser checklist

Alongside the report: loomworks-walk-audit-operator-checklist-v0_1.md — every OPERATOR-VERIFY item as a short numbered browser task against the standing synthetic engagement (URL, what to do, what CLEAN would look like), so the Operator's pass takes minutes and its results merge into the break list as amendments rather than a second audit.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — seed-to-render walk audit — CC brief — v0.1 — 2026-07-28