Part One

The Machine

Before there was a methodology, there was a machine. And before the machine, there was a game.

In 2017, Shea Gunther started building a working computer inside Minecraft — redstone logic gates, loop-line memory, an ALU. The design drew from mercury delay lines, a storage technology from the 1940s: data encoded as pulses circulating through a tube of mercury, alive only in motion, gone the moment circulation stops. He worked on the Minecraft machine for seven years. In early March 2026, he decided to bring it to life outside the game. He opened a conversation with Claude, an AI assistant, and asked if it could code.

Loop 2.1 is what followed. A manual flow computer that runs in a browser tab. It simulates a kind of computing hardware that has never existed outside of that browser window — a system of circular storage loops where 17-bit words circulate continuously, advancing one position per clock tick, passing through pattern matchers and threshold gates and ALU operations, routed between loops by nine buses that the human operator configures in real time. There is no instruction pointer. No fetch-decode-execute cycle. No stored program of any kind. The human is the program. Every routing decision, every control flow choice, every data movement happens because the operator made it happen, watching the bits circulate and deciding what to do next.

It was built over 325 iterative sessions between one developer — Shea Gunther, working from an RV in New Gloucester, Maine — and Claude, an AI coding assistant. The entire thing lives in a single HTML file. Roughly 18,200 lines of JavaScript. Zero external dependencies. No npm packages, no CDN imports, no build toolchain. One file, one browser, one operator.

By the 300th build, the codebase was doubling in size while the build rate was accelerating — 27 builds per day, up from 13. This is the opposite of how software normally works. Software normally gets slower to change as it gets bigger. The L21 project got faster, and the reason was structural: the conventions, the test suites, the documentation, the coding standards, the architectural discipline baked into the project over hundreds of sessions created a compounding effect. Each new session could do more because the ground under it was solid.

Part Two

The Question

By late March, Gunther had been building Loop 2.1 for three weeks — over three hundred sessions, nights and weekends, from the one-room RV where he lives with his fiancée in New Gloucester, Maine. A bill had arrived that week, large enough to sharpen a question he was already asking: could the thing he was doing with the AI become a living? On the morning of Saturday, March 29, 2026, he opened a new conversation with Claude and typed: OK, here's our goal- come up with an entirely novel and new way to develop software in the AI agentic age. The broad idea is to take the conceptual model of the Loop 2.1 system and use it to create a way to structure both the development of software, using AI agents governed with managing a portfolio of in-context software, as well as the actual software itself, leaning into a model that looks to the Space Shuttle for fault tolerance and recoverability. It's re-thinking everything. Let's talk this through. The end product, the thing that will mark whether this is a success or failure, is a set of developed guidelines, rules, and files that I can use to develop an app for my father-in-laws deer butcher company in three days. The system we come up with, named the Loop MMT system, must allow me to develop first-class enterprise level software as a solo one man dev leading an AI coding assistant. So our job, again, is to come up with that system. Let's start by you looking over everything and hitting me up with a list of questions.

That's the constraint set. Not "design a framework." Not "write an architecture document." Build a complete methodology — architecture, development process, testing strategy, document governance, failure handling — that a single person can use to ship production software with an AI writing the code. And validate it by building a real application for a real business: a deer processing management system for a butcher shop in Maine.

Claude read through the entire Loop 2.1 corpus — the whitepaper, the production code paper, the dev playbook, the restructuring paper, the coding standards — and came back with questions. Questions about scope, about the target application, about what "enterprise-level" means when there's one developer, about how the L21 hardware model maps to software architecture.

The conversation that followed lasted roughly eight hours. It produced an entire software methodology.

Part Three

Three Drafts and a Discovery

The first architecture was straightforward. Six loop types — Working, Compute, Vault, Filter, Signal, Presentation — connected by a single bus. It mapped cleanly to L21's hardware: the Working Loop was the intake point (like L21's Working Loop and Inject mechanism), the Compute Loop was the ALU, the Vault Loop was the Memory Loop, and so on. Simple. Obvious. Wrong.

Two problems surfaced almost immediately. First, a single bus is a shared failure domain. If the bus goes down, everything goes down. In L21, there are nine buses in four categories — the hardware model already solved this by having independent transport channels. The software architecture was ignoring that lesson. Second, multi-step operations — take an order, validate it, calculate pricing, store it, send a confirmation — had no orchestrator. The architecture was flat. Individual loops could process individual events, but nobody was driving the sequence.

Draft 2 introduced the multi-bus model. Four independent named buses: DATA (application data flow), VAULT (persistence operations), SIGNAL (outbound communications), SYNC (cross-device coordination). Each bus is its own failure domain with its own priority queue and its own contract validation. A failure on the Signal Bus doesn't touch the Data Bus. This came directly from studying how L21's nine buses work — the hardware model had already solved the isolation problem by making each bus physically independent.

Then came Draft 3 and the seventh loop type: the Workflow Loop. Pipeline specs — declared as data structures, not procedural code — define multi-step operations. The Workflow engine is generic; adding a new workflow means adding a new spec, not writing new orchestration code. A five-word failure vocabulary constrains what can happen when a step fails: Abort, Retry, Continue, Compensate, Escalate. Five words. That's it. Every failure in every workflow in every application built with this methodology is handled by one of those five words.

The five-word constraint is deliberate. It is easier to choose the right response from five options than from an open-ended design space. It forces the developer to think about failure at spec time, not at debug time. And it makes failure behavior auditable — you can look at any pipeline spec and know exactly what happens when each step fails, because the answer is one of five words.

State Reincarnation rounds out the workflow model. Transaction logs persist after every step. If the application crashes — and on a tablet running in a deer processing shed in Maine, things will crash — the Workflow engine reads the transaction log on restart and picks up where it left off. No lost orders. No half-processed payments. The crash is a recoverable event, not a data integrity crisis.

Part Four

The Standard, v1 Through v6

With three drafts behind it, the conversation shifted. The architecture wasn't just a design for the butcher app anymore. It was a methodology — a generalizable set of constraints and patterns for building any data-centric business application. Shea made the call: extract it into a standalone standard. The architecture document became the Loop MMT Standard.

Version 1 codified the seven loop types, the multi-bus model, the closure wall, pipeline specs, and eight governing principles. The development methodology took shape alongside the architecture: ten practices distilled from the L21 project's 320+ builds. Read before you write. Talk first, code second. Plan in phases, deliver in builds. The Verification Gantry is a fixed gate. Code is the persistence layer for architecture. The Operator owns decisions; pushback is a deliverable. Documentation is part of the product. Verify against source, not memory. Design around the memory boundary. This method is not a shortcut.

Practice 9 — "design around the memory boundary" — is the one that separates this from every other AI development approach. The AI forgets everything when a conversation ends. This is not a limitation to work around. It is the fundamental constraint that shapes the entire methodology. Documents are the only thing that survives the session boundary. Every architectural decision, every status update, every design choice that matters must exist in a document before the session closes. If it lives only in chat history, it is already dead.

Practice 10 — "this method is not a shortcut" — is the honest one. The structural investment that Loop MMT demands — the specification phase, the document governance, the verification layers, the handoff discipline — feels like overhead when you're staring at an empty editor. It pays back when you're not debugging a system built on assumptions that drifted across fifteen sessions.

Versions 2 and 3 of the Standard came from going back to the L21 hardware model with fresh eyes. A direct component-by-component comparison revealed two concepts the software architecture was missing. First, the gate — in L21, every loop has a gate that can selectively destroy data. In the MMT analog, Data Gates became lifecycle policies: Transit Gates on buses (consume, archive, or hold packets), Retention Gates on Vaults (active, archived, purged), and Workflow Gates on transaction logs. Second, the Observatory — L21's operator can observe the state of any component at any time without affecting its operation. The Observatory became a separate, reusable monitoring constellation that attaches to any Loop MMT application via passive bus observation.

These versions also produced the ninth principle: The system outlives its builders. This changed the trajectory of everything. It meant the standard had to address not just how to build software, but how to build software that remains comprehensible, maintainable, and evolvable after the people who built it move on. Self-verification (the constellation checks itself against its own blueprint), contract versioning (old and new packet formats coexist during migration), schema migration (Vault Loops automatically update their database schemas on startup), and dependency sunset protocols (every adopted dependency has a documented replacement plan) all trace back to this principle.

Version 5 produced the patterns inventory. A systematic walk through L21's twelve hardware component types yielded twenty-two patterns — and fourteen of them traced directly to a specific L21 component or operating technique. The Bridge pattern from L21's PM eject buffer. The Cascade pattern from PM1 → PM2 → TG1 → TG2 on the Big Loop. The Sentinel from the operator watching counter trends over time. The Replay pattern from L21's session recording files. The observation was striking: the hardware model, because it is minimal and observable, exposes computational patterns that conventional software buries under layers of abstraction. Loop MMT names them and makes them explicit.

Version 6 stress-tested the architecture against ten different application types: the butcher shop, a SaaS project manager, a restaurant POS system, an inventory/logistics platform, a real-time multiplayer game, a content management system, a personal finance tracker, a field service dispatch system, an educational platform, and a browser-based digital audio workstation. Nine worked. One — the DAW — revealed a hard boundary. The audio engine requires sub-millisecond latency where the cost of latency exceeds the cost of correctness. Loop MMT's bus validation adds overhead that is negligible for business logic but potentially fatal for sample-accurate audio processing.

The CMS was the more interesting result. It stressed every pattern in the catalog — content types as configurable schemas, version history via append-only Vault sub-patterns, media management through Dependency Gates, access control through the Auth Gate, real-time collaborative editing via the Sync Bus — and found no gaps. If a CMS doesn't break your architecture, your architecture covers a lot of ground.

All of this — the seven loop types, four buses, the closure wall, pipeline specs, the five-word failure vocabulary, Data Gates, the Observatory, self-verification, contract versioning, schema migration, dependency sunset protocols, twenty-two patterns, a scope boundary informed by ten stress tests — was designed in a single conversation. About eight hours of work. No code was written. The Standard existed only as a specification. The butcher app existed only as the example that grounded the specification in concrete decisions.

Part Five

The Evening Sessions

The first day did not end with the Standard.

That evening, Shea ran parallel conversations — multiple Claude instances working different problems simultaneously. One conversation took an external review of the build plan and picked it apart honestly, identifying two problems worth solving: the interaction between compensation, Split-Merge, and parallel branch failure states (solved by extending pipeline specs with per-branch compensation declarations), and the persistence layer reliability window during crashes (solved by write-ahead logging — an INTENT record before step execution and a COMPLETED record after, creating a three-state recovery model that closes the crash window).

Another conversation produced the first Loop MMT white paper — roughly 5,500 words, styled HTML, covering the full concept for a layered audience of developers, technical leadership, and the broader AI development conversation. The white paper states plainly that no production application has shipped yet. Shea specified this: honest framing over optimism.

A third conversation explored commercialization paths. An earlier document called the "Sovereign Logic Foundry" — a commercial model for Loop MMT — got an honest critique: the commercial model was running ahead of any production proof. The core proposition — selling a governed process rather than developer hours — was sound but premature. The conversation pivoted to concrete paths: high-value employment as an AI Development Lead, AI code rescue consulting, shipping the butcher app as a sovereign product, technical publishing, paid workshops, open-sourcing the standard with paid templates, and local business software for trades clients. All paths converge on one prerequisite: ship the Butcher Constellation first.

Part Six

The Documentation Explosion

The second day was about building the corpus.

If the Standard is the law, the supporting documents are the institutions that make the law operational. A constitution without a legislature, a judiciary, a civil service, and a tax code is just a nice essay. The Standard needed operational documents — guides, templates, standards-for-standards, behavioral specifications, test frameworks — that together make it possible for someone to actually use the methodology.

The day started with a gap. The Glossary was at version 5, but the Standard had moved to version 7 overnight with additions (the Translator pattern, Failure Strategy Assignment, the Constellation Map, Noted Future Extensions). The Glossary didn't define these new terms. This was not a crisis. It was worse: it was a demonstration of the very problem the methodology needed to solve. Documents can drift out of sync with their dependencies silently, and no mechanism existed to catch the drift automatically.

The solution was a complete redesign of Section 17 of the Standard — the Document Stack. The old §17 was a list of documents. The new §17 is a governance system. It introduces a Document Registry (a versioned manifest tracking every document's name, version, last updated date, dependencies, and status), four status values (Current, Review Required, Draft, Archived), a formal dependency graph rooted in the Standard, version pinning for loading packs, document authorship rules (a version increment equals Operator approval — the AI does not unilaterally advance version numbers), and a mandatory Document Hygiene Protocol at session close. When a document's upstream dependency changes, downstream documents are automatically flagged as Review Required. The flag is a property of the event, not a manual step.

The Glossary was updated to v6, then v7, then v8 as the day progressed. Each bump added terms introduced by the latest Standard version. By the end, the Glossary contained entries spanning the full vocabulary: from L21 hardware terms (ALU, Big Loop, Carry Flag) through MMT architecture terms (Closure Wall, Constellation, Dependency Gate) to development process terms (Auditor, Circuit Breaker, Event Ledger, Finding, Session ID). Every concept has a precise definition tagged with its origin: L21, MMT, BOTH, or DEV.

The Interaction Guide went through three versions. Version 1 was the Operator's guide — what to do, in what order, with which documents. Version 2 merged the Operator's guide with an AI guide covering the AI's behavioral rules for each conversation type — what to verify, when to push back, what to never do. Version 3 added the Coordinator and Auditor roles, session identity, the event ledger, routing manifests, the decision queue, and the five-layer safety architecture. The final document is split into two parts: Part I for the Operator, Part II for the AI. Both parties read their own section and understand the other's.

The Coding Standards reached v2, codifying the full prefix taxonomy (bus_, loop_, pkt_, wf_, gate_, v_, f_, e_, h_, c_), the single-purpose function rule, the NASA-inspired error-case-before-happy-path convention, and the seven-item delivery checklist that every module must pass before it can be called done.

The Conversation Prompt Templates document — v3 by end of day — formalized something that had been informal: exactly what to say when opening, continuing, or closing each of the six conversation types. Fill-in-the-blank templates with concrete examples drawn from the Butcher Constellation. Not optional. The prompt structure encodes the methodology's loading discipline — give each conversation exactly what it needs and nothing more.

Part Seven

The Coordinator and the Auditor

The most architecturally significant documents produced on March 30 were the role specifications for two new AI conversation types.

The Coordinator Operating Instructions define the behavioral specification for the Coordinator conversation — a persistent AI session that manages the logistics of an entire project. The Coordinator maintains the event ledger (an append-only chronological record of everything that happens in the project), tracks module status, triages Integrator findings, surfaces decisions to the Operator in a priority queue, and prepares routing manifests for document packages moving between conversations.

The event ledger is the conceptual heart of the development process. It is the source of truth. All other project documents — the progress dashboard, the decision log, the session log — are materialized views derived from the ledger. Nothing in the ledger is edited. If a status was wrong and gets corrected, that's two events: the original and the correction. Both remain. The Coordinator produces an updated ledger artifact after every event. If the Coordinator crashes, the most recent artifact is the recovery point.

The Coordinator has boundaries. It does not write code. It does not verify code against the spec. It does not make architectural decisions. It does not apply spec changes without explicit Operator approval. These boundaries have the same structural status as the closure wall that constrains loop capabilities. The Coordinator is expected to push back when it detects conflicts — routing to a blocked module, spec changes that break dependencies, decisions that contradict earlier decisions. The Operator can always override. The override is always recorded in the ledger.

The Auditor Operating Instructions define a different kind of conversation entirely. The Auditor is intermittent — opened for a check cycle, loaded with the current document set, run through a reconciliation check suite, and closed after delivering its report. It does not persist between cycles. Each session is a clean room with no memory of previous sessions. A stateless Auditor cannot drift.

The Auditor's twenty checks fall into three categories. Count Reconciliation: do totals match across documents? Reference Integrity: do identifiers in one document exist in the documents they point to? Sequence Integrity: are ordered events consistent — do timestamps flow forward, do spec changes follow decisions and precede propagation? The checks are mechanical and binary. The Auditor does not recommend corrective action. It does not assess quality. It compares documents and reports mismatches. The Operator reads the report and decides what to do.

The design decision to make the Auditor stateless was deliberate. A persistent Auditor is tempting because it could watch in real time. But real-time watching requires persistent state, and persistent state requires trust, and trust requires verification — which is the problem the Auditor was created to solve. The intermittent design breaks the recursion. Each session is a clean room. It trusts nothing except the documents it is handed and the checks it was built to run.

Together, the Coordinator and Auditor join the Integrator (which verifies code against the spec), the Module Workers (which build the code), and the Operator (the human) to form a five-role development process with a five-layer safety architecture. Layer 1: Coordinator self-checks catch immediate errors. Layer 2: the Auditor catches cross-document drift. Layer 3: the Integrator incidentally catches stale loading packs (a module built against the wrong contracts fails verification). Layer 4: document fingerprinting catches silent failures — operations reported as completed but that didn't actually change the document. Layer 5: Operator touch points — every spec change, every phase transition, every circuit breaker trip requires the human.

Part Eight

The Supporting Corpus

The remaining documents filled gaps that became visible as the methodology solidified.

The Developer Guide is a standalone walkthrough of the entire methodology — all six phases, all five roles, every practice, every failure mode — written so that someone who has never touched the corpus can run a project from it alone. Seventeen sections. It is v1 and it says so: it pre-dates a completed real project and will be updated after the Butcher Constellation run produces lived experience.

The Operator Orientation is the entry-point document for someone encountering Loop MMT for the first time. Where the Developer Guide is comprehensive, the Orientation is accessible. It covers the mental model (an application is a constellation of loops connected by buses, the development process mirrors this structure, documents are the bus between sessions), the six phases, the five roles, the session cycle, and where to go next. It is read once before starting a first project and not loaded into project conversations.

The Technical Design Document Standard governs when and how to write TDDs — feature-level design decisions too detailed for the Constellation Spec but too important to live only in chat history. It includes a seven-section structure, a trigger decision tree for when a TDD is warranted, and a worked example. A notable correction happened during its creation: Claude wrote that "a TDD takes 30 minutes to 3 hours to write." Shea pointed out that the AI writes TDDs in about two minutes. The passage was corrected to reflect the actual cost framing: the writing cost is negligible; the value question is whether the clarity gained prevents wasted implementation time.

The Handoff Standard codifies the most critical document in the entire methodology: the session handoff. Every session ends with one. No exceptions. Seven required sections. The document includes weak and strong comparison examples so the AI can see the difference between a handoff that transfers state effectively and one that doesn't. The Handoff Standard is compact enough to go in every loading pack — and it does. Every loading pack includes this document.

The Patterns Reference — v3 by end of day — is the complete implementation guide for all thirty Loop MMT patterns. (The catalog grew from twenty-two to thirty as the stress tests and document work revealed additional patterns.) Each entry includes what the pattern is, its L21 analog, when to use it, how it works, a complete code example, implementation constraints, and related patterns. Six categories: Core (nine patterns that constrain constellation design), Data Flow, Workflow, Resilience, Infrastructure, and Scale. Twenty-four of the thirty patterns trace directly to a specific Loop 2.1 hardware component or operating technique.

The Test Suite and Gantry Specification defines "gantry green" across three tiers. Tier 1: module self-check (does this loop satisfy its own contracts?). Tier 2: Integrator cross-check (do modules satisfy each other's contracts?). Tier 3: final constellation gate (does the wired system hold up under scenario tests and injected failures?). The document includes a two-track testing model — an AI static analysis checklist for things the AI can verify by reading code, and JavaScript harness templates for things that require execution. It is a universal template: each project instantiates a Project Gantry Document during Phase 0 by populating all fill-in slots. Phase 0 is not complete until the Project Gantry Document exists.

Part Nine

The Standard at v11

By the end of March 30, the Standard itself had advanced from v6 to v11. Each version bump addressed something specific.

Version 7 added the Translator pattern (the data-scrubbing responsibility for loops that adopt external dependencies), Failure Strategy Assignment guidance (a decision framework for when to use which of the five failure words — Escalate when the cost of a wrong automatic decision exceeds the cost of delay, Retry when the failure is likely transient, Abort when continuing would produce corrupt state, Continue when the failed step is supplementary, Compensate when earlier steps must be undone), the Constellation Map (a design-time topology visualization generated from the spec), and Noted Future Extensions (multi-tenant scoping flagged as a future pattern rather than speculatively designed now).

Version 8 was the §17 rewrite — Document Registry, dependency graph, version pinning, authorship rules, the Document Hygiene Protocol.

Versions 9, 10, and 11 absorbed the Coordinator, the Auditor, the event ledger, session identity, the five-layer safety architecture, the Divergence Circuit Breaker, the full role taxonomy, auto-routing, and the complete development methodology that governs how the documents, the conversations, and the code all fit together. The Standard grew from a software architecture document into a comprehensive methodology specification — eighteen sections covering everything from loop types to document governance to the five-layer safety architecture to the coding standards prefix taxonomy.

Section 16 — Development Methodology — is the largest and most significant addition. It defines six conversation types (Specification, Module, Integrator, Coordinator, Auditor, Bug Fix), the event ledger as the source of truth, session identity (ROLE-YYYYMMDD-HHMM-SEQ), the Coordinator–Integrator interface, auto-routing and the decision queue, and the Divergence Circuit Breaker (if a single Auditor check cycle produces three or more failures, routing pauses until the Operator investigates). It makes the development process itself auditable, replayable, and structurally governed — the same properties the architecture gives to the software it produces.

Part Ten

What Exists and What Doesn't

This is the honest accounting.

As of March 30, 2026, the Loop MMT methodology is documented by a corpus of twenty documents: The Standard v11 — the complete methodology in eighteen sections. The Glossary v8 — shared vocabulary, every concept precisely defined. The Coding Standards v2 — naming, structure, prefix taxonomy. The Interaction Guide v3 — how work gets done, for the Operator and the AI. The Coordinator Operating Instructions — the Coordinator's behavioral specification. The Auditor Operating Instructions v1 — the reconciliation check suite. The Developer Guide v1 — standalone comprehensive walkthrough. The Operator Orientation v1 — the entry point for new users. The Conversation Prompt Templates v3 — fill-in-the-blank templates for all six conversation types. The TDD Standard v1 — when and how to write technical design documents. The Handoff Standard v1 — the session handoff specification. The Patterns Reference v3 — all thirty patterns with complete implementation guides. The Test Suite and Gantry Specification v1 — the three-tier verification framework.

Every document is HTML with a consistent visual format: a three-skin system (OG, Winamp, Sunrise), a TOC sidebar where the document warrants one, monospace typography for the header and navigation, and a clean sans-serif body. Every document carries a version number. Every version increment represents Operator approval. The dependency graph is rooted in the Standard: a Standard version bump touches everything, and the propagation is tracked.

What does not exist: code. Not one line of application code has been written. The Butcher Constellation — the deer processing management system that was the original impetus for the entire methodology — sits at Phase 0. No constellation spec. No action plan. No loading packs. No infrastructure. No loops. No buses. The methodology exists entirely in specification.

This is deliberate. The talk-first discipline that governs individual sessions also governed the creation of the methodology itself. Every section of the Standard, every pattern in the catalog, every role in the taxonomy was designed in conversation before it was written down. The pre-production investment — the two days of specification, documentation, and stress-testing — is the methodology's own Practice 10 in action: this method is not a shortcut.

The test ahead is whether the specification holds up under the pressure of building real software. The Standard was stress-tested against ten application types in the abstract. It has not been stress-tested by a real build. The Butcher Constellation is that test. When it ships — the deer processing management system running on a tablet in a butcher shop in Maine, managing orders, tracking processing stages, generating invoices, handling multi-device sync, surviving crashes — the methodology will have earned its claims.

Until then, what exists is a bet. A carefully specified, thoroughly documented, honestly framed bet that the lessons of 325 builds of a manual flow computer, formalized into a software architecture and development methodology, can make it possible for one person with an AI assistant to build production software that works, that lasts, and that can be understood by whoever comes next.

Epilogue

On the Shape of the Thing

There is something worth noticing about how the corpus came together.

The first document was the Standard, and it was designed in conversation — eight hours of talking through architecture before a single word was written down. The second wave was the supporting documents: the Glossary, the Interaction Guide, the Coding Standards, the handoff conventions, the build plan. The third wave was the meta-documents: the Coordinator Operating Instructions, the Auditor Operating Instructions, the Gantry Specification — documents that govern how the other documents get used. The fourth wave was the accessibility layer: the Developer Guide, the Operator Orientation, the Conversation Prompt Templates — documents that make it possible for someone new to enter the system.

Each wave addressed a different kind of problem. The Standard answers "what is this?" The supporting documents answer "how does this work?" The meta-documents answer "how do we keep this consistent?" The accessibility documents answer "how do I start?"

This layering was not planned in advance. It emerged from the work. The Glossary was written because terms were being used inconsistently. The Document Registry was invented because the Glossary drifted out of sync with the Standard. The Auditor was designed because the Coordinator needed an independent check. The Developer Guide was written because the corpus had grown complex enough that a single entry point was necessary. Each document exists because a specific problem demanded it, not because a checklist said it should.

The methodology claims that it evolves by discovering what's missing when real problems hit real constraints. The document corpus is the first proof of that claim. It was not designed top-down. It was grown from the inside out, one gap at a time, over two days.

Twenty documents. Roughly 45,000 words of specification. Thirteen HTML files in the project knowledge base. Zero lines of application code. One developer. One AI. Two days.

What comes next is in The Four-Day Build.

Five days after this weekend, the Operator called out of work, sat down at the same blue desk in the same RV, loaded the documents into a fresh AI session that remembered nothing, and began building the Butcher Constellation. That story — what happened when the methodology met reality — is Volume II.