Found while amending ADR-0094 for #15244 (docs-only, governed surface), so it was not fixed there.
The defect
Two comments introduced by PR #14982 point the reader at the wrong section of ADR-0094 for boot reconciliation:
packages/metadata-protocol/src/protocol.ts, in the rollbackMetaItem projector comment: ... not only after the next unrelated write or boot reconciliation (ADR-0094 D3) eventually heals it.packages/metadata-protocol/src/protocol.recovery-doors-mutation-projector.test.ts, in the file header: ... or a boot reconciliation (ADR-0094 D3), re-derived it.
In ADR-0094, boot reconciliation is D4 (### D4 — Boot reconciliation and the migration/backfill path). D3 is a different decision entirely: ### D3 — Data-door writes are redirected into metadata (write-through).
Why it is worth a card rather than a shrug
Every other citation of this mechanism in the tree already spells it D4, so these two are the outliers, not a naming convention:
git grep -n "ADR-0094 D3\|ADR-0094 D4" -- packages/
The D4 spellings are in packages/plugins/plugin-security/src/permission-set-projection.ts (several, including the log strings reconciled (ADR-0094 D4) and backfill into metadata FAILED (ADR-0094 D4)), permission-set-drift.ts, permission-set-overlay-discard.ts, security-plugin.ts and permission-set-projection.test.ts. The genuine D3 spellings in that same file set all refer correctly to the data-door write-through.
Prime Directive #13's whole mechanism is that a code comment naming an ADR section sends the next author to the decision they are standing on. A comment that names the wrong section sends them to the write-through redirect table when they were looking for the kernel:ready convergence pass — a plausible-looking wrong answer, which is worse than no citation.
Scope
Comment text only, two files, no behaviour. Suggested fix: D3 to D4 at both sites.
Measured on origin/main at 1bc3c092a.
Found while amending ADR-0094 for #15244 (docs-only, governed surface), so it was not fixed there.
The defect
Two comments introduced by PR #14982 point the reader at the wrong section of ADR-0094 for boot reconciliation:
packages/metadata-protocol/src/protocol.ts, in therollbackMetaItemprojector comment:... not only after the next unrelated write or boot reconciliation (ADR-0094 D3) eventually heals it.packages/metadata-protocol/src/protocol.recovery-doors-mutation-projector.test.ts, in the file header:... or a boot reconciliation (ADR-0094 D3), re-derived it.In ADR-0094, boot reconciliation is D4 (
### D4 — Boot reconciliation and the migration/backfill path). D3 is a different decision entirely:### D3 — Data-door writes are redirected into metadata (write-through).Why it is worth a card rather than a shrug
Every other citation of this mechanism in the tree already spells it D4, so these two are the outliers, not a naming convention:
git grep -n "ADR-0094 D3\|ADR-0094 D4" -- packages/The D4 spellings are in
packages/plugins/plugin-security/src/permission-set-projection.ts(several, including the log stringsreconciled (ADR-0094 D4)andbackfill into metadata FAILED (ADR-0094 D4)),permission-set-drift.ts,permission-set-overlay-discard.ts,security-plugin.tsandpermission-set-projection.test.ts. The genuine D3 spellings in that same file set all refer correctly to the data-door write-through.Prime Directive #13's whole mechanism is that a code comment naming an ADR section sends the next author to the decision they are standing on. A comment that names the wrong section sends them to the write-through redirect table when they were looking for the
kernel:readyconvergence pass — a plausible-looking wrong answer, which is worse than no citation.Scope
Comment text only, two files, no behaviour. Suggested fix:
D3toD4at both sites.Measured on
origin/mainat1bc3c092a.