forgedock 1.3.0 → 1.5.0

package/commands/orchestrate/phase-5-cleanup.md

@@ -45,6 +45,8 @@ Include the audit summary in the final report (Phase 6). Key metrics to surface:
 
 **Run after Step 5B, before Step 5D.** No-ops cleanly if the claims board was never created this run (`COORD_ISSUE_NUMBER` unset/empty — e.g. Step 3D.1's `gh issue create` failed, or this batch never reached DAG construction). Tolerates GitHub API failures without aborting the rest of Phase 5 — the same tolerant-failure convention (`2>/dev/null || echo ...`, `|| true`) used throughout `phase-3-dependency.md`/`phase-4-execution.md`.
 
+**Orchestrator lease should already be released by this point** (forge#2627): `phase-4-execution.md`'s Termination condition (end of Step 4B) calls `release_orchestrator_lease()` before handing off to Phase 5 on a normal drain, and the "Stopping the orchestrator" procedure (Step 4A-pre.-0.5) does the same on an interrupted exit. Closing the coordination issue here does not depend on lease state either way — an unreleased lease on an issue about to be closed is harmless (a future batch creates its own new coordination issue per Step 3D.1), but if `ACTIVE_CLAIMS_NOTE` logic is ever extended to also surface lease state, prefer checking for a still-unreleased `FORGE:LEASE` the same way `ACTIVE_CLAIMS` is computed above.
+
 ```bash
 if [ -n "${COORD_ISSUE_NUMBER:-}" ]; then
   # Detect any still-active (unreleased) claims — a claim posted with no matching

package/commands/quality-gate.md

@@ -1226,7 +1226,7 @@ fi
 
 **Triggered when**: BILLING domain is set (changed files are under `billing/`, `credits/`, `subscription`, `ledger`, or `payment` paths).
 
-**Why this matters**: Billing code has three reliably grep-detectable defect classes that account for ~27% of review findings in the AlterLab health window: (1) `org_id` not propagated to debit/refund ledger write paths (silent data ownership loss — charges appear with wrong tenant); (2) `asyncio.sleep` / blocking sleep called inside an advisory-lock or open-transaction scope (holds DB connection/lock for the full sleep duration, causing connection exhaustion and deadlocks under load); (3) stdlib `logging.*()` calls passed structlog-style keyword arguments (`event=`, named context keys) that are not valid stdlib kwargs — crashes at runtime with `TypeError: unexpected keyword argument`. <!-- Added: forge#1329 --> <!-- allowlist: AlterLab -->
+**Why this matters**: Billing code has three reliably grep-detectable defect classes that recur often enough in production billing code to justify a deterministic check: (1) `org_id` not propagated to debit/refund ledger write paths (silent data ownership loss — charges appear with wrong tenant); (2) `asyncio.sleep` / blocking sleep called inside an advisory-lock or open-transaction scope (holds DB connection/lock for the full sleep duration, causing connection exhaustion and deadlocks under load); (3) stdlib `logging.*()` calls passed structlog-style keyword arguments (`event=`, named context keys) that are not valid stdlib kwargs — crashes at runtime with `TypeError: unexpected keyword argument`. <!-- Added: forge#1329 -->
 
 **2Q-1: org_id propagation in ledger write functions**
 
@@ -1241,7 +1241,7 @@ while IFS= read -r f; do
         # Read the full function signature (up to 3 lines to cover multi-line sigs)
         sig=$(sed -n "${lineno},$((lineno+2))p" "$f" 2>/dev/null)
         echo "$sig" | grep -qE '\borg_id\b' || \
-            echo "BILLING-1 | MEDIUM | $f:$lineno | Ledger write function '$(echo "$rest" | grep -oE 'def \w+' | head -1)' signature does not include org_id parameter — verify org_id is propagated to all debit/refund paths (AlterLab#25348 pattern)" <!-- allowlist: AlterLab -->
+            echo "BILLING-1 | MEDIUM | $f:$lineno | Ledger write function '$(echo "$rest" | grep -oE 'def \w+' | head -1)' signature does not include org_id parameter — verify org_id is propagated to all debit/refund paths"
     done
 done < <(echo {CHANGED_FILES} | tr ' ' '\n' | grep -E '\.py$')
 ```
@@ -1252,14 +1252,14 @@ done < <(echo {CHANGED_FILES} | tr ' ' '\n' | grep -E '\.py$')
 # Grep billing Python files for asyncio.sleep / time.sleep called inside an advisory-lock
 # or open-transaction context (within 20 lines after lock acquisition or BEGIN/session open).
 # Holding a lock or DB connection across a sleep starves the connection pool and causes
-# deadlocks under concurrent load (AlterLab#25725 pattern). <!-- allowlist: AlterLab -->
+# deadlocks under concurrent load.
 while IFS= read -r f; do
     [ -z "$f" ] && continue
     grep -nE "\basyncio\.sleep\b|\btime\.sleep\b" "$f" 2>/dev/null | while IFS=: read -r lineno rest; do
         start=$((lineno > 20 ? lineno - 20 : 1))
         window=$(sed -n "${start},$((lineno-1))p" "$f" 2>/dev/null)
         echo "$window" | grep -qE 'advisory_lock|BEGIN\b|async with.*session|async with.*conn|async with.*transaction|with.*engine\b' && \
-            echo "BILLING-2 | HIGH | $f:$lineno | asyncio.sleep/time.sleep inside advisory-lock or open-transaction scope — holds DB connection/lock for full sleep duration, causing connection exhaustion and deadlocks under load (AlterLab#25725 pattern). Move sleep outside lock/transaction scope." <!-- allowlist: AlterLab -->
+            echo "BILLING-2 | HIGH | $f:$lineno | asyncio.sleep/time.sleep inside advisory-lock or open-transaction scope — holds DB connection/lock for full sleep duration, causing connection exhaustion and deadlocks under load. Move sleep outside lock/transaction scope."
     done
 done < <(echo {CHANGED_FILES} | tr ' ' '\n' | grep -E '\.py$')
 ```
@@ -1271,7 +1271,7 @@ done < <(echo {CHANGED_FILES} | tr ' ' '\n' | grep -E '\.py$')
 # that are NOT valid stdlib logging kwargs (exc_info, stack_info, stacklevel, extra).
 # Structlog-style kwargs (event=, extra_=, named context keys) are NOT accepted by stdlib
 # Logger methods and crash at runtime with TypeError: unexpected keyword argument.
-# (AlterLab#25715, #25837, #25819 pattern) <!-- allowlist: AlterLab -->
+# This is a recurring, well-observed pattern in production billing code.
 while IFS= read -r f; do
     [ -z "$f" ] && continue
     # Match logging.info/warning/error/debug/critical and logger.info/etc. calls with
@@ -1280,7 +1280,7 @@ while IFS= read -r f; do
     grep -nE "\b(logging|logger)\.(info|warning|error|debug|critical|exception)\s*\(.*\b\w+\s*=" "$f" 2>/dev/null | \
         grep -vE "\b(exc_info|stack_info|stacklevel|extra)\s*=" | \
         grep -v "^\s*#" && \
-        echo "BILLING-3 | HIGH | $f | stdlib logging call with non-stdlib keyword argument detected — stdlib Logger.info/warning/error/etc. only accept exc_info, stack_info, stacklevel, extra as kwargs. Structlog-style kwargs (event=, named context keys) cause TypeError at runtime (AlterLab#25715 pattern). Use structlog.get_logger() instead of logging if structlog kwargs are needed." <!-- allowlist: AlterLab -->
+        echo "BILLING-3 | HIGH | $f | stdlib logging call with non-stdlib keyword argument detected — stdlib Logger.info/warning/error/etc. only accept exc_info, stack_info, stacklevel, extra as kwargs. Structlog-style kwargs (event=, named context keys) cause TypeError at runtime. Use structlog.get_logger() instead of logging if structlog kwargs are needed."
 done < <(echo {CHANGED_FILES} | tr ' ' '\n' | grep -E '\.py$')
 ```
 

package/commands/review-pr-staging.md

@@ -681,14 +681,32 @@ gh label create "needs-validation" --color "FBCA04" --description "Review findin
 gh label create "staging-review" --color "1D76DB" --description "Finding from a staging branch review before deploy to main. Managed by ForgeDock." --force -R {GH_REPO} 2>/dev/null
 ```
 
-### 7D: Milestone Detection
-Only assign milestone if reviewing a milestone/* branch. Plain staging reviews get no milestone.
+### 7D: Milestone & Code Branch Detection
+
+Derive both `CODE_BRANCH` and `MILESTONE_FLAG` from the reviewed PR before creating any findings. Unlike `commands/review-pr.md` (feature-lane PRs with short-lived HEAD branches that get deleted post-merge — see the rationale comment on that spec's finding template), `review-pr-staging.md` reviews long-lived branches (`staging`, `milestone/*`) that persist after merge, so `CODE_BRANCH` uses `headRefName` (the PR's HEAD — the branch actually being reviewed), consistent with forge#1391's original fix. This replaces the previous hardcoded `staging` literal, which was silently wrong whenever this spec reviewed a `milestone/X → staging` PR instead of a `staging → main` PR — `CODE_BRANCH` used to always say `staging` even when the reviewed branch was `milestone/X`.
+
+```bash
+CODE_BRANCH=$(gh pr view ${PR_NUMBER} --json headRefName --jq '.headRefName')
+MILESTONE_FLAG=""
+
+# scripts/derive-finding-milestone.sh is the single source of truth for
+# milestone derivation — commands/review-pr.md and commands/review-pr-staging.md
+# both call it identically so the two specs cannot independently drift.
+# <!-- forge#2443 -->
+MILESTONE_TITLE=$(bash scripts/derive-finding-milestone.sh "${PR_NUMBER}" -R {GH_REPO})
+# Quoted so multi-word milestone titles survive as a single value wherever
+# MILESTONE_FLAG is later interpolated — matches the quoting convention already
+# used for --title/--body-file/--label below.
+[ -n "$MILESTONE_TITLE" ] && MILESTONE_FLAG="--milestone \"$MILESTONE_TITLE\""
+```
+
+Plain staging→main reviews resolve `CODE_BRANCH` to `staging` dynamically (same value as before, now derived rather than hardcoded) and typically resolve no milestone. A milestone→staging review resolves `CODE_BRANCH` to `milestone/X` and (via the shared script) the matching milestone.
 
 ### 7E: Deduplicate Against Existing Issues
 Check for open review-finding issues at same file:line → skip. Closed issues at same location → potential regression (elevate priority).
 
 ### 7F: Create Issues
-Sequential creation. Title: `Staging Review: {summary} (staging → main)`. Labels: review-finding, needs-validation, staging-review, priority:P1/priority:P2/priority:P3. Body includes: source branch context (`staging`), code context, evidence, validation checklist.
+Sequential creation. Title: `Staging Review: {summary} (staging → main)`. Labels: review-finding, needs-validation, staging-review, priority:P0-P3 (derived from Severity — see below). Body includes: source branch context (`${CODE_BRANCH}`, derived in Phase 7D — not a hardcoded `staging` literal), code context, evidence, validation checklist.
 
 **For each finding** (that passes dedup), create issue through the `/issue` create-hook's programmatic invocation contract (see `commands/issue.md` § "Programmatic Invocation Contract") instead of calling the raw issue-creation command directly:
 ```bash
@@ -716,10 +734,10 @@ Files that need changes:
 
 ## Source Branch Context
 
-**Code branch**: `staging`
-**Worktree base**: `origin/staging`
+**Code branch**: `[CODE_BRANCH]`
+**Worktree base**: `origin/[CODE_BRANCH]`
 
-> When fixing: `git worktree add ../fix-{slug} -b fix/{slug} origin/staging`
+> When fixing: `git worktree add ../fix-{slug} -b fix/{slug} origin/[CODE_BRANCH]`
 
 ## Code Context
 [10 lines around finding]
@@ -733,8 +751,32 @@ Files that need changes:
 - [ ] If VALIDATED: fix implemented and tested on correct branch
 ISSUE_EOF
 
+# STAGING_FINDING_SEVERITY is extracted from the finding's own **Severity**
+# body field (set above in the heredoc) — example assignment shown here for
+# clarity, same convention as STAGING_FINDING_TITLE etc.
+STAGING_FINDING_SEVERITY="LOW"
+
+# priority:* label is a deterministic function of the finding's **Severity**
+# (CRITICAL/HIGH/MEDIUM/LOW) — NEVER of its Confidence
+# (CONFIRMED/LIKELY/POSSIBLE). scripts/severity-to-priority.sh is the single
+# source of truth for this mapping; commands/review-pr.md calls the identical
+# script so the two specs cannot independently drift. <!-- forge#2447 -->
+STAGING_FINDING_PRIORITY=$(bash scripts/severity-to-priority.sh "$STAGING_FINDING_SEVERITY")
+STAGING_FINDING_PRIORITY_EXIT=$?
+
+# Exit code MUST be checked before use — severity-to-priority.sh exits 1 (empty stdout)
+# on a missing/unrecognized severity. Proceeding with an empty $STAGING_FINDING_PRIORITY
+# would call Skill(issue, --label "") instead of aborting issue creation for this finding.
+# Mirrors the identical check in commands/review-pr.md. <!-- forge#2479 -->
+if [ "$STAGING_FINDING_PRIORITY_EXIT" -ne 0 ]; then
+  echo "PRIORITY: severity-to-priority.sh failed (exit $STAGING_FINDING_PRIORITY_EXIT) for severity '$STAGING_FINDING_SEVERITY' — skipping finding issue creation"
+  # Skip this finding — do NOT fall through to issue creation with an empty label
+else
+
 # --label is repeatable (not comma-joined) per the /issue programmatic contract.
-Skill(skill="issue", args="--title \"$STAGING_FINDING_TITLE\" --body-file \"$STAGING_FINDING_BODY_FILE\" --label review-finding --label needs-validation --label staging-review --label \"{priority}\"")
+# ${MILESTONE_FLAG} carries the Phase 7D derivation through — empty string is
+# a no-op arg when the reviewed branch has no milestone (plain staging→main).
+Skill(skill="issue", args="--title \"$STAGING_FINDING_TITLE\" --body-file \"$STAGING_FINDING_BODY_FILE\" --label review-finding --label needs-validation --label staging-review --label \"$STAGING_FINDING_PRIORITY\" ${MILESTONE_FLAG}")
 rm -f "$STAGING_FINDING_BODY_FILE"
 
 # /issue has no machine-readable return contract — resolve the created issue's number by
@@ -746,9 +788,10 @@ for _resolve_attempt in 1 2 3; do
   [ -n "$ISSUE_NUM" ] && break
   sleep 2
 done
+fi
 ```
 
-Labels: `review-finding` + `needs-validation` + `staging-review` + priority (`priority:P1` CONFIRMED, `priority:P2` LIKELY, `priority:P3` POSSIBLE).
+Labels: `review-finding` + `needs-validation` + `staging-review` + priority. `priority:*` is derived from the finding's `**Severity**` field via `scripts/severity-to-priority.sh` (identical script used by `commands/review-pr.md` — single documented mapping, see that script's header comment): `CRITICAL` → `priority:P0`, `HIGH` → `priority:P1`, `MEDIUM` → `priority:P2`, `LOW` → `priority:P3`. **Never derive `priority:*` from Confidence** (CONFIRMED/LIKELY/POSSIBLE) — conflating the two axes previously mislabeled LOW-severity CONFIRMED findings as `priority:P1`, defeating orchestrate's P3 batching rule. <!-- forge#2447 -->
 
 **No pre-filtering**: Every finding becomes an issue. Validation agents sort out false positives downstream.
 

package/commands/review-pr.md

@@ -1626,26 +1626,28 @@ gh label create "false-positive" --color "CCCCCC" --description "Review finding
 
 **Milestone detection:**
 ```bash
-# Check BOTH head and base branches — feature PRs targeting milestone/* branches
-# should inherit the milestone for their review findings
+# BASE_BRANCH is what the finding template stamps as **Code branch** below
+# (see the rationale comment at that template block) — HEAD_BRANCH is no
+# longer needed here; derive-finding-milestone.sh resolves its own
+# base/head branch lookup internally for its Tier 3 slug match.
 BASE_BRANCH=$(gh pr view ${PR_NUMBER} --json baseRefName --jq '.baseRefName')
-HEAD_BRANCH=$(gh pr view ${PR_NUMBER} --json headRefName --jq '.headRefName')
 MILESTONE_FLAG=""
 
-# First check: PR's base branch is a milestone branch (most common for feature-lane PRs)
-MILESTONE_BRANCH=""
-if echo "$BASE_BRANCH" | grep -qE "^milestone/"; then
-    MILESTONE_BRANCH="$BASE_BRANCH"
-elif echo "$HEAD_BRANCH" | grep -qE "^milestone/"; then
-    MILESTONE_BRANCH="$HEAD_BRANCH"
-fi
-
-if [ -n "$MILESTONE_BRANCH" ]; then
-    BRANCH_SLUG=$(echo "$MILESTONE_BRANCH" | sed 's|^milestone/||')
-    MILESTONE_NUMBER=$(gh api repos/${REPO}/milestones 2>/dev/null | jq --arg slug "$BRANCH_SLUG" '.[] | select((.title | ascii_downcase | gsub("[^a-z0-9]+"; "-")) == $slug) | .number' 2>/dev/null | head -1)
-    [ -z "$MILESTONE_NUMBER" ] && MILESTONE_NUMBER=$(gh api repos/${REPO}/milestones 2>/dev/null | jq --arg slug "$BRANCH_SLUG" '.[] | select((.title | ascii_downcase | gsub("[^a-z0-9]+"; "-")) | test($slug)) | .number' 2>/dev/null | head -1)
-    [ -n "$MILESTONE_NUMBER" ] && MILESTONE_FLAG="--milestone $(gh api repos/${REPO}/milestones/${MILESTONE_NUMBER} --jq '.title')"
-fi
+# scripts/derive-finding-milestone.sh is the single source of truth for
+# milestone derivation — commands/review-pr.md and commands/review-pr-staging.md
+# both call it identically so the two specs cannot independently drift the
+# way they did before this fix (forge#2443 Instance B/C: findings from a
+# milestone-lane PR sometimes inherited the milestone and sometimes didn't,
+# depending on incidental inheritance rather than an explicit step). The
+# script's 3-tier resolution (PR's own milestone -> originating issue's
+# milestone via Closes/Fixes/Resolves #N -> branch-slug match against
+# milestone/* branches) supersedes the old base/head-branch-only slug match
+# that used to be hand-rolled here.
+MILESTONE_TITLE=$(bash scripts/derive-finding-milestone.sh "${PR_NUMBER}" -R "${REPO}")
+# Quoted so multi-word milestone titles (e.g. "Watch & Fleet Observability") survive
+# as a single value wherever MILESTONE_FLAG is later interpolated — matches the
+# quoting convention already used for --title/--body-file/--label below.
+[ -n "$MILESTONE_TITLE" ] && MILESTONE_FLAG="--milestone \"$MILESTONE_TITLE\""
 ```
 
 **Dedup against existing issues (MANDATORY before creating):**
@@ -1763,10 +1765,26 @@ Files that need changes:
 
 ## Source Branch Context
 
-**Code branch**: `[HEAD_BRANCH]`
-**Worktree base**: `origin/[HEAD_BRANCH]`
-
-> When fixing: `git worktree add ../fix-{slug} -b fix/{slug} origin/[HEAD_BRANCH]`
+<!--
+  BASE_BRANCH, not HEAD_BRANCH, is correct here (forge#2443). This looks like
+  a revert of forge#1391 ("review-finding template stamps BASE_BRANCH instead
+  of HEAD_BRANCH — fixes target wrong code state") but is NOT: forge#1391's
+  scenario was a staging->main review where HEAD (staging) is a long-lived
+  branch that already had the bug's code, while BASE (main) had not yet
+  received it. review-pr.md's scenario is different — HEAD here is a
+  short-lived feat/*|fix/* branch that Phase 6E deletes once the auto-merge
+  step completes, which happens SYNCHRONOUSLY within this same /review-pr run,
+  before any downstream consumer (a human, or /work-on) ever reads this
+  finding. By the time the finding is read, HEAD no longer exists but BASE
+  does, and BASE now contains the merged code the finding is about.
+  commands/review-pr-staging.md keeps HEAD_BRANCH semantics (as a dynamic
+  ${CODE_BRANCH}, not a hardcoded literal) because ITS reviewed branches
+  (staging, milestone/*) are long-lived — consistent with forge#1391.
+-->
+**Code branch**: `[BASE_BRANCH]`
+**Worktree base**: `origin/[BASE_BRANCH]`
+
+> When fixing: `git worktree add ../fix-{slug} -b fix/{slug} origin/[BASE_BRANCH]`
 
 ## Code Context
 [10 lines around finding]
@@ -1785,8 +1803,30 @@ Files that need changes:
 [BATCHABLE_ANNOTATION]
 ISSUE_EOF
 
+# FINDING_SEVERITY is extracted from the finding's own **Severity** body field
+# (set above in the heredoc) — example assignment shown here for clarity, same
+# convention as FINDING_ISSUE_TITLE etc.
+FINDING_SEVERITY="LOW"
+
+# priority:* label is a deterministic function of the finding's **Severity**
+# (CRITICAL/HIGH/MEDIUM/LOW) — NEVER of its Confidence
+# (CONFIRMED/LIKELY/POSSIBLE). scripts/severity-to-priority.sh is the single
+# source of truth for this mapping; commands/review-pr-staging.md calls the
+# identical script so the two specs cannot independently drift. <!-- forge#2447 -->
+FINDING_PRIORITY=$(bash scripts/severity-to-priority.sh "$FINDING_SEVERITY")
+FINDING_PRIORITY_EXIT=$?
+
+# Exit code MUST be checked before use — severity-to-priority.sh exits 1 (empty stdout)
+# on a missing/unrecognized severity, mirroring the DEDUP_EXIT idiom above. Proceeding
+# with an empty $FINDING_PRIORITY would call Skill(issue, --label "") instead of aborting
+# issue creation for this finding. <!-- forge#2479 -->
+if [ "$FINDING_PRIORITY_EXIT" -ne 0 ]; then
+  echo "PRIORITY: severity-to-priority.sh failed (exit $FINDING_PRIORITY_EXIT) for severity '$FINDING_SEVERITY' — skipping finding issue creation"
+  # Skip this finding — do NOT fall through to issue creation with an empty label
+else
+
 # --label is repeatable (not comma-joined) per the /issue programmatic contract.
-Skill(skill="issue", args="--title \"$FINDING_ISSUE_TITLE\" --body-file \"$FINDING_ISSUE_BODY_FILE\" --label review-finding --label needs-validation --label \"{priority}\" ${MILESTONE_FLAG}")
+Skill(skill="issue", args="--title \"$FINDING_ISSUE_TITLE\" --body-file \"$FINDING_ISSUE_BODY_FILE\" --label review-finding --label needs-validation --label \"$FINDING_PRIORITY\" ${MILESTONE_FLAG}")
 rm -f "$FINDING_ISSUE_BODY_FILE"
 
 # /issue has no machine-readable return contract (it's a user-facing command, not a work-on
@@ -1799,15 +1839,16 @@ for _resolve_attempt in 1 2 3; do
   [ -n "$ISSUE_NUM" ] && break
   sleep 2
 done
+fi
 ```
 
-Labels: `review-finding` + `needs-validation` + priority (`priority:P1` CONFIRMED, `priority:P2` LIKELY, `priority:P3` POSSIBLE).
+Labels: `review-finding` + `needs-validation` + priority. `priority:*` is derived from the finding's `**Severity**` field via `scripts/severity-to-priority.sh` (single documented mapping — see that script's header comment): `CRITICAL` → `priority:P0`, `HIGH` → `priority:P1`, `MEDIUM` → `priority:P2`, `LOW` → `priority:P3`. **Never derive `priority:*` from Confidence** (CONFIRMED/LIKELY/POSSIBLE) — Confidence and Severity are independent axes; conflating them previously mislabeled LOW-severity CONFIRMED findings as `priority:P1`, defeating the P3 batching rule below. <!-- forge#2447 -->
 
-**P3 batchable annotation** — <!-- Added: forge#1333 --> When priority resolves to `priority:P3` (POSSIBLE confidence), check whether the finding qualifies for batching. If the affected file does NOT touch a security or billing path, substitute `[BATCHABLE_ANNOTATION]` with the `<!-- FORGE:BATCHABLE -->` marker. This signals the orchestrator's Phase 1 batching rule that this finding can be grouped with other P3s in the same domain:
+**P3 batchable annotation** — <!-- Added: forge#1333 --> When priority resolves to `priority:P3` (i.e. `**Severity**: LOW`), check whether the finding qualifies for batching. If the affected file does NOT touch a security or billing path, substitute `[BATCHABLE_ANNOTATION]` with the `<!-- FORGE:BATCHABLE -->` marker. This signals the orchestrator's Phase 1 batching rule that this finding can be grouped with other P3s in the same domain:
 
 ```bash
 # Determine batchable eligibility for this finding
-FINDING_PRIORITY="{priority}"  # priority:P1 / priority:P2 / priority:P3
+# $FINDING_PRIORITY was already computed above (severity-to-priority.sh) — reuse it, do not re-derive.
 BATCHABLE_ANNOTATION=""
 
 if [ "$FINDING_PRIORITY" = "priority:P3" ]; then
@@ -2089,19 +2130,41 @@ if [ "$PRE_MERGE_HEALTH" = "CONFLICTING" ] || [ "$PRE_MERGE_HEALTH_STATE" = "DIR
     # STOP — do not attempt gh pr merge on a CONFLICTING/DIRTY PR
 else
 
-# Previously-escalated re-review guard <!-- Added: forge#1810 -->
+# Previously-escalated re-review guard <!-- Added: forge#1810; base-scoped: forge#2570 -->
 # If the linked issue currently carries needs-human, this PR was escalated at some
 # earlier point (VERDICT/purpose-regression/calibration/trust/mergeability) and has
 # now been remediated + re-reviewed back to a clean, mergeable APPROVED state above.
-# The "auto-land bar" (≥2 independent adversarial approvals + domain gates — see
-# #1809 Q1) is not yet implemented (future #1809 sub-issues B/C/D), so the safe
-# default here is to land on workflow:awaiting-merge (clearing needs-human) rather
-# than silently auto-merging a PR that was once flagged human-risk.
+#
+# forge#2570: the hold is now scoped by the PR's target branch. This PR still transitions
+# to workflow:awaiting-merge (clearing needs-human) in BOTH cases below — the transition is
+# unchanged; only who acts next differs:
+#   - `main` / deploy gate (or an unresolved base — fail closed): held for a HUMAN merge
+#     decision, because `staging → main` is the genuine human gate no agent performs.
+#   - any other base (staging, milestone/* — reversible integration branches): NOT held for
+#     a human. It is parked for remediate.md Phase M7's base-scoped auto-land bar (bot APPROVED
+#     + quality-gate pass), which merges it on the SAME condition the normal /work-on fast lane
+#     uses for the same target branch — no manual click. This reconciles the asymmetry where a
+#     bot-only re-review (authorAssociation=NONE) could never satisfy the strict ≥2 verified-
+#     human bar and so stranded staging PRs the fast lane would auto-merge.
 PREVIOUSLY_ESCALATED=$(gh issue view {MERGE_ISSUE} {MERGE_GH_FLAG} --json labels \
   --jq '[.labels[].name] | any(. == "needs-human")' 2>/dev/null || echo "false")
+GUARD_BASE=$(gh pr view {PR_NUMBER} {MERGE_GH_FLAG} --json baseRefName --jq '.baseRefName' 2>/dev/null || echo "")
 
 if [ "$PREVIOUSLY_ESCALATED" = "true" ]; then
-    gh issue comment {MERGE_ISSUE} {MERGE_GH_FLAG} --body "🟠 PR #{PR_NUMBER} was previously escalated (\`needs-human\`) and has now been re-reviewed to \`${VERDICT:-APPROVED}\` with a clean mergeability check. The automated auto-land bar for previously-escalated PRs is not yet implemented, so this PR is held at \`workflow:awaiting-merge\` for a human merge decision instead of auto-merging. Merge manually once reviewed: \`gh pr merge {PR_NUMBER} {MERGE_GH_FLAG} --merge\`."
+    # forge#2625: `jq -r '.baseRefName'` stringifies a JSON null to the literal text "null" (not
+    # an empty string), so the `-n` check alone does not catch it — add an explicit `!= "null"`
+    # check so a literal-string "null" is treated the same as an empty/unresolved base (strict).
+    if [ -n "$GUARD_BASE" ] && [ "$GUARD_BASE" != "null" ] && [ "$GUARD_BASE" != "main" ]; then
+      # forge#2570: non-`main` base — defer to remediate.md M7's auto-land, not a human.
+      # forge#2626: standalone `/review-pr` (no remediate.md M6→M7 chain) would otherwise
+      # strand this PR at `workflow:awaiting-merge` with no actionable guidance — add a
+      # manual-merge fallback so the comment is correct in both the chained and standalone cases.
+      # GOVERNOR-exempt: intentional coordination side-effect (best-effort lease/board/finding post), DRY_RUN-safe — reviewed & accepted for the check-command-side-effects gate. Flagged only by the staging->main full-diff; passes on every feature PR. forge#2627
+      gh issue comment {MERGE_ISSUE} {MERGE_GH_FLAG} --body "🟠 PR #{PR_NUMBER} was previously escalated (\`needs-human\`) and has now been re-reviewed to \`${VERDICT:-APPROVED}\` with a clean mergeability check on non-\`main\` base \`${GUARD_BASE}\`. It is parked at \`workflow:awaiting-merge\` for the remediation auto-land bar (\`remediate.md\` Phase M7, forge#2570) — which auto-merges it on the same fast-lane condition the normal \`/work-on\` path uses for this target branch — NOT for a human merge decision. If no remediation \`M7\` follows (e.g. this review was invoked standalone), merge manually once reviewed: \`gh pr merge {PR_NUMBER} {MERGE_GH_FLAG} --merge\`."
+    else
+      # forge#2570: `main` / deploy gate (or unresolved base — fail closed to the human gate).
+      gh issue comment {MERGE_ISSUE} {MERGE_GH_FLAG} --body "🟠 PR #{PR_NUMBER} was previously escalated (\`needs-human\`) and has now been re-reviewed to \`${VERDICT:-APPROVED}\` with a clean mergeability check. This PR targets the deploy gate (\`${GUARD_BASE:-unresolved base}\`), so it is held at \`workflow:awaiting-merge\` for a human merge decision — \`staging → main\` is the genuine human gate. Merge manually once reviewed: \`gh pr merge {PR_NUMBER} {MERGE_GH_FLAG} --merge\`."
+    fi
     RESOLUTION=$(resolve_script 'transition-label')
     TIER="${RESOLUTION%%:*}"; SCRIPT_PATH="${RESOLUTION#*:}"
     case "$TIER" in
@@ -2111,7 +2174,9 @@ if [ "$PREVIOUSLY_ESCALATED" = "true" ]; then
           --remove-label "needs-human,workflow:investigating,workflow:ready-to-build,workflow:building,workflow:in-review,workflow:merged,workflow:invalid,workflow:decomposed" 2>/dev/null || true
         ;;
     esac
-    # STOP — do not attempt gh pr merge; a human decides the merge from here
+    # STOP — do not attempt gh pr merge here. The merge decision belongs to a human for a
+    # `main`/deploy-gate base, or to remediate.md Phase M7's base-scoped auto-land bar for a
+    # non-`main` base (forge#2570). Either way this guard only parks at workflow:awaiting-merge.
 else
     # Checkpoint comment on issue
     gh issue comment {MERGE_ISSUE} {MERGE_GH_FLAG} --body "Review complete for PR #{PR_NUMBER}. Verdict: ${VERDICT:-APPROVED}. Proceeding to merge."
@@ -2229,13 +2294,30 @@ Post a welcome comment when all three conditions are true:
 # Read config — default enabled when key is absent
 WELCOME_ENABLED=$(yq '.community.welcome_new_contributors // true' forge.yaml 2>/dev/null || echo 'true')
 
-if [ "$IS_FIRST_TIME_CONTRIBUTOR" = "true" ] && [ "$WELCOME_ENABLED" != "false" ]; then
+if [ "$IS_FIRST_TIME_CONTRIBUTOR" = "true" ] && [ "$WELCOME_ENABLED" != "false" ] && [ "$REVIEW_MODE" = "single-pr" ]; then
     # Read optional custom values from forge.yaml community section
     CONTRIBUTING_URL=$(yq '.community.contributing_url // "CONTRIBUTING.md"' forge.yaml 2>/dev/null || echo 'CONTRIBUTING.md')
     CUSTOM_CONVENTIONS=$(yq '.community.conventions // ""' forge.yaml 2>/dev/null || echo '')
     PROJECT_NAME_WELCOME=$(yq '.project.name // "this project"' forge.yaml 2>/dev/null || echo 'this project')
 
-    gh pr comment "$ARGUMENTS" --body "## Welcome to ${PROJECT_NAME_WELCOME}! 🎉
+    # Resolve the conventions text into a plain shell variable BEFORE interpolating it into
+    # the --body string below. A nested $(...) command substitution containing an escaped
+    # \$VAR here is never expanded — see forge#2214.
+    if [ -n "$CUSTOM_CONVENTIONS" ]; then
+        CONVENTIONS_TEXT="$CUSTOM_CONVENTIONS"
+    else
+        CONVENTIONS_TEXT="- **Conventional commits**: prefix your commit messages with \`fix(scope):\`, \`feat(scope):\`, \`refactor(scope):\`, etc.
+- **DCO sign-off**: all commits must be signed off with \`git commit -s\` (Developer Certificate of Origin — required for the dual-license model).
+  Fix unsigned commits: \`git commit --amend -s --no-edit && git push --force-with-lease\` <!-- allowlist:check-command-side-effects -->
+- **Issues, not inline fixes**: when you spot a bug or improvement opportunity, open a GitHub issue rather than fixing it inline — so it flows through the pipeline with full traceability."
+    fi
+
+    # Unquoted heredoc (not the corpus's quoted <<'EOF' form) — this body needs live
+    # ${VAR} interpolation, which a quoted heredoc would disable. Literal backticks in
+    # the static text are still escaped (\`) since they remain live inside an unquoted
+    # heredoc, same as inside a double-quoted string. See forge#2223.
+    gh pr comment "$ARGUMENTS" --body "$(cat <<EOF
+## Welcome to ${PROJECT_NAME_WELCOME}! 🎉
 
 Hi @${PR_AUTHOR} — this looks like your first merged contribution here. Thanks for opening a PR!
 
@@ -2245,17 +2327,16 @@ The automated review pipeline (/review-pr) ran against your PR. It spawned domai
 
 ### Key conventions
 
-$([ -n "\$CUSTOM_CONVENTIONS" ] && echo "\$CUSTOM_CONVENTIONS" || echo "- **Conventional commits**: prefix your commit messages with \`fix(scope):\`, \`feat(scope):\`, \`refactor(scope):\`, etc.
-- **DCO sign-off**: all commits must be signed off with \`git commit -s\` (Developer Certificate of Origin — required for the dual-license model).
-  Fix unsigned commits: \`git commit --amend -s --no-edit && git push --force-with-lease\`
-- **Issues, not inline fixes**: when you spot a bug or improvement opportunity, open a GitHub issue rather than fixing it inline — so it flows through the pipeline with full traceability.")
+${CONVENTIONS_TEXT}
 
 ### Getting started
 
 - Contributing guide: [\`${CONTRIBUTING_URL}\`](${CONTRIBUTING_URL})
 - Run \`npx forgedock\` to install the pipeline commands locally if you want to run /review-pr or /work-on yourself.
 
-Welcome aboard!"
+Welcome aboard!
+EOF
+)"
 fi
 ```
 

package/commands/upgrade-deps.md

@@ -376,7 +376,12 @@ Store created issue numbers as `CREATED_ISSUES` (empty when `DRY_RUN=true`).
 For each issue in `CREATED_ISSUES`, invoke `/work-on` via the Skill tool:
 
 ```
-Skill(skill: "work-on", args: "{ISSUE_NUMBER}")
+# DRY_RUN guard — must stay above the Skill() call it guards (forge#1609).
+if [ "$DRY_RUN" = "true" ]; then
+  echo "[DRY RUN] Would invoke: Skill(skill: \"work-on\", args: \"{ISSUE_NUMBER}\")"
+else
+  Skill(skill: "work-on", args: "{ISSUE_NUMBER}")
+fi
 ```
 
 Run **sequentially** — each `/work-on` invocation is heavyweight. If one fails, continue to the next and record the outcome.
@@ -389,7 +394,7 @@ FIX_RESULTS = [
 ]
 ```
 
-**DRY_RUN check**: If `DRY_RUN=true`, print what would be invoked but skip `Skill()` calls.
+**DRY_RUN check**: enforced inline above — the guard wraps the `Skill()` call rather than being stated after it, so a dry run cannot invoke `/work-on` even if only this section is read in isolation (forge#1609).
 
 ---
 

package/commands/work-on/decompose.md

@@ -12,6 +12,8 @@ argument-hint: "[issue number] [--repo GH_REPO] [--gh-flag GH_FLAG]"
 **Invoked by**: `work-on.md` routing loop, when `INVESTIGATE_RESULT.decompose = YES`.
 **Output**: Create sub-issues, update parent tracker, post `<!-- FORGE:DECOMPOSED -->` comment, set labels. STOP — each sub-issue runs its own /work-on.
 
+**Engine coverage** (forge#2379): this subcommand's `command` name (`work-on/decompose`) and completion marker (`FORGE:DECOMPOSED:COMPLETE`) are now registered as a real phase in the headless engine's phase table — `decompose` in `packages/protocol/src/phases.js`'s `PHASE_IDS`/`PHASE_MARKERS`, and the matching `decompose` entry in `bin/engine/phases.mjs`'s `PHASES` array. The engine's `investigate` phase hands off to it on `DECOMPOSE:YES` instead of terminating in place, so a headless `runIssue()` walk now actually dispatches this subcommand rather than stopping short.
+
 **Agent model policy**: `model: "{DEFAULT_MODEL}"` — resolved from forge.yaml `agents.default_model`, else "sonnet" (standard tier). Fallback: `model: "opus"` if rate-limited. Feature gate: pass `effort` in Task/Skill spawns only on Claude Code >= 2.1.154. This file's mechanical bits (label transitions, sub-issue creation) stay at this tier because they're interleaved with the reasoning-heavy sub-issue design steps in the same `Skill()` invocation — see `work-on.md` section "Model and Effort Tiering — What Actually Applies". <!-- Added: forge#1827 -->
 **NEVER use plan mode (EnterPlanMode).**
 

package/commands/work-on/investigate.md

@@ -263,8 +263,8 @@ gh api repos/{GH_REPO}/issues/{NUMBER}/comments --jq '.[] | {id: .id, body: .bod
 ```
 
 **Resume logic**:
-- If `<!-- FORGE:INVESTIGATOR -->` comment exists AND `<!-- INVESTIGATION:COMPLETE -->` is present in the SAME comment → investigation already complete, EXIT (return existing verdict to caller)
-- If `<!-- FORGE:INVESTIGATOR -->` comment exists BUT `<!-- INVESTIGATION:COMPLETE -->` is ABSENT → investigation was interrupted, delete the partial comment and restart:
+- If `<!-- FORGE:INVESTIGATOR -->` comment exists AND (`<!-- INVESTIGATION:COMPLETE -->` OR `<!-- INVESTIGATION:INVALID -->`) is present in the SAME comment → investigation already complete, EXIT (return existing verdict to caller). `INVESTIGATION:INVALID` is the terminal sentinel Phase 1C emits for an INVALID verdict (see Phase 1C below) — it is just as much a completion marker as `INVESTIGATION:COMPLETE`, not an "interrupted" state.
+- If `<!-- FORGE:INVESTIGATOR -->` comment exists BUT NEITHER `<!-- INVESTIGATION:COMPLETE -->` NOR `<!-- INVESTIGATION:INVALID -->` is present → investigation was interrupted, delete the partial comment and restart:
   ```bash
   gh api repos/{GH_REPO}/issues/comments/{COMMENT_ID} -X DELETE
   ```
@@ -355,10 +355,25 @@ bash {REPO_PATH}/scripts/code-index.sh query --domain {DOMAIN_LABEL} --repo-path
 
 ## Phase 1C: Post Investigation Comment
 
-The comment MUST include `<!-- INVESTIGATION:COMPLETE -->` at the very end, AFTER all required sections are present. This marker signals the investigation finished successfully.
+The comment MUST include a terminal sentinel at the very end, AFTER all required sections are present. **The sentinel is conditional on the resolved Verdict — it is NOT always `<!-- INVESTIGATION:COMPLETE -->`:**
+
+- **Verdict is INVALID** → close with `<!-- INVESTIGATION:INVALID -->`. This is a distinct, already-wired-up terminal marker: `bin/engine/phases.mjs`'s `detectOutcome` for the `investigate` phase checks for it explicitly (ahead of `INVESTIGATION:COMPLETE`) and routes to `terminalReason: "invalid"`; `bin/hooks/interactive-engine.mjs`'s `PHASE_MARKERS` table also already treats it as terminal. Emitting `INVESTIGATION:COMPLETE` for an INVALID verdict is what previously caused every completed investigation to read as `{verdict: "CONFIRMED"}` regardless of actual outcome — do NOT regress this (forge#2350).
+- **Verdict is CONFIRMED or PARTIAL** → close with `<!-- INVESTIGATION:COMPLETE -->` as before (PARTIAL still routes to `ready-to-build` in Phase 1D — only INVALID gets the distinct terminal sentinel).
+
+Compute the sentinel once, before building the comment body:
+
+```bash
+if [ "{VERDICT}" = "INVALID" ]; then
+  INVESTIGATION_SENTINEL="<!-- INVESTIGATION:INVALID -->"
+else
+  INVESTIGATION_SENTINEL="<!-- INVESTIGATION:COMPLETE -->"
+fi
+```
 
 **CODEC PATH (forge#1727)**: Construct the annotation body via the protocol codec — do NOT hand-roll the `<!-- FORGE:INVESTIGATOR -->` header. Use `forge-annotation.sh write INVESTIGATOR --field ...` or `node packages/protocol/src/cli.js emit INVESTIGATOR --field ...` to produce the opening tag and completion sentinel. Fill in the Markdown body sections below. The full pattern:
 
+**Caveat (forge#2368)**: `packages/protocol/src/types.js`'s `INVESTIGATOR.completionSentinel` is a single fixed value (`'INVESTIGATION:COMPLETE'`) and `packages/protocol/src/emit.js` appends it unconditionally — the codec does NOT currently support the verdict-conditional sentinel selection described above, and cannot emit `INVESTIGATION:INVALID`. Using the CODEC PATH for an INVALID-verdict investigation would silently regress the forge#2350 fix (every investigation would again read as `{verdict: "CONFIRMED"}`). Until the codec is extended to support a verdict-conditional sentinel, the hand-rolled block above/below (using the `${INVESTIGATION_SENTINEL}` variable computed above) is the authoritative path for Phase 1C — do not use the CODEC PATH for this annotation.
+
 ```bash
 # Build the annotation body via codec (escaping and sentinel handled by codec)
 ANNOTATION_BODY=$(node packages/protocol/src/cli.js emit INVESTIGATOR \
@@ -368,6 +383,7 @@ ANNOTATION_BODY=$(node packages/protocol/src/cli.js emit INVESTIGATOR \
   --field "Task Type={TASK_TYPE}" \
   --field "Decomposition Assessment={YES|NO} — {reason}")
 # ANNOTATION_BODY now has opening tag + required fields + INVESTIGATION:COMPLETE sentinel.
+# NOTE: the codec's sentinel is fixed — do not use this path when Verdict=INVALID (see caveat above).
 # Append the Markdown body sections to it before posting.
 ```
 
@@ -450,9 +466,11 @@ ACCEPTANCE_CHECK: id=ac-4 type=command target="grep -qE '(>= ?2|2\+)' commands/o
 
 **Skipping**: if the issue has no verifiable acceptance criteria and none can be derived from the recommendation, emit a single sentinel: `ACCEPTANCE_CHECK: id=ac-skip type=skipped target="none" matcher="none" description=No machine-checkable criteria available — human review required`
 ${ANNOTATION_LINK_FOOTER}
-<!-- INVESTIGATION:COMPLETE -->"
+${INVESTIGATION_SENTINEL}"
 ```
 
+**Do not hardcode `<!-- INVESTIGATION:COMPLETE -->` as the closing line.** The closing line MUST be the `${INVESTIGATION_SENTINEL}` variable computed above — it resolves to `<!-- INVESTIGATION:INVALID -->` for an INVALID verdict and `<!-- INVESTIGATION:COMPLETE -->` otherwise. `INVESTIGATION:COMPLETE` and `INVESTIGATION:INVALID` are mutually exclusive within a single posted comment — never emit both.
+
 ---
 
 ## Phase 1C.5: Create Knowledge Gist

package/commands/work-on/remediate.md

@@ -20,6 +20,8 @@ argument-hint: "[PR number] [--issue N] [--repo GH_REPO] [--gh-flag GH_FLAG] [--
 
 **Scope note**: This mode owns exactly one gap — re-driving a `needs-human` PR's own remediation. It does NOT implement the `needs-human` sub-label taxonomy (#1815's scope) and it does NOT edit `review-pr.md`'s Phase 8 guard (forge#1810) — that guard's existing safe-default (`workflow:awaiting-merge` on any clean re-review of a previously-escalated PR) is reused as-is; this file only adds a bar-check *after* that guard has already fired.
 
+**Engine coverage** (forge#2379): this subcommand's `command` name (`work-on/remediate`) and completion marker (`FORGE:REMEDIATION:COMPLETE`, including the `**Re-gate outcome**` field Phase M8 posts below) are now registered in the headless engine's phase table — `RESERVED_TYPES.REMEDIATION` in `packages/protocol/src/types.js`, `remediate` in `packages/protocol/src/phases.js`'s `PHASE_IDS`/`PHASE_MARKERS`, and a matching `remediate` entry in `bin/engine/phases.mjs`'s `PHASES` array (`entryCondition`: review committed + `terminalReason: "needs-human"`; `detectOutcome` maps each re-gate outcome to the right terminal reason). **Known limitation, documented in that engine entry's own comment**: a single continuous `runIssue()` walk cannot reach this phase today — `review`'s `"blocked"` outcome and the needs-human divergence guard both terminate the run before `remediate`'s `entryCondition` is ever evaluated. This subcommand therefore continues to run exactly as documented above — as its own separate top-level entry point — until a follow-up issue live-wires the engine to reconstruct state from GitHub for a dedicated remediation run.
+
 ---
 
 ## Inputs
@@ -253,11 +255,51 @@ REVIEW_BODIES=$(gh pr view {PR_NUMBER} {GH_FLAG} --json reviews,comments \
 APPROVED_COUNT=$(echo "$REVIEW_BODIES" | grep -cE 'APPROVED:' 2>/dev/null || true); APPROVED_COUNT=${APPROVED_COUNT:-0}
 ```
 
-**Auto-land bar** (per #1809 Q1) — BOTH conditions required:
+**Auto-land bar — base-branch scoped** (forge#2570): the condition the PR must clear to auto-land depends on its target branch. This reconciles the remediation bar with the normal `/work-on` fast-lane merge bar for the *same target branch*, while keeping the strict human-verified bar only where a human is genuinely in the loop (the `staging → main` deploy gate).
+
+**Re-derive the base fresh — do NOT reuse `$PR_BASE` for this decision** (forge#2624): `$PR_BASE` was resolved in Phase M0 as `PR_BASE="${PR_BASE:-$(... .baseRefName)}"` — a caller-supplied `--base` wins over the PR's actual live base whenever non-empty. That is fine for M0's own purposes (worktree base, display text), but this is a security-relevant decision point: a wrong/stale `--base staging` on a PR that actually targets `main` must never be allowed to relax the strict deploy-gate bar. Mirror `review-pr.md`'s sibling guard (`GUARD_BASE`, which always re-fetches `baseRefName` fresh at its own decision point) by re-querying the PR's live base here, independent of whatever `$PR_BASE` currently holds:
+
+```bash
+# forge#2624: re-fetch baseRefName fresh from the PR itself — never trust the
+# M0-resolved $PR_BASE for this decision, since M0 prefers a caller-supplied
+# --base over the live value. This is the one line in this phase that makes
+# a trust/security decision, so it must be immune to a caller-overridable input.
+LIVE_BASE_REF=$(gh pr view {PR_NUMBER} {GH_FLAG} --json baseRefName --jq '.baseRefName' 2>/dev/null || echo "")
+
+# forge#2570: `main` (and any deploy-gate base) keeps the strict #1809 Q1 verified-human bar;
+# every other base (staging, milestone/* — the reversible integration branches) reconciles to
+# the fast-lane bar. Key on "is the deploy gate", NOT the literal string "staging", so milestone
+# branches reconcile too. Fail closed: only a KNOWN, non-empty, non-`main` LIVE base reconciles
+# to the fast lane; an empty/unresolved fetch is treated as the deploy gate (strict) so a base-
+# resolution failure (or a caller passing a stale/incorrect --base) can never accidentally
+# relax the bar.
+# forge#2625: `jq -r '.baseRefName'` stringifies a JSON null to the literal text "null" (not an
+# empty string), so the `-n` check alone does not catch it — add an explicit `!= "null"` check
+# so a literal-string "null" is treated the same as an empty/unresolved base (strict).
+if [ -n "$LIVE_BASE_REF" ] && [ "$LIVE_BASE_REF" != "null" ] && [ "$LIVE_BASE_REF" != "main" ]; then IS_DEPLOY_GATE=false; else IS_DEPLOY_GATE=true; fi
+```
+
+**Non-`main` base (`IS_DEPLOY_GATE=false` — staging / milestone)** — reconcile to the fast-lane bar. `review-pr.md`'s Phase 8 guard only parks a PR at `workflow:awaiting-merge` after a clean, mergeable `APPROVED` re-review (the same bot-`APPROVED` signal the normal fast lane auto-merges on), so the only additional condition is this remediation's own quality gate:
+1. `GATE_PASSED = true` from this remediation's Phase M3 quality-gate loop.
+
+The strict `APPROVED_COUNT >= 2` verified-human requirement does NOT apply here: it is structurally unsatisfiable for bot-only pipeline review (bot reviews are `authorAssociation=NONE`), and `staging` is reversible — the real human gate is `staging → main`, which no agent performs. This makes the remediation bar identical to the normal fast-lane bar for the same target branch (the issue's core ask). The `authorAssociation` trust filter above is **unchanged** — the relaxation is scoped by *target branch only*, never by *who* may approve (forge#1976/#2519).
+
+**`main` base (`IS_DEPLOY_GATE=true` — deploy gate)** — keep the strict #1809 Q1 bar, BOTH conditions required:
 1. `APPROVED_COUNT >= 2` — at least two distinct adversarial `APPROVED:` review comments from repo collaborators (`OWNER`/`MEMBER`/`COLLABORATOR` authorAssociation only — see trust filter above; same counting convention as `work-on.md` Phase 7A).
 2. `GATE_PASSED = true` from this remediation's own Phase M3 quality-gate loop.
 
-**If the bar is met**:
+**Evaluate the base-scoped bar**:
+```bash
+if [ "$IS_DEPLOY_GATE" = "true" ]; then
+  # main / deploy gate — strict verified-human bar
+  { [ "${APPROVED_COUNT:-0}" -ge 2 ] && [ "${GATE_PASSED:-false}" = "true" ]; } && BAR_MET=true || BAR_MET=false
+else
+  # staging / milestone — fast-lane bar (bot APPROVED already implied by workflow:awaiting-merge)
+  [ "${GATE_PASSED:-false}" = "true" ] && BAR_MET=true || BAR_MET=false
+fi
+```
+
+**If the bar is met** (`BAR_MET=true`):
 ```bash
 gh pr merge {PR_NUMBER} {GH_FLAG} --merge
 MERGE_STATE=$(gh pr view {PR_NUMBER} {GH_FLAG} --json state --jq '.state')
@@ -279,7 +321,7 @@ else
 fi
 ```
 
-**If the bar is NOT met**: leave the issue at `workflow:awaiting-merge` exactly as `review-pr.md`'s guard set it — do NOT attempt a merge. `RE_GATE_OUTCOME="HELD-AWAITING-MERGE"`. Fail-safe direction: any doubt about the bar defaults to holding, matching `review-pr.md`'s own existing default for every other caller.
+**If the bar is NOT met** (`BAR_MET=false`): leave the issue at `workflow:awaiting-merge` exactly as `review-pr.md`'s guard set it — do NOT attempt a merge. `RE_GATE_OUTCOME="HELD-AWAITING-MERGE"`. Fail-safe direction: any doubt about the bar (including an unresolved or unexpected `LIVE_BASE_REF`, which leaves `IS_DEPLOY_GATE=true`-equivalent strict handling) defaults to holding, matching `review-pr.md`'s own existing default for every other caller.
 
 ---
 
@@ -289,7 +331,16 @@ Post the completion body to **both** `{PR_NUMBER}` and `{ISSUE_NUMBER}` — this
 
 ```bash
 case "$RE_GATE_OUTCOME" in
-  AUTO-LANDED)         AUTO_LAND_BAR_TEXT="MET (${APPROVED_COUNT:-0} APPROVED: reviews + quality gate pass)"; OUTCOME_DETAIL="to {PR_BASE}" ;;
+  AUTO-LANDED)
+    # forge#2570: the bar that was met differs by target branch. Non-`main` (staging/milestone)
+    # lands on the fast-lane bar (clean re-review APPROVED + quality-gate pass), identical to the
+    # normal /work-on path; `main`/deploy-gate lands only on the strict ≥2 verified-human bar.
+    if [ "${IS_DEPLOY_GATE:-true}" = "false" ]; then
+      AUTO_LAND_BAR_TEXT="MET — fast-lane bar for non-\`main\` base (clean re-review APPROVED + quality gate pass), matching the normal /work-on merge bar for the same target branch"
+    else
+      AUTO_LAND_BAR_TEXT="MET (${APPROVED_COUNT:-0} APPROVED: reviews + quality gate pass)"
+    fi
+    OUTCOME_DETAIL="to {PR_BASE}" ;;
   HELD-AWAITING-MERGE) AUTO_LAND_BAR_TEXT="NOT MET (${APPROVED_COUNT:-0} APPROVED: reviews)"; OUTCOME_DETAIL="at workflow:awaiting-merge" ;;
   RE-ESCALATED)        AUTO_LAND_BAR_TEXT="N/A — re-escalated before the bar was evaluated"; OUTCOME_DETAIL="at needs-human" ;;
   UNFIXABLE)           AUTO_LAND_BAR_TEXT="N/A — unfixable (see Phase M1 classification)"; OUTCOME_DETAIL="at needs-human" ;;