Sprocket v0.3.0: verify the design before agent checkout

Sprocket v0.3.0, released on August 3, 2026, adds built-in hardware-design skills and agentic checkout using Prava. The release and tagged repository describe a path from AI-generated design files toward an order for their components. They do not document a completed end-to-end purchase. If a team authorizes that path, an unresolved design error can reach procurement before a qualified person accepts the design.

The useful decision boundary is precise: accept the design after its artifacts agree, then give the agent a narrow purchase authorization. A spend limit can restrict the payment, but it cannot prove that an electrical connection, or net, joins the intended pins or that a selected part fits the circuit. Following the dependencies between those decisions shows what a person must verify before checkout and what still requires physical testing after delivery.

Sprocket v0.3.0 joins design work to checkout

The v0.3.0 release notes list hardware-design skills and agentic checkout using Prava among the added features. The project’s tagged README says Sprocket can produce hardware designs and code. For hardware, it names React schematics, which are visual drawings rendered from code, a bill of materials (BOM), and assembly instructions. It also says the agent can buy from websites. These are project claims, not evidence that a specific circuit is electrically correct or that an autonomous purchase has succeeded.

The built-in creating-hardware-project skill makes the intended sequence explicit. It tells the agent to create the hardware documents, get confirmation on the BOM, and then order the parts. That sequence contains a human pause, but BOM confirmation alone leaves an important question open: did the BOM come from a design whose schematic, pin assignments, part facts, and assembly instructions agree?

Checkout can use different execution paths. The tagged UCP shopping skill tells the agent to prefer the Universal Commerce Protocol, or UCP, when a merchant supports it and to use a browser when needed. UCP is an API-based method for product search, checkout, and order tracking. The project documents both paths as ways to place an order. Neither path evaluates the circuit that produced the shopping list.

The design exists across dependent artifacts

Sprocket’s hardware-project-docs skill requires four synchronized artifacts: a BOM, a microcontroller unit (MCU) pin map when a microcontroller is present, a React schematic, and assembly notes. The skill says one schematic change requires checking all four. It also says that net names connect the schematic to the pin map and notes, while current datasheets and supplier descriptions should supply circuit facts.

Each artifact depends on the others in a different way. The BOM identifies the exact parts and quantities that procurement will use. The pin map assigns circuit signals to microcontroller pins, the schematic shows how named signals connect components, and the assembly notes tell a person how to turn those choices into hardware. If firmware is part of the project, its pin definitions and electrical assumptions must also match the accepted design.

Agreement does not mean that four files merely exist. A regulator voltage in the schematic must match the selected regulator and its supporting parts in the BOM. A signal name on an MCU pin must reach the intended device pin, and the assembly notes must use the same connector orientation, polarity, and part variant. Otherwise, checkout can execute a precise order for an internally inconsistent design.

A React schematic also has a narrower purpose than an electrically checked computer-aided design (CAD). It can show components, labels, and visual connections, but successful rendering proves only that the drawing renders. Sprocket’s separate KiCad authoring skill states this distinction directly: file-format validity and electrical validity are separate.

The tagged sample uses two encoder-label sets with no overlap

The current tagged hardware-docs skill calls its embedded React schematic a “verified, collision-checked artifact.” In that sample, the MCU encoder inputs are declared as E1A, E1B, E2A, and E2B. The two Motor instances derive their encoder labels from the motor names, which produces M1A, M1B, M2A, and M2B, even though the sample says matching labels establish connectivity. The two sets have no shared encoder label, so the repository’s own connectivity explanation does not reconcile those endpoints.

BARISTALABS · CONSTRUCTED · SOURCE CHECK

TAGGED v0.3.0 SAMPLE: NO SHARED ENCODER LABELS

Source: hardware-project-docs at 50b1f81b1e51a9f0ba37c378c50337ea8007201a · retrieved 2026-08-03

MCU ENCODER NETS

• E1A
• E1B
• E2A
• E2B

MOTOR ENCODER NETS

• M1A
• M1B
• M2A
• M2B

SHARED LABELS: NONE

BEFORE PARTS ARE ORDERED

1. Compare net names across pin map and schematic
2. Run electrical-rules checking (ERC)
3. Export and inspect the netlist
4. Verify part identity, ratings and quantity
5. Record human design acceptance
6. Then approve the purchase mandate

Checkout does not resolve unmatched net labels.

Design acceptance and purchase authorization are separate decisions.

Greptile’s review of hardware-design PR #154 flagged the same mismatch before merge and reported that an executed comparison found no overlapping encoder labels. The tagged file still contains the two naming schemes. This is narrow source evidence: the current built-in example contains a label mismatch that its connectivity explanation does not resolve. It does not show that the entire product is broken, that any physical circuit was assembled from the sample, or that Sprocket completed a purchase for it.

The mismatch matters because it crosses the handoff between artifacts. A visual inspection can see labels at both ends and still miss that the strings differ. BOM approval would not expose the problem because the encoder modules and MCU could all be valid line items. A reviewer must compare the intended nodes, not only confirm that the parts list looks plausible.

A purchase mandate controls payment, not circuit meaning

Checkout PR #153 describes a cloud-browser checkout path backed by Prava mandates. The PR says each payment credential is single-use, locked to one merchant, and capped at an amount. If the payment path enforces those properties as the PR describes, the credential is limited to one use, one merchant, and the approved amount.

None of those conditions can tell whether E1A should connect to M1A, whether a component package fits the intended assembly, or whether the BOM chose the correct voltage rating. A merchant lock can still permit the wrong item from the allowed merchant. An amount cap can still fund a complete order for an incorrect design. Payment authorization answers whether the agent may spend under stated limits; design acceptance answers whether the artifacts justify buying those exact parts.

The same PR says a live Prava sandbox round-trip was not completed before merge because the required credentials were unavailable. Its reported unit and project tests therefore do not establish an end-to-end sandbox checkout. That limitation concerns payment-path validation and remains separate from the encoder-label evidence in the hardware example.

Budgets, merchant restrictions, identity, logs, and approval rules remain necessary when an agent can spend. Our earlier explanation of agent spending controls covers that wider operating problem. Here, the additional requirement is design evidence before procurement receives authority. A well-controlled payment can record who approved a charge and still say nothing about whether the purchased circuit will work.

Design acceptance belongs before purchase authorization

The design reviewer should first freeze the exact version under review and compare every artifact that carries a circuit fact. Net names must agree across the schematic, pin map, notes, and firmware definitions. Manufacturer part numbers, package types, voltage and current ratings, quantities, connector orientations, and allowed substitutions must agree with the BOM and the current primary documentation for each part.

For a KiCad design, the repository’s own skill gives a useful source-level sequence. Run kicad-cli sch upgrade to check and update the file format, run electrical-rules checking with kicad-cli sch erc, export the netlist, and inspect whether every intended node appears on the intended net. Electrical-rules checking can find defined classes of errors, but the netlist comparison still needs the design intent. Neither step replaces a qualified electrical review for the product’s voltage, current, timing, thermal, safety, or regulatory requirements.

For a React schematic, the team needs an equivalent comparison even though the artifact is not a KiCad electrical design. Extract the labels at both endpoints, compare them against the pin map and notes, and reject unmatched or ambiguous names. Then verify every selected part against the current datasheet and supplier listing. The visible E and M label sets show why rendering and collision checks cannot complete this work.

Only after those checks should a named person accept the design version. Purchase approval can then reference that same version and restrict the agent to the accepted manufacturer part numbers, variants, quantities, merchants, and total. If checkout proposes a substitute, changes a quantity, or encounters a different package, it must return to design review instead of treating the change as an ordinary cart update.

The design reviewer and budget owner can be the same person in a small team, but the decisions must remain separate. “This design is ready to source” records technical acceptance. “This agent may place this order under these limits” grants authority to act outside the design system. Keeping those statements separate makes a rejection or later change easier to trace to the correct owner.

Delivery starts the hardware test

A completed checkout proves that an order reached a merchant and, after delivery, that a shipment arrived. It does not prove that the delivered parts match the accepted BOM, survived shipping, or form a working assembly. Incoming inspection should compare part numbers, package markings, quantities, and visible condition with the accepted order before assembly begins.

The assembled hardware then needs a test plan that fits its design and hazards. That work can include checks for shorts, continuity, polarity, supply rails, signal behavior, firmware pin assignments, thermal behavior, and the intended functional result. The responsible engineer must select the checks and safe test conditions for the actual circuit; the repository sources do not provide physical test evidence for the generated design path.

Source code and purchased components also do not create a deployable device by themselves. As the ESP32-AI hardware analysis explains in another context, available source and a target-ready artifact are different forms of evidence. Firmware must be built for the exact target, loaded onto the assembled hardware, and tested with the accepted circuit under the conditions that matter for its use.

Teams that want to automate this sequence can keep one clear acceptance point between generated work and external action. BaristaLabs helps teams separate AI-generated output, human acceptance, outside actions, and surviving evidence in process automation and integration. For this workflow, the decision is direct: approve the design, then approve the purchase, then test the assembled hardware.