# ADR-0001: Ship a polymorphic single kit, not a recursive kit-of-kits

- **Date:** 2026-04-28
- **Status:** accepted
- **Reversibility:** medium (V2 architecture can introduce kit-of-kits without invalidating V1 artifacts)
- **Deciders:** practitioner@example.com (operator and author)
- **Scope:** kit (V1 architecture decision)

## Context

The deployment kit needs an architecture that can land the operating model in arbitrarily many fresh environments. Two real architectures exist:

- A **polymorphic single kit** that localizes per drop-in via a question set and a worked example. One kit, many landings, each landing customized.
- A **recursive kit-of-kits** where one master kit generates target-specific kits, each pre-customized to its environment. Many kits, generated on demand from a meta-kit.

The recursive architecture is the long-term vision (named in `AI-Architect/BACKLOG.md` as the Recursive Skill Optimization & Scaffolding Engine). The question is whether to build it now or build a polymorphic single kit first.

Upstream constraints already locked:

- L0 strategy: V1 must ship in days, not weeks, because the first deployment target (Cowork) is queued
- L4 platform-kit: no engine exists yet for the recursive pattern; building it would consume the V1 budget
- The recursive engine's design depends on observing how a polymorphic single kit fails in real deployments; without that data, the recursion's optimization rules would be guesswork

## Decision

V1 ships as a polymorphic single kit. The recursive kit-of-kits is deferred to V2, after V1 has produced enough deployed-instance evidence to define the recursion's optimization rules.

## Options considered

### Option A: Polymorphic single kit [CHOSEN]

- **Summary:** One kit. On drop-in, it asks 10 mandatory localization questions, populates templates against a worked example, validates, and lands.
- **Pros:** Buildable in days; testable end-to-end against one deployment target before generalizing; the failure modes that surface in V1 directly inform V2's recursion rules; the kit's outputs (worked example, validation rubric, behavior triggers) are reusable as inputs to V2.
- **Cons:** Each new deployment target requires re-running the question set from scratch; no automatic knowledge transfer between landings; the operator carries the cognitive load of cross-deployment learning until V2.

### Option B: Recursive kit-of-kits

- **Summary:** A meta-kit that generates target-specific kits. Each generated kit is pre-customized to a deployment context.
- **Pros:** Eventually scales to many deployment targets without per-target operator cost; cross-deployment learning compounds inside the engine; matches the long-term vision.
- **Cons:** Cannot be built without observing real deployments first; the optimization rules would be guessed rather than learned; building it now consumes V1's entire budget and probably delays the first landing by 4 to 8 weeks; no concrete win until at least 3 deployment targets exist to compound across.

### Option C: Hybrid - ship V1 polymorphic but with recursion-friendly internals

- **Summary:** Build V1 as a single kit but instrument every decision and template with metadata that V2's engine can read.
- **Pros:** Lowers the V1-to-V2 transition cost; V1 deployments produce structured data that V2 can ingest.
- **Cons:** Doubles the V1 effort because every artifact carries dual purposes (operate the kit and feed the engine); risk of over-engineering for hypothetical V2 needs; speculative metadata schemas tend to be wrong on first design and require rework anyway.

## Rationale

V1 must produce a working deployment in days. Option B is impossible on that timeline. Option C inflates V1 effort against speculative V2 requirements; the operator's prior experience with metadata-for-future-engines is that the metadata is almost always wrong on first design. Option A produces the artifacts (worked example, failure-mode catalog, validation rubric) that V2 needs as inputs anyway.

The tradeoff explicitly accepted: each new deployment target requires re-running the localization question set from scratch until V2 lands. The operator absorbs this cost because the alternative is no V1 at all.

A future V2 ADR will describe the recursive architecture; this ADR remains the record of why V1 is single-kit.

## Consequences

### Positive

- V1 ships in a single dedicated session arc (Chunks A through F)
- The operator gets one validated deployment before generalizing, reducing the risk of generalizing the wrong thing
- The artifacts produced (BOOTSTRAP-BRIEF, QUESTIONS, worked example, failure-mode catalog) become V2's inputs
- The Recursive Engine entry in `AI-Architect/BACKLOG.md` stays parked with no urgency pressure; it activates when extrapolation events compound

### Negative

- Each new deployment target after V1's first landing requires manual operator effort to re-answer the 10 questions and re-populate templates
- Cross-deployment learning is operator-side (memory, notes) rather than engine-side (compounded automatically)
- The kit will need a V2-shaped redesign once 3+ deployment targets exist, rather than being naturally generalizable

### Followups

- After V1 ships, write `RECURSION-PATTERNS.md` capturing what would parameterize cleanly versus what would need structural variation in V2 (entry parked in `BACKLOG.md`)
- After 3 deployment targets land, revisit V2 build per the Recursive Engine entry's "compounding pressure" closes-by condition
- Annotate session logs across all V1 deployments with observations the V2 engine would need
