mandrel 1.86.0 → 1.88.0

package/.agents/skills/core/epic-plan-premortem/SKILL.md

@@ -31,7 +31,12 @@ allowed_tools:
 Senior Engineer + Architect, acting as a **fresh-context pre-mortem critic** —
 deliberately *separate* from `epic-plan-decompose-author` (the generator) and
 `epic-plan-consolidate` (the scope-preserving merge critic) so it is a
-fresh-context, code-reading review, not a same-pass self-critique.
+fresh-context, code-reading review, not a same-pass self-critique. The `/plan`
+workflow delivers that fresh context by **dispatching this skill inside a
+genuine sub-agent** (`Agent` tool, `subagent_type: general-purpose`) at Phase
+8.5, rather than activating it inline in the authoring turn — the sub-agent does
+not inherit the authoring conversation, so its code-reading review is
+independent of the draft it grades.
 
 > **Read [`examples.md`](./examples.md) on demand** for the extended rationale:
 > why this critic opens the actual cited code, why it is additive-recommendation
@@ -52,7 +57,8 @@ surfaces reaches GitHub unreviewed.
 
 ## Inputs
 
-The workflow passes the Epic ID as the Skill argument. The Skill itself reads:
+The `/plan` workflow dispatches this skill inside a fresh-context sub-agent,
+passing the Epic ID as the Skill argument. The Skill itself reads:
 
 - `temp/epic-<Epic_ID>/tickets.json` — the **draft** (or consolidated) Story
   array. This is the pre-mortem subject.

package/.agents/skills/skills.index.json

@@ -1,5 +1,5 @@
 {
-  "generatedAt": "2026-07-04T23:12:38.376Z",
+  "generatedAt": "2026-07-08T12:24:41.101Z",
   "generator": "generate-skills-index.js@1",
   "skills": [
     {
@@ -377,8 +377,8 @@
       "tier": "stack",
       "category": "architecture",
       "path": ".agents/skills/stack/architecture/subagent-orchestration/SKILL.md",
-      "description": "Coordinates complex tasks via task-isolated subagents. Use when one objective is too large for a single agent or when independent work streams should run concurrently with minimal context bleed. One objective per subagent; summarize before returning to keep the main context window clean.",
-      "policyCapsuleBullets": 7,
+      "description": "Coordinates complex tasks via task-isolated subagents. Use when one objective is too large for a single agent or when independent work streams should run concurrently with minimal context bleed. One objective per subagent; summarize before returning to keep the orchestrator's context window clean. Applies recursively — an orchestrator at any supported nesting depth applies the same policy to its own children.",
+      "policyCapsuleBullets": 8,
       "allowedTools": null,
       "vendor": null
     },

package/.agents/skills/stack/architecture/subagent-orchestration/SKILL.md

@@ -4,11 +4,33 @@ description:
   Coordinates complex tasks via task-isolated subagents. Use when one objective
   is too large for a single agent or when independent work streams should run
   concurrently with minimal context bleed. One objective per subagent;
-  summarize before returning to keep the main context window clean.
+  summarize before returning to keep the orchestrator's context window clean.
+  Applies recursively — an orchestrator at any supported nesting depth applies
+  the same policy to its own children.
 ---
 
 # Skill: Subagent Orchestration
 
+## Recursive orchestration model
+
+This skill describes **recursive orchestration**, not a fixed two-tier
+"main agent vs. subagents" split. An **orchestrator** is any agent that
+dispatches sub-agents; a sub-agent is itself an orchestrator over its own
+children. The Claude Code harness carries the `Agent` tool into sub-agents
+(verified nesting depth 2, announced max depth 5; see
+[#2870](https://github.com/dsj1984/mandrel/issues/2870)), so the same
+one-objective / verify / parallelize policy applies **at every level** —
+substitute "orchestrator" for "main agent" and "child" for "subagent"
+throughout and the rules hold unchanged. Keeping a given dispatch level
+flat remains a legitimate **design choice** (e.g. the `/deliver` wave
+loop), but it is no longer forced by a harness limitation.
+
+The cost caution compounds with depth: every nesting level re-pays the
+full always-loaded context, so an orchestrator MUST weigh the depth it
+opens against its budget (see
+[`instructions.md` § 4](../../../../instructions.md)) and stay within the
+supported depth envelope.
+
 ## Policy Capsule
 
 - Dispatch one objective per subagent; never bundle unrelated goals into a single delegation.
@@ -16,11 +38,13 @@ description:
 - Specify the expected return format explicitly (JSON summary, diff, bullet list) in every handoff.
 - Verify the subagent's output before incorporating it; treat returned artifacts as untrusted until checked.
 - Run non-dependent subagents in parallel; serialize only when one subagent's output is required input for another.
-- Require a concise summary back from each subagent to keep the main context window clean.
+- Require a concise summary back from each subagent to keep the orchestrator's context window clean.
 - Investigate subagent failures rather than retrying blindly with the same prompt.
+- Respect the nesting depth budget; each level opened re-pays the always-loaded context, so orchestrate deeper only when the isolation or parallelism gain justifies the cost.
 
 Internal protocol for managing complex tasks through the creation and
-coordination of subagents.
+coordination of subagents, applied recursively by the orchestrator at any
+supported depth.
 
 ## 1. Core Principles
 
@@ -28,8 +52,11 @@ coordination of subagents.
   with multiple unrelated tasks.
 - **Minimal Context:** Provide only the necessary context (files, docs, specific
   goal) to keep the subagent focused and token-efficient.
-- **Verification:** The main agent must always verify the subagent's output
-  before incorporating it into the final solution.
+- **Verification:** The orchestrator must always verify each child's output
+  before incorporating it into its own result — at every level of the tree.
+- **Depth Awareness:** Orchestration is recursive; before opening a deeper
+  level, confirm the work justifies re-paying the always-loaded context and
+  that the nesting stays within the supported depth envelope.
 
 ## 2. Operation Standards
 
@@ -38,11 +65,12 @@ coordination of subagents.
 - **Error Handling:** If a subagent fails or returns an ambiguous result,
   investigate the failure rather than retrying blindly.
 - **Parallelism:** Use subagents to perform non-dependent tasks concurrently
-  (e.g., auditing three different modules simultaneously).
+  (e.g., auditing three different modules simultaneously). A child that is
+  itself an orchestrator may parallelize its own sub-units the same way.
 
 ## 3. Best Practices
 
-- **State Sync:** Ensure the main agent's mental model remains the source of
+- **State Sync:** Ensure the orchestrator's mental model remains the source of
   truth if multiple subagents modify the codebase.
 - **Summarization:** Require subagents to provide a concise summary of their
-  findings to prevent the main context window from being flooded.
+  findings to prevent the orchestrator's context window from being flooded.

package/.agents/workflows/git-cleanup.md

@@ -18,11 +18,17 @@ confirmation:
 3. **reap merged local branches** — the existing squash-aware
    `gh pr list --state merged` + `git branch --merged <base>` sweep,
    with attached worktrees removed first. Optionally also deletes the
-   `origin/<branch>` ref when `--remote` is passed. With `--remote`,
-   the planner additionally enumerates `refs/remotes/origin/*` and
-   reaps any **remote-only** merged branches — branches whose local
-   ref is already gone (or never existed) but whose `origin/<branch>`
-   still points at a merged PR.
+   `origin/<branch>` ref when `--remote` is passed. Every default run
+   also **enumerates** `refs/remotes/origin/*` and reports any
+   **remote-only** merged branches — branches whose local ref is
+   already gone (or never existed) but whose `origin/<branch>` still
+   points at a merged PR — even without `--remote`; `--remote` is still
+   required to *delete* them. A third branch, whose content already
+   landed in `<base>` by another route (a squash-merged Epic PR, a
+   cherry-pick, a manual `merge --squash`), is caught by a
+   **content-equivalence probe** (`git merge-tree --write-tree`,
+   git ≥ 2.38) even when it has no merged PR of its own and is not a
+   git ancestor of `<base>`.
 4. **triage `git stash` entries** — list every stash and prompt for
    `drop / keep / quit` per entry (or pass `--drop-stashes <ref>` for
    non-interactive use).
@@ -150,6 +156,10 @@ programmatic consumption:
       "detectedBy": "gh"
     }
   ],
+  "skipped": [
+    { "branch": "story-4200", "reason": "not-merged", "lastCommitAt": "2026-05-01T00:00:00Z" }
+  ],
+  "ghDegraded": false,
   "worktrees": [{ "path": "C:/repo/.worktrees/fix-foo", "ok": true, "dirty": false }],
   "local":  [{ "branch": "fix/foo", "ok": true, "alreadyGone": false }],
   "remote": [{ "branch": "fix/foo", "ok": true, "alreadyGone": true }],
@@ -200,18 +210,51 @@ follow-up prune when `--remote` is set, so passing both is idempotent
 
 ### branches
 
-The merged-branch sweep semantics:
-
-- A branch is a candidate iff it is not `<base>`, not the current
-  HEAD, not in `git config branch.protectedBranches`, and either has a
-  merged PR (`gh pr list --head <branch> --state merged`) or appears in
-  `git branch --merged <base>`.
+The merged-branch sweep recognizes three detection signals, in order:
+
+1. **`detectedBy: 'gh'`** — the branch has a merged PR
+   (`gh pr list --head <branch> --state all`, classified by the
+   **latest** PR's state).
+2. **`detectedBy: 'git-merged'`** — the branch is a git ancestor of
+   `<base>` (`git branch --merged <base>`), or of `origin/<base>` when
+   that remote-tracking ref exists (unioned so a stale local `<base>` —
+   fast-forward phase skipped, or `--branches` run alone — no longer
+   hides a branch already merged on the remote).
+3. **`detectedBy: 'content-merged'`** (Story #4395) — the branch has no
+   reapable PR verdict and is not an ancestor of `<base>` under either
+   anchor, but simulating the merge via
+   `git merge-tree --write-tree <base> <branch>` (git ≥ 2.38) produces a
+   tree identical to `<base>`'s own tree — i.e. applying the branch's
+   changes on top of `<base>` is a content no-op. This catches
+   `story-<id>` branches merged into `epic/<id>` whose Epic PR
+   **squash-merged** to `main` (the story commits are not ancestors of
+   `main` and the story branch usually has no PR of its own), and any
+   other branch whose content landed via a different route (a renamed
+   head, a cherry-pick, a manual `merge --squash`). When git rejects
+   `--write-tree` (git < 2.38) or the simulated merge conflicts, the
+   probe is inconclusive and the branch keeps its existing `not-merged`
+   skip — the signal never guesses. `content-merged` candidates render
+   with a "weaker signal — verify before deleting" annotation in the
+   dry-run list and are called out separately in the confirmation
+   prompt, since — unlike a merged PR or git ancestry — no CI or GitHub
+   merge check ever validated this branch's exact diff.
+
+Other candidate semantics:
+
+- A branch is a candidate iff it is not `<base>`, not the current HEAD,
+  not in `git config branch.protectedBranches`, and matches one of the
+  three signals above.
 - When a candidate has an attached worktree, the worktree is removed
   (force if dirty) **before** `git branch -D`, mirroring the pattern in
   [`worktree-lifecycle.md`](helpers/worktree-lifecycle.md).
 - `--remote` is required on top of `--execute` to touch `origin/`.
+- A throwing `gh` runner (auth failure, rate limit, missing binary) no
+  longer aborts the run: the branches phase logs one warning and
+  continues with the git-only signals (ancestry + content-equivalence).
+  The JSON envelope's `ghDegraded: true` records that this happened for
+  the run, and the dry-run text carries a matching warning line.
 
-The skip taxonomy distinguishes two unreapable cases:
+The skip taxonomy:
 
 - `reason: 'protected'` — the base branch or a name in
   `git config branch.protectedBranches`. Not reapable; ignore.
@@ -219,15 +262,26 @@ The skip taxonomy distinguishes two unreapable cases:
   `git checkout <base>`. The dry-run output surfaces a remediation
   hint so the operator sees the recovery path without having to look
   in the JSON envelope.
-
-The `--remote` flag also opts the planner into a **remote-only
+- `reason: 'tip-diverged-from-merge'` — the latest PR merged, but the
+  branch's tip has since moved past the merged commit (a post-merge
+  force-push). The dry-run line names both SHAs and a remediation hint
+  (delete manually via `git branch -D <branch>`, or push the follow-up
+  commit).
+- `reason: 'not-merged'` — none of the three detection signals matched.
+  Previously silent; the dry-run output now lists every surviving
+  `not-merged` branch as a one-line-per-branch summary with its
+  last-commit age, so the operator can see why a leftover branch isn't
+  reaped instead of hunting for it by hand.
+
+Every default run also opts the planner into a **remote-only
 enumeration pass**: in addition to walking `refs/heads/*`, the planner
 also walks `refs/remotes/origin/*` and emits candidates for any branch
 that exists on `origin` with a merged PR but has no local ref. These
-candidates carry `detectedBy: 'remote-only'` and `localExists: false`,
-and the executor runs only the `git push --delete origin/<branch>`
-path for them (no local `git branch -D` is attempted — there is no
-local branch to delete).
+candidates carry `detectedBy: 'remote-only'` and `localExists: false`
+and are always shown in the dry-run list; **deleting** them (via the
+`git push --delete origin/<branch>` path — no local `git branch -D` is
+attempted, since there is no local branch) still requires `--remote` on
+top of `--execute`, unchanged.
 
 ### stashes
 

package/.agents/workflows/helpers/acceptance-self-eval.md

@@ -35,7 +35,29 @@ per-criterion, mid-delivery, and evaluates the actual work product.
 1. **Eval pass (fresh context, independent of the author).** Run a **separate
    critic pass** — a fresh-context sub-agent (`Agent` tool,
    `subagent_type: general-purpose`), *not* a continuation of your implementing
-   turn — so the evaluator does not grade its own homework. The critic:
+   turn — so the evaluator does not grade its own homework.
+
+   > **Inline-critic fallback (nesting-absent harness).** Dispatching the
+   > critic as a nested `Agent` is the preferred shape — it gives genuine
+   > fresh-context isolation — and works on any harness that carries `Agent`
+   > into sub-agents (Claude Code ≥ 2.1.202; see
+   > [#2870](https://github.com/dsj1984/mandrel/issues/2870)). This eval loop
+   > itself runs inside a Story delivery sub-agent, so the nested critic sits
+   > at nesting depth 2. If the host does **not** support nested `Agent`
+   > dispatch at that depth — the tool is absent, or a spawn attempt returns
+   > an unsupported-capability error — do **not** stall the Story. Fall back
+   > to authoring the verdict **inline**: in a deliberately scoped,
+   > self-critical pass (re-read only the diff, the `acceptance[]` /
+   > `verify[]` arrays, and the `verify[]` command output — treat the
+   > implementation reasoning as untrusted and score against the criteria
+   > afresh), write the same verdict file described below and hand it to the
+   > same `acceptance-eval.js` gate. The fresh-context isolation is weaker in
+   > the inline path, but the gate, the schema, the round cap, and the
+   > proceed / redraft / block decision are identical — a Story is **never**
+   > stranded on a nesting-absent harness. Note in the blocked/friction
+   > comment (if you block) that the inline fallback was used.
+
+   The critic:
    - Inspects the working diff (`git diff origin/<baseBranch>...HEAD`) and the
      Story's inline `acceptance[]` / `verify[]` arrays.
    - **Runs the `verify[]` commands** and consumes their output as **required

package/.agents/workflows/helpers/code-review.md

@@ -293,12 +293,63 @@ For every finding, provide:
   fix worked. Keep it tight (≤ 5 sentences); the sub-agent will read the
   surrounding code itself.
 
+### The `## Fixed on-branch` section (Story #4399)
+
+Findings that Step 4.5 remediated on `[HEAD_REF]` MUST be rendered under a
+dedicated **`## Fixed on-branch`** heading, **not** in the severity groups
+above. This is the contract seam that keeps remediated findings from
+spawning ghost follow-up issues: the
+[`code-review` graduator](../../scripts/lib/feedback-loop/code-review-graduator.js)
+skips every entry inside this section (both because a fixed entry is
+rendered with a **✅ prefix** — so it carries no leading severity emoji the
+parser would match — and because the parser has an explicit
+Fixed-on-branch section guard).
+
+Render each fixed finding as a `✅`-prefixed line naming its original
+severity, the file path in backticks, and the remediating commit SHA, e.g.:
+
+```markdown
+## Fixed on-branch
+
+- ✅ 🟡 Medium: `src/lib/foo.js` — missing edge-case guard added (a1b2c3d)
+- ✅ 🟠 High: `src/api/users.js` — ownership check added (d4e5f6a)
+```
+
+Open (escalated / unfixed) findings stay in their severity group with
+their leading severity emoji so the graduator still files them.
+
 ## Step 4.5 — Focused-fix Routing (host LLM, no automated loop)
 
 There is **no runtime auto-fix function** at this phase. The host LLM is
-the executor: for each 🔴 / 🟠 finding from Step 4, decide between two
-paths and keep the `code-review` structured comment authoritative for
-anything not fixed in-place.
+the executor: it decides, per finding, between a focused fix on
+`[HEAD_REF]` and leaving the finding on the `code-review` structured
+comment for the operator.
+
+### Resolve the remediation threshold (Story #4399)
+
+Read `delivery.codeReview.autoFixSeverity` from the resolved `.agentrc.json`
+(default **`medium`**; the resolver in
+[`config/runners.js`](../../scripts/lib/config/runners.js) supplies the
+default when the key is absent). The threshold governs **which severities
+route into on-branch remediation** — it never changes the halting rule (a
+surviving 🔴 still stops) or the escalation classes:
+
+- **`medium`** (default) — route 🔴 Critical, 🟠 High, **and 🟡 Medium**
+  findings into remediation. 🟢 Suggestions stay on the comment (never
+  auto-fixed).
+- **`high`** — route only 🔴 Critical and 🟠 High findings, reproducing
+  the pre-4399 behavior exactly. 🟡 Medium and 🟢 Suggestion findings stay
+  on the comment.
+
+Hard cutover per
+[`rules/git-conventions.md`](../../rules/git-conventions.md) § Contract
+Cutovers — no back-compat flag; `high` is opt-in to the old routing.
+
+### 🔴 / 🟠 findings — per-finding ceremony (unchanged)
+
+For each 🔴 / 🟠 finding from Step 4, decide between two paths and keep the
+`code-review` structured comment authoritative for anything not fixed
+in-place.
 
 1. **Apply a focused fix on `[HEAD_REF]`.** Permitted only when the
    finding is unambiguously *fixable* (clean remediation, no scope
@@ -328,11 +379,36 @@ anything not fixed in-place.
      attempt (the equivalent of the prior loop's
      `validation-regression` / `thrash-detected` exits).
 
+### 🟡 Medium findings — batched per-lens ceremony (only when `autoFixSeverity: medium`)
+
+When the threshold is `medium`, remediate the fixable 🟡 Medium findings in
+a **batch keyed by owning review lens/pillar** rather than the per-finding
+ceremony above:
+
+1. Group the fixable Mediums by owning lens (the pillar or audit family
+   that produced them). A Medium is fixable on the same terms as a 🟠; a
+   Medium in any escalation class stays on the comment exactly like a 🟠.
+2. For each lens, call `assert-branch.js --expected [HEAD_REF]`, stage
+   explicit paths only, and make **one focused conventional commit per
+   lens** (`fix(<scope>): <description> (review findings batch)`).
+3. Bounded-attempt semantics extend to the batch: each finding gets **at
+   most one** attempt, and a lens's batch commit that would exceed
+   `delivery.codeReview.maxFixScopeFiles` routes that lens's findings to
+   escalation (`scope-exceeded`) instead of committing.
+4. After **all** lens batches are committed, run a **single** validation
+   pass (`npm run lint` plus the relevant `npm test` slice) and a
+   **single** targeted rescan over the touched files. Surviving batched
+   findings stay on the comment for Step 5.
+
+Record every remediated finding (🟠 or 🟡) in the **"Fixed on-branch"**
+section of the `code-review` comment (Step 4) so it does not graduate to a
+follow-up issue.
+
 Do not invent a programmatic retry budget. The host LLM applies *at most
-one* focused-fix attempt per finding before escalating to the operator.
-Escalated findings remain on the `code-review` structured comment with
-their reason recorded, so Step 5 (and downstream consumers) see exactly
-why each one was not auto-remediated.
+one* focused-fix attempt per finding (or per batched finding) before
+escalating to the operator. Escalated findings remain on the `code-review`
+structured comment with their reason recorded, so Step 5 (and downstream
+consumers) see exactly why each one was not auto-remediated.
 
 ## Step 4.6 — Cross-phase re-check trigger
 

package/.agents/workflows/helpers/deliver-epic.md

@@ -89,9 +89,17 @@ Every other runtime modifier is sourced from the Epic's labels or from
 - **Single pause point.** Only `agent::blocked` halts execution. No
   clarifying questions — if stuck, flip to `agent::blocked`, post a
   friction comment, park.
-- **Two-level dispatch.** Host LLM fans out per-Story Agent calls
-  directly with `subagent_type: general-purpose`. Sub-agents do not
-  carry the `Agent` tool, so this stays flat.
+- **Flat Story dispatch by design.** Host LLM fans out per-Story Agent
+  calls directly with `subagent_type: general-purpose`. Keeping Story
+  dispatch flat — the host owns the single fan-out level — is a
+  **design choice**, not a harness constraint: the wave aggregator, idle
+  watchdog, and merge-lock all assume one host-owned dispatch level. As of
+  Claude Code 2.1.202 a level-1 sub-agent **does** carry the `Agent` tool
+  and can nest further (verified depth 2, announced max depth 5; see
+  [#2870](https://github.com/dsj1984/mandrel/issues/2870)), so a Story
+  worker may itself fan out for its own sub-work within that depth budget —
+  the Epic wave loop nonetheless stays flat by choice, not because nesting
+  is unavailable.
 - **Operator-merges-PR exit.** Phase 7 opens the PR; the workflow
   never merges to `main` itself. Phase 8.5 may fire auto-merge when
   every signal is clean.
@@ -481,8 +489,29 @@ therefore auto-runs its mapped lenses (e.g. a `security`-axis Epic runs
 low-risk Epic adds nothing. Findings are persisted as an `audit-results`
 structured comment on the Epic.
 
-- **Any 🔴 Critical Blocker** — STOP. Relay to the operator.
-- **Only 🟠/🟡/🟢** — log as non-blocking and continue.
+The helper's Step 3 remediation is **threshold-aware** (Story #4399): it
+reads `delivery.epicAudit.autoFixSeverity` (default **`medium`**) and, at
+`medium`, routes 🔴/🟠/**🟡** findings into on-branch remediation (Mediums
+batched per lens — one commit per lens, a single validation + overlapping-
+lens rescan at the end) while 🟢 Suggestions still graduate; `high`
+reproduces the pre-4399 Critical/High-only routing. Remediated findings are
+rendered under the comment's `## Fixed on-branch` section so they never
+graduate to follow-up issues. The severity gate below is **unchanged** —
+it keys off the surviving (unfixed) findings.
+
+The helper walks the selected roster **serially in-context by default**; when
+the roster carries more than one lens it **may delegate the walk to a single
+audit-orchestrator sub-agent** that fans the already-selected lenses out as
+parallel level-2 agents and returns only the aggregated `audit-results` (see
+[`epic-audit.md` § "Optional: delegate the roster walk to an audit-orchestrator
+sub-agent"](epic-audit.md), within the sub-agent depth budget noted under
+"Flat Story dispatch by design" above). The roster stays fixed upstream, every
+per-lens cost gate is preserved, and the seven sequential-only lenses are **not**
+batch-converted — the fan-out parallelizes across lenses only and never changes
+how any single lens runs internally.
+
+- **Any surviving 🔴 Critical Blocker** — STOP. Relay to the operator.
+- **Only 🟠/🟡/🟢 surviving** — log as non-blocking and continue.
 - **Selector reports `degraded: true`** — STOP. Propagate the
   `reason`/`detail`, post a friction comment, do not fall back to a
   full-roster audit.
@@ -514,8 +543,18 @@ emit so a high-risk Epic gets a deeper adversarial pass and a low-risk one a
 lighter one. Depth is **input-only** — it never changes the findings envelope
 or the posted comment shape.
 
-- **Any 🔴 Critical Blocker** — STOP. Relay to the operator.
-- **Only 🟠/🟡/🟢** — log as non-blocking and continue.
+The helper's Step 4.5 focused-fix routing is **threshold-aware**
+(Story #4399): it reads `delivery.codeReview.autoFixSeverity` (default
+**`medium`**) and, at `medium`, routes 🔴/🟠/**🟡** findings into on-branch
+remediation (Mediums batched per lens — one commit per lens, a single
+validation + rescan at the end) while 🟢 Suggestions stay on the comment;
+`high` reproduces the pre-4399 Critical/High-only routing. Remediated
+findings are rendered under the comment's `## Fixed on-branch` section so
+they never graduate to follow-up issues. The severity gate below is
+**unchanged** — it keys off the surviving (unfixed) findings.
+
+- **Any surviving 🔴 Critical Blocker** — STOP. Relay to the operator.
+- **Only 🟠/🟡/🟢 surviving** — log as non-blocking and continue.
 
 ---