Decisions
Architecture decision records for rungs itself.
Index
| ADR | Title | Status | Date |
|---|---|---|---|
| 0001 | Multi-harness rendering: render only what is fragmented | accepted | 2026-08-14 |
| 0002 | Implementation stack, and the runtime footprint of a scaffolded repo | accepted | 2026-08-14 |
| 0003 | Module definition format: a directory that looks like what it emits | accepted | 2026-08-14 |
| 0004 | Adoption detection: map what exists, never migrate it | accepted | 2026-08-14 |
| 0005 | Self-instrumentation: the runner records what it observes, and nothing else | accepted | 2026-08-14 |
| 0006 | The name: rungs, and why a name here is an identifier rather than a brand | accepted | 2026-08-14 |
0001–0005 were decided out of numeric order, each because it blocked the next: 0005 set the gate-shipping contract, 0002 set what a scaffolded repo may depend on, 0003 is largely 0002’s consequence, and 0004 turned out to need mostly what 0002 and 0003 had already settled. Phase 3 is closed. 0006 is Phase 4, taken at the boundary because Phase 4 is where the name stops being prose and starts being written into module manifests.
Admission rule
Before creating an ADR, all of the following must be true (pattern adr-admission-rule,
extracted from axiom-mesh):
- The decision constrains future work rather than describing current work.
- A reasonable alternative existed and was rejected for a stated reason.
- Reversing it later would cost meaningfully more than making it now.
- It is not already owned by a specification or module doc.
- It is not an implementation detail that the code states more precisely than prose can.
If any is false, the content belongs in a design doc or a module spec — not here.