Loomworks — Stele Phase 7 Step 0 Inspection Brief — v0.1

Version. 0.1 Date. 2026-06-19 Author. Marvin Percival (DUNIN7 Operator) with Claude.ai (scoping) on DUNIN7-M4. For. Claude Code (CC) on DUNIN7-M4. Read-only inspection. No edits, no commits, no migrations. Produce a report; file it. Status. Step 0 inspection brief — the grounding pass that precedes the Phase 7 (packaging) scoping note. Markdown primary (technical consumer — CC execution).

Grounding line. engine main at fe7c3f1 (CR-B merge), alembic head 0093, suite 2928/0/46. If main is not at fe7c3f1, stop and report drift — do not inspect against a different tree.

Plain-language summary

What this is. The read-only grounding pass for Stele Phase 7 — the arc that extracts Stele from the engine monorepo into a standalone, mountable, clone-and-run plugin. Before any extraction CR is drafted, CC inventories every way the engine and Stele reach across each other, organized by accessor class, and triages each finding as a hard extraction blocker or a mechanical repoint.

Why it's shaped this way. CR-B's Step 0 swept FK references and ORM stubs with zero drift — and was still blind to three other ways code reached persons: raw-SQL reads, the ORM FK strings the stubs targeted, and the down-path's data dimension. Those surfaced at execution, not grounding, and one (empty recipient lists) would have been a silent production break. The lesson: an inventory's lenses define its blind spots. This brief fixes that by naming the accessor classes explicitly as separate categories — each reported even when empty, so the blind spots are chosen, not inherited.

What CC produces. One report, loomworks-stele-phase-7-step-0-inspection-report-v0_1.md, with one section per accessor class (1–7 below), each carrying findings + a blocker/mechanical triage column, plus a synthesis section (§8) that answers the one question that decides the CR shape: is the import-graph clean enough to extract in one CR, or does it need a de-coupling sub-arc first?

What CC does NOT do. No edits. No commits. No migrations run. No create_all. Read-only inspection only — grep, git, file reads, and read-only DB introspection against playground_dev. If any step would mutate state, stop and report instead.

The discipline this brief enforces (read before inspecting)

Enumerate accessor classes explicitly. A "zero references" result under one lens does not clear the others. CR-B's FK lens was exact and still missed raw-SQL reads. Report every category below even when it is empty — an empty category is a finding ("no raw-SQL reads of Stele tables exist"), not an absence to skip.

Triage every finding. For each finding, mark it:

• BLOCKER — extraction cannot proceed until this is resolved (the load-bearing case: Stele importing upward from the engine; a Stele migration that depends on an engine table existing).
• MECHANICAL — a known repoint with an established pattern (e.g. an engine raw-SQL read of a Stele table stays in the engine and just needs the table reachable; an ORM FK string that converts DB-only, the CR-B Delta 3 pattern).
• OPEN — needs an Operator/scoping decision, not yet classifiable (e.g. a route that is half-Stele half-engine, where the split is a judgment call).

Direction matters. For import-graph and migration coupling especially, record the direction of every dependency. Engine → Stele is expected and fine (the engine consumes Stele). Stele → engine is the extraction blocker (a mountable plugin cannot import upward from the host it mounts into). State the direction on every edge.

Report, don't fix. Where CC sees an obvious repoint, name it in the triage column — do not perform it. This is grounding, not building.

What counts as a "Stele table" and a "Stele surface" (the inspection target set)

Establish the exact target set first, from the real tree — do not work from this list, confirm and correct it:

• Stele tables. The tables owned by Stele's own SteleBase MetaData. Per CR-B end-state: principals, plus the credential/recovery tables (webauthn_credential, recovery_code — confirm exact table names from stele/models.py). Report the full authoritative list as found.
• Stele modules. The stele/ package (confirm path — expected src/loomworks/stele/ or similar; the CR-B migration-path delta proved repo-root assumptions can be wrong). Report the real path and the module inventory.
• Stele surfaces. Any engine route, SDK entry, or session/config hook that is functionally Stele's even if it currently lives in engine code. Identifying these is part of the inspection (category 7), not a given.

The seven accessor classes (one report section each)

For every Stele table and every Stele module/surface, report each category below. Each section: the findings (file:line, the reaching construct, the direction), then the triage (BLOCKER / MECHANICAL / OPEN) with a one-line WHY.

1. ORM model references

Classes, relationship() objects, and ForeignKey objects (not strings — those are category 2) in engine code that point at Stele tables or import Stele model classes.

• Sweep: imports of Stele model classes across the engine; relationship(...) targeting Stele classes; ForeignKey(SteleClass.col) object form.
• Triage hint: engine→Stele model imports are expected (MECHANICAL — they become imports of the extracted package). A Stele model that relationship()s back to an engine class is a BLOCKER (upward coupling).

2. ORM FK strings

ForeignKey("stele_table.col") string targets that resolve in-metadata. CR-B Delta 3: removing the persons stubs stranded 8 of these; they converted DB-only because principals is on a separate MetaData.

• Sweep: every ForeignKey("...") string whose target is a Stele table, across the whole engine.
• Triage hint: once Stele is a separate package/MetaData, these cannot resolve as strings across bases. MECHANICAL (the CR-B DB-only pattern) if the DB constraint carries integrity; BLOCKER if any depends on a relationship() that needs in-metadata resolution.

3. Raw-SQL reads/writes

text() queries, raw SELECT/INSERT/UPDATE/JOIN that name Stele tables directly by string. This is the lens CR-B's Step 0 missed (4 production sites reading persons).

• Sweep: every raw-SQL string in the engine that names a Stele table (FROM principals, JOIN principals, INSERT INTO principals, etc.). Search the table names as string literals, not just the ORM classes.
• Triage hint: an engine raw-SQL read of a Stele table stays in the engine — MECHANICAL, needs the table reachable via the mounted Stele session. A raw-SQL write from the engine into a Stele table is OPEN (does the engine own that write, or should it go through Stele's SDK?).

4. Migration-chain coupling

Where Stele's migrations interleave with engine migrations, and what an independent Stele migration set requires. CR-B Delta 4: a down-path that re-points FKs needs the target table populated, not just schema-present.

• Sweep: which alembic revisions in migrations/versions/ are Stele-owned (create/alter Stele tables) vs engine-owned; the dependency edges between them (does an engine migration depend on a Stele revision, or vice-versa?); whether any Stele migration references an engine table.
• Report: the full Stele-revision list with each one's down_revision, and every cross-edge (Stele-rev depended on by engine-rev = expected; Stele-rev depending on engine-rev = BLOCKER for an independent set).
• Triage hint: a clean contiguous Stele migration sub-chain is MECHANICAL to extract. Interleaving (engine rev between two Stele revs, or a Stele rev whose down_revision is an engine rev) is BLOCKER-shaped — name the exact interleave points.

5. Import-graph coupling — the load-bearing category

What the engine imports from Stele (expected) and what Stele imports from the engine (the extraction blocker).

• Sweep: every import and from … import inside the stele/ package that resolves to an engine module (config, db session, models, utils, settings — anything outside stele/).
• Report: the complete list of Stele→engine imports, each with what it pulls and why (best inference from the call site). Separately, the engine→Stele import surface (for the SDK boundary).
• Triage: every Stele→engine import is a BLOCKER or an OPEN — a mountable plugin cannot import upward. For each: is it (a) something Stele should own (move into Stele — MECHANICAL once moved), (b) something that should be injected (config/session — the mountable-router pattern), or (c) a genuine entanglement needing an Operator call (OPEN)? Classify each; this classification is what §8 synthesizes.

6. Session/config injection points

How Stele currently receives its DB session and config (session-injected, config-injected per the manifest), and what a mountable router needs instead.

• Sweep: how stele/ gets its Session/engine (passed in? imported from an engine module? a global?); how it gets settings/config (e.g. loomworks_secret_key — the ExtractionSkill test pattern reads a per-engagement key; confirm how Stele reads its own config).
• Report: the exact injection mechanism today, and whether it's already injection-shaped (MECHANICAL — a mountable router formalizes it) or import-shaped (overlaps category 5 — BLOCKER until inverted).

7. Route/surface coupling

Which engine routes are actually Stele's, what mounting them as a router requires, and what auth/middleware they assume from the engine.

• Sweep: engine routes whose handlers are functionally Stele (identity/auth/credential/recovery endpoints — confirm against stele/ ownership, not by name guessing); for each, the auth dependency, middleware, and any engine-context it assumes (current-principal resolution, etc.).
• Report: the candidate Stele route set, each route's engine assumptions, and what a host app would need to provide for the router to mount.
• Triage hint: a route that assumes engine-provided auth context is OPEN (the mountable-router contract for auth is a scoping-note decision). A self-contained route is MECHANICAL.

8. Synthesis — the one question that shapes the CR

After the seven sections, a synthesis section answering, in plain terms:

Is the import-graph clean enough to extract Stele in a single CR, or does extraction need a de-coupling sub-arc first?

• List every BLOCKER found, across all seven categories, in one place.
• State whether the blockers are concentrated in one category (likely category 5) or spread.
• Give CC's read: one-CR extraction (blockers are few and mechanical-once-named) vs sub-arc (blockers need their own de-coupling CR before the repo even moves). This is CC's grounded read for the scoping note to absorb — not a decision, an input.

Also report, for the scoping note's sequencing:

• The size of each deliverable-set target as it stands in the real tree: how many migrations are Stele's, how many routes, how big the stele/ package, how many engine call-sites consume Stele.

How to run it (read-only)

• Confirm the tree first. git -C <engine> rev-parse HEAD = fe7c3f1; git -C <engine> status clean; alembic head 0093. If not, stop and report.
• Greps over the whole engine tree, not just stele/ — categories 1–3 are about engine code reaching into Stele.
• DB introspection read-only against playground_dev for the FK/constraint truth (the inbound-FK-on-principals set, the Stele table list) — \d+ / catalog queries, no mutation.
• Direction on every edge for categories 4 and 5.
• Every category reported even if empty.

What CC files

loomworks-stele-phase-7-step-0-inspection-report-v0_1.md — Markdown primary, filed to loomworks-record at phases/stele-extraction-phase-7/. Sections 1–7 (one per accessor class, findings + triage), section 8 (synthesis + deliverable-set sizing). Grounding line at top: engine main at the confirmed HEAD, alembic head, suite count.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Stele Phase 7 Step 0 Inspection Brief — v0.1 — 2026-06-19