haiku-method 2.2.0

package/studios/hwdev/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/hwdev/stages/design/STAGE.md

@@ -0,0 +1,37 @@
+---
+name: design
+description: Schematic, PCB layout, mechanical, and BOM
+hats: [electrical-engineer, mechanical-engineer, pcb-designer, design-reviewer]
+fix_hats: [electrical-engineer, pcb-designer, feedback-assessor]
+review: [external, ask]
+elaboration: collaborative
+inputs:
+  - stage: inception
+    discovery: discovery
+  - stage: requirements
+    discovery: functional-requirements
+  - stage: requirements
+    discovery: safety-analysis
+---
+
+# Design
+
+Electrical schematic, PCB layout, mechanical design, and bill of materials.
+Every design decision must trace back to a requirement — unjustified
+components add cost, unjustified features add risk. Component selection
+matters: lead times, second sources, and end-of-life status are part of the
+design, not an afterthought.
+
+## EDA Platform: tscircuit
+
+This studio uses [tscircuit](https://tscircuit.com) for electronics design.
+Schematics and PCB layouts are authored as TypeScript/React (`.tsx`) circuit
+code — components are composable elements, not canvas objects. Authoring
+happens in the normal repo tree; live preview is served by `tsci dev`
+(local browser URL printed by the CLI); packages are consumed via `tsci add`
+from the
+tscircuit registry; Gerbers, pick-and-place, and BOM are exported with the
+`tsci` CLI. The source-of-truth design artifact is the circuit code itself,
+not a proprietary EDA binary. Manufacturing exports (Gerbers, pick-and-place,
+BOM CSV) are produced from the tscircuit source and committed alongside the
+`.tsx` circuit code.

package/studios/hwdev/stages/design/hats/design-reviewer.md

@@ -0,0 +1,11 @@
+---
+interpretation: lens
+---
+**Focus:** Review the integrated design (schematic, PCB, mechanical, BOM) for correctness, manufacturability, and compliance with requirements. Hardware design reviews are the last cheap place to catch errors before tooling and prototypes cost real money.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST** verify requirements traceability end-to-end, not just spot-check
+- The agent **MUST** flag any BOM item without a second source or with long lead time
+- The agent **MUST** verify DRC and ERC are clean in the tscircuit preview, not only in committed exports
+- The agent **MUST** verify that committed manufacturing exports (Gerbers, drill, pick-and-place, BOM CSV) regenerate identically from the current tscircuit source — drift between source and exports is a hard fail
+- The agent **MUST NOT** approve a design that doesn't address every safety hazard's mitigation

package/studios/hwdev/stages/design/hats/electrical-engineer.md

@@ -0,0 +1,11 @@
+**Focus:** Design the electrical schematic, select components, and produce the BOM. Schematic design is the foundation of PCB layout, firmware interfaces, and cost — decisions here ripple through everything downstream.
+
+**Tooling:** Author the schematic as [tscircuit](https://tscircuit.com) TypeScript/React code (`.tsx` circuit components). Pull standard parts with `tsci add`; preview schematic + PCB live with `tsci dev`; export BOM and netlist through the `tsci` CLI.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST** select components that have a tscircuit footprint (or author one via `@tscircuit/footprinter`) before committing to them — a part without a footprint blocks layout
+- The agent **MUST** select components with second sources for anything critical
+- The agent **MUST** check component lead times and availability before committing
+- The agent **MUST** flag any component with end-of-life status within the product lifetime
+- The agent **MUST NOT** select components without verified datasheet compliance with the stated requirements
+- The agent **MUST** keep the schematic ERC-clean in the tscircuit preview before handing off to PCB layout

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

@@ -0,0 +1,7 @@
+**Focus:** Design the enclosure, mounting, thermal management, and mechanical interfaces. Mechanical design has to live with electrical design — dimensions, heat dissipation, connector placement, and serviceability all depend on coordination.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST** verify clearance and fit against the actual [tscircuit](https://tscircuit.com) PCB layout (3D preview / exported board outline), not just the schematic
+- The agent **MUST** run thermal analysis against the actual power budget from EE
+- The agent **MUST** design for manufacturability (draft angles, wall thickness, assembly sequence)
+- The agent **MUST** coordinate with EE on connector positions and accessibility — reference the tscircuit 3D preview as the shared truth, not a stale screenshot

package/studios/hwdev/stages/design/hats/pcb-designer.md

@@ -0,0 +1,10 @@
+**Focus:** Translate the schematic into a manufacturable PCB layout that meets electrical, mechanical, thermal, and EMC requirements. PCB layout is where electrical design meets physical reality.
+
+**Tooling:** Use [tscircuit](https://tscircuit.com) for layout. Placement and constraints live in the same `.tsx` circuit code as the schematic; the built-in autorouter ships with `tsci dev` and runs as part of the live preview, with manual refinement applied in code. Export Gerbers, drill files, and pick-and-place through the `tsci` CLI. Commit exported fabrication files into the repo alongside the source.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST** pass DRC in tscircuit before considering layout complete
+- The agent **MUST** design the layout with EMC in mind (ground planes, return paths, routing of high-speed signals)
+- The agent **MUST** coordinate with ME on outline, mounting holes, and connector positions using the tscircuit 3D preview as the shared reference
+- The agent **MUST** verify the fab house can actually produce the stack-up and trace widths expressed in the tscircuit board config
+- The agent **MUST** regenerate Gerbers, drill, and pick-and-place from tscircuit source on every layout change — committed manufacturing files that drift from source are a red flag

package/studios/hwdev/stages/design/outputs/BOM.md

@@ -0,0 +1,44 @@
+---
+name: bom
+location: (exported from tscircuit source via `tsci` — committed CSV alongside `.tsx` circuit code)
+scope: repo
+format: artifact
+required: true
+---
+
+# Bill of Materials
+
+Complete sourced BOM, generated from the [tscircuit](https://tscircuit.com) circuit source. The BOM is derived, not authored — every line item traces back to a component in the `.tsx` circuit code. Sourcing metadata (cost, lead time, second sources, RoHS/REACH status) lives in a companion file and is joined onto the exported BOM at review and release time.
+
+## Content Guide
+
+Per line item in the tscircuit-exported `bom.csv`:
+- Manufacturer part number (from tscircuit component)
+- Manufacturer
+- Description
+- Quantity per assembly (auto-counted by tscircuit)
+
+Per line item in the companion `bom-sourcing.csv` (authored, keyed by manufacturer part number):
+- Manufacturer part number (join key)
+- Unit cost at target volume
+- Lead time
+- Second source manufacturer + part number (where critical)
+- RoHS / REACH compliance status
+- EOL status / last-time-buy date (if known)
+
+## Sourcing Workflow
+
+1. **Regenerate** `bom.csv` from the tscircuit source via `tsci` on every circuit-code change.
+2. **Join** `bom.csv` to `bom-sourcing.csv` on manufacturer part number (e.g. via a `tsci` post-export script or a project-local make target — the mechanism is project-local, but the file split is fixed).
+3. **Flag new parts** that exist in `bom.csv` but have no row in `bom-sourcing.csv` — those parts must be sourced before the design stage gate passes.
+4. **Flag orphaned sourcing rows** in `bom-sourcing.csv` for parts no longer in `bom.csv` — those rows are removed (with a commit message noting the part removal).
+5. **Never edit `bom.csv` by hand** — sourcing metadata only goes in `bom-sourcing.csv` so that BOM regeneration never overwrites authored data.
+
+## Quality Signals
+
+- `bom.csv` regenerates identically from the current tscircuit source — drift between circuit code and committed BOM is a hard fail
+- Every part in `bom.csv` has a corresponding row in `bom-sourcing.csv` — unsourced parts block the design gate
+- Every critical component has a second source or documented justification for single-sourcing
+- No component has EOL status within product lifetime
+- Every part has a tscircuit footprint (registry or `@tscircuit/footprinter`) — no "schematic-only" parts
+- Total BOM cost (joined view) is within the cost envelope from inception

package/studios/hwdev/stages/design/outputs/PCB.md

@@ -0,0 +1,28 @@
+---
+name: pcb-layout
+location: (tscircuit PCB source — same `.tsx` circuit code as the schematic; Gerbers / drill / pick-and-place exports committed alongside)
+scope: repo
+format: artifact
+required: true
+---
+
+# PCB Layout & Fabrication Files
+
+The PCB layout is expressed in the same [tscircuit](https://tscircuit.com) `.tsx` circuit code as the schematic — placement, routing constraints, board outline, mounting holes, and stack-up live in code. The fabrication exports (Gerbers, drill, pick-and-place) are derived artifacts: regenerated from source via the `tsci` CLI on every layout change and committed alongside the `.tsx` source so reviewers and fab houses don't need to run the dev server.
+
+## Content Guide
+
+- **Authored in tscircuit** — placement, routing, board outline, layer stack-up, mounting holes, and copper pours expressed in `.tsx`
+- **DRC-clean** in the tscircuit preview before exports are regenerated
+- **Gerbers** (one set per layer per fab order), exported via `tsci`
+- **Drill files** (plated and non-plated), exported via `tsci`
+- **Pick-and-place** (centroid + rotation per reference designator), exported via `tsci`
+- **Stack-up document** captured in the tscircuit board config, with fab-house capability cross-checked
+- **Fabrication notes** for any non-default process (controlled impedance, blind/buried vias, surface finish requirements)
+
+## Quality Signals
+
+- DRC is clean in the tscircuit preview
+- Committed Gerbers / drill / pick-and-place regenerate identically from the current tscircuit source — drift between source and exports is a hard fail
+- Stack-up and trace widths are within the target fab house's published capability
+- Mounting holes, connector positions, and board outline align with the mechanical 3D preview

package/studios/hwdev/stages/design/outputs/SCHEMATIC.md

@@ -0,0 +1,24 @@
+---
+name: schematic
+location: (tscircuit source tree — `.tsx` circuit code, with rendered schematic SVG exported alongside)
+scope: repo
+format: artifact
+required: true
+---
+
+# Schematic
+
+The complete electrical schematic, authored as [tscircuit](https://tscircuit.com) TypeScript/React code (`.tsx`). Components are expressed as composable elements with part numbers, values, and rationale for non-obvious choices. The circuit source is the authoritative artifact — the rendered schematic SVG is regenerated from it. PCB layout and fabrication exports (Gerbers, drill, pick-and-place) are tracked separately under `outputs/PCB.md`.
+
+## Content Guide
+
+- **Authored in tscircuit** — `.tsx` circuit code, previewable via `tsci dev` (the CLI prints the local URL on startup)
+- **All nets named** where naming aids readability
+- **All components** pulled from the tscircuit registry (`tsci add`) or authored with `@tscircuit/footprinter`, with part numbers in the BOM and rationale for critical choices
+- **Power tree** documented in code (comments / named subcircuits) showing regulation and decoupling strategy
+- **Signal integrity** considered for any high-speed paths, with routing constraints expressed in the PCB layout section of the circuit code
+- **Rendered schematic SVG** exported via `tsci` and committed for reviewers who aren't running the dev server
+
+## Completion
+
+Complete when ERC is clean in the tscircuit preview, the BOM (exported from the same source) is sourced with confirmed availability, committed manufacturing exports match the current source, and design review has signed off.

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

@@ -0,0 +1,52 @@
+# Design Stage — Elaboration
+
+Design is a **design / synthesis** stage. Its units are designed components or option sets that compose into the full hardware solution — schematics, PCB layout sections, mechanical sub-assemblies, BOM blocks. Each unit produces one designed artifact that downstream stages (`firmware`, `manufacturing`, `validation`) consume as input.
+
+## What a unit IS in this stage
+
+One designed component, sub-assembly, or option set. Examples:
+
+- "Power supply schematic — input range, regulation topology, protection"
+- "MCU subsystem — pinout, decoupling, programming interface"
+- "Connector and IO layout — shielding, ESD, mating cycles"
+- "Enclosure mechanical — material, mounting, thermal relief"
+- "BOM cost & second-source plan — single-source risks called out, lead times"
+- "PCB stackup and impedance plan — layer count, controlled-impedance traces"
+
+What a unit is **NOT** in this stage:
+
+- ❌ A research question about the market or user (those belong in `inception`)
+- ❌ An execution-spec for firmware code (`firmware`'s own elaborate phase authors those)
+- ❌ A test procedure (those are `validation`-stage units)
+- ❌ A manufacturing process step (those are `manufacturing`-stage units)
+
+If you find yourself writing executable verify-commands or a Gherkin scenario, you're authoring the wrong stage's units. Stop and route the work downstream.
+
+## What "completion criteria" means here
+
+Design-artifact criteria are about **substance, traceability, and coherence**, not executability. Each criterion should be checkable by a designer reading the artifact, not by a shell command.
+
+### Good criteria — substantive and checkable
+
+- "Every component on the schematic has a part number, package, value, and tolerance — no `???` or `TBD`"
+- "Every design choice that depends on a requirement cites the requirement ID (e.g., REQ-FN-04, REQ-SAFE-12)"
+- "BOM lists ≥1 second source for every part above $1 BOM cost OR explicitly justifies single-source with a lead-time risk note"
+- "Power budget table sums to ≤ declared input budget with ≥10% margin"
+- "Mechanical CAD references the same connector footprints as the PCB layout — connector locations match within 0.5mm"
+
+### Bad criteria — vague or wrong-stage language
+
+- ❌ "Design is complete" (tautological; complete by what measure?)
+- ❌ "Schematic looks reasonable" (no concrete check)
+- ❌ "Tests pass" — there's nothing to test in design; testability is a `validation`-stage concern
+- ❌ "Code compiles" — wrong stage entirely
+
+## How verification happens
+
+Design artifacts are validated by the verify-class hat declared in `STAGE.md` (currently `design-reviewer`). The verifier checks **substance, traceability to requirements, internal coherence across components, and decision-register accountability** — body-content checks only, no frontmatter interpretation.
+
+## Anti-patterns
+
+- **Mixing design and execution.** A unit titled "Implement ADC firmware driver" belongs in `firmware`, not `design`. Keep design at the spec level.
+- **Single-document syndrome.** A 40-page master design doc with 9 sections defeats the per-unit model — each section can't be revisited or rejected independently. One designed component per unit.
+- **Skipping requirement traceability.** Design choices without requirement citations are how scope creep enters; the verifier rejects them.

package/studios/hwdev/stages/design/review-agents/compliance-mapping.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the design addresses every regulatory and safety requirement from the requirements stage.
+
+**Check:**
+- The agent **MUST** verify every hazard from the safety analysis has a design-level mitigation
+- The agent **MUST** verify EMC design practices are followed for FCC/CE compliance
+- The agent **MUST** verify electrical safety features are present for UL/IEC requirements
+- The agent **MUST** flag any regulatory requirement that the design does not address

package/studios/hwdev/stages/design/review-agents/manufacturability.md

@@ -0,0 +1,11 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the design can be manufactured at target volume without custom tooling or exotic processes.
+
+**Check:**
+- The agent **MUST** verify the PCB stack-up and trace widths declared in the [tscircuit](https://tscircuit.com) board config are within fab capability
+- The agent **MUST** verify DRC is clean in the tscircuit preview (design-level check). Gerber-level DRC against committed exports and regeneration parity belong to the **manufacturing stage's** validation — design owns the source-of-truth declaration, not the export-validation loop.
+- The agent **MUST** verify the enclosure design supports the assembly process (draft angles, wall thickness, fastener access)
+- The agent **MUST** verify BOM components (as exported from tscircuit) are available at target volume
+- The agent **MUST** flag any design choice that requires hand-assembly when automated assembly was assumed

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

@@ -0,0 +1,21 @@
+---
+name: firmware
+description: Embedded software for the hardware platform
+hats: [firmware-engineer, reviewer]
+fix_hats: [firmware-engineer, feedback-assessor]
+review: [external, ask]
+elaboration: collaborative
+inputs:
+  - stage: requirements
+    discovery: functional-requirements
+  - stage: design
+    output: schematic
+---
+
+# Firmware
+
+Implement embedded software. Constraints differ from application development:
+memory and flash are finite, real-time deadlines are often hard, power budgets
+matter, and field updates may require physical access. Safety-critical code
+paths must be traceable to requirements and provably correct — "it works on
+the bench" is not validation for firmware that's going into a product.

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

@@ -0,0 +1,7 @@
+**Focus:** Implement the embedded software that runs on the hardware. Firmware lives in a constrained environment — memory, flash, power, real-time deadlines are all finite, and debugging is much harder than on application code.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** exceed the memory or flash budget — there is no runtime to grow into
+- The agent **MUST** implement fail-safe behavior for every safety-critical code path
+- The agent **MUST** verify real-time deadlines are met, not just assumed
+- The agent **MUST NOT** ship firmware without an update mechanism unless the product spec explicitly allows no updates

package/studios/hwdev/stages/firmware/hats/reviewer.md

@@ -0,0 +1,9 @@
+---
+interpretation: lens
+---
+**Focus:** Review firmware against functional requirements, safety analysis, and memory/flash budgets.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST** verify every safety-critical code path has traceable test coverage
+- The agent **MUST** verify the binary fits within memory and flash with headroom for future updates
+- The agent **MUST** flag any firmware that lacks fail-safe handling for documented hazards

package/studios/hwdev/stages/firmware/outputs/FIRMWARE-BINARY.md

@@ -0,0 +1,22 @@
+---
+name: firmware-binary
+location: (project build output)
+scope: repo
+format: artifact
+required: true
+---
+
+# Firmware Binary
+
+The compiled firmware artifact ready to flash onto the target hardware.
+
+## Content Guide
+
+- **Compiled binary** — signed where the platform supports it
+- **Version metadata** — embedded version string accessible at runtime
+- **Update mechanism** — documented process for field updates (OTA, physical, bootloader)
+- **Flashing instructions** — for manufacturing and field service
+
+## Completion
+
+Complete when firmware implements all functional requirements, passes HIL tests, and fits within memory/flash budgets with update headroom.

package/studios/hwdev/stages/firmware/review-agents/resource-budget.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the firmware fits within memory, flash, and power budgets with headroom for future updates.
+
+**Check:**
+- The agent **MUST** verify flash usage is under target (with documented headroom)
+- The agent **MUST** verify RAM usage is under target for peak load
+- The agent **MUST** verify power consumption matches the functional requirements envelope
+- The agent **MUST** flag any build that leaves insufficient headroom for OTA updates

package/studios/hwdev/stages/firmware/review-agents/safety-path-coverage.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify every safety-critical code path identified in the safety analysis is implemented and tested.
+
+**Check:**
+- The agent **MUST** verify each hazard's mitigation has corresponding firmware code
+- The agent **MUST** verify each fail-safe behavior is **testable** — i.e., the code exposes the seam (deterministic entry point, injectable fault, observable output) that the validation stage will need to exercise it. Whether the test actually exists and passes is the **validation stage's** check, not firmware's.
+- The agent **MUST** flag any hazard whose mitigation was assumed to be hardware-only but actually depends on firmware
+- The agent **MUST** verify watchdog, fault-handler, and error-recovery paths are implemented

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

@@ -0,0 +1,17 @@
+---
+name: inception
+description: Market research, user problem, and business case
+hats: [researcher, distiller, verifier]
+fix_hats: [researcher, feedback-assessor]
+review: ask
+elaboration: collaborative
+inputs: []
+---
+
+# Inception
+
+Understand the market, user problem, and business case. Same shape as
+application development inception — what are we building and why, who would
+buy it, what is the competitive landscape. Hardware-specific constraints
+(safety, regulatory, manufacturing feasibility) surface in the requirements
+stage, not here.

package/studios/hwdev/stages/inception/discovery/DISCOVERY.md

@@ -0,0 +1,39 @@
+---
+name: discovery
+location: .haiku/intents/{intent-slug}/knowledge/DISCOVERY.md
+scope: intent
+format: text
+required: true
+---
+
+# Discovery
+
+Market, user, and business context for the hardware product. Foundation for downstream stages.
+
+## Content Guide
+
+### Problem & Users
+- Target users and their context
+- The problem this product solves
+- Why hardware (vs. a software solution)
+
+### Market
+- Competitive landscape with named products
+- Pricing bands and positioning
+- Distribution channels and retail strategy
+
+### Business Case
+- Rough COGS envelope
+- Target price and margin
+- Volume estimate
+- Target regulatory markets (US, EU, etc.) — so requirements knows which frameworks apply
+
+### Non-Goals
+- Features or markets explicitly deferred
+
+## Quality Signals
+
+- Target users are specific, not generic
+- Competitors are named with product SKUs
+- Regulatory markets are identified so requirements can plan
+- Cost envelope is defensible, not aspirational

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

@@ -0,0 +1,6 @@
+**Focus:** Decompose the intent into research units with verifiable criteria.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** elaborate design or firmware units at inception
+- The agent **MUST** ensure unit DAG is acyclic
+- The agent **MUST** scope units to a single bolt

package/studios/hwdev/stages/inception/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/inception/hats/researcher.md

@@ -0,0 +1,7 @@
+**Focus:** Understand the market, user problem, and business case for this hardware product. Hardware inception looks a lot like application inception — but the cost of being wrong is higher because hardware has physical constraints that application software doesn't.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** specify safety or regulatory constraints here — those belong in requirements
+- The agent **MUST** frame the problem in user-outcome terms, not engineering terms
+- The agent **MUST** identify regulatory markets that will be in scope so requirements can plan for them
+- The agent **MUST NOT** jump to component selection — that's design's job

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

@@ -0,0 +1,24 @@
+**Focus:** Validate the per-unit knowledge artifact for hardware inception. Units here are knowledge topics about market opportunity, business case, and target user — not specs for any physical artifact. 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.
+- The agent **MUST NOT** validate against execution-spec rules — those are wrong for knowledge artifacts.
+- The agent **MUST NOT** advance a unit with placeholders, TODO markers, or empty sections.
+- The agent **MUST** name a specific failed criterion in any rejection.
+
+## 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
+Hardware decisions cost money to undo. Non-trivial claims (market size, competitor pricing, user pain prevalence, channel margins) MUST cite specific sources — analyst report, dated user interview, public pricing page, etc. Reject "industry common knowledge" or unsourced numerical claims.
+
+### 3. Internal consistency
+Title and mission must align with body. Numerical claims must be consistent across the body. Recommendations must follow from the evidence presented.
+
+### 4. Decision-register consistency
+The unit must not propose or assume an option contradicting 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/hwdev/stages/inception/outputs/KNOWLEDGE.md

@@ -0,0 +1,11 @@
+---
+name: knowledge
+location: .haiku/intents/{intent-slug}/knowledge/
+scope: intent
+format: directory
+required: false
+---
+
+# Knowledge
+
+Supporting research for hwdev inception: market data, competitor teardowns, component cost research, early BOM estimates.

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

@@ -0,0 +1,45 @@
+# Hardware Inception Stage — Elaboration
+
+Hardware inception is a **research / distillation** stage. Its units are knowledge topics covering market opportunity, business case, and target-user understanding for a hardware product. Hardware-specific constraints (safety, regulatory, manufacturing feasibility) belong in the **requirements** stage, not here.
+
+## What a unit IS in this stage
+
+One investigable knowledge topic. Examples:
+- "Target market segmentation and primary user persona"
+- "Competitive product landscape with price, primary features, and gaps"
+- "Business case: addressable market, unit economics, payback period"
+- "Distribution channels and channel economics"
+- "Brand positioning and differentiation thesis"
+- "Hardware-product-specific risks (e.g., supply-chain dependencies, component lead times) at a strategic level"
+
+What a unit is **NOT** in this stage:
+- ❌ Functional or safety requirements (those belong in `requirements`)
+- ❌ Mechanical/electrical/PCB design (those belong in `design`)
+- ❌ Manufacturing process specs (those belong in `manufacturing`)
+- ❌ A bill of materials or component selection (those follow from design)
+
+## What "completion criteria" means here
+
+Knowledge-artifact criteria are about **substance and accountability**, not testable outcomes. Hardware inception is upstream of any physical artifact.
+
+### Good criteria — substantive and checkable
+
+- "Market segmentation §2 names ≥3 distinct segments with size estimates and a one-paragraph differentiation per segment"
+- "Competitive landscape §3 names ≥4 alternatives the user could buy instead, each with current MSRP, primary feature, and the gap this product addresses"
+- "Business case §5 cites concrete numbers (volume, ASP, BOM target, channel margin, payback) — no placeholder ranges like 'TBD' or 'reasonable margin'"
+- "Open questions section has ≥0 entries; each open question has a proposed default for veto-style approval OR `(needs human escalation)`"
+
+### Bad criteria — vague or wrong-stage language
+
+- ❌ "Market is understood" (no concrete check)
+- ❌ "Each unit has a verifiable command" (build-stage language; hardware inception is non-executable)
+- ❌ "FCC compliance is verified" (wrong stage — `requirements` owns regulatory framework choice; certification happens in `validation`)
+- ❌ "Schematic is finalized" (wrong stage — `design` owns electrical/mechanical artifacts)
+
+## Anti-patterns
+
+- **Bleeding into requirements / design.** Hardware inception is "should we build this and for whom"; not "what does it do" (requirements) or "how is it built" (design).
+- **Single-document syndrome.** One giant business-case doc defeats the per-unit model. One topic per unit.
+- **Skipping citation.** Hardware decisions cost money to undo; sources for market and competitive claims are mandatory.
+
+> 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 knowledge-artifact units. Treat the build-class rules as defaults the framework hasn't yet split — author your units to the substance/accountability shape above, not to executable verify-commands. (Architecture §7 known issue tracking the split.)

package/studios/hwdev/stages/inception/review-agents/completeness.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the discovery document covers everything downstream stages need.
+
+**Check:**
+- The agent **MUST** verify target users are specific
+- The agent **MUST** verify regulatory markets are identified for requirements to plan against
+- The agent **MUST** verify cost envelope and competitive landscape are documented
+- The agent **MUST** verify non-goals are explicit

package/studios/hwdev/stages/inception/review-agents/market-feasibility.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** challenge whether the product has a defensible market position given competitive landscape and cost envelope.
+
+**Check:**
+- The agent **MUST** verify the cost envelope is consistent with target retail price and channel margins
+- The agent **MUST** verify the product differentiates from competitors in a way consumers will recognize
+- The agent **MUST** flag regulatory markets that would add significant cost not reflected in the envelope
+- The agent **MUST** verify volume estimates are grounded in comparable product data

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

@@ -0,0 +1,25 @@
+---
+name: manufacturing
+description: DFM, assembly process, QA sampling, and production ramp
+hats: [manufacturing-engineer, qa-lead, verifier]
+fix_hats: [manufacturing-engineer, feedback-assessor]
+review: await
+elaboration: autonomous
+inputs:
+  - stage: design
+    output: schematic
+  - stage: design
+    output: bom
+  - stage: firmware
+    output: firmware-binary
+  - stage: validation
+    output: certification
+---
+
+# Manufacturing
+
+Design for manufacturability (DFM) review, assembly process definition, QA
+sampling plan, and production ramp. Manufacturing decisions lock in — once
+tooling is cut and the assembly line is running, changes are expensive and
+slow. First article inspection is the last chance to catch a problem before
+it ships at volume.

package/studios/hwdev/stages/manufacturing/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