@windyroad/risk-scorer 0.3.3 → 0.3.4-preview.104

package/.claude-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "wr-risk-scorer",
-  "version": "0.3.0",
+  "version": "0.3.4",
   "description": "Pipeline risk scoring, commit/push/release gates for Claude Code"
-}
+}

package/agents/pipeline.md

@@ -94,7 +94,36 @@ Commit score >= push score >= release score (risk accumulates upward).
 
 ## Risk-Reducing and Risk-Neutral Bypass
 
-Assess whether each action is risk-reducing, risk-neutral, or risk-increasing. Include `RISK_BYPASS: reducing` in your output for reducing/neutral actions. Do not include it for risk-increasing actions.
+`RISK_BYPASS: reducing` is reserved for commits that genuinely reduce risk.
+The 329-report retrospective found this label applied to 97.9% of commits in
+this repo because the old criteria were too loose — changeset metadata, ADR
+checkbox ticks, and docs-only edits all earned the bypass. When nearly
+everything is "reducing", the label provides no discriminating signal. These
+criteria tighten that.
+
+Emit `RISK_BYPASS: reducing` ONLY when ALL of the following are true:
+1. The commit closes a problem ticket (the diff includes a `.known-error.md` →
+   `.closed.md` rename, references "closes P<NNN>" in the commit message, or
+   adds a `## Fix Committed` section to a known-error ticket), OR
+2. The commit explicitly remediates a risk item previously flagged by the
+   scorer in a prior report (the diff fixes something a prior risk report
+   called out), OR
+3. The commit removes a documented risk (retires a hazardous hook, removes an
+   insecure API, deletes a known-defective code path)
+
+Ordinary commits that do not meet at least one of these conditions are **risk-neutral, not risk-reducing**. Docs-only edits, test-only additions without a remediation link, and routine refactors are all neutral — do NOT emit the reducing bypass for them.
+
+When emitting `RISK_BYPASS: reducing`, cite the reason on a companion
+`RISK_BYPASS_REASON:` line so the bypass is auditable:
+
+```
+RISK_BYPASS: reducing
+RISK_BYPASS_REASON: closes P043 (tightens reducing-bypass criteria; removes previously-flagged over-application)
+```
+
+Acceptable `RISK_BYPASS_REASON:` values cite the ticket ID closed, the prior
+risk report remediated, or the removed risk — matching one of the three
+criteria above.
 
 For live incidents (outage, security, information disclosure), include `RISK_BYPASS: incident`.
 
@@ -109,7 +138,18 @@ Do NOT emit: "Suggested Actions", "Your call:", advisory warnings, back-pressure
 
 ## Above-Appetite Remediations
 
-When ANY cumulative score exceeds appetite (> 4), emit a structured `RISK_REMEDIATIONS:` block after the `RISK_SCORES:` line. This gives the calling skill machine-readable input for structured decision prompts.
+When ANY cumulative score exceeds appetite (> 4), the verbal verdict is **STOP**.
+The scorer is not the primary decision-maker — the hook gate will block the
+action — but the scorer's verdict must match the structured score so the agent
+does not waste tool calls acting on an ambiguous nudge.
+
+**Do NOT emit** "Proceed", "Proceed with release", "Continue", "You may ship",
+"OK to commit/push/release", or any similar nudge language when cumulative risk
+exceeds appetite. The only sanctioned above-appetite output is the Risk Report
+structure, `RISK_SCORES: ...`, and the structured `RISK_REMEDIATIONS:` block
+defined below.
+
+Emit a structured `RISK_REMEDIATIONS:` block after the `RISK_SCORES:` line. This gives the calling skill machine-readable input for structured decision prompts.
 
 Format (5 columns — machine-readable for structured AskUserQuestion prompts in calling skills):
 ```
@@ -144,6 +184,42 @@ Do not rely on a static list. For each control claimed to reduce risk, you MUST:
 3. Ask: "Would this control catch this failure before reaching the user?"
 4. **Name the control**: "Tests pass" is not a control. Name the specific test file and scenario. If you cannot name it, it provides 0 reduction.
 
+**Monitoring is not a control.** Monitoring, alerting, dashboards, and any other post-release detection activity MUST NOT be credited as a control that reduces residual risk. Post-release detection does NOT reduce pre-release risk — it only shortens the time to notice a failure after it has already reached users. A genuine control exercises the failure
+scenario BEFORE the change ships: a test, a CI gate, a feature flag, a preview
+verification, an architect review, an installer dry-run. Monitoring and rollback
+readiness may be listed separately as "post-release follow-ups" outside the
+residual risk computation, but MUST NOT appear in a Controls list and MUST NOT
+reduce any inherent risk score.
+
+## User-Stated Preconditions Check
+
+A technical control list never substitutes for an explicit user warning. Before
+credit is given to any control, check for **user-stated preconditions** — conditions
+the user has named in the current conversation, commit messages, changesets, or
+problem tickets that tie this change to a paired capability (e.g., "A is only safe
+if B ships alongside", "don't release X until Y is merged").
+
+For each user-stated precondition:
+1. Determine whether the paired capability is released, queued in the unreleased
+   changeset batch, or unmet.
+2. If unmet, the precondition is a failed control — credit zero reduction from
+   otherwise-valid controls (tests, CI, architect review) that do not address the
+   precondition itself.
+3. Surface the unmet precondition as a standalone **Risk item** with inherent
+   impact and likelihood reflecting the consequence the user warned about.
+   Inherent risk MUST be >= Medium (>= 5), even when the diff's technical risk
+   alone would score Low. This routes the precondition through the existing
+   above-appetite `RISK_REMEDIATIONS:` flow rather than burying it in prose.
+
+Sources to inspect for stated preconditions:
+- Recent conversation messages directed to the agent
+- Open or known-error problem tickets referenced in the diff or recent commits
+- Commit messages and changeset files on the unreleased queue
+- CLAUDE.md notes about cross-cutting dependencies
+
+User warnings reflect domain context the scorer cannot derive from the diff alone.
+They outrank the technical assessment.
+
 ## Constraints
 
 - You are a scorer, not an editor.

package/agents/plan.md

@@ -49,7 +49,13 @@ You are the Risk Scorer in plan review mode. Assess both the plan's own risk AND
 
 End your report with `RISK_VERDICT: PASS` or `RISK_VERDICT: FAIL` on its own line. A PostToolUse hook reads this and writes the marker files — do NOT write files yourself.
 
-On FAIL, emit a structured `RISK_REMEDIATIONS:` block after the verdict (5 columns — machine-readable for structured AskUserQuestion prompts in calling skills):
+On FAIL, the verbal verdict is **STOP**. **Do NOT emit** "Proceed", "Continue",
+"You may ship", "OK to implement", or any similar nudge language. The plan is
+not policy-authorised — the only sanctioned FAIL output is the Plan Risk Report,
+the `RISK_VERDICT: FAIL` marker, and the structured `RISK_REMEDIATIONS:` block
+defined below.
+
+Emit a structured `RISK_REMEDIATIONS:` block after the verdict (5 columns — machine-readable for structured AskUserQuestion prompts in calling skills):
 ```
 RISK_REMEDIATIONS:
 - R1 | <description of what the plan must add/change> | <effort S/M/L> | <risk_delta -N> | <affected area>
@@ -68,6 +74,27 @@ For each control claimed to reduce risk:
 2. Name the specific test file/scenario or hook
 3. If you cannot name it, it provides 0 reduction
 
+**Monitoring is not a control.** Monitoring, alerting, dashboards, and any other post-release detection activity MUST NOT be credited as a control in a plan's residual risk. Post-release detection does NOT reduce pre-release risk — it only shortens the time to notice a failure after it has already reached users. A genuine control exercises the failure scenario before the
+plan's changes ship: a test, a CI gate, a feature flag, a preview verification,
+an architect review. Monitoring MUST NOT appear in a Controls list and MUST NOT
+reduce any inherent risk score.
+
+## User-Stated Preconditions Check
+
+Before crediting any control, check for **user-stated preconditions** — conditions
+the user has named in the plan, associated problem tickets, commit messages, or
+CLAUDE.md that tie this plan to a paired capability (e.g., "A is only safe if B
+ships alongside", "don't release X until Y is merged").
+
+For each user-stated precondition:
+1. Check whether the plan already addresses or queues the paired capability.
+2. If the precondition is unmet in the plan, credit zero reduction from controls
+   that do not cover the precondition, and surface the unmet precondition as a **Risk item** with inherent risk >= Medium (>= 5).
+3. A plan that ships a change without addressing a user-stated precondition
+   must be FAIL, regardless of the diff's technical score.
+
+User warnings outrank technical control discovery.
+
 ## Constraints
 
 - You are a scorer, not an editor.

package/agents/test/risk-scorer-above-appetite-stop.bats

@@ -0,0 +1,80 @@
+#!/usr/bin/env bats
+# Doc-lint guard: risk-scorer agent prompts must contain an explicit
+# STOP / do-not-proceed directive in their Above-Appetite sections.
+#
+# Structural assertions — Permitted Exception to the source-grep ban (ADR-005 / P011).
+# These tests assert that the pipeline, wip, and plan scorer prompts forbid
+# "Proceed", "Continue", or "You may ship" nudges when cumulative risk
+# exceeds appetite.
+#
+# Background: P037 identified that scorer reports could include "Proceed
+# with release" or similar nudge language even when residual risk exceeded
+# appetite. The hook gate then correctly blocked the action, but only after
+# the agent wasted tool calls and tokens acting on the nudge. The scorer
+# is not the primary decision-maker, but its verbal verdict must match the
+# structured score — ambiguous "proceed" language undermines this.
+#
+# The Below-Appetite Output Rule (ADR-013 Rule 5) already requires silent
+# policy-authorised release when all scores are within appetite. This guard
+# enforces the inverse: an explicit STOP directive above appetite.
+#
+# Cross-reference:
+#   P037:    docs/problems/037-risk-scorer-proceeds-above-appetite.open.md
+#   ADR-013: docs/decisions/013-structured-user-interaction-for-governance-decisions.proposed.md
+#   @jtbd JTBD-001 (enforce governance without slowing down)
+#   @jtbd JTBD-002 (ship with confidence — verbal verdict must match structured score)
+#   @jtbd JTBD-202 (pre-flight governance — structured output is the only sanctioned channel)
+
+setup() {
+  AGENTS_DIR="$(cd "$(dirname "$BATS_TEST_FILENAME")/.." && pwd)"
+  PIPELINE="${AGENTS_DIR}/pipeline.md"
+  WIP="${AGENTS_DIR}/wip.md"
+  PLAN="${AGENTS_DIR}/plan.md"
+}
+
+# ──────────────────────────────────────────────────────────────────────────────
+# pipeline.md: Above-Appetite STOP directive
+# ──────────────────────────────────────────────────────────────────────────────
+
+@test "pipeline.md Above-Appetite section contains explicit STOP directive" {
+  # Must contain the word STOP (or BLOCKED) as the verdict above appetite.
+  run grep -qE "STOP|BLOCKED" "$PIPELINE"
+  [ "$status" -eq 0 ]
+}
+
+@test "pipeline.md Above-Appetite section forbids Proceed nudges" {
+  # Must explicitly forbid emitting "Proceed" / "Continue" nudges
+  # when risk exceeds appetite.
+  run grep -qE "[Dd]o NOT emit.*Proceed|forbid.*Proceed|not emit.*Continue|must not.*proceed" "$PIPELINE"
+  [ "$status" -eq 0 ]
+}
+
+# ──────────────────────────────────────────────────────────────────────────────
+# wip.md: Above-Appetite STOP directive
+# ──────────────────────────────────────────────────────────────────────────────
+
+@test "wip.md Above-Appetite section contains explicit STOP directive" {
+  # PAUSE is the wip-mode verdict equivalent of STOP.
+  run grep -qE "STOP|BLOCKED|PAUSE" "$WIP"
+  [ "$status" -eq 0 ]
+}
+
+@test "wip.md Above-Appetite section forbids Proceed nudges" {
+  run grep -qE "[Dd]o NOT emit.*Proceed|forbid.*Proceed|not emit.*Continue|must not.*proceed" "$WIP"
+  [ "$status" -eq 0 ]
+}
+
+# ──────────────────────────────────────────────────────────────────────────────
+# plan.md: FAIL directive (plan-mode equivalent of STOP)
+# ──────────────────────────────────────────────────────────────────────────────
+
+@test "plan.md FAIL section contains explicit STOP directive" {
+  # FAIL is the plan-mode verdict; reinforces STOP language.
+  run grep -qE "STOP|BLOCKED|FAIL" "$PLAN"
+  [ "$status" -eq 0 ]
+}
+
+@test "plan.md FAIL section forbids Proceed nudges" {
+  run grep -qE "[Dd]o NOT emit.*Proceed|forbid.*Proceed|not emit.*Continue|must not.*proceed" "$PLAN"
+  [ "$status" -eq 0 ]
+}

package/agents/test/risk-scorer-monitoring-not-a-control.bats

@@ -0,0 +1,76 @@
+#!/usr/bin/env bats
+# Doc-lint guard: risk-scorer agent prompts must explicitly state that
+# monitoring, alerting, and other post-release detection activities are
+# NOT controls and MUST NOT be credited against residual risk.
+#
+# Structural assertions — Permitted Exception to the source-grep ban (ADR-005 / P011).
+#
+# Background: P038 identified that scorer reports were crediting
+# "monitor for elevated errors", "be ready to rollback", and similar
+# post-release detection activities as controls that reduced residual
+# risk. These activities help detect failures after they occur — they
+# are incident response, not release-gate risk reduction. Crediting
+# them creates false confidence in risky releases.
+#
+# A genuine control exercises the failure scenario BEFORE the change
+# ships (tests, CI gates, feature flags, preview verification, architect
+# review). Monitoring shortens detection time; it does not prevent the
+# failure from reaching users.
+#
+# Cross-reference:
+#   P038:    docs/problems/038-risk-scorer-suggests-monitoring-as-control.open.md
+#   ADR-013: docs/decisions/013-structured-user-interaction-for-governance-decisions.proposed.md
+#   @jtbd JTBD-001 (enforce governance — control list must reflect actual prevention)
+#   @jtbd JTBD-002 (ship with confidence — no false-confidence releases)
+#   @jtbd JTBD-202 (pre-flight governance — scorer must distinguish prevention from detection)
+
+setup() {
+  AGENTS_DIR="$(cd "$(dirname "$BATS_TEST_FILENAME")/.." && pwd)"
+  PIPELINE="${AGENTS_DIR}/pipeline.md"
+  WIP="${AGENTS_DIR}/wip.md"
+  PLAN="${AGENTS_DIR}/plan.md"
+}
+
+# ──────────────────────────────────────────────────────────────────────────────
+# pipeline.md
+# ──────────────────────────────────────────────────────────────────────────────
+
+@test "pipeline.md states monitoring is not a control" {
+  run grep -qE "[Mm]onitoring is (not|NOT) a control|[Mm]onitoring.*MUST NOT.*credit" "$PIPELINE"
+  [ "$status" -eq 0 ]
+}
+
+@test "pipeline.md forbids crediting post-release detection as risk reduction" {
+  # Post-release detection activities (monitoring, alerting, rollback readiness)
+  # must not reduce residual risk.
+  run grep -qE "post-release.*(not|NOT) (reduce|control|credit)|detection.*(not|NOT) (reduce|prevention)" "$PIPELINE"
+  [ "$status" -eq 0 ]
+}
+
+# ──────────────────────────────────────────────────────────────────────────────
+# wip.md
+# ──────────────────────────────────────────────────────────────────────────────
+
+@test "wip.md states monitoring is not a control" {
+  run grep -qE "[Mm]onitoring is (not|NOT) a control|[Mm]onitoring.*MUST NOT.*credit" "$WIP"
+  [ "$status" -eq 0 ]
+}
+
+@test "wip.md forbids crediting post-release detection as risk reduction" {
+  run grep -qE "post-release.*(not|NOT) (reduce|control|credit)|detection.*(not|NOT) (reduce|prevention)" "$WIP"
+  [ "$status" -eq 0 ]
+}
+
+# ──────────────────────────────────────────────────────────────────────────────
+# plan.md
+# ──────────────────────────────────────────────────────────────────────────────
+
+@test "plan.md states monitoring is not a control" {
+  run grep -qE "[Mm]onitoring is (not|NOT) a control|[Mm]onitoring.*MUST NOT.*credit" "$PLAN"
+  [ "$status" -eq 0 ]
+}
+
+@test "plan.md forbids crediting post-release detection as risk reduction" {
+  run grep -qE "post-release.*(not|NOT) (reduce|control|credit)|detection.*(not|NOT) (reduce|prevention)" "$PLAN"
+  [ "$status" -eq 0 ]
+}

package/agents/test/risk-scorer-reducing-bypass-criteria.bats

@@ -0,0 +1,62 @@
+#!/usr/bin/env bats
+# Doc-lint guard: risk-scorer agent prompts must scope the
+# `RISK_BYPASS: reducing` label to commits that actually reduce risk.
+#
+# Structural assertions — Permitted Exception to the source-grep ban (ADR-005 / P011).
+#
+# Background: P043 analysed 329 risk reports across 6 projects and found
+# `RISK_BYPASS: reducing` applied to 97.9% of commits in this repo and
+# 79.6% across consumer projects. The scorer treated changeset metadata,
+# ADR checkbox ticks, docs-only edits, and genuinely risk-reducing fixes
+# all the same way. When nearly every commit is "reducing", the label
+# provides no discriminating signal.
+#
+# The tightened criteria require the commit to:
+#   1. Close a problem ticket, OR
+#   2. Explicitly remediate a previously-flagged risk, OR
+#   3. Remove a documented risk
+# Ordinary docs-only or test-only commits that don't meet one of these
+# conditions are risk-neutral — no bypass label.
+#
+# Cross-reference:
+#   P043:    docs/problems/043-risk-bypass-reducing-lost-discriminating-power.open.md
+#   ADR-013: docs/decisions/013-structured-user-interaction-for-governance-decisions.proposed.md
+#   @jtbd JTBD-001 (enforce governance — bypass must reflect real risk reduction)
+#   @jtbd JTBD-202 (pre-flight governance — bypass label must be auditable)
+
+setup() {
+  AGENTS_DIR="$(cd "$(dirname "$BATS_TEST_FILENAME")/.." && pwd)"
+  PIPELINE="${AGENTS_DIR}/pipeline.md"
+}
+
+# NOTE: wip.md is intentionally excluded from these assertions — wip-mode emits
+# RISK_VERDICT: CONTINUE/PAUSE, not RISK_BYPASS labels. Bypass criteria apply
+# only to the pipeline (commit/push/release) scorer.
+
+# ──────────────────────────────────────────────────────────────────────────────
+# pipeline.md: tightened reducing criteria
+# ──────────────────────────────────────────────────────────────────────────────
+
+@test "pipeline.md reducing bypass requires closing a ticket" {
+  # Must reference ticket closure as a valid trigger for reducing bypass.
+  run grep -qE "[Cc]lose[sd]?.*ticket|[Cc]loses P[0-9]|problem.*close" "$PIPELINE"
+  [ "$status" -eq 0 ]
+}
+
+@test "pipeline.md reducing bypass requires remediating a flagged risk" {
+  run grep -qE "remediate.*risk|remediates.*risk|flagged risk" "$PIPELINE"
+  [ "$status" -eq 0 ]
+}
+
+@test "pipeline.md reducing bypass excludes docs-only neutral commits" {
+  # Ordinary docs/test commits without ticket closure must NOT earn the bypass.
+  run grep -qE "docs-only.*neutral|test-only.*neutral|ordinary.*neutral|neutral.*no bypass" "$PIPELINE"
+  [ "$status" -eq 0 ]
+}
+
+@test "pipeline.md requires audit reason for reducing bypass" {
+  # Audit trail: cite which ticket closed, which risk remediated, etc.
+  run grep -qE "RISK_BYPASS_REASON|cite.*ticket|reason.*bypass|bypass.*reason" "$PIPELINE"
+  [ "$status" -eq 0 ]
+}
+

package/agents/test/risk-scorer-user-stated-preconditions.bats

@@ -0,0 +1,89 @@
+#!/usr/bin/env bats
+# Doc-lint guard: risk-scorer agent prompts must define a User-Stated
+# Preconditions Check as a sub-rule of Control Discovery.
+#
+# Structural assertions — Permitted Exception to the source-grep ban (ADR-005 / P011).
+# These tests assert that the pipeline, wip, and plan scorer prompts
+# instruct the scorer to detect user-stated conditional-delivery warnings
+# and surface unmet preconditions as Risk items.
+#
+# Background: P041 identified that the risk scorer evaluated technical
+# risk of a diff in isolation and missed explicit user-stated warnings
+# that a change was conditional on a paired capability. Downstream this
+# caused a breaking change to ship to production despite a twice-stated
+# user warning. This guard prevents regression of the fix: every scoring
+# agent must have a User-Stated Preconditions Check.
+#
+# Cross-reference:
+#   P041:    docs/problems/041-risk-scorer-misses-user-stated-dependencies.known-error.md
+#   ADR-013: structured user interaction for governance decisions
+#   @jtbd JTBD-002 (ship with confidence — user-stated preconditions are honoured)
+#   @jtbd JTBD-202 (pre-flight governance checks surface explicit warnings)
+
+setup() {
+  AGENTS_DIR="$(cd "$(dirname "$BATS_TEST_FILENAME")/.." && pwd)"
+  PIPELINE="${AGENTS_DIR}/pipeline.md"
+  WIP="${AGENTS_DIR}/wip.md"
+  PLAN="${AGENTS_DIR}/plan.md"
+}
+
+# ──────────────────────────────────────────────────────────────────────────────
+# pipeline.md: user-stated precondition check
+# ──────────────────────────────────────────────────────────────────────────────
+
+@test "pipeline.md defines User-Stated Preconditions Check section" {
+  run grep -q "User-Stated Preconditions" "$PIPELINE"
+  [ "$status" -eq 0 ]
+}
+
+@test "pipeline.md precondition check surfaces unmet preconditions as Risk items" {
+  # Unmet preconditions must flow through the existing Risk item structure,
+  # which feeds RISK_REMEDIATIONS above appetite (>= 5).
+  run grep -qE "precondition.*Risk item|Risk item.*precondition" "$PIPELINE"
+  [ "$status" -eq 0 ]
+}
+
+@test "pipeline.md precondition check credits zero reduction when paired capability is unmet" {
+  # Aligns with existing Control Discovery rule: if a control cannot be named,
+  # or a stated precondition is unmet, the control provides 0 reduction.
+  run grep -qE "zero reduction|0 reduction" "$PIPELINE"
+  [ "$status" -eq 0 ]
+}
+
+# ──────────────────────────────────────────────────────────────────────────────
+# wip.md: user-stated precondition check
+# ──────────────────────────────────────────────────────────────────────────────
+
+@test "wip.md defines User-Stated Preconditions Check section" {
+  run grep -q "User-Stated Preconditions" "$WIP"
+  [ "$status" -eq 0 ]
+}
+
+@test "wip.md precondition check surfaces unmet preconditions as Risk items" {
+  run grep -qE "precondition.*Risk item|Risk item.*precondition" "$WIP"
+  [ "$status" -eq 0 ]
+}
+
+@test "wip.md precondition check credits zero reduction when paired capability is unmet" {
+  run grep -qE "zero reduction|0 reduction" "$WIP"
+  [ "$status" -eq 0 ]
+}
+
+# ──────────────────────────────────────────────────────────────────────────────
+# plan.md: user-stated precondition check
+# ──────────────────────────────────────────────────────────────────────────────
+
+@test "plan.md defines User-Stated Preconditions Check section" {
+  run grep -q "User-Stated Preconditions" "$PLAN"
+  [ "$status" -eq 0 ]
+}
+
+@test "plan.md precondition check surfaces unmet preconditions as Risk items" {
+  run grep -qE "precondition.*Risk item|Risk item.*precondition" "$PLAN"
+  [ "$status" -eq 0 ]
+}
+
+@test "plan.md precondition check credits zero reduction when paired capability is unmet" {
+  run grep -qE "zero reduction|0 reduction" "$PLAN"
+  [ "$status" -eq 0 ]
+}

package/agents/wip.md

@@ -51,7 +51,15 @@ If cumulative risk is **within appetite** (< 5): provide the assessment table an
 
 ### Above-Appetite Remediations
 
-If cumulative risk **exceeds appetite** (>= 5): provide the assessment table, then emit a structured `RISK_REMEDIATIONS:` block with specific risk-reducing actions:
+If cumulative risk **exceeds appetite** (>= 5), the verbal verdict is **PAUSE**
+(the wip-mode equivalent of STOP).
+
+**Do NOT emit** "Proceed", "Continue", "OK to edit", "You may commit", or any
+similar nudge language when cumulative risk exceeds appetite. The only
+sanctioned above-appetite output is the WIP Risk Assessment table and the
+structured `RISK_REMEDIATIONS:` block defined below.
+
+Provide the assessment table, then emit a structured `RISK_REMEDIATIONS:` block with specific risk-reducing actions:
 
 Format (5 columns — machine-readable for structured AskUserQuestion prompts in calling skills):
 ```
@@ -100,6 +108,25 @@ RISK_COMMIT_REASON: <one-line description of the completed governance work detec
 
 For each control claimed to reduce risk, name the specific test file/scenario. If you cannot name it, it provides 0 reduction.
 
+**Monitoring is not a control.** Monitoring, alerting, dashboards, and any other post-release detection activity MUST NOT be credited or reduce residual risk. Post-release detection does NOT reduce pre-release risk — it only shortens the time to notice a failure after it has already reached users.
+A genuine control exercises the failure scenario before the change ships: a
+test, a CI gate, a feature flag, a preview verification. Monitoring MUST NOT
+appear in a Controls list and MUST NOT reduce any inherent risk score.
+
+## User-Stated Preconditions Check
+
+Before crediting any control, check for **user-stated preconditions** — conditions
+the user has named in the current conversation, commit messages, changesets, or
+problem tickets that tie this change to a paired capability (e.g., "A is only safe
+if B ships alongside").
+
+If a paired capability is unmet, credit zero reduction from controls that do not
+address the precondition, and surface the unmet precondition as a **Risk item**
+with inherent risk >= Medium (>= 5). This routes it into the above-appetite
+`RISK_REMEDIATIONS:` flow and forces a PAUSE verdict until the precondition is
+met or the change is revised. User warnings outrank the diff's technical
+assessment.
+
 ## Constraints
 
 - You are a scorer, not an editor. Do NOT write files — a PostToolUse hook handles that.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@windyroad/risk-scorer",
-  "version": "0.3.3",
+  "version": "0.3.4-preview.104",
   "description": "Pipeline risk scoring, commit/push gates, and secret leak detection",
   "bin": {
     "windyroad-risk-scorer": "./bin/install.mjs"