Chapter 14 – Appendix A: Implementation Checklist

This appendix turns the book into a build plan.

The goal is not to implement every chapter. The goal is to ship a small loop that is correct, auditable, and easy to extend.

The dependency graph

graph TD
  MVF[Ch 1: Minimum Viable Factory] --> Sandwich[Ch 2: Deterministic Sandwich]
  Sandwich --> Validators[Ch 3: Define Good (Validators)]
  Validators --> Drift[Ch 4: Drift Measurement]
  Validators --> Ouroboros[Ch 5: Ouroboros Protocol]
  Ouroboros --> Slice[Ch 6: Context Slicing]
  Slice --> Missions[Ch 7: Mission Objects]
  Missions --> MapUpdaters[Ch 8: Map-Updaters + CI Gate]
  MapUpdaters --> Dream[Ch 9: Scheduled Maintenance / Dream Daemon]
  Validators --> Guardrails[Ch 10: Immutable Infrastructure]
  Guardrails --> Refactor[Ch 11: Automated Refactoring Under Guards]
  Guardrails --> Policy[Ch 12: Governance at Machine Speed]
  Policy --> Reflect[Ch 13: Hofstadter Bridge (Optional)]

Weekend sprint (Part I): Build the first loop

Milestone 1: A loop you can run locally (Chapter 1)

Definition of done:

• One Effector that updates an artifact (docs, config, or code) from a Map input.
• One Validator that deterministically gates the result.
• One command that runs effector -> validator end-to-end and fails fast on violations.

Minimal scope recommendations:

• Prefer doc sync or config generation before code generation.
• Keep the “Map” small and explicit (one YAML/JSON file).

Milestone 2: Wrap the stochastic call (Chapter 2)

Definition of done:

• Prep layer produces a structured request from typed inputs (a template + a mapping function).
• Validation layer parses the output strictly and emits a machine-readable error on failure.
• The Effector refuses to write when validation fails.

Minimum set of error fields to collect (even if you only print them):

• file_path
• line_number (or “unknown” if your validator cannot localize yet)
• error_code (schema keyword, linter code, or tool name)
• message

Milestone 3: Make “good” executable (Chapter 3)

Definition of done:

• At least one hard validator that catches a real failure mode your team has seen.
• Your validator output is stable and readable (same format every run).
• You can demonstrate causality: break the rule, observe deterministic failure.

Weeks 1–2 (Part II): Understand why it works

Milestone 4: Measure drift (Chapter 4)

Definition of done:

• Run the same mission 10 times.
• Track at least one drift metric:
  • Unique diffs (how many distinct outputs)
  • Failure rate (what percent violates validators)
  • Time-to-convergence (iterations until PASS)

Milestone 5: Build a loop that converges (Chapter 5)

Definition of done:

• A Write -> Judge -> Refine loop that terminates.
• The Judge returns structured diagnostics, not vague prose.
• You have circuit breakers (max iterations + wall-clock budget).

Milestone 6: Slice the graph, do not dump it (Chapter 6)

Definition of done:

• A repeatable way to build a context packet for a single task.
• The slice is small enough to fit comfortably in one model call.
• You can show one failure from a raw dump and one success from a slice.

Weeks 2–4 (Part III): Scale the loop into a system

Milestone 7: Intent as a typed object (Chapter 7)

Definition of done:

• Missions are stored as data (JSON/YAML) rather than embedded strings.
• Missions include constraints and a success condition.
• Failures route through a state machine: Revert, Iterate, or Update Environment.

Milestone 8: Keep the Map fresh (Chapter 8)

Definition of done:

• A Map-Updater that extracts a deterministic skeleton from the Terrain.
• A compare step that detects drift.
• A propose step that emits a unified diff (and nothing else).
• A CI gate that fails on drift and tells you how to repair it.

Milestone 9: The 90% maintenance system (Chapter 9)

Definition of done:

• Scheduled runs (nightly or weekly) that propose maintenance patches.
• Human approval before merge.
• A short “Dream Manifest” of what you measure and why (defects, flaky tests, complexity hotspots).

Ongoing (Part IV): Govern safe evolution

Milestone 10: Protected Infrastructure (Chapter 10)

Definition of done:

• Your system cannot modify the code that grades it (tests, validators, CI rules) without a human.
• Protected paths and review rules are enforced by the platform (CODEOWNERS / branch protection).
• A break-glass procedure exists and is rehearsed.

Milestone 11: Automated refactoring under guards (Chapter 11)

Definition of done:

• A small, metric-driven refactor loop with commit/revert rules.
• The Ratchet is explicit: quality metrics do not regress without an intentional waiver.

Milestone 12: Governance at machine speed (Chapter 12)

Definition of done:

• Clear policy for what can auto-merge vs what requires review.
• Blast radius boundaries are explicit and enforced.
• Audit artifacts are retained (logs, diffs, run metadata).

Optional (Part V): Reflections

Chapter 13 is a useful limit case. Treat it as a tool for thinking, not a build requirement.

Actionable: What you can do this week

1. Pick one artifact and one validator, and get a local end-to-end loop working.

2. Add structured error output to your Judge, even if it is only file_path + message at first.

3. Put one protected path in place (tests/validators/CI) and require human review for it.