WFDASH-WEBAPP/docs/stock-counts.md

34 lines
4.3 KiB
Markdown
Raw Normal View History

# Giellie stock counts
Stock mode uses the ordinary Giellie text box, attachments and camera. It persists on the chat. Quantity changes require an explicit approval of a stored review even when Trust this chat is on.
Ask for a stock count sheet by supplier, brand text, category or selected items, optionally “split into three lists”. Every active matching item is included, even when unpriced or its tracked quantity is zero or negative. Brand selection is text-based until stock has a canonical brand field. Supplier means the item's default supplier.
PDFs show the sheet reference/revision, part, page, stable row reference, SKU, description, unit, current quantity at printing, and a blank physical-count box. Write zero explicitly; blank means not counted. A QR code opens the original chat/count context after sign-in. Upload completed JPEG/PNG/WebP photos through the chat camera or attachment control. Include the printed header, row references and SKUs. Photographs never change stock on their own.
Giellie returns a stored review. Clear counts can be approved while blank, uncertain, wrong-sheet and changed-since-printing rows remain held. Sales or receipts after printing require resolution/recount; upload time is not assumed to be the time of counting. Duplicate approvals use the same operation identifiers and return prior outcomes rather than applying again. A used sheet cannot be re-split; start a new count for a new observation.
## Deployment order
Developed in an isolated worktree; no live schema, hooks or stock were changed during implementation.
1. Review the branch and stock movement migration, including all existing stock writers. Take the normal database backup before schema changes.
2. Run `npm run pb:migrate:stock-movements` and `npm run pb:migrate:stock-counts` against the intended PocketBase instance. These are manual live steps. They add inventory revision/idempotency records, locked count/review collections, and chat mode.
3. Publish the committed hooks with `npm run pb:hooks:publish`. The DEPLOY manifest includes stock movement and stock count hooks. Verify the hook capability endpoint before enabling the rebuilt application.
4. Deploy the matching app version. Do not leave the old app serving stock writes while new hooks reject its unversioned direct writes; use a coordinated maintenance cutover.
5. Verify a stock-mode save round-trips, a small sheet downloads after reload, and a representative handwritten photo yields the right proposed counts. Verify actual counts and unclear readings with the operator before approving production changes.
The new flow fails closed if required hooks/schema are absent. Protected count PDFs are served through owned session-authenticated routes. Bearer tokens never appear in QR codes or browser links.
## Recovery
A connection failure does not prove a stock write failed. Retry with the same movement operation identifier to retrieve its committed outcome. Do not create a new operation ID for an uncertain retry. Catalogue mirrors are secondary; their failure must not replay an inventory movement.
The immutable count manifest and stock review live in PB, not solely in truncated chat history. Retain them and ledger/operation records for investigation. A PDF generation interrupted in building state has no inventory effect; regenerate before attempting a read.
## Verification record
Production build and TypeScript checks passed. Focused tests cover owned mode/attachments, sheet splitting and identity, photo parsing, review corrections/races, authenticated downloads, and stock movement integration. An isolated PocketBase 0.39.8 test exercised concurrent additions, ledger totals, idempotent replay, stale revisions, direct-write/modifier rejection and count-plan identity checks. PDF pages were rendered and visually inspected; the QR was decoded from the rendered sample.
The existing maintenance tests `scripts/backfill-stock-prices.test.ts` and `scripts/apply-default-markup.test.ts` import scripts that auto-run their CLI and call process.exit; these produce known unrelated test-runner errors. They are excluded from the clean application-suite verification; the full suite's assertion results were also inspected. Actual handwriting accuracy with the configured live model still needs representative operator photos before live rollout.