Loomworks — Phase 51 Step 0 Inspection Brief

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

1. What this is

Pre-CR live-codebase verification for Phase 51 — Marketing Site (new repo) + SMTP automation for form-initiated grants + Companion-driven email composition + Phase 45 end-to-end integration testing.

Phase 51 scoping note v0.1 records the build shape and architectural decisions (Option A; P51-D1 through P51-D13). Several of those decisions rest on assumptions about what the Phase 48 SMTP plumbing, the Phase 50 seam, and the Phase 50 endpoint 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 51 = engine + Operator Layer + new marketing repo, three sub-arcs). If P51-Shape-D1 redirects after CC reports, scoping v0.2 reshapes and a fresh Step 0 brief lands for the new shape. v0.1 of this brief is right for Option A.

2. Reading order before running

CC reads in this order before starting verifications:

1. loomworks-phase-51-scoping-note-v0_1.md (parent document; in project knowledge).
2. current-status-manifest-v0_36.md (in project knowledge — substrate state, named principles, residues).
3. phase-50-cr-companion-as-authority-and-public-form-v0_1.md (engine repo docs/phase-crs/; the CR Phase 51 extends).
4. phase-50-implementation-notes-v0_2.md (engine repo docs/phase-impl-notes/; the §7 13-item carry-forward and §8 build findings).
5. phase-48-cr-credit-completion-and-operator-sign-in-v0_1.md §9 (engine repo docs/phase-crs/; the SMTP plumbing Phase 51 extends).
6. This brief.

3. Baseline state to verify

Before running verifications, CC confirms the substrate is at the expected baseline. Phase 50 close per session handoff §6:

• Engine repo: DUNIN7/loomworks-engine, tag phase-50-companion-as-authority-and-public-form at engine c01124d (annotated tag object 67ba251). 2,095 tests passed, 26 skipped, Alembic head 0064. Working tree clean on main. Pushed to origin.
• Operator Layer repo: DUNIN7/loomworks, tag phase-50-companion-as-authority-and-public-form at frontend e4c09e0 (annotated tag object fd8177a). 139 vitest passed, 29 test files, 11 prerendered routes. eslint/tsc/build clean.
• Workshop repo: DUNIN7/loomworks-ui, unchanged from Phase 48 baseline. Not in Phase 51 scope.
• Marketing repo: DUNIN7/loomworks-marketing does NOT yet exist. Phase 51 sub-arc 3 creates it at Step 4. The brief's verifications all run against the engine and Operator Layer.

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

4. Eight 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 — Phase 48 SMTP wiring shape

Ask. Confirm loomworks.email.service.send_email(to, template_name, context) (Phase 48 CR §9) — module location, current signature, task-lifecycle pattern, error-handling posture. Phase 51 sub-arc 1 Step 1 reuses this surface to send form-initiated-grant emails. The scoping note §5.1.1 assumes the API is reusable as-is, called from inside the seam after the grant transaction commits, fire-and-forget with error-logging on send failure.

Look at.

• Engine: the email module tree under src/loomworks/email/ — provider.py, smtp_relay.py, templates.py, service.py (per Phase 48 CR §9.2).
• The current call site in POST /admin/grants (the operator-curated path that uses claim_email.txt) — confirms the post-write fire-and-forget integration shape.
• The background-task pattern Phase 48 used (per Phase 48 CR §9.1 / pre-flight item 15).

Evidence expected.

• File path and current signature of send_email.
• Whether the existing wiring on POST /admin/grants is invoked synchronously inside the request handler, scheduled as a fire-and-forget background task, or some other shape.
• The provider-registry shape (get_email_provider() + EmailProvider Protocol per Phase 48 CR §9.3).
• The current default backend (smtp_relay per Phase 48 §9.4).

Verdict criteria.

• HOLDS. send_email API matches scoping note §5.1.1's read; sub-arc 1 Step 1 wires the seam call to the existing service without changes to the email module. CR §5.1.1 carries.
• PARTIALLY HOLDS. The API is callable but the task-lifecycle integration shape diverges from the scoping note's read (e.g., the Phase 48 callers register sends through a different background-task system than the seam can reach from inside its task). Reports the specifics; CR §5.1.1 sketch updates.
• BREAKS. The send_email API has shifted since Phase 48 in a way that requires re-design before the seam wiring fits, or the email module isn't where Phase 48 CR placed it. Scoping note v0.2 absorbs.
• INCONCLUSIVE. Module exists but the task-lifecycle posture can't be assessed without running the Phase 48 path end-to-end.

4.2 Verification 2 — Seam post-grant-write hook surface for email composition

Ask. Confirm seam.issue_grant(grant_kind='form_initiated', initiated_by=None, recipient_email, asset_id, amount, ...) (Phase 50 CR §13) — module location, current signature, post-write extensibility. Phase 51 sub-arc 1 Step 2 inserts a synchronous Companion-driven email composition step between the grant-row write and the fire-and-forget send. The scoping note §5.1.3 frames this as a synchronous inline composition (NOT a Phase 45 dispatch — there's no held artifact, no approval gate, per P51-D2). The composition output feeds send_email.

Look at.

• Engine: the seam module — seam.py or wherever issue_grant lives.
• The current issue_grant body for grant_kind='form_initiated' (Phase 50) and grant_kind='operator_curated' (Phase 47/48) — confirms what each path currently does post-write.
• Any post-write hook surface or extension point (callbacks, observer registration, lifecycle stage) the seam already provides.

Evidence expected.

• File path and complete current signature of issue_grant.
• The structure of the current post-write phase for both grant_kind values — what fires, in what order, what's awaited vs scheduled.
• Whether an explicit "post-write hook" extension surface exists or whether Phase 51's email composition lands as new inline code in the relevant grant_kind branch.
• Confirms the call site of <GrantDecisionApprovalCard> Approve eventually reaches seam.issue_grant with the expected payload.

Verdict criteria.

• HOLDS. The seam has a clean place to insert the synchronous composition + send_email call between row-write commit and end-of-function. CR §5.1.3 carries the inline-composition design as drafted.
• HOLDS via post-write hook. The seam already exposes a post-write hook surface (callbacks, observer pattern); Phase 51's composition + send registers as a hook rather than as inline code. Cleaner integration; updates CR §5.1.3 to use the hook.
• PARTIALLY HOLDS. The seam's structure works but inserting inline composition introduces concerns the scoping note didn't anticipate (e.g., transaction boundary worries, error-recovery semantics if composition fails between row-write and send). Reports specifics.
• BREAKS. The seam's structure has shifted in a way that requires re-design before the composition step fits, or the form-initiated path doesn't land in the seam at all. Scoping note v0.2 absorbs.
• INCONCLUSIVE. Structure is identifiable but composition fit can't be assessed without running the Phase 50 path end-to-end.

4.3 Verification 3 — Voice template loader for grant_email.md

Ask. Confirm the voice template loader pattern Phase 49/50 used (prompts/credit_voice/tier_drop.md, near_exhaustion.md, exhaustion_choice.md, grant_proposal.md) — directory path, loading function, variable substitution mechanism, AI-invisibility carve-out comment shape. Phase 51 sub-arc 1 Step 2 lands grant_email.md as the fifth template in the family. The scoping note §5.1.2 assumes sibling-pattern composition with the same loader and carve-out comment.

Look at.

• Engine: the prompts/credit_voice/ directory and the four existing templates.
• The voice composition module that loads them (likely loomworks/credit/companion_intelligence/voice_composition.py per Phase 50 scoping reads).
• The signature of the loading function and the variable-substitution mechanism (file read + format-string, Jinja2, or other).

Evidence expected.

• Actual directory path of the credit_voice templates as Phase 50 shipped.
• Loading-function signature and variable-substitution mechanism in voice composition.
• AI-invisibility carve-out comment shape at top of each existing template (the angle-bracket placeholder convention from Phase 50 Finding 4 — confirms <placeholder> form is in use).
• The set of variables grant_proposal.md currently consumes (the Phase 50 template's variable surface is the closest analog for grant_email.md).

Verdict criteria.

• HOLDS. Loader pattern and template family conventions match scoping note §5.1.2's read. grant_email.md slots in as a fifth sibling.
• PARTIALLY HOLDS. Loader works but the variable-substitution mechanism or carve-out comment format differs in a way that requires CR §5.1.2 to update. Reports actual shape.
• BREAKS. Voice composition module structure differs from the scoping note's read; scoping note v0.2 absorbs.
• INCONCLUSIVE. Path is found but loading pattern is unclear without runtime exercise.

4.4 Verification 4 — Phase 45 dispatcher testability with fixture-replayed LLM

Ask. Confirm the Phase 45 dispatcher (register_action_dispatcher, process_approval, process_decline per Phase 49 bimodal dispatch) is exercisable in tests with fixture-replayed LLM responses through the real dispatcher path. Phase 51 sub-arc 1 Step 3 establishes end-to-end integration test coverage for grant-decision dispatch (closing the substrate-tests-with-mocked-LLM gap from Phase 50 impl notes §7). The scoping note P51-D4 specifies fixture-replayed LLM through the real dispatcher (NOT real LLM in tests, NOT mocked dispatcher with real LLM).

Look at.

• Engine: the Phase 45 dispatch module.
• The Phase 50 grant-decision dispatcher's existing test surface — what was mocked vs what ran for real.
• The LLM client interface and any existing fixture / replay / cassette pattern (vcr.py, responses, custom replay, or none).
• The dispatcher's invocation entry point — what process_approval / equivalent calls when a grant_request_received event arrives at the registered delegation_required=True dispatcher.

Evidence expected.

• File path and current signatures of register_action_dispatcher, process_approval, process_decline.
• The current Phase 50 dispatcher tests' mocking posture (which functions are patched, what they return).
• Whether an LLM client interface exists at a clean substitution boundary (e.g., a single llm_client.complete(...) call site that test fixtures can replace) or whether LLM access is scattered.
• Any existing fixture-replay infrastructure that Phase 51 Step 3 can build on.

Verdict criteria.

• HOLDS. Dispatcher invocation path runs against a clean LLM substitution boundary; fixture-replay infrastructure either exists or is straightforward to introduce. Sub-arc 1 Step 3's 8–12 tests slot in cleanly.
• PARTIALLY HOLDS. The dispatcher path is testable end-to-end but the LLM substitution requires either touching multiple call sites or building substitution scaffolding that the scoping note didn't size. Reports specifics.
• BREAKS. The dispatcher path can't be exercised end-to-end without real LLM access (e.g., the LLM call is inlined in a way that doesn't admit fixture replay, or the Phase 45 dispatch doesn't invoke composition through a substitutable interface). Scoping note v0.2 absorbs — possibly redirecting Step 3 to a different test posture (real LLM in a marked-slow test surface, or skipping the e2e gap to a future phase).
• INCONCLUSIVE. Substitution boundary is identifiable but the fixture-replay shape can't be designed without running an exploratory test.

4.5 Verification 5 — Phase 50 endpoint body shape and jurisdiction-field tolerance

Ask. Confirm the POST /authority/grant-request request body shape as Phase 50 shipped, specifically pydantic validation strictness and tolerance for additional fields. Phase 51 sub-arc 3 Step 5 introduces a jurisdiction question on the marketing-site form (per P51-D7). The scoping note recommends adding jurisdiction as an optional field on the existing endpoint (option (a) — additive, no breaking change) over remapping onto the existing source field (option (b)). This verification produces the evidence base for that decision.

Look at.

• Engine: the POST /authority/grant-request route handler and its pydantic body model.
• The pydantic model's Config or model_config — extra = 'forbid' vs 'allow' vs 'ignore'.
• The existing source field's current usage — whether it's freeform string or has implicit conventions (e.g., 'marketing-site' / 'conference' / 'referral' per Phase 50 CR §10.3).
• How the body fields propagate into the grant_request_received Memory event payload — confirms a new optional field would be carried through to the Companion's reading surface.

Evidence expected.

• Pydantic model definition with current field set, types, and extra handling.
• Whether adding an optional jurisdiction: str | None = None field is one-line additive or requires touching downstream Memory-event payload construction.
• Current source field semantics — strict enum, freeform, or convention-only.

Verdict criteria.

• HOLDS for option (a). Endpoint accepts additive optional fields cleanly; jurisdiction lands as a one-line model addition + payload propagation. CR §5.3.4 carries the option (a) path.
• HOLDS for option (b). The pydantic model strictly forbids extras and refactoring it would touch surfaces beyond Phase 51's scope; the cleaner Phase 51 alpha posture is to remap jurisdiction onto source (e.g., source: 'marketing-site:US' | 'marketing-site:EU' | 'marketing-site:OTHER'). CR §5.3.4 shifts to option (b).
• PARTIALLY HOLDS. Either option is workable but with constraints the scoping note didn't anticipate (e.g., adding the field requires a Memory-event-payload schema update tracked through Phase 38 declare-and-register). Reports specifics.
• BREAKS. Neither option fits cleanly without architectural amendment. Scoping note v0.2 absorbs.
• INCONCLUSIVE. Endpoint is identifiable but pydantic posture and downstream propagation can't be assessed without running fixture submissions.

4.6 Verification 6 — CORS env-var posture for marketing-site domain registration

Ask. Confirm loomworks_cors_origins env-var allowlist mechanism (Phase 50 V9 — lowercase config field per scoping v0.2 absorption). Phase 51 sub-arc 3 needs the marketing site's eventual production domain (loomworks.com per deployment strategy v0.2, or a staging Cloudflare Pages preview URL for alpha) added to the allowlist. The scoping note §9 halt-threshold flagged this as Step 0 verification before relying on it.

Look at.

• Engine: the FastAPI app construction site where Phase 50 wired LOOMWORKS_CORS_ORIGINS (or loomworks_cors_origins) reading.
• The env-var config field declaration (likely in a settings / config module).
• The CORS middleware registration logic — whether it accepts a comma-separated list, a JSON array, or another shape.
• Any existing CORS-related configuration the marketing site domain would compose against.

Evidence expected.

• Exact config field name (lowercase per Phase 50 V9 absorption — confirm).
• Comma-separation or other format for multiple origins.
• The dev/test posture when the env var is unset (Phase 50 §10.2 specified existing permissive behavior preserved when unset).
• Whether wildcards or pattern-match origins are supported (e.g., *.pages.dev for Cloudflare Pages preview URLs).

Verdict criteria.

• HOLDS. Env var accepts the marketing site's production and staging domains as comma-separated entries; sub-arc 3 Step 5 production-wiring just adds the domain. CR carries the simple form.
• PARTIALLY HOLDS. Mechanism works but doesn't accommodate Cloudflare Pages preview URLs (which use generated subdomains per deploy) without explicit pattern support. Reports specifics; sub-arc 3 may need a production-only CORS posture for alpha rather than preview-URL coverage.
• BREAKS. Mechanism diverges from Phase 50 V9 absorption in a way that requires re-derivation. Scoping note v0.2 absorbs.
• INCONCLUSIVE. Mechanism is identifiable but pattern-match support can't be assessed without runtime exercise.

4.7 Verification 7 — <GrantDecisionApprovalCard> Approve response shape

Ask. Confirm <GrantDecisionApprovalCard> (Phase 50 frontend; Operator Layer repo) — component file location, Approve action's call shape, response shape that the component reads back from the seam. Phase 51 sub-arc 2 is conditional on whether the response shape needs adjustment to surface email-send status (P51-D2 holds → likely no Operator Layer change; P51-D2 reverses to second-approval-gate → significant Operator Layer work). The scoping note §5.2 estimates 0–8 vitest depending on this.

Look at.

• Operator Layer: <GrantDecisionApprovalCard> component file (Phase 50 CR §13 named it as a sibling to <ProposalApprovalCard>).
• The Approve handler's call into the seam — what it sends, what it expects back.
• The response-handling code path — what fields the component currently reads.
• Whether the existing surface displays / would benefit from displaying email-send status (e.g., "email sent" / "email failed, claim URL: …" / etc.) under the P51-D2 post-approval-automatic posture.

Evidence expected.

• File path and current implementation sketch of <GrantDecisionApprovalCard>.
• Approve and Decline action shapes (what they POST and what they expect).
• Current surface chrome around success/failure feedback after Approve.
• Any vitest tests that pin the current response-shape contract.

Verdict criteria.

• HOLDS, sub-arc 2 empty. Existing surface accommodates the P51-D2 post-approval-automatic posture without changes. Email-send status either isn't needed in the response or surfaces through a separate channel (e.g., the Operator's notification stream). Sub-arc 2 = 0 vitest.
• HOLDS with minor surface adjustment. Existing surface accommodates the posture but would benefit from a small adjustment (e.g., one new field in the response payload, one component string addition for "email sent" feedback). Sub-arc 2 = 1–3 vitest.
• PARTIALLY HOLDS. Existing surface needs a more substantial adjustment under P51-D2 (e.g., the Approve handler currently doesn't await any post-approval fire-and-forget signal, and surfacing email-send status requires shape change). Reports specifics.
• BREAKS. Existing surface incompatible with P51-D2's posture; either P51-D2 reverses or scoping note v0.2 absorbs the architectural delta.
• INCONCLUSIVE. Surface is identifiable but P51-D2 fit can't be assessed without running the Phase 50 Approve path end-to-end.

4.8 Verification 8 — Phase 50 impl notes §7 carry-forward items 12 and 13

Ask. The current-status manifest v0.36 §1 references "three additional items from impl notes v0.2 §7 whose specifics are in the engine-repo notes," and Phase 51 scoping note v0.1 §11 explicitly defers the items 12 and 13 disposition to Step 0 V8. CC reads phase-50-implementation-notes-v0_2.md §7 and reports the verbatim phrasing of the three additional items (one of which — Phase 45 end-to-end integration testing — is already absorbed into Phase 51 scoping as item 4 of the carry-forward; the other two are unenumerated).

Look at.

• Engine repo: docs/phase-impl-notes/phase-50-implementation-notes-v0_2.md, §7 carry-forward.

Evidence expected.

• Verbatim text of the three additional items §7 surfaces beyond CR §20's ten items.
• For each, a one-sentence read on whether it folds into Phase 51 scope, defers to Phase 52+, or is continuing parallel work that doesn't need phase-shaping.

Verdict criteria.

• NOT NEEDED. Manifest references "three additional items" but §7 actually carries only one (the Phase 45 e2e integration testing item, already absorbed into Phase 51). Reports the discrepancy; Phase 51 scope unchanged.
• HOLDS as Phase 51 absorbed. All three items fold into Phase 51 scope as v0.1 currently sketches. Reports the verbatim phrasing for v0.2 to absorb explicitly.
• PARTIALLY HOLDS. One or two items belong in Phase 51; one or two defer. Reports the disposition recommendation.
• DEFERS BEYOND PHASE 51. All three items are Phase 52+ candidates. Phase 51 scope unchanged; Phase 52+ carry-forward gains them.
• INCONCLUSIVE. Impl notes file is missing or §7 is structured differently than expected; reports the obstacle.

5. After verification

CC produces phase-51-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 5 and 7 also accept the per-option HOLDS variants; verification 8 also accepts NOT NEEDED), evidence (file paths, line numbers, function signatures, exact strings as found), implication for scoping note (carry / naming-only divergence / architectural amendment).

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

• All HOLDS or naming-only divergences. Proceed to Phase 51 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-51-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-51-step-0-inspection-brief-v0_1.md

Run all eight verifications against the live codebase at /Users/dunin7/loomworks-engine. For verification 7, also read /Users/dunin7/loomworks (Operator Layer). Phase 50 tags for reference: phase-50-companion-as-authority-and-public-form at engine c01124d / frontend e4c09e0.

Reading order before running: loomworks-phase-51-scoping-note-v0_1.md (in project knowledge); current-status-manifest-v0_36.md (in project knowledge); phase-50-cr-companion-as-authority-and-public-form-v0_1.md (engine repo docs/phase-crs/); phase-50-implementation-notes-v0_2.md (engine repo docs/phase-impl-notes/); phase-48-cr-credit-completion-and-operator-sign-in-v0_1.md §9 (engine repo docs/phase-crs/); this brief.

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

One section per verification. Each section: verdict (HOLDS / PARTIALLY HOLDS / BREAKS / INCONCLUSIVE; verifications 5 and 7 also accept per-option HOLDS variants; verification 8 also accepts NOT NEEDED), evidence (file paths, line numbers, function signatures, exact strings as found), 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-51-scoping-note-v0_1.md — parent scoping note. CC reads this first (the brief presupposes its draft sketches and Operator-decision settings).
• current-status-manifest-v0_36.md — current substrate state and named principles.
• phase-50-cr-companion-as-authority-and-public-form-v0_1.md (engine repo docs/phase-crs/) — Phase 50 CR (active); reference for §13 dispatcher pattern, §10.3 endpoint shape, §10.2 CORS posture.
• phase-50-implementation-notes-v0_2.md (engine repo docs/phase-impl-notes/) — Phase 50 build-record; §7 13-item carry-forward, §8 build findings.
• phase-48-cr-credit-completion-and-operator-sign-in-v0_1.md §9 (engine repo docs/phase-crs/) — Phase 48 SMTP plumbing CR; relevant for Verification 1.
• phase-50-step-0-findings-v0_1.md (engine repo docs/phase-impl-notes/) — Phase 50 Step 0 precedent findings shape.
• loomworks-phase-50-step-0-inspection-brief-v0_1.md — precedent for this brief's structure.

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