haiku-method 2.2.0

package/studios/security-assessment/examples/internal-app-pentest/pre-intent.yml

@@ -0,0 +1,17 @@
+related:
+  - compliance
+  - software
+  - documentation
+turns:
+  - role: user
+    text: "Pentest our internal admin dashboard before we open it to partner admins."
+  - role: agent
+    text: "Scope — the web app only, or API + infra too?"
+  - role: user
+    text: "Web app + the API it calls. Infra is out of scope."
+  - role: agent
+    text: "Authenticated testing, unauthenticated, or both?"
+  - role: user
+    text: "Both. Partner admin role is the primary target."
+  - role: agent
+    text: "Got it — web + API pentest, authenticated and unauthenticated, partner-admin role focus."

package/studios/security-assessment/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/security-assessment/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/security-assessment/operations/finding-tracker.md

@@ -0,0 +1,21 @@
+---
+name: finding-tracker
+type: scheduled
+owner: agent
+schedule: "0 9 * * 1"
+runtime: node
+---
+
+**Purpose:** Track remediation status of all reported findings. Untracked findings stay unresolved.
+
+**Procedure:**
+- Load all findings from the assessment report
+- Check remediation status against the target system
+- Verify fixes are deployed and effective (not just committed)
+- Update finding status (open, in-progress, resolved, risk-accepted)
+- Flag overdue findings based on severity SLA
+
+**Signals:**
+- Weekly tracking
+- After any deployment that claims to fix a finding
+- Approaching remediation SLA deadline

package/studios/security-assessment/operations/retest-schedule.md

@@ -0,0 +1,20 @@
+---
+name: retest-schedule
+type: process
+owner: human
+frequency: "as-needed"
+---
+
+**Purpose:** Schedule and execute retests for remediated findings. A remediation claim without retest is unverified.
+
+**Procedure:**
+- [ ] Identify findings marked as remediated
+- [ ] Verify the fix is deployed to the target environment
+- [ ] Attempt to reproduce the original finding
+- [ ] Test for bypass or regression of the fix
+- [ ] Update finding status based on retest results
+
+**Signals:**
+- Finding marked as remediated by engineering
+- Remediation SLA approaching deadline
+- Before the final assessment report is issued

package/studios/security-assessment/reflections/coverage.md

@@ -0,0 +1,17 @@
+---
+name: coverage
+studio: security-assessment
+---
+
+**Analyze:** Attack surface coverage, technique effectiveness, false positive rates across enumeration and exploitation.
+
+**Look for:**
+- Areas of the attack surface that were not tested
+- Techniques that produced the most actionable findings
+- False positive rates by tool and technique
+- Whether the scope was appropriate (too narrow missed things, too broad wasted effort)
+
+**Produce:**
+- Coverage map against the target attack surface
+- Technique effectiveness ranking
+- Recommendations for scope and methodology improvements

package/studios/security-assessment/reflections/impact.md

@@ -0,0 +1,17 @@
+---
+name: impact
+studio: security-assessment
+---
+
+**Analyze:** Finding severity distribution, remediation feasibility, business impact accuracy.
+
+**Look for:**
+- Severity ratings that were over/under-classified vs actual risk
+- Findings where remediation was harder than expected
+- Whether the executive summary accurately conveyed business risk
+- Client remediation follow-through (if historical data available)
+
+**Produce:**
+- Severity calibration assessment
+- Remediation complexity analysis
+- Recommendations for improving severity rating accuracy and report clarity

package/studios/security-assessment/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/security-assessment/stages/enumeration/STAGE.md

@@ -0,0 +1,15 @@
+---
+name: enumeration
+description: Service discovery, version detection, vulnerability scanning, and attack surface mapping
+hats: [enumerator, vulnerability-scanner, verifier]
+fix_hats: [enumerator, feedback-assessor]
+review: ask
+elaboration: autonomous
+inputs:
+  - stage: reconnaissance
+    discovery: target-profile
+---
+
+# Enumeration
+
+Service discovery, version detection, vulnerability scanning, and attack surface mapping.

package/studios/security-assessment/stages/enumeration/hats/enumerator.md

@@ -0,0 +1,9 @@
+**Focus:** Deep-dive into discovered services to extract version information, configuration details, supported protocols, authentication mechanisms, and exposed functionality. Turn the reconnaissance map into a detailed service inventory.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** attempt exploitation during enumeration — this stage is observation only
+- The agent **MUST NOT** use default or brute-force credential attacks without explicit authorization
+- The agent **MUST NOT** fail to record exact commands and parameters used for reproducibility
+- The agent **MUST NOT** ignore less common services in favor of only well-known ports
+- The agent **MUST** distinguish between confirmed versions and inferred versions
+- The agent **MUST NOT** acces systems or services outside the authorized scope

package/studios/security-assessment/stages/enumeration/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/security-assessment/stages/enumeration/hats/verifier.md

@@ -0,0 +1,27 @@
+**Focus:** Validate the per-unit knowledge artifact for the enumeration stage of security-assessment. Units here are enumeration 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.
+- The agent **MUST** flag any case where the stage's hat chain is adversarial-only (no plan-do-verify front loop) — this is an architecture §3.5 violation. Per architecture §3.5 the plan-do-verify triplet MUST come BEFORE adversarial hats. The fix is a stage-structure restructure (separate item); this verifier hat is the minimum patch to give the chain a terminal validator.
+
+## 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/security-assessment/stages/enumeration/hats/vulnerability-scanner.md

@@ -0,0 +1,9 @@
+**Focus:** Identify known vulnerabilities in discovered services using version correlation, configuration analysis, and targeted vulnerability checks. Classify findings by severity and verify where possible without exploitation.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** run unauthenticated exploit checks that could crash services or cause data loss
+- The agent **MUST NOT** report raw scanner output without validation or false-positive triage
+- The agent **MUST NOT** treat all scanner findings as confirmed without manual verification
+- The agent **MUST NOT** ignore configuration weaknesses that don't have CVE numbers
+- The agent **MUST NOT** scan outside the authorized scope or during restricted time windows
+- The agent **MUST NOT** fail to document scanner versions, plugins, and configuration for reproducibility

package/studios/security-assessment/stages/enumeration/outputs/VULNERABILITY-CATALOG.md

@@ -0,0 +1,25 @@
+---
+name: vulnerability-catalog
+location: .haiku/intents/{intent-slug}/stages/enumeration/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Vulnerability Catalog
+
+Service enumeration results with vulnerability findings and attack surface map.
+
+## Expected Artifacts
+
+- **Vulnerability findings** -- each linked to specific service, version, and CVE where applicable
+- **Service enumeration** -- software versions detected for discovered services
+- **Attack surface map** -- entry points categorized by protocol, authentication, and exposure level
+- **Priority targets** -- identified for exploitation with rationale
+
+## Quality Signals
+
+- Each finding has CVE reference, CVSS score, and verification status
+- Service enumeration identifies versions for at least 90% of discovered services
+- False positives are flagged and verified findings are distinguished
+- Attack surface entries are categorized by risk level

package/studios/security-assessment/stages/enumeration/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Enumeration Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Vulnerability catalog lists each finding with CVE reference, CVSS score, affected service, and verification status"
+- "Service enumeration identifies software versions for at least 90% of discovered services"
+- "Attack surface map categorizes entry points by protocol, authentication requirement, and exposure level"
+
+### Bad criteria — vague (no clear check)
+
+- "Services are enumerated"
+- "Vulnerabilities are found"
+- "Attack surface is documented"
+

package/studios/security-assessment/stages/enumeration/review-agents/false-positive-check.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify vulnerability findings are real, not scanner noise.
+
+**Check:**
+- The agent **MUST** verify that each finding has been manually verified or has strong confidence indicators
+- The agent **MUST** verify that version-based detections are confirmed against actual behavior, not just banners
+- The agent **MUST** verify that scanner findings are correlated across tools to reduce false positives
+- The agent **MUST** verify that severity ratings reflect exploitability in this specific environment

package/studios/security-assessment/stages/exploitation/STAGE.md

@@ -0,0 +1,15 @@
+---
+name: exploitation
+description: Controlled exploitation of discovered vulnerabilities with proper scoping and authorization
+hats: [attack-strategist, exploit-developer, exploit-reviewer, attack-operator, verifier]
+fix_hats: [exploit-developer, feedback-assessor]
+review: ask
+elaboration: collaborative
+inputs:
+  - stage: enumeration
+    discovery: vulnerability-catalog
+---
+
+# Exploitation
+
+Controlled exploitation of discovered vulnerabilities with proper scoping and authorization.

package/studios/security-assessment/stages/exploitation/hats/attack-operator.md

@@ -0,0 +1,9 @@
+**Focus:** Execute exploitation attempts against authorized targets using developed proof-of-concepts. Maintain detailed logs of every action taken, monitor for unintended side effects, and abort immediately if scope boundaries are approached.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** execute exploits without reviewing proof-of-concept safety constraints first
+- The agent **MUST NOT** continu exploitation after observing unintended side effects or service degradation
+- The agent **MUST NOT** fail to log every action with precise timestamps and parameters
+- The agent **MUST NOT** operat outside authorized time windows or scope boundaries
+- The agent **MUST** have a communication channel ready for immediate escalation
+- The agent **MUST NOT** modify or destroying data on target systems beyond what is required to demonstrate access

package/studios/security-assessment/stages/exploitation/hats/attack-strategist.md

@@ -0,0 +1,10 @@
+**Focus:** Plan the exploitation approach for THIS attack surface (one unit = one surface from the vulnerability catalog). Decide which vulnerability(ies) on this surface to exploit, in what order, with what techniques, against what scope boundaries. You do NOT build the exploit and you do NOT run it — that is the exploit-developer's and attack-operator's job.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** plan exploits that operate outside the authorized scope — surface boundary checks are non-negotiable
+- The agent **MUST NOT** plan destructive payloads (data wipe, persistent DoS, lateral movement to out-of-scope assets)
+- The agent **MUST NOT** delegate the scope-boundary check to the exploit-developer — strategy MUST verify scope before development starts
+- The agent **MUST NOT** describe attack steps so vaguely that the exploit-developer has to re-plan the strategy
+- The agent **MUST NOT** plan an exploit chain when a simpler, equivalent-impact path is available
+- The agent **MUST NOT** propose techniques that contradict a recorded Decision (e.g., "use a public PoC" when Decision N said all PoCs must be developed in-house)
+- The agent **MUST** name the success-criterion observable concretely — "we get a shell" is not specific; "non-zero exit from `id` command run as root inside the container" is

package/studios/security-assessment/stages/exploitation/hats/exploit-developer.md

@@ -0,0 +1,11 @@
+**Focus:** Build the exploit per the attack-strategist's plan for THIS attack surface unit. You do NOT redesign the strategy — your job is to translate the strategy into reliable, controlled proof-of-concept code that demonstrates the planned impact without escaping the test boundary or causing destruction. If the strategy is wrong, reject up the chain (raise the issue in the unit body for the strategist to revise on next iteration); do not silently substitute a different attack.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** develop exploits that could cause data destruction or service denial
+- The agent **MUST NOT** use publicly available exploits without reviewing them for safety, scope compliance, and licensing
+- The agent **MUST NOT** skip the development of rollback or cleanup procedures
+- The agent **MUST NOT** target vulnerabilities or surfaces outside the strategist's plan or the authorized scope
+- The agent **MUST NOT** silently widen the strategy — if a step in the strategist's plan is infeasible, document it in the unit body so the strategist can revise
+- The agent **MUST** test exploits in a controlled manner (local container, staging clone, mocked service) before the attack-operator deploys against the real target
+- The agent **MUST NOT** fail to document the exploit chain, dependencies, and prerequisites
+- The agent **MUST NOT** ship a PoC without a kill switch / abort path

package/studios/security-assessment/stages/exploitation/hats/exploit-reviewer.md

@@ -0,0 +1,30 @@
+**Focus:** Verify-class hat for the exploitation stage's plan-do-verify front loop. Validate that the exploit-developer's body content for THIS attack surface unit is realistic, scoped, and safe to hand to the attack-operator. Body-only verification per architecture §3.4 — frontmatter is workflow engine territory. Adversarial verify (`verifier`) runs LATER, after the red-team-style attack-operator step. Your job is to keep the operator from being handed a broken or scope-creeping PoC.
+
+**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 the PoC. You are reviewing the PoC's specification and code (read-only); execution is the attack-operator's job.
+
+## What you check (BODY ONLY)
+
+### 1. PoC matches the strategist's plan
+The exploit-developer's PoC MUST execute the attack chain the attack-strategist described in this unit's prior section. If the developer silently substituted a different technique, reject — the strategist must revise the plan first.
+
+### 2. Scope adherence is explicit and demonstrable
+The body MUST show that every step of the PoC stays within the rules of engagement (target list, time windows, no-go assets). Reject if any step's target is ambiguous or outside the catalog's authorized surface.
+
+### 3. Safety constraints are concrete
+The PoC MUST have: a kill switch (how to abort mid-execution), a payload-size or rate limit (no unbounded loops, no large-volume sends), and a rollback/cleanup procedure (how to remove any artifacts left on the target). Reject if any of these is "TBD" or missing.
+
+### 4. Pre-flight checks are runnable
+The body MUST list pre-flight checks the operator runs BEFORE invoking the PoC (target reachability, scope confirmation, time-window check). Each check MUST be a concrete command or observable signal — not "verify the target is up" but `curl -sf https://target/health | grep ok`.
+
+### 5. Test-boundary containment
+The body MUST show that the PoC was test-driven against a local/staging surrogate before being green-lit for the real target. Reject if the developer skipped this and went straight to "ready for operator."
+
+### 6. Decision-register consistency
+The PoC MUST NOT contradict a recorded Decision (e.g., using a public exploit when Decision N requires in-house PoCs only). Cite the Decision ID.

package/studios/security-assessment/stages/exploitation/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/security-assessment/stages/exploitation/hats/verifier.md

@@ -0,0 +1,27 @@
+**Focus:** Validate the per-unit build artifact for the exploitation stage of security-assessment. Units here are attack chain — discrete pieces of work with executable acceptance criteria. Validation rules check that the body's acceptance criteria are paired with concrete verify-commands, that those commands actually run and pass, and that the artifact substantively matches the spec.
+
+**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.
+- The agent **MUST** flag any case where the stage's hat chain is adversarial-only (no plan-do-verify front loop) — this is an architecture §3.5 violation. Per architecture §3.5 the plan-do-verify triplet MUST come BEFORE adversarial hats. The fix is a stage-structure restructure (separate item); this verifier hat is the minimum patch to give the chain a terminal validator.
+
+## What you check (BODY ONLY)
+
+### 1. Body matches the spec it claims to satisfy
+The unit body MUST substantively address every acceptance criterion declared in the unit's spec section. Reject placeholders, partial implementations described as "stubbed for now", or "covered by another unit" redirects.
+
+### 2. Acceptance criteria paired with verify-commands
+Every acceptance criterion in the body MUST be paired with a concrete shell command (or test invocation) that returns a clear pass/fail signal. Vague criteria ("works correctly", "tests pass") are a reject. Map verify-commands to the project's actual stack — read `package.json` / `pyproject.toml` / `Cargo.toml` / `go.mod` to know which test runner / coverage tool / linter the project uses.
+
+### 3. Verify-commands actually pass
+Run the named verify-commands. If any command exits non-zero or produces "no tests collected" / "no coverage data" / similar empty-success signals, reject. Cite the failing command and its exit code in the rejection reason.
+
+### 4. Decision-register consistency
+The unit must not introduce an approach contradicting a recorded Decision (e.g., a sync API when Decision N chose async). Cite the Decision ID.
+
+### 5. Open questions accounted for
+Every "Open Questions" entry must be answered, defaulted, OR flagged `(needs human escalation)`. Build-stage open questions block downstream consumers — be strict.

package/studios/security-assessment/stages/exploitation/outputs/ACCESS-LOG.md

@@ -0,0 +1,25 @@
+---
+name: access-log
+location: .haiku/intents/{intent-slug}/stages/exploitation/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Access Log
+
+Exploitation attempt records with proof-of-concept artifacts and access chains.
+
+## Expected Artifacts
+
+- **Attempt log** -- every exploitation attempt with timestamp, tool/technique, target, and outcome
+- **Proof-of-concept artifacts** -- impact demonstrated without causing harm
+- **Access chains** -- end-to-end documentation from initial vector to achieved access level
+- **Failed attempts** -- recorded with analysis of why they failed
+
+## Quality Signals
+
+- All exploitation attempts are logged with timestamps and outcomes
+- Successful exploits have proof-of-concept artifacts demonstrating impact
+- Each access chain is documented end-to-end with reproduction steps
+- All activity stayed within authorized scope and rules of engagement

package/studios/security-assessment/stages/exploitation/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Exploitation Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Each exploit attempt is logged with exact timestamp, tool/technique used, target, and outcome (success/fail/partial)"
+- "Proof-of-concept demonstrates impact without causing data destruction, service disruption, or scope violation"
+- "Access log documents the full chain from initial vector to achieved access level with reproduction steps"
+
+### Bad criteria — vague (no clear check)
+
+- "Vulnerabilities are exploited"
+- "Access is gained"
+- "Exploits work"
+

package/studios/security-assessment/stages/exploitation/review-agents/scope-compliance.md

@@ -0,0 +1,10 @@
+---
+interpretation: strict
+---
+**Mandate:** The agent **MUST** verify exploitation stayed within authorized scope and rules of engagement.
+
+**Check:**
+- The agent **MUST** verify that all exploitation targets are within the defined scope
+- The agent **MUST** verify that techniques used comply with the rules of engagement
+- The agent **MUST** verify that no denial-of-service or data destruction occurred
+- The agent **MUST** verify that evidence of exploitation is captured with timestamps and methodology

package/studios/security-assessment/stages/post-exploitation/STAGE.md

@@ -0,0 +1,15 @@
+---
+name: post-exploitation
+description: Assess impact, test lateral movement, evaluate data exposure, and document access chains
+hats: [post-exploit-analyst, impact-assessor]
+fix_hats: [post-exploit-analyst, feedback-assessor]
+review: ask
+elaboration: autonomous
+inputs:
+  - stage: exploitation
+    discovery: access-log
+---
+
+# Post-Exploitation
+
+Assess impact, test lateral movement, evaluate data exposure, and document access chains.

package/studios/security-assessment/stages/post-exploitation/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/security-assessment/stages/post-exploitation/hats/impact-assessor.md

@@ -0,0 +1,9 @@
+**Focus:** Evaluate the business impact of each successful access chain. Classify data exposure by sensitivity, assess regulatory implications, estimate blast radius, and determine the real-world consequences if each vulnerability were exploited by a malicious actor.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** inflat or deflating severity to fit a predetermined narrative
+- The agent **MUST NOT** ignore regulatory or compliance implications of data exposure
+- The agent **MUST NOT** assess technical impact without translating to business risk
+- The agent **MUST NOT** fail to distinguish between demonstrated impact and theoretical impact
+- The agent **MUST** consider the cumulative effect of chained vulnerabilities
+- The agent **MUST NOT** treat all data exposure as equivalent regardless of data classification

package/studios/security-assessment/stages/post-exploitation/hats/post-exploit-analyst.md

@@ -0,0 +1,9 @@
+**Focus:** From established footholds, map lateral movement possibilities, identify privilege escalation paths, and assess what an attacker could reach from each compromised position. Document the full attack graph without causing additional harm.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** actually exfiltrating sensitive data instead of documenting its accessibility
+- The agent **MUST NOT** attempt lateral movement outside the authorized scope
+- The agent **MUST NOT** instal persistent backdoors or modifying system configurations
+- The agent **MUST NOT** fail to document the exact path taken at each step for reproducibility
+- The agent **MUST** clean up artifacts (shells, temporary files) created during analysis
+- The agent **MUST NOT** caus service disruption while exploring post-exploitation paths

package/studios/security-assessment/stages/post-exploitation/outputs/IMPACT-ASSESSMENT.md

@@ -0,0 +1,25 @@
+---
+name: impact-assessment
+location: .haiku/intents/{intent-slug}/stages/post-exploitation/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Impact Assessment
+
+Full scope assessment of what an attacker could achieve through each access chain.
+
+## Expected Artifacts
+
+- **Access scope** -- maximum access level achieved and data categories exposed per access chain
+- **Lateral movement paths** -- potential pivot paths with required credentials and access levels
+- **Privilege escalation** -- starting access, technique used, and resulting access with evidence
+- **Data exposure analysis** -- accessible data categorized by sensitivity
+
+## Quality Signals
+
+- Impact assessment documents the full blast radius of each access chain
+- At least 3 lateral movement paths are mapped with required credentials
+- Privilege escalation paths are documented end-to-end
+- All post-exploitation activity stayed within scope

package/studios/security-assessment/stages/post-exploitation/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Post Exploitation Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Impact assessment documents the maximum access level achieved, data categories exposed, and blast radius of each access chain"
+- "Lateral movement analysis maps at least 3 potential pivot paths with the credentials or access required for each"
+- "Privilege escalation findings document the starting access level, technique used, and resulting access level with evidence"
+
+### Bad criteria — vague (no clear check)
+
+- "Impact is assessed"
+- "Lateral movement tested"
+- "Data exposure documented"
+

package/studios/security-assessment/stages/post-exploitation/review-agents/impact-accuracy.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify impact assessment accurately reflects the real-world risk.
+
+**Check:**
+- The agent **MUST** verify that lateral movement paths are documented with evidence at each step
+- The agent **MUST** verify that data exposure assessment reflects what an attacker could actually access
+- The agent **MUST** verify that access chain documentation is complete (initial access → current position)
+- The agent **MUST** verify that impact rating considers business context, not just technical severity

package/studios/security-assessment/stages/reconnaissance/STAGE.md

@@ -0,0 +1,13 @@
+---
+name: reconnaissance
+description: Passive and active information gathering about the target
+hats: [osint-analyst, network-mapper, verifier]
+fix_hats: [osint-analyst, feedback-assessor]
+review: auto
+elaboration: autonomous
+inputs: []
+---
+
+# Reconnaissance
+
+Passive and active information gathering about the target.

package/studios/security-assessment/stages/reconnaissance/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/security-assessment/stages/reconnaissance/hats/network-mapper.md

@@ -0,0 +1,9 @@
+**Focus:** Map the target's network topology, identify live hosts, open ports, and external-facing services within the authorized scope. Build a comprehensive picture of the attack surface from a network perspective.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** scan hosts or ranges outside the authorized scope
+- The agent **MUST NOT** use aggressive scan techniques that could cause denial of service
+- The agent **MUST NOT** fail to document scan parameters and timing for reproducibility
+- The agent **MUST NOT** skip UDP services or non-standard port ranges without justification
+- The agent **MUST** correlat network findings with OSINT data
+- The agent **MUST NOT** run scans without confirming the rules of engagement permit active probing

package/studios/security-assessment/stages/reconnaissance/hats/osint-analyst.md

@@ -0,0 +1,9 @@
+**Focus:** Collect publicly available information about the target using open-source intelligence techniques. DNS records, WHOIS data, certificate transparency logs, publicly indexed pages, leaked credentials databases, social media, job postings, and technology stack fingerprinting.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** acces systems or data outside the authorized scope
+- The agent **MUST NOT** fail to timestamp and source every finding
+- The agent **MUST NOT** use techniques that could alert the target during passive recon phases
+- The agent **MUST NOT** skip certificate transparency or DNS enumeration
+- The agent **MUST NOT** draw conclusions without corroborating across multiple sources
+- The agent **MUST NOT** store or exfiltrating any actual credentials found in public breaches