autonomous-coding-toolkit 1.0.0

package/docs/plans/2026-02-22-research-unconventional-perspectives.md

@@ -0,0 +1,528 @@
+# Research: Unconventional Perspectives on Autonomous Coding
+
+> **Date:** 2026-02-22
+> **Status:** Research complete
+> **Method:** Cross-domain analogy mining + synthesis of 10 parallel research papers
+
+## Executive Summary
+
+Three insights that none of the other 10 research papers would have found:
+
+1. **The toolkit is an immune system, not an assembly line.** Every other paper treats the pipeline as a manufacturing process (input -> stages -> output). But the lesson system, quality gates, and failure-pattern learning more closely resemble an adaptive immune system -- where each encountered bug produces "antibodies" (lessons) that provide lasting protection. This reframe changes the design priorities: invest in immune memory diversity and speed-of-response, not in pipeline throughput optimization.
+
+2. **Competitive mode is a jazz ensemble, not a tournament.** The competitive-landscape and multi-agent papers frame dual-track execution as two agents competing, with a judge picking a winner. But the mandatory best-of-both synthesis means the real pattern is _improvisation within structure_ -- like a jazz combo where two soloists play over the same changes, and the bandleader (judge) weaves together the best phrases from each. This reframe suggests the judge should be a _synthesizer_, not a _scorer_.
+
+3. **The single biggest blind spot across all 10 papers is _succession_.** Ecological succession describes how pioneer species colonize barren ground and create conditions for more complex species. The toolkit treats every batch as equal. But batch 1 of any plan is a pioneer -- it creates the files, tests, and structures that all subsequent batches depend on. A failure in batch 1 cascades differently than a failure in batch 6. No paper addresses batch-position-dependent failure dynamics or pioneer-batch hardening.
+
+---
+
+## Per-Topic Unconventional Additions
+
+### 1. Plan Quality -- Military Mission Command (Auftragstaktik)
+
+#### The Analogy
+
+In German military doctrine, _Auftragstaktik_ (mission command) distinguishes between the _Auftrag_ (the objective and intent) and the _Befehl_ (specific orders). Subordinate commanders receive the intent ("take that hill by dawn") and choose their own methods. This doctrine emerged because fog of war makes detailed plans obsolete within minutes of contact with the enemy.
+
+Clausewitz's famous observation: "No plan survives contact with the enemy." The autonomous coding equivalent: no plan survives contact with the actual codebase. The plan-quality paper documents this -- stale plans, no-op tasks, batches that encounter code already changed by earlier batches. These are textbook friction (Clausewitz's _Friktion_) -- the gap between theory and execution caused by real-world complexity.
+
+#### What It Adds to the Other Paper
+
+The plan-quality paper recommends "structured intent" over "complete code in plan" -- provide the contract, not the implementation. This is exactly Auftragstaktik. But the paper stops at the plan level. Mission command goes further: it requires _two levels up_ understanding. Each subordinate knows not just their own objective but their commander's objective and their commander's commander's objective. This way, when the plan breaks, the subordinate can make intelligent decisions about what to do next.
+
+The plan-quality paper's proposed task template has `Contract`, `Test`, `Verify`, and `Constraints`. What's missing is `Intent` -- why this task exists in the context of the whole feature. When a batch fails and the agent retries, it needs to know not just "what to do" but "why we're doing this" to make intelligent adaptations.
+
+#### Concrete Design Implication
+
+Add an `Intent` field to the plan task template:
+
+```markdown
+### Task N: [Name]
+**Intent:** This task exists because [feature goal] requires [capability]. In the larger plan, this task enables Batch N+1 to [downstream dependency].
+```
+
+This gives the retry agent the same decision-making power that Auftragstaktik gives to a field commander: freedom to deviate from the specific method while maintaining alignment with the larger objective.
+
+---
+
+### 2. Prompt Engineering -- Musical Rehearsal Marks and Call-and-Response
+
+#### The Analogy
+
+In orchestral music, a conductor doesn't tell violinists which fingers to use. The score provides _rehearsal marks_ -- structural signposts (letters A, B, C or measure numbers) that let performers navigate the piece. When something goes wrong in performance, the conductor calls out "from letter C!" and everyone resynchronizes.
+
+In jazz, _call-and-response_ is a conversational structure where one musician plays a phrase (the "call") and another answers it (the "response"). This creates structure without rigidity -- the response must be _related_ to the call but is not predetermined.
+
+#### What It Adds to the Other Paper
+
+The prompt-engineering paper recommends structured planning instructions (+4% on SWE-bench). But it treats the prompt as a monologue -- a set of instructions the agent receives and follows. Musicians know that performance quality depends on _navigation structure_, not instruction density.
+
+The top SWE-bench agents (SWE-agent, OpenHands) use 5-phase workflows that function as rehearsal marks: Explore, Analyze, Test, Implement, Verify. These aren't detailed instructions -- they're structural landmarks that keep the agent oriented. The prompt paper identifies this but doesn't name the principle.
+
+The call-and-response pattern maps to retry prompts. Currently, the retry escalation _tells_ the agent what went wrong. A call-and-response structure would _ask_ the agent to articulate what went wrong first, then provide the failure digest as confirmation or correction. Research on self-correction confirms this: "ask yourself what went wrong" prompts outperform "be aware that you failed" prompts.
+
+#### Concrete Design Implication
+
+Structure the batch prompt as rehearsal marks, not instructions:
+
+```
+[A] INVESTIGATE — Read the files you'll modify. Note discrepancies with the plan.
+[B] TEST-FIRST — Write failing tests for each task. Confirm they fail.
+[C] IMPLEMENT — Make each test pass. One task at a time.
+[D] VERIFY — Run the full quality gate. All tests must pass.
+[E] COMMIT — Commit completed work. Update progress.txt.
+```
+
+On retry, use call-and-response: "Before reading the failure digest, describe in one sentence what you think went wrong. Then read the digest below and compare."
+
+---
+
+### 3. Context Utilization -- Ecological Carrying Capacity
+
+#### The Analogy
+
+In ecology, _carrying capacity_ (K) is the maximum population an environment can sustain. Below K, population grows. At K, resources are fully utilized. Above K, the population crashes as resources are exhausted.
+
+The context window is a habitat with carrying capacity. The "population" is tokens of information. Below carrying capacity, adding more tokens improves the agent's performance (more relevant context = better decisions). At carrying capacity, the agent is using context optimally. Above carrying capacity, performance crashes -- the "context rot" documented in the Chroma study.
+
+#### What It Adds to the Other Paper
+
+The context-utilization paper documents the degradation curve and recommends a 6000-10000 char injection budget. But it treats context as a linear resource ("more is better up to a point, then worse"). Ecological carrying capacity has a more nuanced dynamic: _what_ occupies the capacity matters as much as _how much_.
+
+In ecology, invasive species crowd out native species, reducing ecosystem productivity even below carrying capacity. In context windows, irrelevant injected context is an invasive species -- it consumes attention budget without contributing to task performance. The Factory.ai finding that "indiscriminate context stuffing" is counterproductive is the token-ecology equivalent of an invasive species outbreak.
+
+The ecological insight is that healthy ecosystems have _niche partitioning_ -- different species occupy different ecological niches without competing. Context sections should occupy different informational niches: progress.txt occupies the "what happened before" niche, failure patterns occupy the "what to avoid" niche, referenced files occupy the "what exists now" niche. When two sections compete for the same niche (e.g., progress notes and git log both conveying "recent history"), one should be pruned.
+
+#### Concrete Design Implication
+
+Audit the context assembler for _niche overlap_. Currently, `run-plan-context.sh` injects recent commits AND progress notes -- both serve the "recent history" niche. Either merge them (a structured summary combining commit messages with progress notes) or prune one. The goal is not to fill the carrying capacity -- it's to maximize _niche diversity_ per token.
+
+---
+
+### 4. Competitive Landscape -- Niche Partitioning in Ecology
+
+#### The Analogy
+
+In ecology, Gause's competitive exclusion principle states that two species competing for the identical niche cannot coexist indefinitely -- one will outcompete the other. But species _can_ coexist if they partition the niche -- occupying slightly different roles in the same ecosystem. Darwin's finches survived by partitioning the seed-eating niche: different beak shapes for different seed sizes.
+
+#### What It Adds to the Other Paper
+
+The competitive-landscape paper positions the toolkit against 10 competitors but frames the competition spatially ("unique features vs. gaps"). Ecology would frame it temporally and dynamically. The market is not a static feature matrix -- it's an evolving ecosystem where competitive exclusion will eliminate tools that occupy the same niche as stronger competitors.
+
+The toolkit's niche is _pipeline orchestration for Claude Code power users_. No competitor occupies this exact niche. But the niche is adjacent to Claude Code itself (which could absorb these features) and to Devin (which provides autonomous execution for a broader audience). The ecological question is: will the toolkit's niche remain viable, or will adjacent species (Claude Code with built-in pipeline features, Devin with better quality gates) consume it?
+
+The defensive strategy from ecology is _niche hardening_ -- making the toolkit's niche deeper and more specialized so that generalist competitors can't easily subsume it. The lesson system, competitive dual-track, and batch-type-aware prompt selection are all niche-hardening features.
+
+#### Concrete Design Implication
+
+Stop chasing feature parity with competitors (IDE support, cloud hosting, multi-model). Instead, deepen the niche: more lesson types, richer failure pattern learning, cross-project lesson sharing, plan quality scoring. These are features that generalist tools won't build because they serve too narrow an audience -- which is exactly the point.
+
+---
+
+### 5. Agent Failure Taxonomy -- Swiss Cheese Model (Aviation Safety)
+
+#### The Analogy
+
+James Reason's Swiss cheese model of accident causation describes how safety barriers are like slices of Swiss cheese: each has holes (weaknesses), but the holes are in different places. An accident occurs only when the holes in multiple slices align, allowing a hazard to pass through all barriers.
+
+In aviation, barriers include: pilot training, checklists, crew resource management, air traffic control, maintenance inspections, and aircraft design redundancy. No single barrier is sufficient. Safety comes from the _orthogonality_ of barriers -- different barriers catch different failure types.
+
+#### What It Adds to the Other Paper
+
+The failure-taxonomy paper identifies six failure clusters and maps them to the toolkit's coverage, finding 40-55% of failures uncovered. But it treats each failure type independently. The Swiss cheese model adds the insight that failure _combinations_ matter more than individual failures.
+
+The toolkit's barriers are: lesson-check (syntactic anti-patterns), test suite (behavioral correctness), ast-grep (structural patterns), test-count monotonicity (test integrity), git-clean (completeness), and the verification stage (spec compliance). These are well-differentiated slices. But the paper identifies three _uncovered failure types_ (specification misunderstanding, planning errors, context degradation) -- these are holes that exist in _every_ slice simultaneously. No current barrier catches "agent solving the wrong problem."
+
+The Swiss cheese insight is that adding more barriers of the same type (more linting rules, more grep patterns) doesn't close these aligned holes. You need a fundamentally different type of barrier -- one that operates at the specification level, not the implementation level.
+
+#### Concrete Design Implication
+
+Add a "specification echo-back" barrier -- a new slice of Swiss cheese that catches specification misunderstanding. Before executing code, the agent restates the task intent in its own words. A simple diff between the agent's restatement and the plan's intent section catches misalignment before implementation begins. This is a different _type_ of barrier, not more of the same type.
+
+---
+
+### 6. Verification Effectiveness -- Epidemiological Contact Tracing
+
+#### The Analogy
+
+When a disease outbreak occurs, epidemiologists perform _contact tracing_ -- working backward from confirmed cases to identify everyone the infected person contacted. The goal is to find and isolate potential carriers before they spread the disease further.
+
+R0 (basic reproduction number) measures how many new infections each case generates. If R0 > 1, the outbreak grows exponentially. If R0 < 1, it dies out.
+
+#### What It Adds to the Other Paper
+
+The verification paper quantifies bug detection rates for each pipeline stage. But it treats each bug as independent. Bugs in code, like diseases in populations, have an R0. A bug in a shared utility function has high R0 -- it infects every module that imports it. A bug in a leaf function has R0 near zero -- it stays local.
+
+The toolkit's quality gates check for bugs but don't trace their _spread_. When a bug is found in batch 5, the gates don't check whether batches 1-4 introduced shared code that propagates the bug to other modules. This is the equivalent of treating a COVID case without contact tracing.
+
+The epidemiological insight is that _prevention_ (vaccination) is cheaper than _treatment_ (hospitalization). The toolkit invests heavily in treatment (finding bugs after they're written) but could invest more in prevention (making bugs impossible to write). Property-based testing, which the verification paper recommends, is vaccination -- it tests invariants that prevent entire classes of bugs, not just specific instances.
+
+The herd immunity concept also applies: if enough of the codebase is covered by property tests (the "vaccinated population"), then even untested code benefits from the surrounding protection (because integration tests exercise it through tested interfaces).
+
+#### Concrete Design Implication
+
+Add "bug R0 estimation" to the failure digest. When a quality gate catches a bug, classify it as high-R0 (shared utility, imported by many) or low-R0 (leaf function, local scope). High-R0 bugs get immediate attention and trigger a scan of downstream consumers. Low-R0 bugs are fixed in place. This is triage by spread potential, not just severity.
+
+---
+
+### 7. Cost/Quality Tradeoff -- Theory of Constraints (Goldratt)
+
+#### The Analogy
+
+Eli Goldratt's Theory of Constraints (TOC) states that every system has exactly one constraint (bottleneck) that limits throughput. Optimizing anything other than the constraint produces zero improvement in system throughput. The Five Focusing Steps: Identify the constraint -> Exploit it -> Subordinate everything else to it -> Elevate the constraint -> Repeat.
+
+#### What It Adds to the Other Paper
+
+The cost-quality paper models costs per batch, per mode, per model. It identifies prompt caching as the biggest lever (83% reduction). But it implicitly assumes the constraint is _cost_. What if the constraint is something else?
+
+For the toolkit, the actual throughput constraint is likely _plan quality_, not execution cost. The plan-quality paper found that plan quality is "worth roughly 3x the execution capability of the model itself." If plans are the bottleneck, then optimizing execution costs (model routing, caching, batch API) is optimizing a non-constraint -- it makes the execution stage faster and cheaper without increasing total throughput of _successful features_.
+
+TOC says: don't balance capacity, balance _flow_. If plan creation takes 60 minutes and execution takes 20 minutes, making execution 50% cheaper doesn't matter. The bottleneck is plan creation.
+
+Goldratt's "drum-buffer-rope" model suggests the pipeline should be paced by the bottleneck (plan quality), with buffers before it (design exploration time) and ropes pulling work through it (validation that plans meet quality thresholds before execution begins).
+
+#### Concrete Design Implication
+
+Implement the plan-quality scorecard (recommended in the plan-quality paper) as the _drum_ of the system. Don't start execution until plan quality exceeds 0.8. This subordinates execution to the constraint (plan quality), which TOC predicts will increase overall feature completion rate more than any execution-level optimization.
+
+---
+
+### 8. Multi-Agent Coordination -- Crew Resource Management (Aviation)
+
+#### The Analogy
+
+After a series of crashes caused not by mechanical failure but by crew miscommunication, the aviation industry developed Crew Resource Management (CRM). CRM training teaches pilots and crew to: use standardized communication protocols, challenge authority when safety is at risk, maintain shared situational awareness, and conduct structured briefings and debriefings.
+
+The key CRM insight: most multi-crew accidents are not caused by one person's error -- they're caused by the crew failing to catch or communicate about that error. The error is the first event; the failure to catch it is the accident.
+
+#### What It Adds to the Other Paper
+
+The multi-agent paper catalogs coordination patterns (pipeline, debate, ensemble, etc.) and maps them to the toolkit. But it focuses on _architecture_ -- how agents are wired together. CRM focuses on _communication quality_ within any architecture.
+
+The MAST study found that inter-agent misalignment causes 37% of multi-agent failures. CRM addresses exactly this: the 1977 Tenerife disaster (583 deaths) was caused not by pilot incompetence but by _communication failure_ between the flight crew and tower. The captain's authority gradient prevented the first officer from asserting a safety concern.
+
+The toolkit's team mode has an authority gradient problem: the implementer generates code, the reviewer evaluates it. But the reviewer is the same model -- creating what CRM calls "authority gradient" (the reviewer may defer to the implementer's apparent confidence). The Berkeley MAST study confirms this: "conformity bias / groupthink" where agents reinforce each other's errors.
+
+CRM's solution is the _sterile cockpit rule_ -- below 10,000 feet, no non-essential conversation. Applied to the toolkit: during critical execution phases (integration batches, retry attempts), restrict the agent's context to only task-essential information. No progress notes from previous batches, no recent commit logs -- just the task, the relevant files, and the quality gate requirements.
+
+#### Concrete Design Implication
+
+1. Implement a "sterile cockpit" mode for critical and retry batches: strip non-essential context, provide only the task and directly relevant files.
+2. Use different models for implementer and reviewer to break the authority gradient (the multi-agent paper already recommends this, but CRM provides the _why_: homogeneous crews amplify errors).
+3. Add a structured "briefing" at the start of each batch (the investigation-first instruction from the prompt paper) and a structured "debriefing" at the end (append to progress.txt in a structured format).
+
+---
+
+### 9. User Adoption -- Sports Periodization
+
+#### The Analogy
+
+In sports science, _periodization_ structures training into cycles: macrocycles (season-long), mesocycles (weeks), and microcycles (days). Athletes don't train at maximum intensity continuously -- they alternate between high-load phases (building capacity) and low-load phases (recovery and skill development). Attempting to train at maximum intensity every day leads to overtraining syndrome: decreased performance, injury, and burnout.
+
+Anders Ericsson's research on _deliberate practice_ shows that expertise develops through focused practice on specific weaknesses, not through general repetition. A pianist doesn't play the whole concerto repeatedly -- they isolate the difficult passages and drill them.
+
+#### What It Adds to the Other Paper
+
+The user-adoption paper identifies that the toolkit's rigid six-stage pipeline causes adoption friction. Its solution is progressive disclosure: start simple, unlock complexity. But progressive disclosure is spatial (what features to show) -- periodization adds a temporal dimension (when to introduce complexity).
+
+A new user doesn't need to learn the full toolkit on day one. But they also shouldn't learn it in a single progressive climb. The periodization model suggests _cycles_:
+
+- **Week 1 (Foundation):** Run pre-made plans. Experience quality gates. Build trust.
+- **Week 2 (Skill):** Write your own plans. Learn plan quality patterns. Practice TDD.
+- **Week 3 (Integration):** Use /autocode. Full pipeline with brainstorming. Higher autonomy.
+- **Week 4 (Recovery):** Review what worked. Submit lessons from your experience. Customize.
+
+This is not just "start simple" -- it's a structured learning progression with deliberate practice on specific skills and recovery periods for reflection.
+
+The "coaching vs. playing" distinction is also relevant. The toolkit currently acts as a player (executing code). For adoption, it should also act as a coach -- explaining why quality gates matter after the user sees them work, not before.
+
+#### Concrete Design Implication
+
+Add a "training mode" that structures the first-month experience:
+1. First run: execute an example plan with verbose quality gate output explaining what each check does and why
+2. First plan: the toolkit validates the user's plan and explains how to improve it before execution
+3. First failure: the toolkit walks through the retry mechanism, showing what context it injects and why
+4. First lesson: the toolkit guides the user through `/submit-lesson`, demonstrating the feedback loop
+
+---
+
+### 10. Lesson Transferability -- Biological Immune System (Adaptive vs. Innate)
+
+#### The Analogy
+
+The vertebrate immune system has two layers:
+
+1. **Innate immunity:** Fast, non-specific. Physical barriers (skin), inflammation, phagocytes. Responds identically to any pathogen. No memory.
+2. **Adaptive immunity:** Slow first response, highly specific. B-cells produce antibodies targeting exact pathogens. T-cells kill infected cells. Creates _immunological memory_ -- second exposure triggers faster, stronger response.
+
+Vaccination works by exposing the adaptive immune system to weakened pathogens, building memory without suffering the disease.
+
+#### What It Adds to the Other Paper
+
+The lesson-transferability paper maps beautifully onto immune system biology:
+
+- **Innate immunity = universal lessons.** "Log before fallback" is like skin -- it protects against everything, requires no learning, and is always active. These are the ~25 universal-scope lessons.
+- **Adaptive immunity = project-specific lessons.** "Hub.cache access patterns" is a specific antibody -- it only fights one pathogen (one codebase's anti-pattern) but fights it with precision. These are the ~2 project-specific lessons.
+- **Vaccination = community lessons.** When another user submits a lesson from their production failure, they're providing a weakened pathogen that builds your project's immunity without suffering the bug.
+
+But the immune analogy reveals something the paper misses: **autoimmune disorders**. When the immune system attacks the body's own healthy cells, you get autoimmune disease. When a lesson system produces false positives -- flagging correct code as buggy -- it's an autoimmune response. The paper identifies false positive risk but doesn't name the mechanism.
+
+In immunology, autoimmune disorders are prevented by _clonal selection_ -- immune cells that react to self-antigens are eliminated during development. The lesson system equivalent: during lesson creation (the "development" phase), test the lesson against known-good code. If it triggers on good code, it's an autoimmune antibody and must be refined or eliminated.
+
+The immune system also has _tolerance_ mechanisms -- it learns to stop reacting to benign substances (like food proteins). The lesson system needs tolerance: when a finding is repeatedly dismissed as a false positive, the system should learn to suppress it for that context. This is what DeepSource's relevance engine and Semgrep's AI triage provide -- immune tolerance for code analysis.
+
+#### Concrete Design Implication
+
+1. Add "clonal selection" to the lesson creation process: before merging a new lesson, run it against a corpus of known-good code (the toolkit's own codebase, for example). If it triggers, refine the pattern.
+2. Add "immune tolerance": track dismissals per lesson per project. After N dismissals for the same project, automatically suppress that lesson for that project with a note in the scan output ("suppressed: 5 dismissals").
+3. Classify lessons as innate (universal, always active) or adaptive (scope-filtered, learned from specific exposure).
+
+---
+
+## Cross-Cutting Synthesis
+
+### Meta-Patterns
+
+**1. Orthogonality Beats Redundancy**
+
+Every domain says the same thing differently:
+- Aviation (Swiss cheese): barriers must cover different failure modes
+- Ecology (niche partitioning): organisms coexist by filling different niches
+- Immunology (innate + adaptive): two systems cover non-overlapping threat spaces
+- Military (combined arms): infantry, armor, and air power defeat enemies that any single arm cannot
+
+The toolkit already practices this (bottom-up anti-patterns + top-down integration tests = orthogonal verification). But the principle should be explicit in design decisions: when adding a new check, ask "does this cover a failure mode no existing check covers?" not "does this make existing coverage stronger?"
+
+**2. Memory Transforms Reactive Systems into Adaptive Systems**
+
+- Immune system: memory B-cells enable faster response to known pathogens
+- Aviation ASRS: incident reports enable industry-wide learning from near-misses
+- Toyota A3: searchable problem database means "you never solve the same problem twice"
+- Sports: film study enables adaptation to opponents' patterns
+
+The toolkit's lesson system is its memory. The papers undervalue this: the lesson system is not just "automated anti-pattern checking" -- it's the mechanism by which the toolkit _evolves_. Every production failure makes the system permanently harder to break. No competitor has this. This is the toolkit's immune memory, and it's the single most defensible competitive advantage.
+
+**3. Structure Enables Improvisation**
+
+- Jazz: chord changes provide structure; solos are improvisation within that structure
+- Military (Auftragstaktik): mission intent provides structure; tactical decisions are improvised
+- Sports (plays vs. execution): the play is the plan; reading the defense is improvisation
+- Ecology (succession): early species create structure; later species improvise within it
+
+The toolkit's skill chain is the chord changes. The agent's execution is the solo. The quality gates are the barlines that keep everyone synchronized. The right design doesn't _constrain_ the agent -- it _enables_ the agent to make intelligent local decisions within a globally coherent framework.
+
+**4. Pioneers Bear Disproportionate Risk**
+
+- Ecology (succession): pioneer species face harsh conditions that climax species never encounter
+- Military: the first wave takes the heaviest casualties
+- Manufacturing (first article inspection): the first unit off the line gets the most thorough inspection
+- Sports: the opening drive sets the tone for the game
+
+Batch 1 of any plan is a pioneer. It creates the file structure, test infrastructure, and patterns that all subsequent batches inherit. A bug in batch 1 has the highest R0 of any bug. Yet the toolkit treats batch 1 identically to batch 6. The design implication: batch 1 should get hardened execution -- higher-tier model, competitive mode, extra verification.
+
+**5. Degradation is Non-Linear and Has Phase Transitions**
+
+- Ecology (carrying capacity): populations don't decline gradually; they crash
+- Epidemiology: disease spread is exponential until herd immunity threshold, then crashes
+- Materials science: metals bend, then suddenly fracture
+- Aviation: workload is manageable until it isn't -- then all errors happen at once
+
+Context degradation follows this pattern (the Chroma study: "performance drops are often sudden rather than progressive"). The toolkit's fresh-context-per-batch architecture avoids the phase transition entirely by never accumulating enough context to reach the tipping point. This is prevention, not treatment -- the epidemiological equivalent of keeping R0 below 1.
+
+### Contradictions
+
+**1. Biology says evolve; Manufacturing says standardize.**
+
+The immune system succeeds through diversity and mutation. Toyota succeeds through standardization and waste elimination. These are opposite strategies. The resolution: the _process_ should be standardized (Toyota -- rigid skill chain, consistent quality gates), but the _responses_ should evolve (immune system -- lessons learned, adaptive prompt selection, failure pattern learning). The toolkit already does this correctly: rigid pipeline structure with evolving content.
+
+**2. Military says decentralize; Aviation says standardize communication.**
+
+Auftragstaktik delegates decision-making downward. CRM standardizes communication upward. The resolution: delegate _execution_ decisions (the agent chooses how to implement) but standardize _status communication_ (structured progress.txt, standardized quality gate output). The toolkit should not constrain how the agent writes code but should constrain how it reports what it did.
+
+**3. Ecology says diversity; Manufacturing says reduce variation.**
+
+Ecological resilience comes from species diversity. Manufacturing quality comes from reducing variation. The resolution depends on which part of the system: _input_ diversity (multiple prompt strategies, competitive execution) increases resilience; _output_ consistency (quality gates, test assertions) ensures quality. The toolkit's MAB system gets this right: diverse approaches in, consistent quality bar out.
+
+### The Single Most Powerful Insight
+
+**The toolkit is building an artificial immune system for codebases, and it doesn't know it.**
+
+The lesson system is adaptive immunity. The quality gates are innate immunity. Community lesson submission is vaccination. False positives are autoimmune disorders. Scope filtering is clonal selection. The retry mechanism is the inflammatory response.
+
+This is not a metaphor -- it's a structural isomorphism. The immune system is the most successful quality-assurance system in biology: it protects against billions of potential pathogens, learns from every encounter, shares knowledge across organisms (breast milk, vaccination), and operates with zero downtime.
+
+Reframing the toolkit as an immune system changes the roadmap priorities:
+
+1. **Maximize memory diversity** (more lesson types, richer failure patterns) -- not just more checks, but checks that cover orthogonal failure modes
+2. **Speed up the immune response** (faster lesson-to-check pipeline, automated lesson extraction from failures) -- when a bug gets through, how fast does the system learn?
+3. **Prevent autoimmune disorders** (scope filtering, false positive tracking, tolerance mechanisms) -- the system should never attack healthy code
+4. **Build herd immunity** (community lessons, shared quality profiles) -- every user's failures protect every other user
+5. **Invest in vaccination** (property-based testing, pre-execution specification checks) -- prevent entire classes of bugs, don't just detect individual instances
+
+No competitor is building an immune system. They're building assembly lines. Assembly lines break when they encounter novel inputs. Immune systems get stronger.
+
+---
+
+## Appendix: Addenda for Each Research Paper
+
+### Addendum for Plan Quality Paper
+
+**Cross-Domain Perspective: Military Mission Command (Auftragstaktik)**
+
+The plan-quality paper's recommendation to shift from "complete code in plan" to "contracts + one example" is structurally identical to the military doctrine of Auftragstaktik (mission command), where subordinate commanders receive the objective and intent rather than detailed orders. Clausewitz's observation that "no plan survives contact with the enemy" maps directly to the finding that stale plans and no-op tasks degrade execution.
+
+The mission command framework adds one element the paper misses: _commander's intent at two levels_. Each task should include not just its own contract but its role in the larger feature. When a batch fails and the agent retries, knowing "this task exists to enable Batch N+1 to wire the modules together" gives the agent the context to make intelligent adaptation decisions -- the same way a field commander adapts tactics when the original plan is disrupted by terrain or enemy action.
+
+Additionally, the military concept of _friction_ (the accumulation of small difficulties that make simple things difficult in war) provides a useful lens for batch boundary design. Integration batches experience the most friction because they cross module boundaries. The paper's recommendation to "never mix file-creation and integration tasks" maps to the military principle of maintaining clear phase lines between offensive operations. Crossing a phase line (moving from creation to integration) should be a deliberate, verified transition -- not an accident of batch grouping.
+
+### Addendum for Prompt Engineering Paper
+
+**Cross-Domain Perspective: Musical Rehearsal Structure and Call-and-Response**
+
+The prompt-engineering paper's finding that structured planning (+4% SWE-bench) outperforms raw chain-of-thought parallels a well-known principle in musical performance: rehearsal marks (structural landmarks in a score) enable performers to navigate complex pieces without getting lost, while detailed phrase-by-phrase instructions from a conductor actually degrade performance by removing the musician's interpretive agency.
+
+The batch prompt should function like rehearsal marks -- five structural landmarks (Investigate, Test-First, Implement, Verify, Commit) that the agent navigates through. This is lighter than detailed step-by-step instructions and heavier than "just code it." The top SWE-bench agents already use this pattern (SWE-agent's 5-phase workflow, OpenHands' 5-phase workflow) but the paper doesn't name the underlying principle.
+
+For retry prompts, the jazz concept of call-and-response suggests a structural improvement: instead of the current pattern (system tells agent what failed), use an interactive pattern (system asks agent to diagnose, then provides the actual failure data for comparison). The self-correction research cited in the paper supports this -- "ask yourself what went wrong" prompts outperform "here's what went wrong" prompts. In jazz terms: the rhythm section states the question, and the soloist must formulate their own answer before hearing what the rest of the band plays.
+
+### Addendum for Context Utilization Paper
+
+**Cross-Domain Perspective: Ecological Carrying Capacity and Niche Partitioning**
+
+The context-utilization paper models the context window as a linear resource with a degradation curve. Ecology offers a richer model: the context window is a habitat with carrying capacity (K). Below K, adding context tokens improves performance. At K, the agent is maximally effective. Above K, performance crashes -- matching the "sudden rather than progressive" degradation the paper documents from the Chroma study.
+
+The ecological insight is that _what_ occupies the carrying capacity matters more than _how much_. In a healthy ecosystem, species partition niches -- different organisms fill different ecological roles without competing for the same resources. The context assembler's injected sections should similarly occupy distinct informational niches. Currently, recent commits and progress notes both serve the "recent history" niche, competing for the agent's attention. Merging these into a single structured "recent context" section would improve niche diversity per token.
+
+The concept of _invasive species_ also applies: irrelevant context that consumes attention budget without contributing to task performance is an ecological invader. The paper's recommendation for XML-tagged sections helps the agent distinguish between context types, which is the token equivalent of species identification -- you can't manage a habitat if you can't tell the species apart.
+
+### Addendum for Competitive Landscape Paper
+
+**Cross-Domain Perspective: Ecological Niche Partitioning and Competitive Exclusion**
+
+Gause's competitive exclusion principle states that two species cannot indefinitely occupy the same ecological niche. Applied to the autonomous coding tool market: tools that compete for the exact same user need (e.g., general-purpose IDE coding assistants) will converge until only the strongest survive. Cursor and Windsurf are in a competitive exclusion race. So are Claude Code and Codex CLI.
+
+The toolkit survives competitive exclusion by occupying a distinct niche: pipeline orchestration for Claude Code power users. This niche is too specialized for generalist tools to subsume (they won't build test-count monotonicity or batch-type-aware prompt selection for their mass market), yet valuable enough for its target audience to sustain.
+
+The defensive strategy from ecology is _niche hardening_: making the toolkit indispensable in its niche rather than expanding into adjacent niches where it would face direct competition. Every feature that deepens the pipeline (richer lessons, better failure learning, plan quality scoring) hardens the niche. Every feature that broadens the toolkit (IDE support, cloud hosting, multi-model routing) enters contested territory where larger competitors have structural advantages.
+
+### Addendum for Agent Failure Taxonomy Paper
+
+**Cross-Domain Perspective: James Reason's Swiss Cheese Model (Aviation Safety)**
+
+The failure-taxonomy paper identifies six failure clusters and three major gaps in the toolkit's coverage. The Swiss cheese model from aviation safety adds a crucial structural insight: failures occur when holes in multiple safety barriers _align_. The toolkit's barriers (lesson-check, test suite, ast-grep, test-count, git-clean, verification) are well-differentiated slices of Swiss cheese. But the three uncovered failure classes (specification misunderstanding, planning errors, context degradation) represent holes that exist in _every_ slice simultaneously -- no current barrier operates at the specification level.
+
+Adding more barriers of the same type (more regex patterns, more linting rules) moves the holes within existing slices but doesn't add a new slice. What's needed is a fundamentally different barrier type: a specification-level check that catches "right code, wrong task" before implementation begins. The paper's recommendation for a "specification echo-back gate" is exactly this -- it's a new slice of Swiss cheese with its holes in a different place than all existing slices.
+
+The Swiss cheese model also provides a framework for the paper's concern about "force multiplier" failures: context degradation doesn't create bugs directly, but it _enlarges the holes_ in every barrier. When the agent's attention is degraded, it's more likely to miss each individual check. The toolkit's fresh-context architecture prevents this enlargement by resetting the barrier quality at every batch.
+
+### Addendum for Verification Effectiveness Paper
+
+**Cross-Domain Perspective: Epidemiological Contact Tracing and Herd Immunity**
+
+The verification paper quantifies detection rates per pipeline stage but treats each bug as an independent event. Epidemiology provides a richer model: bugs have a _reproduction number_ (R0) -- how many downstream bugs each bug creates. A bug in a shared utility has high R0 (every consumer is "infected"). A bug in a leaf function has R0 near zero.
+
+Contact tracing (working backward from a bug to identify all potentially affected code) is missing from the pipeline. When a quality gate catches a bug, the current response is "fix the bug." An epidemiological response would be "fix the bug AND trace its contacts" -- identify all modules that import or depend on the buggy code, and verify they aren't already exhibiting symptoms.
+
+The paper's recommendation for property-based testing maps to the epidemiological concept of vaccination: property tests establish invariants that prevent entire classes of bugs, not just specific instances. If enough of the codebase is "vaccinated" with property tests, the remaining untested code benefits from herd immunity -- integration tests exercise it through tested interfaces, and invariant violations are caught at the boundary.
+
+### Addendum for Cost/Quality Tradeoff Paper
+
+**Cross-Domain Perspective: Theory of Constraints (Goldratt)**
+
+The cost-quality paper optimizes execution costs (caching, model routing, batch API). The Theory of Constraints says this optimization may be irrelevant: if the system's bottleneck is plan quality (which the plan-quality paper argues it is), then making execution faster and cheaper produces zero improvement in total throughput.
+
+Goldratt's Five Focusing Steps applied to the toolkit: (1) Identify the constraint -- plan creation takes 60 minutes while execution takes 20 minutes per feature. (2) Exploit the constraint -- invest in plan-quality tooling, not execution-cost optimization. (3) Subordinate everything else -- don't start execution until plan quality exceeds threshold. (4) Elevate the constraint -- build a plan-quality validator that catches gaps before the human reviews. (5) Repeat -- after plan quality improves, re-identify the new constraint.
+
+The paper's recommendation to implement cost tracking is correct regardless of the constraint location -- you need data to identify the bottleneck. But the Theory of Constraints predicts that caching optimization ($0.73 savings per MAB plan) will matter far less than plan-quality investment (preventing entire feature rework cycles worth $5-10).
+
+### Addendum for Multi-Agent Coordination Paper
+
+**Cross-Domain Perspective: Crew Resource Management and the Sterile Cockpit Rule**
+
+The multi-agent paper catalogs coordination patterns and identifies conformity bias as a key risk. Aviation's Crew Resource Management (CRM) has 50+ years of evidence on exactly this problem. The Tenerife disaster (1977, 583 deaths) was caused not by pilot error per se, but by the failure of crew members to challenge the captain's incorrect assumption. CRM training reduced the aviation accident rate by teaching standardized communication and empowering junior crew members to challenge authority.
+
+The toolkit's team mode has an analogous authority gradient: the implementer produces code, the reviewer evaluates it. When both use the same model, the reviewer tends to defer to the implementer's apparent reasoning -- the LLM equivalent of a first officer deferring to a captain. Using different models (as the paper recommends) is the CRM solution: different training backgrounds produce different assumptions, enabling genuine challenge.
+
+CRM's sterile cockpit rule (below 10,000 feet, no non-essential communication) suggests a design pattern for critical batches: strip non-essential context and restrict the agent to only task-relevant information. This reduces cognitive load at exactly the moment when errors are most dangerous -- during integration, retry, and production-critical batches.
+
+### Addendum for User Adoption Paper
+
+**Cross-Domain Perspective: Sports Periodization and Deliberate Practice**
+
+The user-adoption paper recommends progressive disclosure to reduce friction. Sports science adds a temporal dimension: periodization. Athletes don't train at maximum intensity every day -- they alternate between loading phases (building capacity) and recovery phases (consolidating gains). Attempting to learn the full toolkit pipeline in one session is overtraining.
+
+A periodized onboarding schedule would look like: Week 1 (foundation) -- run existing plans, experience quality gates; Week 2 (skill building) -- write plans, practice the format; Week 3 (integration) -- full /autocode pipeline; Week 4 (recovery/reflection) -- review outcomes, submit lessons, customize.
+
+Anders Ericsson's deliberate practice research adds another dimension: expertise develops through focused practice on specific weaknesses, not general repetition. The toolkit's onboarding should identify which stage is causing the most friction for each user and provide targeted practice. If plan writing is the bottleneck, offer plan-writing exercises with the quality scorecard. If TDD is unfamiliar, offer a TDD-focused tutorial that's independent of the toolkit's pipeline.
+
+The "coaching vs. playing" distinction is critical: the toolkit currently acts as a player (executing code). For adoption, it should also act as a coach -- explaining quality gate results after the user sees them work, demonstrating the value of TDD by showing before/after failure rates, and celebrating (in command output) when lessons prevent real bugs.
+
+### Addendum for Lesson Transferability Paper
+
+**Cross-Domain Perspective: The Adaptive Immune System**
+
+The lesson-transferability paper proposes scope metadata (universal, language, framework, domain, project-specific) for filtering lessons. This taxonomy is a structural isomorphism with the vertebrate immune system: universal lessons are innate immunity (always active, non-specific); language and framework lessons are adaptive immunity (activated by specific antigens -- file extensions, dependency manifests); project-specific lessons are tissue-specific immune responses (only active in the originating organ).
+
+The immune analogy reveals three mechanisms the paper doesn't discuss:
+
+First, _clonal selection_ (testing new antibodies against self before deployment): before merging a new lesson, it should be tested against known-good code. A lesson that triggers on correct code is an autoimmune antibody -- it attacks healthy tissue. Adding a "run against known-good corpus" step to the lesson PR review process prevents this.
+
+Second, _immune tolerance_ (learning to stop reacting to benign substances): when a lesson finding is repeatedly dismissed as a false positive, the system should learn to suppress it for that context. Tracking dismissals per lesson per project and auto-suppressing after N dismissals implements tolerance without removing the lesson entirely.
+
+Third, _mucosal immunity_ (specialized immune responses at high-exposure surfaces): the toolkit's most critical boundary is the quality gate between batches. Lessons that fire at this boundary (lesson-check.sh) should be the highest-confidence, lowest-false-positive checks -- the equivalent of the immune system's strongest defenses at the body's most exposed surfaces (gut, lungs, skin). Lower-confidence checks belong at less critical boundaries (verification stage, semantic scanner).
+
+---
+
+## Sources
+
+### Biology and Immunology
+- Janeway, C.A. et al. _Immunobiology: The Immune System in Health and Disease._ 5th edition. Garland Science, 2001.
+- Murphy, K. & Weaver, C. _Janeway's Immunobiology._ 9th edition. Garland Science, 2016.
+- Medzhitov, R. & Janeway, C.A. "Innate immunity." _New England Journal of Medicine_ 343.5 (2000): 338-344.
+
+### Ecology
+- Gause, G.F. _The Struggle for Existence._ Williams & Wilkins, 1934.
+- Hardin, G. "The Competitive Exclusion Principle." _Science_ 131.3409 (1960): 1292-1297.
+- Connell, J.H. & Slatyer, R.O. "Mechanisms of succession in natural communities." _American Naturalist_ 111.982 (1977): 1119-1144.
+- Holling, C.S. "Resilience and stability of ecological systems." _Annual Review of Ecology and Systematics_ 4 (1973): 1-23.
+
+### Military Doctrine
+- von Clausewitz, C. _On War._ Trans. Howard & Paret. Princeton University Press, 1976.
+- Vandergriff, D.E. _Mission Command: The Who, What, Where, When and Why._ CreateSpace, 2019.
+- US Army. _ADP 6-0: Mission Command._ 2019.
+
+### Aviation Safety
+- Reason, J. "Human error: models and management." _BMJ_ 320.7237 (2000): 768-770.
+- Reason, J. _Managing the Risks of Organizational Accidents._ Ashgate, 1997.
+- Helmreich, R.L. et al. "The evolution of crew resource management training in commercial aviation." _International Journal of Aviation Psychology_ 9.1 (1999): 19-32.
+- Federal Aviation Administration. _Advisory Circular 120-51E: Crew Resource Management Training._ 2004.
+
+### Manufacturing and Theory of Constraints
+- Goldratt, E.M. _The Goal: A Process of Ongoing Improvement._ North River Press, 1984.
+- Ohno, T. _Toyota Production System: Beyond Large-Scale Production._ Productivity Press, 1988.
+- Shook, J. "Toyota's Secret: The A3 Report." _MIT Sloan Management Review_ 50.4 (2009): 30-33.
+
+### Game Theory
+- Nash, J. "Equilibrium points in n-person games." _Proceedings of the National Academy of Sciences_ 36.1 (1950): 48-49.
+- Milgrom, P. & Roberts, J. "Complementarities and fit: Strategy, structure, and organizational change in manufacturing." _Journal of Accounting and Economics_ 19 (1995): 179-208.
+
+### Epidemiology
+- Anderson, R.M. & May, R.M. _Infectious Diseases of Humans: Dynamics and Control._ Oxford University Press, 1991.
+- Fine, P. et al. "Herd immunity: a rough guide." _Clinical Infectious Diseases_ 52.7 (2011): 911-916.
+
+### Sports Science
+- Bompa, T.O. & Haff, G.G. _Periodization: Theory and Methodology of Training._ 5th edition. Human Kinetics, 2009.
+- Ericsson, K.A. et al. "The role of deliberate practice in the acquisition of expert performance." _Psychological Review_ 100.3 (1993): 363-406.
+
+### Music and Performance
+- Berliner, P.F. _Thinking in Jazz: The Infinite Art of Improvisation._ University of Chicago Press, 1994.
+- Sawyer, R.K. "Group creativity: Music, theater, collaboration." _Mahwah, NJ: Lawrence Erlbaum_ (2003).
+
+### Organizational Psychology
+- Edmondson, A. "Psychological safety and learning behavior in work teams." _Administrative Science Quarterly_ 44.2 (1999): 350-383.
+- Sweller, J. "Cognitive load theory, learning difficulty, and instructional design." _Learning and Instruction_ 4.4 (1994): 295-312.
+- Weick, K.E. & Sutcliffe, K.M. _Managing the Unexpected: Resilient Performance in an Age of Uncertainty._ 3rd edition. Jossey-Bass, 2015.
+
+### Checklists and Verification
+- Gawande, A. _The Checklist Manifesto: How to Get Things Right._ Metropolitan Books, 2009.
+- Nielsen, J. "Progressive Disclosure." Nielsen Norman Group, 1995.