haiku-method 2.2.0

package/studios/ideation/stages/review/STAGE.md

@@ -0,0 +1,15 @@
+---
+name: review
+description: Adversarial quality review of the deliverable
+hats: [review-planner, synthesizer, reviewer, critic, fact-checker]
+fix_hats: [synthesizer, feedback-assessor]
+review: ask
+elaboration: autonomous
+inputs:
+  - stage: create
+    discovery: draft-deliverable
+---
+
+# Review
+
+Adversarial quality review of the deliverable.

package/studios/ideation/stages/review/discovery/REVIEW-REPORT.md

@@ -0,0 +1,39 @@
+---
+name: review-report
+location: .haiku/intents/{intent-slug}/knowledge/REVIEW-REPORT.md
+scope: intent
+format: text
+required: true
+---
+
+# Review Report
+
+Adversarial review findings for the draft deliverable. This output drives the deliver stage's remediation work.
+
+## Content Guide
+
+Organize findings by severity:
+
+- **Critical** — factual errors, logical fallacies, missing essential content. Must be fixed before delivery.
+- **Major** — structural problems, weak arguments, significant gaps. Should be fixed.
+- **Minor** — clarity issues, style improvements, nice-to-haves. May be fixed.
+
+Each finding should include:
+- Description of the issue
+- Location in the deliverable (section, paragraph)
+- Evidence or reasoning for why it's a problem
+- Suggested remediation
+
+Separate sections for:
+- **Structural issues** — organization, flow, argument structure
+- **Factual issues** — incorrect claims, unverified data, reasoning errors
+- **Completeness gaps** — missing perspectives, unaddressed questions
+
+End with a summary verdict: **approve** (ready for delivery), **revise** (fix critical/major issues then re-review), or **reject** (fundamental problems requiring substantial rework).
+
+## Quality Signals
+
+- Findings are specific enough to act on without re-reading the entire draft
+- Severity ratings reflect actual impact, not reviewer preference
+- Remediation suggestions are concrete, not vague
+- The report distinguishes between "must fix" and "nice to have"

package/studios/ideation/stages/review/hats/critic.md

@@ -0,0 +1,8 @@
+**Focus:** Identify weaknesses, logical gaps, missing perspectives, and structural problems in the draft. The critic's job is to find what's wrong — constructively, with alternatives.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** nitpick style or formatting over substance
+- The agent **MUST NOT** provide only negative feedback without constructive alternatives
+- The agent **MUST NOT** b vague ("this section is weak" without explaining why or how to fix)
+- The agent **MUST NOT** miss forest for trees — focusing on details while ignoring structural problems
+- The agent **MUST NOT** rubber-stamp without genuine critical engagement

package/studios/ideation/stages/review/hats/fact-checker.md

@@ -0,0 +1,8 @@
+**Focus:** Verify claims, check sources, validate reasoning chains, and confirm data accuracy. Trust nothing — trace every claim to its source.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** accept claims at face value because they sound reasonable
+- The agent **MUST NOT** only check easy-to-verify facts while skipping complex reasoning
+- The agent **MUST** trac claims back to primary sources
+- The agent **MUST NOT** conflate "not disproven" with "verified"
+- The agent **MUST NOT** ignore statistical or logical reasoning errors

package/studios/ideation/stages/review/hats/feedback-assessor.md

@@ -0,0 +1,11 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you are a verifier, not a fixer
+- The agent **MUST NOT** close a finding that isn't actually resolved — that is how drift hides
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
+- The agent **MUST NOT** expand the scope beyond the one feedback item you were dispatched against

package/studios/ideation/stages/review/hats/review-planner.md

@@ -0,0 +1,9 @@
+**Focus:** Plan the review for THIS unit. Identify which aspects of the draft deliverable need review (clarity, novelty, evidence, structural integrity, scope, audience fit, etc.) and the criteria each aspect is judged against. You do NOT perform the review — that is the synthesizer's job. You produce a structured review plan the synthesizer follows.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** plan a generic "review for quality" — every aspect MUST be a named, observable property of the deliverable
+- The agent **MUST NOT** plan more aspects than the synthesizer can substantively review in a single bolt
+- The agent **MUST NOT** plan aspects that contradict a recorded Decision (e.g., reviewing for a tone the intent's Decision N explicitly ruled out)
+- The agent **MUST** declare out-of-scope aspects explicitly so the synthesizer doesn't widen the review
+- The agent **MUST NOT** prescribe the conclusions of the review — your job is to plan WHAT gets reviewed, not WHAT the review will say
+- The agent **MUST NOT** delegate criterion definition to the synthesizer — vague criteria mean inconsistent reviews

package/studios/ideation/stages/review/hats/reviewer.md

@@ -0,0 +1,30 @@
+**Focus:** Verify-class hat for the review stage's plan-do-verify front loop. Validate that the synthesizer's body content for THIS unit covers every aspect the review-planner called for, with observations grounded in the draft and severities assigned per the planner's rubric. Body-only verification per architecture §3.4 — frontmatter is workflow engine territory. Adversarial loop (`critic`, `fact-checker`) runs LATER. Your job is to keep half-finished or off-spec reviews out of the adversarial loop.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
+- The agent **MUST NOT** validate against frontmatter schema, `depends_on:` resolution, status-field shape, or any other FM-driven check.
+- The agent **MUST NOT** advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
+- The agent **MUST NOT** reject for stylistic preferences. Substantive gaps only.
+- The agent **MUST** name a specific failed criterion in any rejection.
+- The agent **MUST NOT** invent rules not in this mandate. Stage scope is the contract.
+- The agent **MUST NOT** re-do the review or substitute its own opinion for the synthesizer's findings. You verify coverage and rigor, not conclusions.
+
+## What you check (BODY ONLY)
+
+### 1. Every planned aspect is covered
+For every aspect the review-planner listed in the prior section, the synthesizer's notes MUST contain a corresponding observation block. A skipped aspect — silently or with "skipped, out of time" — is a hard reject.
+
+### 2. Observations cite the draft concretely
+Every observation MUST cite a specific section, paragraph, line range, or quote from the draft. "The introduction is weak" without citing what in the introduction is a reject. "Introduction's claim that 'X is the dominant approach' (paragraph 2) is unsupported" passes.
+
+### 3. Severities follow the planner's rubric
+Every finding's severity (critical / major / minor) MUST be justified by the rubric the review-planner set in the prior section. A "critical" finding without rubric justification is a reject; so is a finding without any severity at all.
+
+### 4. Decision-register consistency
+The synthesizer's findings MUST NOT recommend changes that contradict a recorded Decision. If a finding bumps against a Decision and the synthesizer flagged it, that's fine — but a silent contradiction is a reject. Cite the Decision ID.
+
+### 5. Open questions accounted for
+If the synthesizer flagged open questions, each MUST be explicit and actionable for the planner / human. Vague open questions ("not sure about this section") are a reject — be specific or resolve.
+
+### 6. No scope drift
+The synthesizer MUST NOT have reviewed aspects the planner did not list. If the synthesizer added new aspects without surfacing the scope concern in the body, that's a reject — the planner needs the chance to revise before scope grows.

package/studios/ideation/stages/review/hats/synthesizer.md

@@ -0,0 +1,10 @@
+**Focus:** Perform the review per the review-planner's plan. Read the draft deliverable, the intent's constraints/decisions, and the comparable cases the planner cited. Produce structured review notes that cover every planned aspect against the planned criteria. You do NOT widen scope — if the planner did not call for an aspect, do not introduce it (raise it in the unit body for the planner to revise on the next iteration if you think it matters).
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** review aspects the planner did not call for — raise scope concerns in the unit body, don't act on them
+- The agent **MUST NOT** make findings without citing the specific section / line / paragraph of the draft they refer to
+- The agent **MUST NOT** assign severities arbitrarily — every severity MUST follow the planner's rubric
+- The agent **MUST NOT** rubber-stamp ("looks fine") — every aspect MUST have a substantive observation, even if the conclusion is "passes the criterion"
+- The agent **MUST NOT** introduce conclusions that contradict a recorded Decision — cite the Decision ID if a finding bumps against one
+- The agent **MUST NOT** issue findings that are stylistic preferences dressed up as substance — the criterion is the contract
+- The agent **MUST** flag open questions explicitly rather than guess

package/studios/ideation/stages/review/outputs/REVIEW-FINDINGS.md

@@ -0,0 +1,25 @@
+---
+name: review-findings
+location: .haiku/intents/{intent-slug}/stages/review/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Review Findings
+
+Severity-ranked findings from adversarial quality review with fact-checking results.
+
+## Expected Artifacts
+
+- **Findings** -- severity-ranked issues with actionable fix recommendations
+- **Fact-check results** -- all factual claims classified as verified, unverified, or false
+- **Fix recommendations** -- specific "this is wrong because X, fix by Y" guidance
+- **Verdict** -- approve, revise, or reject with rationale
+
+## Quality Signals
+
+- At least 3 substantive issues are identified with specific remediation suggestions
+- All factual claims are verified against original sources
+- Each finding includes severity rating and actionable fix
+- Verdict is clear with supporting rationale

package/studios/ideation/stages/review/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Review Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Review report identifies at least 3 substantive issues with specific remediation suggestions"
+- "All factual claims are verified against original sources with citations"
+- "Each finding includes severity rating and actionable fix recommendation"
+
+### Bad criteria — vague (no clear check)
+
+- "Review is complete"
+- "Facts are checked"
+- "Feedback is provided"
+

package/studios/ideation/stages/review/review-agents/coherence.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the deliverable is internally consistent and presents a unified narrative.
+
+**Check:**
+- The agent **MUST** verify that terminology is used consistently throughout
+- The agent **MUST** verify that recommendations do not contradict each other
+- The agent **MUST** verify that the executive summary accurately reflects the detailed content
+- The agent **MUST** verify that transitions between sections are logical

package/studios/incident-response/STUDIO.md

@@ -0,0 +1,14 @@
+---
+name: incident-response
+description: Incident response lifecycle from triage through investigation, mitigation, resolution, and postmortem
+stages: [triage, investigate, mitigate, resolve, postmortem]
+category: operations
+default_model: sonnet
+---
+
+# Incident Response Studio
+
+Incident response lifecycle for managing production incidents from initial triage
+through root cause investigation, mitigation, full resolution, and postmortem
+documentation. Optimized for fast response with structured follow-through. Uses
+git persistence because incidents often result in code fixes.

package/studios/incident-response/examples/db-outage-2026-03/intent.md

@@ -0,0 +1,17 @@
+---
+title: db-outage-2026-03
+studio: incident-response
+stages: [triage, investigate, mitigate, resolve, postmortem]
+status: complete
+---
+
+# Primary DB Outage · 2026-03
+
+Primary Postgres unreachable; writes failing fleet-wide. Replica healthy, replication lag sub-second, failover not yet triggered. Likely linked to a schema migration merged ~40 minutes ago.
+
+## Goals
+
+- Restore writes as fast as safely possible
+- Preserve transaction integrity (no silent data loss)
+- Capture the failure mode for the postmortem
+- Produce a regression test or guardrail so this class of migration can't repeat the outage

package/studios/incident-response/examples/db-outage-2026-03/pre-intent.yml

@@ -0,0 +1,17 @@
+related:
+  - data-pipeline
+  - software
+  - operations
+turns:
+  - role: user
+    text: "Primary Postgres is unreachable — writes are failing everywhere."
+  - role: agent
+    text: "Is the failover standby healthy and accepting writes?"
+  - role: user
+    text: "Replica is up, replication lag < 1s. Failover not triggered yet."
+  - role: agent
+    text: "Any recent changes — deploy, schema migration, infra change?"
+  - role: user
+    text: "Migration merged 40 minutes ago. Running on primary only so far."
+  - role: agent
+    text: "Got it — opening incident, starting triage with the migration as the prime suspect."

package/studios/incident-response/fix-hats/reconciler.md

@@ -0,0 +1,10 @@
+---
+agent_type: general-purpose
+---
+**Focus:** Reconcile cross-stage artifacts against studio-wide standards. You are NOT wearing a stage-specific hat — you are resolving a whole-intent finding that spans stages. Your mandate is alignment, not fresh authoring.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** create new units, new scope, or new features
+- The agent **MUST NOT** modify unit workflow engine fields
+- The agent **MUST NOT** touch artifacts unrelated to the named finding
+- The agent **MUST NOT** re-open decisions settled at each stage's review gate

package/studios/incident-response/fix-hats/validator.md

@@ -0,0 +1,10 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that the reconciler's fix resolves the intent-scope feedback. You are the terminal hat — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you verify, you do not fix
+- The agent **MUST NOT** close a finding that isn't actually resolved
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — either close, leave open, or reject as genuinely invalid

package/studios/incident-response/operations/incident-drill.md

@@ -0,0 +1,20 @@
+---
+name: incident-drill
+type: scheduled
+owner: human
+frequency: "quarterly"
+---
+
+**Purpose:** Practice incident response before real incidents. Muscle memory reduces MTTR.
+
+**Procedure:**
+- [ ] Select a realistic failure scenario
+- [ ] Simulate the failure (or run a tabletop exercise)
+- [ ] Execute the response using standard procedures
+- [ ] Time each phase (detection, triage, mitigation, resolution)
+- [ ] Debrief: what worked, what was slow, what was missing
+
+**Signals:**
+- Quarterly drill schedule
+- New team members joining on-call rotation
+- After significant architecture changes

package/studios/incident-response/operations/runbook-review.md

@@ -0,0 +1,20 @@
+---
+name: runbook-review
+type: scheduled
+owner: human
+frequency: "quarterly"
+---
+
+**Purpose:** Verify runbooks are current and actionable. Outdated runbooks during incidents cost time.
+
+**Procedure:**
+- [ ] Review all runbooks for accuracy against current infrastructure
+- [ ] Verify commands and URLs in runbooks are still valid
+- [ ] Check that on-call contacts and escalation paths are current
+- [ ] Walk through at least one runbook end-to-end in a test environment
+- [ ] Update or retire runbooks for decommissioned services
+
+**Signals:**
+- Quarterly review cadence
+- After infrastructure changes
+- After an incident where a runbook was inaccurate

package/studios/incident-response/reflections/prevention.md

@@ -0,0 +1,17 @@
+---
+name: prevention
+studio: incident-response
+---
+
+**Analyze:** Root cause categories, action item completion rates from postmortems, recurrence patterns.
+
+**Look for:**
+- Incidents with similar root causes (systemic pattern)
+- Postmortem action items that were never completed
+- Whether previous prevention measures would have caught this incident
+- Detection gaps: how long was the issue present before detection?
+
+**Produce:**
+- Root cause taxonomy
+- Action item completion tracking
+- Recommendations for systemic prevention investments

package/studios/incident-response/reflections/response-effectiveness.md

@@ -0,0 +1,17 @@
+---
+name: response-effectiveness
+studio: incident-response
+---
+
+**Analyze:** Time in each stage (triage, investigate, mitigate, resolve), escalation patterns, blast radius accuracy.
+
+**Look for:**
+- Time from detection to mitigation (MTTM) vs time to full resolution (MTTR)
+- Severity classification accuracy (over/under-classified?)
+- Whether blast radius assessment was accurate
+- Escalation decisions that were too slow or unnecessary
+
+**Produce:**
+- Response timeline analysis
+- Severity calibration assessment
+- Recommendations for detection, escalation, or mitigation process improvements

package/studios/incident-response/review-agents/cross-stage-consistency.md

@@ -0,0 +1,17 @@
+---
+scope: intent
+interpretation: lens
+---
+**Mandate:** Verify the intent's artifacts are internally consistent across stages. You are the only reviewer that sees the whole intent at once — your job is to catch seams that per-stage reviewers miss.
+
+**Check:**
+- The agent **MUST** verify that each stage's outputs align with what upstream stages specified — no dropped requirements, no silent scope expansion
+- The agent **MUST** verify that naming is consistent across stages — a concept named one thing upstream should carry the same name downstream
+- The agent **MUST** verify that stages' declared outputs exist at the paths their unit frontmatter promised
+- The agent **MUST** verify that the stages collectively deliver the intent's stated goal (read `intent.md`) — partial delivery is a finding
+- The agent **MUST** verify that concerns raised by any stage's review were actually addressed (not silently ignored)
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** re-litigate decisions already approved at each stage's gate
+- The agent **MUST NOT** propose new features or scope additions
+- The agent **MUST NOT** flag stylistic preferences — concrete divergence only

package/studios/incident-response/stages/investigate/STAGE.md

@@ -0,0 +1,15 @@
+---
+name: investigate
+description: Root cause analysis, log analysis, and timeline reconstruction
+hats: [investigator, log-analyst, verifier]
+fix_hats: [investigator, feedback-assessor]
+review: auto
+elaboration: autonomous
+inputs:
+  - stage: triage
+    discovery: incident-brief
+---
+
+# Investigate
+
+Root cause analysis, log analysis, and timeline reconstruction.

package/studios/incident-response/stages/investigate/discovery/ROOT-CAUSE.md

@@ -0,0 +1,29 @@
+---
+name: root-cause
+location: .haiku/intents/{intent-slug}/knowledge/ROOT-CAUSE.md
+scope: intent
+format: text
+required: true
+---
+
+# Root Cause
+
+Root cause analysis with timeline reconstruction and evidence. This output drives the mitigation stage by providing a clear target for immediate action.
+
+## Content Guide
+
+Structure the analysis to support both immediate mitigation and long-term resolution:
+
+- **Reconstructed timeline** — every key event from first anomaly through detection and escalation, with timestamps from multiple sources
+- **Root cause statement** — clear, specific description of what caused the incident
+- **Supporting evidence** — log entries, metric correlations, code paths, and configuration states that confirm the root cause
+- **Contributing factors** — conditions that enabled or amplified the root cause (not the cause itself)
+- **Ruled-out hypotheses** — alternative explanations investigated and why they were eliminated
+- **Affected code paths or systems** — specific files, services, or configurations involved
+
+## Quality Signals
+
+- Root cause is specific enough to target a fix (not "the database was slow" but "query X on table Y hit a full table scan due to missing index on column Z")
+- Timeline entries cite specific data sources, not memory
+- Contributing factors are distinguished from the root cause — they explain severity, not causation
+- At least 2 alternative hypotheses are documented with elimination evidence

package/studios/incident-response/stages/investigate/hats/feedback-assessor.md

@@ -0,0 +1,11 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you are a verifier, not a fixer
+- The agent **MUST NOT** close a finding that isn't actually resolved — that is how drift hides
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
+- The agent **MUST NOT** expand the scope beyond the one feedback item you were dispatched against

package/studios/incident-response/stages/investigate/hats/investigator.md

@@ -0,0 +1,8 @@
+**Focus:** Reconstruct the incident timeline, form and test root cause hypotheses, and distinguish the root cause from contributing factors. Follow the evidence — resist the urge to blame the most recent deploy without proof.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** assume the most recent change is the cause without evidence
+- The agent **MUST NOT** stop at the first plausible explanation without testing alternatives
+- The agent **MUST NOT** confus correlation with causation (e.g., "it broke after the deploy" is not proof the deploy caused it)
+- The agent **MUST** document ruled-out hypotheses and the evidence that eliminated them
+- The agent **MUST NOT** investigate in isolation without sharing findings with the log-analyst

package/studios/incident-response/stages/investigate/hats/log-analyst.md

@@ -0,0 +1,8 @@
+**Focus:** Deep-dive into logs, metrics, and traces to find concrete evidence supporting or refuting root cause hypotheses. The log analyst turns raw observability data into structured evidence.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** search logs without a hypothesis to test — fishing expeditions waste time during incidents
+- The agent **MUST NOT** present raw log output without synthesis or interpretation
+- The agent **MUST NOT** ignore logs from adjacent systems that may reveal upstream causes
+- The agent **MUST** correlat timestamps across different data sources
+- The agent **MUST NOT** treat absence of error logs as evidence of no problem

package/studios/incident-response/stages/investigate/hats/verifier.md

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit knowledge artifact for the investigate stage of incident-response. Units here are investigation finding — knowledge artifacts that downstream stages consume. Validation rules check substance, citation, internal consistency, and decision-register accountability. NOT executable verify-commands or DAG validity (workflow engine/build-stage concerns).
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
+- The agent **MUST NOT** validate against frontmatter schema, `depends_on:` resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
+- The agent **MUST NOT** advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
+- The agent **MUST NOT** reject for stylistic preferences. Substantive gaps only.
+- The agent **MUST** name a specific failed criterion in any rejection.
+- The agent **MUST NOT** invent rules not in this mandate. Stage scope is the contract.
+
+## What you check (BODY ONLY)
+
+### 1. Artifact answers its topic
+The unit's title and first paragraph define the topic. The remaining body MUST deliver substantive content on that topic. Reject placeholders, content-free outlines, or redirects.
+
+### 2. Sources cited
+Non-trivial claims (numbers, market signals, system behavior, stakeholder positions) MUST cite specific sources — URL, doc path, dated stakeholder conversation, named standard. Reject "industry common knowledge" or unsourced numerical claims.
+
+### 3. Internal consistency
+Title, mission, and body must align. Numerical/categorical claims must be consistent across the body. Recommendations must follow from the evidence presented.
+
+### 4. Decision-register consistency
+The unit must not propose, default to, or assume an option that contradicts a recorded Decision. Cite the Decision ID in any rejection.
+
+### 5. Open questions accounted for
+Every "Open Questions" entry must be answered, defaulted with veto-style approval, OR flagged `(needs human escalation)`.

package/studios/incident-response/stages/investigate/outputs/ROOT-CAUSE.md

@@ -0,0 +1,25 @@
+---
+name: root-cause
+location: .haiku/intents/{intent-slug}/stages/investigate/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Root Cause Analysis
+
+Timeline reconstruction, root cause hypothesis, and contributing factors.
+
+## Expected Artifacts
+
+- **Timeline** -- reconstructed from first anomaly to detection with timestamps from independent sources
+- **Root cause hypothesis** -- supported by log evidence with specific entries cited
+- **Contributing factors** -- distinguished from root cause with evidence for each
+- **Alternative hypotheses** -- at least 2 ruled-out alternatives with evidence
+
+## Quality Signals
+
+- Timeline uses timestamps from at least 2 independent sources
+- Root cause hypothesis is supported by specific log evidence
+- Contributing factors are distinguished from the root cause
+- Alternative hypotheses are ruled out with evidence, not just dismissed

package/studios/incident-response/stages/investigate/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Investigate Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Timeline reconstructs the incident from first anomaly to detection with timestamps from at least 2 independent sources"
+- "Root cause hypothesis is supported by log evidence with specific entries cited"
+- "Contributing factors are distinguished from the root cause with evidence for each"
+
+### Bad criteria — vague (no clear check)
+
+- "Root cause is found"
+- "Logs are analyzed"
+- "Investigation is thorough"
+

package/studios/incident-response/stages/investigate/review-agents/thoroughness.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the investigation identified the actual root cause, not just the proximate trigger.
+
+**Check:**
+- The agent **MUST** verify that timeline is complete with no unexplained gaps between events
+- The agent **MUST** verify that evidence (logs, metrics, traces) supports the causal chain
+- The agent **MUST** verify that alternative hypotheses were considered and ruled out with evidence
+- The agent **MUST** verify that contributing factors (deploys, config changes, traffic patterns) are identified

package/studios/incident-response/stages/mitigate/STAGE.md

@@ -0,0 +1,15 @@
+---
+name: mitigate
+description: Apply immediate fixes to stop the bleeding — rollbacks, feature flags, scaling
+hats: [mitigator, verifier]
+fix_hats: [mitigator, feedback-assessor]
+review: [ask, await]
+elaboration: collaborative
+inputs:
+  - stage: investigate
+    discovery: root-cause
+---
+
+# Mitigate
+
+Apply immediate fixes to stop the bleeding — rollbacks, feature flags, scaling.

package/studios/incident-response/stages/mitigate/discovery/MITIGATION-LOG.md

@@ -0,0 +1,30 @@
+---
+name: mitigation-log
+location: .haiku/intents/{intent-slug}/knowledge/MITIGATION-LOG.md
+scope: intent
+format: text
+required: true
+---
+
+# Mitigation Log
+
+Record of all mitigation actions taken, their effects, and how to reverse them. This output feeds the resolve stage so the permanent fix can be built with full context of the temporary measures in place.
+
+## Content Guide
+
+Document every action taken to stop the bleeding:
+
+- **Actions taken** — exact commands, config changes, rollback versions, or feature flags toggled, with timestamps
+- **Rationale** — why this mitigation was chosen over alternatives
+- **Verification results** — before/after metrics showing the mitigation's effect
+- **Rollback plan** — how to reverse each mitigation action if it causes its own problems
+- **Known side effects** — any degraded functionality, reduced capacity, or disabled features resulting from the mitigation
+- **Remaining risk** — what the mitigation does NOT address and what could still go wrong
+- **Cleanup required** — what temporary measures need to be removed once a permanent fix is in place
+
+## Quality Signals
+
+- Every action has a timestamp, an actor, and a reversal procedure
+- Verification uses the same metrics that detected the incident
+- Side effects are explicitly documented, not discovered later
+- The mitigation is clearly labeled as temporary, with cleanup expectations

package/studios/incident-response/stages/mitigate/hats/feedback-assessor.md

@@ -0,0 +1,11 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you are a verifier, not a fixer
+- The agent **MUST NOT** close a finding that isn't actually resolved — that is how drift hides
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
+- The agent **MUST NOT** expand the scope beyond the one feedback item you were dispatched against

package/studios/incident-response/stages/mitigate/hats/mitigator.md

@@ -0,0 +1,8 @@
+**Focus:** Apply the fastest safe action to stop user-facing impact — rollback, feature flag, scaling, or hotfix. Speed matters, but so does not making things worse. Every action must be reversible.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** apply a fix without a rollback plan for the fix itself
+- The agent **MUST NOT** choose a permanent fix when a faster temporary mitigation exists
+- The agent **MUST** document the exact commands or config changes applied
+- The agent **MUST NOT** make multiple changes simultaneously, making it impossible to attribute which one helped
+- The agent **MUST NOT** skip communication — stakeholders need to know what's being done

package/studios/incident-response/stages/mitigate/hats/verifier.md

@@ -0,0 +1,8 @@
+**Focus:** Confirm the mitigation actually stopped the user-facing impact. Use the same signals that detected the incident — if error rates triggered the alert, error rates should confirm the fix. Trust metrics, not assumptions.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** declare "fixed" based on a single data point or gut feeling
+- The agent **MUST NOT** use different metrics to verify than the ones that detected the problem
+- The agent **MUST** wait long enough for metrics to stabilize before confirming
+- The agent **MUST NOT** ignore partial mitigation — impact reduced but not eliminated
+- The agent **MUST** check for side effects introduced by the mitigation itself