haiku-method 2.2.0

package/studios/marketing/stages/research/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Research Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Market brief identifies at least 3 competitor campaigns with positioning analysis for each"
+- "Audience segments are defined with demographics, psychographics, and behavioral signals"
+- "Competitive gap analysis surfaces at least 2 underserved messaging angles"
+
+### Bad criteria — vague (no clear check)
+
+- "Research is thorough"
+- "Competitors are analyzed"
+- "Audience is understood"
+

package/studios/marketing/stages/research/review-agents/rigor.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify market research is based on evidence, not assumptions.
+
+**Check:**
+- The agent **MUST** verify that audience segments are defined with observable characteristics, not stereotypes
+- The agent **MUST** verify that competitive analysis covers actual capabilities, not just marketing claims
+- The agent **MUST** verify that data sources are cited and current
+- The agent **MUST** verify that conclusions are supported by the evidence presented

package/studios/marketing/stages/strategy/STAGE.md

@@ -0,0 +1,15 @@
+---
+name: strategy
+description: Define campaign goals, messaging framework, and channel strategy
+hats: [strategist, brand-reviewer]
+fix_hats: [strategist, feedback-assessor]
+review: ask
+elaboration: collaborative
+inputs:
+  - stage: research
+    discovery: market-brief
+---
+
+# Strategy
+
+Define campaign goals, messaging framework, and channel strategy.

package/studios/marketing/stages/strategy/discovery/MESSAGING-FRAMEWORK.md

@@ -0,0 +1,30 @@
+---
+name: messaging-framework
+location: .haiku/intents/{intent-slug}/knowledge/MESSAGING-FRAMEWORK.md
+scope: intent
+format: text
+required: true
+---
+
+# Messaging Framework
+
+Campaign strategy and messaging architecture. This output drives the content stage's asset creation and provides the measurement framework for the measure stage.
+
+## Content Guide
+
+Structure the framework around campaign execution needs:
+
+- **Campaign goals** — SMART objectives with target KPIs and measurement criteria
+- **Value proposition hierarchy** — primary message, supporting proof points, and differentiators
+- **Tone guidelines** — voice attributes, vocabulary preferences, and channel-specific tone adaptations
+- **Audience-message mapping** — which messages resonate with which segments and why
+- **Channel strategy** — selected channels mapped to audience segments with rationale and format requirements
+- **Objection handling** — anticipated audience objections with response frameworks
+- **Brand alignment notes** — brand reviewer's approved elements and any guardrails
+
+## Quality Signals
+
+- Every messaging choice traces back to a research finding in the market brief
+- Goals are quantified with specific KPIs, not aspirational statements
+- Tone guidelines are specific enough to evaluate copy against
+- Channel selections are justified by audience behavior data, not convention

package/studios/marketing/stages/strategy/hats/brand-reviewer.md

@@ -0,0 +1,11 @@
+---
+interpretation: lens
+---
+**Focus:** Evaluate the campaign strategy for brand alignment — ensure messaging, tone, and positioning are consistent with brand identity and don't create conflicts with existing brand promises or ongoing campaigns.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** rubber-stamp strategy without genuine brand scrutiny
+- The agent **MUST NOT** block effective messaging purely for brand orthodoxy when the data supports a shift
+- The agent **MUST NOT** review messaging in isolation without considering how it interacts with existing campaigns
+- The agent **MUST NOT** provide vague feedback ("not on-brand") without specifying what's misaligned and how to fix it
+- The agent **MUST NOT** ignore audience research when enforcing brand guidelines

package/studios/marketing/stages/strategy/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/marketing/stages/strategy/hats/strategist.md

@@ -0,0 +1,8 @@
+**Focus:** Translate research insights into a cohesive campaign strategy — define goals, build the messaging framework, select channels, and create the campaign architecture. Every strategic choice should trace back to a research finding.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** set vague goals that can't be measured ("increase brand awareness")
+- The agent **MUST NOT** build messaging that doesn't connect to audience pain points from research
+- The agent **MUST NOT** select channels based on convention rather than audience behavior data
+- The agent **MUST NOT** create a strategy disconnected from budget or resource constraints
+- The agent **MUST NOT** define KPIs that don't ladder up to campaign goals

package/studios/marketing/stages/strategy/outputs/MESSAGING-FRAMEWORK.md

@@ -0,0 +1,25 @@
+---
+name: messaging-framework
+location: .haiku/intents/{intent-slug}/stages/strategy/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Messaging Framework
+
+Campaign goals, value proposition hierarchy, tone guidelines, and channel strategy.
+
+## Expected Artifacts
+
+- **Value proposition** -- primary proposition with supporting proof points and tone guidelines
+- **Channel strategy** -- each audience segment mapped to specific channels with rationale
+- **Campaign goals** -- SMART goals with target KPIs
+- **Brand alignment** -- messaging validated against brand identity
+
+## Quality Signals
+
+- Messaging framework includes primary value proposition and supporting proof points
+- Channel strategy maps each audience segment to specific channels
+- Campaign goals are specific, measurable, achievable, relevant
+- Messaging aligns with brand identity without positioning conflicts

package/studios/marketing/stages/strategy/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Strategy Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Messaging framework includes primary value proposition, 3 supporting proof points, and tone guidelines"
+- "Channel strategy maps each audience segment to specific channels with rationale"
+- "Campaign goals are SMART — specific, measurable, achievable, relevant, time-bound"
+
+### Bad criteria — vague (no clear check)
+
+- "Strategy is complete"
+- "Messaging is clear"
+- "Channels are selected"
+

package/studios/marketing/stages/strategy/review-agents/consistency.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the strategy is internally consistent and aligned with brand.
+
+**Check:**
+- The agent **MUST** verify that messaging framework is consistent across all channels
+- The agent **MUST** verify that target audience matches the research findings
+- The agent **MUST** verify that campaign goals are measurable with defined KPIs
+- The agent **MUST** verify that strategy does not contradict existing brand guidelines or positioning

package/studios/marketing/templates/product-launch.md

@@ -0,0 +1,42 @@
+---
+name: product-launch
+studio: marketing
+description: Launch campaign for a new product or feature
+parameters:
+  - name: product
+    description: Product or feature being launched
+    required: true
+  - name: launch_date
+    description: Target launch date
+    required: false
+  - name: target_audience
+    description: Primary audience segment
+    required: false
+units:
+  - name: "audience-research"
+    stage: research
+    criteria:
+      - "Target audience for {{ product }} defined with observable characteristics"
+      - "Competitive messaging landscape mapped"
+      - "Key differentiators identified"
+  - name: "messaging-framework"
+    stage: strategy
+    criteria:
+      - "Core messaging defined (headline, value props, proof points)"
+      - "Channel strategy aligned with audience behavior"
+      - "KPIs defined with targets"
+  - name: "launch-assets"
+    stage: content
+    criteria:
+      - "Landing page copy finalized"
+      - "Email sequences drafted"
+      - "Social content calendar populated"
+  - name: "go-live"
+    stage: launch
+    criteria:
+      - "All assets live and tracking verified"
+      - "Distribution channels activated"
+      - "Day-1 metrics baseline captured"
+---
+
+Product launch campaign through the full marketing lifecycle.

package/studios/migration/STUDIO.md

@@ -0,0 +1,14 @@
+---
+name: migration
+description: System and data migration lifecycle for platform transitions, version upgrades, and data moves
+stages: [assessment, mapping, migrate, validation, cutover]
+category: operations
+default_model: sonnet
+---
+
+# Migration Studio
+
+Lifecycle for platform transitions, version upgrades, data moves, and system replacements.
+Use this studio when work involves moving data or functionality from one system, schema,
+or platform version to another — where integrity verification and rollback planning are
+essential. Covers the full arc from inventory through production cutover.

package/studios/migration/examples/mongo-to-postgres-migration/intent.md

@@ -0,0 +1,18 @@
+---
+title: mongo-to-postgres-migration
+studio: migration
+stages: [assessment, mapping, migrate, validation, cutover]
+status: complete
+---
+
+# User Service: MongoDB → Postgres
+
+Migrate the user service from MongoDB to Postgres with a 2-week dual-write overlap. Collapse the accidentally-nested document shape into a proper relational model with foreign keys. Read traffic flips after the dual-write window; Mongo is decommissioned 7 days after read cutover.
+
+## Goals
+
+- Design the relational schema — users, profiles, sessions, auth_methods
+- Dual-write path in the service (writes hit both stores atomically)
+- Backfill job reconciling historical Mongo data into Postgres with checksum validation
+- Read cutover with feature flag + instant rollback capability
+- Zero data loss, zero duplicate identity rows post-cutover

package/studios/migration/examples/mongo-to-postgres-migration/pre-intent.yml

@@ -0,0 +1,17 @@
+related:
+  - data-pipeline
+  - software
+  - security-assessment
+turns:
+  - role: user
+    text: "Move the user service from MongoDB to Postgres."
+  - role: agent
+    text: "Is this a clean cut-over or a dual-write period first?"
+  - role: user
+    text: "Dual-write for 2 weeks, then read from Postgres, then drop Mongo."
+  - role: agent
+    text: "What's the schema story — flatten the nested documents or relational model?"
+  - role: user
+    text: "Relational. The nesting was accidental; the real model has foreign keys."
+  - role: agent
+    text: "Got it — dual-write migration to a proper relational model, 2-week overlap."

package/studios/migration/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/migration/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/migration/operations/data-sync-monitor.md

@@ -0,0 +1,20 @@
+---
+name: data-sync-monitor
+type: reactive
+owner: agent
+trigger: "migration active"
+runtime: node
+---
+
+**Purpose:** During active migration, continuously verify data sync between source and target.
+
+**Procedure:**
+- Compare row counts between source and target for migrated entities
+- Run checksum verification on a sample of records
+- Verify no data loss from in-flight writes during sync windows
+- Alert on sync lag exceeding threshold
+
+**Signals:**
+- Migration is in progress
+- Sync lag exceeds configured threshold
+- Row count discrepancy detected

package/studios/migration/operations/rollback-readiness.md

@@ -0,0 +1,20 @@
+---
+name: rollback-readiness
+type: scheduled
+owner: human
+frequency: "daily"
+---
+
+**Purpose:** During active migration, verify rollback capability daily. The window for safe rollback narrows over time.
+
+**Procedure:**
+- [ ] Confirm source system is still operational and data-current
+- [ ] Verify rollback scripts/procedures are tested
+- [ ] Document new data written to target since last check
+- [ ] Assess rollback complexity (point-of-no-return approaching?)
+- [ ] Confirm all stakeholders know the rollback trigger criteria
+
+**Signals:**
+- Daily during active cutover period
+- After any data sync issue
+- When approaching point-of-no-return

package/studios/migration/reflections/cutover-execution.md

@@ -0,0 +1,17 @@
+---
+name: cutover-execution
+studio: migration
+---
+
+**Analyze:** Cutover plan vs actual execution, downtime duration, stakeholder communication effectiveness.
+
+**Look for:**
+- Steps that took longer than planned
+- Rollback points that were triggered (or almost triggered)
+- Communication gaps during the cutover window
+- Post-cutover issues discovered by users vs caught by validation
+
+**Produce:**
+- Plan vs actual timeline comparison
+- Risk assessment accuracy evaluation
+- Recommendations for cutover planning in future migrations

package/studios/migration/reflections/data-integrity.md

@@ -0,0 +1,17 @@
+---
+name: data-integrity
+studio: migration
+---
+
+**Analyze:** Data reconciliation results, record loss/corruption rates, validation failures.
+
+**Look for:**
+- Entity types with the most reconciliation discrepancies
+- Data transformations that introduced errors
+- Edge cases that the mapping missed (encoding, timezone, null handling)
+- Whether validation caught issues before or after cutover
+
+**Produce:**
+- Data integrity scorecard by entity type
+- Transformation accuracy assessment
+- Recommendations for mapping and validation improvements in future migrations

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

@@ -0,0 +1,13 @@
+---
+name: assessment
+description: Inventory what's being migrated, identify risks and dependencies
+hats: [migration-analyst, risk-assessor]
+fix_hats: [migration-analyst, feedback-assessor]
+review: auto
+elaboration: collaborative
+inputs: []
+---
+
+# Assessment
+
+Inventory what's being migrated, identify risks and dependencies.

package/studios/migration/stages/assessment/discovery/MIGRATION-INVENTORY.md

@@ -0,0 +1,30 @@
+---
+name: migration-inventory
+location: .haiku/intents/{intent-slug}/knowledge/MIGRATION-INVENTORY.md
+scope: intent
+format: text
+required: true
+---
+
+# Migration Inventory
+
+Document the complete catalog of artifacts in scope for migration. This output feeds the mapping stage as its foundational context.
+
+## Content Guide
+
+Structure the inventory around the migration scope:
+
+- **Source system overview** — platform, version, architecture summary
+- **Artifact catalog** — schemas, tables, services, jobs, integrations with size/volume estimates
+- **Dependency graph** — which artifacts depend on which, migration ordering constraints
+- **Risk register** — categorized risks with severity, likelihood, and mitigation strategies
+- **Data volume estimates** — row counts, storage sizes, growth rates
+- **Downstream consumers** — systems that read from or depend on the source
+- **Migration ordering constraints** — what must move first, what can move in parallel
+
+## Quality Signals
+
+- Every artifact is accounted for, including ancillary systems (caches, queues, cron jobs)
+- Dependencies are verified against the live system, not just documentation
+- Risks have concrete mitigations, not just descriptions
+- Volume estimates inform the migration strategy (bulk vs. incremental vs. streaming)

package/studios/migration/stages/assessment/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/migration/stages/assessment/hats/migration-analyst.md

@@ -0,0 +1,8 @@
+**Focus:** Inventory every artifact in scope — schemas, data stores, services, integrations, jobs, and configuration. Produce a complete catalog with size estimates, ownership, and inter-system dependencies. Nothing can be migrated safely if it isn't inventoried first.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** declare the inventory complete without verifying against the live system
+- The agent **MUST NOT** ignore ancillary systems (cron jobs, caches, queues) that depend on the source
+- The agent **MUST NOT** list artifacts without documenting their relationships
+- The agent **MUST NOT** assume the documentation matches the actual deployed state
+- The agent **MUST NOT** skip volume estimates that affect migration strategy (bulk vs. incremental)

package/studios/migration/stages/assessment/hats/risk-assessor.md

@@ -0,0 +1,8 @@
+**Focus:** Identify what can go wrong — data loss vectors, downtime windows, compatibility gaps, and blast radius. Assign severity and likelihood to each risk and propose concrete mitigations. Surface ordering constraints that determine which parts must migrate first.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** list risks without mitigation strategies
+- The agent **MUST NOT** treat all risks as equal severity
+- The agent **MUST NOT** ignore the human/process risks (team readiness, tribal knowledge, manual steps)
+- The agent **MUST NOT** assume rollback is always possible without verifying
+- The agent **MUST NOT** overlook data in transit during the migration window

package/studios/migration/stages/assessment/outputs/MIGRATION-INVENTORY.md

@@ -0,0 +1,25 @@
+---
+name: migration-inventory
+location: .haiku/intents/{intent-slug}/stages/assessment/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Migration Inventory
+
+Complete catalog of source artifacts with risk register and dependency graph.
+
+## Expected Artifacts
+
+- **Source catalog** -- all schemas, services, data stores, and integrations to be migrated
+- **Risk register** -- risks categorized by type (data loss, downtime, compatibility) with severity ratings
+- **Dependency graph** -- migration ordering constraints and parallel opportunities
+- **Volume estimates** -- row counts and data sizes for each source artifact
+
+## Quality Signals
+
+- Inventory covers all source artifacts with no undiscovered systems
+- Risk register identifies at least 3 categories with severity and mitigation strategies
+- Dependency graph shows which systems must migrate in sequence vs parallel
+- Each risk has a mitigation strategy documented

package/studios/migration/stages/assessment/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Assessment Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Inventory covers all source tables/services with row counts and dependency mappings"
+- "Risk register identifies at least 3 categories (data loss, downtime, compatibility) with severity ratings"
+- "Dependency graph shows which systems must migrate in sequence vs. parallel"
+
+### Bad criteria — vague (no clear check)
+
+- "Assessment is complete"
+- "Risks are documented"
+- "Systems are inventoried"
+

package/studios/migration/stages/assessment/review-agents/risk-coverage.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify all migration risks and dependencies are identified.
+
+**Check:**
+- The agent **MUST** verify that every system, data store, and integration in the migration scope is inventoried
+- The agent **MUST** verify that dependencies between migrated components are mapped (migration order matters)
+- The agent **MUST** verify that risk assessment covers data loss, downtime, and functional regression scenarios
+- The agent **MUST** verify that rollback feasibility is assessed for each component

package/studios/migration/stages/cutover/STAGE.md

@@ -0,0 +1,20 @@
+---
+name: cutover
+description: Plan and execute the production cutover with rollback procedures
+hats: [cutover-coordinator, rollback-engineer, verifier]
+fix_hats: [cutover-coordinator, feedback-assessor]
+review: external
+elaboration: collaborative
+inputs:
+  - stage: validation
+    discovery: validation-report
+review-agents-include:
+  - stage: migrate
+    agents: [data-integrity]
+  - stage: validation
+    agents: [parity]
+---
+
+# Cutover
+
+Plan and execute the production cutover with rollback procedures.

package/studios/migration/stages/cutover/discovery/CUTOVER-RUNBOOK.md

@@ -0,0 +1,31 @@
+---
+name: cutover-runbook
+location: .haiku/intents/{intent-slug}/knowledge/CUTOVER-RUNBOOK.md
+scope: intent
+format: text
+required: true
+---
+
+# Cutover Runbook
+
+Document the production cutover plan, rollback procedure, and post-cutover verification. This is the final deliverable of the migration studio.
+
+## Content Guide
+
+Structure the runbook around execution phases:
+
+- **Pre-cutover checklist** — prerequisites verified before starting
+- **Cutover steps** — sequenced steps with owner, expected duration, and go/no-go checkpoints
+- **Traffic routing plan** — how traffic shifts from source to target
+- **Point of no return** — the step after which rollback becomes significantly more expensive
+- **Rollback procedure** — step-by-step restoration to pre-migration state with RTO verification
+- **Post-cutover verification** — checks confirming the target is serving correctly
+- **Communication plan** — stakeholder notifications for maintenance window, completion, and escalation
+- **Escalation contacts** — who to reach for each category of issue
+
+## Quality Signals
+
+- Every step has an explicit owner and go/no-go criteria
+- Rollback procedure is tested end-to-end, not theoretical
+- Point of no return is clearly marked and understood by all participants
+- Post-cutover verification reuses validation checks from the validation stage

package/studios/migration/stages/cutover/hats/cutover-coordinator.md

@@ -0,0 +1,8 @@
+**Focus:** Plan and sequence the production cutover. Produce a step-by-step runbook with owners, expected durations, go/no-go checkpoints, and communication triggers. Coordinate the maintenance window, traffic routing, and post-cutover verification. The cutover is a one-shot operation — rehearse it until it's boring.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** treat the cutover as "just run the scripts in prod"
+- The agent **MUST NOT** skip a rehearsal cutover in a staging environment
+- The agent **MUST** define explicit go/no-go criteria at each checkpoint
+- The agent **MUST NOT** leave the communication plan until the last minute
+- The agent **MUST NOT** assume all stakeholders know the maintenance window without explicit notification

package/studios/migration/stages/cutover/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/migration/stages/cutover/hats/rollback-engineer.md

@@ -0,0 +1,8 @@
+**Focus:** Design, implement, and test the rollback procedure that restores the source system to its pre-migration state. Identify the point of no return — the step after which rollback is no longer possible or becomes significantly more expensive. Ensure the rollback can execute within the defined RTO.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** assume rollback will work without testing it end-to-end
+- The agent **MUST** define a clear point of no return
+- The agent **MUST NOT** write rollback scripts that depend on state destroyed by the forward migration
+- The agent **MUST NOT** ignore data written to the target after cutover that would be lost on rollback
+- The agent **MUST NOT** treat rollback as optional because "the migration will work"

package/studios/migration/stages/cutover/hats/verifier.md

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit operational artifact for the cutover stage of migration. Units here are cutover step — 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.