Version. 0.3
Date. 2026-08-03
Supersedes. v0.2 and v0.1, both drafted and never filed — each halted at pre-flight. The record holds neither.
Changes from v0.2. One self-reference. The §9 kickoff still named this brief at v0_1 — a path that does not exist and, per its own filing instruction, never will. A session executing the kickoff would have failed at its first line. The cause: the version bump replaced the prose form v0.1 and the kickoff carries the filename form v0_1. Two spellings of one version string, and only one was swept. Caught by the input-document sweep this brief's own correction had just added.
Changes from v0.1, carried and re-checked. The grounding line only; no question, fence or reporting instruction changed. It cited two documents: one without a path, which is in the code repository rather than the record, and one that does not exist — Checkpoint A was reported in session and never filed as a document. A session sent to read it would have found nothing.
Author. Claude.ai (drafting session). Operator: Marvin Percival.
Executed by. Claude Code on DUNIN7-M4, one session.
Target. /Users/dunin7/loomworks-engine at main ffc29af; /Users/dunin7/stele at main 689de41, tag v0.4.0. Both read-only.
Charter. standing-notes/dunin7-standing-authorization-charter-v0_1. R-5 inspection run.
Build-list item. B-41.
Status. Read-only. Establishes ground for a scoping decision. Produces no code change, no change request, and no fix.
What B-41 is. Running the engine's own migration command against an empty database does not produce a working database. It was found while building B-9's live verification, which needed a throwaway database and could not get one the documented way. It was worked around in the throwaway only and deliberately not fixed.
Why it is not a small item. The migration chain is what you rely on to stand the system up somewhere new — a second environment, a recovery, a customer's own deployment, a contributor's laptop. If it cannot produce a working database, then the only working database is the one that has been running since the beginning, and its shape is known by inspection rather than by anything written down. Every schema claim this project makes rests on that chain being the source of truth.
Grounding. /Users/dunin7/loomworks/docs/phase-crs/cr-2026-164-implementation-notes-v0_1.md, and cr-2026-164-step-0-determinations-v0_1.md beside it. Both are in the code repository, not the record — the convention CR-2026-159 set, where implementation notes sit next to the code they describe. They record the failure as encountered during a live verification, not as investigated.
> Two corrections to v0.1's grounding line, and one finding behind them. v0.1 cited the notes without a path, implying they were in the record; they are not. And it cited "its Checkpoint A report" as a second document — no such document exists. Checkpoint A was reported in session and never filed. (The brief's own §2.5 rule: confirm a target exists before treating its silence as a pass. Caught at filing.)
>
> The finding: a session reading only the record cannot find these notes. The format convention places documents in loomworks-record; implementation notes have been going to the code repositories. Both are defensible and the record does not say which is intended. Recorded for the build list, not settled here. Two facts are established at source by the drafting session and are to be re-verified, not inherited:
loomworks-engine/alembic.ini leaves version_locations commented out, so only %(here)s/migrations/versions is scanned.stele ships its own chain at src/stele/migrations/versions.Read-only in both repositories. No fixes, no branches, no commits, no dependency installs.
No migration is run against any database, including a throwaway. This is an inspection of the chain as written, not an attempt to make it work. If a question cannot be settled by reading, report it unread — a session that starts fixing this by trial has stopped inspecting.
playground_dev is the live production database and is not touched. Neither is any other database.
No dev server, no suite run, no perimeter call.
State only what you have read back, plus the disciplines at standing-notes/loomworks-standing-note-executable-document-versions-v0_7:
unread rather than closing a gap with a plausible reading.The workaround found two failures by hitting them in sequence. A chain can hide further breaks behind an earlier one.
Read the chain as written, from the base revision to head. Establish:
3.1 The first break. The revision the workaround identified as needing a bootstrapped administrative record. What does it actually require, and why? Read the migration itself, not the error. Is it inserting data, or is it altering a table in a way that assumes rows exist?
3.2 Every other revision that assumes existing data. Sweep the whole chain, not just up to the first failure. A migration that inserts, updates, backfills, or adds a NOT NULL column without a default is in this class. Report every one, with its revision and what it assumes.
3.3 The Stele dependency. Confirm alembic.ini's version_locations is unset and that only the engine's own versions directory is scanned. Then establish which tables and columns the engine's ORM expects that Stele's chain owns — the workaround named principals.totp_last_step; establish whether it is alone.
3.4 Whether the two chains have a defined relationship at all. Do they share a version table? Do they have conflicting base revisions? Has anything ever been written down about how they are meant to compose? If not, say so — an undocumented relationship between two chains is a finding in itself.
This is the question that decides how serious B-41 is.
If playground_dev was built by running the chain, then the chain worked once and has since drifted — a repairable regression. If it was built by some other route — a dump, a hand-applied script, an ORM create_all, an accumulation of manual changes — then the chain has never been the source of truth, and B-41 is not a regression but a gap that has always been there.
Establish what can be established from the repositories alone: any bootstrap script, seed command, fixture loader, create_all call, README instruction, or deployment script that stands up a database by a route other than the chain. Name each and say what it does.
What cannot be established without the database — whether playground_dev's current schema matches what the chain would produce — is named as unread, not estimated. That comparison needs a connection and this session does not have one.
Report the options the codebase admits. Do not recommend one.
The two chains have to compose somehow, and the shapes available are materially different:
version_locations names Stele's directory.For each: what it would touch, and what it would foreclose. Note especially whether any option is foreclosed by Stele being a separate distributable package with its own release cycle — that is the constraint most likely to make the obvious answer wrong.
Establish what the repositories tell someone to run to stand up a database — READMEs, AGENTS.md, contributing guides, deployment notes, anything.
Then say whether that instruction works. A documented command that does not produce a working result is a claim the project makes and does not meet, and it is the same class as everything B-25 and B-29 corrected — a statement made without a read behind it, in prose rather than in a record.
One findings document, Markdown primary.
Path. inspection-briefs/loomworks-b41-step-0-findings-v0_1.md. Copy to ~/Downloads.
Structure: environment (both SHAs, both tree states, and an explicit statement that no database was connected and no migration was run) · question two answered first and plainly — whether the chain has ever been the source of truth, or cannot currently be · question one with every break enumerated · question three's options with their trade-offs · question four · corrections preserved · unread.
Filing. Charter R-1: commit and push on clean pre-flight. Append the outcome to current-status/dunin7-status-brief.
B-41 Step 0 inspection. Read-only.
Brief: loomworks-record/inspection-briefs/loomworks-b41-step-0-inspection-brief-v0_3.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, both at main — the brief's header names them.
NO MIGRATION IS RUN, against any database including a throwaway. This is an
inspection of the chain as written. If a question cannot be settled by reading,
report it unread. A session that starts fixing this by trial has stopped
inspecting.
playground_dev is the live production database and is not touched. Neither is
any other database.
No fixes, no branches, no commits, no dependency installs, no dev server, no
suite run, no perimeter call.
Section 4 decides how serious this item is: has the chain ever been the source
of truth for the schema, or has the working database always come from somewhere
else? Answer it first and plainly.
Section 5 reports options and recommends none.
File findings per section 8. Append the outcome to the status brief.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — B-41 Step 0 inspection brief — v0.3 — 2026-08-03 Whether the system can be built from its own sources, or only from the one that is already running.