rewrite(phase6): batch 9 — MDIO/PWM catalog re-derivation - #162
Merged
Conversation
Part of the v3.0.0 ground-up rewrite (cpp-RCP #129, ROADMAP.md Phase 17), branch rewrite/v3-from-c-rcp. Phase 6 (requirement catalog), batch 9 of 13. ## Scope mdio.hpp's REQ-MDIO-* (c-RCP: 28 entries), pwm.hpp's REQ-PWM-* (75, the largest single per-endpoint prefix in the whole catalog) -- 103 c-RCP entries total. ## Major finding: same pattern as batches 7/8 Both modules' code and tests were already ported ahead of the catalog in an earlier untracked pass -- mdio.hpp/test_mdio.cpp needed zero edits at all (top-of-file manifests already covered the full 28-id c-RCP range). The gap was almost entirely catalog-side, plus 14 pre-existing low-numbered id collisions. ## New catalog entries (87) - MDIO: 21 (REQ-MDIO-008-028) - PWM: 66 (REQ-PWM-010-026, 060-075 minus already-covered/collision ids) ## Id-collision gaps filed (14) - MDIO: 7 (001-007) -- old entries describe unrelated pre-rewrite content (ep_type id, payload width validation); real c-RCP content (addr_valid, burst_next_regad, word_encode/decode, pack_len/words, word_count_of) genuinely implemented+tested under the same bracket numerals -- a legitimate dual-tag overlap, not a gap. - PWM: 7 (001, 004-009) -- verified content collisions directly, e.g. cpp's REQ-PWM-008 carries severity:cybersecurity and describes handle_request Row-2 classification, while c-RCP's real REQ-PWM-008 (RESERVED4 no-op) is unrelated and genuinely tested elsewhere. REQ-PWM-001 is an honest architecture divergence, not force-fit as a collision or a gap: cpp has no validate-and-reject write_semantics_valid(); endpoint::write_semantics_of() masks to 3 bits instead, making every input constructively valid -- same safety property, different shape, cited to test_endpoint.cpp's REQ-ENDPOINT-002 tests. ## Already-covered, no action (2) REQ-PWM-002 (exact 1:1 match), REQ-PWM-003 (cpp's own entry bundles Or/And/Xor/Add/Subtract under one id; OR is a literal subset). ## Real tested-coverage gaps found and closed (2, following batch 8's lesson) Grepped the whole include/+tests/ tree for every id before adding it (per the explicit instruction added to this batch's dispatch after batch 8's CI-caught miss): found REQ-PWM-041 (PWM_IN strerror uniqueness -- cpp shares one PwmErrc/pwm_category() across PWM_OUT/ PWM_IN, unlike c-RCP's two separate functions, so no dedicated test existed) and REQ-PWM-061 (decode_read_request rejects a non-ACF_ABB frame -- no test covered bad_msg_type for PWM_OUT's read-request decode at all). Strengthened the existing REQ-PWM-024 message test into an exhaustive non-empty/distinct-message-per-code loop (dual- tagged [REQ-PWM-024][REQ-PWM-041]), and added a new TEST_CASE for REQ-PWM-061 mirroring test_mdio.cpp's existing pattern for the same check. ## Verification Independently re-verified (the porting agent's own final step re-ran a whole-catalog tag-coverage script covering all 869 entries, not just this batch's 103 -- confirming no regression to batches 1-8): semantic id-keyed diff confirms zero pre-existing entries modified/ deleted, exactly 87 new ids matching the report's per-prefix breakdown exactly (MDIO 21, PWM 66), zero duplicate ids. Independently re-ran my own from-scratch Python tag-coverage check against the merged worktree (not trusting the agent's script output alone): confirmed 869/869 entries have both a real //fusa:req and a real //fusa:test-or-bracket tag somewhere in the tree, zero gaps. Confirmed no new entry carries severity:cybersecurity -- sec-tested count holds exactly at 72/869. Full tree rebuilt from scratch: 0 errors, 0 warnings, 58/58 ctest suites pass (100%). .fusa-reqs.json: 782 -> 869 entries (+87, 8003 -> 9026 lines). .fusa-reqs-pending.json: 73 -> 87 entries (+14, 783 -> 961 lines). tests/test_pwm.cpp: +42 lines. include/rcp/mdio.hpp, include/rcp/pwm.hpp, tests/test_mdio.cpp: unchanged. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Matt <47545907+SoundMatt@users.noreply.github.com>
10 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of the v3.0.0 ground-up rewrite (#129, ROADMAP.md Phase 17). Phase 6 (requirement catalog), batch 9 of 13.
This batch: MDIO (28 c-RCP entries) / PWM (75, the largest single per-endpoint prefix)
Same pattern as batches 7/8:
mdio.hpp/test_mdio.cppneeded zero edits — already fully re-derived from c-RCP in an earlier untracked pass.write_semantics_of()masks to 3 bits instead, same safety property via a different shape.REQ-PWM-041(no dedicated PWM_IN strerror test — cpp shares one error category across PWM_OUT/PWM_IN unlike c-RCP's two) andREQ-PWM-061(no test coveredbad_msg_typefor PWM_OUT's read-request decode at all). Both fixed with real tests before any catalog entry was added.Verification
Independently re-verified (the porting agent's own final step re-ran a whole-catalog tag-coverage script across all 869 entries, confirming no regression to batches 1-8): semantic id-keyed diff confirms zero pre-existing entries modified, exactly 87 new ids matching the per-prefix breakdown exactly. Independently re-ran my own from-scratch Python tag-coverage check against the merged worktree (not trusting the agent's script alone) — confirmed 869/869 entries have both a real
//fusa:reqand a real//fusa:test-or-bracket tag, zero gaps. Confirmed no new entry carriesseverity: cybersecurity. Full tree rebuilt from scratch: 0 errors, 0 warnings, 58/58 ctest suites pass.🤖 Generated with Claude Code