Loomworks — Phase 50 Step 0 Inspection Brief

Version. 0.1 Date. 2026-05-08 Audience. Claude Code (CC), executing on DUNIN7-M4. Purpose. Eight pre-CR-drafting verifications against the live codebase. CC produces a findings document; does not propose remediation, edit the scoping note, draft a CR, or implement.

1. What this is

The Phase 50 scoping note v0.1 (loomworks-phase-50-scoping-note-v0_1.md) settled three primary build items: Companion-as-Authority decision logic for grants (item 2), public credit-request form endpoint (item 3, engine half), Operator override path for conversion-credit asset_id (item 8). The scoping note's §8 listed eight pre-flight items where the draft sketches assume substrate shapes that have not been verified against the live codebase.

This brief is the verification ask. CC reads the scoping note and this brief, runs each of the eight verifications, and produces a findings document. The findings either confirm the scoping note's draft sketches (CR drafting can begin), reveal naming-only divergences (drafting absorbs them inline), or surface architectural friction (scoping note bumps to v0.2 to absorb).

CC does not propose remediation. CC does not edit the scoping note. CC does not draft a CR. CC does not start implementation. CC reports.

2. Reading order for CC

1. loomworks-phase-50-scoping-note-v0_1.md (scope, decisions, draft sketches that this brief verifies)
2. current-status-manifest-v0_35.md (Phase 49 close state — substrate baseline)
3. This document (the eight verifications)

Optional reads if a verification needs context:

• phase-49-implementation-notes-v0_2.md (engine repo docs/phase-impl-notes/) — Phase 49 build-record
• phase-49-cr-companion-intelligence-v0_3.md (engine repo docs/phase-crs/) — Phase 49 CR (active)
• phase-48-implementation-notes-v0_1.md (engine repo docs/phase-impl-notes/) — Phase 48 build-record (relevant for verification 6, conversion observer)

3. Code baseline

• Substrate repo: DUNIN7/loomworks-engine, tag phase-49-companion-intelligence at engine f27aba3 (annotated tag object cf24958). 2,023 tests passed, 26 skipped, Alembic head 0064. Working tree clean on main.
• Operator Layer repo: DUNIN7/loomworks, tag phase-49-companion-intelligence at frontend 6a3653b (annotated tag object 9c8c116). 128 vitest passed, 28 test files, 11 prerendered routes (one of which is /settings), eslint/tsc/build clean.
• Workshop repo: DUNIN7/loomworks-ui, unchanged from Phase 48 baseline. Not in Phase 50 scope.

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 45 dispatch surface for item 2

Ask. Confirm register_action_dispatcher signature and ApprovalCard extension pattern. The scoping note assumes Phase 49's bimodal dispatch (delegation_required: bool = True, on_decline: Callable | None = None) is the surface item 2's dispatcher registers against, and that the Phase 49 item 9 ProposalApprovalCard is the closest-fit reuse pattern for item 2's GrantDecisionApprovalCard.

Look at.

• Engine: phase_45/dispatch.py (function register_action_dispatcher, process_approval, process_decline); the Phase 49 reconciliation dispatcher registration call site (the file that registers delegation_required=False for reconciliation).
• Frontend (Operator Layer): the Phase 49 ProposalApprovalCard component file and the base ApprovalCard it extends (or the discriminator pattern, if it works that way).

Evidence expected.

• File paths and current signatures of register_action_dispatcher, process_approval, process_decline.
• The signature of on_decline (what arguments it receives, what it returns).
• The frontend ApprovalCard extension/composition shape (subclass, discriminator union, render-prop pattern, etc.).
• The exact name and file location of the Phase 49 ProposalApprovalCard (or its actual name if different).

Verdict criteria.

• HOLDS. Both substrate dispatch and frontend approval-card pattern match the scoping note's §4.1 sketch. GrantDecisionApprovalCard will be a sibling to ProposalApprovalCard with the same scaffolding.
• PARTIALLY HOLDS. Substrate matches but frontend pattern is structurally different (e.g., ProposalApprovalCard is not a clean extension point, requires refactor before GrantDecisionApprovalCard slots in). Names what scoping note §4.1 needs to revise.
• BREAKS. Either substrate signature has shifted or ProposalApprovalCard is not a viable reuse template. CR drafting needs scoping note v0.2.
• INCONCLUSIVE. Frontend pattern is unclear without running the dev server or following multiple component layers; reports the obstacle.

4.2 Verification 2 — Cross-engagement Memory read seam generalization

Ask. Confirm read_credit_management_assertions (or whatever it's actually named in loomworks/credit/cross_engagement_memory.py) parameterizes the category filter cleanly enough to support a second category (conversion_credit_policy for item 8), or whether item 8 needs a sibling function. The scoping note assumes the filter path correction from Phase 49 (payload->'metadata'->>'category') is in place and that the function takes a category parameter.

Look at.

• Engine: loomworks/credit/cross_engagement_memory.py — module structure, function signatures, current category filter constants.
• Phase 49 impl notes v0.2 for the corrected filter path narrative.

Evidence expected.

• Current function signature(s) in cross_engagement_memory.py.
• Whether category is a parameter or a hardcoded constant in the existing function.
• Whether the function returns assertions in a shape item 8's policy override resolution can use directly (most-specific-scope wins per scoping note §4.3), or whether transformation is needed at the caller.

Verdict criteria.

• HOLDS. Function takes category as parameter; sibling function for conversion_credit_policy is unnecessary; item 8's read fits cleanly.
• PARTIALLY HOLDS. Function works for model_profile but generalization for a second category requires either a small refactor (extract category to a parameter) or a sibling function. CR §4.3 read-seam wiring expands by one small step.
• BREAKS. The Phase 49 function's filter path is hardcoded in a way that can't accommodate a second category without duplication; CR drafting needs to specify the refactor or the sibling.
• INCONCLUSIVE. Function signature is unclear without running the test suite or the seam mock.

4.3 Verification 3 — Public endpoint posture

Ask. Confirm whether the engine has rate-limit middleware, CORS configuration, and a clean public-endpoint validation pattern. Item 3's POST /authority/grant-request is a public unauthenticated endpoint; the scoping note §4.2 sketches all three pieces but does not assert their presence.

Look at.

• Existing public endpoints: POST /claim/grant (Phase 47, possibly Phase 48), POST /signup (Phase 47/48).
• Engine main app file (FastAPI app construction) — middleware list, CORS config, rate-limit middleware if any.
• Any existing rate-limit utility module, decorator, or third-party dependency in pyproject.toml.

Evidence expected.

• File paths and posture of the two existing public endpoints — what auth check (if any), what validation pattern (pydantic model with strict types?), what rate-limit (if any).
• Presence or absence of rate-limit middleware (named library, configuration, applicability scope).
• CORS configuration: where it's set, what origins are currently allowed, how to add a new origin.
• Validation pattern: pydantic model conventions, error response shape.

Verdict criteria.

• HOLDS. Rate-limit middleware exists; CORS is config-driven; pydantic validation pattern is reusable. Item 3's endpoint slots in cleanly.
• PARTIALLY HOLDS. CORS and validation are fine, but rate-limit middleware is absent. Phase 50 adds the simplest viable form (in-memory token bucket per IP) as a small build step. Scoping note §5.1 needs to name the addition.
• BREAKS. Multiple posture pieces are missing in ways that meaningfully expand item 3's scope. Scoping note v0.2 needs to absorb the gap (or item 3 defers to Phase 51).
• INCONCLUSIVE. Posture is partially identifiable but full readiness can't be assessed without exercising the endpoint.

4.4 Verification 4 — Memory event author for form submissions

Ask. Confirm the existing ActorRef kinds and how Phase 16 contributions create Memory events with non-Operator authoring. The scoping note §4.2 recommends Companion-as-receiver for the form submission's Memory event (ActorRef(kind="companion")); alternatives are system-actor (sentinel) or external-actor (new ActorRef kind).

Look at.

• Engine: ActorRef model definition (kind enum / literal). Phase 41 introduced kind="companion"; Phase 49 used person-actor and Companion-actor in bimodal dispatch.
• Phase 16 Memory contribution path — how a held assertion is created with non-Operator authoring; the file that constructs the ActorRef for system-emitted events (DST/DRT events from Phase 49 ensure_reconciliation_specialists_declared are one example).
• Any existing system or sentinel ActorRef kind for non-person, non-Companion authoring.

Evidence expected.

• The complete list of ActorRef.kind values currently supported in the model.
• The file and function that creates the ActorRef for system-emitted DST/DRT events (Phase 49 lifespan hook).
• Whether kind="companion" requires a companion_id or comparable association — if so, whether the Credit Management Engagement's Companion has an identity that the dispatcher can use.

Verdict criteria.

• HOLDS. Companion-as-receiver works cleanly: the Credit Management Engagement's Companion has an addressable identity; Memory events authored with kind="companion" and the appropriate Companion id pass validation. Item 3's design carries.
• PARTIALLY HOLDS. A system-actor or sentinel kind exists and is the cleaner fit for "external form submission ingested by the engagement." Scoping note §4.2 design shifts; CR drafts to the system-actor pattern.
• BREAKS. Neither Companion-as-receiver nor a system-actor sentinel works without introducing a new ActorRef kind. Surface as architectural amendment for scoping note v0.2.
• INCONCLUSIVE. ActorRef shape is partially clear but the form-submission case requires running tests to determine fit.

4.5 Verification 5 — Grant-request event kind registration

Ask. Determine whether the new grant_request_received event kind needs Phase 38 declare-and-register treatment (specification-grammar extension via lifespan hook, like Phase 49's ensure_reconciliation_specialists_declared) or whether it's a routine Memory event that doesn't require DST/DRT declaration. The distinction matters: declare-and-register fires bootstrap-idempotent appender code; routine event creation does not.

Look at.

• Engine: how Phase 16 contributions register event kinds (if at all) versus how Phase 49's reconciliation specialists registered DST/DRT events.
• The engagement specification grammar surface — what counts as a DeclaredShapeType / DeclaredRenderType vs. what counts as a routine assertion category.
• Any existing event kind registry or canonical event-kind list.

Evidence expected.

• Whether the engagement specification grammar enumerates allowed event kinds at bootstrap, and if so, whether grant_request_received is a new entry or an existing one.
• Whether the dispatcher pattern (Phase 49 dispatchers register against event kinds) requires the event kind to be pre-declared.
• The Phase 49 ensure_reconciliation_specialists_declared shape — what it does, what it idempotently appends.

Verdict criteria.

• HOLDS as routine event. grant_request_received is a routine Memory event in the Phase 16 sense; no DST/DRT declaration needed; item 3's CR slots in cleanly.
• HOLDS as specification-grammar extension. grant_request_received requires declare-and-register; item 3's CR adds a ensure_grant_request_event_declared lifespan hook. (Aligns with Phase 49 Finding 2 — engagement specification grammar evolves through Memory contributions, post-bootstrap.)
• BREAKS. The dispatcher requires a registration shape that doesn't exist for either routine or specification-grammar-extension events; scoping note v0.2 needs the architectural decision.
• INCONCLUSIVE. The distinction between routine and specification-grammar-extension events is unclear in the codebase; reports the boundary CC can identify.

4.6 Verification 6 — Conversion observer location and extension shape

Ask. Confirm _on_api_key_saved_for_conversion (Phase 48 CR §12.3) — module location, signature, integration with register_on_api_key_saved. Item 8 extends it; the extension shape in scoping note §4.3 should not surprise the existing structure.

Look at.

• Engine: the conversion observer module (likely loomworks/credit/conversion.py or similar, but verify); the register_on_api_key_saved hook registration.
• The function body of _on_api_key_saved_for_conversion — current logic, how it reads the referee's most recent claimed grant, how it calls seam.write_referral_credit_flow.

Evidence expected.

• File path and full current signature of _on_api_key_saved_for_conversion.
• The register_on_api_key_saved registration call site.
• Current logic's idempotency check shape (Phase 48 used metadata-based check on credit.foray_action_flows with metadata->>'reason' = 'conversion_detected').
• The exact shape of the metadata dict the observer currently writes to the conversion flow.

Verdict criteria.

• HOLDS. Observer's structure accommodates item 8's override-read insertion cleanly. CR §4.3 carries.
• PARTIALLY HOLDS. Observer's structure works but the metadata extension (adding asset_id_source and override_assertion_id) requires schema considerations the scoping note didn't anticipate. Reports the specifics.
• BREAKS. Observer's structure has shifted since Phase 48 in a way that requires re-design before item 8 fits. Scoping note v0.2 absorbs.
• INCONCLUSIVE. Observer is identifiable but the extension fit can't be assessed without running tests.

4.7 Verification 7 — Voice composition module location and prompt loading pattern

Ask. Confirm where Phase 49's three credit_voice templates live (prompts/credit_voice/tier_drop.md, prompts/credit_voice/near_exhaustion.md, prompts/credit_voice/exhaustion_choice.md) and how they are loaded into voice composition. Item 2's prompts/credit_voice/grant_proposal.md lands in the same location with the same loading pattern.

Look at.

• Engine: the prompts/credit_voice/ directory (or whatever path Phase 49 actually used).
• The voice composition module that loads these templates (likely loomworks/credit/companion_intelligence/voice_composition.py per scoping note §1 — Phase 49's listed touched modules).
• The loading pattern (file read, template substitution, integration with the Phase 31/42 converse pipeline).

Evidence expected.

• Actual directory path of the credit_voice templates.
• Loading pattern in voice composition module — function signatures, template variable substitution mechanism, integration point.
• The AI-invisibility carve-out comment shape at the top of each Phase 49 template (item 2's grant_proposal.md mirrors this).

Verdict criteria.

• HOLDS. Voice templates and loading pattern are as scoping note §4.1 / §5.2 sketch. grant_proposal.md slots in.
• PARTIALLY HOLDS. Path or loading mechanism differs in a way that requires CR §4.1 to update the description. Reports the actual shape.
• BREAKS. Voice composition is structurally different from the scoping note's read; scoping note v0.2 absorbs.
• INCONCLUSIVE. Path is found but loading pattern is unclear without runtime exercise.

4.8 Verification 8 — Rate-limit and CORS infrastructure decision support

Ask. If Verification 3 reveals no rate-limit middleware or no CORS config mechanism, this verification supports the scoping decision: does Phase 50 add the simplest viable form, or does the gap warrant scoping note v0.2 / Phase 51 deferral? Provides the evidence base for that call.

Look at.

• The findings from Verification 3.
• Available rate-limit Python libraries already in pyproject.toml (e.g., slowapi, fastapi-limiter) or absent.
• Any in-codebase rate-limit utility or in-memory bucket implementation.
• The CORS configuration's flexibility — environment-variable-driven, code-constant, etc.

Evidence expected.

• Whether a rate-limit library is already a dependency.
• Estimated effort to add a minimal rate-limit middleware (lines of code, test count, configuration footprint).
• CORS allowlist mechanism's shape — adding a new origin is one-line config or requires more.

Verdict criteria.

• NOT NEEDED. Verification 3 returned HOLDS; this verification produces a one-line "no follow-up needed" finding.
• SIMPLE-VIABLE-FORM RECOMMENDED. Verification 3 returned PARTIALLY HOLDS. The gap is small; Phase 50 adds the minimal middleware and one CORS config entry. Reports the recommendation with effort estimate.
• DEFERRAL RECOMMENDED. Verification 3 returned BREAKS. The gap is non-trivial; Phase 50 defers item 3 to Phase 51 and ships items 2 and 8 only. Reports the recommendation with rationale.
• INCONCLUSIVE. Verification 3 was inconclusive; this verification cannot resolve.

5. After verification

CC produces phase-50-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 / NOT NEEDED for verification 8), 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 50 in:

• All HOLDS or naming-only divergences. Proceed to Phase 50 CR drafting handoff (the next document Claude.ai produces, which references both the scoping note and the findings).
• 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/phase-50-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/phase-50-step-0-inspection-brief-v0_1.md

Run all eight verifications against the live codebase at /Users/dunin7/loomworks-engine. For verifications that cross into the Operator Layer frontend repo, also read /Users/dunin7/loomworks. Phase 49 tag for reference: phase-49-companion-intelligence at engine f27aba3 / frontend 6a3653b.

Reading order before running: loomworks-phase-50-scoping-note-v0_1.md (in project knowledge); current-status-manifest-v0_35.md (in project knowledge); this brief.

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

One section per verification. Each section: verdict (HOLDS / PARTIALLY HOLDS / BREAKS / INCONCLUSIVE; 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-50-scoping-note-v0_1.md — parent scoping note. CC reads this first (the brief presupposes its draft sketches).
• current-status-manifest-v0_35.md — current substrate state.
• phase-49-implementation-notes-v0_2.md (engine repo docs/phase-impl-notes/) — Phase 49 build-record.
• phase-49-cr-companion-intelligence-v0_3.md (engine repo docs/phase-crs/) — Phase 49 CR (active).
• phase-48-implementation-notes-v0_1.md (engine repo docs/phase-impl-notes/) — Phase 48 build-record (relevant for Verification 6).

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