copperheadhq/copperhead

💰 BOUNTY — $50 USD Tracked in #💰・bounties. Claim by commenting below. First mergeable PR wins; paid on merge, not on submission. Claims expire after 2 days without visible progress. Keep fix discussion on this issue, not in the channel. Discord: https://discord.com/channels/1527265832730628136/1529900631735799828/1530129559868149800 Summary copperhead create is an 8-stage pipeline (spec-seed → architecture → part-selection → schematic → layout-draft → outputs → firmware → dev-plan) that turns a natural-language brief into manufacturable KiCad artifacts. Each stage is committed independently, and a full board is built over multiple invocations. There is rich per-stage instrumentation but no end-to-end coverage that proves the whole pipeline runs clean from a brief to a committed final stage. Manual driving of the pipeline has repeatedly wedged mid-run (most recently at stage 4, schematic) and surfaced a string of blockers, defects, and inefficiencies. We want th

Context copperhead do "<instruction>" (src/cli.ts:125) is the core edit loop: take an existing, known-good KiCad project and apply a surgical, verified change to it. The acceptance criteria that define this product (SPEC.md AC-3.1 ... AC-3.7, the pitch) are all edits on an already existing board: AC-3.1 propagating net rename across sheets + docs, surgical diff (< 5% lines). AC-3.2 constraint-aware pin choice (RTC-capable, non-strapping on ESP32-S3). AC-3.3 add a part with a unique refdes + UNVERIFIED BOM row. AC-3.4 budget refusal (the money demo): refuse an edit that busts a power budget. AC-3.5 repair loop, AC-3.6 rollback, AC-3.7 surgical (file not regenerated). We cannot exercise any of these repeatably today. test/fixtures/ has a single known-good project (open-key, one sheet) plus a few canned report JSONs. It is enough to prove the ERC/DRC plumbing works, but it does not contain the board features each AC-3.x edit needs to reason over: multi-sheet nets, an ESP32-S3 with a doc

Tracking issue for the add-part-research-tools OpenSpec change. Full spec: openspec/changes/add-part-research-tools/ (proposal, design, tasks, specs/). Why The agent designs from trained knowledge alone: it cannot look up a datasheet, confirm a part exists, or check availability, so every new part is guesswork flagged UNVERIFIED and constraint sources cite datasheets nobody fetched. Grounding part selection in real, current data removes the biggest credibility gap in create/do output and pulls forward the "sourceable becomes a checked constraint" roadmap item (SPEC.md §8). What ships New research tool family, available to the agent loop in do/create alongside file/KiCad/memory tools: web_search: reference designs, app notes, errata search_parts: structured part search (MPN, parametrics, availability, pricing) via a supplier API fetch_datasheet: download a datasheet PDF and cache it under .copperhead/datasheets/, recorded with URL, retrieval date, and content hash for reproducibility

Context The planned copperhead check --fab (OpenSpec change add-fab-release-gate, task 4.1) needs deliberately broken KiCad fixture variants so every gate check has a failing test. This is an ideal issue for someone fluent in KiCad who does not write TypeScript: each fixture is a small KiCad project committed as text, immediately consumed by tests. What to build Starting from the known-good project in test/fixtures/, create minimal variants, each breaking exactly one thing: Unrouted net: board with one net left unrouted (DRC reports an unconnected item). MPN-less BOM row: BOM.md row with an empty MPN column. UNVERIFIED row: complete BOM.md row flagged UNVERIFIED. Refdes mismatch: component present in the schematic, absent from the board. Footprint mismatch: same refdes, different footprint between schematic and board. Missing ## Draft quality: LAYOUT.md without the section. Definition of done Each variant lives under test/fixtures/ with a short README line stating what is broken and

Context The planned copperhead export bom --supplier mouser (OpenSpec change add-supplier-bom-export, task 1.3) emits a Mouser cart-upload CSV. One emitter function, one golden file; see the sibling JLCPCB and DigiKey issues for the pattern. What to do Implement one emitter function producing Mouser's cart upload CSV: MPN, manufacturer, quantity, customer reference (refdes group). Quantities come from the shared order-quantity arithmetic (boards + spares); stub the interface if that issue has not merged. Golden-file test from the fixture BOM, asserted byte-equal in CI. Definition of done (from the delta spec) Rows carry MPN, manufacturer, and computed quantity from BOM.md. MPN-less rows and UNVERIFIED rows are excluded and named in the warnings footer; --include-unverified behaves as specified in the change. Golden file committed and asserted. Notes Offline, no API key. Familiarity with Mouser's upload template (column names, delimiter tolerance) is the valuable part.