# Tasks Planning completion is not implementation approval. Consumer changes and schema changes retain the explicit confirmation boundaries in design.md. Complete independent backend tasks when apply is requested; do not mark blocked capabilities delivered. ## 1. Persistence and compatibility prerequisites - [x] 1.1 Add a read-only Inventory preflight for multi-location balances, invalid quantities, ledger/balance disagreement, and identifier collisions; verify isolated valid/invalid fixtures and document findings without auto-repair. - [x] 1.2 Present concrete photo persistence, retry persistence, and mixed-disposition schema candidates before editing schema; verify an explicit user decision is recorded for each required change or an explicit scoped deferral updates the artifacts. - [x] 1.3 Present the consumer compatibility contract for approval queue, request status, stock adjustments, QR navigation, optional location, and movement types/export; verify consumer files remain untouched unless separately authorized. - [x] 1.4 Define durable retry storage and canonical payload matching for creation, zero-stock master writes, posting, and decisions; verify the design covers concurrent retries and actor/key collisions before implementing it, requesting confirmation if a migration is needed. - [x] 1.5 Implement only approved persistence changes and internal-room bootstrap; verify clean/populated isolated migration fixtures preserve history and document forward repair/rollback without destructive data merging. ## 2. Contracts and catalogue - [x] 2.1 Add explicit non-financial Inventory DTOs in the authorized shared workspace, strict validators, and error codes; verify contract tests reject spoofed actors/deltas, invalid quantities, and database-length violations. - [x] 2.2 Implement catalogue/detail, lookups, group filtering, search, and global summary; verify filtered counts, page boundaries, stock status at zero minimum, archived targets, and stable sorting with MySQL fixtures. - [x] 2.3 Implement authorized metadata writes and normalized group/kind resolution without new place/rack inputs; verify duplicate product-ID races, duplicate part numbers, and immutable unit after posting. - [x] 2.4 Document catalogue endpoints and compatibility limits in OpenAPI and source docs; verify source/compiled contracts and no financial fields in DTOs. ## 3. Posting and technical movement history - [x] 3.1 Implement the shared transaction-client posting service and single-room balance locking/version checks; verify real MySQL rollback and competing issue/hold tests preserve all quantity invariants. - [x] 3.2 Implement atomic initial receipt with part creation and privileged receipts/adjustments; verify zero initial stock creates no zero movement, reason is required for adjustment, and partial creation rolls back. - [x] 3.3 Implement durable idempotent replay using the reviewed storage design; verify lost-response retry, different-payload conflict, cross-actor collision, and concurrent identical requests without duplicate audit. - [x] 3.4 Implement bounded returns and full reversal; verify excess returns, double reversal, reversal-of-reversal, receipt reversal after consumption, and case-effect rollback. - [x] 3.5 Implement posted history/detail and filtered XLSX export; verify month boundaries in facility timezone, page-independent export, explicit size limit, literal user text, signed deltas, and absence of financial fields. - [x] 3.6 Document posting rules, new error responses, export bounds, and the technical-only exception to financial schema notes; verify OpenAPI tests cover the implemented routes. ## 4. Checkout and approval - [x] 4.1 Implement grouped catalogue and explicit QR resolution for current product IDs and tokens, with ambiguity handling for legacy part numbers; verify reads never mutate stock and require no location. - [x] 4.2 Implement public checkout with required identity and universally PENDING requests; verify all roles, identity spoofing, required purpose and rejection of WO linkage, and no HIGH/URGENT bypass. - [x] 4.3 Implement token-protected public request status and privileged pending queue; verify object-level access and rejection of unauthorized review. - [x] 4.4 Implement approve/reject with current role checks, posting-time stock/requester validation, and attributed review audit; verify approve-versus-reject races, repeat decisions, insufficient stock remaining pending, and inactive accounts. - [x] 4.5 Document checkout states, no-reservation semantics, and goods collection only after posted success; verify endpoint examples and contract tests agree without editing kiosk or settings UI. ## 5. Quarantine and Maintenance boundary - [x] 5.1 Implement immediate holds and case reads under the explicitly documented hold policy; verify technician attribution, physical stock unchanged, duplicate retries, issue-versus-hold races, and no automatic WO creation. - [x] 5.2 Implement privileged release/scrap and reversals after applicable disposition confirmation; verify partial/mixed quantities, terminal state, case reopening through reversal, and concurrent over-disposition prevention. - [x] 5.3 Expose Inventory service contracts for future WO issue/return and net usage without adding WO execution endpoints; verify pending exclusion, unallocated issues, immutable WO references, and shared-transaction failure rollback. - [x] 5.4 Document quarantine policy, disposition semantics, and Maintenance integration; verify OpenAPI and isolated transaction tests cover the supported behavior. ## 6. Photo checkpoint and release validation - [x] 6.1 After explicit photo-design approval, implement the approved photo API/storage lifecycle or record an explicitly approved scope deferral; verify valid images, size/type validation, stale writes, rollback cleanup, and preserved save semantics with no unapproved consumer edits. - [x] 6.2 Run API typecheck, build, existing tests, new isolated MySQL suites, and compiled Swagger contract checks; verify auth and Pilot Plant/Work Order read regressions remain green and report skipped database suites honestly. - [x] 6.3 Review changed-file scope and release notes; verify no consumer files, schema modifications, or migrations exceed explicit authorization, and distinguish backend availability from end-to-end consumer readiness. ## Workflow follow-up - Obtain separate authorization for concrete frontend integration changes and an appropriately writable monorepo workspace before modifying consumers. - Archive/sync through OpenSpec after implemented scope and required confirmation checkpoints are resolved; do not equate artifact existence with delivery.