jouleclaw-compliance: EU Cyber Resilience Act Article 14 reporting as an auditable filing chain #282
2026-10-16
jouleclaw-compliance: a later-stage CRA filing carries the earlier stages' information
All checks were successful
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 5s
repository checks / lockfiles, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 1m32s
standards workspaces build + test / mesh-rs (mesh/mesh-rs, -p mesh-engine-gguf -p mesh-openai --features mesh-engine-gguf/gguf,mesh-openai/server, mesh-rs, linux-arm64) (pull_request) Successful in 1m5s
standards workspaces build + test / jouleclaw-rs (-nodebug, jouleclaw/jouleclaw-rs, -p jouleclaw-energy --features rapl,nvml, jouleclaw-rs, linux-arm64, -C target-feature=+fp16) (pull_request) Successful in 2m52s
jouleclaw public surface must stay documented / Public-surface audit (jouleclaw-rs) (pull_request) Successful in 1m3s
standards workspaces build + test / macOS energy backends (pull_request) Successful in 5m2s
standards workspaces build + test / jouledesk-rs (jouledesk/jouledesk-rs, jouledesk-rs, macos) (pull_request) Successful in 52s
As first built, a stage was satisfied only by a filing at exactly that stage, or one that listed it in `also_provides`. A final report filed without a separate notification therefore left the notification stage unsatisfied. Since a stage cannot be filed after a later one, it would have stayed overdue for good, although the final report carries everything the notification does. `Filing::provides(stage)` is now `self.stage >= stage` or a stage listed in `also_provides`. Each stage's content contains the earlier stages', and `also_provides` keeps its real job: declaring that a filing already carries a LATER stage's information early. The module and method docs say so. `a_later_stage_carries_the_earlier_ones` covers a final report filed on time and one filed late with no separate notification. Co-Authored-By: Claude Opus 5.5 <[email protected]>
jouleclaw-compliance: EU Cyber Resilience Act Article 14 reporting as a filing chain
A new `cra` module records one Article 14 case (an actively exploited vulnerability, Regulation (EU) 2024/2847, Art. 14(2), or a severe incident, Art. 14(4)) as a hash-linked chain of filings. Every accepted filing's BLAKE3 content hash is a leaf in a Merkle log, and filing returns a receipt carrying the leaf index, content id, inclusion proof and root. A filing altered after it was filed no longer verifies against its receipt. The chain refuses a filing for another case or subject, one that does not supersede the current head, one dated before the previous filing, one whose stage is behind the furthest filed, one that moves awareness later, one dated before its own awareness, and one naming a product twice. An earlier awareness is accepted and moves the deadlines earlier. Deadlines: early warning 24 h and notification 72 h after the chain's earliest awareness; the vulnerability final report 14 days after the earliest stated corrective measure; the incident final report one calendar month after the filing that satisfied the notification. The early warning is satisfied by any filing; the later stages by a filing at that stage or one declaring the stage in `also_provides`. Also: known_at(t), per-product status revisions, tree heads for signing, consistency and inclusion proofs, and replay from stored filings. Co-Authored-By: Claude Opus 5.5 <[email protected]>