Version. v0.1
Date. 2026-08-03
Author. Claude.ai (drafting session). Approving: Marvin Percival.
Charter. standing-notes/dunin7-standing-authorization-charter-v0_1. No session executes a change request it drafted (§1).
Target. /Users/dunin7/loomworks-engine at main ffc29af. One repository. No Stele change — Stele's side already works and is a separately released package.
Build-list item. B-41.
CR number. CR-2026-165. Highest confirmed is CR-2026-164. [EXECUTING SESSION: verify; advance if taken.]
Grounding. inspection-briefs/loomworks-b41-verification-findings-v0_1 — every command and every trap below was run or read there; scoping-notes/loomworks-b41-scoping-note-v0_2 (the two decisions); inspection-briefs/loomworks-b41-step-0-findings-v0_1 (the chain read).
Status. Pre-execution.
A fresh Postgres instance cannot be taken to a working database by following anything written down, because nothing is written down. The engine's README says nothing about the database at all — a grep for alembic, migrat, stele, database and create_all returns zero matches. The only instruction to run the chain anywhere in the repository is an error message inside a test fixture.
The sequence that works is now known, because the verification ran it end to end and the result passed three independent tests: the test-suite precondition, a live application boot, and matching alembic heads.
Two things stand between knowing it and having it. One structural: the bootstrap the sequence depends on has a single invocation site, the web-server startup handler, so the step cannot be performed without booting a web server. One documentary: the sequence, and the several ways it silently misleads, exist only in a findings document.
D-1 — the bootstrap gets a standalone entry point in scripts/, calling the existing functions.
The four ensure_* functions already exist, are already idempotent, and are already the single implementation. What is missing is a way to call them without _lifespan.
A script in scripts/, following the bootstrap_platform_founder.py precedent — the codebase's own established shape for an operator-run, database-touching, outside-the-app action.
It duplicates nothing. It imports and calls the same four functions in the same order inside the same transactional pattern the verification proved works. [EXECUTING SESSION: the verification's §3.2 records the exact invocation that succeeded. The script is that, made durable.]
Why not a migration (the scoping note's Option C). 0034 does not merely need the row — it reads the row's current_engagement_version, which the bootstrap sets by writing seed and engagement memory objects through append_event. A migration would have to replicate all of it, which is the 0058 mirror hazard at scale.
D-2 — the README carries the sequence, and it is the deliverable.
Not an appendix to the code change — the point of it. A working bootstrap script that nobody can find leaves B-41 exactly where it was.
The sequence is five commands, not three. The engine's walk splits at 0033 and resumes to head — two. The bootstrap is its own — three. Stele's step is stamp then upgrade — five.
> Two counts corrected here rather than inherited. The scoping note said three; that was an estimate made before anything was run. The verification says five in one clause and six in the next — its "six" counts the bootstrap one-liner separately from the bootstrap step, which is the same command. Counted directly from its own §4.1 transcript: five. (A count carried from another document is verified by counting, not by establishing that it matters.)
D-3 — the traps are documented, not only the happy path.
The verification enumerated the ways a reader following the sequence goes wrong, and one is severe enough that omitting it would make the documentation actively misleading.
A failed multi-revision alembic upgrade head from empty rolls back everything it attempted. A reader who runs it, sees 0034 fail, and inspects the database finds zero tables — indistinguishable from the command having done nothing. The split at 0033 is not a style preference; it is what makes thirty-three migrations' progress survive a failure. Documentation that presents the split without this reads as fussiness and will be skipped.
The other four, all from verification §4.2: stamping succeeds unconditionally and against a database without principals leaves a self-consistent lie only a later step exposes; three different URL variables control three pieces, and STELE_DATABASE_URL alone has no fallback; two alembic configs in two directories accept the same URL variable and neither validates that it belongs to it; and re-running the bootstrap succeeds while changing nothing, which is correct and easy to misread.
D-4 — the prerequisites are named, including the two the verification only discovered by hitting them.
LOOMWORKS_SECRET_KEY is required by three migrations, and the verification never had to set it — .env supplied it silently through a second-level fallback. A fresh environment without that .env entry hits a RuntimeError the sequence gives no warning about.
The database role needs CREATEDB. The playground role does not have it; every throwaway had to be created by a role that does and owner-assigned afterward. Not written down anywhere in either repository or the record before now.
D-5 — no wrapper script that runs the whole sequence. Not yet.
Six commands invites collapsing them into one, and that is the right instinct at the wrong time. A wrapper hides the steps, and a hidden step that fails is harder to diagnose than a visible one — particularly given D-3's rollback trap, where the failure mode is looks like nothing happened.
Write the sequence down first, let it be followed a few times, then wrap it if it earns wrapping. Recorded as a build-list candidate, not built here. Reversal cost: none — it is additive whenever it is wanted.
3.1 scripts/bootstrap_engagements.py (name subject to Step 0) — the standalone entry point, per D-1. Reads its database URL from the same settings path the application does. Prints what it did: whether each row was created or already present, because D-3's fourth trap is that a no-op looks like a success.
3.2 README.md — a database section, per D-2, carrying the sequence verbatim from the verification, the prerequisites from D-4, and the traps from D-3.
3.3 Nothing else. No migration is added, edited or reordered. No alembic.ini change. No Stele change.
0034 self-sufficient. The scoping note set that aside as Option C.alembic.ini's version_locations. Option A, set aside — Stele is separately released and its internal layout is not the engine's to depend on.LOOMWORKS_SECRET_KEY migrations themselves. They fail recoverably and name their own recovery; documenting the prerequisite is the fix here.playground_dev's live schema matches what the chain produces. Named unread twice; still unread; needs the production database.Per-step commits, suite at each against the Step 0 baseline set. Check the current branch before the first commit.
Step 0 — pre-flight and one determination. Verify HEAD, tree, CR number. Record the baseline failure set by name — the engine's baseline is not green and carries one long-standing unrelated failure. Re-confirm the verification's anchors.
Then settle: is there an existing CLI or entry-point convention — a console_scripts block, a Makefile, a task runner — that the bootstrap should join instead of a bare script? scripts/bootstrap_platform_founder.py is the precedent this CR assumes; if a newer convention exists, the script follows it. Report before proceeding.
Step 1 — the script, §3.1.
Step 2 — the README, §3.2.
Step 3 — the acceptance run. See §6; it is the gate, and it happens before Checkpoint A rather than as part of it.
CHECKPOINT A — report, then proceed. The baseline comparison, and §6's acceptance run in full. No Operator confirmation. Halt and queue on: any new failure; the acceptance run failing at any step; the determination coming back ambiguous; any charter §6 anomaly.
Step 4 — implementation notes, carrying the determination and the acceptance run's transcript.
CHECKPOINT B — merge and tag. --no-ff to main, tag stand-up-sequence-v0_1, push. Authorized under R-2 including the push. Deployment is never autonomous (F-1) — and nothing here reaches the serving perimeter in any case.
Every other item on the gate is a proxy for this one.
On a fresh throwaway database, following only what the README says — not the verification findings, not this change request, not prior knowledge — stand the database up.
The session executing this knows the answer, which is the difficulty. So the instruction is procedural: read the README's database section as written, execute exactly what it says, and stop at the first point where it is insufficient, ambiguous, or wrong. Anything supplied from memory rather than from the page is a documentation defect, and the run halts there rather than continuing.
Then verify the result three ways, as the verification did: the test-suite precondition query returns its expected table count; the application boots and reports the administrative engagement present; both alembic heads match the repositories' declared heads.
Walk-audit dev pattern throughout: throwaway database created for the run and dropped after, spare ports, inline environment, .env untouched, live processes untouched. playground_dev and playground_test are never connected to.
ensure_* functions and duplicates no logic — a reader can see there is one implementation.0033.alembic.ini change. No Stele change.This block names the entry point and the standing fences.
CR-2026-165 — B-41, standing the system up from its own sources. Execution session.
CR: loomworks-record/change-requests/cr-2026-165-stand-up-sequence-v0_1.md
Confirm it exists, and that it is the highest version present — numeric sort.
Grounding, read before the CR:
inspection-briefs/loomworks-b41-verification-findings-v0_1.md
scoping-notes/loomworks-b41-scoping-note-v0_2.md
Charter dunin7-standing-authorization-charter-v0_1 governs.
Read the CR in full. It is the authority on what changes and where; this block
repeats none of it. Where this block and the CR appear to differ, the CR is
right and you halt rather than choosing.
Section 2 — the construction decisions and their reasoning
Section 3 — what changes
Section 4 — what is out of scope
Section 5 — the step sequence and both checkpoints
Section 6 — the acceptance run, which is the gate
Section 7 — the acceptance gate
ONE REPOSITORY — the CR's header names the target and the scope. No Stele change.
No migration change. If either appears to need changing, halt.
Section 6 is the difficult part, and the difficulty is that you will already know
the answer. Execute only what the README says, and stop at the first point where
the page is insufficient. Supplying a step from memory defeats the entire gate.
Standing fences, true regardless of this CR:
playground_dev and playground_test are live databases and are not touched.
Throwaway databases only, dropped after; .env untouched; spare ports.
Commit to a branch; check the current branch before the first commit.
Deployment is never yours.
Append the outcome to current-status/dunin7-status-brief at close.
DUNIN7 — Done In Seven LLC — Miami, Florida CR-2026-165 — B-41: standing the system up from its own sources — v0.1 — 2026-08-03 The sequence is known. This makes it findable, and proves it by following it.