docs: correct 14 more ADR records, five of which claimed capabilities the tree does not deliver (BACKLOG #1503-#1505)

[wshallwshall]

Follow-on to #1003 (merged). Same subject, different and much stronger instrument.

#1003 was a solo review. It corrected 21 ADR records by finding code — every check asked can I find the artifact, so a record claiming a build it never did had no way to fail. This PR is the result of running that missing direction, plus three more adversarial passes over the whole corpus.

Five records claimed capabilities the tree does not deliver

Every one is a scope mismatch, not absent code. The artifact exists and is wired; it does less than the ADR decided. No symbol grep can find this class, which is why #1003 and the first audit pass both missed all five.

ADR	Asserts	Tree
0133	Accepted (built), AC-3 "WHEN a Handler emits a content_match"	content_match is on NotifierAlertSink only — absent from the AlertSink protocol, from LoggingAlertSink, and from the authoring surface; a @handler receives only msg. No Handler can reach it. D1 and D2 are fully wired on all three backends, and the correction says so. → #1504
0075	AC-1: route_handoff / transform_handoff / mark_done all batched, citing a named test	no _mark_done_batched; mark_done never reads the flag. The cited test node id does not exist — it survived because adr_analyze.py checks that the file exists, not the test name. A cited-but-absent test reads as verified evidence. → #1503
0089	"Phase A is built and adopted"	the read atom never shipped (the recogniser only sees bare expression statements, so an assignment cannot reach it) and set_segment does not exist on the Message API. Measured by running the lens, not by grep. → #1505
0150	item 6: client on three named surfaces	missing on one
0002	the mirror: "Nothing in this ADR is built yet"	WP-13a, WP-13b and WP-15 all ship, self-labelled with those exact numbers

Six more (0004, 0007, 0017, 0028, 0161, 0167) understate what shipped. 0007 is the sharpest: both halves of the record said unbuilt while the entire connections.toml feature ships including a write seam, and CLAUDE.md §1 already describes it as shipped.

The rejection rate is the real finding

13 of 16 first-attempt corrections failed their checker. Not on style — on substance. Each correction was drafted by one agent that re-verified the finding independently, then checked by a second that confirmed the old_string matches byte-for-byte and that the new text does not itself over-claim. One rejection read: "ONE SENTENCE IS FALSE, AND IT IS THE POSITIVE CONTROL."

A correction arrives with the authority of a fix, so a wrong one is harder to catch than the wrong original. Had these been hand-applied from the audit findings — which is what I was about to do before adding the checker stage — most would have landed unverified.

Revisers were told a checker is not automatically right. Four (0075, 0089, 0007, 0161) disputed complaints with evidence rather than complying. 0075's mattered: the checker's own suggested replacement sentence carried a fresh factual error, and following it literally would have put a third wrong claim into the paragraph whose entire job is to be exact.

What is deliberately not here

• 0179 and 0176 were rejected a second time (a provenance paragraph; a splice defect the dry run could not see). Not applied, rather than applied unverified.
• #1506 was allocated and is burned. It would have said ADR 0129 cites a parity test with zero Postgres/SQL Server references. All three limbs failed on checking: the file names both backends in its docstring, ADR 0129 never cites it for parity and says plainly that parity is a CI gate, and tests/test_store_schema_hash.py already asserts the DDL in all three _SCHEMA sets. It came from a critic whose other points held — which is why it was checked rather than taken.

Method and its limits

Four workflows, 191 agents, ~22M subagent tokens. Every agent was required to report a positive control that fired alongside any null result, and told the ADR 0124 story (wait_for_ack returns zero; the real knob is no_ack; the feature is built) so a null reads as a wrong needle before it reads as an absence.

The over-claim hunt's own critic is worth quoting against it: it inverted the one-sidedness rather than escaping it. Three of the five survivors were already written down somewhere in the repo before the hunt ran (0075's unchecked box, BACKLOG.md:698, BACKLOG.md:270). Only 0089 and 0150 are independent discoveries. A cleaner instrument would find an over-claim in an ADR with no ledger row and no unchecked box.

Also unresolved and worth someone's attention: 0013 carries two documents under one index row, so both audits graded one file and never opened the other.

Severity is conditional throughout per CLAUDE.md §0 — zero deployments. Nothing mis-executes; what was wrong is the record.

Checks

Check	Result
pre-commit, all three commits	passed, ledger gate included
open-count control	items 489 to 492, open 300 to 303, closed 189 flat — expected delta for filing 3
backlog_status_check.py --quiet	exit 0
link_check.py docs	5040 relative links in 303 files, all resolve
control_char_check.py	clean
ruff / mypy / pytest	not run — no code changed, docs only

Rebuilt onto current main rather than pushed onto the old branch: #1003 squash-merged, so its commits are not ancestors and the old branch would have re-proposed merged work.

🤖 Generated with Claude Code