ORDER

edakit cart check: every field of the job (job.json, from the keys of [order] in the maker's words) is read back from the page with its value (quote.json; case and blanks ignored) – the quantities and, where the job lists parts not to place, their marks included; a field the page shows that is neither in the job nor in the profile's ignore fails.

Why

The form is the one place where the order differs from the release without any file knowing it: the reference cart still said 'Remove Mark' although the board had the placeholder, the remark was wrong three times. FILES.order holds [order] to the board; only ORDER.form holds the form to [order]. A field the maker added is a question nobody answered – the page's preset would go into the order.

What to do

Set the field on the page to the job's value and read it back; a value the form does not offer: correct [order] and run the gate. A new field: a key for it in edakit, or the field into the profile's ignore with its reason – before the order goes on.

Sources

1. edakit handbook 8.4 (pytree's order: 'Remove Mark', the remark)
2. Ordering at the manufacturer (docs/concepts/done/ordering.md, decided 2026-10-30): edakit prepares the order, Claude fills the maker's form in the owner's browser (skill cart), edakit checks what it brings back; up to the maker's cart button, never further

Replaces B-1

edakit cart check: the maker's matching (quote.json parts) has exactly the lines of the job's BOM – the same part numbers (LCSC or MPN, as the maker matches), the same designators; a line the maker marked (not matched, out of stock, replaced, another manufacturer, 'Standard Only') fails. A maker that matches the BOM only in its review after the cart (matching = "review" in its profile – PCBWay) shows no lines before it: nothing to hold, and the parts it buys show on the order page (edakit cart actual).

Why

The maker's BOM tool decides what is placed: a replaced part, another manufacturer or a line it could not match is a board the gate never checked and M-6 never saw. A part the maker would replace needs a new release – with it a new M-6.

What to do

A part the maker cannot place: another part in the graph (part-search), a new gate run and a new order. Never accept a replacement on the page.

Sources

1. Ordering at the manufacturer (docs/concepts/done/ordering.md, decided 2026-10-30): edakit prepares the order, Claude fills the maker's form in the owner's browser (skill cart), edakit checks what it brings back; up to the maker's cart button, never further
2. edakit handbook 8.4 and 15.4 (M-6 reviews the parts of the release)

Replaces B-2

edakit cart check: the board's price lines of the quote without shipping and VAT – PCB, assembly fees, parts – against the estimate of edakit cost for the board in the job, each above [cart] tolerance per price line a warning with both values; the board total above [cost] budget a warning. Without an estimate – a maker without a fee table (PCBWay, Eurocircuits, AISLER), a quote in another currency than the estimate – the board total against the budget alone, in [cost] currency through [cost] rates; without a rate for the quote's currency the budget is named, not compared.

Why

edakit cost came within about 1 $ of the reference carts; a larger difference is a fee edakit does not know, a class or a side that changed, or a field set otherwise than the job says. Shipping and VAT belong to the order, which may hold several boards – edakit cart actual compares them.

What to do

Find the line that differs: a field of the form (ORDER.form), a part line (ORDER.parts), a fee the table lacks (edakit cart actual brings real costs into the project's fee table). Accept a difference that is understood, or stop the order.

Sources

1. edakit handbook 8.4 (the estimate within about 1 $ of the cart of 2026-10-25)
2. Ordering at the manufacturer (docs/concepts/done/ordering.md, decided 2026-10-30): edakit prepares the order, Claude fills the maker's form in the owner's browser (skill cart), edakit checks what it brings back; up to the maker's cart button, never further

Replaces B-3

edakit cart check: every value of quote.json – the fields, the part numbers and designators, the price amounts, the file names, the lead time – occurs in quote_page.txt, the page text Claude kept.

Why

Both files come from Claude: ORDER.read cannot prove the page, but it finds a value that was not read – one filled in from the job or from memory, which would make ORDER.form to ORDER.quote compare the job with itself.

What to do

Read the page again and write what it shows; keep the page text whole (form, matching, quote).

Sources

1. Ordering at the manufacturer (docs/concepts/done/ordering.md, decided 2026-10-30): edakit prepares the order, Claude fills the maker's form in the owner's browser (skill cart), edakit checks what it brings back; up to the maker's cart button, never further

Replaces B-4

edakit cart check: the SHA-256 of every upload file is still that of the job and of the current release's manifest, the job's run is still the current release, and the names – and sizes, where the page shows them – of the uploads the page lists are the job's files, none more. Where the files go up in the cart (upload = "after_cart" – PCBWay) their names come with the cart line (cart.json files); an upload the maker's pages name nowhere (unshown – JLCPCB's BOM and CPL) is held by its SHA-256 alone.

Why

The second lesson of pytree's order: the upload of another run's files. edakit release verify had to be run by hand right before the upload; ORDER.files checks the files and what the page says it received.

What to do

Upload the job's files again from the paths in job.json; after a new release, edakit cart prepare again.

Sources

1. edakit handbook 8.4 (release verify before the upload)
2. Ordering at the manufacturer (docs/concepts/done/ordering.md, decided 2026-10-30): edakit prepares the order, Claude fills the maker's form in the owner's browser (skill cart), edakit checks what it brings back; up to the maker's cart button, never further

Replaces B-5

edakit cart check: a surface finish with lead (HASL that is not lead-free) in the job or on the page fails for purpose.use sale or without a purpose, warns for gift and is a note for private – support, not legal advice (handbook 15).

Why

The finish is in the layout and fab hash, not in the circuit hash M-6 reviewed: leaded HASL puts lead into the product. For a board that is sold RoHS forbids it; for a gift lead is a substance of very high concern that REACH Art. 33 asks to name to a consumer who asks.

What to do

finish = "LeadFree HASL" or "ENIG" in [order] and a new gate run; a gift with lead: accept with the statement at hand, or change the finish.

Sources

1. edakit handbook 15.1 and 15.2 (RoHS, REACH Art. 33, graded by purpose)
2. Directive 2011/65/EU (RoHS 2) Annex II: lead 0.1 % by weight in homogeneous materials
3. Ordering at the manufacturer (docs/concepts/done/ordering.md, decided 2026-10-30): edakit prepares the order, Claude fills the maker's form in the owner's browser (skill cart), edakit checks what it brings back; up to the maker's cart button, never further

Replaces B-6

edakit cart check: regulatory.md, the result of the agent regulatory-reviewer on the order, exists, names the SHA-256 of job.json and quote.json as they are now and ends with the line 'Order: OK'. Without it the check is open (exit 3); another hash, 'Order: not OK' or another last line fails.

Why

M-6 reviewed the circuit; the order adds what M-6 never saw – the finish and the other keys, the quantity against the purpose, where the maker sits, parts the owner supplies. A new quote is another order: its hash changes and the review must see it. Whether every finding 'important' is settled is the agent's judgement, as for M-6; edakit checks the line and the hashes.

What to do

Run the agent regulatory-reviewer on the order (skill cart, step 8) and write its result unchanged to regulatory.md; settle a 'block' with a new release, an 'important' as a numbered decision.

Sources

1. edakit handbook 15.4 (M-6) and the agent regulatory-reviewer, section 'At the order'
2. Ordering at the manufacturer (docs/concepts/done/ordering.md, decided 2026-10-30): edakit prepares the order, Claude fills the maker's form in the owner's browser (skill cart), edakit checks what it brings back; up to the maker's cart button, never further

Replaces B-7

edakit cart confirm: what the maker asks to confirm after the order, as the skill cart read it into confirm.json – the production file, where the maker asked for it: both renders seen and as released; the placement as the maker's engineer adjusted it: as many parts assembled as the job places, none unassembled, every polarised part of the polarity sheet (FILES.sheet) read with its pin 1 and judged right, no part judged wrong, no DFM finding. ORDER.read and ORDER.parts run on the same files: every value in the page text, every part of the job's BOM in the placement with the job's part number. With --sign BY and every check passed, M-2 is written into the sign-off file for the job's fab hash – the owner's word, never on its own.

Why

M-2 is the one manual check that happens on the maker's pages after the order: the placement the maker builds from is the one its engineer adjusted, not the preview of the quote, and the production file is the maker's rendering of the files. The first order (2026-11-02) read both by hand – the viewer's address from the page's data, the pin-1 dot and the anode + part by part against the sheet – and wrote M-2 by hand; a part judged wrong and still confirmed goes into production turned round.

What to do

A part found wrong: 'Not good, modification needed' on the maker's page, and the layout again (the CPL's rotation, SYNC.cpl); a part not read: open the viewer again and read it; counts that differ: the maker's BOM matching against the job (ORDER.parts). Nothing signed until the check passes.

Sources

1. The first order at JLCPCB (pytree, 2026-11-02): 'Confirm Production file' a dialog in the order history, 'Confirm Parts Placement' a second browser window; the placement viewer /smt/dfm-result read in the skill's own tab; M-2 written into signoff.json by hand
2. Ordering at the manufacturer (docs/concepts/done/ordering.md, decided 2026-10-30): edakit prepares the order, Claude fills the maker's form in the owner's browser (skill cart), edakit checks what it brings back; up to the maker's cart button, never further

edakit order check: the supplier's cart as the skill cart read it back (<out>/<supplier>/cart.json, LCSC) has every line of basket.json – edakit order's, --with projects included – by its code, as many pieces or more (more is the supplier's rounding, named), none with less stock than its quantity and none marked (discontinued, replaced, out of stock); no line that is neither the basket's nor in the cart before the upload; every code, quantity, stock and the weight of cart.json in cart_page.txt, the page text kept, a number as a number of its own. The lines there before the upload are the owner's – listed, never touched, never a finding. With the weights read it prints the parcel together and the routes to compare before the maker's checkout; with shipping.json, LCSC's methods after combining by price and the cheapest arriving by [cart] needed_by.

Why

The first parts order (2026-11-02) went by hand: three lists merged by a throwaway script, uploaded to a cart that already held 25 lines of earlier work, nothing showing which lines were this order's or whether LCSC had rounded or replaced one. The combined shipment was decided before its prices were known – JLCPCB's address cannot be changed after its checkout – and cost 74.94 USD against 48.94 for the two cheapest separate routes; after combining DHL Express was paid instead of the cheapest express.

What to do

A line missing or short: upload the basket's line again, never change a line that was there before. Out of stock or marked: another part is a hardware change (skill hardware-change), then edakit order again. A line not read: read the cart again and keep its page text whole.

Sources

1. The parts order (docs/concepts/done/parts-order.md, decided 2026-11-02): decision 3 – the skill fills LCSC's cart and stops before the checkout, lines already there only reported; decision 5 – the skill enters LCSC's warehouse at JLCPCB's checkout
2. LCSC, 'Combine Your LCSC and JLCPCB Orders', https://www.lcsc.com/faqs/ordering-quotation/combine-lcsc-jlcpcb-orders (read 2026-11-02)