Implement product lifecycle and supplier reorder planning

[OneTwo3D]

Summary

• Add DRAFT/ACTIVE/EOL/ARCHIVED lifecycle statuses with migration from NOT_FOR_SALE to EOL.
• Add preferred supplier tracking, supplier filters, supplier-scoped reorder draft PO generation, and PO line reorderEvidence.
• Add EOL auto-archive cron backed by structured incoming-stock checks across POs, transfers, production, and WMS ASN evidence.

Validation

• npm run validate
• npm run validate:db
• npx tsx --test tests/products-lifecycle.test.ts tests/domain/purchasing/preferred-supplier.test.ts tests/domain/inventory/replenishment-reports.test.ts
• npx tsx --test tests/domain/inventory/product-lifecycle-archive.test.ts

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 594af9368b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[OneTwo3D]

PR #156 — Product lifecycle + supplier reorder planning (P8.1 + P8.2)

Implementation of Group 21 from PR #155. 39 files / +976/-133. Migrates ProductLifecycleStatus enum, adds preferredSupplierId + preferredSupplierLocked to Product, skipPreferredSupplierUpdate to PurchaseOrder, reorderEvidence JSONB to PO lines. New lib/products/lifecycle.ts state machine helpers, lib/domain/purchasing/preferred-supplier.ts auto-update on PO_SENT, lib/domain/inventory/product-lifecycle-archive.ts cron-driven archive job, route at /api/cron/product-lifecycle-archive.

PR #155 spec findings — all addressed

PR #155 ID	Issue	Status
ljw	Migration path from NOT_FOR_SALE	✓ — SQL maps NOT_FOR_SALE → EOL
dn2	Incoming stock spec	✓ — getProductIncomingStock returns structured breakdown across PO/transfer/production/WMS ASN
tep	SupplierProduct overlap	✓ — field named preferredSupplierId; SupplierProduct retained for catalog metadata
2uu	Timing / rollback semantics	✓ — PO_SENT trigger, skipPreferredSupplierUpdate per-PO opt-out, preferredSupplierLocked per-product opt-out, explicit no-rollback policy
f91	Forecast evidence schema	✓ — reorderEvidence JSONB field on PO line

Good response to spec feedback. The implementation is clean: backfill query in migration uses DISTINCT ON + COALESCE(poSentAt, updatedAt, createdAt) DESC for ordering, row-level FOR UPDATE locks ordered by id, EOL → ARCHIVED transition is per-candidate transactional.

4 new findings filed in bd on PR #156's implementation (commit 33fbd7ce).

Findings filed in bd

Priority	bd ID	Title
P2	onetwo3d-ims-27w	getReorderReport uses supplierProducts[0] as primary, preferredSupplier as fallback — inverts auto-update intent
P2	onetwo3d-ims-ywu	OPEN_WMS_ASN_STATUSES counts CREATE_PENDING / CREATE_IN_FLIGHT as firm incoming stock
P2	onetwo3d-ims-3i3	updatePreferredSuppliersForPlacedPurchaseOrder writes no activity log — silent supplier reassignment
P3	onetwo3d-ims-zqe	Third instance of $executeRaw for SELECT FOR UPDATE — same anti-pattern as PR #127

Why P2 on 27w

This one closes the loop on the P8.2 implementation. The auto-update writes the latest-PO-supplier to product.preferredSupplierId. But getReorderReport's displaySupplier logic:

const supplier = product.supplierProducts[0] ?? null
const displaySupplier = supplier ? { ...A from catalog } : product.preferredSupplier ? { ...B } : null

…uses supplierProducts[0] (the SupplierProduct catalog row) as the PRIMARY source. preferredSupplier only fills in when no SupplierProduct row exists. So a product that had Supplier A in its catalog AND a recent PO with Supplier B (which set preferredSupplierId=B) shows A in the reorder report. The "latest placed PO wins" signal is silently dropped at the read path.

Cleanest fix: look up the SupplierProduct row matching preferredSupplierId first; fall back to supplierProducts[0]. Gets the catalog metadata for the most-recently-used supplier when both signals exist.

Why P2 on ywu

OPEN_WMS_ASN_STATUSES = ['CREATE_PENDING', 'CREATE_IN_FLIGHT', 'OPEN', 'PARTIALLY_BOOKED_IN'] includes pre-confirmation states. A stuck CREATE_PENDING ASN (queue dead-letter, WMS reject loop) indefinitely counts as "incoming stock", silently deferring archive forever. EOL products with stuck ASNs never auto-archive. Either exclude the pre-confirmation states or time-bound them.

Why P2 on 3i3

updatePreferredSuppliersForPlacedPurchaseOrder performs updateMany and returns the affected count, but writes no activity log. A 200-line PO can flip 200 products' preferred supplier without audit trail. Operators asking "why did the preferred supplier change?" have no answer. Same audit gap pattern as PRs #128/#129/#138 silent dedup branches.

P3 — $executeRaw for SELECT FOR UPDATE

Third instance in the codebase (after PR #127's po-cancellation.ts finding). Both preferred-supplier.ts and product-lifecycle-archive.ts use this anti-pattern in the new code. Worth a codebase sweep + ESLint rule.

Notes

• The migration SQL backfill uses COALESCE(po.poSentAt, po.updatedAt, po.createdAt) for ordering — robust to historical data where poSentAt may be missing. Good defensive choice.
• The auto-archive job's archiveExhaustedEolProducts is per-candidate transactional (good) but processes sequentially up to limit=500. For tenants with thousands of EOL products, archive lag is multiple cron ticks. Acceptable but worth documenting.
• isPurchasableProductStatus includes DRAFT — operators can place POs for products that aren't yet sellable. Worth a UX warning on PO create for DRAFT products (would prevent the "the goods landed but I can't sell them" surprise).
• All 4 bd issues tagged pr-156 for filtering: bd list --labels pr-156