haiku-method 2.2.0

package/studios/software/stages/operations/review-agents/reliability.md

@@ -0,0 +1,11 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the deployment and operational configuration supports reliable production operation.
+
+**Check:**
+- The agent **MUST** verify that health checks cover actual readiness, not just process liveness
+- The agent **MUST** verify that rollback procedure is defined and tested
+- The agent **MUST** verify that resource limits (CPU, memory, connections) are set appropriately
+- The agent **MUST** verify that graceful shutdown handles in-flight requests
+- The agent **MUST** verify that retry and circuit-breaker patterns are configured for external dependencies

package/studios/software/stages/product/STAGE.md

@@ -0,0 +1,28 @@
+---
+name: product
+description: Define behavioral specifications and acceptance criteria
+hats: [product, specification, validator]
+fix_hats: [product, feedback-assessor]
+review: [external, ask]
+elaboration: collaborative
+inputs:
+  - stage: inception
+    discovery: discovery
+  - stage: design
+    discovery: design-brief
+  - stage: design
+    discovery: design-tokens
+outputs:
+  - discovery: acceptance-criteria
+    hat: product
+  - discovery: behavioral-spec
+    hat: specification
+  - discovery: data-contracts
+    hat: specification
+  - discovery: coverage-mapping
+    hat: validator
+---
+
+# Product
+
+Define behavioral specifications and acceptance criteria.

package/studios/software/stages/product/discovery/ACCEPTANCE-CRITERIA.md

@@ -0,0 +1,25 @@
+---
+name: acceptance-criteria
+location: .haiku/intents/{intent-slug}/product/ACCEPTANCE-CRITERIA.md
+scope: intent
+format: text
+required: true
+---
+
+# Acceptance Criteria
+
+Prioritized user stories and acceptance criteria produced by the product hat. Defines what "done" looks like from the user's perspective — not how the system implements it.
+
+## Content Guide
+
+- **User stories** — "As a [role], I want [action], so that [benefit]" with specific domain entities
+- **Variability brief** — dimensions along which behavior varies, confirmed before AC writing
+- **Acceptance criteria** — structured as General Rules first, then variant-specific subsections
+- **Prioritization** — P0 (must-have for completion) vs P1 (follow-up)
+
+## Quality Signals
+
+- User stories reference specific domain entities, not generic placeholders
+- Every criterion is specific enough to write a test for
+- Edge cases and error paths are covered alongside happy paths
+- Variability dimensions are explicitly enumerated

package/studios/software/stages/product/discovery/BEHAVIORAL-SPEC.md

@@ -0,0 +1,31 @@
+---
+name: behavioral-spec
+location: .haiku/intents/{intent-slug}/features/
+scope: intent
+format: gherkin
+required: true
+---
+
+# Behavioral Spec
+
+Gherkin `.feature` files defining what the system does from the user's perspective. These files drive development — tests are written to verify these behaviors, and the features themselves can be executed by Cucumber-compatible test runners.
+
+## Content Guide
+
+Each `.feature` file should contain:
+
+- **Feature** — descriptive name and summary of the capability
+- **Background** — shared preconditions across scenarios (Given steps common to all)
+- **Scenarios** — concrete examples covering:
+  - Happy path — the expected successful flow
+  - Error scenarios — validation failures, auth errors, not found, server errors
+  - Edge cases — boundary conditions, concurrent access, empty states, maximum limits
+- **Scenario Outlines** — parameterized scenarios for testing across multiple inputs
+
+## Quality Signals
+
+- Every feature has at least one error scenario, not just the happy path
+- Scenarios are specific enough to execute as automated tests
+- Actors are named roles, not generic "user"
+- Edge cases cover boundaries (zero, one, max, empty, null)
+- Steps use domain language consistent with acceptance criteria from the product hat

package/studios/software/stages/product/discovery/COVERAGE-MAPPING.md

@@ -0,0 +1,25 @@
+---
+name: coverage-mapping
+location: .haiku/intents/{intent-slug}/product/COVERAGE-MAPPING.md
+scope: intent
+format: text
+required: true
+---
+
+# Coverage Mapping
+
+Traceability matrix produced by the validator hat mapping every unit success criterion to its corresponding acceptance criteria and specification items. A GAPS FOUND result blocks stage completion until the responsible hat addresses the gap.
+
+## Content Guide
+
+- **Coverage matrix** — each success criterion mapped to AC and spec items that cover it
+- **Gap flags** — any criterion with no corresponding AC or spec, with the responsible hat identified
+- **Scope creep flags** — any AC or spec item that doesn't trace back to a success criterion
+- **Validation decision** — APPROVED (no gaps) or GAPS FOUND (blocks stage completion)
+
+## Quality Signals
+
+- Every success criterion maps to at least one AC or spec item
+- Every AC item is testable — a concrete test can be described for it
+- No gaps remain unflagged
+- Scope creep items are identified but do not block approval

package/studios/software/stages/product/discovery/DATA-CONTRACTS.md

@@ -0,0 +1,46 @@
+---
+name: data-contracts
+location: .haiku/intents/{intent-slug}/product/DATA-CONTRACTS.md
+scope: intent
+format: text
+required: true
+---
+
+# Data Contracts
+
+API, database, and event contracts that define the data shapes flowing through the system. This output is the agreement between frontend and backend, between services, and between the system and its persistence layer.
+
+## Content Guide
+
+### API Endpoints
+
+For each endpoint:
+- **Method and path** (e.g., `POST /api/v1/users`)
+- **Request schema** — field names, types, required vs. optional, validation rules
+- **Response schema** — field names, types, shape for success and each error case
+- **Error responses** — status codes, error body shape, when each error occurs
+- **Authentication** — what auth is required, what scopes/roles
+
+### Database Models
+
+For each entity:
+- **Entity name** and table/collection name
+- **Fields** — name, type, nullable, default, constraints
+- **Relationships** — foreign keys, join tables, cardinality
+- **Indexes** — which fields are indexed and why
+- **Constraints** — unique, check, not-null
+
+### Event Schemas (if applicable)
+
+For each event:
+- **Event name** and topic/channel
+- **Payload schema** — field names and types
+- **Producer** — what emits this event
+- **Consumers** — what listens for this event
+
+## Quality Signals
+
+- Every field has an explicit type and required/optional designation
+- Error responses are specified alongside success responses
+- Example values are provided for non-obvious fields
+- Naming is consistent across all contracts (same entity name everywhere)

package/studios/software/stages/product/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/software/stages/product/hats/product.md

@@ -0,0 +1,10 @@
+**Focus:** Define user stories, prioritize features, and specify acceptance criteria from the user's perspective. Think in terms of what users do and see, not how the system implements it. Identify variability dimensions (user states, roles, devices, error conditions) before writing AC to ensure complete coverage.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** write implementation details instead of user behavior ("use a Redis cache" vs. "page loads in under 2 seconds")
+- The agent **MUST NOT** skip edge cases and error scenarios
+- The agent **MUST** define what "done" looks like from the user's perspective
+- The agent **MUST NOT** prioritize by implementation ease instead of user value
+- The agent **MUST NOT** write acceptance criteria that cannot be verified with a test
+- The agent **MUST NOT** write vague criteria like "works well" or "is performant" — every criterion must be specific enough to test
+- The agent **MUST** present a variability brief to the user for confirmation before writing AC

package/studios/software/stages/product/hats/specification.md

@@ -0,0 +1,10 @@
+**Focus:** Write behavioral specs in Gherkin format (Feature/Scenario/Given/When/Then), define data contracts (API schemas, database models), and specify API contracts (endpoints, methods, request/response shapes). Gherkin is the spec language — every behavioral requirement becomes a concrete scenario with preconditions, actions, and expected outcomes. Precision matters — ambiguity in specs becomes bugs in code. Adapt contract format to the unit's discipline: frontend specs define component states and responsive behavior; backend specs define input/output contracts, status codes, and authorization; devops specs define environment-specific configuration and rollback criteria.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST** write behavioral specs as `.feature` files in Gherkin syntax — not prose, not pseudocode, not bullet lists
+- The agent **MUST NOT** write specs that describe implementation rather than behavior
+- The agent **MUST NOT** leave contracts ambiguous ("returns data" instead of specifying the schema)
+- The agent **MUST** specify error responses alongside success responses
+- The agent **MUST NOT** define happy path only without error scenarios
+- The agent **MUST NOT** use inconsistent naming between spec and data contracts
+- The agent **MUST** check the unit's discipline before writing specs and adapt format accordingly

package/studios/software/stages/product/hats/validator.md

@@ -0,0 +1,9 @@
+**Focus:** Verify that acceptance criteria and specifications provide complete, testable coverage of the unit's success criteria. This is the "did we miss anything" pass — a separate set of eyes that grades the product and specification hats' work rather than its own.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** approve without producing an explicit coverage mapping
+- The agent **MUST** verify every unit success criterion maps to at least one AC or spec item
+- The agent **MUST** flag any success criterion with no corresponding AC or spec (coverage gap)
+- The agent **SHOULD** flag any AC or spec item that doesn't trace back to a success criterion (potential scope creep)
+- The agent **MUST** verify every AC item is testable — if you cannot describe a concrete test for it, it is not testable
+- The agent **MUST NOT** write new AC or specs to fill gaps — route gaps back to the responsible hat

package/studios/software/stages/product/outputs/SPECS.md

@@ -0,0 +1,23 @@
+---
+name: specs
+location: .haiku/intents/{intent-slug}/
+scope: intent
+format: mixed
+required: true
+---
+
+# Product Specifications
+
+Behavioral specs and data contracts produced by product units. The specification hat writes `.feature` files in Gherkin syntax; the product hat writes acceptance criteria documents.
+
+## Expected Artifacts
+
+- **Behavioral specs** — `.feature` files with Gherkin scenarios (Feature/Scenario/Given/When/Then)
+- **Data contracts** — API schemas, request/response shapes, field types
+- **Acceptance criteria** — testable conditions for each feature, structured by variability dimension
+
+## Quality Signals
+
+- Every product unit produces at least one spec artifact
+- Behavioral specs are valid Gherkin syntax executable by a Cucumber-compatible runner
+- Data contracts include error responses, not just success cases

package/studios/software/stages/product/phases/ELABORATION.md

@@ -0,0 +1,63 @@
+---
+skip: [design-direction, wireframes]
+add: []
+wireframe_fidelity: skip
+criteria_focus: product
+---
+
+# Product Stage — Elaboration
+
+## Criteria Guidance
+
+Product criteria are verified by **behavioral testing** — automated tests (e.g. Cucumber `.feature` scenarios, integration tests, contract tests) that assert the system behaves as specified.
+
+### Good criteria — concrete and verifiable
+
+When generating criteria for this stage, focus on behavioral verification:
+
+- Detailed behavioral specs that describe what the system does, not how it is built
+- Acceptance criteria for every user-facing scenario, each expressible as a Given/When/Then test
+- Edge cases, error paths, and boundary conditions explicitly covered
+- Data contracts, validation rules, and state transitions specified with concrete examples
+- Integration points and external dependency behavior documented (with mock or contract-test specifications)
+- Behavioral specs precise enough for a developer to implement without follow-up questions
+
+### Bad criteria — vague (no clear check)
+
+- "Works correctly" — under what conditions? With what input?
+- "Handles errors" — which errors? What's the expected response?
+- "Data is validated" — against which schema? What error format?
+
+### Bad criteria — product-specific unverifiable
+
+(In addition to the universal unverifiable shapes called out in the workflow engine contracts.)
+
+- "Behavior is intuitive" — needs a usability-test pass with a stated success-rate threshold
+- "Coverage is comprehensive across the user-facing capability list" — needs a structural check counting scenarios against the capability list, not a subjective judgment
+
+## Unit `outputs:` — required artifact shape
+
+Every unit MUST declare its produced artifacts as **real file paths** in the `outputs:` frontmatter. The advance-hat gate verifies each path exists on disk; freeform descriptions get rejected at write time and at advance time.
+
+For product-stage units, the typical artifact set is:
+
+```yaml
+outputs:
+  # Behavioral spec — Gherkin .feature file the specification hat
+  # writes to features/. Per the behavioral-spec template, units MUST
+  # produce at least one .feature file when they cover user-observable
+  # behavior. Reference the file by its actual path, not by name.
+  - .haiku/intents/{intent-slug}/features/my_week.feature
+
+  # Acceptance criteria — markdown produced by the product hat for
+  # this slice of behavior. Lives at .haiku/intents/{intent-slug}/product/
+  # (NOT knowledge/ — that's discovery-stage territory).
+  - .haiku/intents/{intent-slug}/product/ACCEPTANCE-CRITERIA.md
+
+  # Data contract — schema/API/DB shape touched by this unit.
+  - .haiku/intents/{intent-slug}/product/DATA-CONTRACTS.md
+```
+
+Substitute the bracketed paths with the unit's real intent slug and feature filename. The validator hat's `COVERAGE-MAPPING.md` is one shared file across the stage — typically only the validator hat's terminal unit lists it as an output.
+
+**MUST NOT**: write prose like `outputs: ["Weekly carryover roll: scheduler trigger, idempotent roll logic"]`. That's a completion-criteria description, belongs in the body's `## Completion Criteria` section, and the gate now rejects it as `unit_outputs_missing` (no real path matches).

package/studios/software/stages/product/phases/EXECUTION.md

@@ -0,0 +1,17 @@
+# Product Stage — Execution
+
+## Builder Focus
+
+- Write detailed behavioral specs that describe what the system does, not how it is built
+- Define acceptance criteria for every user-facing scenario
+- Identify edge cases, error paths, and boundary conditions
+- Reference design direction (mockups, component specs) from earlier stages as context
+- Specify data contracts, validation rules, and state transitions
+- Document integration points and external dependency behavior
+
+## Reviewer Focus
+
+- Verify specs are precise enough for a developer to implement without follow-up questions
+- Check that edge cases and error scenarios are explicitly covered
+- Confirm behavioral specs align with design artifacts where they exist
+- Ensure acceptance criteria are testable and unambiguous

package/studios/software/stages/product/review-agents/completeness.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify behavioral specifications and data contracts fully cover the intent with no ambiguous or missing scenarios.
+
+**Check:**
+- The agent **MUST** verify that every user-facing flow has defined happy path, error states, and edge cases
+- The agent **MUST** verify that data contracts specify all fields, types, nullability, and validation rules
+- The agent **MUST** verify that acceptance criteria are specific enough to write tests against — no subjective judgments
+- The agent **MUST** verify that no feature described in the intent is missing from the behavioral spec

package/studios/software/stages/product/review-agents/feasibility.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** challenge whether the specified behavior is implementable within the technical constraints.
+
+**Check:**
+- The agent **MUST** verify that specified response times and performance targets are realistic given the data model and infrastructure
+- The agent **MUST** verify that data contracts are compatible with existing schemas (no breaking changes without migration plan)
+- The agent **MUST** verify that edge cases have defined behavior, not just "handle gracefully"
+- The agent **MUST** verify that no specification assumes capabilities that would require unreasonable effort to build

package/studios/software/stages/security/STAGE.md

@@ -0,0 +1,34 @@
+---
+name: security
+description: Threat modeling, security review, and vulnerability assessment
+hats: [threat-modeler, security-engineer, security-reviewer, red-team, blue-team]
+fix_hats: [security-engineer, feedback-assessor]
+review: [external, ask]
+elaboration: autonomous
+inputs:
+  - stage: inception
+    discovery: discovery
+  - stage: product
+    discovery: behavioral-spec
+  - stage: product
+    discovery: data-contracts
+  - stage: development
+    output: code
+  - stage: development
+    discovery: architecture
+review-agents-include:
+  - stage: development
+    agents: [security, architecture]
+  - stage: operations
+    agents: [reliability]
+gate-protocol:
+  timeout: 72h
+  timeout-action: escalate
+  escalation: comms
+  conditions:
+    - "no HIGH findings from review agents"
+---
+
+# Security
+
+Threat modeling, security review, and vulnerability assessment.

package/studios/software/stages/security/discovery/THREAT-MODEL.md

@@ -0,0 +1,37 @@
+---
+name: threat-model
+location: .haiku/knowledge/THREAT-MODEL.md
+scope: project
+format: text
+required: true
+---
+
+# Threat Model
+
+STRIDE-based threat model organized by trust boundary. This output drives red-team testing priorities and blue-team mitigation work.
+
+## Content Guide
+
+For each trust boundary (e.g., client-server, service-service, service-database):
+
+- **Data flows crossing the boundary** — what data moves, in which direction, via what protocol
+- **STRIDE analysis** — for each data flow, assess:
+  - **S**poofing — can an attacker impersonate a legitimate actor?
+  - **T**ampering — can data be modified in transit or at rest?
+  - **R**epudiation — can actions be denied after the fact?
+  - **I**nformation Disclosure — can sensitive data leak?
+  - **D**enial of Service — can the service be made unavailable?
+  - **E**levation of Privilege — can an attacker gain unauthorized access?
+- **Identified threats** — each with severity rating (critical/high/medium/low)
+- **Attack vectors** — how each threat could be exploited
+- **Impact assessment** — what happens if the threat is realized
+- **Required mitigations** — what controls are needed
+
+End with a summary table mapping threats to mitigations and their implementation status (pending/implemented/verified).
+
+## Quality Signals
+
+- Trust boundaries are explicitly drawn, not assumed
+- Every data flow has a STRIDE assessment, even if most categories are N/A
+- Severity ratings reflect actual impact, not just likelihood
+- Mitigations are specific controls, not vague recommendations

package/studios/software/stages/security/discovery/VULN-REPORT.md

@@ -0,0 +1,34 @@
+---
+name: vuln-report
+location: .haiku/intents/{intent-slug}/knowledge/VULN-REPORT.md
+scope: intent
+format: text
+required: false
+---
+
+# Vulnerability Report
+
+Vulnerability findings from red-team testing. This output drives blue-team remediation and security reviewer sign-off.
+
+## Content Guide
+
+For each vulnerability:
+
+- **Title** — concise description of the vulnerability
+- **Severity** — critical, high, medium, low, or informational
+- **OWASP category** — which OWASP Top 10 category it falls under (if applicable)
+- **Description** — what the vulnerability is and why it matters
+- **Reproduction steps** — exact steps to reproduce, specific enough for another tester to follow
+- **Affected component** — file, endpoint, or module where the vulnerability exists
+- **Evidence** — request/response captures, code snippets, screenshots
+- **Recommended fix** — how to remediate the root cause (not just the specific payload)
+- **Mitigation status** — open, mitigated, or accepted risk
+
+End with summary statistics (count by severity) and trend analysis if this is a repeat assessment.
+
+## Quality Signals
+
+- Reproduction steps are specific enough to execute without guessing
+- Recommended fixes address the vulnerability class, not just the test payload
+- Evidence is concrete (actual requests/responses, not hypothetical scenarios)
+- Accepted risks are documented with justification and compensating controls

package/studios/software/stages/security/hats/blue-team.md

@@ -0,0 +1,8 @@
+**Focus:** Defense verification — implement security controls for identified threats, add security tests that prove the controls work, and validate monitoring coverage for security events. Fix root causes, not symptoms.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** patch the specific payloadd used in testing instead of the vulnerability class
+- The agent **MUST** add regression tests that reproduce the original attack
+- The agent **MUST NOT** implement security controls without testing them
+- The agent **MUST NOT** choose functionality over security without explicit human approval
+- The agent **MUST NOT** treat WAF rules as sufficient without fixing the underlying code

package/studios/software/stages/security/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/software/stages/security/hats/red-team.md

@@ -0,0 +1,8 @@
+**Focus:** Attack surface analysis, injection testing (SQL, XSS, command), auth bypass attempts, privilege escalation testing, and data exposure checks. Think like an attacker — find what automated scanners miss.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** only test happy paths with slightly malformed input
+- The agent **MUST** test authentication and authorization boundaries
+- The agent **MUST NOT** execute destructive payloads in shared environments
+- The agent **MUST NOT** stop after the first finding instead of completing the attack surface
+- The agent **MUST NOT** declare code "secure" without executing actual attack payloads

package/studios/software/stages/security/hats/security-engineer.md

@@ -0,0 +1,20 @@
+**Focus:** Implement (or document, where existing controls already cover the surface) the security controls the threat-modeler called for on THIS attack surface. Each unit at this stage corresponds to one attack surface (auth flow, data layer, API endpoint, session management, secrets handling, etc.). Your deliverable is the body of the unit: the concrete controls that defend the surface, mapped to the threats identified by the threat-modeler.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** widen the scope to attack surfaces other than the one this unit names — one unit, one surface
+- The agent **MUST NOT** describe controls in the abstract ("input is validated") without naming the file, function, or middleware that does the validation
+- The agent **MUST NOT** claim a control exists without citing the test that exercises it (or noting "no test — gap" honestly)
+- The agent **MUST NOT** silently skip a threat from the threat model — every applicable threat MUST be addressed (control in place, control to be added, or explicit residual-risk acceptance)
+- The agent **MUST NOT** confuse "the WAF will catch it" with a fix — application-layer controls are what this hat documents
+- The agent **MUST NOT** propose controls that contradict a recorded Decision in the intent's decision register
+- The agent **MUST** be specific about residual risk — "small risk remains" is not residual analysis; "an attacker with valid OAuth token but revoked permissions can still call /admin/users for up to 60 seconds due to JWT cache TTL" is
+
+## Deliverable shape
+
+The unit body MUST be organized so the security-reviewer can verify it against the threat model in one read. Recommended sections:
+
+1. **Surface scope** — one paragraph stating the surface boundary (entry points, trust boundary crossed, data classes handled)
+2. **Threat coverage** — table or list mapping each threat-modeler-identified threat to its control + test
+3. **Implementation references** — file paths + function/middleware names for every control cited
+4. **Test references** — test file paths + test names for every control cited
+5. **Residual risk** — what's NOT covered, with rationale and any acceptance/escalation marker

package/studios/software/stages/security/hats/security-reviewer.md

@@ -0,0 +1,30 @@
+**Focus:** Verify-class hat for the security stage. Validate that the security-engineer's body content for THIS attack surface unit substantively addresses every threat the threat-modeler identified. Body-only verification per architecture §3.4 — frontmatter is workflow engine territory.
+
+**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** execute attacks or run scanners — that is the red-team's job after this hat passes.
+
+## What you check (BODY ONLY)
+
+### 1. Surface scope is concrete and bounded
+The unit body MUST name ONE attack surface (auth flow, data layer, /api/payments endpoint, etc.) with a clear boundary. Reject "this unit covers all API security" — that is not a single surface.
+
+### 2. Every threat-modeler threat is accounted for
+For every threat the threat-modeler called out for this surface, the body MUST show one of: a control in place (with implementation reference + test reference), a control to be added (with concrete plan, not "TBD"), or an explicit residual-risk acceptance with rationale. Silent omission of a threat is a hard reject.
+
+### 3. Controls cite real implementation references
+Every claimed control MUST cite a file path + function / middleware / class name. "Input is validated" without naming the validator is a reject. "JWT verification in `src/middleware/auth.ts:verifyToken`" passes.
+
+### 4. Controls cite tests OR explicitly note the gap
+Every claimed control MUST cite a test file path + test name, OR explicitly note "no test — gap" with a rationale. A control claimed without test backing AND without acknowledgment is a reject.
+
+### 5. Decision-register consistency
+The unit body MUST NOT recommend a control that contradicts a recorded Decision (e.g., recommending a managed-secrets vendor when Decision N chose self-hosted Vault). Cite the Decision ID.
+
+### 6. Residual risk is specific
+If "Residual risk" is non-empty, each item MUST be specific (the conditions under which the risk applies + the impact). Vague residuals ("some risk remains") are a reject.

package/studios/software/stages/security/hats/threat-modeler.md

@@ -0,0 +1,8 @@
+**Focus:** STRIDE threat modeling for all data flows and trust boundaries. Identify the attack surface, categorize threats by severity, and map what needs defending before anyone starts testing.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** only model external threats — insider threats and supply chain attacks matter too
+- The agent **MUST** map trust boundaries (where does trusted data become untrusted?)
+- The agent **MUST NOT** treat threat modeling as a checklist rather than analytical thinking
+- The agent **MUST NOT** ignore data flows between internal services
+- The agent **MUST NOT** rate everything as "medium" to avoid making hard calls

package/studios/software/stages/security/outputs/ASSESSMENTS.md

@@ -0,0 +1,24 @@
+---
+name: assessments
+location: .haiku/intents/{intent-slug}/stages/security/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Security Assessments
+
+Threat models and security findings produced by security units. Each unit MUST write its assessment to the intent's `knowledge/` directory.
+
+## Expected Artifacts
+
+- **Threat models** — attack surfaces, threat actors, risk ratings
+- **Vulnerability assessments** — specific findings with severity
+- **Security test results** — what was tested, what passed, what failed
+- **Mitigation plans** — how identified risks will be addressed
+
+## Quality Signals
+
+- Every security unit produces at least one assessment artifact
+- Findings reference specific code, not generic categories
+- Mitigations are actionable (not "improve security")

package/studios/software/stages/security/phases/ELABORATION.md

@@ -0,0 +1,17 @@
+# Security Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "OWASP Top 10 coverage verified: each category has at least one test or documented N/A justification"
+- "All SQL queries use parameterized statements — verified by grep for string concatenation in query construction"
+- "Authentication tokens expire after 1 hour and refresh tokens after 30 days, verified by test"
+- "All user input is validated at the API boundary before reaching business logic"
+
+### Bad criteria — vague (no clear check)
+
+- "Security review done"
+- "No SQL injection"
+- "Auth is secure"
+

package/studios/software/stages/security/review-agents/mitigation-effectiveness.md

@@ -0,0 +1,11 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** challenge whether proposed mitigations actually address the threats they claim to.
+
+**Check:**
+- The agent **MUST** verify that mitigations address the root cause, not just the symptom
+- The agent **MUST** verify that defense-in-depth: critical threats have multiple layers of mitigation
+- The agent **MUST** verify that mitigations do not introduce new attack surface
+- The agent **MUST** verify that cryptographic choices are current (no MD5, SHA-1 for security purposes, adequate key lengths)
+- The agent **MUST** verify that rate limiting and abuse prevention cover automated attack scenarios, not just manual misuse

package/studios/software/stages/security/review-agents/threat-coverage.md

@@ -0,0 +1,11 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the threat model is comprehensive and all identified threats have mitigations.
+
+**Check:**
+- The agent **MUST** verify that threat model covers all entry points (APIs, webhooks, file uploads, user input)
+- The agent **MUST** verify that sTRIDE or equivalent categorization is applied consistently
+- The agent **MUST** verify that each identified threat has a specific mitigation, not just "we should address this"
+- The agent **MUST** verify that trust boundaries are correctly identified
+- The agent **MUST** verify that third-party dependencies are included in the threat surface