Problem
Four small ADR-record inaccuracies surfaced during the audit. None changes a decision; each is a precision fix so the ADR base stays a faithful record. (Per repo convention, an agent never flips a status or edits an accepted ADR in place — these are flagged for @reefact.)
- ADR-0025 is still
Proposed while fully implemented and load-bearing. StringMatching ships in the package README and the Accepted ADR-0026 depends on it (ErrorCodeFactory is built on StringMatching). Until the status flips, an accepted decision formally rests on an undecided one. The recorded intent and the code agree, so acceptance should be a formality — but only the maintainer flips it.
- ADR-0025 wording is imprecise on the character universe. "Terminals draw from printable ASCII" is not exact —
\s includes tab (0x09) and explicit escapes emit exactly the character they name. Since the ADR declares this universe a compatibility-relevant behavior, the rationale bullet should be corrected before acceptance (coordinated with the "printable ASCII" docs fix). It also cites "a property test" against the real engine; what exists is a fixed-seed, fixed-corpus oracle test — the text should say so.
- ADR-0026 has two precision drifts. Its decision says each factory exposes "an
IAny generator through a distinct method where composition is needed" — no factory exposes one today (zero IAny occurrences in FirstClassErrors.Testing). And its risk clause says the double-assembly hazard exists "precisely because Dummies types appear in Testing's public API" — today none do. Both are defensible in substance but misdescribe the current state.
- ADR-0013 / ADR-0015 point to detail the reference does not hold. Both defer specifics ("hint interface, collection state, draw budget, exception payload, seed propagation" for 0013) to the implementation reference, but
adr-implementation-reference.md's Dummies section records none of those numbers/payloads.
Impact
The ADR base is otherwise exemplary; these are the few places where a maintainer checking compliance a year from now would be misled by the record.
Direction
- Correct the ADR-0025 rationale wording (character universe + "oracle test, not property test"); then let
@reefact flip its status to Accepted (or record why not).
- Record the two ADR-0026 clarifications as a short note in the implementation reference (accepted ADRs are not edited in place): the factories currently expose values only, with
IAny companions deferred until a demonstrated need; and the accurate statement of the double-assembly hazard.
- Either enrich
adr-implementation-reference.md's Dummies section with the specifics ADR-0013/0015 promise, or soften those ADRs' pointers.
Acceptance criteria
- ADR-0025's character-universe wording is accurate and its safety-net description matches the actual test; its status is resolved by the maintainer.
- The implementation reference carries the two ADR-0026 clarifications.
- The ADR-0013/0015 pointers and the reference agree (either the detail exists, or the pointer no longer promises it).
Context
Surfaced by the 2026-07-20 architecture & design audit of the standalone Dummies library (doc/handwritten/for-maintainers/audit/2026-07-20-dummies-architecture-and-design-audit.md, §5/§6; branch claude/dummies-architecture-audit-cru5aq).
Filed from the Claude Code session that produced the 2026-07-20 Dummies architecture & design audit: https://claude.ai/code/session_01GvrWFVoG74xiys3oyEft1G
Problem
Four small ADR-record inaccuracies surfaced during the audit. None changes a decision; each is a precision fix so the ADR base stays a faithful record. (Per repo convention, an agent never flips a status or edits an accepted ADR in place — these are flagged for
@reefact.)Proposedwhile fully implemented and load-bearing.StringMatchingships in the package README and the Accepted ADR-0026 depends on it (ErrorCodeFactoryis built onStringMatching). Until the status flips, an accepted decision formally rests on an undecided one. The recorded intent and the code agree, so acceptance should be a formality — but only the maintainer flips it.\sincludes tab (0x09) and explicit escapes emit exactly the character they name. Since the ADR declares this universe a compatibility-relevant behavior, the rationale bullet should be corrected before acceptance (coordinated with the "printable ASCII" docs fix). It also cites "a property test" against the real engine; what exists is a fixed-seed, fixed-corpus oracle test — the text should say so.IAnygenerator through a distinct method where composition is needed" — no factory exposes one today (zeroIAnyoccurrences inFirstClassErrors.Testing). And its risk clause says the double-assembly hazard exists "precisely because Dummies types appear in Testing's public API" — today none do. Both are defensible in substance but misdescribe the current state.adr-implementation-reference.md's Dummies section records none of those numbers/payloads.Impact
The ADR base is otherwise exemplary; these are the few places where a maintainer checking compliance a year from now would be misled by the record.
Direction
@reefactflip its status toAccepted(or record why not).IAnycompanions deferred until a demonstrated need; and the accurate statement of the double-assembly hazard.adr-implementation-reference.md's Dummies section with the specifics ADR-0013/0015 promise, or soften those ADRs' pointers.Acceptance criteria
Context
Surfaced by the 2026-07-20 architecture & design audit of the standalone
Dummieslibrary (doc/handwritten/for-maintainers/audit/2026-07-20-dummies-architecture-and-design-audit.md, §5/§6; branchclaude/dummies-architecture-audit-cru5aq).Filed from the Claude Code session that produced the 2026-07-20 Dummies architecture & design audit: https://claude.ai/code/session_01GvrWFVoG74xiys3oyEft1G