DUNIN7 · Loomworks · walk audit
The walk-audit report of 2026-07-28/29 was produced headlessly and by source inspection. Several findings were asserted from reading code rather than watching the product behave, and the checklist marked those OPERATOR-VERIFY. This pass ran them in a browser.
One struck outright, one substantially narrowed. Both were negatives asserted from source, and in both cases the product does better than the source read suggested. That is the value the pass was meant to produce, and it produced it.
Three findings are materially worse than recorded, and one is the most serious defect the project has surfaced this month: the record is being written with provenance that is not true.
And a class emerged that no single finding names. It is set out in Section 4 and should govern how the completion arc is scoped.
| Original | Disposition |
|---|---|
| W-5 | REVISED — worse in kind. Not a stale value: the answer is unstable. See §3.2. |
| W-4 | CONFIRMED and worse. The verb is understood; it searches the wrong scope, then denies the record exists. See §3.3. |
| W-9 | CONFIRMED, with exact copy. Manifestation: "Nothing organized into a picture yet. Committed memory is the raw material here." Shaping: "No shapes waiting on you yet. Shapes appear here once there's settled memory to shape." Both on an engagement holding a derived Manifestation and two confirmed shapes. |
| W-10 | STRUCK as written. Asked to draft, the Companion accepted with no refusal and no delegation demand, working correctly from the record — the eleven-day problem, the Board Technology Committee audience, the $400,000 cap, the 1.5 FTE limit, the September 15 deadline — then named what it lacked and offered a choice. Whether the audit's refusal was §3.2's instability or a since-changed condition is unresolved; the finding cannot stand as written. |
| W-12 / W-13 | PARTIALLY STRUCK. Renders are clearly distinguishable — "Board brief (walk audit)" and "(re-render)", each naming its producing specialist; the audit reported both as #1 — html_document. The download half stands: opening produces a new tab, not a file, and no download control exists. |
| Row 1.1 | STRUCK — the held tray populated immediately, no refresh required. |
| Row 1.1 | CONFIRMED — three facts in one message became one held item. Granularity visible before commit; nothing offers to split it. |
| W-8 | NOT TESTED this pass. Stands as recorded. |
Two independent engine sites write the permanent record with a value that is plausible and wrong. Neither fails, neither warns, and neither surface can detect it.
W-17The seed amend attributes to a phantom contributor. engagements.py:347 constructs ActorRef(kind="contributor", id=uuid.uuid4()) on every call. The route authorises correctly using assert_engagement_creator, then discards the result and stamps a freshly generated UUID as the author. The Operator's edit to the Kestrel foundation is recorded as the work of a contributor who has never existed — confirmed live as Seed v2 attributed to ff079835…, which resolves to no principal.
W-18Create-conversation turns are written to the wrong engagement. converse.py:690 resolves engagement_id = body.project_id or _current_engagement_id. The frontend correctly sends project_id: null, honouring the documented project-less contract, but Python's None or X cannot distinguish an explicit null from an omitted field — so it substitutes whichever engagement the Operator last viewed. Two create-stage greetings were written into the CONTROL engagement's permanent record. Not displayed there in error; written there.
These join a third, already known. compositions.py:73 relabels a Companion-triggered composition as contributor — filed by CR-2026-120, carried by CR-2026-127, never chased, currently build-list item B-25.
Three sites where a write that cannot resolve its true value substitutes a plausible one rather than failing. On a system whose product is a record you can trust to say who did what and where, this is the most damaging failure available. Scope it as one change request covering all three, not three small fixes — and the two sweeps that size it have not yet been run.
W-19The door-3 verification claim is unsupported. Manifest Entry 118 records door 3 as live-verified on 2026-06-28 with an adjusted value surviving to commit ("ADJUSTED persisted: True"). No completion record, handoff, or CR files a browser transcript; door 1's entry by contrast explicitly names a screenshot, and the phrasing reads as scripted API output. A check of that shape could not have detected W-17 — it would compare returned content and never inspect provenance.wasAttributedTo. Entry 118 needs a supersession marker, and manifest v0.76 carried the claim forward unexamined.
The same question, asked three times in one conversation against unchanged data:
This is worse than the audit's finding, not milder. A consistently wrong answer is a defect you can locate. An answer that is usually right and occasionally disavows itself is unusable, because the correct output and the denial are indistinguishable from outside. The second response also invited the Operator to re-supply a fact the system already held — the concrete harm is a duplicate record, or lost trust in a record that was right.
One caveat, preserved. Probe 2 followed a malformed input (two questions with stray quote marks in one line). That may be contributory. It does not excuse the behaviour — no input should produce a false confession — and probe 3 proves the thread was not permanently poisoned.
Manifest v0.76 §5 names the ask_about_past_input carve-out from CR-2026-129 as the strongest lead for the recall defect. That path answered correctly, twice, citing its source. The defect is elsewhere. The residue stands as a real gap — that path genuinely was never brought under the truthful-by-construction discipline — but it is not the diagnosis.
retract 3 → "I don't see a held item 3 here, so I haven't discarded anything."withdraw finding 3 → "I don't have a record of a 'finding 3' in this project that I can confirm was saved. Can you tell me what finding 3 covers?"The second is false. It is saved, settled, displayed — and the Companion cited it correctly by that exact number two turns later.
Reading a settled record by number works. Acting on one does not. "No retract exists" understates it: the vocabulary is understood, the scope resolution is wrong, and the failure is reported as your record does not exist — which, believed, produces a duplicate or a lost fact.
One thing done right: it refused rather than acting. Nothing was discarded, revised, or redirected. The human-authority gate from CR-2026-128 held throughout.
Across the pass, surfaces repeatedly stated things they had not verified. In order of appearance:
/settings/security renders for under a second, then redirects to sign-in with no message. The 401 handler is deliberately bypassed so the component can handle the failure itself; it handles it by navigating away silently. Not dev-only — in production this fires when a 24-hour session ages out.When the system cannot resolve something, it asserts a plausible answer rather than saying it does not know. W-17 and W-18 are the same failure with teeth: there, the plausible answer is written into the permanent record instead of merely displayed.
This is the other face of the surface-silence class filed in manifest v0.76 §5. Silence and confident wrongness are one subject: the surface does not read back what it claims. The completion plan should carry that as a rule — a surface states only what it has read back — rather than a list of individual message fixes.
Commit {entire work description} with your passkey to make it official. yields a stray capital and a lowercase clause after a full stop. This is the last thing read before the most consequential act in the product.remember_about_me. The propose-and-confirm gate held; accepting would have replaced a correct settled record with unrelated text. What matching was actually built is recorded nowhere.show held re-listed the item with no mention of the outstanding proposal; answering no produced no acknowledgement that it was dropped and no confirmation that #3 was untouched.```html fence and closes with ```. Nothing strips it before the client-facing document.walk-audit@example.invalid. Investigated and cleared: the ceremony reads host_account.email with an unconditional fallback to display name; the value is a provisioning placeholder, the column is NULL for all 41 real principals in playground_dev, and nothing resolves identity by it. The seed's email is not identity commitment holds. Recorded because a fixture that reads as a user's own choice is exactly how a false conclusion enters a record.useRef guard is correct within one mount but resets on remount. Compounds W-18: each duplicate wrote to the wrong engagement.attestation_recorded: true remains unproven end-to-end from a browser.ActorRef built from a generated UUID, and every or-coalesced field that may legitimately be null on a write path. These determine whether the change request covers three sites or twenty.ask_about_past_input carve-out. It is the instability in §3.2 and the addressing failure in §3.3 — reading works, acting does not, and answering is not deterministic.