A real feature from practice (a DNS group with failover, sing-box-lx), distilled into the methodology's format. It shows every artifact of the cycle filled in:
| File | What it shows |
|---|---|
| SPECS/FEATURES/001-DNS_GROUP/CONCEIVED.md | the conception ledger: the intent put at risk, eleven ideas each run to a fate |
| SPECS/FEATURES/001-DNS_GROUP/FEATURE.md | sea-level promises, witnesses, assumptions, non-goals |
| SPECS/TASKS/002-SURVIVAL_SINGLE_ATTEMPT/SPEC.md | the task's narrow contract, Touches by ID |
| SPECS/TASKS/002-SURVIVAL_SINGLE_ATTEMPT/UPHOLD.md | a filled-in court ledger |
The ledger's storyline is the exact class of defect the methodology hunts: the task declares Touches: P6 and closes flawlessly by its own criteria, but a refactor of a shared outcome-classification helper betrays P2 — a promise the task "didn't touch". A check that looks only at the task's acceptance criteria misses this defect by construction; a pass over all of the feature's promises catches it in the P2 row.
The example is illustrative: the file names and quotes in the verdicts are schematic (there is no code behind them), but the rows are in live format: examples/SPECS/TASKS/002-… passes scripts/check-uphold.sh.
For the same reason there is no code here to carry // PROMISE F001-PN markers, so the feature checks with scripts/check-promises.sh --no-code examples/SPECS/FEATURES/001-DNS_GROUP — IDs and witnesses are verified, markers are not. In a real repository the markers would sit in the resolver code, and the P2 row's locus would start from them.