Claude Prompt

/devlyn:resolve "Add a `fulfill-wave` command to `bench-cli` so users can run `bench-cli fulfill-wave --input <path>`. The input file is one JSON object with the required collections `{ \"warehouses\": Array<Warehouse>, \"orders\": Array<Order> }`: a warehouse has `{ \"id\": string, \"distance\": number, \"lots\": Array<Lot> }`; a lot has `{ \"sku\": string, \"lot\": string, \"qty\": number, \"expires\": \"YYYY-MM-DD\" }`; an order has `{ \"id\": string, \"priority\": number, \"submitted_at\": string, \"lines\": Array<Line> }`; and a line has `{ \"sku\": string, \"qty\": number, \"single_warehouse\": boolean }`. Validate the complete input before allocating: ids and SKU/lot identifiers must be non-empty strings, quantities must be positive integers, lot expiry values must be valid `YYYY-MM-DD` calendar dates, submitted times must parse as ISO dates or timestamps, distances and priorities must be numbers, the named collections must be arrays, and order ids must be unique. Do not mutate the input file.\n\nProcess orders globally by priority descending, then `submitted_at` ascending, then id ascending. An order is all-or-nothing: if any line cannot be fully allocated, reject the order and restore every stock deduction tentatively made for it. Accepted allocations reduce stock for later orders; rejected orders do not. A normal line (`single_warehouse: false`) may split across warehouses and lots. A `single_warehouse: true` line must come entirely from one warehouse, although it may consume multiple lots in that warehouse; reject it when no one warehouse has enough stock even if the combined stock across warehouses would suffice. Consider warehouses by distance ascending, then warehouse id ascending. Within a chosen warehouse, consume matching lots FEFO by expiry ascending, then lot id ascending. Allocation rows must remain in the exact sequence stock was chosen.\n\nOn success, write exactly one parseable JSON object to stdout, write nothing to stderr, and emit no extra text. The success object's only keys are `accepted`, `rejected`, and `remaining`. `accepted` follows processing order; each row has exactly `{ \"id\": string, \"allocations\": Array<Allocation> }`, and each allocation has exactly `{ \"sku\": string, \"warehouse\": string, \"lot\": string, \"qty\": number }`. `rejected` follows original input order; each row has exactly `{ \"id\": string, \"reason\": \"insufficient_stock\" }`. `remaining` contains positive leftover lot quantities, sorted by warehouse id, then sku, then expiry, then lot id; each row has exactly `{ \"warehouse\": string, \"sku\": string, \"lot\": string, \"qty\": number, \"expires\": \"YYYY-MM-DD\" }`.\n\nInvalid input and file-read failures must exit `2`, write nothing to stdout, and write exactly one parseable JSON value to stderr. That value must be a non-null, non-array JSON object; its member names are otherwise not prescribed.\n\nUpdate `tests/cli.test.js` so all existing tests still pass and add at least two `fulfill-wave` tests covering an accepted allocation and a rejected all-or-nothing order. Do not use a catch block that silently returns `null`, `undefined`, an empty string, or an empty object, and do not use an empty catch block. No new npm dependencies. Carrier selection, package dimensions, backorders or partial order acceptance, and persistence beyond stdout are out of scope. Only touch `bin/cli.js` and `tests/cli.test.js`." --pair-verify