Version. 0.1 Date. 2026-04-17 Status. Handoff document. Carries context from the Phase 5 build into a new chat for Phase 6 scoping and execution. Reader. Claude (new chat instance). Marvin Percival (DUNIN7) will paste this as the first message.
Tag. phase-5-considerations-and-terminal-states, applied at Step 14 commit on branch phase-5-considerations-and-terminal-states, merged to main, pushed to DUNIN7/loomworks on GitHub.
What the codebase can now do.
ConsiderationStageMachine) with legal-and-illegal transitions tested exhaustively.DeliberateExceptionNotPermittedError if triggering_reason is not seed_drift_triggered.drift_detection_jobs for polling. Non-blocking per R-B25.2; Commit finalizes before drift check completes.summarization_jobs for polling.retrieval-triggered-consideration, that produces a retrieval-triggered consideration from a rule-set outcome on a retrieval channel.What the codebase cannot yet do.
design_intent as an optional parameter but Phase 5 always passes None. Phase 6 populates it.
Test state. 290 passed, 2 skipped. Both skips are environment-gated and carry forward from earlier phases: Anthropic integration smoke on ANTHROPIC_API_KEY, HTTP integration on LOOMWORKS_RUN_HTTP_INTEGRATION. Phase 5 added 120 new tests across 9 new test files.
Per Construction Brief v0.1 Sec-7:
> Phase 6 — Design intent. Implements Sec-A.7 of the spec. Deliverables: the DesignIntent model, the initialisation at engagement instantiation (R-A37), the amendment path through considerations (R-A38), the drift check against the seed (R-A39), and the fine-grained individual-contribution drift check against both seed and design intent (R-A40).
Phase 6's substantive additions:
object_type: Literal["design_intent"] on the MemoryObject union. Carries whatever fields Sec-A.7 commits to — read Sec-A.7 before drafting the CR; the fields are not rehearsed here because the handoff should not preempt CR-drafting's own grounding pass.amend against a DesignIntent-in-scope. This is a reuse of Phase 5's closure machinery; the _close_amend helper already handles revision of whatever is in assertions_in_scope, and DesignIntent may ride the same path or may need its own closure helper. The CR decides.seed: Seed | None = None to a shape that carries both seed and design intent, and the firing logic evaluates drift against both.
The DriftDetectionAgent signature change. Phase 5's implementation has seed: Seed | None = None, design_intent: Any | None = None — the forward-compatible shape. Phase 6 populates both. Whether design_intent remains Optional or becomes required is a Phase 6 CR decision; the caller (Commit hook, closure-producing-Commit hook) will need a way to load the engagement's current DesignIntent version before dispatch, the way it will need to load the seed.
Acceptance per the Construction Brief. A pytest suite drafts a synthetic design intent, amends it through a consideration, verifies the amendment is recorded as a DesignIntent version bump per Sec-A.0, runs the fine-grained drift check at Commit against both seed and design intent with a stub agent, verifies that drift detected against design-intent-only opens a seed-drift-triggered consideration with appropriate metadata, verifies that drift against both seed and design intent is distinguishable from drift against only one.
These are conventions the Loomworks project has accumulated across Phases 2, 3, 4, 5. Phase 6's CR drafter should treat them as closed and not relitigate them.
Section references. Use Sec-N or Section N in prose. No §. Convention across the project; the Phase 4 CR versions drifted on this three times and the Phase 5 CR honoured it.
Versioned filenames. name-v0_1.ext, name-v0_2.ext. Version advances when content changes substantively. A revised CR produces v0_2, not an overwrite of v0_1. The version also appears visibly at the top of the document — in the title or a header field.
Discovery-record posture. Corrections are preserved as corrections. When a scoping decision replaces a prior position, name the prior position alongside the current one. When options are considered and set aside, make the alternatives and reasons visible. When something crystallizes as a new synthesis, distinguish it from established knowledge. The goal is that a Discovery record built from the chat later can reconstruct positive and negative paths, not only the destination.
Skill-vs-agent distinction. A skill is a bounded structural transformation — inputs in, deterministic output out, no registered actor. An agent is a registered actor with an instruction set, carrying out actions attributed back to its ActorRef. Phase 5 held this cleanly: ConsiderationStageMachine is a skill, SummarizationAgent is an agent, the closure logic is a skill. Phase 6 should expect DesignIntent-related code to be similarly distinguishable — the DesignIntent model and its read/write functions are skill-layer; any agent that contributes to DesignIntent authoring or amendment is agent-layer.
Shaping/Render boundary discipline. Surfaced during the final exchanges of the Phase 5 chat, recorded in docs/loomworks-standing-note-shaping-render-boundary-v0_1.md in the Loomworks project knowledge. The principle: knowledge of specialist-specific requirements belongs to the specialist layer, not upstream. A Shaped set is specialist-agnostic; a rendered artifact is specialist-specific. This is not load-bearing for Phase 6 — design intent is not Render work — but the standing note applies to every phase and Phase 6 is the first phase after it was surfaced. The note becomes load-bearing for Phase 9 (projections) when that phase is drafted. Phase 6 CR drafting should read the note, note it does not apply to Phase 6's scope, and carry it forward in the Phase 6 → Phase 7 handoff.
Correction-discipline convention. When the operator corrects something, read the correction at full scope before typing any defence. The Phase 5 vocabulary drift trajectory (v0.1 → v0.2 → v0.3) is the case study: Marvin pointed at the word "substrate" being wrong in a CR draft, Claude read the correction narrowly (code-level table names only) and defended keeping "substrate" in prose for one round, then did the full correction after Marvin named it a second time. The fix is: assume the correction has the scope the operator meant, not the narrowest scope that preserves prior drafting work. If the operator's first correction was narrower than now suspected, the full-scope pass catches the narrower case anyway; if the operator's first correction was broader, the full-scope pass catches the broader case. Either way, full-scope reading is safer than narrow-scope-with-defence.
CC pre-flight review offer. Carried forward from Phase 5 Finding A. CC is willing to run a pre-flight review on each CR before the operator approves it: walk every step's code samples against the current codebase, flag any signature-shape-ordering mismatch, report drifts before execution. The Phase 6 CR drafting chat should accept this offer — produce v0.1, send to CC for pre-flight review, incorporate CC's drift-reports into v0.2, then send v0.2 to the operator for approval. This adds a review step between CR draft and operator approval that Phase 5 did not have, and that would have caught the nine v0.4 items at draft time instead of execution time.
Closure-enumeration discipline. The unifying principle underneath Phase 5 Finding A's four drafting shapes (pre-flight walk-through, signature-level grounding, wire-vs-persistence audit, vocabulary budget). Surfaced during the Render discovery chat's reading of the Phase 5 finding. The principle: declare explicitly what is closed to the consumer (CC), leave the complement as latitude, expect drift-reports where latitude and judgment-reveals-mismatch intersect. The four shapes are four lenses on the same discipline — closure at four different levels of the Shaped set (completeness, interfaces, form-transformation, terminology). A CR that fully enumerates closure at all four levels is a CR that has the four shapes. The Phase 6 CR drafter should treat closure-enumeration as the principle and the four shapes as operational forms of it.
Session autobegin pattern. From Phase 5 Finding C. Test-infrastructure convention: after a full_engagement fixture has driven HTTP traffic on the shared db session, the session is in an autobegun transaction. Direct library calls from the same test body (e.g., seeding assertions via add_assertion(...) before an HTTP request) must NOT use async with db.begin(): wrappers — the explicit begin() collides with the autobegun state and raises "A transaction is already begun on this Session." Phase 6 test writers should inherit the convention: if the test uses full_engagement or any fixture that drives HTTP calls on the shared session, library calls in the test body run unwrapped.
The Render discovery chat is a separate discovery conversation running alongside the Loomworks build in its own project. The Phase 5 chat produced substantive framework input to that discovery, and the discovery has returned one observation request that bears on Phase 6 specifically.
The request. The discovery is testing a prediction: if a CR enumerates closure at four levels with visible density differences — some sections densely closed, others lightly — then drift-reports during execution should cluster in the lightly-closed sections. If the prediction holds, the framework has empirical grounding. If it fails in either direction (drift-reports from densely-closed sections, or no drift-reports from lightly-closed sections), the framework has learned something it did not know.
What Phase 6 is asked to do.
Stage one, at CR draft time: run a closure-density pass over the Phase 6 CR, marking each section as high, medium, or low density. Record this map in the CR drafting notes (not in the CR itself). This fixes the prediction before execution begins.
Stage two, after Phase 6 execution completes: compare actual drift-reports against the closure-density map. Three outcomes are possible — prediction holds, fails by commission (drift from densely-closed sections), or fails by omission (no drift from lightly-closed sections). Report all three cases honestly.
Self-validation caveat. The density estimate at stage one is a Claude-internal judgment. If the same instance drafts the CR and estimates the density, the prediction is trivially confirmed because both come from the same source. The cleaner form would be for Marvin to make the density estimate, or for a fresh instance to make it without seeing the drafting rationale. The Phase 6 CR drafter should surface this caveat with Marvin explicitly and let him decide whether Claude-internal density-marking is enough, or whether external density-marking is needed.
What not to do with this. The request is a request for post-execution observation, not a gate on Phase 6 execution. It does not change what Phase 6 does; it changes what Phase 6 observes about itself. If the observation request feels intrusive to drafting or execution discipline, flag it and it will be dropped or deferred. The framework needs exposure to being wrong; Phase 6 is an inexpensive way to produce that exposure, but only if the execution itself is not distorted by the observation.
The Phase 5 implementation notes (docs/phase-5-implementation-notes-v0_1.md) carry nine items as input to CR v0.4, which has not yet been drafted. Each item names its location in the codebase and a recommended shape where CC had a view. The operator has not yet decided when to draft CR v0.4 — it is not on a critical path for Phase 6; Phase 6 does not need CR v0.4 to exist to proceed.
Phase 6 CR drafting should read the v0.4 items but not wait for them. The items are input to CR v0.4's eventual revision of the Phase 5 CR, not corrections that Phase 6 inherits. Several of them (items 7, 8, 9 on vocabulary, stub_summary gating, opening_rationale persistence) will remain open during Phase 6 execution; this is acceptable and does not block Phase 6.
Items Phase 6 should be aware of by category:
The new chat has access to these via project_knowledge_search:
playground-spec-v0_10.docx — the Playground Specification. Sec-A.7 is Phase 6's primary source for the DesignIntent model, R-A37 through R-A40.playground-reference-design-v0_1_2.docx — the Reference Design. Sec-A.7 in the Reference Design (if present; confirm during grounding) gives the reasoning behind the spec's design-intent commitments.playground-construction-brief-v0_1.docx — the Construction Brief. Sec-7 Phase 6 names the deliverables.what-dunin7-is-building-v0_17.docx — the methodology document.Loom_Protocol_Specification_v0_1_2026-04-12.md — the Loom Protocol.stress-test-five-cases-v0_1_2.docx — the five-case stress test.loomworks-tessera-composition-v0_1.md — the TESSERA composition decision.phase-2-cr-engagement-creation-and-seed-induction-v0_3.md — Phase 2 CR.phase-3-cr-assertions-and-protocol-transitions-v0_2.md — Phase 3 CR.phase-4-cr-channels-and-boundary-v0_3.md — Phase 4 CR.phase-5-cr-considerations-and-terminal-states-v0_3.md — Phase 5 CR.phase-5-implementation-notes-v0_1.md — Phase 5 implementation notes (nine v0.4 items plus four findings including closure-enumeration material).loomworks-standing-note-shaping-render-boundary-v0_1.md — the Shaping/Render boundary discipline standing note.
The Phase 5 implementation notes (in the Loomworks repo at docs/phase-5-implementation-notes-v0_1.md) should be added to this project's knowledge before the Phase 6 chat starts, if not already present.
The new chat should produce a Phase 6 CR in the same format as CR-2026-012 (Phase 2), CR-2026-013 (Phase 3), CR-2026-014 v0.3 (Phase 4), and CR-2026-015 v0.3 (Phase 5). The next CR number is probably CR-2026-016; confirm with the operator. The CR template: metadata, executive summary, rationale, prerequisites, construction decisions, project layout, detailed sections specifying the data model and code paths, test infrastructure, acceptance suite, order of operations with checkpoints, acceptance gate, post-CR state, dependencies, kickoff prompt, deferred items, findings surfaced during drafting, approval, changes from prior versions.
New step for Phase 6: CC pre-flight review between CR v0.1 draft and operator approval. Phase 6's CR drafter produces v0.1, sends it to CC for the pre-flight review described in the conventions section above (walk code samples against the codebase, flag signature-shape-ordering mismatches), incorporates CC's drift-reports into v0.2, then sends v0.2 to the operator for approval. If v0.2 still has drifts that surface during execution, v0.3 is drafted the same way Phase 5 did — from execution reports, between execution checkpoints.
Prep step the operator runs for every CR, including this one. Claude produces the CR file for download. The operator downloads it to ~/Downloads/. The operator starts the Claude Code session and points CC directly at the Downloads path — no intermediate move to docs/ is required for CC to read it. Archival into docs/ happens at Step 14 of the CR alongside the implementation notes, not before.
The Phase 6 drafting chat should open something like:
> I want to continue the Loomworks implementation build. Phase 5 (considerations and the seven terminal states) is complete and tagged. Phase 6 is ahead. Read the handoff at [this document] and confirm you have absorbed it before proposing Phase 6 scope.
>
> The Playground Specification v0.10 Sec-A.7 is the primary source for Phase 6; read it via project_knowledge_search before drafting the CR. The Reference Design's Sec-A.7 (if present) gives the reasoning behind the spec's design-intent commitments. The Phase 5 CR and implementation notes are worth reading for the drafting conventions and the v0.4 item list.
>
> Standing conventions to honour are named in the handoff. The new one for Phase 6 is the CC pre-flight review step: produce v0.1, send to CC for pre-flight drift review, incorporate into v0.2, send to operator for approval. Also the closure-enumeration discipline — declare what is closed at every section, leave latitude explicit in the complement.
>
> The Render discovery chat has asked for an observational pass on Phase 6's CR (closure-density mapping before execution, drift-report comparison after). The handoff describes the request. Accept or decline the request as Marvin directs.
>
> Before drafting Section 5 of the CR, run a codebase ground-truth check: find src/loomworks -type d | sort, the list of existing migrations, relevant Pydantic Literal declarations. The Phase 4 and Phase 5 CRs learned this discipline across revisions; Phase 6 should inherit it and save a revision cycle.
The operator (Marvin) will paste the handoff document alongside this message. The new chat absorbs the handoff, confirms absorption, and begins Phase 6 scoping with the open questions the Construction Brief leaves (what fields DesignIntent carries; how R-A37 initialisation draws from the seed or operator input; whether design-intent amendment rides _close_amend or needs its own helper; how the DriftDetectionAgent signature evolves).
Two items I carried forward because the standing principle is "do not close doors," but whose Phase 6 relevance is genuinely uncertain and should be confirmed or dropped by the Phase 6 chat after it has read Sec-A.7.
Provisional 1: Whether Phase 6 touches the DriftDetectionAgent firing points or only the agent's input signature. Phase 5 wired the firing points at Commit and at closure-producing-Commit. R-A40 might add firing points (I cannot tell from Sec-7 of the Construction Brief alone whether the fine-grained check fires at the same points as the existing drift check or introduces new ones). The Phase 6 chat should read Sec-A.7 and confirm.
Provisional 2: Whether DesignIntent amendment needs a dedicated _close_design_intent_amend helper or rides the existing _close_amend. The existing helper handles revise_assertion calls on whatever is in assertions_in_scope. If DesignIntent is a MemoryObject with its own revise path (analogous to Assertion's), the existing helper may work unchanged. If DesignIntent has its own revision semantics (e.g., amendments must include a consideration-closure rationale that the existing helper does not capture), a dedicated helper may be warranted. The Phase 6 chat should read Sec-A.7 and decide.
Both items are carried provisionally; Phase 6's CR drafting decides to confirm, modify, or drop them after grounding against Sec-A.7.
Scope of Phase 6 beyond what the Construction Brief names. The handoff frames what Phase 6 inherits; the Phase 6 CR drafting chat decides what Phase 6 builds. Specific items the handoff deliberately does not commit to:
design_intent parameter becomes required or stays optional. The Phase 6 CR decides.DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks Phase 6 Handoff — v0.1