Loomworks — Phase 53 Step 0 Inspection Brief

Version. 0.1 Date. 2026-05-10 Status. Pre-CR scoping evidence brief. Hands to CC. Mirrors loomworks-phase-52-step-0-inspection-brief-v0_1.md. Author. Claude.ai. Operator: Marvin Percival. Companion document. loomworks-phase-53-scoping-note-v0_1.md (parent — the brief presupposes its decomposition, its P53-D1 through P53-D9 recommendations all settled by the Operator, and its §7 candidate verification list).

1. What this is

Pre-CR live-codebase verification for Phase 53 — Discovery-to-seed skill substrate as the engagement creation arc kickoff (Option B from the scoping-time shape options). Single sub-arc; engine repo only; sub-arcs 2 (Operator Layer) and 3 (marketing) empty by default.

Phase 53 scoping note v0.1 records the build shape and architectural decisions (Option B; P53-D1 through P53-D9 with all Operator-confirmed recommendations). Several of those decisions rest on assumptions about what the Phase 16 ExtractionSkill family, the Phase 25 seed-induction loop, the Phase 31 conversational creation flow, the Phase 38 declare-and-register surface, the Phase 16 upload pipeline, and the FORAY attestation seam look like as actually shipped at the Phase 52 close baseline. The scoping note carries [Step 0 verifies] markers across the substrate touch-points. This brief enumerates those verifications, gives CC a paste-ready way to run them, and defines what CC produces as a result.

CC verifies, evidence-cites, and reports verdicts. CC does not propose remediation, does not edit the scoping note, does not draft the CR, does not start build.

The brief assumes Option B is the working shape with all P53-D1 through P53-D9 recommendations settled per Operator confirmation:

P53-D1: LLM-assisted bounded skill (LLM call wrapped by strict input/output contract).
P53-D2: free-form Markdown Discovery documents with recognized section headers (path (a)).
P53-D3: registry locus deferred to Step 0 (V2 resolves).
P53-D4: Operator Layer sub-arc 2 empty by default.
P53-D5: Phase 31 and Phase 53 coexist as sibling paths.
P53-D6: Phase 16 upload-pipeline artifact as Discovery-document Memory location.
P53-D7: tag name phase-53-discovery-to-seed-skill.
P53-D8: explicit multi-phase engagement creation arc framing.
P53-D9: Memory event kind discovery_to_seed_extracted.

If V2 or V5 reports diverge from the scoping-note read in ways that affect P53-D3 or P53-D5, scoping v0.2 reshapes around the actual evidence.

Lens-bounded discipline note. Per manifest v0.37 §2 lens-bounded-scoping-evidence-cascade methodology candidate (awaiting second instance), several verifications below explicitly ask for enumeration of call-sites or registration-sites where the scoping note assumes a count or shape. The Phase 52 finding was that Step 0 verifications inherit aperture from the brief's explicit asks; this brief widens aperture pre-emptively where the scoping note's assumptions involve counts. If Phase 53 surfaces this pattern again as a real call-site count divergence, it promotes from candidate to named principle in the manifest v0.38 bump.

2. Reading order before running

CC reads in this order before starting verifications:

loomworks-phase-53-scoping-note-v0_1.md (parent document; in project knowledge).
Highest-versioned current-status manifest in project knowledge (v0.37).
phase-52-cr-jurisdiction-routing-v0_1.md (engine repo docs/phase-crs/; the most recent CR — for §6–§11 substrate decomposition pattern, §17 test list pattern, FORAY hook conventions, Memory event registration pattern V7 verifies).
phase-31-cr-conversational-engagement-creation-v0_1.md (engine repo docs/phase-crs/; the existing conversational creation flow — V5 verifies the as-shipped substrate; especially §4 system-level key store, §5 conversational seed synthesis endpoint, §6 conversation prompt template, §7 FORAY hooks).
Phase 16 CR + Phase 16 addendum (engine repo docs/phase-crs/; ExtractionSkillRegistry shape — V1 verifies; per-engagement key store pattern — context for V5).
Phase 38 CR (engine repo docs/phase-crs/; declare-and-register pattern — V3 verifies).
Phase 25 CR + Phase 25 FORAY amendment (engine repo docs/phase-crs/; engagement creation endpoints, seed-induction loop, FORAY attestation seam — V4, V9 verify).
loomworks-queued-directions-and-deferred-work-v0_7.md §1.1 + §1.2 (the queued-directions framing of the engagement creation arc; §1.2 trajectory note's reference to "materializer registry" — V2 resolves).
This brief.

3. Baseline state to verify

Before running verifications, CC confirms the substrate is at the expected baseline. Phase 52 close per the scoping note §predecessor-state:

Engine repo: DUNIN7/loomworks-engine, tag phase-52-jurisdiction-routing at engine 69aecdc (annotated tag object f11e41a). main one commit ahead at 14e5a7f per Phase 52 close report. Substrate 2,137 tests passed, 25 skipped. Alembic 0064. Working tree clean on main. Pushed to origin.
Operator Layer repo: DUNIN7/loomworks, Phase 51 marker tag phase-51-marketing-site-and-companion-email at frontend e4c09e0 (Phase 50 commit). 139 vitest passed, eslint/tsc/build clean. Phase 52 sub-arc 2 was empty by default per P52-D4. Not in Phase 53 scope by default per P53-D4.
Marketing repo: DUNIN7/loomworks-marketing, tag phase-51-marketing-site-and-companion-email at bf2f694. main one commit ahead at 78c26fa. Live at https://loomworks.doneinseven.com. Not in Phase 53 scope.
Workshop repo: DUNIN7/loomworks-ui, unchanged from Phase 48 baseline. Not in Phase 53 scope.

If the live baseline diverges (test count off by more than ±2 routine noise, Alembic head different from expected, working tree dirty, tag missing), CC stops at the start and reports before running any verifications.

4. Ten verifications

Each verification has four parts: ask (what to verify), look at (where to read), evidence expected (what the finding should cite), verdict criteria (when each verdict applies).

4.1 Verification 1 — ExtractionSkill family location, protocol, and registration call-sites

Ask. Confirm the as-shipped ExtractionSkill family — module location, protocol surface (the Python protocol or base class skills implement), the registration mechanism (decorator, registry function, both), the secret_key kwarg autouse-monkeypatch convention from the testing standard, AND enumerate every existing skill registration call-site so the Phase 53 skill registration lands in a verified-by-count surface (lens-bounded discipline; the scoping note assumes "the existing registry pattern" — count divergence here would surface a P53-D3 reshape).

Look at.

Engine: the skills directory — likely loomworks/skills/. Confirm the directory exists, list its contents, and identify the base class / protocol all skills inherit / implement.
The registration mechanism — likely loomworks/skills/__init__.py or a sibling registry.py; identify how skills get registered (decorator? imperative call? auto-discovery?).
Every call-site that registers a skill — grep or equivalent for the registration mechanism's signature; count and list.
The secret_key kwarg pattern — confirm the autouse-monkeypatch convention from the testing standard (per userMemories: "ExtractionSkill protocol carries a secret_key kwarg; tests must autouse-monkeypatch settings.loomworks_secret_key to TEST_SECRET_KEY"). Read the relevant conftest.py files.

Evidence expected.

Skills directory path; full file listing.
Base class / protocol definition: file path, line range, full signature.
Registration mechanism: file path, line range, full signature, calling convention.
Enumerated list of every registration call-site with file path and line number for each.
The secret_key kwarg signature in the protocol; the autouse-monkeypatch fixture in conftest.py (file path + line range).

Verdict criteria.

HOLDS. ExtractionSkill family exists at the conventional location; protocol surface matches the scoping note read; registration mechanism is straightforward; call-site count is consistent with what one would expect (a small handful for the existing skills); secret_key kwarg pattern intact. Phase 53 skill registers in the same family.
HOLDS via close-but-not-identical naming. The substrate exists but uses different naming (e.g., the family is called Extractor not ExtractionSkill, or the registry is named differently). Reports the actual names; CR drafting uses the actual names.
PARTIALLY HOLDS. Family exists but the registration mechanism has shifted since Phase 16 / Phase 38 (e.g., a new decorator-based pattern co-exists with imperative registration; the secret_key kwarg now lives on a different protocol). Reports the specifics and which call-sites use which pattern.
BREAKS. ExtractionSkill family doesn't exist as a registry-shaped thing — skills are scattered across modules without unified registration. Phase 53 substrate work grows scope to introduce the registry. Scoping v0.2 absorbs.
INCONCLUSIVE. Family is identifiable but the registration mechanism is non-obvious without runtime inspection.

4.2 Verification 2 — "Materializer registry" identity (resolves P53-D3)

Ask. Queued directions v0.7 §1.2 trajectory note refers to "the skill pattern composes with the rest of Loomworks (extraction skills, materializer registry, etc.)" — phrasing that suggests materializer registry is a distinct thing from ExtractionSkillRegistry. Resolve whether materializer registry is (i) a separate registered surface, (ii) a synonym for ExtractionSkillRegistry, (iii) a Phase 38 grammar-dict surface, or (iv) terminology that didn't survive into shipped substrate. This verification settles P53-D3 (skill registration locus).

Look at.

Engine: grep -ri "materializer" across the codebase; report all hits with file paths and line ranges.
If hits exist: the module(s) containing the term, their relationship to the ExtractionSkill family (V1) and the Phase 38 declare-and-register surface (V3).
If no hits: confirm the term is queued-directions-side framing only, not a substrate concept. Report the absence.

Evidence expected.

All materializer hits in the substrate (file path, line range, usage context for each).
For each hit, a one-sentence read on whether it's the same surface as ExtractionSkillRegistry (V1) or distinct.
A definitive identity reading for "materializer registry" — what it actually is in shipped substrate, or that the term is queued-directions-only and Phase 53 should pick another locus.

Verdict criteria.

HOLDS as ExtractionSkillRegistry synonym. "Materializer registry" is queued-directions phrasing for what the substrate calls ExtractionSkillRegistry (V1). P53-D3 settles to: register Phase 53 skill in the existing ExtractionSkillRegistry.
HOLDS as distinct surface. "Materializer registry" is a real, distinct registered surface (e.g., a render-pipeline registry, a Phase 10 specialist registry). Reports which surface; P53-D3 settles to: register Phase 53 skill in the ExtractionSkillRegistry (still the right family for upload-side skills) with explicit acknowledgment that the queued-directions phrasing referred to a different substrate concept.
HOLDS as Phase 38 grammar surface. The term refers to grammar-driven materialization in the Phase 38 declare-and-register pattern. Reports the surface; P53-D3 settles per V3's verdict on whether Phase 38's grammar-dict is the right registration locus or whether ExtractionSkillRegistry is.
NOT FOUND. No materializer hits in substrate. Reports the absence; queued directions §1.2 trajectory note's phrasing was forward-looking, not load-bearing on shipped substrate. P53-D3 settles to ExtractionSkillRegistry by default.
INCONCLUSIVE. Hits exist but their identity is non-obvious.

4.3 Verification 3 — Phase 38 declare-and-register pattern current shape

Ask. Confirm the Phase 38 declare-and-register pattern as actually shipped — module location, declaration surface (where engagements declare what they want registered), registration mechanism, and any existing extension points the Phase 53 skill might use directly rather than going through the ExtractionSkillRegistry. The scoping note assumes Phase 38 is a sibling registration pattern that could be the Phase 53 locus per P53-D3 candidate (iii); V3 confirms or refutes that candidate.

Look at.

Engine: the Phase 38 module(s) — likely loomworks/spec/ or loomworks/grammar/ per Phase 38 CR §6 (specification grammar declaration).
The declaration surface — how an engagement declares grammar; where the grammar-dict lives.
The registration mechanism — how declared grammar gets registered into a runtime registry.
The relationship between Phase 38's grammar-dict and the ExtractionSkillRegistry from V1.

Evidence expected.

Phase 38 module path(s); file listing.
The declaration surface signature (what an engagement passes to declare grammar).
The registration mechanism call-sites (grep or equivalent for the registration function).
A one-sentence read on whether Phase 38's grammar-dict is structurally similar to ExtractionSkillRegistry (which would make P53-D3 candidate (iii) viable) or structurally different (which would refute (iii)).

Verdict criteria.

HOLDS as sibling-but-distinct. Phase 38 grammar-dict is a sibling registration pattern but distinct from ExtractionSkillRegistry; mixing the two is not the Loomworks convention. P53-D3 settles to ExtractionSkillRegistry per V1's family.
HOLDS as composable. Phase 38 grammar-dict and ExtractionSkillRegistry compose cleanly (e.g., engagement-declared grammar references ExtractionSkillRegistry-resolved skill names). P53-D3 settles to ExtractionSkillRegistry but Phase 53's CR notes the Phase 38 composition surface for future engagement-creation-arc work.
PARTIALLY HOLDS. Phase 38 pattern has shifted since the CR; the declaration surface or registration mechanism diverges in ways that affect Phase 53 read. Reports specifics.
BREAKS. Phase 38 didn't ship as the CR described; the declare-and-register pattern is materially different. Scoping v0.2 absorbs.
INCONCLUSIVE. Phase 38 module identifiable but the pattern surface is non-obvious without runtime inspection.

4.4 Verification 4 — Existing seed schema in code (R-A5–R-A11)

Ask. Confirm the seed schema (R-A5 through R-A11 per methodology v0.20 / Spec v0.10 Sec-A.2) as actually shipped in code — the canonical Pydantic model or dataclass for a candidate seed payload, the field names, the field types, the Phase 25 POST /engagements/{eid}/seed endpoint's request body shape. Phase 53's skill output must conform exactly. Enumerate every code site that constructs or validates a seed payload (lens-bounded discipline; scoping note assumes "the canonical structure" — count divergence here would surface seed-schema scattering).

Look at.

Engine: the engagement creation router — likely loomworks/api/routers/engagements.py or similar; the POST /engagements/{eid}/seed endpoint definition.
The Pydantic / dataclass model for seed payload (request body).
The persistence path — how the seed gets written to Memory; what model defines the shape of what's persisted.
Every construction site for a seed payload — grep for the model name; report file paths + line numbers.
The R-A5 through R-A11 mapping — confirm the field names align with the methodology document's R-A5 through R-A11 (or report the divergence).

Evidence expected.

Pydantic / dataclass definition: file path, line range, full field listing with types.
Endpoint definition: file path, line range, request body type annotation.
Persistence model (if distinct from request body): file path, line range, field listing.
Enumerated list of every construction site for a seed payload (file path + line number).
One-sentence read on R-A5 through R-A11 alignment with shipped field names.

Verdict criteria.

HOLDS. Single canonical model; field names align cleanly with R-A5 through R-A11 (or document a clean naming map); construction sites are countable and bounded (e.g., one in the form-submission path, one in the Phase 31 conversational path, plus tests). Phase 53's skill output target is unambiguous.
HOLDS with naming-only divergence. Field names use different identifiers than R-A5 through R-A11 but the structural correspondence is clean. Reports the mapping; CR drafting uses the actual names.
PARTIALLY HOLDS. Multiple seed-shaped models exist (e.g., one for request, one for persistence, one for display); Phase 53's skill output target needs explicit selection. Reports the models and recommends which one Phase 53 produces.
BREAKS. Seed schema doesn't exist as a single canonical shape; field-shape is scattered across construction sites; Phase 53 needs to introduce a canonical model first. Scoping v0.2 absorbs scope growth.
INCONCLUSIVE. Schema identifiable but construction-site enumeration is too entangled without deeper read.

4.5 Verification 5 — Phase 31 conversational creation surface current state (resolves P53-D5 default)

Ask. Confirm Phase 31's conversational creation flow is still functional in current substrate — POST /seed/converse endpoint live, POST /seed/converse/transcribe live, GET /seed/conversation live, system_config table populated, conversation prompt template at loomworks/prompts/creation_conversation.py, all FORAY hooks intact. Confirms the P53-D5 "coexist as sibling paths" recommendation rests on a working sibling, not a degraded one. Enumerate every call-site that touches the seed-induction loop entry (Phase 25 POST /engagements/{eid}/seed/induct and equivalents) so Phase 53's new skill-completion → induction-loop hand-off lands consistently with both Phase 25 form-submission and Phase 31 conversation endpoints.

Look at.

Engine: Phase 31 router module — loomworks/api/routers/seed_conversation.py or wherever the endpoints live.
All four endpoints' definitions (POST /seed/converse, POST /seed/converse/transcribe, GET /seed/conversation, GET /seed/converse/ready per Phase 31 CR §5 + §8).
The conversation prompt template module — confirm exists and exports current PROMPT_VERSION / CONVERSATION_MODEL / CREATION_CONVERSATION_PROMPT.
The system_config table — Alembic migration history; current schema.
Every call-site that hands off to the Phase 25 induction loop — grep for the induction endpoint or its handler function.
Any drift since Phase 31's tag in either the endpoints or the model.

Evidence expected.

Endpoint definitions: file paths, line ranges, request/response signatures.
Prompt template module: file path, current PROMPT_VERSION value.
system_config table: Alembic migration ID; current column listing.
Enumerated list of every induction-loop entry call-site (file path + line number).
Drift summary: any structural changes since Phase 31's tag.

Verdict criteria.

HOLDS. Phase 31 surface is intact; endpoints functional; FORAY hooks present; induction-loop entry call-sites are countable and bounded. P53-D5 sibling-paths recommendation rests on solid ground.
HOLDS with minor drift. Endpoints present; minor refactoring since Phase 31 (e.g., model relocations, signature simplifications) but the surface is still functional. Reports the drift; no Phase 53 implication.
PARTIALLY HOLDS. Phase 31 surface is partially functional; some endpoint or some FORAY hook has degraded since the Phase 31 tag. Reports specifics; P53-D5 may need to revisit (do we ship Phase 53 alongside a degraded Phase 31, or do we repair Phase 31 first?).
BREAKS. Phase 31 surface is non-functional or has been substantially reshaped (e.g., the conversational endpoint was removed, the system_config table was renamed). Reports the surface state; P53-D5 reshapes — coexist-as-sibling-paths becomes structurally impossible if the sibling doesn't exist.
INCONCLUSIVE. Endpoints present but their functional state is non-obvious without runtime exercise.

4.6 Verification 6 — Phase 16 upload pipeline current shape (Discovery-document landing)

Ask. Confirm the Phase 16 upload pipeline as actually shipped — POST /engagements/{eid}/files endpoint live; the file upload mechanism produces a Memory artifact reference; Markdown content is supported (text-shaped artifact, not just binary blob). Phase 53's skill input is "a Discovery document landed in Memory via the Phase 16 upload pipeline" per P53-D6.

Look at.

Engine: Phase 16 file upload router — loomworks/api/routers/files.py or equivalent.
The endpoint definition (POST /engagements/{eid}/files); request body shape; supported content types.
The Memory artifact write path — what kind of Memory event is produced, what reference shape the caller gets back.
How Markdown / text content is handled — whether it's stored as a binary blob (and the Phase 53 skill must read+decode), as a text-shaped artifact (and the skill reads directly), or as both (the Phase 53 skill chooses).
Any size limits or content-type filters that affect Discovery-document upload.

Evidence expected.

Endpoint definition: file path, line range, request signature.
Memory artifact write path: file path, line range, event kind written.
Content-type handling: code path that branches on text vs binary, if any.
Any limits or filters: file path, line range, exact thresholds.

Verdict criteria.

HOLDS. Phase 16 upload pipeline accepts Markdown/text content, produces a Memory artifact reference Phase 53 skill can consume. P53-D6 settles cleanly.
HOLDS with text/binary disambiguation. Pipeline supports text content but the Phase 53 skill needs to choose how to request it. Reports the choice; CR drafting absorbs.
PARTIALLY HOLDS. Pipeline accepts uploads but produces a binary-only artifact reference; Phase 53 skill needs to add a text-decoding step at its input edge. Reports the gap; CR §6 grows scope to handle it.
BREAKS. Phase 16 upload pipeline doesn't accept text/Markdown content, or the Memory artifact reference shape is incompatible with skill input. P53-D6 reshapes — Phase 53 may need to introduce a Discovery-record-as-Memory-shape upstream substrate, growing scope substantially.
INCONCLUSIVE. Pipeline identifiable but content handling is non-obvious without runtime exercise.

4.7 Verification 7 — Memory event registration pattern (Phase 50/52 mirror)

Ask. Confirm the typed-MemoryObject-subclass-without-migration pattern from Phase 50 (grant_request_received) and Phase 52 (jurisdiction_routing_decided) as still the canonical pattern for new Memory event kinds. Phase 53 registers discovery_to_seed_extracted per P53-D9 following the same pattern — without an Alembic migration if the pattern holds. Confirm OBJECT_TYPE_REGISTRY entry point, event-kind literal canonicalization site, and FORAY namespace pattern.

Look at.

Engine: the Phase 50 grant_request_received registration — likely in loomworks/credit/grant_request.py or similar; full registration code.
The Phase 52 jurisdiction_routing_decided registration — likely in loomworks/credit/jurisdiction_routing.py per scoping note baseline state; full registration code.
The OBJECT_TYPE_REGISTRY definition — file path, structure.
The event-kind literal canonicalization site — where event kinds get registered as canonical literals.
The FORAY namespace pattern — _foray namespace in event payloads, content_hash field convention.

Evidence expected.

Phase 50 registration: file path, line range, full registration code.
Phase 52 registration: file path, line range, full registration code.
OBJECT_TYPE_REGISTRY: file path, structure, current entries.
Event-kind literal canonicalization site: file path, line range.
FORAY namespace + content_hash pattern as code: file path, line range, conventional shape.
Confirmation that neither Phase 50 nor Phase 52 required a new Alembic migration for their event-kind addition.

Verdict criteria.

HOLDS. Pattern is canonical and consistent; Phase 53 follows mechanically. No migration needed.
HOLDS with minor convention drift. Pattern is canonical but minor naming or location differences exist between Phase 50 and Phase 52 registrations. Phase 53 picks the more recent (Phase 52) convention.
PARTIALLY HOLDS. Pattern works but some part of it (e.g., OBJECT_TYPE_REGISTRY shape, FORAY hook registration) has shifted since Phase 50. Reports the shift; CR drafting absorbs.
BREAKS. Pattern requires Alembic migration for new event kinds in current substrate (e.g., a typed-event-kinds table was introduced). Phase 53 grows scope to include a migration. Scoping v0.2 absorbs.
INCONCLUSIVE. Pattern identifiable but its repeatability for Phase 53 is non-obvious.

4.8 Verification 8 — Existing Discovery records as test fixture inventory

Ask. Inventory the Discovery records already produced in project knowledge as candidate test fixtures for the Phase 53 skill. The skill operates on free-form Markdown with recognized section headers (path (a) per P53-D2); the test surface needs at least three such records spanning different domains to demonstrate the skill is not over-fit to one Discovery shape. Confirm the recognized-section-header convention is reading-pattern-stable enough for the skill to depend on.

Look at.

Project knowledge: search for documents with names matching -discovery-, Discovery, or files that read as Discovery-trajectory shape (per the candidate seed v0.8 / declared-shape-types draft v0.1 description: "positions considered, alternatives set aside and why, corrections that landed, moments where something new crystallized").
For each candidate Discovery record found, read for section headers and structural patterns. Identify the convention: are sections like "What the engagement is", "Voice", "Constraints" used consistently, or do different records use different section patterns?
Inventory at least the following candidates (others welcome):
loomworks-person-layer-discovery-v0_2.md
discovery-shape-as-specification-v0_4.md
loomworks-marketing-creation-flow-content-v0_3.md
render-discovery-handoff-v0_2.md
loomworks-ui-discovery-sign-in-and-dashboard-v0_1.md

Evidence expected.

For each candidate Discovery record: file name, top-level section headers (verbatim), one-sentence read on whether the record's structure maps cleanly to the seed schema (R-A5–R-A11 from V4).
A summary read on section-header convention stability across the records: do they share enough structural pattern that a single skill prompt / instruction can extract seeds from all of them, or are they different enough that the skill needs per-record-shape branching?
A recommendation on which 3+ records make the strongest test fixture set for Phase 53's CR §17 test list.

Verdict criteria.

HOLDS. 3+ Discovery records exist; section-header convention is stable enough that one skill prompt handles all of them. Phase 53 skill design proceeds with confidence in input-shape stability.
HOLDS via lens-narrowing. 3+ records exist but only a subset shares stable section-header convention. Phase 53 skill targets the subset; the broader inventory becomes Phase 54+ surface for handling Discovery-record-shape variation. Reports the subset.
PARTIALLY HOLDS. Records exist but section-header convention varies enough that the skill prompt design needs to be more flexible than "structured Markdown extraction." Phase 53 skill leans more on the LLM-assisted side of the bounded-skill posture (per P53-D1). Reports the variance; CR drafting absorbs.
BREAKS. Few or no records carry consistent Discovery-trajectory shape; the §1.1 product surface needs to design the convention before the skill can depend on it. Phase 53 reshapes — either reduce scope to a fixed-template Discovery skill (loses generality) or defer until §1.1 settles (loses the kickoff posture). Scoping v0.2 absorbs.
INCONCLUSIVE. Records identifiable but their structural patterns are non-obvious without deeper read.

4.9 Verification 9 — FORAY attestation seam current shape

Ask. Confirm the FORAY attestation seam (Phase 25 amendment + Phase 50/52 extensions) as actually shipped. The Phase 53 skill produces a discovery_to_seed_extracted Memory event with content_hash + _foray namespace per P53-D9 and the Phase 50/52 precedent. V9 confirms the canonical content_hash computation function, the _foray namespace structure, and the test fixture for FORAY hook coverage.

Look at.

Engine: the FORAY hook module — likely loomworks/foray/ or similar.
The content_hash computation function — file path, signature, hashing convention.
The _foray namespace structure — what fields go inside _foray in event payloads.
A representative Phase 50/52 test that asserts FORAY hook coverage — file path, fixture pattern.

Evidence expected.

FORAY module path and listing.
content_hash function: file path, line range, full signature.
_foray namespace example: a representative event payload showing the structure.
A Phase 50 or Phase 52 test asserting FORAY coverage: file path, line range, assertion shape.

Verdict criteria.

HOLDS. Pattern is canonical; Phase 53 mechanics follow.
PARTIALLY HOLDS. Pattern shifted slightly (e.g., new fields in _foray namespace since Phase 50). Reports specifics; CR drafting absorbs.
BREAKS. Pattern materially different. Scoping v0.2 absorbs.
INCONCLUSIVE. Pattern identifiable but the test fixture shape is non-obvious.

4.10 Verification 10 — Endpoint surface naming convention

Ask. Confirm the existing engagement creation endpoint surface naming so Phase 53's new endpoint lands consistently. Phase 25 ships POST /engagements/{eid}/seed (form submission), POST /engagements/{eid}/seed/induct (induction trigger), and Phase 31 ships POST /seed/converse, GET /seed/conversation, POST /seed/converse/transcribe, GET /seed/converse/ready. The Phase 53 endpoint candidate POST /engagements/{eid}/seed/from-discovery (per scoping note §4) needs to fit into the family without surprise.

Look at.

Engine: every endpoint route definition that touches /seed or /engagements/{eid}/seed. grep for the route prefixes; report all routes with file paths and line numbers.
The convention reading: do /engagements/{eid}/seed/ and /seed/ co-exist as parallel families (engagement-scoped vs system-scoped), or has there been consolidation?
Whether Phase 53's POST /engagements/{eid}/seed/from-discovery fits the engagement-scoped family naturally.

Evidence expected.

Enumerated list of every route under /seed*: file path, line number, full route signature.
A one-sentence read on the convention (engagement-scoped + system-scoped parallel; or consolidated; or inconsistent).
A recommendation on the Phase 53 endpoint name: confirm /engagements/{eid}/seed/from-discovery, or propose a more in-convention name.

Verdict criteria.

HOLDS. Naming convention clean; POST /engagements/{eid}/seed/from-discovery fits naturally. CR drafting uses the proposed name.
HOLDS via in-convention rename. Naming convention is clean but the proposed name has an in-convention sibling (e.g., POST /engagements/{eid}/seed/discovery simpler; or POST /engagements/{eid}/seed/extract more aligned with skill-centric naming). Reports the alternative; Operator picks at v0.2 review.
PARTIALLY HOLDS. Naming convention has minor inconsistencies; Phase 53 endpoint can land but adjacent convention drift is worth flagging. Reports the drift; carries forward as Phase 54+ minor cleanup.
BREAKS. Naming convention is inconsistent enough that the Phase 53 endpoint needs deliberate placement to not increase the entropy. Reports specifics; v0.2 absorbs.
INCONCLUSIVE. Routes identifiable but the convention pattern is non-obvious.

5. After verification

CC produces phase-53-step-0-findings-v0_1.md at /Users/dunin7/loomworks-engine/docs/phase-impl-notes/. One section per verification. Each section: verdict (HOLDS / PARTIALLY HOLDS / BREAKS / INCONCLUSIVE; verifications also accept their per-verdict variants per §4 above), evidence (file paths, line numbers, function signatures, exact strings as found, enumerated lists where the verification asks for enumeration), implication for scoping note (carry / naming-only divergence / architectural amendment).

CC then tells Marvin which of three states the findings put Phase 53 in:

All HOLDS or naming-only divergences. Proceed to Phase 53 CR drafting handoff (the next document Claude.ai produces, which references both the scoping note and the findings; scoping v0.2 absorbs Step 0 findings before the CR drafts).
One or more PARTIALLY HOLDS or BREAKS with architectural implications. Findings get reviewed; Marvin and Claude.ai produce scoping note v0.2 absorbing the findings; CR drafting waits.
One or more INCONCLUSIVE. Marvin reviews CC's specific obstacles; either commissions deeper inspection (Step 0.5), proceeds with explicit acknowledgment of unknown, or pauses pending more information.

CC does not propose remediation in the findings document. CC does not edit the scoping note. CC does not start CR drafting. CC does not start implementation. CC reports.

Lens-bounded discipline reminder. Verifications V1, V4, V5, and V10 explicitly ask for enumeration of call-sites, construction-sites, induction-loop entries, or routes. If any enumeration produces a count materially different from what the scoping note assumes (V1: a small handful of skill registrations; V4: one canonical seed model with bounded construction sites; V5: clean and bounded induction-loop entry; V10: clean and bounded /seed routes), CC reports the discrepancy as a finding worth surfacing* even if the verdict otherwise lands HOLDS — this is how the lens-bounded scoping evidence cascade methodology candidate gets its second instance and becomes a named principle.

6. CC kickoff prompt — paste-ready

Place this brief at /Users/dunin7/loomworks-engine/docs/phase-impl-notes/loomworks-phase-53-step-0-inspection-brief-v0_1.md (or wherever you prefer; adjust the first line of the kickoff accordingly). Then open a new CC session on DUNIN7-M4 and paste:


Read /Users/dunin7/loomworks-engine/docs/phase-impl-notes/loomworks-phase-53-step-0-inspection-brief-v0_1.md

Run all ten verifications against the live codebase at /Users/dunin7/loomworks-engine. Phase 52 close baseline: tag phase-52-jurisdiction-routing at engine 69aecdc; main one commit ahead at 14e5a7f. Substrate 2,137 tests passed, 25 skipped, Alembic 0064. Working tree expected clean on main.

Reading order before running: loomworks-phase-53-scoping-note-v0_1.md (in project knowledge); current-status-manifest-v0_37.md (in project knowledge); phase-52-cr-jurisdiction-routing-v0_1.md (engine repo docs/phase-crs/); phase-31-cr-conversational-engagement-creation-v0_1.md (engine repo docs/phase-crs/); Phase 16 CR + addendum (engine repo docs/phase-crs/); phase-38-cr-specification-grammar-declaration-v0_1.md (engine repo docs/phase-crs/); Phase 25 CR + FORAY amendment (engine repo docs/phase-crs/); loomworks-queued-directions-and-deferred-work-v0_7.md sections 1.1 and 1.2 (in project knowledge); this brief.

Produce findings at /Users/dunin7/loomworks-engine/docs/phase-impl-notes/phase-53-step-0-findings-v0_1.md.

One section per verification. Each section: verdict (HOLDS / PARTIALLY HOLDS / BREAKS / INCONCLUSIVE; per-verdict variants per brief §4), evidence (file paths, line numbers, function signatures, exact strings as found; enumerated lists where the verification asks for enumeration), implication for scoping note (carry / naming-only divergence / architectural amendment).

V1, V4, V5, and V10 explicitly require enumeration of call-sites, construction-sites, induction-loop entries, or routes. If any enumeration produces a count materially different from what the scoping note assumes, surface the discrepancy as a finding worth recording even if the verdict otherwise lands HOLDS — this is the lens-bounded scoping evidence cascade methodology candidate's second-instance test.

Do not propose remediation. Do not edit the scoping note. Do not start CR drafting or implementation.

Report back with the findings document.

The receiving CC session reads the brief, runs the verifications, produces the findings document, and reports.

7. Companion documents

loomworks-phase-53-scoping-note-v0_1.md — parent scoping note. CC reads this first (the brief presupposes its decomposition and Operator-confirmed P53-Dn settings).
current-status-manifest-v0_37.md — current substrate state and named principles; Section 2 lens-bounded-scoping-evidence-cascade methodology candidate context.
phase-52-cr-jurisdiction-routing-v0_1.md (engine repo docs/phase-crs/) — most recent CR; Memory event registration pattern V7 verifies; FORAY hook conventions V9 verifies.
phase-31-cr-conversational-engagement-creation-v0_1.md (engine repo docs/phase-crs/) — existing conversational creation flow; V5 verifies the as-shipped substrate.
Phase 16 CR + Phase 16 addendum (engine repo docs/phase-crs/) — ExtractionSkillRegistry shape V1 verifies; per-engagement key store pattern context.
phase-38-cr-specification-grammar-declaration-v0_1.md (engine repo docs/phase-crs/) — declare-and-register pattern V3 verifies.
Phase 25 CR + Phase 25 FORAY amendment (engine repo docs/phase-crs/) — engagement creation endpoints; seed schema V4 verifies; FORAY attestation seam V9 verifies.
loomworks-queued-directions-and-deferred-work-v0_7.md §1.1 + §1.2 — engagement creation arc framing; the "materializer registry" trajectory note V2 resolves.
phase-52-step-0-findings-v0_1.md (engine repo docs/phase-impl-notes/) — Phase 52 Step 0 precedent findings shape.
loomworks-phase-52-step-0-inspection-brief-v0_1.md — precedent for this brief's structure.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks Phase 53 Step 0 Inspection Brief — v0.1 — 2026-05-10