用途：根据实际销售情况判断该补什么、什么时候补，同时停止采购卖不动的商品。库存是已花出去的现金，缺货与积压都能在销售历史中提前看到。
主要能力：第一步获取销售与库存数据，首选 Shopify，Square 和 NetSuite 同理；也完全支持 CSV 回退路径，只需销售历史加现有库存，零连接器即可，输出相同。每项需 SKU、名称、按日销量、现有库存、单位成本、单价、供应商，以及已知的提前期；缺失的提前期会询问一次并记住。需说明盘点截止日期，两周前的库存数会导致缺货日期偏差两周。
第二步计算 7 天与 28 天两个窗口的速度，两者不一致本身是信息，需区分趋势与一次性大单，并尽量排除一次性失真（单笔批发、退货批次、因缺货导致的零销售期）。第三步保守预测缺货日期，用两个窗口中较高的速度，再与提前期比较，分为已过不可逆点、立即下单、尽快下单、无需行动；无可靠速度的商品按 SKU 标注“历史不足”，不给缺货日期。第四步确定补货量，默认目标为 60 天覆盖加提前期，按 28 天速度计算，并调整包装规格、最小起订量和在途库存；必须减去在途，按供应商包装取整并说明方向，每条建议显示美元成本。第五步单独处理不动销商品：28 天零销量列为滞销并报告占用现金，超过 120 天覆盖为积压，90 天无动销为死库存，建议清仓、捆绑或打折，并汇总占用现金。第六步仅在至少一年历史时应用季节性，不足一年则说明不调整并询问店主。第七步呈现采购清单，先给总金额与即将缺货数量，再分立即下单、尽快下单、滞销、历史不足，每行附速度、覆盖天数、提前期、数量、成本，并渲染为 HTML 制品。第八步起草采购单与供应商邮件，两者都需明确批准；可提供补货决策的周期性日历块，并与 QuickBooks 或 NetSuite 配合把编码备忘交给 ap-processor。
限制：不得编造速度、提前期或缺货日期；不得把缺货期当作零需求；不得建议补货零速度商品；不得在未减在途时确定补货量；不足一年不得应用季节性；未经批准不得发送采购单或供应商邮件；不得只报数量不报金额。未列出的工具可通过 build-connector 连接，先查连接器目录，否则经 Zapier 接入，不手写原始 API。