Files
bfe-core1106-sdk/docs/decisions/0002-mcdc-tiering.md
T
BFE EngineeringandClaude Opus 4.8 5a8b60ba3a review: iteration-2 fixes (fail-closed loader whole-name match + doc accuracy)
Second recursive pass: two adversarial re-reviewers verified the iteration-1 fixes.
Fuzz/empirical checks cleared the freshness min-budget rewrite (200k random trials),
the config-lint reg-token scanner, its UTF-8 boundary safety, and the build-kernel.sh
trap (5 exit scenarios) — no defects. Three items corrected here:

- config-lint is_known_safe_loader: match the WHOLE normalized loader name, not an
  unanchored substring. The iteration-1 allowlist swap kept `contains()`, so a future
  coprocessor whose name merely contained a boot word ("AudioLoader" ⊃ "loader",
  "SplRtos" ⊃ "spl", "Bl32" ≠ "bl31") would have been waved through — reopening the
  0x40000-brick false-negative the fail-closed change exists to prevent. Regression
  test added with those exact adversarial names.
- docs/architecture.md §3: the `cru` bullet no longer claims flared's devmem `Bus`
  seam is shipped — it lands when flare-edge consumes warden-sdk ([maintainer]-gated), which
  is what §7 item 3 already said. Resolves an in-document contradiction.
- drivers/README.md: modbus "11 pty scenarios" -> "8 pty scenarios + 3 wire/daemon
  checks (11 total)", matching flare-edge tools/modbus-sim's actual SCENARIOS list.
- docs/decisions/0002-mcdc-tiering.md: Consequences now describe the shared
  drivers/enforce-mcdc.sh + drivers/<name>/test/ layout actually built (not the
  per-driver dirs the ADR first anticipated); Rust MC/DC tooling reality noted.

config-lint: 9 tests pass; clippy clean under -D warnings; gitleaks clean. C drivers
untouched (still relays 40/40, freshness 66/66 MC/DC).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017wB8KB3MMQztRDXCMCkPrf
2026-08-25 16:02:22 -06:00

34 lines
1.8 KiB
Markdown

# ADR 0002 — Tiered MC/DC coverage policy
**Status:** Accepted (2026-08-25).
## Context
The goal "port + harden 100% of drivers to 100% MC/DC" is infeasible as literally
stated: ~97% of driver LOC is vendor blobs (the AIC8800 wifi driver alone is 88.5K
lines) that we cannot meaningfully unit-test to MC/DC on the host. Forcing MC/DC on
that code would be theatre, not assurance.
## Decision
A **two-tier** policy, measured against the Hardware Abstraction Seam:
- **Tier 1 — our own hardware-facing code → real 100% MC/DC.** `modbus_engine.c`,
`relays.c`, `warden_rga.c` (wrapper), `hpmcu.rs`, `devmem.rs`, `freshness.c`, plus
the two smallest near-mainline drivers where feasible. Enforced in CI
(`gcc-14 -fcondition-coverage` + `gcov-14 --conditions`). Rust uses
`cargo-llvm-cov` line/region coverage for now — true `--mcdc` needs a nightly
toolchain (`-Z coverage-options=condition`) and is deferred on that tooling skew;
the C drivers carry the literal MC/DC gate.
- **Tier 2 — ported/vendor drivers → fault-injection + branch coverage + benchmarks**
against the simulator, behind a stable seam. Explicitly NOT literal MC/DC.
## Consequences
- Matches the user's framing: "as many drivers as possible at 100% MC/DC; for the
rest, a very serious testing and benchmarking system."
- The seam is the shared object: the same thing MC/DC is measured against and the
simulator implements — the two goals reinforce, not duplicate.
- Every Tier-1 file gets a `drivers/<name>/test/` host harness (a `Makefile` +
`test_<name>.c`) that calls the one shared `drivers/enforce-mcdc.sh` — which derives
the driver name from the `.gcov` file, so there is a single gate to maintain, not a
per-driver copy. The CI `mcdc` job auto-discovers any `drivers/*/test/Makefile` and
fails below 100%.