Loomworks — Graph Stage 2 (Forward Walk / Dependents) — Step-0 Inspection Brief — v0.1

Version. 0.1 Date. 2026-07-28 Status. Inspection brief. Read-only inspection of the live engine tree and dev database ahead of the Stage 2 change-request draft. No code changes, no builds, no commits to code repos. Author. Claude Code on DUNIN7-M4. Companion document. loomworks-graph-stage-2-cr-scoping-note-v0_1 (scoping note; defines items 2a and 2b). Shape. Mirrors loomworks-graph-hygiene-step-0-inspection-brief-v0_1 (the CR-2026-154 brief) — posture, lettered sections, numbered checks, three-bucket findings summary.

Posture

Read-only. Inspect, query, report. Do not modify any file in loomworks-engine, loomworks, or loomworks-ui. Database queries are read-only SELECTs against the dev database. No builds and no code execution — the suite is not re-run in this session; the baseline is carried from its last measured run and marked as carried, not measured. If any check requires more than reading, halt and report instead.

Section A — Baseline

1. Report loomworks-engine current branch, main HEAD SHA, and whether the working tree is clean.
2. Report alembic heads (expect single head; report the revision).
3. Report the suite baseline as carried, not re-measured, naming the run it comes from. Flag explicitly that it was not re-run in this session.
4. Confirm Stage 1 (CR-2026-154) is landed and does not gate this work — the scoping note §1 asserts independence; verify rather than assume.

Section B — Item 2a: the field and its home

1. Confirm the live field name for shape events' selected memory references, and the containing view/table. The scoping note says selected_memory_refs; confirm against the live schema, not the model.
2. Report the field's SQL type and nullability, and the exact JSON structure of one element (verbatim, from live data).
3. Report where the field is written from — the production path(s) that populate it — and whether anything other than the shaping path writes it.
4. Report whether selected_memory_refs is version-pinned in practice (R-C2 says it should be), with live evidence.

Section C — Index state

1. Report every index currently on the containing view, with type and columns.
2. Report specifically whether a GIN index exists on selected_memory_refs. If not, report what the nearest in-tree GIN precedent is and where it lives — the scoping note names render_events_view.render_content (Phase 10); confirm whether a closer precedent exists.
3. Report the query plan today for an id-only containment predicate against selected_memory_refs, so the change-request draft can size the index's effect rather than assume it.
4. Confirm whether id-only containment (@> with {"id": …} and no version) is semantically correct against the live JSON structure — this is what the scoping note's recommended any-version match depends on.

Section D — Item 2b: the attach point

1. Enumerate the supersede and retract route(s) for assertions: paths, functions, and current response schemas. The scoping note explicitly does not assume "supersede" is a distinct terminal state — confirm what it actually is.
2. Report whether those routes' response models are shared with other routes. If they are, name every route sharing them, because that determines whether 2b's summary field can be added directly or needs the subclass pattern.
3. Report whether an in-tree precedent exists for additively extending a shared assertion response — CR-2026-154 item 1c faced this exact question; report what it did and whether it applies.

Section E — The cross-engagement question

1. Answer with live evidence: does selected_memory_refs ever cross engagement boundaries? The scoping note §2 asks step-0 to confirm it never does. Report the actual answer, not the expected one.
2. If it does cross: characterise the crossing precisely — how many refs, of what object type, owned by which engagement(s), and in what structural position within the array. A systematic crossing and an incidental one have very different consequences for 2a.
3. State plainly whether the crossing, if any, affects item 2a's actual scope — a dependents query keyed on an assertion. Distinguish "the field crosses engagements" from "an assertion-keyed query would cross engagements"; they are not the same claim.

Section F — Report format

Produce one Markdown report: loomworks-graph-stage-2-step-0-inspection-report-v0_1.md, sections mirroring A–E, every claim carrying a file path (with line numbers where useful) or the query used. End with a findings summary in three buckets:

• Confirms scoping note — items where live code matches the scoping assumptions.
• Corrects scoping note — items where live code differs; state the difference plainly.
• Blocks or splits — anything triggering the scoping note §4 halt condition (the supersede/retract route sitting in the middle of other active work) or surfacing a migration larger than the anticipated single GIN index.

File the report to loomworks-record under inspection-briefs/, alongside this brief. Stage by explicit path. Halt before push and report paths and SHA.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Graph Stage 2 (Forward Walk / Dependents) — Step-0 Inspection Brief — v0.1 — 2026-07-28