Feature: Supplies stock - manual counts, receives, adjustments, and waste #768

Status

Planned follow-on: supplies stock starts only after the completed product-ledger baseline in #280 / PR #775. This issue records a bounded proposal only; it does not authorize implementation.

Problem or motivation

Merchants need to count supplies held on hand that are not necessarily sellable menu products: for example packaging, cleaning materials, or manually tracked ingredients. Product stock in products cannot represent those items without turning every supply into a sellable catalog product, and the product ledger does not infer raw-material usage.

Current behavior

FloCafe has finished-product stock and the completed product movement ledger, but no separate supplies-stock catalog, base-unit model, or manual movement history for non-product supplies. There is no automatic recipe deduction in this scope.

Desired outcome

Provide a small offline supplies-stock workflow that lets an authorized operator create or activate a supply item, record its on-hand count, receive stock, make a reasoned adjustment, record waste, and review low-stock state and movement history without introducing purchasing or ERP behavior.

Proposed technical approach

• Keep supplies distinct from sellable products; do not force non-menu items into the product catalog.
• Use a small stock-item record with name, active state, required base unit (each, g, kg, ml, or l), on-hand quantity, and optional low-stock threshold.
• Reuse the completed ledger's local SQLite, atomic-write, append-only movement, actor attribution, reason, timestamp, and resulting-quantity conventions.
• Support only explicit manual movement types for the first phase: receive, count, adjustment, and waste. Counts and adjustments must define whether the submitted quantity is an absolute count or a signed delta.
• Gate management and history with the existing owner/manager role conventions, and keep all operations offline-capable.
• Require fresh-database and upgrade-path checks that preserve existing product/order data.

Alternatives considered

• Treating supplies as products would pollute the sellable catalog and cannot express non-menu units cleanly.
• Automatically deducting supplies when a menu product sells belongs to the separate recipe/BOM pilot in #769.
• Supplier accounts, receiving against purchase orders, and invoice settlement belong to the separate materials-expense/finance discussion in #645.

Area

Inventory / Products / Menu

Acceptance criteria

• Offline create/activate, count, receive, adjustment, and waste flows use one atomic append-only movement history.
• Quantities are validated in the declared base unit and cannot silently become negative or non-finite.
• Owner/manager permissions and actor/reason history are enforced.
• Low-stock visibility is available without a purchasing, supplier, or ERP subsystem.
• Existing product/order data survives fresh and upgraded database paths under the additive migration policy.
• No menu sale changes a supply quantity unless a later recipe issue explicitly links the two.

Explicit exclusions

No recipe/BOM deduction, add-on stock, supplier accounts, purchase orders, invoices, accounts payable, partial payments, automatic purchasing, multiple warehouses, transfers, demand forecasting, valuation, or full ERP/accounting behavior.

Dependencies and sequencing

This issue depends on the completed product-ledger conventions in #280 and is the first planned inventory follow-on. The recipe pilot in #769 must remain separate and later. The materials-expense issue #645, cash-drawer delivery PR #772, and receipt projection issue #770 are related but not substitutes or implementation dependencies.

Review request

@itsbkm, please review the proposed boundary and sequencing, share your thoughts, and let us know whether you are willing to take over or collaborate on this issue after the product-ledger baseline.

Additional context

The purpose of this issue is manual supplies stock, not a hidden ingredient or purchasing system. Any broader demand should be captured as a new, explicit scope decision.