riskrails 3.0.0 → 3.1.0

package/agents/ai-reviewer.md.tmpl

@@ -47,12 +47,14 @@ does each named finding close against the real code, and what did the remediatio
 introduce? A re-review that re-reads the whole change is a first review wearing
 the wrong name, and costs the same.
 
-Verify by execution where execution is possible. A claim you ran beats a claim you
-reasoned to, and it is what makes your row in the ledger worth inheriting.
+Read the diff; run only the tests the step names, through `step_test_command`; no
+scripts, mutation or timing loops in a scratchpad or temp dir. About 40 tool calls
+in light and guarded, about 80 in full, then FINDINGS and VERDICT, with
+`not reached (budget): …` under EXAMINED AND CLEAN.
 
 ## Boundary
 
-The brief names the task's mode; `.ai/state/current.json` has it otherwise. In
+The brief names the task's mode; `.ai/state/state.json` (or the legacy `current.json`) has it otherwise. In
 light and guarded mode your inputs are the task goal, the diff, the tests the
 step names, and the project's own fixture corpus and threat model:
 `.ai/policies/safety.md`, the guards' `*-defaults.json`, the test fixtures.
@@ -61,7 +63,7 @@ it — a shape no session produces, a size no fixture reaches — is reported as
 `[INFO]` with `in_scope: no`, with the severity it would carry inside the
 boundary in `why it matters`. It goes to the risk register, never to a
 remediation, and it does not move your verdict. In full mode there is no
-boundary: the list below applies unbounded.
+boundary: the list below applies unbounded, but the call cap holds.
 
 ## Look for
 

package/ai/policies/model-routing.md

@@ -19,16 +19,16 @@ not settle — never for fact collection.
 
 Which model a tier is depends on the plan and the runtime: the installed profile
 decides it, `state.py profile --tier <TIER>` prints it for the runtime you are in,
-and `/ai-status` shows all four. This file names tiers only, so it is true on
+and `/rr-status` shows the plan's budget. This file names tiers only, so it is true on
 every plan.
 
 The main session runs the model the installed profile sets and does the
 implementation itself. Planning, the weight, the test run and the release are
 its work too, not an agent's: `/rr-plan`, `state.py weight`, `state.py verify`,
 `/rr-ship`. Which stages spawn an agent at all
-is decided by `pipeline_profile` in `risk-tiers.json`: in `solo`, T0–T4 run in
-direct mode — nothing on STRONG below T4, a BALANCED review at T2/T3 only when
-a sensor is red, one STRONG review at T4 — and tests run once
+is decided by the mode `state.py weight` gives: light runs direct — no review
+unless `close` reports a red fact — guarded has one BALANCED review, full one
+STRONG review, and nothing runs on STRONG below full — and tests run once
 after the last step, to the end, with every failure fixed as one batch.
 
 **Reading by difficulty.** A lookup — where X is, one route, service id, config
@@ -65,12 +65,12 @@ depends on a local model; if one becomes available it slots in at the FAST tier.
 
 ## EXPERT triggers
 
-1. The task is T6: migration, infrastructure, production architecture.
+1. The task is full and irreversible: migration, infrastructure, production architecture.
 2. STRONG could not settle it: `confidence: uncertain`, or two STRONG results
    contradict each other.
 3. An irreversible design with several viable options — core data model, public
    API or event contract, service split.
-4. The final check of a T6 plan or of a production-incident root cause before a
+4. The final check of a full-and-irreversible plan or of a production-incident root cause before a
    human acts on it.
 
 ## Escalation
@@ -104,7 +104,7 @@ the model `state.py profile --tier STRONG` printed — because a tier alone does
 cost or how much weight to give it. Report the model that **ran**, not the one
 that was requested: a gate may have sent an EXPERT agent down one tier during a
 rate limit, and a Codex agent file may have overridden the spawn-time model. Both
-runtimes expose the current state through `/ai-status`.
+runtimes expose the current state through `/rr-status`.
 
 ## What never gets delegated
 

package/ai/policies/production.md

@@ -7,8 +7,8 @@ is reached by a real customer until you have evidence it is not.
 
 1. Find the callers. `grep`/`rg` for the method, the service id, the route, the
    event name, the template.
-2. Find the tests that pin the current behaviour. If none exist and the tier is
-   T3 or above, write a characterization test **first** — one that passes against
+2. Find the tests that pin the current behaviour. If none exist and the mode is
+   guarded or full, write a characterization test **first** — one that passes against
    the code as it is today.
 3. Check the history for why it looks like this: `git log -L`, `git log -S`,
    `git blame`. A workaround with a ticket number in the message is a constraint,
@@ -37,6 +37,6 @@ named in the release report. "It worked locally" is not observability.
 
 ## Rollback
 
-Every T3+ change states how to undo it. If undoing it is impossible — a data
+Every guarded or full change states how to undo it. If undoing it is impossible — a data
 migration, an external system call, a fiscal record — say so plainly in the
 release report, because that changes who has to approve it.

package/ai/policies/release.md

@@ -29,7 +29,7 @@ It exists so that the human approving the change can see, in one page, what
 changed, what deliberately did not, what was tested, what was reviewed, what
 could go wrong, and how to undo it.
 
-A report that says "no known risks" for a T4 change is a report that was not
+A report that says "no known risks" for a guarded or full change is a report that was not
 written carefully.
 
 ## What blocks a release
@@ -38,7 +38,7 @@ written carefully.
   `focus: security` pass;
 - a new regression in the last `state.py verify` run;
 - a destructive database operation without its own named approval;
-- a T3+ change with no rollback section;
+- a guarded or full change with no rollback section;
 - an unanswered blocking question in the plan.
 
 ## Project specifics

package/ai/policies/review-economy.md

@@ -72,8 +72,8 @@ The ledger is what replaces agent memory. Without it, every pass is pass one.
 ## 3. Findings are fixed as one batch, and re-review is scoped, not repeated
 
 A review returns all its findings at once, and they are fixed at once: one
-`state.py remediate` step whose scope is the finished steps plus what the
-findings name, every BLOCKER and HIGH addressed in it, then the verification
+fix batch (`state.py start --amend` widens the task to the finished steps plus
+what the findings name), every BLOCKER and HIGH addressed in it, then the verification
 command once. Never one fix, one run, one re-review per finding — that is the
 serial loop the measurements below describe, and the remediation of one finding
 is where the next regression comes from.
@@ -91,16 +91,19 @@ A task gets **two passes**: one full review and one scoped re-review, at every
 tier. That holds whoever asks — a re-review the human requests is one of the
 two, a cross-vendor review is one, and the parallel dimensions of §4 together
 are one. When both are spent, a third pass is not the next move: the human
-decides the verdict. The reviewer's verdict says which closing rule applies:
+decides the verdict. One exception, chosen per project or per task: a **batch**
+task (`/rr-build-all`, `weight.json` `batch.*`) runs a whole plan as one task,
+and its passes are full ones — `batch.review_rounds_max` of them (three as
+shipped), each after a fix batch — before the same stop: the pass past that
+number is the human's. The reviewer's verdict says which closing rule applies:
 `blockers_open` (a BLOCKER) takes the remediation and the scoped re-review;
 `pass_with_findings` (a HIGH, no BLOCKER) takes the remediation and a green
-verification run, no re-review; `pass` closes. `state.py` has no value of its
-own for `pass_with_findings` yet: it is recorded as `blockers_open`, stays so
-after the green run, and the close summary names the labels that run closed.
+verification run, no re-review; `pass` closes. `state.py review --verdict`
+takes all three values.
 
-## 3a. The boundary of a direct-mode review
+## 3a. The boundary of a light or guarded review
 
-Below T5 the review is bounded. Its inputs are the task goal, the diff, the
+In light and guarded the review is bounded. Its inputs are the task goal, the diff, the
 tests the step names, and the project's own fixture corpus and threat model —
 `.ai/policies/safety.md`, the guards' `*-defaults.json`, the test fixtures.
 The reviewer works its whole list inside that corpus; what it may not do is
@@ -113,8 +116,8 @@ it only towards `yes`.
 
 A guard whose input is any shell line is a bottomless well for an unbounded
 reviewer: every pass finds a new input nobody will type, and every fix for one
-is the next pass's target. The boundary is what lets a review end. At T5 and
-T6 there is none — the reviewer's list applies unbounded, as the cost of being
+is the next pass's target. The boundary is what lets a review end. In full
+mode there is none — the reviewer's list applies unbounded, as the cost of being
 wrong there warrants.
 
 ## 4. Split one pass into parallel dimensions, not serial rounds
@@ -170,40 +173,39 @@ script, or run it yourself:
 A review pass spent on a self-contradictory risk register is a pass not spent on
 the code. When a task closes a gap that a register entry calls open, the entry is
 corrected **in the same step as the fix**, not later. When the plan gains a
-remediation, the plan gains a section — at T4 and above the artefact a human
+remediation, the plan gains a section — in guarded and full the artefact a human
 approves must describe the change that exists, and a diff wider than the plan is
 invisible to the path guard, because the file set never changed.
 
 ## 8. The one thing the sensors may replace
 
-At T3 and below, when every sensor in `risk-tiers.json` `required_for_skip` is
-green or explicitly not applicable **on the tree as it is now**, the model
-review is replaced by the sensor set and `state.py review-gate` records
-`review_status: skipped_green`. This is the intent's decision 6, and it is an
-exception to the rule below, written here so the two do not contradict each
-other.
+In light mode, when the two facts `close` measures are green **on the tree as
+it is now** — a green whole-suite `verify` and every changed file inside the
+task's files — the model review is replaced by the sensor set and the task
+closes without one. This is the intent's decision 6, and it is an exception to
+the rule below, written here so the two do not contradict each other.
 
 It is narrow on purpose. The skip requires that the suite passed on this exact
-tree, that the tests the plan named **fail without the change** (`bite` — a
-green suite that never reaches the diff is not evidence), that the diff is
-inside its budget — the budget is advisory for the tier, never for the skip —
-and that the tier re-scored from the real diff is still T3 or lower. A missing
-linter is not green: `unavailable` keeps the review, and only a human writing
-`lint_command: none` says the project has no linter. No
-sensor writes `skipped_green` by asserting it — `review-gate` reaches it from
-measurements, and `state.py set review_status skipped_green` is refused.
-
-From T4 the review always runs. What the sensors change there is where it
-starts: their rows are in the ledger, CONFIRMED, before the reviewer plans its
-work.
+tree, and that the tests the plan named **fail without the change** (`bite` — a
+green suite that never reaches the diff is not evidence). The mode is the one
+re-scored from the real diff: a diff that raises it to guarded or full keeps the
+review. A missing linter is not green: `unavailable` keeps the review, and only
+a human writing `lint_command: none` says the project has no linter. No
+sensor skips the review by asserting it — `close` reaches it from
+measurements.
+
+In guarded and full the review always runs. What the sensors change there is
+where it starts: their rows are in the ledger, CONFIRMED, before the reviewer
+plans its work.
 
 ## What this policy will not trade away
 
-- No review stage the tier requires is skipped, shortened, or merged — except
-  the T2/T3 model review, and only under §8's measured conditions.
+- No review stage the mode requires is skipped, shortened, or merged — except
+  the light-mode model review, and only under §8's measured conditions.
 - No reviewer is moved to a cheaper model to go faster. Narrow the surface, never
   the mind.
 - A blocker still returns to implementation, however late it arrives. Past the
-  two passes of §3, a human — not a third pass — decides that it closed.
+  two passes of §3 — `batch.review_rounds_max` passes in a batch task — a human,
+  not another pass, decides that it closed.
 - The probe is the manager's own work and never replaces the adversarial pass. It
   exists so the pass starts further in, not so it happens less.

package/ai/using-riskrails.md

@@ -13,6 +13,7 @@ the steps; `policies/` holds the rules; this says which to open.
 | turn an idea into intent, requirements and design | `/rr-spec <idea>` |
 | plan a spec into tasks, or one task into a mode and a start | `/rr-plan <spec or task>` |
 | do the work, or resume it | `/rr-build` (no task in flight: it runs `/rr-plan` first) |
+| run a whole plan as one task — parallel implementers and fixers, tests and the review again until it passes | `/rr-build-all <plan>` |
 | review the change | `/rr-review` — guarded and full, or when `close` asks |
 | close the task, get the human's approval | `/rr-ship` |
 | see where the task stands, or what it cost | `/rr-status`, `/rr-status --cost` |
@@ -38,6 +39,20 @@ domain at 2 is full whatever W is.
 The mode only rises during a task (`verify` and `close` re-score reversibility
 and domain from the diff); lowering it is the human's.
 
+## Batch — one task for a whole plan
+
+`/rr-build-all docs/sdlc/plans/<slug>.md` runs every row of a programme plan as
+one task: the ready rows go to parallel implementers on BALANCED (`after`
+serializes the dependent ones), the suite runs once, every failure is fixed by
+parallel fixers as one batch, one review at the mode's tier, its findings fixed
+as one batch, then tests and the review again until it passes. Its budgets are
+`weight.json` `batch.*`: three failed review passes (`batch.review_rounds_max`)
+and eight suite runs stop at the human — `REVIEW_BUDGET` and `SUITE_BUDGET`, as
+always. The mode, the guard, the two facts and the gate are unchanged.
+`batch.default` makes it the project's default; `state.py batch off --by …
+--why …` returns a task to the standard loop (anyone); `batch on` mid-task is
+the human's, from their own terminal.
+
 ## The two facts
 
 `close` measures, never asks: (a) a green whole-suite `verify` on the tree as it

package/bin/claude-1m

@@ -6,15 +6,15 @@
 #   claude-1m                    Opus 5 [1m] as the main session
 #   claude-1m fable              Fable 5.1 [1m] as the main session
 #   claude-1m fable -p '<brief>' one headless large-context run, e.g. called from another session
-#   CLAUDE_1M_COMPACT_WINDOW=500000 claude-1m     # compact earlier than 767k
+#   CLAUDE_1M_COMPACT_WINDOW=500000 claude-1m     # compact earlier than the runtime would
 #
-# `autoCompactWindow` in settings.json is one value for every model, but Claude Code
-# caps it at the model's own window, so the 800 000 there already means near 167k on
-# `opus` and near 767k on `opus[1m]` and `fable[1m]`. This launcher is therefore about
-# the model, not the window: it pins a [1m] model for one session at launch.
-# CLAUDE_CODE_AUTO_COMPACT_WINDOW still outranks settings.json for this process only,
-# which is how CLAUDE_1M_COMPACT_WINDOW compacts *earlier* than 767k. context-guard
-# reads the same variable, so its warning and hold-back thresholds follow.
+# This launcher is about the model, not the window: it pins a [1m] model for one
+# session at launch, and by default leaves compaction to Claude Code (or to the
+# `autoCompactWindow` of an install with `--context economy`, which Claude Code caps at
+# the model's own window: 800 000 means near 167k on `opus` and near 767k on `opus[1m]`).
+# Only CLAUDE_1M_COMPACT_WINDOW sets a window: exported as CLAUDE_CODE_AUTO_COMPACT_WINDOW,
+# it outranks settings.json for this process only. context-guard reads the same
+# variable, so its warning and hold-back thresholds follow.
 #
 # Subagents get the session's window, capped by Claude Code at each model's own: a 200k
 # agent compacts near 167k, and `architect` on fable[1m] gets the full window.
@@ -28,10 +28,11 @@ case "${1:-}" in
   fable) MODEL='fable[1m]'; shift;;
 esac
 
-WINDOW="${CLAUDE_1M_COMPACT_WINDOW:-800000}"
-case "$WINDOW" in
-  ''|*[!0-9]*) echo "claude-1m: CLAUDE_1M_COMPACT_WINDOW must be a number of tokens (got '$WINDOW')" >&2; exit 2;;
-esac
-
-export CLAUDE_CODE_AUTO_COMPACT_WINDOW="$WINDOW"
+if [ -n "${CLAUDE_1M_COMPACT_WINDOW:-}" ]; then
+  WINDOW="$CLAUDE_1M_COMPACT_WINDOW"
+  case "$WINDOW" in
+    ''|*[!0-9]*) echo "claude-1m: CLAUDE_1M_COMPACT_WINDOW must be a number of tokens (got '$WINDOW')" >&2; exit 2;;
+  esac
+  export CLAUDE_CODE_AUTO_COMPACT_WINDOW="$WINDOW"
+fi
 exec "${CLAUDE_BIN:-claude}" --model "$MODEL" "$@"