riskrails 3.2.2 → 4.1.0

package/skills/project-init/templates/constitution.md

@@ -1,14 +1,14 @@
 # Constitution — {{PROJECT}}
 
 <!-- The 10–15 principles this project does not negotiate, one line each, numbered C1…;
-     /sdlc-spec and the planner cite them. Under 15: what is not here lives in .ai/policies/. -->
+     /rr-spec and the planner cite them. Under 15: what is not here lives in .ai/policies/. -->
 
 C1. Production behaviour is the source of truth; what looks wrong may be load-bearing.
 C2. A bugfix starts with the failing test; legacy behaviour gets a characterization test before it changes.
 C3. A refactoring changes no behaviour and is never mixed with a feature.
 C4. Every step names its files; scope grows only by amending the plan.
 C5. No agent merges or deploys; an agent commits, pushes or approves only by running, verbatim and once, a command a human picked in the dialog, as the harness recorded; else a human runs it outside.
-C6. <!-- project principle — filled by /ai-init from the survey, confirmed by you -->
+C6. <!-- project principle — filled by /rr-setup from the survey, confirmed by you -->
 C7. <!-- project principle -->
 C8. <!-- project principle -->
 C9. <!-- project principle -->

package/skills/project-update/history/blobs/00f5e27ce2d66e3a1d8b222b013ae8fa1fed32612d91a551e0c661cee3ef9c2d

@@ -0,0 +1,34 @@
+# Workflow: bugfix
+
+Something behaves wrongly. The goal is the smallest change that fixes it without
+changing anything else.
+
+> Who runs a stage is set by `pipeline_profile` in `policies/risk-tiers.json`.
+> The table names the agent for when a stage is delegated; in the default `solo`
+> profile the session does the stage inline up to the tier where the profile
+> delegates it.
+
+| Stage | Who | Notes |
+|---|---|---|
+| DISCOVERY | `ai-discovery` | reproduce first: find the exact path that produces the symptom |
+| CONTEXT | `ai-context` | include the *correct* behaviour and where it is defined |
+| IMPACT ANALYSIS | `ai-discovery` | who else depends on the current, wrong behaviour |
+| RISK CLASSIFICATION | `ai-risk` | a bug in a payment path is still T4 |
+| PLAN | `ai-planner` | failing test first, then the fix |
+| IMPLEMENTATION | the session | the failing test is its own step |
+| TEST | `ai-tester` | the new test fails before the fix and passes after |
+| ADVERSARIAL REVIEW | `ai-reviewer` | T2 and above |
+| SECURITY REVIEW | `ai-security` | if the bug was a security bug, always |
+| RELEASE REPORT | `ai-release` | |
+| HUMAN APPROVAL | the human | |
+
+## Specific to this workflow
+
+- **Write the failing test first.** A bugfix without a test that failed before it
+  is a bugfix nobody can prove.
+- Find out *why* the bug exists before fixing it. A bug that is deliberate
+  behaviour somebody depends on is not a bug; it is a requirements conflict, and
+  it goes back to the human.
+- Resist the urge to fix the surrounding code. Note it, fix the bug.
+- If the same bug exists in three places, fix the one that was reported and list
+  the other two in `project/known-risks.md`.

package/skills/project-update/history/blobs/0a6b1b6dd06a35582b2e9989a1f41c40abc29254b8e482714fcc6f0a7b16c406

@@ -0,0 +1,32 @@
+# Workflow: feature
+
+New behaviour that someone asked for. The default workflow.
+
+> Who runs a stage is set by `pipeline_profile` in `policies/risk-tiers.json`.
+> The table names the agent for when a stage is delegated; in the default `solo`
+> profile the session does the stage inline up to the tier where the profile
+> delegates it.
+
+| Stage | Who | Notes |
+|---|---|---|
+| DISCOVERY | `ai-indexer` then `ai-discovery` | where the feature lands, what it will touch |
+| CONTEXT | `ai-context` | the structured summary everything downstream reads |
+| IMPACT ANALYSIS | `ai-discovery` (second pass) | callers, data, contracts, other environments |
+| RISK CLASSIFICATION | `ai-risk` | one tier, from `policies/risk-tiers.json` |
+| PLAN | `ai-planner` | steps with `allowed_files`; STRONG for T3/T4, `ai-expert` for T5 |
+| PLAN REVIEW | `ai-reviewer` | T3 and above |
+| IMPLEMENTATION | the session, one step at a time | scope-guarded |
+| TEST | `ai-tester` | after every step, not only at the end |
+| ADVERSARIAL REVIEW | `ai-reviewer` | T2 and above |
+| SECURITY REVIEW | `ai-security` | T4, T5, and anything touching auth or personal data |
+| RELEASE REPORT | `ai-release` | full report from T2 up |
+| HUMAN APPROVAL | the human | the pipeline stops here |
+
+## Specific to this workflow
+
+- The plan states what stays the same, not only what changes. A feature that
+  quietly alters an existing behaviour is the most common source of regressions.
+- New code paths need their negative cases tested: not authorized, not found,
+  invalid input, external system down.
+- If the feature needs a new dependency, that is a decision worth its own line in
+  the plan.

package/skills/project-update/history/blobs/0aeb04b04262683cac6513545683486a73dc473b447bba43b5aaab18403957a6

@@ -0,0 +1,34 @@
+# Manager
+
+The manager is the main session, not a subagent. It orchestrates; it does not
+collect facts itself, and it keeps its own context small so it can stay in the
+task until the end.
+
+## Responsibilities
+
+- Understand the request and restate it in one sentence the human can correct.
+- Classify the task: which workflow, which risk tier.
+- Establish scope, and defend it.
+- Choose the stages the tier requires, and the agent for each.
+- Delegate every reading and analysis stage. Never read logs, test output or
+  large files into its own context.
+- Split the work into steps small enough that each one names the files it touches.
+- Track state through `state.py` after every stage. The state file, not the
+  conversation, is what survives.
+- Decide when to escalate a model tier, one task at a time, against the triggers
+  in `policies/risk-tiers.json`.
+- Write the final summary the human reads.
+
+## What the manager must not do
+
+- Skip a stage because the task looks easy. Make it lightweight instead, and
+  record that it happened.
+- Expand scope. A discovered problem goes into `project/known-risks.md`.
+- Delegate the conclusion. The synthesis a human reads is written by the session.
+- Commit, push, merge or deploy. The pipeline ends at human approval.
+
+## Implementation
+
+The manager implements approved steps itself, under this policy and under
+`ai-scope-guard`. `ai-implementer` exists for mechanical, pattern-copying steps
+and for when the human asks for it — not as the default.

package/skills/project-update/history/blobs/0ce913a28996f546f72d570b0e5a376362e993ce4d805bc4aae57d38caa44212

@@ -0,0 +1,41 @@
+# Workflow: refactoring
+
+Changing the shape of code without changing what it does. The most dangerous
+workflow in a legacy codebase, because success is invisible.
+
+> Who runs a stage is set by `pipeline_profile` in `policies/risk-tiers.json`.
+> The table names the agent for when a stage is delegated. In the default `solo`
+> profile T0–T2 run in direct mode — the session does every stage itself, in a
+> few lines, with cheap readers and one `sonnet` review at T2 — and T3+ run the
+> full pipeline with the delegations below.
+
+| Stage | Who | Notes |
+|---|---|---|
+| DISCOVERY | `ai-discovery` | every caller, every test, every dynamic reference |
+| CONTEXT | `ai-context` | with `legacy_constraints` filled properly |
+| IMPACT ANALYSIS | `ai-discovery` | serialized data, cache keys, service ids, event names |
+| RISK CLASSIFICATION | `ai-risk` | shared code is T3 minimum |
+| PLAN | `ai-planner` | characterization tests as their own steps, before anything moves |
+| PLAN REVIEW | `ai-reviewer` | always, whatever the tier |
+| IMPLEMENTATION | the session | one mechanical transformation per step |
+| TEST | the session (`ai-tester` in `team`) | the same tests, unchanged, must still pass — the characterization tests for the moved code run inside their step, the full suite once at the end, then the e2e suite once; failures fixed as one batch |
+| ADVERSARIAL REVIEW | `ai-reviewer` | looking specifically for behaviour drift |
+| RELEASE REPORT | `ai-release` | |
+| HUMAN APPROVAL | the human | |
+
+## The order, which is not negotiable
+
+```
+characterization test → refactor → verify identical behaviour → (a different task) feature change
+```
+
+## Rules
+
+- **Never** combine a refactoring with a feature change. If the plan contains
+  both, it is two tasks.
+- A test that has to be modified during a refactoring is a signal that behaviour
+  changed. Stop and say so.
+- Renaming something that appears in a string — a service id, a template name, a
+  queue name, a route name, a column — is not a rename, it is a migration.
+- If the only justification is "this is cleaner", the task needs a human to
+  confirm it is worth the risk before it starts.

package/skills/project-update/history/blobs/0ea9e36446b624b73b2a821231b2ee66a357b43d584a5b23da48b3c800855e65

@@ -0,0 +1,41 @@
+# Workflow: refactoring
+
+Changing the shape of code without changing what it does. The most dangerous
+workflow in a legacy codebase, because success is invisible.
+
+> Who runs a stage is set by `pipeline_profile` in `policies/risk-tiers.json`.
+> The table names the agent for when a stage is delegated. In the default `solo`
+> profile T0–T2 run in direct mode — the session does every stage itself, in a
+> few lines, with cheap readers and one `sonnet` review at T2 — and T3+ run the
+> full pipeline with the delegations below.
+
+| Stage | Who | Notes |
+|---|---|---|
+| DISCOVERY | `ai-discovery` | every caller, every test, every dynamic reference |
+| CONTEXT | `ai-context` | with `legacy_constraints` filled properly |
+| IMPACT ANALYSIS | `ai-discovery` | serialized data, cache keys, service ids, event names |
+| RISK CLASSIFICATION | `ai-risk` | shared code is T3 minimum |
+| PLAN | `ai-planner` | characterization tests as their own steps, before anything moves |
+| PLAN REVIEW | `ai-reviewer` | always, whatever the tier |
+| IMPLEMENTATION | the session | one mechanical transformation per step |
+| TEST | the session (`ai-tester` in `team`) | the same tests, unchanged, must still pass; one full run at the end, failures fixed as one batch |
+| ADVERSARIAL REVIEW | `ai-reviewer` | looking specifically for behaviour drift |
+| RELEASE REPORT | `ai-release` | |
+| HUMAN APPROVAL | the human | |
+
+## The order, which is not negotiable
+
+```
+characterization test → refactor → verify identical behaviour → (a different task) feature change
+```
+
+## Rules
+
+- **Never** combine a refactoring with a feature change. If the plan contains
+  both, it is two tasks.
+- A test that has to be modified during a refactoring is a signal that behaviour
+  changed. Stop and say so.
+- Renaming something that appears in a string — a service id, a template name, a
+  queue name, a route name, a column — is not a rename, it is a migration.
+- If the only justification is "this is cleaner", the task needs a human to
+  confirm it is worth the risk before it starts.

package/skills/project-update/history/blobs/0fb1d68678a1349195b2e79433bb20174d25874e3bfd0b70410bb4e428b4e4b8

@@ -0,0 +1,35 @@
+# Workflow: hotfix
+
+Production is broken now. Stages get shorter; none of them disappears.
+
+> Who runs a stage is set by `pipeline_profile` in `policies/risk-tiers.json`.
+> The table names the agent for when a stage is delegated. In the default `solo`
+> profile T0–T3 run in direct mode — the session does every stage itself, in a
+> few lines, with cheap readers and one review (BALANCED at T2; STRONG at T3,
+> whose plan the human approves in plan mode) — and T4+ run the full pipeline
+> with the delegations below.
+
+| Stage | Who | Notes |
+|---|---|---|
+| DISCOVERY | `ai-discovery` | narrow: the failing path only |
+| CONTEXT | the session, inline | a paragraph, recorded in the state file |
+| RISK CLASSIFICATION | `ai-risk` | the tier of the code being touched, not of the urgency |
+| PLAN | `ai-planner` or the session | the smallest change that stops the bleeding |
+| IMPLEMENTATION | the session | one step |
+| TEST | the session (`ai-tester` in `team`) | at minimum, a test that reproduces the incident, run scoped; the full command once after the fix, then e2e only if the incident is in a flow it covers; failures fixed as one batch |
+| ADVERSARIAL REVIEW | `ai-reviewer` | short, focused on "what else does this touch" |
+| SECURITY REVIEW | `ai-security` | if the incident is a security incident |
+| RELEASE REPORT | `ai-release` | short form, but rollback is mandatory |
+| HUMAN APPROVAL | the human | always, and usually faster than the rest |
+
+## Rules
+
+- Urgency lowers the *depth* of a stage, never its existence. The risk tier is a
+  property of the code, not of how loudly someone is asking.
+- A hotfix is the smallest possible change. Everything else — the real fix, the
+  cleanup, the missing test — becomes a follow-up task, written down before the
+  hotfix is approved so it does not evaporate when the incident closes.
+- Record what actually happened in `project/known-risks.md`: the trigger, the
+  detection, and what would have caught it earlier.
+- Never disable a test or a check to get a hotfix out. If CI is the obstacle, a
+  human decides that, explicitly.

package/skills/project-update/history/blobs/119b2b9d0f9c647a243540724edac6b29afa020c69aa205797bcfa9eb06bc021

@@ -0,0 +1,35 @@
+# Workflow: bugfix
+
+Something behaves wrongly. The goal is the smallest change that fixes it without
+changing anything else.
+
+> Who runs a stage is set by `pipeline_profile` in `policies/risk-tiers.json`.
+> The table names the agent for when a stage is delegated. In the default `solo`
+> profile T0–T2 run in direct mode — the session does every stage itself, in a
+> few lines, with cheap readers and one BALANCED review at T2 — and T3+ run the
+> full pipeline with the delegations below.
+
+| Stage | Who | Notes |
+|---|---|---|
+| DISCOVERY | `ai-discovery` | reproduce first: find the exact path that produces the symptom |
+| CONTEXT | `ai-context` | include the *correct* behaviour and where it is defined |
+| IMPACT ANALYSIS | `ai-discovery` | who else depends on the current, wrong behaviour |
+| RISK CLASSIFICATION | `ai-risk` | a bug in a payment path is still T4 |
+| PLAN | `ai-planner` | failing test first, then the fix |
+| IMPLEMENTATION | the session | the failing test is its own step |
+| TEST | the session (`ai-tester` in `team`) | the new test is shown failing before the fix; each step runs only its own scoped tests; the full verification command runs once after the last step, to the end, then the e2e suite once; every failure fixed as one batch |
+| ADVERSARIAL REVIEW | `ai-reviewer` | T2 and above |
+| SECURITY REVIEW | `ai-security` | if the bug was a security bug, always |
+| RELEASE REPORT | `ai-release` | |
+| HUMAN APPROVAL | the human | |
+
+## Specific to this workflow
+
+- **Write the failing test first.** A bugfix without a test that failed before it
+  is a bugfix nobody can prove.
+- Find out *why* the bug exists before fixing it. A bug that is deliberate
+  behaviour somebody depends on is not a bug; it is a requirements conflict, and
+  it goes back to the human.
+- Resist the urge to fix the surrounding code. Note it, fix the bug.
+- If the same bug exists in three places, fix the one that was reported and list
+  the other two in `project/known-risks.md`.

package/skills/project-update/history/blobs/1d0fe3ee5fb8260ba610942d4bbdfff7410fbe80ed826ac07f32985031dc2b3f

@@ -0,0 +1,34 @@
+# Workflow: hotfix
+
+Production is broken now. Stages get shorter; none of them disappears.
+
+> Who runs a stage is set by `pipeline_profile` in `policies/risk-tiers.json`.
+> The table names the agent for when a stage is delegated. In the default `solo`
+> profile T0–T2 run in direct mode — the session does every stage itself, in a
+> few lines, with cheap readers and one BALANCED review at T2 — and T3+ run the
+> full pipeline with the delegations below.
+
+| Stage | Who | Notes |
+|---|---|---|
+| DISCOVERY | `ai-discovery` | narrow: the failing path only |
+| CONTEXT | the session, inline | a paragraph, recorded in the state file |
+| RISK CLASSIFICATION | `ai-risk` | the tier of the code being touched, not of the urgency |
+| PLAN | `ai-planner` or the session | the smallest change that stops the bleeding |
+| IMPLEMENTATION | the session | one step |
+| TEST | the session (`ai-tester` in `team`) | at minimum, a test that reproduces the incident, run scoped; the full command once after the fix, then e2e only if the incident is in a flow it covers; failures fixed as one batch |
+| ADVERSARIAL REVIEW | `ai-reviewer` | short, focused on "what else does this touch" |
+| SECURITY REVIEW | `ai-security` | if the incident is a security incident |
+| RELEASE REPORT | `ai-release` | short form, but rollback is mandatory |
+| HUMAN APPROVAL | the human | always, and usually faster than the rest |
+
+## Rules
+
+- Urgency lowers the *depth* of a stage, never its existence. The risk tier is a
+  property of the code, not of how loudly someone is asking.
+- A hotfix is the smallest possible change. Everything else — the real fix, the
+  cleanup, the missing test — becomes a follow-up task, written down before the
+  hotfix is approved so it does not evaporate when the incident closes.
+- Record what actually happened in `project/known-risks.md`: the trigger, the
+  detection, and what would have caught it earlier.
+- Never disable a test or a check to get a hotfix out. If CI is the obstacle, a
+  human decides that, explicitly.

package/skills/project-update/history/blobs/1de9a37ed6402893dcab6e61ddbf15ffd35f15a6d84b18e675a0c5bf4e981f85

@@ -0,0 +1,42 @@
+# Workflow: refactoring
+
+Changing the shape of code without changing what it does. The most dangerous
+workflow in a legacy codebase, because success is invisible.
+
+> Who runs a stage is set by `pipeline_profile` in `policies/risk-tiers.json`.
+> The table names the agent for when a stage is delegated. In the default `solo`
+> profile T0–T4 run in direct mode — the session does every stage itself, in a
+> few lines, with cheap readers and one review (BALANCED at T2/T3, and only
+> when a sensor is red; STRONG at T4, whose plan the human approves in plan
+> mode) — and T5+ run the full pipeline with the delegations below.
+
+| Stage | Who | Notes |
+|---|---|---|
+| DISCOVERY | `ai-discovery` | every caller, every test, every dynamic reference |
+| CONTEXT | `ai-context` | with `legacy_constraints` filled properly |
+| IMPACT ANALYSIS | `ai-discovery` | serialized data, cache keys, service ids, event names |
+| RISK CLASSIFICATION | `ai-risk` | shared code is T4 minimum |
+| PLAN | `ai-planner` | characterization tests as their own steps, before anything moves |
+| PLAN REVIEW | `ai-reviewer` | always, whatever the tier |
+| IMPLEMENTATION | the session | one mechanical transformation per step |
+| TEST | the session (`ai-tester` in `team`) | the same tests, unchanged, must still pass — the characterization tests for the moved code run inside their step, the full suite once at the end, then the e2e suite once; failures fixed as one batch |
+| ADVERSARIAL REVIEW | `ai-reviewer` | looking specifically for behaviour drift |
+| RELEASE REPORT | `ai-release` | |
+| HUMAN APPROVAL | the human | |
+
+## The order, which is not negotiable
+
+```
+characterization test → refactor → verify identical behaviour → (a different task) feature change
+```
+
+## Rules
+
+- **Never** combine a refactoring with a feature change. If the plan contains
+  both, it is two tasks.
+- A test that has to be modified during a refactoring is a signal that behaviour
+  changed. Stop and say so.
+- Renaming something that appears in a string — a service id, a template name, a
+  queue name, a route name, a column — is not a rename, it is a migration.
+- If the only justification is "this is cleaner", the task needs a human to
+  confirm it is worth the risk before it starts.

package/skills/project-update/history/blobs/1f44e1a236233dcbab58064f39b69f798b35d1d9a29f8c615b5b12854ce633cb

@@ -0,0 +1,15 @@
+# Constitution — {{PROJECT}}
+
+<!-- The 10–15 principles this project does not negotiate, one line each, numbered C1…;
+     /rr-spec and the planner cite them. Under 15: what is not here lives in .ai/policies/. -->
+
+C1. Production behaviour is the source of truth; what looks wrong may be load-bearing.
+C2. A bugfix starts with the failing test; legacy behaviour gets a characterization test before it changes.
+C3. A refactoring changes no behaviour and is never mixed with a feature.
+C4. Every step names its files; scope grows only by amending the plan.
+C5. No agent merges or deploys; an agent commits, pushes or approves only by running, verbatim and once, a command a human picked in the dialog, as the harness recorded; else a human runs it outside.
+C6. <!-- project principle — filled by /rr-setup from the survey, confirmed by you -->
+C7. <!-- project principle -->
+C8. <!-- project principle -->
+C9. <!-- project principle -->
+C10. <!-- project principle -->

package/skills/project-update/history/blobs/1f824645299579cbdd8141642ddbb4bca9fd5fe9d3112f036d8221f0811e0abf

@@ -0,0 +1,40 @@
+# Workflow: refactoring
+
+Changing the shape of code without changing what it does. The most dangerous
+workflow in a legacy codebase, because success is invisible.
+
+> Who runs a stage is set by `pipeline_profile` in `policies/risk-tiers.json`.
+> The table names the agent for when a stage is delegated; in the default `solo`
+> profile the session does the stage inline up to the tier where the profile
+> delegates it.
+
+| Stage | Who | Notes |
+|---|---|---|
+| DISCOVERY | `ai-discovery` | every caller, every test, every dynamic reference |
+| CONTEXT | `ai-context` | with `legacy_constraints` filled properly |
+| IMPACT ANALYSIS | `ai-discovery` | serialized data, cache keys, service ids, event names |
+| RISK CLASSIFICATION | `ai-risk` | shared code is T3 minimum |
+| PLAN | `ai-planner` | characterization tests as their own steps, before anything moves |
+| PLAN REVIEW | `ai-reviewer` | always, whatever the tier |
+| IMPLEMENTATION | the session | one mechanical transformation per step |
+| TEST | `ai-tester` | the same tests, unchanged, must still pass |
+| ADVERSARIAL REVIEW | `ai-reviewer` | looking specifically for behaviour drift |
+| RELEASE REPORT | `ai-release` | |
+| HUMAN APPROVAL | the human | |
+
+## The order, which is not negotiable
+
+```
+characterization test → refactor → verify identical behaviour → (a different task) feature change
+```
+
+## Rules
+
+- **Never** combine a refactoring with a feature change. If the plan contains
+  both, it is two tasks.
+- A test that has to be modified during a refactoring is a signal that behaviour
+  changed. Stop and say so.
+- Renaming something that appears in a string — a service id, a template name, a
+  queue name, a route name, a column — is not a rename, it is a migration.
+- If the only justification is "this is cleaner", the task needs a human to
+  confirm it is worth the risk before it starts.

package/skills/project-update/history/blobs/235fb88393cfe20dd58b35fe9785cc45baf5ffe21a13d926652d76ec68cea8b7

@@ -0,0 +1,35 @@
+# Workflow: bugfix
+
+Something behaves wrongly. The goal is the smallest change that fixes it without
+changing anything else.
+
+> Who runs a stage is set by `pipeline_profile` in `policies/risk-tiers.json`.
+> The table names the agent for when a stage is delegated. In the default `solo`
+> profile T0–T2 run in direct mode — the session does every stage itself, in a
+> few lines, with cheap readers and one `sonnet` review at T2 — and T3+ run the
+> full pipeline with the delegations below.
+
+| Stage | Who | Notes |
+|---|---|---|
+| DISCOVERY | `ai-discovery` | reproduce first: find the exact path that produces the symptom |
+| CONTEXT | `ai-context` | include the *correct* behaviour and where it is defined |
+| IMPACT ANALYSIS | `ai-discovery` | who else depends on the current, wrong behaviour |
+| RISK CLASSIFICATION | `ai-risk` | a bug in a payment path is still T4 |
+| PLAN | `ai-planner` | failing test first, then the fix |
+| IMPLEMENTATION | the session | the failing test is its own step |
+| TEST | the session (`ai-tester` in `team`) | the new test is shown failing before the fix; each step runs only its own scoped tests; the full verification command runs once after the last step, to the end, then the e2e suite once; every failure fixed as one batch |
+| ADVERSARIAL REVIEW | `ai-reviewer` | T2 and above |
+| SECURITY REVIEW | `ai-security` | if the bug was a security bug, always |
+| RELEASE REPORT | `ai-release` | |
+| HUMAN APPROVAL | the human | |
+
+## Specific to this workflow
+
+- **Write the failing test first.** A bugfix without a test that failed before it
+  is a bugfix nobody can prove.
+- Find out *why* the bug exists before fixing it. A bug that is deliberate
+  behaviour somebody depends on is not a bug; it is a requirements conflict, and
+  it goes back to the human.
+- Resist the urge to fix the surrounding code. Note it, fix the bug.
+- If the same bug exists in three places, fix the one that was reported and list
+  the other two in `project/known-risks.md`.

package/skills/project-update/history/blobs/3918b4ee011d9477b9d2779e2893ab599749c406d4b09439a9748b64fbff58f3

@@ -0,0 +1,18 @@
+# Verification — this project's commands
+<!-- Yours. Read by state.py verify and close, setup.py check, update.py hints; /rr-setup --update never rewrites it.
+     Each line is `field: value`; a line left empty reads as "not written down yet", `none` says the project has none.
+     What each command must do is in policies/testing.md (Verification). -->
+
+verify_command:      # the full fast suite, e2e excluded, no fail-fast — e.g. make test | composer qa && vendor/bin/phpunit --exclude-group e2e
+step_test_command:   # the same runner scoped to a path or filter, `{files}` replaced by the step's paths — e.g. vendor/bin/phpunit {files} | pytest {files}
+e2e_command:         # the end-to-end suite, run once at the end of a task — e.g. make e2e | vendor/bin/behat | npx playwright test — `none` if the project has none
+lint_command:        # e.g. vendor/bin/php-cs-fixer fix --dry-run | ruff check . | npm run lint — `none` if the project has none
+typecheck_command:   # e.g. vendor/bin/phpstan analyse --no-progress | mypy . | npx tsc --noEmit — `none` if the project has none
+single_test:         # how to run one test, for the failing-test-first step of a bugfix
+doc_tests:           # the suites a documents-only edit runs after a green suite — e.g. tests/test_docs.py; `none` if the project has none
+bite_codes:          # exit codes that mean "a test failed" (default 1) — e.g. 1,2 for pytest and phpunit, 101 for cargo
+healthy_output:      # two or three lines of what a green run ends with
+
+## Project specifics
+
+<!-- How to run unit tests, integration tests, a single test. Where fixtures live. What the CI runs. Cite the config. -->

package/skills/project-update/history/blobs/449273200dfec2a56885c881ff34d40e8ecc00da53c24c2d09b7fbeb1004d255

@@ -0,0 +1,40 @@
+# Architecture
+
+<!-- Filled by /rr-setup. Describe what the code does, not what the framework's
+     documentation says it should do. -->
+
+## Style
+
+<!-- Layered, hexagonal, modular monolith, service-oriented, or — most often —
+     several of these in different parts of the code. Say which is where. -->
+
+## Entry points
+
+<!-- HTTP routes, console commands, message consumers, cron jobs, webhooks.
+     KNOWN FACT with the file that defines each. -->
+
+## Request and message flow
+
+<!-- One paragraph per major flow: what comes in, what it touches, what it
+     writes, what goes out. -->
+
+## Module boundaries
+
+<!-- Where the seams are, and where they leak. -->
+
+## Where state lives
+
+<!-- Database, cache, queue, session, external systems, filesystem. -->
+
+## Cross-cutting mechanisms
+
+<!-- Events, the command bus, state machines, workflows, the DI container,
+     configuration and how it is layered per environment. -->
+
+## Contradictions found
+
+<!-- Documented behaviour: …
+     Observed behaviour: …
+     Evidence: …
+     Risk: …
+     One block per contradiction. Do not resolve it here. -->

package/skills/project-update/history/blobs/4c45aee9b9fc5f6b4e1d9739e434c4094975a5a8dec6b9703fb25f3080680c77

@@ -0,0 +1,124 @@
+# Testing policy
+
+Tests describe behaviour. Coverage percentage is a side effect, not a goal.
+
+## Characterization first
+
+Before changing behaviour that is not covered by a test — which is most legacy
+behaviour — write a test that passes against the code **as it is today**. That
+test is the definition of what must not break. Only then change the code.
+
+```
+characterization test → refactor → verify identical behaviour → feature change
+```
+
+Never do those in one step, and never in one commit.
+
+## What to consider, by kind of change
+
+| Change touches | Also test |
+|---|---|
+| a shared service | the existing callers, not only the new one |
+| money, tax, fiscal | rounding, currency, negative and zero amounts, refunds |
+| a state machine | every transition that is now reachable, and the ones that must stay unreachable |
+| an async consumer | retry, double delivery, out-of-order delivery, poison message |
+| an external integration | timeout, 500, malformed response, partial write |
+| a write path | idempotency, concurrency, transaction boundaries |
+| authorization | the negative case, for every role |
+| a public API or event | the old shape still works |
+
+## Three scopes, three moments
+
+A task runs tests three times at most, and each run has its own scope. Nothing
+else runs in between.
+
+| When | What runs | Command |
+|---|---|---|
+| after each implementation step, before `step-done` | **only the tests the plan named for that step** — the files it touched, their direct callers' tests | `step_test_command` |
+| once, after the **last** step | the full fast suite — unit and integration, no e2e | `verify_command` |
+| once, at the **end of the task**, after the full suite is green | the end-to-end suite | `e2e_command` |
+
+- A step never runs the full suite, and **never** runs e2e. If the plan named
+  no test for a step, nothing runs for it.
+- A step's tests are scoped by path or filter, not by `--stop-on-failure`: the
+  scoped run still goes to the end, and its failures are fixed inside that step.
+- The e2e suite runs **once per task**, at the very end, never per step. Skip it
+  at T0/T1, and when the change cannot reach a flow the e2e suite covers — say
+  which, in one line; silence is not a verdict.
+- A failure in a step's own tests is fixed in that step, before `step-done`;
+  the batch rule below is for the two end-of-task runs.
+- After a green suite, a documents-only edit runs `doc_tests` (step scope), not the suite.
+
+## Reading a failure
+
+**Run to the end, then fix as one batch.** The verification command runs with
+no fail-fast flag and is never interrupted at the first failure. Collect every
+failure, classify each one, fix all the new regressions in one batch
+(`state.py start --amend` widens the task when a fix needs more files), and run the
+command once more. One failure never
+sends the task back to the start: the plan, the tier and the finished steps
+stand. At most two remediation rounds; a third means the human decides.
+
+Classify before fixing. The four answers are:
+
+- **EXISTING TEST FAILURE** — it failed before this change too. Say so, do not
+  fix it inside this task.
+- **NEW REGRESSION** — this change broke it. Fix the code, not the test.
+- **TEST ENVIRONMENT FAILURE** — database, fixtures, network, container. Say what
+  is missing.
+- **UNKNOWN** — you could not tell. Say what you tried.
+
+A review's MEDIUM and LOW findings are recorded with `state.py memory risk add`, not
+fixed in the task; only a BLOCKER, a HIGH or a regression buys an `--after-fix` run.
+
+**Never edit a test to make it pass when production behaviour changed
+unexpectedly.** A test that suddenly disagrees with the code is evidence, and
+deleting evidence is the worst available option.
+
+## Verification
+
+Three commands, one per scope. `verify_command` proves the project is healthy;
+`step_test_command` proves one step is; `e2e_command` proves the whole flow
+still works. Keep each to one command — chain the pieces in a Makefile or
+composer script if there are several — and make sure none of them stops at the
+first failure (`--stop-on-failure`, `-x`, `--bail`, `failfast` are off).
+
+`verify_command` must **exclude** the e2e suite: it is the fast loop run after
+the last step and again after a remediation batch. `e2e_command` runs once, at
+the end of the task. A bugfix still shows its new failing test first — that one
+test only, through `single_test`.
+
+The commands themselves are written in `policies/verification.md` (`verify_command`,
+`step_test_command`, `e2e_command`, `lint_command`, `typecheck_command`, `single_test`,
+`doc_tests`, `bite_codes`, `healthy_output`): a human fills them in, `state.py` reads them from
+there, and `/rr-setup --update` never rewrites that file.
+
+`step_test_command` may contain `{files}`, which is replaced by the paths the
+step names; without it the paths are appended. The placeholder is what lets
+`sensors.py` run a step's own tests for the "test must bite" check, so a runner
+that only takes a `--filter` gets `bite: unavailable` rather than a wrong answer.
+
+`bite_codes` (optional, in `policies/verification.md`) lists the exit codes that mean "a test failed" when a
+test is shown failing before its fix; the default is `1`. Runners that exit
+differently say so here — `bite_codes: 1,2` for pytest (2 is a collection
+error, such as a missing import), `1,2` for phpunit, `101` for cargo. Any other
+code is the runner's own usage error and does not count as a bite.
+
+`lint_command` and `typecheck_command` are read by the deterministic sensors,
+never by a model. They decide, together with the test run, whether a light-mode change
+can skip its model review (`state.py close` measures them). A **missing** line is
+`unavailable` and keeps the review; only the literal `none`, written by a human,
+says the project has no such tool. Read the exact line from the project's
+config files (`package.json`, `composer.json`, `pyproject.toml`, `Makefile`), and
+never run a command just to find it out.
+
+If the project has no e2e suite, write `e2e_command: none` and say so — an
+empty line is read as "not written down yet" and the next task will go looking
+for it. Say which group, tag or directory marks the e2e tests and how
+`verify_command` excludes them, so a step's scoped run and the fast suite stay
+free of them.
+
+## Project specifics
+
+<!-- The real commands: how to run unit tests, integration tests, a single test.
+     Where fixtures live. What the CI runs. Cite the config. -->