Decisions
Architecture decision records for rungs itself.
Index
| id | title | status | date |
|---|---|---|---|
| ADR-0001 | Multi-harness rendering: render only what is fragmented | accepted | 2026-08-14 |
| ADR-0002 | Implementation stack, and the runtime footprint of a scaffolded repo | accepted | 2026-08-14 |
| ADR-0003 | Module definition format: a directory that looks like what it emits | accepted | 2026-08-14 |
| ADR-0004 | Adoption detection: map what exists, never migrate it | accepted | 2026-08-14 |
| ADR-0005 | Self-instrumentation: the runner records what it observes, and nothing else | accepted | 2026-08-14 |
| ADR-0006 | The name: rungs, and why a name here is an identifier rather than a brand | accepted | 2026-08-14 |
| ADR-0007 | Detector applicability is declared per gate, and has no default | accepted | 2026-08-16 |
| ADR-0008 | A gate tier is an ordered level, and an unknown tier is refused | accepted | 2026-08-17 |
| ADR-0009 | rungs drives git for the concurrency loop, and only where the loop is the product | accepted | 2026-08-17 |
| ADR-0010 | A hook is dispatched through the consumer’s pinned launcher to a central engine | accepted | 2026-09-06 |
| ADR-0011 | An instruction detector reports what it read and asserts nothing about enforcement | accepted | 2026-09-06 |
The table above is generated from the records’ frontmatter by rungs render and held current by
adr-index-current. It replaced a hand-kept copy on 2026-09-06, when the gate started comparing
rows to records (WI-087) and found the block had been empty beside ten records since it was written.
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.