haiku-method 2.2.0

package/studios/data-pipeline/stages/transformation/hats/verifier.md

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit build artifact for the transformation stage of data-pipeline. Units here are transformation step — 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.
+
+## 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/data-pipeline/stages/transformation/outputs/DATA-MODEL.md

@@ -0,0 +1,25 @@
+---
+name: data-model
+location: (project source tree)
+scope: repo
+format: code
+required: true
+---
+
+# Data Model
+
+Transformation layer converting staged raw data into the target schema.
+
+## Expected Artifacts
+
+- **Transformation SQL/code** -- idempotent transformations producing deterministic output
+- **Data model documentation** -- entity relationships, grain definitions, and SCD strategies
+- **Business rules** -- centralized logic in named CTEs or macros
+- **Model tests** -- grain consistency and join correctness validations
+
+## Quality Signals
+
+- Transformations are idempotent and produce deterministic output
+- All business rules are centralized, not scattered across queries
+- Data model is documented with entity relationships and grain definitions
+- Grain consistency and join correctness are verified

package/studios/data-pipeline/stages/transformation/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Transformation Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Transformation SQL is idempotent — re-running produces the same result without duplicates"
+- "Data model follows the agreed dimensional modeling pattern with surrogate keys and SCD type documented per dimension"
+- "All business logic (e.g., revenue recognition rules, status mappings) is centralized in named CTEs or macros, not scattered across queries"
+
+### Bad criteria — vague (no clear check)
+
+- "Transformations are complete"
+- "Data model looks good"
+- "Business logic is implemented"
+

package/studios/data-pipeline/stages/transformation/review-agents/data-quality.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify transformations produce correct, consistent output that matches the target schema.
+
+**Check:**
+- The agent **MUST** verify that type conversions handle edge cases (nulls, empty strings, timezone differences, encoding)
+- The agent **MUST** verify that business logic transformations match the documented rules exactly
+- The agent **MUST** verify that deduplication logic is deterministic and handles all key collision scenarios
+- The agent **MUST** verify that referential integrity is maintained across related entities

package/studios/data-pipeline/stages/validation/STAGE.md

@@ -0,0 +1,18 @@
+---
+name: validation
+description: Validate data quality, schema compliance, and business rules
+hats: [validator, data-quality-reviewer]
+fix_hats: [validator, feedback-assessor]
+review: ask
+elaboration: autonomous
+inputs:
+  - stage: transformation
+    discovery: modeled-data
+review-agents-include:
+  - stage: extraction
+    agents: [correctness]
+---
+
+# Validation
+
+Validate data quality, schema compliance, and business rules.

package/studios/data-pipeline/stages/validation/hats/data-quality-reviewer.md

@@ -0,0 +1,11 @@
+---
+interpretation: lens
+---
+**Focus:** Review the validation suite for coverage completeness and assertion quality. Verify that tests cover all critical data paths, that thresholds are appropriately tight, and that failure modes produce actionable diagnostics rather than opaque errors.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** rubber-stamp a validation suite without tracing coverage back to requirements
+- The agent **MUST NOT** accept row count checks as sufficient without uniqueness and referential integrity tests
+- The agent **MUST** verify that validation failures produce enough context to diagnose the root cause
+- The agent **MUST NOT** ignore SLA-related validations (freshness, completeness percentages)
+- The agent **MUST NOT** treat validation as a gate to pass rather than a safety net to maintain

package/studios/data-pipeline/stages/validation/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/data-pipeline/stages/validation/hats/validator.md

@@ -0,0 +1,8 @@
+**Focus:** Build and run data quality checks that verify schema compliance, referential integrity, uniqueness, accepted value ranges, row count reconciliation, and business rule correctness. Every assertion should be specific, automated, and produce a clear pass/fail/warning result.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** write only "happy path" tests without edge case coverage
+- The agent **MUST NOT** check row counts without also checking for duplicates
+- The agent **MUST NOT** validate schema structure but not actual data values
+- The agent **MUST NOT** use overly loose thresholds that mask real quality issues
+- The agent **MUST** distinguish between blocking failures and non-blocking warnings

package/studios/data-pipeline/stages/validation/outputs/VALIDATION-REPORT.md

@@ -0,0 +1,25 @@
+---
+name: validation-report
+location: .haiku/intents/{intent-slug}/stages/validation/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Validation Report
+
+Data quality verification results covering schema compliance, business rules, and reconciliation.
+
+## Expected Artifacts
+
+- **Quality check results** -- uniqueness, not-null, referential integrity, and value range checks per target table
+- **Row count reconciliation** -- source-to-target variance within agreed tolerance
+- **Business rule tests** -- edge case verification for critical transformations
+- **Coverage summary** -- percentage of target tables with passing quality checks
+
+## Quality Signals
+
+- Quality checks cover all target tables with no unchecked entities
+- Row count reconciliation is within agreed tolerance thresholds
+- At least 3 edge cases are tested per critical transformation
+- Failed checks have documented remediation actions

package/studios/data-pipeline/stages/validation/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Validation Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Data quality checks cover uniqueness, not-null constraints, referential integrity, and accepted value ranges for every target table"
+- "Row count reconciliation between source and target is within the agreed tolerance (e.g., < 0.1% variance)"
+- "Business rule tests verify at least 3 known edge cases per critical transformation (e.g., timezone handling, currency conversion, null propagation)"
+
+### Bad criteria — vague (no clear check)
+
+- "Data quality is validated"
+- "Tests pass"
+- "Business rules are checked"
+

package/studios/data-pipeline/stages/validation/review-agents/coverage.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify validation rules cover all data quality dimensions.
+
+**Check:**
+- The agent **MUST** verify that schema compliance checks cover all fields (type, format, range, nullability)
+- The agent **MUST** verify that business rule validations match the transformation specifications
+- The agent **MUST** verify that row count reconciliation between source and target is performed
+- The agent **MUST** verify that sample-based spot checks verify actual data values, not just structure

package/studios/dev-evangelism/STUDIO.md

@@ -0,0 +1,11 @@
+---
+name: dev-evangelism
+description: Developer evangelism lifecycle — research, narrative, create, publish, measure
+stages: [research, narrative, create, publish, measure]
+category: content
+default_model: sonnet
+---
+
+# Developer Evangelism Studio
+
+Lifecycle for developer-facing content that builds community, drives adoption, and establishes technical brand. Covers conference talks, blog posts, demos, videos, and community engagement from audience research through impact measurement.

package/studios/dev-evangelism/examples/launch-conference-talk/intent.md

@@ -0,0 +1,17 @@
+---
+title: launch-conference-talk
+studio: dev-evangelism
+stages: [research, narrative, create, publish, measure]
+status: complete
+---
+
+# ReactConf Talk: Server Components in Production
+
+25-minute ReactConf talk on shipping React Server Components in production. Audience has read the docs but hasn't built anything real yet — the talk bridges the theory/practice gap with one anchor demo and a narrative arc around the tradeoffs we hit.
+
+## Goals
+
+- Narrative arc: what we expected → what broke → what we learned
+- One anchor live demo (streaming data + RSC boundaries) that runs in under 3 minutes
+- Code walkthroughs in slides for the non-demo content
+- Post-talk blog + repo drop within 48 hours

package/studios/dev-evangelism/examples/launch-conference-talk/pre-intent.yml

@@ -0,0 +1,17 @@
+related:
+  - marketing
+  - documentation
+  - product-strategy
+turns:
+  - role: user
+    text: "I'm speaking at ReactConf about our new server components work."
+  - role: agent
+    text: "What's the audience's baseline — brand new to RSC or already shipping?"
+  - role: user
+    text: "Mixed. Assume they've read the docs but haven't built anything production."
+  - role: agent
+    text: "Slot length and demo depth?"
+  - role: user
+    text: "25 minutes. One live demo, rest slides and code walkthroughs."
+  - role: agent
+    text: "Got it — narrative-first talk with one anchor demo, mixed-experience audience."

package/studios/dev-evangelism/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/dev-evangelism/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/dev-evangelism/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/dev-evangelism/stages/create/STAGE.md

@@ -0,0 +1,15 @@
+---
+name: create
+description: Produce the content — posts, slides, demos, videos
+hats: [content-creator, demo-builder, verifier]
+fix_hats: [content-creator, feedback-assessor]
+review: ask
+elaboration: autonomous
+inputs:
+  - stage: narrative
+    discovery: story-arc
+---
+
+# Create
+
+Produce the content — posts, slides, demos, videos.

package/studios/dev-evangelism/stages/create/discovery/CONTENT-PACKAGE.md

@@ -0,0 +1,28 @@
+---
+name: content-package
+location: .haiku/intents/{intent-slug}/knowledge/CONTENT-PACKAGE.md
+scope: intent
+format: text
+required: true
+---
+
+# Content Package
+
+The collection of developer evangelism content produced for multi-channel distribution. This output feeds the publish stage for distribution planning.
+
+## Content Guide
+
+Organize the package by content format and target audience:
+
+- **Blog posts** -- technically grounded articles with working code examples and clear takeaways
+- **Talk materials** -- slides following the narrative arc with speaker notes and timing
+- **Demos** -- working projects with README, setup instructions, and annotated code
+- **Video content** -- scripts or outlines with technical verification notes
+- **Code examples** -- standalone snippets that compile and run, annotated for context
+
+## Quality Signals
+
+- Code examples compile and run without modification
+- Demos are reproducible from a clean environment
+- Each asset follows the narrative arc and delivers key takeaways
+- Technical claims are substantiated by working examples

package/studios/dev-evangelism/stages/create/hats/content-creator.md

@@ -0,0 +1,8 @@
+**Focus:** Produce the developer content — blog posts, talk slides, video scripts — that executes the narrative arc. Prioritize technical substance and developer utility over production polish.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** write code examples that cannot compile or run
+- The agent **MUST NOT** create slides with walls of text instead of visual storytelling
+- The agent **MUST NOT** deviate from the narrative arc without justification
+- The agent **MUST NOT** produce content that reads as marketing material rather than technical education
+- The agent **MUST NOT** leave placeholder code or TODO sections in finished assets

package/studios/dev-evangelism/stages/create/hats/demo-builder.md

@@ -0,0 +1,8 @@
+**Focus:** Build working demos and code examples that prove the narrative's technical claims. Ensure demos are reproducible, well-documented, and suitable for live presentation or self-guided exploration.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** create demos that require undocumented environment setup
+- The agent **MUST NOT** build fragile demos that break under live conditions
+- The agent **MUST NOT** hardcode secrets, API keys, or environment-specific paths
+- The agent **MUST NOT** skip error handling that would cause confusing failures during presentation
+- The agent **MUST** verify that each demo runs end-to-end from a clean environment

package/studios/dev-evangelism/stages/create/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/dev-evangelism/stages/create/hats/verifier.md

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit build artifact for the create stage of dev-evangelism. Units here are content artifact — 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.
+
+## 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/dev-evangelism/stages/create/outputs/CONTENT-PACKAGE.md

@@ -0,0 +1,25 @@
+---
+name: content-package
+location: .haiku/intents/{intent-slug}/stages/create/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Content Package
+
+All produced content assets -- blog posts, slides, demos, videos -- ready for distribution.
+
+## Expected Artifacts
+
+- **Blog posts** -- technically grounded with working code examples and clear takeaways
+- **Talk materials** -- slides following the narrative arc, speaker notes, and timing guidance
+- **Demos** -- working projects with README, setup instructions, and annotated code
+- **Video scripts** -- structured scripts or outlines with technical verification notes
+
+## Quality Signals
+
+- Code examples compile and run without modification
+- Demos are reproducible from a clean environment
+- Each asset follows the narrative arc and delivers key takeaways
+- Content reads as technical education, not marketing material

package/studios/dev-evangelism/stages/create/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Create Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Blog post includes working code examples that the reader can copy-paste and run"
+- "Talk slides follow a narrative arc with no slide exceeding 3 bullet points"
+- "Demo runs end-to-end without manual setup steps beyond what the README documents"
+
+### Bad criteria — vague (no clear check)
+
+- "Content is created"
+- "Demo works"
+- "Slides look good"
+

package/studios/dev-evangelism/stages/create/review-agents/engagement.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify content is compelling and structured for developer engagement.
+
+**Check:**
+- The agent **MUST** verify that content follows the narrative arc and delivers the promised takeaways
+- The agent **MUST** verify that the hook grabs developer attention within the first paragraph or slide
+- The agent **MUST** verify that content format is appropriate for the target platform and audience segment
+- The agent **MUST** verify that calls-to-action are clear and the reader knows what to do next

package/studios/dev-evangelism/stages/create/review-agents/technical-accuracy.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify all technical content is accurate, runnable, and trustworthy.
+
+**Check:**
+- The agent **MUST** verify that code examples compile and run without errors
+- The agent **MUST** verify that demos are reproducible from a clean environment with documented setup
+- The agent **MUST** verify that technical claims are substantiated by working examples, not hand-waving
+- The agent **MUST** verify that API references, version numbers, and configuration details are current

package/studios/dev-evangelism/stages/measure/STAGE.md

@@ -0,0 +1,15 @@
+---
+name: measure
+description: Track engagement, gather feedback, identify follow-up opportunities
+hats: [analyst, feedback-synthesizer, verifier]
+fix_hats: [analyst, feedback-assessor]
+review: auto
+elaboration: autonomous
+inputs:
+  - stage: publish
+    discovery: distribution-log
+---
+
+# Measure
+
+Track engagement, gather feedback, identify follow-up opportunities.

package/studios/dev-evangelism/stages/measure/hats/analyst.md

@@ -0,0 +1,8 @@
+**Focus:** Track engagement metrics across all distribution channels, compare actuals against targets, and identify what drove success or underperformance. Surface patterns across content formats and audience segments.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** report vanity metrics (impressions, likes) without connecting them to meaningful outcomes
+- The agent **MUST NOT** attribute causation where only correlation exists
+- The agent **MUST NOT** compare metrics across channels without normalizing for platform differences
+- The agent **MUST NOT** ignore underperforming channels without analyzing why
+- The agent **MUST** distinguish between reach (who saw it) and engagement (who acted on it)

package/studios/dev-evangelism/stages/measure/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/dev-evangelism/stages/measure/hats/feedback-synthesizer.md

@@ -0,0 +1,8 @@
+**Focus:** Gather and categorize developer feedback from comments, community discussions, and direct responses. Synthesize qualitative signals into actionable themes and identify follow-up content opportunities.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** cherry-pick only positive feedback while ignoring criticism
+- The agent **MUST NOT** over-index on a single loud voice instead of identifying patterns
+- The agent **MUST NOT** categorize feedback without preserving representative quotes
+- The agent **MUST NOT** recommend follow-ups without connecting them to specific feedback themes
+- The agent **MUST** flag feedback that reveals misunderstandings the content should have prevented

package/studios/dev-evangelism/stages/measure/hats/verifier.md

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

package/studios/dev-evangelism/stages/measure/outputs/IMPACT-REPORT.md

@@ -0,0 +1,25 @@
+---
+name: impact-report
+location: .haiku/intents/{intent-slug}/stages/measure/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Impact Report
+
+Engagement analysis, feedback synthesis, and follow-up recommendations.
+
+## Expected Artifacts
+
+- **Engagement metrics** -- actuals vs. targets with channel-level breakdown
+- **Audience analysis** -- which developer segments engaged and through what formats
+- **Feedback synthesis** -- categorized community feedback with sentiment and notable quotes
+- **Follow-up recommendations** -- prioritized next actions with projected reach and effort
+
+## Quality Signals
+
+- Metrics compare actuals against defined targets with variance analysis
+- Channel breakdown identifies top and bottom performers with specific drivers
+- Feedback categories are backed by representative developer quotes
+- Recommendations connect to specific feedback themes and audience needs

package/studios/dev-evangelism/stages/measure/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Measure Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Impact report compares actual engagement metrics against targets with variance analysis per channel"
+- "Feedback synthesis categorizes developer responses into actionable themes with sentiment analysis"
+- "Follow-up recommendations are prioritized by potential impact and effort"
+
+### Bad criteria — vague (no clear check)
+
+- "Metrics are tracked"
+- "Feedback is gathered"
+- "Report is written"
+

package/studios/dev-evangelism/stages/measure/review-agents/roi.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the impact analysis is data-driven and produces actionable recommendations.
+
+**Check:**
+- The agent **MUST** verify that metrics compare actuals against defined targets, not just report raw numbers
+- The agent **MUST** verify that channel analysis identifies specific drivers of success or underperformance
+- The agent **MUST** verify that feedback synthesis is backed by representative developer quotes, not paraphrased assumptions
+- The agent **MUST** verify that follow-up recommendations are prioritized by projected impact and connected to specific findings

package/studios/dev-evangelism/stages/narrative/STAGE.md

@@ -0,0 +1,15 @@
+---
+name: narrative
+description: Craft story arcs, key messages, and takeaways
+hats: [storyteller, editor, verifier]
+fix_hats: [storyteller, feedback-assessor]
+review: ask
+elaboration: collaborative
+inputs:
+  - stage: research
+    discovery: audience-landscape
+---
+
+# Narrative
+
+Craft story arcs, key messages, and takeaways.