Loomworks — Stele Extraction CR-B 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 — ground-truth inspection against engine main at d0f302e. Status. Step 0 inspection brief for CR-B (the sole remaining Stele arc). The FK-target decision is settled: the 11 host FKs re-target to principals.id — a UUID, the id of an authorized identity (seed §Identity: "the UUID is the identity; it is what other Loomworks records reference"). This brief asks CC to ground every assumed fact against the real schema before any CR drafts. Markdown primary (technical consumer).

Plain-language summary

What this is. A read-only inspection. CC inspects, reports, changes nothing. The CR-B handoff carries an 11-FK list and a 4-stub list inherited from CC's CR-C grounding — this brief confirms those lists against the live schema at d0f302e and surfaces the migration shape per FK before a CR is drafted.

The one decision already made. FK target is principals.id. Not in scope to re-open.

The one thing the Operator's phrasing newly surfaced. principals.id is a UUID. Step 0 must verify the actual column types — principals.id and all 11 host person_id columns — because if any host FK column is not already UUID-typed to match, the re-target is a column-type migration, not just a constraint swap. That changes the per-FK migration shape and the down-path.

What CC does not do here. No migration. No code change. No branch. Inspect and report only. The CR drafts from this report.

Ground state (verify first)

Confirm before inspecting:

cd /Users/dunin7/loomworks-engine
git fetch origin
git rev-parse origin/main
git status

Expect origin/main = d0f302e, working tree clean, alembic head 0090. If origin/main is not d0f302e, STOP and report — drift means the orientation is stale.

What to inspect and report

A. The FK-target type question (the new one — do this first)

1. The actual column type of principals.id in the live schema (playground_dev, migration 0090). Confirm it is UUID.
2. The actual column type of persons.id.
3. For each of the 11 host FK columns: the column type, and whether it matches principals.id's type or persons.id's type.

Report a table: FK column → current type → matches principals.id? (yes/no). Any "no" is a column-type migration, not just a constraint re-point — flag each.

B. Confirm the 11 host FKs against the real schema

The inherited list (from CR-C grounding) is: companion_notifications, conversation_turns, credit.credit_grant, engagement_tags, engagements, memberships, organization_memberships, person_settings, saved_filters, uploaded_files, workspaces.

For each, report (schema-qualified where it applies — some are on audit/credit, not public):

• The exact table and schema.
• The exact FK column name (is it person_id everywhere, or does any table differ?).
• The current FK constraint definition (the REFERENCES persons(id) clause, constraint name, and ON DELETE / ON UPDATE behavior).
• Nullable or NOT NULL.

Then answer: is the count exactly 11, or has anything drifted since CR-C grounding? If a 12th FK references persons or one of the 11 is gone, report it — do not silently reconcile.

C. Confirm the 4 _PersonRow stubs as distinct tokens

Inherited list: files/models.py, notifications/models.py, orchestration/models.py, persons/models.py.

For each, report the exact class definition (the stub source lines) and confirm it is an id-only FK-target stub on the module's Base — not an app-columns model. Confirm the count is exactly 4 and the token in each file. (Token-level removal discipline applies in the build; here just locate and confirm.)

D. The trigger to retire

Confirm migration 0090 installs the principals → persons mirror trigger and report the trigger + function names exactly as they exist in the DB. The CR-B down-path will need to restore them verbatim.

E. Migration-shape signal (report, do not design)

Based on A–D, state for the CR drafter:

• Which of the 11 are pure constraint re-points (type already matches) vs. column-type migrations (type differs).
• Whether any of the 11 are NOT NULL with no default (affects ordering — the new target must be populatable before the old constraint drops).
• Whether the audit/credit-schema FKs need schema-qualified migration handling.

Do not propose the migration. Report the shape so the CR can.

What this brief does NOT ask for

• No migration drafting. The CR does that.
• No code changes, no branch, no commits.
• No re-opening the FK target — principals.id is settled.
• No stub removal or table drop — those are CR-B build steps, scoped after this report.

Report back

A single report to Downloads (or inline if short) covering A–E. If anything contradicts the inherited lists (count drift, a stub that's actually an app model, a type mismatch), surface it plainly — the inherited lists are CR-C-era and this brief exists precisely to catch drift before a CR commits to them.

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