Version. 0.1
Date. 2026-08-04
Author. Claude.ai (drafting session). Operator: Marvin Percival.
Executed by. Claude Code on DUNIN7-M4, one session.
Target. /Users/dunin7/loomworks-engine at main 7bdbf8b, tag stele-mount-test-fix-v0_1; /Users/dunin7/loomworks at main 7a9adc9, tag clean-report-surface-v0_1. Both read-only. [EXECUTING SESSION: confirm both; report if either has moved.]
Charter. standing-notes/dunin7-standing-authorization-charter-v0_1. R-5 inspection run.
Build-list item. B-49.
Status. Read-only. Establishes ground for a change request. Produces no change and no recommendation on what the gate should check beyond what is already clean.
Why now, and why it has a window. Both repositories pass their own checks today — the engine's suite for the first time in weeks, the surface's lint at zero and its tests exiting zero. Nothing enforces any of it. The engine's only automated check verifies OpenAPI-doc freshness and does not run the tests at all; what the surface's automation runs has never been read.
A gate installed over a clean state holds. A gate installed later is a negotiation about what to grandfather — which is the position this week began from, three times over.
Grounding. inspection-briefs/loomworks-clean-report-cluster-step-0-findings-v0_1 — which established the engine's CI situation, and did not examine the surface's.
Both repositories read-only. No fixes, no branches, no commits, no dependency changes, and no workflow file is written or edited.
No pipeline is triggered. Do not push anything, do not open a pull request, do not run a workflow manually. A CI run is a side effect on a shared service and this session produces none.
Local runs are permitted — the same commands a gate would run, to establish they currently pass and how long they take.
Database. playground_dev and playground_test are never touched. If the engine's suite needs a database, use a throwaway on the walk-audit dev pattern, created for the run and dropped after — the engine's own README now documents the stand-up sequence.
A failure is a result. Do not work around one.
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.The engine's situation is partly established and the surface's is not.
3.1 Every workflow file in each repository. Read them in full. For each: what triggers it, what it runs, and what makes it fail. Name the file and the job.
3.2 What the triggers actually cover. A workflow on push to main only, in a project that merges via --no-ff from branches, catches nothing before the merge. Establish which branches and events each workflow responds to, and whether anything at all runs before code reaches main.
3.3 Anything outside the workflow files. Pre-commit hooks, a Makefile, package scripts intended as gates, a task runner, branch protection settings visible in the repository. A gate need not be CI, and something may already exist that nobody has been running.
3.4 The engine's doc-freshness job, read properly. It is the engine's only automated check. What does it actually verify, and does it fail when it should? A check nobody has watched fail is a check nobody knows works.
The change request will install gates over what already passes. This establishes what that costs before anyone commits to it.
For each command a gate would run — the engine's suite, the surface's lint, the surface's tests, and the surface's build:
4.1 Does it currently pass? Run it. Report the output.
4.2 How long does it take? Wall-clock, locally. A gate that takes twenty minutes is a different proposition from one that takes two, and nobody has measured.
4.3 What does it require? The engine's suite needs a database — establish exactly what a fresh runner would need to provide, using the README's stand-up sequence as the reference. Secrets, services, environment variables, a Postgres instance. Name each.
4.4 Is it deterministic? Run the surface's tests twice and the engine's suite twice. Report any test that passes once and fails once, and any output that differs between runs in a way that would make a gate flap. A flaky gate is worse than none — it teaches people to re-run until green.
Two hazards, both of which this project has already met in other forms.
5.1 A gate that passes vacuously. The engine's current job is the worked example: it runs, it is green, and it checks something nobody was worried about. Establish, for each proposed gate, what failure it would actually catch — and confirm by construction that it can fail. A gate whose failure mode nobody has seen is a claim, not a check.
5.2 A gate that hardcodes a moving number. Several documents in this project have carried counts that drifted. A gate asserting "3522 tests pass" fails the next time a test is added. Establish whether any candidate gate would encode a figure rather than a condition, and report it.
B-48 is the decision about ruff and mypy, and it is not this item. But a gate that runs the tests and not the type checker states something by omission, and a reader will take a green pipeline as meaning more than it does.
Establish what a truthful statement of coverage would look like — a line in the README, a comment in the workflow, a badge that names what it covers. Report the options; choose none.
This is the same rule the rooms hold: a green report should say only what was actually checked. The gate is a surface, and it is subject to the governing rule like any other.
ruff and mypy should gate. B-48.playground_dev or playground_test.One findings document, Markdown primary.
Path. inspection-briefs/loomworks-b49-step-0-findings-v0_1.md. Copy to ~/Downloads.
Structure: environment (both SHAs, both tree states, which databases were used, and an explicit statement that no pipeline was triggered) · question one first — what runs today in each repository, and whether anything runs before main · question two with timings and requirements per command · question three's hazards · question four's options · corrections preserved · unread and unrun.
Filing. Charter R-1: commit and push on clean pre-flight. Append the outcome to current-status/dunin7-status-brief.
B-49 Step 0 inspection. Read-only.
Brief: loomworks-record/inspection-briefs/loomworks-b49-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 WORKFLOW FILE IS WRITTEN OR EDITED. NO PIPELINE IS TRIGGERED — no push, no
pull request, no manual run. A CI run is a side effect on a shared service and
this session produces none.
Local runs of the same commands ARE expected — that is how the cost is
established.
playground_dev and playground_test are live databases and neither is touched. If
the engine's suite needs a database, use a throwaway, dropped after.
Section 3 is answered first: what runs today, and does anything run before code
reaches main? The engine's situation is partly established; the surface's has
never been read.
Section 4.4 wants each suite run twice. A gate that flaps is worse than no gate.
Section 6 reports options and chooses none.
File findings per section 8. Append the outcome to the status brief.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — B-49 Step 0 inspection brief — v0.1 — 2026-08-04 Both repositories pass today. Nothing makes them keep passing.