Inventory Management Planner

The problem this kills

Most inventory systems that come out of AI-assisted builds share the same fatal flaw: they store stock as a single editable number. When that number drifts — because two clerks entered the same delivery, because a write failed halfway, because someone "corrected" a count directly — there is no trail to explain why. You cannot reconcile it. You cannot audit it. You cannot trust the reports.

The second failure is scope bloat. Marketplace scripts bundle POS checkout, ecommerce sync, accounting ledgers, HR, and SMS into what the buyer asked for as stock control. The generated code inherits all of it. The buyer spends weeks debugging features they never wanted and never gets a working reorder alert.

The third failure is premature branching. Low-stock alerts, basic purchasing, barcode fields, and physical counts are the reason small teams adopt inventory software in the first place. Sending an agent straight to WMS bin-level picking or FEFO expiry workflows without asking what the buyer actually needs produces a spec that is too large to build, too complex to test, and too specific to be useful.

Why your agent cannot fake this

This planner is grounded in a research pass across SaaS product pages (Zoho Inventory, Odoo, ERPNext, Cin7, Katana, Fishbowl, Finale, Ordoro), official workflow documentation, open-source ERP schemas, CodeCanyon marketplace scripts, and community pain reports from practitioner discussions. That evidence base produced a feature inventory covering item/SKU master design, stock ledger architecture, purchasing and receiving workflows, physical count patterns, barcode and scanner levels, batch/expiry/serial traceability branches, multi-location transfer rules, and warehouse operations — each tagged by frequency tier and source.

Your agent cannot reproduce that without redoing the research. It cannot tell you that stock movement must be documented before stock physically moves (not after, in a batch), that lot/serial corrections require adjustment-out/adjustment-in with preserved audit trail, that scanner-as-keyboard and dedicated hardware scanner are two entirely different build paths, or that ecommerce sync requires an explicit source-of-truth decision before a single line of integration code is written. The planner encodes all of that as decision rules, not suggestions.

What you actually get

A structured interview that forces scope decisions before any code is written: First Delivery depth (Basic, Moderate, or Advanced), business shape, role selection, core stock loop, purchasing and location branches, traceability level, barcode/scanning level, import needs, integrations, negative-stock policy, stack preference, UI priority, and build execution mode.

After discovery, the planner runs a forbidden-family scan across your selected scope — blocking POS, ecommerce, accounting, manufacturing, offline sync, hardware SDK claims, AI forecasting, and 3PL portals from leaking into roles, data model, screens, workflows, APIs, reports, build steps, and acceptance tests unless you explicitly selected them.

The output is one complete, tool-aware build spec: CLAUDE.md for Claude Code or AGENTS.md for Codex. Every major recommendation cites a research anchor. Every build step includes the tables it touches, the screens it produces, the server actions it requires, seed data, an acceptance checkpoint, and a hard gate before the next step begins. Step 1 alone delivers a real product shell — owner dashboard with low-stock queue and recent movements, stock clerk workbench, item list and detail with movement ledger, setup/profile/users — not a skeleton with placeholder routes.

The final handover gate requires a hands-on walkthrough: create a real SKU, post opening stock, post stock-in/out/adjustment with reasons, attempt a blocked negative-stock write, verify the item ledger matches the dashboard and CSV export, switch roles, restart the server, confirm survival.

Coverage

Basic (7-9 steps): business and location setup, owner/admin and stock clerk roles, item/SKU master with category/unit/barcode field/reorder point, opening stock, full stock movement ledger, manual in/out/adjustment with reason and audit, low-stock dashboard and report, item detail movement history, inventory summary and movement exports, real persistence, server-side RBAC, audit log.

Moderate adds: purchase order lifecycle and receiving, physical count/stocktake workflow with variance review, barcode label printing and scan-to-receive/count, multi-location transfer orders with in-transit state, richer reports.

Advanced covers: warehouse bins and picking/packing, regulated batch/expiry/serial traceability with FEFO rules, ecommerce and accounting integrations (with source-of-truth architecture), offline mobile workflows, 3PL client portals, SaaS multi-tenant onboarding.

Every branch is gated behind an explicit buyer selection. Nothing bleeds in from "inventory" alone.