Version. 0.18
Date. 2026-08-03
Charter. standing-notes/dunin7-standing-authorization-charter-v0_1.
Author. Claude Code (execution session). Operator: Marvin Percival.
Supersedes. v0.17 at record 7eccd8e. All earlier versions stand as siblings; v0.3 remains deliberately absent.
Changes from v0.17. B-41 Step 0 inspection closed. Read-only, both target repositories untouched, no database connected, no migration run. Findings filed.
B-41 Step 0 inspection brief, filed at inspection-briefs/loomworks-b41-step-0-inspection-brief-v0_3.md, record b771159. Two prior drafts (v0.1, v0.2) halted at pre-flight on grounding-line misses and were never filed — the record holds neither; only v0.3 exists.
B-41 Step 0 findings, filed at inspection-briefs/loomworks-b41-step-0-findings-v0_1.md, copy in ~/Downloads. loomworks-engine main ffc29af and stele main 689de41 (tag v0.4.0), both read-only throughout, both clean, neither touched. No database connected — playground_dev or any other. No migration run.
The migration chain has never been the sole source of truth. The engine's own app-boot path (_lifespan in app.py, wired to the real uvicorn entrypoint) runs four idempotent bootstrap calls at every startup that insert the administrative engagement, the E2E test engagement, and two credit engagements — rows migration 0034 reads and assumes present, but which no migration anywhere in the 103-file chain ever creates. B-41 is not a regression in a chain that once worked end-to-end; it is a gap that was structurally invisible for as long as every real database was born by booting the app rather than by running migrations to completion in isolation.
Full chain swept, not just the first break. Four downstream revisions (0035, 0037, 0043, 0058) are chained consequences of the same 0034 gap, not independent breaks. Three revisions (0062–0064) depend on LOOMWORKS_SECRET_KEY being resolvable — a different, recoverable failure shape. No unguarded NOT NULL-without-backfill revision was found anywhere in the chain.
The Stele gap re-confirmed and narrowed to one column. alembic.ini's version_locations is commented out (re-verified at source, not inherited). principals.totp_last_step is the sole column the engine's own chain builds a table for that disagrees with Stele's ORM model — webauthn_credentials and recovery_codes show no further discrepancy this session found. The two chains share no version table by design (stele_alembic_version vs. the default alembic_version) and reference no common base revision.
A documentation gap the inspection surfaced beyond the brief's own framing. Stele's own README.md already names the exact composition procedure this project needs (alembic stamp 0001_baseline then alembic upgrade head, for a host that already owns principals) — but an exhaustive grep found zero references to it, or to stele_alembic_version, anywhere in loomworks-engine or loomworks. The fix has been written down since Stele shipped it; nothing on the engine side appears to have found it.
Documentation claims checked against the repositories. loomworks-engine/README.md's setup section is uv sync --all-extras only — zero mentions of alembic, migration, database, or Stele anywhere in the file. The only written instruction to run the chain at all lives in a test-fixture error message, not in any document a contributor or agent would read before starting.
Four options reported, none recommended, per the brief's own fence — the Operator's scoping decision, not this session's.
Five items named unread, not estimated — chiefly whether playground_dev's live schema matches what the chain would produce today, and whether the row it holds actually came from an app boot as opposed to some other undocumented route. Both require a database connection this session did not open.
R-1 for two filings, each on a clean pre-flight, each verified at origin: the brief (b771159) and this status brief.
R-5 inspection run held to its fences throughout. No fix, no branch, no commit, no dependency install in either target repository. No migration run against any database, including a throwaway. playground_dev and every other database were never connected to. No dev server, no suite run, no perimeter call.
Discipline clause held. Every claim in the findings names its file and line, or a revision id. Both facts the brief attributed to the drafting session were independently re-derived this session rather than inherited. Five items that could not be settled by reading were named unread rather than estimated.
Two pre-flight halts preceded this filing, both caught by sweeps the drafting process itself added in response to the prior halt — v0.1 on a grounding line citing a document without a path and a second document that was never filed; v0.2 on the kickoff's self-reference still naming the superseded v0_1 filename after the version bump. Both are preserved in v0.3's own changelog rather than smoothed over.
DUNIN7 — Done In Seven LLC — Miami, Florida DUNIN7 — status brief — v0.18 — 2026-08-03 The chain reads as a chain a database that has already been touched once, not as a chain that builds one from nothing.