Context
Receiving one pallet twice because a request was retried is a correctness failure. This inbound prototype covers facility configuration, packaging, expected receipts, receiving, directed putaway, inventory, and reconciliation. Outbound work remains future scope.
Architecture
A React workbench calls a .NET API organised into configuration, catalogue, inbound, inventory, and work modules. SQL Server holds operational records and immutable inventory events. The modular monolith keeps related changes within one application and transaction boundary; facility context accompanies each command.
Engineering Decisions
The architecture above keeps the command receipt and domain change in one transaction. An exact retry returns the recorded response; a changed payload under the same identity conflicts. Different command IDs still need domain validation.
Corrections append events instead of rewriting history. Balances can then be reconciled against the ledger. Splitting these modules into services would add coordination costs before the current slice needs independent deployment.
How It Breaks
Repeated submission, wrong facility context, unit mismatch, and confirmation at the wrong location can all produce a plausible response with an incorrect physical outcome. Checks must inspect resulting inventory, not just HTTP status.
The July 28 browser record exposed Enter-key submission failures despite component checks. Visible buttons completed that journey. The fresh capture also uses buttons; it does not close the scanner or keyboard acceptance gap.
Testing & UAT
The new walkthrough started with one open synthetic expectation and no inventory. Receiving and putaway completed through the real UI. Exact API replays reused each browser-generated command identity and payload; both returned the saved result. Subsequent read-only API and SQL checks found the counts shown above.
Representative warehouse operators still need to exercise uncertain submission status, corrections, facility changes, and physical scanners. A controller-driven browser run verifies a workflow; it cannot establish usability on a warehouse floor.
AI: Now / Future
The operational boundary stays the same whether a person or an assistant proposes the next action.
Now
No runtime AI feature is established in the reviewed operational implementation. AI-assisted development is separate from AI making warehouse decisions.
Future · Proposed
Start with read-only investigation of discrepancies, citing inventory events and exposing uncertainty. Stock movements would require a separately designed approval and verification path.
Observability & Measurements
Command and correlation IDs connect requests to stored outcomes. The current evidence checks event counts, saved responses, task state, and ledger-to-balance reconciliation. Latency, contention, operator completion time, and load limits have not been measured for this case study.
What Changed After Testing
Earlier verification changes required proof of open work before the browser journey and tied final assertions to that preparation. This prevents an already completed API run from masquerading as a new UI journey.
The fresh run confirms button-driven completion and replay invariants. It also makes two interface limits visible: operators select a facility by UUID, and there is no transaction-history screen. Those remain work to validate with users.
What I’d Change at 10× Scale
With ten times the concurrent operators, I would measure contention around receiving, putaway, and replay, including conflicting commands with different IDs. Keep checking the same inventory invariants. A new service boundary would follow a measured bottleneck rather than the size of the roadmap.