docs: make .fusa-reqs.json an honest map of TC18's endpoint-layer normative surface

[SoundMatt]

What

A systematic pass over TC18's endpoint layer against this repo's requirements corpus, closing the gap between "what .fusa-reqs.json claims" and "what TC18 actually requires".

Sections walked clause by clause: §13.1, §13.2 (Table 28 ep_generic_config, Table 29 ep_type), §13.3 request validation, §13.4, §13.5 (Table 30) and §13.5.1 (compound-wait evt modes), §13.7.1 RC Server endpoint (Tables 33/34), §13.7.2 Wakeup (Tables 36/37), §13.7.3 SPI (Tables 38/39), §13.7.4 GPIO (Tables 40/41), §13.7.5 PWM_OUT (Tables 42/43), §13.7.6 PWM_IN (Tables 44/45), §13.7.7 I²C (Tables 46/47), §13.7.8 UART (Tables 48/49), §13.7.9 ADC (Tables 50/51), §13.7.10 LIN (Table 52), §13.7.11 CAN (Tables 53/54), §13.7.12 ISELED (Table 55), §13.7.13 MDIO (Tables 56/57).

Result: 375 → 435 requirement entries.

	count
New entries, behavior implemented (full req + real test)	7
New entries, [NOT IMPLEMENTED]	53
Existing entries corrected (described removed symbols)	2

Every new entry cites the exact TC18 section and, where applicable, table or figure. No feature code is added or changed.

Implemented (requirement + literal, spec-derived test)

• REQ-ENDPOINT-007 — every ep_type id matches §13.2 Table 29, ids pairwise distinct, 0x0A (DAC) and 0x00 (Server) not squatted on.
• REQ-EVT-001 — §13.5's evt[3]=acknowledge / evt[2:0]=operation split, asserted against the raw wire nibble, not just a struct round-trip.
• REQ-GPIO-009 — §13.7.4.3's "OR with an all-zero payload results in no change", including that it fires no edge triggers.
• REQ-PWM-008 — §13.7.5.3's exactly-four-bytes rule (over-long rejected as well as short).
• REQ-I2C-006 — §13.7.7.4 Table 47 lists three trigger ids with the Event column blank in v0.5.1_RC, so TransferComplete/Nack are this implementation's own assignment; the test pins the ids and asserts id 2 is never fired.
• REQ-MDIO-006 — §13.7.13.3 Table 57 gives selector 01b twice and never lists 00b; the entry records how cpp-RCP resolves that defect and that both MMS values stay at Table 57's 10b/11b.
• REQ-WIRE-016 — §13.3's "tu=1 is executed as if tu=0", tested by decoding two headers differing only in that bit.

Corrected stale entries

• REQ-PWM-006 claimed a MidPulse PWM_IN trigger signal. That symbol was removed at v2.16.0; PWM_IN now has Table 44's rising/falling pair. Text rewritten to the current behavior + Table 44 citation.
• REQ-ISELED-004 claimed a NativeCrcError trigger. Removed together with the invented CRC-8; §13.7.12.1 gives ISELED exactly one trigger event. Text rewritten and now cross-references the CRC gap entry.

Both entries were passing traceability while describing code that does not exist — worth noting as a corpus-rot pattern.

Not-implemented convention

Title ends [NOT IMPLEMENTED], text starts NOT IMPLEMENTED: , followed by what TC18 requires, the citation, and the reason where determinable (e.g. REQ-ENDPOINT-008: TC18 allocates DAC's ep_type but defines no behavior chapter for it; REQ-ISELED-007: TC18 defers the ISELED-native CRC algorithm to a separate standard not available here).

Each carries a //fusa:req tag on the header where the feature would live, and every such header gains a TC18 conformance gaps (not implemented) comment block naming the entries, so the gap is visible from the code and not only from the corpus.

Follow-ups: three genuine conformance bugs found while writing accurate descriptions

Not fixed here — this pass is corpus-completeness only. Each is filed as a [NOT IMPLEMENTED] entry so it is at least tracked.

1. CAN FrameFormat values disagree with §13.7.11.3 Table 54 on the wire (REQ-CANEP-008). Table 54: CBFF=0, CEFF=1, FBFF=2, FEFF=3, XL-classic-PL=4, XL-new-PL=5, 6-7 reserved. rcp::can::FrameFormat is Classical=0, Fd=1, Xl=2 — so an FD frame encodes as Table 54's CEFF, the two XL physical-layer variants are collapsed, the base/extended distinction that Table 54 carries in the format field lives in CanIdentifier::extended instead, and the reserved values are not rejected. This is wire-visible, not cosmetic.

2. GPIO writes are applied to pins configured as inputs (REQ-GPIO-010). §13.7.4.3 requires a write addressed to an input pin to be ignored for that pin. apply_gpio_write consults GpioState::directions only for Reconfigure; every other semantics writes all 32 bit positions unmasked.

3. PWM_OUT rejects five of Table 30's eight evt[2:0] semantics (REQ-PWM-010). §13.5 Table 30 puts GPIO and PWM_OUT in one row, and its examples for 101b/110b name increasing and decreasing the duty cycle of PWM_out explicitly. REQ-PWM-003's stated rationale — that the spec describes no combining write behavior for PWM_OUT — is contradicted by Table 30. That existing entry is left untouched here; resolving the contradiction means changing behavior.

Also recorded rather than resolved: REQ-ENDPOINT-009 — §13.5 states the add/subtract saturation bounds literally as 0x0000/0xFFFF, while apply_bitmask_write saturates at the caller's operand width, so a 32-bit GPIO payload saturates at 0xFFFFFFFF. Whether TC18's bound is 16-bit-specific or universal is not resolvable from the text, so the divergence is documented in both directions rather than silently picked.

Verification

• cmake --build build --parallel clean; ctest 53/53 pass.
• cpfusa check — 0 errors (2 pre-existing warnings, 1 info, unchanged).
• cpfusa trace --req-coverage 100 — passes; annotation coverage stays 100% (435/435), which is the gate ci.yml enforces.
• clang-tidy -p build --warnings-as-errors='*' on every touched test translation unit — 0 findings.
• Test coverage moves 375/375 (100%) → 382/435 (87.8%) by design: a requirement recording behavior that does not exist has nothing to assert, and writing a tautological test to keep the number at 100% would defeat the point of the pass. --req-coverage gates annotation coverage only (cpp-FuSa src/cmd/cli.cpp maps it to min_annotation_pct; min_test_pct comes from a separate flag CI does not pass), so no gate regresses.

Scope note

This pass covers §13 in full. §10-§12 were surveyed but only entered where a §13 clause pointed into them (§12.9.6's Table 27 error codes were checked and are complete, all 17 values present with correct numbering; §13.3's request-validation clauses produced REQ-WIRE-016/REQ-WIRE-017). A comparable clause-by-clause pass over §11.2's request taxonomy, §11.3/§11.4, and §12.3-§12.10 remains open and is the natural next increment.