Loomworks — Phase 52 Step 0 Inspection Brief

Version. 0.1 Date. 2026-05-10 Status. Pre-CR scoping evidence brief. Hands to CC. Mirrors loomworks-phase-51-step-0-inspection-brief-v0_1.md. Author. Claude.ai. Operator: Marvin Percival. Companion document. loomworks-phase-52-scoping-note-v0_1.md (parent — the brief presupposes its sketches and §10 candidate verification list).

1. What this is

Pre-CR live-codebase verification for Phase 52 — Authority-side jurisdiction routing logic (Item 3 of the Phase 51 §19 carry-forward) as the unconditional substrate core. Items 1 and 2 stay deferred-pending-trigger; operational items (engine deployment, mailbox provisioning, cloudflared upgrade) proceed as a parallel non-CR track.

Phase 52 scoping note v0.1 records the build shape and architectural decisions (Option A; P52-D1 through P52-D8). Several of those decisions rest on assumptions about what the Phase 51 seam, the Phase 50 endpoint, the Phase 38 declare-and-register pattern, and the engine settings module look like as actually shipped. The scoping note carries [CC 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 A is the working shape (Phase 52 = engine substrate sub-arc 1 only by default; sub-arcs 2 and 3 empty). If P52-D2 redirects after V1 reports, scoping v0.2 reshapes around the actual seam shape. v0.1 of this brief is right for Option A.

One verification (V6) is a documentation read rather than a code verification: CC reads phase-51-implementation-notes-v0_2.md §11 addendum and reports the verbatim phrasing of the findings 7 and 8 family. v0.2 of the scoping note absorbs the verbatim text into §13 trajectory note and §4 P52-D5.

2. Reading order before running

CC reads in this order before starting verifications:

1. loomworks-phase-52-scoping-note-v0_1.md (parent document; in project knowledge).
2. Highest-versioned current-status manifest in project knowledge (v0.36 at session open; v0.37 if absorbed).
3. phase-51-cr-marketing-site-and-companion-email-v0_1.md (engine repo docs/phase-crs/; the CR Phase 52 extends — especially §5 Companion-driven email composition, §10 e2e test posture).
4. phase-51-implementation-notes-v0_2.md (engine repo docs/phase-impl-notes/; for §11 addendum read in V6 and §8 build findings as context).
5. phase-50-cr-companion-as-authority-and-public-form-v0_1.md (engine repo docs/phase-crs/; especially §10.3 endpoint body shape — the jurisdiction field flow V5 confirmed in Phase 51).
6. phase-38-cr-specification-grammar-declaration-v0_1.md (engine repo docs/phase-crs/; the declare-and-register pattern V3 verifies).
7. This brief.

3. Baseline state to verify

Before running verifications, CC confirms the substrate is at the expected baseline. Phase 51 close per session prompt:

• Engine repo: DUNIN7/loomworks-engine, tag phase-51-marketing-site-and-companion-email at engine 876ff66 (annotated tag object 2065637). main one commit ahead at 25294ca (impl notes v0.2 §11 addendum). Substrate 2,121 tests passed, 25 skipped. Working tree clean on main. Pushed to origin.
• Operator Layer repo: DUNIN7/loomworks, tag phase-51-marketing-site-and-companion-email at frontend e4c09e0 (marker tag on the Phase 50 commit per Phase 51 V7 — sub-arc 2 was empty). 139 vitest passed, eslint/tsc/build clean (unchanged from Phase 50 baseline). Not in Phase 52 scope by default.
• Marketing repo: DUNIN7/loomworks-marketing, tag phase-51-marketing-site-and-companion-email at bf2f694 (annotated tag object 76071b0). main one commit ahead at 78c26fa (Astro adapter fix). Live at https://loomworks.doneinseven.com. Not in Phase 52 scope.
• Workshop repo: DUNIN7/loomworks-ui, unchanged from Phase 48 baseline. Not in Phase 52 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, marketing site not live), CC stops at the start and reports before running any verifications.

4. Six 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 — Email composition seam current shape (post-Phase-51)

Ask. Confirm the as-shipped Phase 51 email composition seam — module location, current shape, exact location of the context-prep step (where recipient + grant context are assembled), and exact location of the claim_url construction. Phase 52 P52-D2 inserts a new routing-decision step between context-prep and claim_url construction so the destination-instance URL is available when claim_url is built. The scoping note §5.1.2 frames this insertion as a single new step in an existing sequence; v0.2 settles definitively against this verification's report.

Look at.

• Engine: the seam module — seam.py or wherever issue_grant(grant_kind='form_initiated', ...) lives (Phase 50 substrate; Phase 51 extended).
• The current issue_grant body for grant_kind='form_initiated' — confirms the current sequence: row-write commit → context-prep → template load → composition → claim_url construction → send_email fire-and-forget.
• The Phase 51 §5.1.3 inline-composition design as actually shipped — exact line range, function name(s), variable names where claim_url is built.
• Whether the context-prep step pulls form-submission Memory event data or works against direct-call payload (matters for V2).

Evidence expected.

• File path and line range of the form-initiated branch in issue_grant.
• The current sequence of steps as code, with line numbers.
• Exact location where claim_url is constructed (function call, string format, base URL source).
• Exact location where context for the email template is assembled.
• Any existing extension points (callbacks, observer registration) that could absorb the routing-decision step without changing the inline sequence.

Verdict criteria.

• HOLDS. Sequence matches the scoping note's read; routing-decision step inserts cleanly between context-prep and claim_url construction. CR §5.1.2 carries.
• HOLDS via existing extension point. Seam already exposes a hook (callback, observer, lifecycle stage) that the routing-decision step registers against rather than landing as inline code. Cleaner integration; updates CR §5.1.2 to use the hook.
• PARTIALLY HOLDS. Sequence is structurally similar but specific assumptions in the scoping note diverge (e.g., context-prep and claim_url construction are interleaved rather than sequential; the base URL is hardcoded inside the template rather than passed via context). Reports the specifics.
• BREAKS. Phase 51 actually shipped a different shape than v0.2 absorbed; routing-decision step requires re-architecture. Scoping v0.2 absorbs.
• INCONCLUSIVE. Seam exists but the inline sequence is too entangled for a confident insertion-point read without running the path.

4.2 Verification 2 — jurisdiction field flow from form submission to seam

Ask. Confirm the Phase 51 V5-implemented additive optional jurisdiction: str | None = None field on POST /authority/grant-request flows through to where the routing-decision step needs it. Phase 51 records the value in the form-submission Memory event payload (per Phase 51 P51-D7 / V5); Phase 52's routing-decision step reads it. The scoping note §5.1.2 assumes the value is available at the seam's routing-decision-step location either via direct-call payload propagation or via Memory event read.

Look at.

• Engine: the POST /authority/grant-request endpoint handler (Phase 50 substrate).
• The form-submission Memory event payload schema — does it carry jurisdiction, and if so, under what key?
• The path from endpoint handler → Memory event creation → grant-decision dispatcher → <GrantDecisionApprovalCard> Approve handler → seam.issue_grant. At which step is jurisdiction last visible, and does the seam reach it from inside its function body?
• The Phase 50 grant-decision dispatcher's payload shape (the held assertion that the Approve handler commits against) — does it carry jurisdiction forward from the form submission?

Evidence expected.

• File path and line of the endpoint handler's request body type / pydantic model that carries jurisdiction.
• File path and line where jurisdiction is written into the Memory event payload.
• File path and line where jurisdiction enters the seam's stack (function parameter, Memory read, or held-assertion field).
• A trace, in three or four lines: form POST → (file:line) → Memory event payload → (file:line) → held assertion → (file:line) → seam call.

Verdict criteria.

• HOLDS via direct propagation. jurisdiction flows through the call chain as a function parameter (form POST → endpoint → dispatcher → Approve handler → seam). Routing-decision step reads it from the seam's own scope. Cleanest path.
• HOLDS via Memory event read. jurisdiction is stored in the form-submission Memory event payload; the routing-decision step reads it via Memory query inside the seam. CR §5.1.2 adds the read; small additional substrate work.
• HOLDS via held-assertion field. jurisdiction is on the Phase 50 held assertion that the Approve handler commits; the seam reads it from the assertion. Slight wiring-shape change to scoping note's read; otherwise carries.
• PARTIALLY HOLDS. jurisdiction is captured at the endpoint but doesn't propagate to where the seam can reach it; routing-decision step needs a new propagation path. Reports the gap; scoping v0.2 absorbs.
• BREAKS. jurisdiction was not actually wired into the form-submission flow as Phase 51 V5 implied; Phase 52's routing-decision step has nothing to route on. Scoping v0.2 reshapes (likely defers Phase 52 until the gap is closed in a sub-step).
• INCONCLUSIVE. The flow is identifiable but the exact propagation step where the seam reads it can't be confirmed without running the path.

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

Ask. Confirm the Phase 38 specification grammar declaration pattern (or its closest in-substrate kin — Phase 49's ensure_reconciliation_specialists_declared is the noted alternative reference). Phase 52's P52-D1 mirrors the pattern: a registry that accepts register_jurisdiction_route(jurisdiction, destination_instance) calls and exposes resolve_destination(jurisdiction) -> DestinationInstance. The scoping note assumes the existing registry mechanism gives Phase 52 a clean template; v0.2 settles definitively against the verbatim signatures CC reports.

Look at.

• Engine repo: phase-38-cr-specification-grammar-declaration-v0_1.md for the original pattern shape.
• The actual substrate location where the pattern is implemented — module path, registry container, register / resolve function signatures, registration call sites.
• Phase 49's ensure_reconciliation_specialists_declared (or whatever the function is actually named in the live code) for the closest sibling pattern in the credit-system arc.
• Any other in-substrate registries that follow the declare-and-register shape (extraction skills registry, render specialists registry, etc.).

Evidence expected.

• File paths and verbatim function signatures of one or more existing register/resolve pairs.
• The container shape (module-level dict, class with a registry attribute, etc.).
• How registration is called (at module import, at app startup, lazily on first lookup).
• How resolution handles unknown keys (raise, return None, return default).

Verdict criteria.

• HOLDS. Existing pattern is reusable as-is; Phase 52's routing-skill registry mirrors the verbatim signatures of an existing register/resolve pair. CR §5.1.1 names the specific sibling pattern Phase 52 mirrors.
• HOLDS with naming-only divergence. Pattern shape is the same; specific function / parameter names differ from the scoping note's sketch. Naming-only; CR §5.1.1 adopts the in-substrate naming.
• PARTIALLY HOLDS. Pattern exists but with some structural property the scoping note's read didn't anticipate (e.g., the registry is class-based with init-time registration; or unknown-key resolution raises rather than returning a default). Reports the specifics.
• BREAKS. No declare-and-register pattern exists in the substrate, or the existing patterns aren't reusable for Phase 52's needs. Scoping v0.2 absorbs (likely Phase 52 ships the pattern itself rather than reusing).
• INCONCLUSIVE. Patterns exist but the right sibling for Phase 52 to mirror isn't determinable from the codebase read alone.

4.4 Verification 4 — Memory event schema registration

Ask. Confirm the registration mechanism for new Memory event types — specifically, the schema and call site Phase 52's jurisdiction_routing_decided event mirrors. The closest sibling is Phase 50's grant_request_received form-submission event. The scoping note §5.1.3 assumes the registration shape is reusable; v0.2 confirms against the verbatim phrasing CC reports.

Look at.

• Engine: where Memory event types are registered (likely a module enumerating event-kind literals, plus a schema registry mapping kinds to pydantic models).
• The grant_request_received event registration (Phase 50) — exact location, schema model, fields.
• Adjacent event registrations (Phase 50 grant_decision_proposal, Phase 49 reconciliation events) for sibling shape.
• Any naming conventions for event-kind literals (e.g., past-tense verb form, snake_case, namespacing).

Evidence expected.

• File path and verbatim registration of grant_request_received.
• The pydantic model fields and their types.
• Where the event-kind literal is enumerated (e.g., a Literal type alias, an enum, a string constant).
• File path and any other registration sites for new event types Phase 52 needs to add.

Verdict criteria.

• HOLDS. Registration shape is reusable; Phase 52's jurisdiction_routing_decided lands as a parallel registration with field shape per the scoping note's §4 P52-D3. CR §5.1.3 carries.
• HOLDS with naming-only divergence. Same registration shape; the in-substrate convention dictates a slightly different event-kind literal (e.g., routing_decided rather than jurisdiction_routing_decided, or vice versa). Naming-only; CR §5.1.3 adopts.
• PARTIALLY HOLDS. Registration mechanism exists but with structural properties Phase 52's read didn't anticipate (e.g., schema lives in a different module from event-kind enumeration). Reports the specifics.
• BREAKS. Memory event type registration mechanism has shifted in Phase 51 from what the scoping note assumes. Scoping v0.2 absorbs.
• INCONCLUSIVE. Registration mechanism is identifiable but the exact mirror Phase 52 should follow isn't clear without a deeper read.

4.5 Verification 5 — Settings field shape for the Authority instance URL

Ask. Confirm whether a settings field for the Authority instance URL exists today, and if so, where it lives and what its naming convention is. Phase 52's routing-skill default registration (P52-D1: all jurisdictions → Authority) uses the field as the destination-instance URL source. The scoping note §5.1.1 sketches loomworks_authority_instance_url provisionally; v0.2 settles definitively against what V5 reports.

Look at.

• Engine: the settings module (likely settings.py or a pydantic-settings class).
• Existing instance-URL-related settings (e.g., loomworks_authority_url, loomworks_api_url, loomworks_base_url, loomworks_public_url, or similar).
• The Phase 51 marketing-site CORS allowlist setting (loomworks_cors_origins per Phase 51 V6) — adjacent precedent for naming convention.
• Whether claim_url construction in Phase 51's seam uses a settings field for its base URL or a hardcoded string.

Evidence expected.

• Settings module file path.
• Verbatim field name(s) for any existing instance-URL setting, with their default values and types.
• Where the field is read in the Phase 51 seam (if it exists) — file path and line.
• Whether Phase 52 adds a new field, reuses an existing one, or extends an existing field's purpose.

Verdict criteria.

• HOLDS — exists and is reusable. A settings field for the Authority/base URL already exists; Phase 52's routing-skill default config reads it directly. CR §5.1.1 names the exact field. No new settings work.
• HOLDS — exists but needs a Phase 52 addition. A related field exists (e.g., loomworks_base_url) but the routing-skill semantics warrant a new field (loomworks_authority_instance_url or in-convention equivalent). Phase 52 adds the new field; small additional substrate work.
• PARTIALLY HOLDS. Claim_url construction in Phase 51's seam works against a hardcoded string or env-var-without-settings field; Phase 52's first job is to introduce the settings field. Reports the gap; CR §5.1.1 grows scope.
• BREAKS. Settings module shape has shifted in a way that affects how Phase 52 introduces / reads the field. Scoping v0.2 absorbs.
• INCONCLUSIVE. Settings module is identifiable but the right field shape for Phase 52 isn't determinable without a deeper read.

4.6 Verification 6 — Phase 51 impl notes v0.2 §11 addendum (findings 7 and 8 family)

Ask. Phase 52 scoping note v0.1 paraphrases the deploy-target-named-in-scoping cascade language based on the session prompt's framing; v0.2 sharpens against the actual finding text. CC reads phase-51-implementation-notes-v0_2.md §11 addendum and reports the verbatim phrasing of the findings 7 and 8 family (and any sibling findings in the same §11 addendum if more than two are present).

Look at.

• Engine repo: docs/phase-impl-notes/phase-51-implementation-notes-v0_2.md, §11 addendum.

Evidence expected.

• Verbatim text of finding 7 (full body, not just the headline).
• Verbatim text of finding 8 (full body, not just the headline).
• Verbatim text of any other findings in the §11 addendum beyond 7 and 8 (the user's prompt referenced "findings 7 and 8 family" — the family may include additional surfacings).
• For each, a one-sentence read on the implication for Phase 52 scope:
• Does the finding apply to Phase 52's substrate work?
• Does it apply to Phase 52's operational items handling?
• Does it apply to Phase 52's deploy-target-naming discipline (per scoping note §4 P52-D5 and §13 trajectory note)?

Verdict criteria.

• NOT NEEDED. §11 addendum exists but doesn't contain findings 7 and 8 family as the prompt describes (e.g., the addendum is unrelated work). Reports the discrepancy; scoping v0.1 §13 paraphrase stands; Operator clarifies.
• HOLDS as v0.1 paraphrased. Verbatim phrasing matches the v0.1 §13 trajectory note's gist; v0.2 absorbs the verbatim text into §13 for the Discovery-trajectory record.
• PARTIALLY HOLDS. Verbatim phrasing partly matches v0.1's paraphrase but adds nuance v0.1 didn't anticipate (e.g., specific cascades named that v0.1 didn't enumerate). v0.2 absorbs the verbatim text and adjusts §13 / §4 P52-D5.
• DIVERGES. Verbatim phrasing materially differs from v0.1's paraphrase; v0.2 reshapes the deploy-target-naming framing against the actual finding text. Reports the divergence.
• INCONCLUSIVE. §11 addendum exists but is structured in a way that makes finding identification non-obvious; reports the obstacle.

5. After verification

CC produces phase-52-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 1, 2, 3, 4, 5 also accept the per-option HOLDS variants; verification 6 also accepts NOT NEEDED, DIVERGES), evidence (file paths, line numbers, function signatures, exact strings as found, verbatim addendum text for V6), implication for scoping note (carry / naming-only divergence / architectural amendment).

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

• All HOLDS or naming-only divergences. Proceed to Phase 52 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.

6. CC kickoff prompt — paste-ready

Place this brief at /Users/dunin7/loomworks-engine/docs/phase-impl-notes/loomworks-phase-52-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-52-step-0-inspection-brief-v0_1.md

Run all six verifications against the live codebase at /Users/dunin7/loomworks-engine. Phase 51 tags for reference: phase-51-marketing-site-and-companion-email at engine 876ff66 / frontend e4c09e0 (marker) / marketing bf2f694. Engine main is at 25294ca (one commit ahead of tag, carrying impl notes v0.2 §11 addendum). Verification 6 reads the §11 addendum verbatim.

Reading order before running: loomworks-phase-52-scoping-note-v0_1.md (in project knowledge); current-status-manifest-v0_36.md (or v0.37 if available, in project knowledge); phase-51-cr-marketing-site-and-companion-email-v0_1.md (engine repo docs/phase-crs/); phase-51-implementation-notes-v0_2.md (engine repo docs/phase-impl-notes/); phase-50-cr-companion-as-authority-and-public-form-v0_1.md (engine repo docs/phase-crs/); phase-38-cr-specification-grammar-declaration-v0_1.md (engine repo docs/phase-crs/); this brief.

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

One section per verification. Each section: verdict (HOLDS / PARTIALLY HOLDS / BREAKS / INCONCLUSIVE; verifications 1-5 also accept per-option HOLDS variants; verification 6 also accepts NOT NEEDED, DIVERGES), evidence (file paths, line numbers, function signatures, exact strings as found; for V6, verbatim addendum text), implication for scoping note (carry / naming-only divergence / architectural amendment).

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-52-scoping-note-v0_1.md — parent scoping note. CC reads this first (the brief presupposes its sketches and Operator-decision settings).
• Highest-versioned current-status manifest in project knowledge — current substrate state and named principles.
• phase-51-cr-marketing-site-and-companion-email-v0_1.md (engine repo docs/phase-crs/) — Phase 51 CR (active); reference for §5 Companion-driven email composition (the seam V1 verifies), §10 e2e test posture, §19 carry-forward.
• phase-51-implementation-notes-v0_2.md (engine repo docs/phase-impl-notes/) — Phase 51 build-record; §11 addendum is V6's read target; §8 build findings as context.
• phase-50-cr-companion-as-authority-and-public-form-v0_1.md (engine repo docs/phase-crs/) — Phase 50 CR; §10.3 endpoint body shape (the jurisdiction field added in Phase 51 V5).
• phase-38-cr-specification-grammar-declaration-v0_1.md (engine repo docs/phase-crs/) — declare-and-register pattern V3 verifies.
• phase-51-step-0-findings-v0_1.md (engine repo docs/phase-impl-notes/) — Phase 51 Step 0 precedent findings shape.
• loomworks-phase-51-step-0-inspection-brief-v0_1.md — precedent for this brief's structure.

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