haiku-method 2.2.0

package/studios/hwdev/stages/manufacturing/hats/manufacturing-engineer.md

@@ -0,0 +1,7 @@
+**Focus:** Design the manufacturing process, coordinate with the contract manufacturer, own the first article inspection, and manage production ramp. Manufacturing decisions lock in — tooling, fixtures, and process changes are slow and expensive once volume starts.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST** run DFM review before committing to tooling
+- The agent **MUST NOT** skip first article inspection to hit a date
+- The agent **MUST** document the assembly process so it's reproducible by a different factory if needed
+- The agent **MUST** plan for yield loss, not assume 100%

package/studios/hwdev/stages/manufacturing/hats/qa-lead.md

@@ -0,0 +1,7 @@
+**Focus:** Own the production quality plan — incoming inspection, in-process checks, end-of-line functional test, and outgoing inspection sampling. Quality on the manufacturing line is a numbers game; the QA lead defines what passes, what fails, and what gets reworked.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST** define acceptance criteria quantitatively, not subjectively
+- The agent **MUST** verify the test fixtures actually exercise the functional requirements
+- The agent **MUST NOT** relax acceptance criteria to hit yield targets
+- The agent **MUST** track defect rates and trigger corrective action when thresholds are exceeded

package/studios/hwdev/stages/manufacturing/hats/verifier.md

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

package/studios/hwdev/stages/manufacturing/outputs/PRODUCTION.md

@@ -0,0 +1,28 @@
+---
+name: production
+location: (factory floor + QA systems)
+scope: external
+format: artifact
+required: true
+---
+
+# Production
+
+The state of the manufacturing line producing shippable units at target volume with acceptable yield and quality. This is not a document in the intent directory; it is the state of the outside world after manufacturing ramp.
+
+## Content Guide
+
+Production is ramped when:
+- **DFM review** is complete with all findings addressed
+- **Tooling and fixtures** are built and validated
+- **First article inspection** has passed
+- **Assembly process** is documented and reproducible
+- **QA plan** is operational with functional test at end-of-line
+- **Yield** is at or above target after ramp period
+
+## Quality Signals
+
+- First article inspection passed without reopening design
+- Defect rates are within acceptance thresholds
+- Assembly process can be reproduced at a second factory if needed
+- Functional test at end-of-line catches the defect modes seen during validation

package/studios/hwdev/stages/manufacturing/phases/ELABORATION.md

@@ -0,0 +1,46 @@
+# Manufacturing Stage — Elaboration
+
+Manufacturing is an **operational** stage. Its units are discrete operational steps in the design-for-manufacturability, assembly-process, QA-sampling, and production-ramp pipeline. Each unit specifies preconditions, action, post-condition check, and rollback.
+
+## What a unit IS in this stage
+
+One operational step in the production pipeline. Examples:
+
+- "DFM review checklist run — feedback ingested into design or signed off"
+- "Assembly process spec — line layout, station-by-station operations, takt time"
+- "First-article inspection plan — sample size, instruments, accept/reject criteria"
+- "QA sampling plan — AQL level, defect classification, re-test policy"
+- "Production ramp gate — pilot run sample size, yield threshold, escalation path"
+- "ESD / clean-room compliance pass — measurement record, certification scan"
+
+What a unit is **NOT** in this stage:
+
+- ❌ A design change (those belong back in `design` — file a feedback if the design is unmanufacturable)
+- ❌ A field-failure RMA process (that's a post-launch concern, not initial manufacturing)
+- ❌ A regulatory cert step (those belong in `validation`)
+
+## What "completion criteria" means here
+
+Operational-step criteria specify **preconditions, action, post-condition check, and rollback** — and must produce evidence that survives a quality audit.
+
+### Good criteria — concrete and audit-ready
+
+- "First-article inspection: 5 units pulled from the first production run, dimensional checks logged in `manufacturing/fai/run-001.csv`, all measurements within drawing tolerance"
+- "Assembly station 3 (paste / placement) post-condition: solder paste inspection (SPI) reports >98% pad coverage on a 30-board sample, recorded with timestamps"
+- "Pilot run gate: yield ≥ 95% on a 100-unit pilot before authorizing full production; failures categorized and recorded"
+
+### Bad criteria — vague or wrong-stage
+
+- ❌ "Manufacturing is ready" (tautological)
+- ❌ "Boards build OK" (no instruments, no threshold, no record)
+- ❌ "Design is good" — wrong stage; that's a `design` feedback if surfaced here
+
+## How verification happens
+
+Manufacturing artifacts are validated by the verifier hat (`hats/verifier.md`). The verifier checks **preconditions stated, action unambiguous, post-condition mechanically decidable with audit-trail evidence, rollback / scrap-policy declared where applicable** — body-content checks only, no frontmatter interpretation.
+
+## Anti-patterns
+
+- **No rollback / scrap policy.** A non-idempotent assembly step (board reflow, conformal coat) MUST state what happens to a unit that fails the post-condition — scrap, rework, or quarantine. Silence here ships defective product.
+- **Vague yield gates.** "Yield is acceptable" is not a check; "yield ≥ 95% on 100-unit pilot, computed as `passed / total`, recorded in `manufacturing/yield-pilot-001.csv`" is.
+- **Treating FAI as a formality.** First-article inspection is the last gate before tooling and process lock in. Every measurement must be logged and signed.

package/studios/hwdev/stages/manufacturing/review-agents/dfm-readiness.md

@@ -0,0 +1,10 @@
+---
+interpretation: strict
+---
+**Mandate:** The agent **MUST** verify the design is ready for manufacturing at target volume without outstanding DFM findings.
+
+**Check:**
+- The agent **MUST** verify DFM review is complete
+- The agent **MUST** verify every DFM finding is either fixed or accepted with documented justification
+- The agent **MUST** verify tooling and fixtures are built and validated
+- The agent **MUST** verify the assembly process is documented end-to-end

package/studios/hwdev/stages/manufacturing/review-agents/quality-plan.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the production quality plan will catch defects before they ship.
+
+**Check:**
+- The agent **MUST** verify functional test at end-of-line exercises every requirement
+- The agent **MUST** verify sampling plan and acceptance criteria are quantitative
+- The agent **MUST** verify defect escalation procedures are in place
+- The agent **MUST** flag any test fixture that does not exercise a safety-critical code path

package/studios/hwdev/stages/requirements/STAGE.md

@@ -0,0 +1,23 @@
+---
+name: requirements
+description: Functional, safety, and regulatory requirements
+hats: [systems-engineer, compliance-officer, distiller, verifier]
+fix_hats: [systems-engineer, feedback-assessor]
+review: [external, ask]
+elaboration: collaborative
+inputs:
+  - stage: inception
+    discovery: discovery
+---
+
+# Requirements
+
+Capture functional specifications (what the product does), safety requirements
+(hazard analysis, failure modes, fail-safes), and regulatory compliance
+obligations (FCC, CE, UL, FDA, RoHS, REACH depending on product class and
+target markets). These constrain every downstream decision — treat them as
+hard gates, not suggestions.
+
+Regulatory frameworks cannot be retrofitted. A product that wasn't designed
+for FCC compliance will fail cert, and fixing it means redesigning the PCB.
+Get the framework right here.

package/studios/hwdev/stages/requirements/discovery/FUNCTIONAL-REQUIREMENTS.md

@@ -0,0 +1,41 @@
+---
+name: functional-requirements
+location: .haiku/intents/{intent-slug}/knowledge/FUNCTIONAL-REQUIREMENTS.md
+scope: intent
+format: text
+required: true
+---
+
+# Functional Requirements
+
+Complete, testable, traceable specification of what the product does.
+
+## Content Guide
+
+### Functional Requirements
+Every requirement tagged with a unique identifier (e.g., FR-001, FR-002). Each requirement is:
+- **Testable** — can be verified by a specific test
+- **Unambiguous** — no subjective language
+- **Traceable** — linked back to discovery and forward to validation
+
+### Non-Functional Envelope
+- **Power** — peak, average, sleep
+- **Thermal** — operating range, max junction temp
+- **Mechanical** — dimensions, weight, mounting
+- **Environmental** — operating temp, humidity, ingress (IP rating), shock/vibration
+
+### External Interfaces
+- Every port, wire, wireless protocol with version and pinout if applicable
+
+### Lifetime and Reliability
+- Expected operating hours
+- Duty cycle
+- MTBF target if relevant
+- Field lifetime
+
+## Quality Signals
+
+- Every requirement has a unique ID
+- Every requirement is testable
+- Non-functional envelope is quantified, not qualitative
+- No requirement says "adequate" or "reasonable"

package/studios/hwdev/stages/requirements/discovery/SAFETY-ANALYSIS.md

@@ -0,0 +1,41 @@
+---
+name: safety-analysis
+location: .haiku/intents/{intent-slug}/knowledge/SAFETY-ANALYSIS.md
+scope: intent
+format: text
+required: true
+---
+
+# Safety Analysis
+
+Hazard identification, failure modes, and regulatory compliance map for the product.
+
+## Content Guide
+
+### Applicable Regulatory Frameworks
+Enumerated per target market: FCC/CE/UL/FDA/IC/RoHS/REACH/WEEE/IEC and any industry-specific standards. For each: certification path, test lab candidates, rough cost, and timeline.
+
+### Hazard Analysis
+For each identified hazard:
+- **Hazard description** — what can go wrong
+- **Likelihood** — how often, under what conditions
+- **Severity** — consequence if it occurs
+- **Mitigation** — how design, firmware, or user interface prevents or handles it
+- **Residual risk** — what remains after mitigation
+
+### Failure Modes
+- Electrical failure modes (shorts, opens, overcurrent, ESD)
+- Mechanical failure modes (drop, vibration, ingress)
+- Thermal failure modes (overheat, thermal runaway)
+- Software failure modes (hang, crash, bad state)
+- Per failure mode: fail-safe behavior
+
+### Standards to Design Against
+Specific standards the product must meet with section references where relevant.
+
+## Quality Signals
+
+- Every target market has its applicable frameworks identified
+- Every hazard has severity, likelihood, and mitigation
+- Fail-safes are specified, not hoped for
+- Cert cost and timeline are estimated, not deferred

package/studios/hwdev/stages/requirements/hats/compliance-officer.md

@@ -0,0 +1,7 @@
+**Focus:** Identify and document every regulatory framework that applies to this product in its target markets (FCC, CE, UL, FDA, IC, RoHS, REACH, WEEE, etc.), plus any safety standards (IEC, IEEE, ANSI). Compliance cannot be retrofitted — get it right here or pay 10x to redesign later.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST** identify every framework up front, not iteratively
+- The agent **MUST** flag any hazard that requires a specific mitigation in design or firmware
+- The agent **MUST** estimate cert cost and timeline for downstream planning
+- The agent **MUST NOT** defer compliance to validation — the validation stage tests against the framework identified here

package/studios/hwdev/stages/requirements/hats/distiller.md

@@ -0,0 +1,5 @@
+**Focus:** Decompose requirements work into units with verifiable criteria.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST** produce units whose completion can be verified by reviewing documents
+- The agent **MUST** ensure unit DAG is acyclic

package/studios/hwdev/stages/requirements/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/hwdev/stages/requirements/hats/systems-engineer.md

@@ -0,0 +1,7 @@
+**Focus:** Translate user needs from discovery into functional and non-functional requirements that are testable, traceable, and complete. Every downstream stage reads requirements — sloppy requirements produce sloppy hardware.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST** give every requirement a unique identifier for traceability
+- The agent **MUST NOT** write requirements that are not testable
+- The agent **MUST** specify non-functional envelope explicitly (not "fast enough")
+- The agent **MUST** identify every external interface, even low-bandwidth ones

package/studios/hwdev/stages/requirements/hats/verifier.md

@@ -0,0 +1,30 @@
+**Focus:** Validate the per-unit requirement-spec artifact for hardware requirements. Units here are requirement domains (functional / safety / regulatory / environmental / reliability) — testable obligations that downstream stages verify against. Validation rules check substance, completeness against the requirement category, and downstream-testability. Hardware requirement defects cascade into PCB redesigns and cert failures — be strict.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** read or interpret unit frontmatter. workflow engine territory.
+- The agent **MUST NOT** validate against build-stage executable verify-commands — requirements are testable obligations specifying what downstream `validation` MUST verify, not commands themselves.
+- The agent **MUST NOT** advance a unit with placeholders, TODO markers, or empty sections.
+- The agent **MUST NOT** soften regulatory requirements (e.g., advancing a regulatory unit that defers the framework choice). Reject — regulatory frameworks cannot be retrofitted.
+- The agent **MUST** name a specific failed criterion in any rejection.
+
+## What you check (BODY ONLY)
+
+### 1. Artifact answers its requirement domain
+Functional units list functional requirements with measurable outcomes. Safety units list hazards with mitigations and fail-safe behaviors. Regulatory units name the framework, cite the specific section, and prove applicability. Reject placeholders or domain-content gaps.
+
+### 2. Each requirement has a verification approach
+Every requirement listed in the body MUST name HOW it will be verified — test type (unit / system / regulatory / field), test method (instrument-based measurement / inspection / analysis / demonstration), and a measurable threshold where applicable. This is what makes downstream `validation` able to author the actual tests.
+
+Acceptable: "Powers on within 500ms of switch press — verified by oscilloscope measurement at TP3 with cold start (system in storage temperature for 24h)"
+Bad: "Powers on quickly" (no method, no threshold)
+
+### 3. Internal consistency
+- Functional requirements MUST NOT contradict safety requirements (a "high-throughput mode that bypasses overcurrent" is a contradiction).
+- Regulatory framework chosen MUST be appropriate for the product class declared in inception (medical device requires FDA/CE-MDR, not just FCC).
+- Mission and body content must align.
+
+### 4. Decision-register consistency
+The unit must not propose requirements contradicting recorded Decisions (e.g., requiring rechargeable battery when Decision N chose disposable). Cite the Decision ID.
+
+### 5. Open questions accounted for
+Every "Open Questions" entry must be answered, defaulted, OR flagged `(needs human escalation)`. **Regulatory open questions MUST default to `(needs human escalation)`** — agents do not have authority to defer regulatory framework decisions.

package/studios/hwdev/stages/requirements/phases/ELABORATION.md

@@ -0,0 +1,50 @@
+# Hardware Requirements Stage — Elaboration
+
+Hardware requirements is a **research / specification** stage. Its units are knowledge topics capturing functional, safety, and regulatory requirements. Requirements drive every downstream stage — design, firmware, manufacturing, validation. Defects here cascade into PCB redesigns, certification failures, and recalls. Be strict.
+
+This stage straddles research (gather and synthesize requirements) and specification (formalize them into testable obligations). Each unit is one requirement domain, not one feature.
+
+## What a unit IS in this stage
+
+One requirement domain. Examples:
+- "Functional requirements: power management"
+- "Functional requirements: connectivity (Wi-Fi/BLE/wired)"
+- "Safety requirements: thermal management"
+- "Safety requirements: overcurrent and short-circuit protection"
+- "Regulatory: FCC Part 15B emissions framework and applicability evidence"
+- "Regulatory: CE LVD and RED applicability"
+- "Environmental requirements: operating range, ingress protection, vibration"
+- "Reliability requirements: MTBF target and failure-mode analysis approach"
+
+What a unit is **NOT** in this stage:
+- ❌ A schematic, BOM, or PCB layout (those belong in `design`)
+- ❌ Firmware code or bring-up procedures (those belong in `firmware`)
+- ❌ Manufacturing process specs (those belong in `manufacturing`)
+- ❌ A test plan execution (those belong in `validation` — but the requirements DO specify what must be testable)
+
+## What "completion criteria" means here
+
+Requirements are **testable obligations**, not executable code. Criteria here describe what must be specified for downstream stages to verify against.
+
+### Good criteria — substantive and checkable
+
+- "Functional §2 lists every functional requirement with a measurable outcome (e.g., 'powers on within 500ms of switch press', 'connects to a known SSID within 5s of cold boot')"
+- "Safety §3 lists every hazard with: failure mode, mitigation, and fail-safe behavior — no hazard without all three"
+- "Regulatory §4 names the framework (e.g., 'FCC Part 15B'), cites the specific CFR or EN section, and provides applicability evidence (product class, deployment region, intended use)"
+- "Each requirement has a verification approach (test type: unit / system / regulatory / field) so downstream `validation` can author the test"
+- "Open questions: regulatory open questions MUST default to `(needs human escalation)` — agents do not have authority to defer regulatory framework decisions"
+
+### Bad criteria — vague or wrong-stage language
+
+- ❌ "Product is safe" (no specific hazard, no mitigation, no fail-safe)
+- ❌ "Compliant with applicable regulations" (which? cite them)
+- ❌ "Each unit has 3-5 verify-commands" (build-stage language; requirements don't have shell commands)
+- ❌ "Schematic implements the requirements" (wrong stage; design owns the schematic)
+
+## Anti-patterns
+
+- **Soft regulatory language.** "We'll figure out FCC later" is a hard reject. Regulatory frameworks cannot be retrofitted; pre-design lock-in is the whole point of this stage.
+- **Functional-safety contradictions.** A "high-throughput mode that bypasses overcurrent" is a contradiction; the mitigation exists to enforce safety. Reconcile or escalate.
+- **Drifting into design.** "Use the XYZ chipset" is a design decision, not a requirement. Requirements describe what must be true; design picks how to achieve it.
+
+> Note on the universal FSM_CONTRACTS_ELABORATE_BLOCK: the orchestrator currently injects build-class rules (`depends_on:` cycles, executable `quality_gates:`, criteria-with-verify-commands) into every elaborate dispatch. Those rules are correct for build-class stages but do not apply to this stage's requirement-spec units (which are testable obligations, not executable artifacts). Treat the build-class rules as defaults the framework hasn't yet split — author your units to the substance/testability shape above. (Architecture §7 known issue tracking the split.)

package/studios/hwdev/stages/requirements/review-agents/regulatory-coverage.md

@@ -0,0 +1,10 @@
+---
+interpretation: strict
+---
+**Mandate:** The agent **MUST** verify every target market has its applicable regulatory frameworks identified and the certification path understood.
+
+**Check:**
+- The agent **MUST** verify every target market listed in discovery has its frameworks identified
+- The agent **MUST** verify certification test labs have been identified for each framework
+- The agent **MUST** verify cert cost and timeline are estimated, not "TBD"
+- The agent **MUST** verify standards-driven design constraints are passed down to the design stage

package/studios/hwdev/stages/requirements/review-agents/traceability.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify every functional requirement is traceable to a user need in discovery and to a validation test plan.
+
+**Check:**
+- The agent **MUST** verify every requirement has a unique identifier
+- The agent **MUST** verify every requirement traces back to a discovery need
+- The agent **MUST** verify every requirement is testable by a specific method
+- The agent **MUST** flag any requirement that cannot be traced forward or backward

package/studios/hwdev/stages/validation/STAGE.md

@@ -0,0 +1,29 @@
+---
+name: validation
+description: HIL testing, environmental, and regulatory certification
+hats: [test-engineer, compliance-officer, validation-lead, verifier]
+fix_hats: [test-engineer, feedback-assessor]
+review: await
+elaboration: collaborative
+inputs:
+  - stage: requirements
+    discovery: functional-requirements
+  - stage: requirements
+    discovery: safety-analysis
+  - stage: design
+    output: schematic
+  - stage: firmware
+    output: firmware-binary
+---
+
+# Validation
+
+Hardware-in-the-loop testing, environmental testing (temperature, humidity,
+vibration, ESD, drop), and regulatory certification. Validation failures mean
+going back to design or firmware — this is where hardware projects find out
+whether their assumptions held, and the cost of being wrong grows with every
+downstream stage that already happened.
+
+Certification is often gated by an external lab with its own schedule. Plan
+for cert slots early; "we'll just submit when we're ready" is how launches
+slip by months.

package/studios/hwdev/stages/validation/hats/compliance-officer.md

@@ -0,0 +1,7 @@
+**Focus:** Coordinate regulatory certification testing with external labs. Pre-screen the product against cert requirements before formal submission to avoid expensive retests.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST** pre-scan before submitting to a cert lab
+- The agent **MUST** track lab submission status and turnaround times
+- The agent **MUST NOT** submit to cert without documentation the lab requires
+- The agent **MUST** respond to cert findings within the lab's feedback window

package/studios/hwdev/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/hwdev/stages/validation/hats/test-engineer.md

@@ -0,0 +1,7 @@
+**Focus:** Build and run the hardware-in-the-loop (HIL) test rig, environmental tests (temperature, humidity, vibration, ESD, drop), and regression coverage against functional requirements.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST** run tests on production-representative hardware, not dev boards
+- The agent **MUST** test every functional requirement, not a convenient subset
+- The agent **MUST NOT** accept "works on the bench" as validation — tests must be automated and reproducible
+- The agent **MUST** test the environmental envelope to the specified limits

package/studios/hwdev/stages/validation/hats/validation-lead.md

@@ -0,0 +1,6 @@
+**Focus:** Own the overall validation plan, coordinate between test-engineer and compliance-officer, and judge release readiness based on aggregate validation results.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** declare validation complete with open high-severity findings
+- The agent **MUST** track every requirement to a passing validation artifact
+- The agent **MUST** surface risks from partial validation coverage to stakeholders

package/studios/hwdev/stages/validation/hats/verifier.md

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit verification artifact for the validation stage of hwdev. Units here are verification surface — verification surfaces that test built artifacts against requirements, contracts, or standards. Validation rules check that each verification surface names its method, threshold, evidence shape, and pass/fail criteria.
+
+**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. Verification surface scoped to a testable boundary
+The unit body MUST name exactly one boundary being verified (an API contract, a regulatory criterion, a hardware envelope, a behavior class). "Verify the system works" is a reject. The scope must be tight enough that pass/fail is unambiguous.
+
+### 2. Method, threshold, and evidence shape declared
+Every verification surface MUST name HOW it will be verified (test type / instrument / inspection / analysis / demonstration), the measurable threshold or expected outcome, and the shape of the recorded evidence (log file, oscilloscope trace, signed audit record, test-suite output).
+
+### 3. Pass/fail criteria are mechanical
+Pass/fail must be decidable without judgment calls. "Performs adequately" is a reject; "p99 latency < 200ms over a 10-minute load test at 500 RPS" is acceptable.
+
+### 4. Decision-register consistency
+The unit must not propose a verification approach contradicting a recorded Decision (e.g., verifying against an SLO that the user explicitly relaxed). Cite the Decision ID.
+
+### 5. Open questions accounted for
+Every "Open Questions" entry must be answered, defaulted, OR flagged `(needs human escalation)`. Verification gaps that ship are how regressions reach production.

package/studios/hwdev/stages/validation/outputs/CERTIFICATION.md

@@ -0,0 +1,43 @@
+---
+name: certification
+location: .haiku/intents/{intent-slug}/knowledge/CERTIFICATION.md
+scope: intent
+format: text
+required: true
+---
+
+# Certification
+
+Record of all regulatory certifications obtained for the product and the underlying test evidence.
+
+## Content Guide
+
+### Certifications Obtained
+Per regulatory framework:
+- Framework name and target market
+- Cert lab and cert document reference
+- Date of certification
+- Expiration (if applicable)
+- Scope of cert (which product variants, which firmware versions)
+
+### Functional Validation
+- Test plan coverage against functional requirements
+- Pass/fail per requirement
+- Open findings and their status
+
+### Environmental Validation
+- Envelope tested vs. envelope specified
+- Pass/fail per test type (temp, humidity, vibration, ESD, drop)
+- Open findings and their status
+
+### HIL Results
+- Test rig configuration
+- Test execution reports
+- Regression trend
+
+## Quality Signals
+
+- Every functional requirement has a linked validation test and result
+- Every regulatory framework from requirements has a cert document
+- Environmental testing covered the full specified envelope
+- No open high-severity findings at release time

package/studios/hwdev/stages/validation/phases/ELABORATION.md

@@ -0,0 +1,48 @@
+# Validation Stage — Elaboration
+
+Validation is a **validation / certification** stage. Its units are verification surfaces — one per testable boundary or compliance area. Each unit specifies the surface, method, threshold, evidence shape, and pass/fail criteria.
+
+## What a unit IS in this stage
+
+One verification surface. Examples:
+
+- "Functional verification — every `requirements/functional/REQ-FN-NN` has a HIL or bench test that exercises it and records a pass/fail"
+- "Environmental: thermal — operating temperature sweep with chamber log, pass criteria mapped to spec"
+- "Environmental: ESD — IEC 61000-4-2 contact / air discharge sweep, pass at declared performance criterion"
+- "Environmental: drop / vibration — per declared use case (consumer, industrial, automotive)"
+- "EMC pre-cert — radiated/conducted emissions and immunity, pre-scan at internal lab before booking the certified lab"
+- "Regulatory: FCC Part 15 / CE-RED / ISED RSS — submission package, lab-booking calendar"
+- "Reliability: MTBF / HALT — accelerated-life test plan with statistical pass criteria"
+
+What a unit is **NOT** in this stage:
+
+- ❌ A design change (those belong back in `design`; raise feedback)
+- ❌ A firmware bug fix (those belong back in `firmware`)
+- ❌ A manufacturing process tweak (those belong in `manufacturing`)
+
+## What "completion criteria" means here
+
+Verification-surface criteria specify **method, instrument, threshold, evidence shape, and pass/fail criteria** — pass/fail must be decidable without judgment calls.
+
+### Good criteria — mechanical and audit-ready
+
+- "Method: oscilloscope at TP3, cold-start from 24h soak at -40°C. Threshold: power-on within 500ms ±50ms. Evidence: scope screenshot + CSV. Pass: ≥ 19/20 units within threshold"
+- "Method: IEC 61000-4-2, contact discharge ±8kV / air ±15kV at 50 named coupling points. Threshold: performance criterion B (self-recoverable). Evidence: lab report PDF, signed by test engineer. Pass: criterion B met at all coupling points"
+- "Method: FCC Part 15 Subpart B radiated emissions, 30 MHz to 1 GHz. Threshold: Class B limits with 6 dB margin. Evidence: certified-lab report. Pass: all emissions ≥ 6 dB below limit"
+
+### Bad criteria — vague or judgmental
+
+- ❌ "Performs adequately" (not decidable)
+- ❌ "Passes EMC" (which standard? which limits? which evidence?)
+- ❌ "Looks good in the chamber" (no instrument, no threshold)
+
+## How verification happens
+
+Validation artifacts are themselves verified by the verifier hat (`hats/verifier.md`). Note the meta-level: the unit body IS a verification plan; the verifier-hat checks that the plan is **scoped, methodical, and decidable** — body-content checks only, no frontmatter interpretation. The actual certification work is performed by the test-engineer / compliance-officer / validation-lead hats; the verifier-hat checks that their deliverable is sufficient for downstream release / cert sign-off.
+
+## Anti-patterns
+
+- **Plans without thresholds.** "Run drop test and observe" is not a verification surface; "drop from 1.2m onto concrete on each face, ≤ 1 cosmetic defect, no functional failure across 10 units" is.
+- **Lumping multiple surfaces into one unit.** Functional + environmental + EMC + regulatory in a single "validation" unit defeats per-surface revisit / sign-off. One surface per unit.
+- **Skipping evidence shape.** "Tested OK" is not evidence; "scope trace + signed test record at `validation/runs/run-NN/`" is.
+- **Booking certified labs late.** Cert lab calendars run weeks-to-months out; the unit for "FCC submission" should include a `book-lab-by:` decision-class consideration even though the cert action itself is late.

package/studios/hwdev/stages/validation/review-agents/cert-completion.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify every regulatory framework identified in requirements has an obtained certification before manufacturing ramp.
+
+**Check:**
+- The agent **MUST** verify each framework listed in requirements has a cert document on file
+- The agent **MUST** verify cert scope matches the product variant going into manufacturing
+- The agent **MUST** flag any expiring certs or scope gaps
+- The agent **MUST** verify cert labs have returned formal results, not preliminary findings

package/studios/hwdev/stages/validation/review-agents/coverage.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify validation covers every functional requirement and every hazard from the safety analysis.
+
+**Check:**
+- The agent **MUST** verify every functional requirement has a passing test
+- The agent **MUST** verify every hazard mitigation has a test exercising the fail-safe
+- The agent **MUST** verify environmental testing covered the full specified envelope
+- The agent **MUST** flag any requirement or hazard without test coverage

package/studios/ideation/STUDIO.md

@@ -0,0 +1,13 @@
+---
+name: ideation
+description: Universal lifecycle for any creative or analytical work
+stages: [research, create, review, deliver]
+category: general
+default_model: sonnet
+---
+
+# Ideation Studio
+
+General-purpose lifecycle for creative, analytical, or exploratory work that
+doesn't fit a specialized domain. Works for content creation, research projects,
+documentation initiatives, or any work that follows a gather-create-review-deliver pattern.