# Inventory Threshold Monitoring

Run a scheduled sweep of stock levels and sales velocity, and raise a reorder-proposal task whenever an item breaches its configured threshold.

## When to use

- You need recurring visibility into stock-outs and slow-moving inventory without a human checking dashboards daily.
- Sales velocity has changed and reorder points need to be flagged before a stock-out hits.
- A warehouse or store location reports low counts and you need to confirm it against the source system before anyone reorders.
- You want reorder decisions proposed for human approval rather than placed automatically.

## Tools

- `http-get` - read current stock levels, sales velocity, and reorder thresholds from the commerce or inventory platform's REST API.
- `shell-execute` - run local calculations (e.g. days-of-cover, velocity trend) over the data pulled from the API when the platform does not expose a pre-built report.
- `schedule-task` - set up the recurring sweep (for example, run every morning) so monitoring happens without a manual trigger each time.
- `send-message` - notify a human or another agent in-session when a breach is detected or when input is needed.
- `create-task` - open a reorder-proposal task for human approval whenever a threshold is breached.

## Playbook

1. On each scheduled run (set up once via `schedule-task`), call `http-get` against the inventory platform, e.g. GET https://api.example-commerce.com/v1/inventory/levels, to pull current on-hand quantities for all tracked SKUs.
2. Call `http-get` again, e.g. GET https://api.example-commerce.com/v1/reports/sales-velocity?window=14d, to retrieve recent sales velocity per SKU.
3. Use `shell-execute` to compute days-of-cover per SKU (on-hand ÷ daily velocity) and compare against each SKU's configured reorder threshold.
4. For any SKU below threshold or projected to stock out within the org's lead-time window, call `http-get` on the specific SKU record, e.g. GET https://api.example-commerce.com/v1/inventory/items/{sku_id}, to confirm the figure is current and not a sync lag artifact.
5. If confirmed, open a `create-task` reorder proposal containing the SKU, current stock, velocity, days-of-cover, and a suggested reorder quantity, and route it to the human owner for approval — never place the order or write the catalog yourself.
6. If no Integration row exists for the inventory platform's host, or a call returns 401/403, stop and use `send-message` to alert a human, naming the service and the scopes needed.
7. Once the sweep completes, use `send-message` to post a short summary (SKUs checked, breaches found, tasks opened) to the relevant channel or agent.
8. If the reorder-proposal task requires a catalog write, price change, or refund above the org's configured threshold, do not execute it — the `create-task` approval gate is mandatory and no autonomous action should follow.

## Failure modes

- The inventory platform's API paginates or rate-limits large SKU catalogs, causing partial sweeps that under-report breaches; check for pagination tokens and retry with backoff.
- Sales velocity data lags real-time sales (e.g. batch-updated overnight), producing false stock-out projections; always cross-check against a fresh on-hand read before opening a task.
- Duplicate reorder-proposal tasks get created across consecutive runs for the same SKU; check `list-tasks` (or equivalent open-task state) before creating a new one for a SKU already pending approval.
- Missing or expired Integration credentials silently fail calls; treat any 401/403 as a hard stop and escalate via `send-message` rather than guessing at values.

## Done when

- The sweep has run on schedule, all tracked SKUs have been evaluated against their thresholds, and a summary has been posted via `send-message`.
- Every SKU found in breach has exactly one open reorder-proposal task awaiting human approval, with no autonomous reorder, price change, or refund executed.