Loomworks — B-41 verification brief — the stand-up sequence — v0.1

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 ffc29af; /Users/dunin7/stele at main 689de41, tag v0.4.0. Both repositories read-only. Charter. standing-notes/dunin7-standing-authorization-charter-v0_1. Verification run under R-4. Build-list item. B-41. Grounding. scoping-notes/loomworks-b41-scoping-note-v0_2 (the two decisions and what they wait on); inspection-briefs/loomworks-b41-step-0-findings-v0_1 (the chain read, with the chain-count correction at the scoping note's §8). Status. Verification. This is not an inspection — it runs migrations. It produces no code change and no change request.

Why it exists. The scoping note takes two decisions and both rest on one unread fact: Stele's stamp asserts that the tables already present match what its own 0001_baseline would have built. Whether they do cannot be settled by reading. If they do not, D-1 collapses and the Stele half reopens with Option A back on the table — so this runs before a change request, not inside one.

1. The fences

Both repositories are read-only. No fixes, no branches, no commits, no dependency installs beyond what a clean checkout already declares. If making the sequence work requires editing a repository, stop — that is the change request, and it is not authorized here.

Everything runs against a throwaway database, on the walk-audit dev pattern: a database created for this run and dropped at the end, spare ports, inline environment only, .env untouched, live processes untouched.

playground_dev is the live production database and is not touched. Neither is playground_test. The test database is a working database whose shape has history; using it would answer a different question.

No merge, no tag, no push.

A failure is a result, not a problem to work around. The B-9 session's workarounds are what produced B-41; this session records what fails and stops on that step rather than getting past it. Working around a failure here would destroy the finding.

2. The discipline clause

State only what you have read back — and here, only what you have run. Plus the disciplines at standing-notes/loomworks-standing-note-executable-document-versions-v0_7:

1. Name the command and quote its output for every claim. A claim with no command behind it is not a result.
2. Report unrun where a step could not be attempted, and say what blocked it.
3. Do not inherit. The scoping note and findings are prior reads; where this run contradicts them, the run wins and the contradiction is recorded.
4. A count carried from another document is verified by counting, not by establishing that it matters. (The findings' chain count was wrong and reached a second document before anyone counted.)
5. A check that cannot fail is not a check. A baseline taken with the change in place, a stash that leaves untracked files, a grep narrower than its claim.

3. Question one — does the stamp assert something true?

The decision D-1 rests on.

3.1 Build the engine's schema as far as it goes. On a fresh throwaway database, run the engine's chain from empty. Record where it stops and the exact error. The findings predict 0034; confirm or contradict.

3.2 Capture what the engine built. For principals, webauthn_credentials and recovery_codes: column names, types, nullability, defaults, primary keys, indexes and constraints. Read from the live throwaway, not from the migration source.

3.3 Build Stele's schema alone. On a second, separate throwaway database with nothing else in it, run Stele's chain from empty per its README. Capture the same three tables the same way.

3.4 Diff them. Column by column, constraint by constraint. Report every difference, not only the ones that would break a stamp.

The findings predict exactly one: principals.totp_last_step, present in Stele's model and absent from the engine's build. Confirm or contradict. A difference in a type, a default, an index name or a constraint is as consequential as a missing column for a procedure whose whole claim is that the shapes match.

3.5 Run the stamp. On the first throwaway — the engine-built one — run Stele's alembic stamp 0001_baseline followed by alembic upgrade head, using Stele's own config pointed at that database. Record whether it succeeds, and whether totp_last_step exists afterward.

The verdict this question returns: the stamp is safe, the stamp is unsafe and why, or it could not be attempted and what blocked it.

4. Question two — does the whole sequence produce a working database?

The claim B-41 exists to make true. The scoping note's §4 says asserting it without running it once would be the defect this project keeps correcting.

The sequence, on a third throwaway from empty:

1. Engine chain up to the last revision before the break — the findings say 0033.
2. The bootstrap. It currently has one invocation site: the application's startup handler. Getting it to run without a web server is the point of D-2 and does not exist yet. For this run, invoke the ensure_* functions by whatever minimal means works — a Python one-liner against the same database is fine. Record exactly what you did, because that is the shape D-2 has to provide properly.
3. Engine chain to head.
4. Stele's stamp and upgrade, per question one.

Then establish whether the result is actually working, and say by what test:

• Does the engine's own test-suite precondition pass — the conftest fixture that checks for its expected tables?
• Can the application boot against it?
• Does the alembic head match the repository's declared head?

Report each step's command, its output, and where it stopped if it did.

Three environment facts to record while you are there, because they are part of the sequence whether or not anyone has written them down:

• Whether LOOMWORKS_SECRET_KEY was needed, and at which revisions. (The findings name 0062, 0063, 0064.)
• What database URL variables each chain reads, and whether they differ.
• Anything else the sequence required that no document mentions.

5. Question three — what the sequence actually costs

For the change request to specify a stand-up procedure, someone has to know what it is.

Write down the exact sequence that worked, if one did — every command, in order, with its environment. This is the deliverable most likely to outlive the rest of this brief, because the engine's README currently says nothing about the database at all.

And name what a person or agent would get wrong following it without help: an ordering that looks optional and is not, a command that succeeds while doing nothing, an error that reads as fatal and is recoverable.

6. What this brief does not do

• No repository change of any kind. If the sequence needs one, that is the change request.
• Does not build D-2's bootstrap entry point. It establishes what that entry point has to do.
• Does not touch playground_dev or playground_test.
• Does not compare a throwaway to playground_dev. Still unread, still needs the production database.
• Does not decide anything. If question one contradicts D-1, that is a finding and the scoping note reopens — it is not this session's call to pick a different option.

7. Reporting

One findings document, Markdown primary.

Path. inspection-briefs/loomworks-b41-verification-findings-v0_1.md. Copy to ~/Downloads.

Structure: environment (both SHAs, both tree states, an explicit statement that playground_dev and playground_test were never connected to, and confirmation that every throwaway was dropped) · question one answered first and plainly — is the stamp safe · the full table diff · question two, step by step with commands and output · question three's written sequence · corrections preserved, including anywhere this run contradicts the findings or the scoping note · unrun, with what blocked each.

Filing. Charter R-1: commit and push on clean pre-flight. Append the outcome to current-status/dunin7-status-brief.

8. Claude Code kickoff

B-41 verification. Runs migrations against throwaway databases.

Brief: loomworks-record/inspection-briefs/loomworks-b41-verification-brief-v0_1.md
Confirm it exists, and that it is the highest version present — numeric sort.

Grounding, read before the brief:
  scoping-notes/loomworks-b41-scoping-note-v0_2.md
  inspection-briefs/loomworks-b41-step-0-findings-v0_1.md

Read the brief in full. Charter dunin7-standing-authorization-charter-v0_1 governs.

BOTH REPOSITORIES ARE READ-ONLY. This session runs migrations; it does not
change code. If making the sequence work requires editing a repository, STOP —
that is the change request and it is not authorized here.

Throwaway databases only, on the walk-audit dev pattern: created for this run,
dropped at the end, spare ports, inline environment, .env untouched.
playground_dev and playground_test are both live databases and neither is
touched. The brief's section 3 needs more than one throwaway; create them
separately.

A FAILURE IS A RESULT. Record what fails and stop on that step. Working around
a failure destroys the finding — working around failures is what produced this
item in the first place.

Section 3 decides whether the scoping note's first decision survives. Answer it
first and plainly.

File findings per section 7. Append the outcome to the status brief.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — B-41 verification brief — v0.1 — 2026-08-03 Whether the documented procedure works, established by doing it rather than by reading that it should.