Implements: trailers are never relevance-checked — 51 of 73 production commits, and five repeater commits claim 'signed transfer manifests'

[dc0sk]

Follow-up from #1371, split out rather than widening PR #1401. Found during the adversarial review recorded in docs/dev/reviews/review-1371-split-and-enforce.md, and re-derived independently before filing.

The gap

#1401 enforces relevance — a named capability must own at least one file the change touched — but only for Refactors:. Implements: names a requirement, and nothing checks that the requirement's covering capabilities own anything the change touched.

Measured over the last 400 commits, production-touching only:

Refactors:        22
Implements: only  51     <- never relevance-checked

Of the 51, 29 name a requirement whose covered_by capabilities own none of the touched files.

The systematic instance

Five repeater commits carry Implements: REQ-FUN-11, which reads "Support signed transfer manifests" and is covered by CAP-03 (manifest.rs) and CAP-71 (filexfer). The repeater crate is CAP-47.

commit	subject	touched (example)
59784df1	fix(repeater): identify while idle, under its own key	openpulse-daemon/src/server.rs
42369e60	fix(repeater): recover from a panic without handing back a keyed rig	openpulse-daemon/src/lib.rs
4d268836	fix(repeater): hand the repeater back so a stopped one can restart	openpulse-daemon/src/lib.rs
ceaa3d4f	fix(repeater): listen to rig_b's band before keying it	openpulse-config/src/lib.rs
fcbb8594	fix(repeater): hear what the daemon hears, and be startable	openpulse-config/src/lib.rs

That is the same copy-paste shape #1371 was filed for, in the half of the trailers nobody is checking — and it is the larger half.

Why it is not simply "apply the same rule"

Implements: is a requirement→capability→file join, not a direct one, so the rule has a choice the Refactors: case does not:

1. Require the requirement's covered_by capabilities to own a touched file. Direct analogue. But it inherits every narrowness in covered_by: 29 of 51 flag today, and an unknown share of those are map gaps rather than mislabels — the same 09048b84 shape that made me briefly adopt the wrong predicate in feat(trace): enforce trailer relevance, on the path that actually guards main (#1371) #1401.
2. Report-only for Implements: until the flagged 29 are triaged.
3. Triage the 29 first, then enforce — the ordering the 2026-09-15 decision used for code:, which worked.

Option 3 looks right by precedent, but the triage is the work and it is not clerical: telling a mislabel from a narrow covered_by needs reading each commit.

Prerequisite

The 29 need adjudicating before any of this is a gate, exactly as the 8 Refactors: failures were adjudicated in review-1371-capability-ownership.md (7 true mislabels, 1 map gap). Until then the honest statement is that half the trailers on main carry an unchecked claim.

Related: #1371, #1283 (give requirements a verification: field).

🤖 Generated with Claude Code

https://claude.ai/code/session_0188ATCj6DZ9aRVQ2vSirua6

[dc0sk]

Adjudication of the 29 (2026-09-19): 9 real mislabels, 20 false positives — do NOT apply the relevance rule to Implements:

I filed this implying Implements: should get the same relevance check as Refactors:. Checking the structure before the instances — the order I should have used on #1409 — shows that is a category error, and the numbers confirm it.

The structural argument, from the script's own header

Implements: REQ-x    product behaviour SERVING a requirement
Refactors:  CAP-x    STRUCTURAL CHANGE to a capability

The relevance rule ("does the named thing own a file you touched?") is a structural test, correctly applied to a structural claim. Implements: is teleological — a commit can legitimately serve a requirement by adding its test, fixing a caller, changing a default, or removing a blocker, touching no file its capabilities own. Same shape as #1409: I measured instances and inferred a gap, where measuring the claim's meaning shows there is no gap to measure.

Adjudicated by purpose, all 29

Real mislabels — 9 (31 %)

commits	trailer	why it is wrong
59784df1 42369e60 4d268836 ceaa3d4f fcbb8594	REQ-FUN-11 "Support signed transfer manifests"	five repeater fixes — panic recovery, restart, carrier sense, idle ID. No reading serves signed manifests. A copy-paste run, same shape as the CAP-59 cluster in #1371
185ce8d1	REQ-OBS-02 "Persistent rotating file logging"	"a repeater that is not running is no longer reported as running" is not logging
6f06b0f6	REQ-SEC-13 "every signing context bound to a registered domain"	refusing a wildcard ConnectPeer dial is not signing-domain work
d8527a3f	REQ-SEC-13	rejecting non-zero ACK reserved bits is not signing-domain work
561f064a	REQ-DISC-01 "Native JS8-compatible waveform"	a rendezvous codec dialect token is REQ-DISC-07 ("2-message rendezvous over JS8"). Now visibly wrong after #1400 split the waveform into CAP-79

False positives of the file-overlap rule — 20 (69 %), each defensible on purpose: eight REQ-PTT-01 keying fixes, two REQ-DEV-01 audio-device pins, three REQ-FUN-06 HPX adaptive-modulation fixes, two REQ-SEC-10 envelope/QSY integrity changes, plus REQ-QRM-01 (notch), REQ-FUN-09 (ACK scan serving ARQ retransmission), REQ-REG-10 (137e4a89 removes mesh's audio route because it had no station-ID timer — it serves the requirement by removing a non-compliant transmitter), REQ-UX-02, REQ-RX-03.

A file-overlap check on Implements: would therefore be wrong 69 % of the time. That is not a gate; it is noise with a red build attached.

A separate finding, worth its own issue

Eight commits map "every emission keys the transmitter" onto REQ-PTT-01, whose statement is "PTT assert/release within 50 ms" — a timing requirement. Keying-at-all and keying-within-50 ms are different properties, and PTT-01 is the only PTT requirement, so it absorbs both. The trailers are defensible only because there is nowhere better to point. That looks like a missing requirement ("every emission keys the transmitter"), which is the kind of gap CLAUDE.md's acceptance table already pins with three separate rows and the registry does not carry.

Recommendation

1. Do not build the relevance check for Implements:. The structure does not support it.
2. Correct the 9 in the record. They are merged, so the ledger is the only place the record can still be fixed — the same remedy The requirements-trailer lint checks that a CAP id EXISTS, not that it is the right one — 4 of the last 14 name an unrelated capability #1371 applied to its four. Five of the nine are one copy-paste run.
3. File the REQ-PTT-01 double-duty gap separately if it is worth a requirement.

The original framing of this issue — "51 of 73 production commits carry an unchecked claim" — is true but misleading: the claim Implements: makes is not one this check could have checked.

🤖 Generated with Claude Code

https://claude.ai/code/session_0188ATCj6DZ9aRVQ2vSirua6

[dc0sk]

Closing: adjudicated and acted on.

Outcome. The 29 flagged resolve to 9 real mislabels and 20 false positives (69 %). No relevance check is built for Implements:, and none should be — it is a teleological claim ("product behaviour serving a requirement") and the file-overlap rule is a structural test, so it would fire wrongly more often than rightly.

Acted on: the 9 are corrected in the ledger via #1410 (60a14514), the only place a merged squash message's record can still be fixed. The unifying finding is that most carried the wrong trailer type, not merely the wrong id — and Refactors: CAP-47 on the repeater cluster was verified to PASS the live relevance rule, so the correct trailer was also the checkable one.

Split out: #1411, for the REQ-PTT-01 double-duty gap that eight of the twenty defensible commits exposed — 'every emission keys the transmitter' has three acceptance rows and no requirement id.

The issue's original framing ('51 of 73 production commits carry an unchecked claim') was true but misleading: the claim Implements: makes is not one this check could have checked. Recorded on the adjudication comment so it is not re-derived.