riskrails 3.2.2 → 4.1.0

package/skills/project-update/history/blobs/7bcdf9a0e6b85277b9b60669150224b9414d2e32821ff06f4d148eb1d18785bb

@@ -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–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` | 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/7f834103e9d97aea44e76717bcdcbbe349c560e5b81a42ce85a1cec341041281

@@ -0,0 +1,4 @@
+{
+  "version": 1,
+  "_comment": "Yours. weight.py lays it over the plugin's weight table: objects merge, any other value replaces. /rr-setup --update never rewrites it."
+}

package/skills/project-update/history/blobs/7fb3acb0211818efebc2234863db0b8c846022a7280a6d2d69f267dbf63db48c

@@ -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 `sonnet` 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; the full command once, 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/87f0855859ff68cc6c988cc0b631ee7f56af7fbba062172bf80e01f4982cc054

@@ -0,0 +1,35 @@
+# Workflow: refactoring
+
+Changing the shape of code without changing what it does. The most dangerous
+workflow in a legacy codebase, because success is invisible.
+
+| 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/8abab74759766d02b5cb7b0c3e59a3d440b25a454216cd8fea325c23fd822d36

@@ -0,0 +1,33 @@
+# Workflow: investigation
+
+A question, not a change. "Why does this happen?", "where is this handled?",
+"can we do X?". The deliverable is an answer with evidence.
+
+> 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-indexer`, then `ai-discovery` in parallel per area | read-only |
+| CONTEXT | `ai-context` | the structured summary is often the deliverable itself |
+| IMPACT ANALYSIS | `ai-discovery` | only if the question is "what would it take to…" |
+| RISK CLASSIFICATION | `ai-risk` | so the answer carries the tier a change would have |
+| REPORT | the session | written by the main session, not delegated |
+
+There is no implementation stage. If the investigation concludes that something
+should change, that is a **new task** with its own intent, plan and approval.
+
+## Rules
+
+- Nothing is edited. Not a comment, not a formatting fix.
+- Every claim in the answer is labelled and cited: KNOWN FACT with `file:line`,
+  INFERENCE with what it rests on, UNKNOWN with what would settle it.
+- Contradictions between documentation and code are reported as both, not
+  resolved by preference.
+- Findings worth acting on go into `project/known-risks.md` so the next task can
+  see them.
+- Say what you could not determine. An investigation that hides its gaps is worse
+  than one that admits them.

package/skills/project-update/history/blobs/8ec171f0fbdf38cc6996d496f01491fd1f21f04a435a118ad979b127a8be06f1

@@ -0,0 +1,85 @@
+# Safety policy
+
+This is the file every agent reads first. It is short on purpose. It binds every
+agent in every runtime — Claude Code and Codex alike.
+
+## The one rule
+
+**Production behaviour is the source of truth until proven otherwise.** Code that
+looks wrong, dead, or badly written may be load-bearing. The repository's history
+is evidence; your intuition about how the code "should" look is not.
+
+## What an agent must never do
+
+- Change application code that the current task did not ask about.
+- Rename, move, reorganise or "clean up" anything as a side effect.
+- Remove code because it looks unused. Find the callers first; if there are none,
+  say so in the report and leave the code alone.
+- Combine a refactoring with a feature change in the same step.
+- Modify database schemas, dependencies or framework versions outside a task that
+  is explicitly about that.
+- Weaken a test, a linter rule or a static-analysis level to make a check pass.
+- Commit, push, merge or deploy on its own initiative.
+- Read production secrets or customer data into the model context.
+
+If you find a problem outside the current task: **write it down, do not fix it.**
+Unrelated findings are recorded with `state.py memory risk add` (in files mode it
+writes `.ai/project/known-risks.md`) or go into the report's "observations"
+section, and the human decides whether they become their own task.
+
+The compact record is the human's to switch: `state.py memory enable`, `disable`,
+`cleanup`, `pack`, `redact` and `migrate --move-logs` take the human route, as
+`approve` does. `enable` may also run as the command the human picked in the
+`/rr-setup` dialog; the rest have no dialog route. `.ai/memory/` and
+`.ai/local/memory/` are written by `state.py` alone — an agent never edits them
+(`state.py memory --help`; the plugin's `docs/local-memory.md`).
+
+## Scope
+
+Every implementation step names the files it may touch. Editing anything else is
+refused by `ai-scope-guard` and must be answered with `SCOPE_CHANGE_REQUIRED`:
+stop, say which file you need and why, and let the plan be amended. A step whose
+scope keeps growing is a step that was planned wrong.
+
+`ai-git-guard`, `ai-path-guard` and `ai-scope-guard` all run in both runtimes. A
+multi-file edit in one call — Codex's `apply_patch` — is checked path by path, so
+a single out-of-scope or protected file rejects the whole patch. What a guard
+refuses is not a hint: do not reword the command to get past it.
+
+A guard is a backstop, not the policy. Some checks exist in only one runtime —
+Codex has no hookable read tool, so the large-read cap is Claude-only there — and
+an agent that behaves correctly only because a hook is watching is not behaving
+correctly. The rules above hold whether or not a hook enforces them.
+
+**The guards' threat model.** The guards defend against an agent's mistakes — a
+careless `rm`, a write to a frozen policy during a task, a commit with a
+secret — not against an agent that constructs a command to exhaust them. A
+command built to time the guard out is visible in the transcript and in the
+journal, and the human gate in full and full_irreversible mode is the boundary
+for anything that matters.
+Approval rests on a guard plus a ledger: a command the agent constructs to pass
+for the human's pick is outside the threat model, and `state.py consent audit`
+detects it afterwards.
+
+## Evidence labels
+
+Anything an agent writes into `.ai/project/` carries one of four labels:
+
+- **KNOWN FACT** — read from the code, a config file, a migration or a test.
+  Cite `file:line`.
+- **INFERENCE** — a conclusion drawn from facts. Say what it is drawn from.
+- **UNKNOWN** — something that matters and could not be determined. Say what
+  would answer it.
+- **RISK** — something that looks dangerous. Say what could go wrong.
+
+Never present an inference as a fact. When documentation and code disagree,
+record both under "Documented behaviour" and "Observed behaviour", with the
+evidence for each, and let the human decide which is the bug.
+
+## When in doubt
+
+Stop and ask. An agent that pauses costs a message; an agent that guesses on a
+payment path costs an incident.
+
+Doubt on reversibility or domain is a blocker; other doubt is written to
+`task.md` and the work continues.

package/skills/project-update/history/blobs/a1fb50e6c86fae1679ef3351296fd6713411a08cf8dd1790a4fd05fae8688164

@@ -0,0 +1 @@
+12

package/skills/project-update/history/blobs/a3df7268feb0780be0d2cf9acced6ed81780a7790f36fe024b6ea0b1bd6eb7a6

@@ -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; the full verification command runs once at the end, to the end; 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/b28721136482dafb9fd2801af340364cb97e9f6eaa987908606c786045b8d334

@@ -0,0 +1,28 @@
+# Workflow: hotfix
+
+Production is broken now. Stages get shorter; none of them disappears.
+
+| 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 | `ai-tester` | at minimum, a test that reproduces the incident |
+| 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/b3726422d767f9219fea633bea77f0c99ad9af843c591e6e928e1ccd2a47f374

@@ -0,0 +1,27 @@
+# Workflow: investigation
+
+A question, not a change. "Why does this happen?", "where is this handled?",
+"can we do X?". The deliverable is an answer with evidence.
+
+| Stage | Who | Notes |
+|---|---|---|
+| DISCOVERY | `ai-indexer`, then `ai-discovery` in parallel per area | read-only |
+| CONTEXT | `ai-context` | the structured summary is often the deliverable itself |
+| IMPACT ANALYSIS | `ai-discovery` | only if the question is "what would it take to…" |
+| RISK CLASSIFICATION | `ai-risk` | so the answer carries the tier a change would have |
+| REPORT | the session | written by the main session, not delegated |
+
+There is no implementation stage. If the investigation concludes that something
+should change, that is a **new task** with its own intent, plan and approval.
+
+## Rules
+
+- Nothing is edited. Not a comment, not a formatting fix.
+- Every claim in the answer is labelled and cited: KNOWN FACT with `file:line`,
+  INFERENCE with what it rests on, UNKNOWN with what would settle it.
+- Contradictions between documentation and code are reported as both, not
+  resolved by preference.
+- Findings worth acting on go into `project/known-risks.md` so the next task can
+  see them.
+- Say what you could not determine. An investigation that hides its gaps is worse
+  than one that admits them.

package/skills/project-update/history/blobs/b3839425f9d0ab2efa42a6f5e9488ec2d26ca5fb8dcd694b8ab098e10743ca46

@@ -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 | none at T0/T1; the session at T2; `ai-planner` from T3 | 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 | the session (`ai-tester` in `team`) | once, after the last step; a step's own single test when cheap |
+| 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/ba14a457e83f9dde65e4190fdfab83b912f7398c1442a2a1cb3d89bfac741cf3

@@ -0,0 +1,8 @@
+# Initial assessment
+
+<!-- Written once by /rr-setup, then kept as a snapshot. It records what the
+     repository looked like when this infrastructure was installed, so later
+     drift is visible. Do not edit it into a living document — that is what the
+     other files in this directory are. -->
+
+*Not yet generated. Run `/rr-setup` in the project root.*

package/skills/project-update/history/blobs/bceb7189444bb6291b262ca08e34db01010dda2f6e64d696231ec3c343c95c66

@@ -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 `sonnet` 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/bf82a2bb4fce1bd349ff66118930a01d61a7af8e2bd8d200c721d43afc58c713

@@ -0,0 +1,34 @@
+# Workflow: investigation
+
+A question, not a change. "Why does this happen?", "where is this handled?",
+"can we do X?". The deliverable is an answer with evidence.
+
+> 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-indexer`, then `ai-discovery` in parallel per area | read-only |
+| CONTEXT | `ai-context` | the structured summary is often the deliverable itself |
+| IMPACT ANALYSIS | `ai-discovery` | only if the question is "what would it take to…" |
+| RISK CLASSIFICATION | `ai-risk` | so the answer carries the tier a change would have |
+| REPORT | the session | written by the main session, not delegated |
+
+There is no implementation stage. If the investigation concludes that something
+should change, that is a **new task** with its own intent, plan and approval.
+
+## Rules
+
+- Nothing is edited. Not a comment, not a formatting fix.
+- Every claim in the answer is labelled and cited: KNOWN FACT with `file:line`,
+  INFERENCE with what it rests on, UNKNOWN with what would settle it.
+- Contradictions between documentation and code are reported as both, not
+  resolved by preference.
+- Findings worth acting on go into `project/known-risks.md` so the next task can
+  see them.
+- Say what you could not determine. An investigation that hides its gaps is worse
+  than one that admits them.

package/skills/project-update/history/blobs/c4dbeb180292a6199ad73a3be861ece07c1f8bf6bf0cc7ca204412bc8e1bb1d8

@@ -0,0 +1,31 @@
+# Weight table
+
+<!-- generated by `state.py weight --mirror` from weight.json; edit the JSON and regenerate. sha256: 6d6dee8634abf9ac057bb206828b83a893a2afcf4f86bbe69e839a3b47d0adde -->
+
+Six axes, 0–2 each; W is their sum. Why each rule is what it is: the plugin's `docs/weight.md`.
+
+| Axis | Measured by | Table |
+|---|---|---|
+| scope | references | bands: [0, 5]; hot_paths: ["hooks/**", "src/Shared/**"] |
+| behaviour | session | keywords: ["workflow", "transition", "state machine", "messenger", "queue", "async", "transaction"] |
+| reversibility | paths+content | needs_step: ["**/migrations/**", "**/Migrations/**", "config/**", "k8s/**", "**/env/**"]; irreversible: ["**/prod/**", "**/production/**", "deploy/**", "**/*.deploy.*"]; irreversible_content: ["DROP ", "TRUNCATE", "DELETE FROM", "ALTER .* DROP", "RENAME"] |
+| domain | modules+session | modules: ["**/Payment/**", "**/Tax/**", "**/Invoice/**", "**/Security/**", "**/account/**"]; customer_visible: ["templates/**", "**/Shop/**", "**/Resources/views/**"] |
+| novelty | session | manifests: ["composer.json", "requirements*.txt", "package.json", "pyproject.toml", "Gemfile"] |
+| coverage | tests-map | code_globs: ["**/*.php", "**/*.py", "**/*.js", "**/*.ts", "**/*.sh"]; test_globs: ["tests/**", "spec/**", "**/*Test.php", "**/*.test.*", "**/*.spec.*", "**/test_*.py"]; map: {} |
+
+| Mode | When | Plan | Review | Reviewer | Human stops | Suite |
+|---|---|---|---|---|---|---|
+| light | W ≤ 2 | inline | on_red_fact | BALANCED | 0 | verify |
+| guarded | W ≤ 7 | plan_mode | one | BALANCED | 1 | verify+e2e |
+| full | W ≥ 8 or reversibility or domain = 2 | written | one | STRONG | 2 | verify+e2e |
+| full_irreversible | reversibility=2 and domain=2, or irreversible_content | as full | as full | as full | 3 | as full |
+
+| Hint paths | Axis | Note |
+|---|---|---|
+| `**/login*`, `**/Security/**`, `**/*Auth*` | domain +1 | auth-shaped path |
+| `.ai/policies/**`, `.claude/**`, `.codex/**`, `CLAUDE.md`, `AGENTS.md` | behaviour +1 | pipeline |
+| `composer.json`, `package.json`, `requirements*.txt` | novelty +1 | dependency manifest |
+
+Rules: {"unknown_scores": 1, "hint_raises_by": 1, "hint_raises_once_per_axis": true, "rescore_axes": ["reversibility", "domain"], "rescore_direction": "up", "lower_by": "human", "steps_advice_over": 8}
+
+Budgets: review_rounds_max 2 · remediation_rounds 2 · tests {"max_suite_runs": 2, "timeout_seconds": 1800, "env_retries": 1, "log_max_bytes": 2097152} · batch {"default": false, "review_rounds_max": 3, "max_suite_runs": 8, "parallel": 3, "tier": "BALANCED"}

package/skills/project-update/history/blobs/c644838866df2001a42501a988dd7b77aacf862bf09d22b465f3cd8a22c6b6eb

@@ -0,0 +1,33 @@
+# 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 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-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 | none at T0/T1; the session at T2; `ai-planner` from T3 | 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 | the session (`ai-tester` in `team`) | once, after the last step, to the end; every failure fixed as one batch, then one more run |
+| 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/c980d74f76a4bdfb38c94b573ac10a54eb50b850b052e15fa6f2442889b36ccb

@@ -0,0 +1,32 @@
+# Workflow: investigation
+
+A question, not a change. "Why does this happen?", "where is this handled?",
+"can we do X?". The deliverable is an answer with evidence.
+
+> 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` in parallel per area | read-only |
+| CONTEXT | `ai-context` | the structured summary is often the deliverable itself |
+| IMPACT ANALYSIS | `ai-discovery` | only if the question is "what would it take to…" |
+| RISK CLASSIFICATION | `ai-risk` | so the answer carries the tier a change would have |
+| REPORT | the session | written by the main session, not delegated |
+
+There is no implementation stage. If the investigation concludes that something
+should change, that is a **new task** with its own intent, plan and approval.
+
+## Rules
+
+- Nothing is edited. Not a comment, not a formatting fix.
+- Every claim in the answer is labelled and cited: KNOWN FACT with `file:line`,
+  INFERENCE with what it rests on, UNKNOWN with what would settle it.
+- Contradictions between documentation and code are reported as both, not
+  resolved by preference.
+- Findings worth acting on go into `project/known-risks.md` so the next task can
+  see them.
+- Say what you could not determine. An investigation that hides its gaps is worse
+  than one that admits them.

package/skills/project-update/history/blobs/ceed2f3bd937f862d0e6ca59ce1b1e3603e19a0d7f85d90d6dfeb7bf690153be

@@ -0,0 +1,29 @@
+# Workflow: bugfix
+
+Something behaves wrongly. The goal is the smallest change that fixes it without
+changing anything else.
+
+| 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/d51ea2e893482a20c5882056cf8043327ca1dc1c957927f6746929a47ee8368e

@@ -0,0 +1,45 @@
+# 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.
+
+The role is the same whichever runtime the session is: Claude Code or Codex. The
+agents it delegates to carry the same names in both, and the tier each runs at is
+the same; only the model behind that tier differs.
+
+## 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.
+- Do inline what the pipeline profile leaves inline — in a few lines, recorded
+  in the state file — and delegate the rest. In the `solo` profile the
+  developer's request and `grep -n` are the context for anything up to T2; a
+  subagent is spawned only for what the tier makes mandatory, or on a trigger
+  from `policies/risk-tiers.json`. 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`, and name the trigger when it does.
+- Record, in every artifact, the tier **and the model that actually ran** — see
+  `policies/model-routing.md`. A gate may have moved an agent down a tier, and a
+  Codex agent file may override the model asked for at spawn time.
+- 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.