diff --git a/docs/v4.0.0/plans/2026-11-11-capa-fmea-gate.md b/docs/v4.0.0/plans/2026-11-11-capa-fmea-gate.md
index 3283c3d2..4ed1aa1f 100644
--- a/docs/v4.0.0/plans/2026-11-11-capa-fmea-gate.md
+++ b/docs/v4.0.0/plans/2026-11-11-capa-fmea-gate.md
@@ -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.