Version. 0.1
Date. 2026-08-03
Author. Claude.ai (drafting session). Operator: Marvin Percival.
Executed by. Claude Code on DUNIN7-M4, one session.
Target. /Users/dunin7/loomworks-engine at main 3b10ff1, tag cr-2026-157-non-member-contribution-v0_1; /Users/dunin7/loomworks at main cb8b940, tag provenance-walk-v0_1. Both read-only. [EXECUTING SESSION: confirm both, and report if either has moved.]
Charter. standing-notes/dunin7-standing-authorization-charter-v0_1. R-5 inspection run.
Build-list items. B-33, B-34, B-42.
Status. Read-only. Establishes ground for a change request. Produces no fix and no change request.
What the cluster is. Three items, one problem: neither repository can report a clean run, so every change request has to record a baseline failure set and compare against it. That works, and it costs something real — a standing exception held in mind is how a second failure hides, and this project has already had one figure go stale inside such an exception.
Why this needs an inspection at all. The drafting session initially judged all three diagnosed and ready to build. They are not. For each, what is known is the symptom; the cause is unread, and for two of them the remedy is a decision rather than a repair.
Both repositories read-only. No fixes, no branches, no commits, no npm install, no dependency changes.
Test and lint runs are permitted and expected — they are how these three are observed. No dev server. No perimeter call.
Database. playground_dev and playground_test are both live and neither is touched. If running the engine's suite requires a database, use a throwaway on the walk-audit dev pattern, created for the run and dropped after. [EXECUTING SESSION: the engine's suite has a database precondition. Establish what it needs before running anything, and report it — the stand-up sequence at the engine's README is now the documented route.]
A failure is a result. Do not work around one to see the next.
State only what you have read or run, plus the disciplines at standing-notes/loomworks-standing-note-executable-document-versions-v0_7:
unread or unrun rather than closing a gap with a plausible reading.
What is known: test_stele_router_mount.py::test_stele_router_mounts_and_begin_resolves_end_to_end fails with a 401. It has failed across every suite run this week, is unrelated to anything built, and is the engine's entire baseline failure set.
What is unknown: everything else.
3.1 The cause. Read the test and what it exercises. What returns the 401, and why? Is it asserting against a route whose authentication changed, a fixture that no longer authenticates, a Stele-side expectation the engine's mount does not satisfy, or something else?
3.2 When it started. git log the test and the code it exercises. Was it ever passing? A test that has failed since it was written is a different item from one that regressed.
3.3 What it is for. The test's name says it verifies Stele's router mounts and a begin-flow resolves end to end. Is that behaviour actually working in the product, with only the test broken — or is the test correctly reporting something broken? This is the question that decides whether B-33 is a test fix or a defect report.
3.4 Whether anything else covers it. If the behaviour is covered elsewhere and passing, that is evidence for the first reading. If nothing else covers it, deleting or skipping the test would remove the only check on a real path.
Report the cause, the history, and which of the two readings the evidence supports. Do not fix it.
What is known: the surface's suite passes every test and exits non-zero, on unhandled promise rejections from fetchPlatformLevel. They arise in three test files that render shared layout components, and the count grows with any new screen whose test renders those components without mocking the call.
4.1 The mechanism, precisely. Read fetchPlatformLevel and its callers. What is rejecting, and why does the rejection go unhandled? Is the call unawaited, awaited without a catch, fired in an effect with no error path, or something else?
4.2 Whether it also happens in the product. This is the load-bearing question. If the same call rejects unhandled in a browser and not only under test, B-34 is a product defect wearing a test-noise costume and its remedy is entirely different.
Establish it from source — is the rejection path reachable outside a test environment, and is there a handler that only test conditions bypass?
4.3 The candidate remedies, with what each touches. Report them; do not choose.
fetchPlatformLevel itself. Narrower, and may be wrong if callers need to distinguish failure from absence.
4.4 What the room state contract implies. Three of the four rooms carry a contract where a failed read says the read failed and never that the record is empty. If fetchPlatformLevel swallows a rejection to silence the test, does the surface then assert something it has not read back? That is the governing rule, and it constrains which remedy is acceptable regardless of which is cheapest.
What is known: one code-quality rule — set-state-synchronously-in-an-effect — is broken across many files and rising, including ManifestationRoom, the component every later room was modelled on. Lint also carries warnings alongside these errors.
5.1 Count it, and count everything else. How many files break this rule; how many errors and warnings lint reports in total; how many distinct rules are broken. (Every prior figure here was carried between documents rather than counted. Count.)
5.2 Why the pattern exists. Read the violations in ManifestationRoom and usePagedList. Is the rule being broken carelessly, or is it being broken because the pattern the codebase needs is one this rule forbids? Those have opposite remedies.
5.3 What the rule is actually protecting against. Read the rule's own documentation. Does the hazard it names apply to these call sites? A rule broken by the codebase's own model component is either a real hazard nobody has hit yet, or a rule aimed at a pattern this codebase does not have.
5.4 The three answers, and what each costs. Report them; do not choose.
5.5 The other warnings. Are they one rule or many? Is "make lint pass" one job or several? The cluster's premise is that a clean report becomes readable; that premise fails if the errors go and the warnings stay.
The cluster exists so that a clean report can be read as clean. Establish what that would take.
For each repository: what commands would need to exit zero, and what currently stops them. Report whether all three items together achieve it, or whether something else also stands in the way that nobody has named — a fourth item this cluster does not include.
[EXECUTING SESSION: this is the question most likely to find something. Three items were identified by noticing them during other work, not by looking for them.]
playground_dev or playground_test.One findings document, Markdown primary.
Path. inspection-briefs/loomworks-clean-report-cluster-step-0-findings-v0_1.md. Copy to ~/Downloads.
Structure: environment (both SHAs, both tree states, an explicit statement about which databases were used and that both live ones were untouched) · question four answered first — what clean would take, and whether these three achieve it · questions one to three in order, each with its options and none chosen · corrections preserved · unread and unrun, each with what blocked it.
Filing. Charter R-1: commit and push on clean pre-flight. Append the outcome to current-status/dunin7-status-brief.
Clean-report cluster Step 0 inspection. Read-only.
Brief: loomworks-record/inspection-briefs/loomworks-clean-report-cluster-step-0-inspection-brief-v0_1.md
Confirm it exists, and that it is the highest version present — numeric sort.
Read the brief in full. Charter dunin7-standing-authorization-charter-v0_1 governs.
Two repositories, both READ-ONLY — the brief's header names them and their SHAs.
Confirm both; report if either has moved.
No fixes, no branches, no commits, no npm install, no dependency changes, no dev
server, no perimeter call. Test and lint runs ARE expected — they are how these
are observed.
playground_dev and playground_test are live databases and neither is touched. If
the engine's suite needs a database, use a throwaway, created for the run and
dropped after.
Answer Section 6 FIRST — what would it take for a clean report to be readable
as clean, and do the items this cluster names achieve it? They were found by
noticing them during other work, not by looking for them.
Sections 4 and 5 report options and choose none. Section 3 establishes whether
its item is a test fix or a defect report; that is a finding, not a decision.
File findings per section 8. Append the outcome to the status brief.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — clean-report cluster Step 0 inspection brief — v0.1 — 2026-08-03 Three symptoms, three unread causes, and a premise worth testing before anything is built on it.