rajames/LithosAnanke
1
1
Fork 0
Code Issues 76 Pull Requests 1 Actions 2 Packages Projects 1 Releases 6 Activity

plan: the FMEA in the PR review -- section 8, for ruling (CAPA & FMEA gate)

Browse Source 
Captain Bob, 2026-11-12: "Is it possible to include the FMEA in the pr
review? That way the items are forced into a manual review beforehand?" --
"Yes, add it to the plan". Each FMEA row names its paths; the PR carries a
review record with a decision for every row its diff touches; a
check_fmea_review.sh beside check_protocol.sh refuses the PR without one, or
with one for another diff. A sixth point to rule. Nothing built.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
This commit is contained in:
Claude
2026-11-12 00:45:35 +00:00
parent 1f94a048f4
commit 4d4706c389
1 changed files with 27 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/v4.0.0/plans/2026-11-11-capa-fmea-gate.md
+27
View File
@@ -91,6 +91,33 @@ Threshold: RPN >= 100, or Severity >= 9 at any RPN.
3. Where: a stage in `acceptance.yml` (my call), or a separate required check?
4. The scales and the threshold (section 5).
5. Which of section 4's five become CAPAs.
6. The FMEA in the PR review (section 8), or not.
Don't over-engineer: start with the escaped defects and an FMEA grown as defects arrive, not a
large table written up front.
## 8. The FMEA in the PR review: a manual review forced before the merge
Captain Bob, 2026-11-12: "Is it possible to include the FMEA in the pr review? That way the items
are forced into a manual review beforehand?" -- then "Yes, add it to the plan". As with the protocol's
evidence (#135), the review is a record committed in the PR, and the gate refuses the PR without it.
- **Each FMEA row names the paths it concerns** (`paths:` in `fmea.yml`), narrowly: the MINT-ZUSE row
`kernel/src/v4/sk_v4_mint.c`, the put-back row `scripts/nightly.sh` and the scripts it lists.
- **The PR carries `docs/quality/reviews/<TS>.yml`:** for every row whose paths the PR's diff against
`master` touches -- the row's id; the decision (scores unchanged / raised / lowered, a control
added); one line of why; and any failure mode the change brings, as a new row in `fmea.yml`.
- **The gate:** `scripts/check_fmea_review.sh` in `acceptance.yml`, beside `check_protocol.sh`, refuses
the PR when a touched row has no entry, an entry names a row that does not exist, or the review was
made for another diff (it names the base and head it reviewed, as PROTOCOL.md names its commit).
It prints exactly which rows the PR triggers, so the review is of those and no more.
- **The PR template** gets an "FMEA review" section pointing at the file: the review is done before
the PR is opened, not after.
- **What it forces, and what it cannot:** that every affected row was looked at and a decision
written down. Whether the thinking was honest stays a person's: Captain Bob's while there is one
developer; with a second, branch protection's required approval as well, the record telling the
reviewer what to check.
- **The risk:** rows mapped too coarsely make every PR touch dozens, and the review becomes ticking
boxes. Rows are mapped narrowly, and a row that triggers on most PRs is split.
*To rule:* a sixth point -- the FMEA review in the PR, as above, or not.