Version. 0.1
Date. 2026-04-15
Status. Handoff document. Carries context, current state, and decisions-needed from the 2026-04-15 methodology-rework-and-repo-work session into a new chat focused on continuing Loomworks implementation build.
Reader. Claude (new chat instance). Marvin Percival (DUNIN7) will paste this as the first message of the new chat to establish context.
Supersedes. Nothing for the build continuation specifically. Related handoffs: loom-loomworks-repo-handoff-v0_2.md (executed earlier today, established the two repos).
Marvin wants to resume the Loomworks implementation build. Phase 1 substrate foundation was completed previously (before the recent methodology rework cycles). Phase 2 and subsequent phases are ahead. The new chat's job is to guide the continuation of the build through Claude Code on the MacMini, respecting the methodology-layer thinking that has advanced substantially since Phase 1 was defined.
A meaningful tension exists and must be handled honestly: the phase definitions were written against older vocabulary (playground/substrate/source/projection) and against an older version of the methodology document. The current methodology is at v0.17 with substantial advances — the three-layer architecture made explicit, the vocabulary settled (memory/manifestation/shaping/render), hierarchical domains introduced, the skill-vs-agent distinction established, access modes treated as first-class, and several working notes in place that refine the shaping layer (saved-vs-one-shot shapings, static-vs-dynamic shapings, the render-boundary constraint on external data retrieval). The build continuation cannot naively execute old phase definitions; it needs to read those definitions against v0.17 and decide what still holds, what needs reframing, and what the phase sequence should now be.
Location. /Users/dunin7/loomworks on the MacMini (renamed from /Users/dunin7/playground earlier today).
What exists. Phase 1 substrate foundation is complete and tagged phase-1-substrate-foundation. Specifically:
alembic.ini, migrations/)SubstrateObject base class and SubstrateEventRow ORM modelappend_event code pathstate_at_time and state_at_version query functionspyproject.toml is now loomworks; Python package under src/loomworks/; all imports updated.env.example, .gitignore, READMEWhat is NOT yet done. Phase 2 onward. Per the original thirteen-phase plan anticipated in the Phase 0 CR (CR-2026-011), the subsequent phases were roughly:
GitHub state. Both DUNIN7/loomworks and DUNIN7/loom exist as private repos; loomworks has the full 18-commit history including Phase 1 plus the rename commit plus the methodology documentation addition. The methodology document chain v0.4 through v0.17 lives in docs/methodology/. Decision notes live in docs/decisions/.
Operator identity and authentication. Git global identity on the MacMini is Marvin Percival <marvinp@dunin7.com>. gh CLI authenticated to DUNIN7 account with repo and admin:public_key scopes, SSH protocol via ed25519 keypair in ~/.ssh/. Ready for pushes without setup.
The implementation cannot be coded without understanding what it is implementing. The new chat should, before any build work, read at minimum these documents in the loomworks repo:
Required reading.
docs/methodology/what-dunin7-is-building-v0_17.docx — the current methodology document. The three-layer architecture, the four operations (memory/manifestation/shaping/render), the access modes, hierarchical domains, supersession with severity, contribution trust, engagements as first-class objects, federation, skill-vs-agent distinction. This is what any conforming implementation must support. Loomworks is one such implementation.docs/decisions/loomworks-tessera-composition-v0_1.md — architectural decision about render-boundary as methodology's edge; TESSERA as example downstream consumer.docs/decisions/shaping-refinements-working-note-v0_3.md (if added to the repo by the time the new chat starts; if not, it is in Marvin's Downloads at ~/Downloads/dunin7-repo-staging/shaping-refinements-working-note-v0_3.md — Marvin can add it to the repo or share it in the new chat) — three shaping refinements plus the no-external-data-at-render-time constraint with the sharpening that the rendered artifact retrieves and evaluates data at use time.Also available but older.
docs/methodology/what-dunin7-is-building-v0_6.md and earlier versions in the chain — these were the methodology state at the time Phase 1 was built. Reading them reveals what the Phase 1 implementation was built against. Useful for judging whether Phase 1's substrate design still aligns with v0.17's methodology requirements or whether some refactoring is due alongside Phase 2.docs/implementation/phase-1-implementation-spec.md — the original Phase 1 spec.docs/implementation/how-the-playground-works.md — pre-rename document, preserved as historical but carries some useful implementation thinking.Elsewhere (not in the repo currently).
Step 1: Read the methodology document v0.17 and the two decision notes. Get full context on what the implementation is building toward. Note particularly:
Step 2: Inspect what the Phase 1 implementation actually built and how well it aligns with the current methodology. The implementation was written against older vocabulary. Review src/loomworks/ and migrations/ to see:
substrate_events table is (probably the memory-layer immutable event log; the methodology calls this the memory layer now)SubstrateObject is and how it relates to memory fragments as the methodology now describes them
Step 3: Read what Phase 2 was originally envisioned as. Find the Phase 2 description in docs/implementation/ (or ask Marvin to share the Construction Brief if it is not in the repo). The original Phase 2 was "engagement creation and seed induction" — but the methodology at v0.17 has much richer treatment of engagements (as first-class durable objects with provenance and lineage) and of seed induction (the placement-recommendation agent, the operator confirmation step, the hierarchical domain placement). Decide whether the original Phase 2 scope is still right, or whether it should be reframed for what the methodology now requires.
Step 4: Propose a Phase 2 scope and a CR to Marvin. Following the DUNIN7-M4 CR template discipline (the Phase 0 CR at CR-2026-011 is an example of the format). The CR should:
Marvin uses a Change Request template for all DUNIN7-M4 infrastructure and project changes (the document is titled "DUNIN7-M4 — INFRASTRUCTURE CHANGE REQUEST"). The template structure appears in the Phase 0 CR (CR-2026-011) that bootstrapped the environment. Each CR has:
The operator-approval rule is load-bearing. Claude Code does not execute CR content without seeing recorded operator approval. This is the implementation-level instance of the methodology's operator-approval principle.
The CR numbering runs sequentially by year: CR-2026-011 was the Phase 0 bootstrap. The next CR for Phase 2 would presumably be the next in the DUNIN7-M4 sequence — Marvin should confirm the actual next number when the CR is being drafted. CRs also typically increment a baseline reference (the Phase 0 CR moved DUNIN7-M4-System-Reference from BSL 1.9 to BSL 1.10; subsequent CRs continue incrementing).
Do not execute Claude Code commands from this chat. All actual implementation work happens in Claude Code on the MacMini, not in this Claude.ai chat. This chat produces CRs, reviews output, makes decisions, and hands off to Claude Code. Claude Code is the shell-access tool that modifies the filesystem.
Do not land methodology-layer changes in the implementation ahead of the methodology document. The working notes (shaping refinements, TESSERA composition) capture methodology-layer thinking that has not yet landed in the methodology document. Implementation decisions should be based on what v0.17 actually says, not on what future versions might say. If a Phase 2 decision requires methodology guidance that only exists in working notes, surface this to Marvin and discuss whether v0.18 should land the guidance first.
Do not try to implement the full Loom Protocol at the protocol layer within Loomworks. Loom Protocol is a separate concern, specified in the DUNIN7/loom repo (or will be once the spec lands there). Loomworks implements against Loom Protocol as a dependency, not as something it owns. If Phase 2 needs protocol-level features that Loom v0.1 does not provide, surface the gap rather than extending the protocol silently.
Do not ignore the old vocabulary in existing code. Phase 1 code was written with older vocabulary. Some of it should be renamed; some is internal enough that renaming is low-priority; some is public-ish (module names, exported classes) and warrants renaming soon. The judgment about what to rename and when is part of the Phase 2 scoping work; do not rename ambitiously without Marvin's agreement, and do not leave old vocabulary in newly-added code.
Do not abandon the filename-versioning discipline. Every file Marvin produces carries a version in its filename per his standing preference. Every CR is versioned (V1_0_0 format in the DUNIN7-M4 template). Every working note is versioned. Every methodology document version is preserved. The discipline applies to anything Marvin downloads.
On Phase 2 scope. Is the original "engagement creation and seed induction" still the right Phase 2, or should the scope be reframed? The methodology's treatment of engagements and seed induction is richer now than when Phase 2 was originally scoped.
On refactoring the existing Phase 1 code. Does Phase 2 work pick up Phase 1's naming and vocabulary as-is, or does Phase 2 begin with a cleanup pass that brings Phase 1's identifiers in line with the v0.17 vocabulary? Both are valid; they are different operational choices with different trade-offs.
On the pace. The original thirteen-phase plan was ambitious. Whether to keep that pace, revise the plan based on what was learned in Phase 1 and in the methodology work since, or restructure into a different phase sequence entirely — this is Marvin's call informed by the new chat's analysis.
On protocol version alignment. Loom Protocol v0.1 is current. The methodology has named gaps between what v0.1 provides and what the methodology depends on (in v0.17's What Remains Unsettled section). Loomworks implementing against v0.1 means implementing around those gaps. Subsequent Loom versions may close some gaps. Whether Loomworks waits for a specific Loom version before advancing to specific phases, or proceeds with gap-coverage implementation and refactors later, is a decision for Marvin with input from the new chat.
Marvin is an Operator in DUNIN7's own methodology sense. He holds domain knowledge, judgment, and intent; he does not code; AI is the production layer. When he hits a technical wall, that is a product deficiency in the tooling around him, not a failing on his part. Give him step-by-step instructions when technical work is required; do not assume he can figure out terminal commands, git operations, or infrastructure decisions without guidance.
Marvin has 55 years of systems architecture experience and conceived what is now the Loom-FORAY pattern roughly 45 years ago. He came back from retirement three months ago because AI plus blockchain finally makes buildable what he had held as architectural vision for decades. He works from Miami. He is a bladder cancer survivor; Maria's clinical trial in the methodology document's running case is real-inspired, not arbitrary.
He operates on the MacBook typically, with SSH access to the MacMini where actual build work happens. Claude Code is available on the MacMini. He has downloaded documents from this project to ~/Downloads/dunin7-repo-staging/ previously for repo-work sessions; he may have a fresh staging folder or a cleaned-up one by the time the new chat starts.
Marvin's preferred working pattern is correction rather than upfront specification. He says things like "what if we simply do not allow such behavior" or "but it does allow the dashboard itself retrieve and evaluate the data" and expects the AI to absorb the correction and update its model. The new chat should expect to be corrected, hold prior context across corrections, and surface its current understanding for the next correction. Rapid decisiveness is welcome once options are clearly framed; extended re-discussion after options are framed is not.
False-structure anchoring is a known failure mode Claude has exhibited before in this work. Inventing analogies, overreaching pattern claims, anchoring to Forge when Loomworks is the topic, inverting SAE's position in the stack — all of these have surfaced before. When uncertain, ask rather than guess.
In the DUNIN7/loomworks repo's docs/decisions/ directory. Both loomworks-tessera-composition-v0_1.md and shaping-refinements-working-note-v0_1.md through v0_3.md live there (or will by the time the new chat runs; Marvin may not have added the v0.1-v0.3 shaping notes yet). When the new chat produces decisions that Marvin approves, the decision gets a working note in docs/decisions/ with filename versioning, before landing in the implementation.
CRs land as files too, typically in a docs/crs/ subdirectory (or wherever Marvin has been placing them). The CR is the executable version of an approved decision: the decision becomes a CR, the CR is approved, Claude Code executes the CR, the post-CR state is the new reality.
Something like:
> I want to continue the Loomworks implementation build. The Loomworks repo at /Users/dunin7/loomworks has Phase 1 substrate foundation complete (tag phase-1-substrate-foundation); Phase 2 onward is ahead. The original thirteen-phase scaffolding plan came from the Playground Construction Brief v0.1, but the methodology has advanced substantially since then (now at v0.17 of "What DUNIN7 is building"). Before we continue, you need to read the handoff document at ~/Downloads/dunin7-repo-staging/loomworks-build-continuation-handoff-v0_1.md and the current methodology document at docs/methodology/what-dunin7-is-building-v0_17.docx (or wherever it now lives). Confirm you have absorbed both before proposing any Phase 2 work.
Produced 2026-04-15 in conversation between Marvin Percival (DUNIN7) and Claude. The 2026-04-15 session focused on methodology document v0.17 development, the TESSERA-composition architectural decision, the repo establishment (DUNIN7/loom and DUNIN7/loomworks), and the shaping refinements working note through v0.3. This handoff synthesizes the current state of the work in a form a new chat can pick up from without losing context.
The handoff intentionally does not enumerate everything that was in the 2026-04-15 session — that conversation history is searchable via conversation_search from the new chat and does not need to be reproduced. What the handoff gives the new chat is enough orientation to know what to read, what to do, and what to avoid, along with the structural context (the CR discipline, the operator's working model, the iterative correction pattern) that cannot be derived from documents alone.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks Build Continuation