haiku-method 2.2.0

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

@@ -0,0 +1,25 @@
+---
+name: mitigation-log
+location: .haiku/intents/{intent-slug}/stages/mitigate/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Mitigation Log
+
+Record of immediate actions taken to stop user-facing impact.
+
+## Expected Artifacts
+
+- **Actions taken** -- exact commands or config changes applied with timestamps
+- **Verification** -- confirmation that user-facing impact has stopped using the same detection signals
+- **Rollback plan** -- documented procedure in case the mitigation itself causes regression
+- **Known side effects** -- any side effects of the mitigation called out
+
+## Quality Signals
+
+- Mitigation actions are documented with exact details and timestamps
+- Impact cessation is verified using the same metrics that triggered the incident
+- A rollback plan exists for the mitigation itself
+- Side effects are explicitly documented

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

@@ -0,0 +1,16 @@
+# Mitigate Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Mitigation action is documented with exact commands or config changes applied"
+- "Verification confirms user-facing impact has stopped, measured by the same metrics that triggered the incident"
+- "Rollback plan exists in case the mitigation itself causes regression"
+
+### Bad criteria — vague (no clear check)
+
+- "Issue is mitigated"
+- "Fix is applied"
+- "Things are back to normal"
+

package/studios/incident-response/stages/mitigate/review-agents/safety.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the mitigation stops the bleeding without introducing new risks.
+
+**Check:**
+- The agent **MUST** verify that mitigation addresses the immediate impact, not a side effect
+- The agent **MUST** verify that rollback or feature flag changes do not break other functionality
+- The agent **MUST** verify that the mitigation is verified working in production, not just deployed
+- The agent **MUST** verify that no data loss or corruption results from the mitigation action

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

@@ -0,0 +1,15 @@
+---
+name: postmortem
+description: Document timeline, root cause, action items, and prevention measures
+hats: [postmortem-author, action-item-tracker, verifier]
+fix_hats: [postmortem-author, feedback-assessor]
+review: external
+elaboration: autonomous
+inputs:
+  - stage: resolve
+    discovery: resolution-summary
+---
+
+# Postmortem
+
+Document timeline, root cause, action items, and prevention measures.

package/studios/incident-response/stages/postmortem/discovery/POSTMORTEM.md

@@ -0,0 +1,34 @@
+---
+name: postmortem
+location: .haiku/intents/{intent-slug}/knowledge/POSTMORTEM.md
+scope: intent
+format: text
+required: true
+---
+
+# Postmortem
+
+Blameless retrospective document covering the full incident lifecycle. This output is the final artifact — it exists for organizational learning and systemic improvement.
+
+## Content Guide
+
+Structure the postmortem for both immediate stakeholders and future readers:
+
+- **Summary** — one-paragraph description of what happened, who was affected, and how it was resolved
+- **Impact** — quantified user and business impact (error counts, duration, revenue, SLA)
+- **Complete timeline** — every key event from trigger to full resolution with timestamps and actors
+- **Root cause** — clear explanation accessible to non-specialists
+- **Detection** — how the incident was found and how long it took from trigger to detection
+- **Response** — what went well, what went poorly, and where the response could improve
+- **Mitigation and resolution** — what was done immediately and what was done permanently
+- **Action items** — specific, owned, prioritized follow-ups with tracking references
+- **Prevention measures** — systemic changes to prevent this class of incident, not just this specific one
+- **Lessons learned** — insights for the team beyond the specific technical fix
+
+## Quality Signals
+
+- Narrative is blameless — focuses on systems and processes, not individuals
+- Action items are specific, owned, and tracked in the team's work management system
+- Prevention measures address the class of failure, not just this instance
+- Detection story is told honestly, including delays or lucky catches
+- Document is useful to someone encountering a similar incident in the future

package/studios/incident-response/stages/postmortem/hats/action-item-tracker.md

@@ -0,0 +1,8 @@
+**Focus:** Extract concrete, actionable follow-up items from the postmortem and ensure each one has an owner, priority, and tracking mechanism. Action items without owners are wishes, not commitments.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** create action items without owners — unowned items never get done
+- The agent **MUST NOT** list vague actions like "improve monitoring" instead of specific ones like "add latency p99 alert on /api/checkout with 500ms threshold"
+- The agent **MUST** distinguish between quick wins and systemic improvements
+- The agent **MUST NOT** fail to track action items in the team's existing work management system
+- The agent **MUST NOT** create so many action items that none get prioritized and all are forgotten

package/studios/incident-response/stages/postmortem/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/postmortem/hats/postmortem-author.md

@@ -0,0 +1,8 @@
+**Focus:** Write a blameless postmortem that tells the full story — what happened, why, how it was caught, how it was fixed, and what will prevent recurrence. The postmortem is for organizational learning, not individual accountability.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** assign blame to individuals instead of identifying systemic failures
+- The agent **MUST NOT** write a timeline that skips the "boring" parts between detection and resolution
+- The agent **MUST NOT** propose only tactical fixes ("add a check here") without addressing systemic gaps
+- The agent **MUST NOT** omit the detection story — how the incident was found matters as much as what caused it
+- The agent **MUST NOT** write for compliance rather than learning — a postmortem nobody reads prevents nothing

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

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit knowledge artifact for the postmortem stage of incident-response. Units here are postmortem section — 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/postmortem/outputs/POSTMORTEM-DOCUMENT.md

@@ -0,0 +1,25 @@
+---
+name: postmortem-document
+location: .haiku/intents/{intent-slug}/stages/postmortem/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Postmortem Document
+
+Blameless incident narrative with timeline, action items, and prevention measures.
+
+## Expected Artifacts
+
+- **Blameless narrative** -- complete timeline from trigger to resolution with all key events
+- **Impact assessment** -- quantified user and business impact
+- **Action items** -- specific, owned, prioritized, and tracked items
+- **Prevention measures** -- systemic improvements, not just "don't do that again"
+
+## Quality Signals
+
+- Timeline includes every key event with timestamps and actors
+- Each action item has an owner, priority, and due date
+- Prevention measures address systemic gaps, not just the specific failure
+- Postmortem has been reviewed by stakeholders

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

@@ -0,0 +1,16 @@
+# Postmortem Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Postmortem timeline includes every key event from trigger to resolution with timestamps and actors"
+- "Each action item has an owner, priority, and due date — no unassigned items"
+- "Prevention measures address systemic gaps, not just the specific failure that occurred"
+
+### Bad criteria — vague (no clear check)
+
+- "Postmortem is written"
+- "Action items are listed"
+- "Lessons are documented"
+

package/studios/incident-response/stages/postmortem/review-agents/actionability.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the postmortem produces actionable improvements, not just a narrative.
+
+**Check:**
+- The agent **MUST** verify that action items are specific, assigned, and have deadlines
+- The agent **MUST** verify that prevention measures address systemic causes, not just the specific incident
+- The agent **MUST** verify that detection improvements would catch this class of issue earlier
+- The agent **MUST** verify that the timeline is accurate enough to be useful for future reference

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

@@ -0,0 +1,15 @@
+---
+name: resolve
+description: Implement permanent fix with proper testing and review
+hats: [engineer, reviewer]
+fix_hats: [engineer, feedback-assessor]
+review: ask
+elaboration: autonomous
+inputs:
+  - stage: mitigate
+    discovery: mitigation-log
+---
+
+# Resolve
+
+Implement permanent fix with proper testing and review.

package/studios/incident-response/stages/resolve/discovery/RESOLUTION-SUMMARY.md

@@ -0,0 +1,30 @@
+---
+name: resolution-summary
+location: .haiku/intents/{intent-slug}/knowledge/RESOLUTION-SUMMARY.md
+scope: intent
+format: text
+required: true
+---
+
+# Resolution Summary
+
+Record of the permanent fix, its testing, and deployment. This output feeds the postmortem stage with the technical closure needed for a complete incident narrative.
+
+## Content Guide
+
+Document the permanent resolution:
+
+- **Fix description** — what was changed and why, with references to specific code, configuration, or infrastructure changes
+- **Root cause addressed** — how the fix prevents the specific root cause from recurring
+- **Difference from mitigation** — how the permanent fix differs from the temporary mitigation and why the mitigation alone was insufficient
+- **Regression tests** — tests added that would catch this failure mode, with evidence they fail without the fix
+- **Deployment details** — rollout strategy, monitoring criteria, and rollback plan
+- **Mitigation cleanup** — status of removing temporary mitigations (completed, scheduled, or blocked)
+- **Related improvements** — any additional hardening or defensive changes made alongside the primary fix
+
+## Quality Signals
+
+- Fix addresses the root cause, not just the symptom that triggered the incident
+- Regression tests are specific to this failure mode, not generic
+- Deployment plan reflects the risk level — not just "merge and deploy"
+- Mitigation cleanup has a clear timeline and owner

package/studios/incident-response/stages/resolve/hats/engineer.md

@@ -0,0 +1,8 @@
+**Focus:** Implement the permanent fix that addresses the root cause, not just the symptom. Write regression tests that would catch this failure mode. The mitigation bought time — now use it to do the job properly.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** ship the mitigation as the permanent fix without addressing the root cause
+- The agent **MUST NOT** write a fix without a regression test that would have caught this incident
+- The agent **MUST** consider whether the same class of bug exists elsewhere in the codebase
+- The agent **MUST NOT** skip the deployment plan because "it's just a small change"
+- The agent **MUST NOT** leave the temporary mitigation in place without a plan to remove it

package/studios/incident-response/stages/resolve/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/resolve/hats/reviewer.md

@@ -0,0 +1,11 @@
+---
+interpretation: lens
+---
+**Focus:** Review the permanent fix for correctness, completeness, and safety. Verify it addresses the root cause, not just the trigger. Ensure regression tests are meaningful and the deployment plan is sound.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** rubber-stamp because the incident is resolved and urgency has passed
+- The agent **MUST NOT** review only the diff without understanding the root cause it's meant to fix
+- The agent **MUST** verify the regression test actually fails without the fix applied
+- The agent **MUST NOT** ignore deployment risk because the mitigation is already in place
+- The agent **MUST** check whether the temporary mitigation cleanup is included or planned

package/studios/incident-response/stages/resolve/outputs/RESOLUTION-SUMMARY.md

@@ -0,0 +1,25 @@
+---
+name: resolution-summary
+location: .haiku/intents/{intent-slug}/stages/resolve/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Resolution Summary
+
+Permanent fix documentation with regression tests and deployment plan.
+
+## Expected Artifacts
+
+- **Fix description** -- how the permanent fix addresses root cause, not just the symptom
+- **Regression tests** -- tests that would catch this specific failure mode
+- **Deployment plan** -- rollout strategy with monitoring criteria
+- **Mitigation removal** -- confirmation that the temporary mitigation can be safely removed
+
+## Quality Signals
+
+- Fix addresses the root cause, not just the symptom the mitigation covered
+- Regression tests exist that would have caught this incident
+- Deployment plan includes canary or staged rollout with rollback criteria
+- Code review is complete before deployment

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

@@ -0,0 +1,16 @@
+# Resolve Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Fix addresses the root cause identified in investigation, not just the symptom the mitigation covered"
+- "Test coverage includes a regression test that would have caught this incident before it reached production"
+- "Deployment plan includes canary or staged rollout with rollback criteria"
+
+### Bad criteria — vague (no clear check)
+
+- "Code is fixed"
+- "Tests pass"
+- "Deployed to production"
+

package/studios/incident-response/stages/resolve/review-agents/correctness.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the permanent fix addresses the root cause with adequate testing.
+
+**Check:**
+- The agent **MUST** verify that fix addresses the root cause identified in the investigation, not just the symptom
+- The agent **MUST** verify that test coverage includes the specific failure scenario that caused the incident
+- The agent **MUST** verify that regression tests prevent this class of failure, not just this exact instance
+- The agent **MUST** verify that fix does not reintroduce the conditions that led to the incident

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

@@ -0,0 +1,13 @@
+---
+name: triage
+description: Assess severity, identify blast radius, and assign ownership
+hats: [incident-commander, first-responder, verifier]
+fix_hats: [incident-commander, feedback-assessor]
+review: auto
+elaboration: collaborative
+inputs: []
+---
+
+# Triage
+
+Assess severity, identify blast radius, and assign ownership.

package/studios/incident-response/stages/triage/discovery/INCIDENT-BRIEF.md

@@ -0,0 +1,30 @@
+---
+name: incident-brief
+location: .haiku/intents/{intent-slug}/knowledge/INCIDENT-BRIEF.md
+scope: intent
+format: text
+required: true
+---
+
+# Incident Brief
+
+Initial assessment of the incident capturing severity, blast radius, and ownership. This output feeds all downstream stages as the foundational context for the incident response.
+
+## Content Guide
+
+Structure the brief to enable immediate action:
+
+- **Severity classification** — SEV level with justification based on user impact, data integrity, and business criticality
+- **Blast radius** — affected services, regions, customer segments, and estimated user count
+- **Timeline so far** — when the issue started, when it was detected, and how it was detected
+- **Current user impact** — what users are experiencing (errors, latency, data loss, etc.)
+- **Ownership assignments** — who is investigating, who is communicating, who is the incident commander
+- **Communication status** — who has been notified and through which channels
+- **Initial diagnostic data** — error samples, relevant metrics, reproduction steps if known
+
+## Quality Signals
+
+- Severity rating is justified with specific impact data, not gut feeling
+- Blast radius is scoped precisely — not "some users" but "users in region X hitting endpoint Y"
+- Ownership is unambiguous — every role has exactly one person assigned
+- Initial data is captured before it ages out of log retention

package/studios/incident-response/stages/triage/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/triage/hats/first-responder.md

@@ -0,0 +1,8 @@
+**Focus:** Confirm the incident is real, capture initial diagnostic data, and assess immediate user impact. The first responder provides ground truth — what's actually happening, not what dashboards suggest might be happening.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** assume the alert is a false positive without verifying
+- The agent **MUST NOT** start a fix before documenting what's broken
+- The agent **MUST** captur ephemeral diagnostic data (logs, metrics) that may rotate out
+- The agent **MUST NOT** report symptoms without measuring actual user impact
+- The agent **MUST NOT** work in isolation without feeding findings back to the incident commander

package/studios/incident-response/stages/triage/hats/incident-commander.md

@@ -0,0 +1,8 @@
+**Focus:** Take ownership of the incident, classify severity, assess blast radius, and coordinate the response. The incident commander is the single point of authority — decisions flow through them to avoid confusion during high-pressure situations.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** jump to root cause analysis before establishing severity and blast radius
+- The agent **MUST NOT** fail to assign clear ownership for investigation and mitigation
+- The agent **MUST** communicat status to stakeholders early and often
+- The agent **MUST NOT** downgradd severity without evidence that impact is contained
+- The agent **MUST NOT** attempt to fix the issue instead of coordinating the response

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

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit operational artifact for the triage stage of incident-response. Units here are triage decision — operational steps with concrete preconditions, actions, and post-condition checks. Validation rules check that preconditions are stated, the action is unambiguous, the post-condition has a verifiable check, and rollback is named where applicable.
+
+**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. Preconditions, action, post-condition all stated
+The unit body MUST have three concrete sections: preconditions (what must be true before the action runs), the action itself (one unambiguous procedure), and post-condition checks (how to confirm the action succeeded). Reject if any of the three is missing or vague.
+
+### 2. Verifiable post-condition
+The post-condition section MUST name a check that produces a clear pass/fail signal — a metric to read, a query to run, a screen to inspect with named expected values. "Verify by eye that things look good" is a reject.
+
+### 3. Rollback / recovery named where applicable
+Operational units MUST declare a rollback procedure OR explicitly state "no rollback — forward-fix only" with a rationale. Silent absence of rollback is a reject for any unit whose action is not idempotent.
+
+### 4. Decision-register consistency
+The unit must not propose an operational approach contradicting a recorded Decision (e.g., blue-green deploy when Decision N chose canary). Cite the Decision ID.
+
+### 5. Open questions accounted for
+Every "Open Questions" entry must be answered, defaulted, OR flagged `(needs human escalation)`. Operational open questions left to runtime are how outages happen.

package/studios/incident-response/stages/triage/outputs/INCIDENT-BRIEF.md

@@ -0,0 +1,25 @@
+---
+name: incident-brief
+location: .haiku/intents/{intent-slug}/stages/triage/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Incident Brief
+
+Severity classification, blast radius assessment, and ownership assignment.
+
+## Expected Artifacts
+
+- **Severity classification** -- SEV level with justification based on user impact
+- **Blast radius assessment** -- all affected services, regions, and customer segments identified
+- **Ownership assignment** -- incident commander and responders identified
+- **Initial diagnostics** -- incident confirmed reproducible with diagnostic data captured
+
+## Quality Signals
+
+- Severity level has justification based on measurable user impact
+- Blast radius identifies all affected systems and customer segments
+- Initial communication has been sent to stakeholders
+- Diagnostic data is captured for the investigation stage

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

@@ -0,0 +1,16 @@
+# Triage Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Incident brief includes severity level (SEV1-4) with justification based on user impact"
+- "Blast radius assessment identifies all affected services, regions, and customer segments"
+- "Communication plan specifies who has been notified and through which channels"
+
+### Bad criteria — vague (no clear check)
+
+- "Severity is assessed"
+- "People are notified"
+- "Incident is triaged"
+

package/studios/incident-response/stages/triage/review-agents/severity-accuracy.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify severity classification and blast radius assessment are accurate.
+
+**Check:**
+- The agent **MUST** verify that severity level matches the observed impact (users affected, data at risk, revenue impact)
+- The agent **MUST** verify that blast radius assessment accounts for downstream dependencies, not just the failing component
+- The agent **MUST** verify that escalation path is appropriate for the severity level
+- The agent **MUST** verify that no under-classification to avoid process overhead

package/studios/incident-response/templates/production-incident.md

@@ -0,0 +1,48 @@
+---
+name: production-incident
+studio: incident-response
+description: Respond to a production incident from triage through postmortem
+parameters:
+  - name: service
+    description: Affected service or system
+    required: true
+  - name: severity
+    description: "Severity: sev1, sev2, sev3"
+    required: true
+  - name: alert_url
+    description: Link to the alert or monitoring dashboard
+    required: false
+units:
+  - name: "triage"
+    stage: triage
+    criteria:
+      - "Severity confirmed as {{ severity }}"
+      - "Blast radius assessed (users, services, data)"
+      - "Incident commander assigned"
+  - name: "root-cause"
+    stage: investigate
+    criteria:
+      - "Timeline reconstructed with evidence"
+      - "Root cause identified (not just proximate trigger)"
+      - "Contributing factors documented"
+  - name: "stop-bleeding"
+    stage: mitigate
+    criteria:
+      - "{{ service }} restored to functional state"
+      - "Mitigation verified in production"
+      - "No data loss or corruption from mitigation"
+  - name: "permanent-fix"
+    stage: resolve
+    criteria:
+      - "Fix addresses root cause, not just symptom"
+      - "Regression test covers the failure scenario"
+      - "Fix deployed and verified"
+  - name: "postmortem"
+    stage: postmortem
+    criteria:
+      - "Timeline accurate and complete"
+      - "Action items assigned with owners and deadlines"
+      - "Prevention measures identified"
+---
+
+Full incident response for production issues. Uses all 5 stages.

package/studios/legal/STUDIO.md

@@ -0,0 +1,11 @@
+---
+name: legal
+description: Legal review and contract management lifecycle
+stages: [intake, research, draft, review, execute]
+category: back-office
+default_model: sonnet
+---
+
+# Legal Studio
+
+Legal review and contract management lifecycle from initial intake through execution. Covers requirements gathering, precedent research, document drafting, compliance review, and signature coordination. Works for contracts, agreements, policy documents, and regulatory filings.

package/studios/legal/examples/vendor-nda-mutual/intent.md

@@ -0,0 +1,17 @@
+---
+title: vendor-nda-mutual
+studio: legal
+stages: [intake, research, draft, review, execute]
+status: complete
+---
+
+# Mutual NDA for Data Processor
+
+Draft a mutual NDA for a new data-processor vendor relationship. Delaware law, 3-year term from the effective date. Cover customer PII (our side) and proprietary pipeline internals (their side).
+
+## Goals
+
+- Mutual protection — both parties share confidential information
+- Standard carveouts for publicly-available and independently-developed information
+- Return-or-destroy provision at termination
+- Survival clause: confidentiality obligations persist 5 years post-term

package/studios/legal/examples/vendor-nda-mutual/pre-intent.yml

@@ -0,0 +1,17 @@
+related:
+  - vendor-management
+  - compliance
+  - security-assessment
+turns:
+  - role: user
+    text: "Draft a vendor NDA — we're onboarding a new data processor."
+  - role: agent
+    text: "One-way or mutual?"
+  - role: user
+    text: "Mutual. We share customer data; they share proprietary pipeline internals."
+  - role: agent
+    text: "Governing law and term?"
+  - role: user
+    text: "Delaware. 3 years from effective date."
+  - role: agent
+    text: "Got it — I'll pull our template, tailor the definitions, and draft."

package/studios/legal/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