Add invariant preflight CI gate

[OneTwo3D]

Summary

• Add npm run invariant-check:preflight using the scheduled invariant reporters with cron side effects disabled.
• Add a production-readiness CI job that migrates a clean Postgres database and fails on report failures or critical invariant findings.
• Document remediation steps for invariant preflight failures.
• Mark group 20 complete in docs/plan.md and re-add group 21 for product lifecycle statuses / EOL sell-off planning.
• Add P8.2 to group 21 for product supplier tracking from the latest placed PO, supplier filtering, and supplier-scoped draft PO generation from reorder forecasts.

Validation

• npm run lint: pass
• npm run type-check: pass
• npx tsx --test tests/cron/invariant-check-preflight.test.ts tests/cron/invariant-check.test.ts: pass
• npm run validate: pass
• npm run validate:db: pass
• npm run invariant-check:preflight: command path verified; local DB config fails with Prisma auth error as expected and exits non-zero without hanging.
• Latest P8.2 update: docs/beads only; git diff --check pass.

Risk areas

• CI runtime increases by one Postgres-backed job on non-doc PRs.
• The preflight uses a clean migrated DB in CI; tenant data checks still need cron/operator runs against tenant databases.
• Group 21 product lifecycle/supplier items are planned only, not implemented in this PR.

[OneTwo3D]

PR #155 — Invariant preflight CI gate (Group 20 / QG1) + Group 21 plan addition

Two things in one PR:

1. QG1 implementation: new npm run invariant-check:preflight script + lib/cron/invariant-check-preflight.ts helper + invariant-preflight CI job in the production-readiness workflow that boots a Postgres service, applies migrations, and runs the preflight.
2. Group 21 plan-only addition: P8.1 product-lifecycle statuses (active, draft, eol, archived) and EOL sell-off semantics in docs/plan.md. No code for this.

The CI gate's structure is clean: pure helper (runInvariantCheckPreflight) takes a runCheck dependency injection, returns a structured { ok, failure, result }, defaults wire up the real runScheduledInvariantCheck with cron side effects disabled. Tests cover the helper's branching logic (happy path, critical findings, divergent summary/list, partial failure).

But the gate's coverage is narrower than the PR claims, and the plan addition introduces scope without fully specifying it.

4 findings filed in bd on this PR's branch (codex/ci-invariant-gate, commit 0219af2d).

Findings filed in bd

Priority	bd ID	Title
P2	onetwo3d-ims-ejx	CI preflight runs against fresh empty DB — code-correctness only, not data-level
P2	onetwo3d-ims-ljw	P8.1 missing migration path from existing ProductLifecycleStatus enum
P3	onetwo3d-ims-dn2	P8.1 "incoming stock" auto-archive query spans 5+ tables; needs concrete spec
P3	onetwo3d-ims-l7d	No integration test for the real runScheduledInvariantCheck codepath

Why P2 on ejx and ljw

• ejx — the original QG1 acceptance was "Synthetic data with a known invariant violation; assert CI fails." The PR's tests cover this on a mocked result, but the actual CI workflow runs against an empty migrated DB, where every invariant trivially passes. The gate catches code-level regressions (e.g., a refactor that makes a reporter throw on empty input) but does NOT catch data-level invariant violations — yet the PR description and the plan closure imply the latter. Worth making the scope explicit OR seeding a known-violating fixture in the CI step to genuinely deliver the acceptance criterion.

• ljw — the existing ProductLifecycleStatus { ACTIVE, NOT_FOR_SALE, ARCHIVED } enum at prisma/schema.prisma:36-40 needs an explicit mapping to the new { active, draft, eol, archived }. The plan acceptance criteria mention 'each allowed and blocked transition' but the transition diagram is unstated. Existing NOT_FOR_SALE could plausibly map to draft (never published) OR eol (post-publication withdrawal) — operators need a default policy.

Notes

• The CI workflow gating if: needs.classify_changes.outputs.run_expensive == 'true' is the right shape — docs-only PRs skip the Postgres-backed job.
• disconnectDb with the 5-second race + timeout.unref() is good defensive pattern for CI not hanging. Standard.
• The "divergent critical summary/list" defensive test (tests/cron/invariant-check-preflight.test.ts) is a nice touch — catches a class of bug where the count and the list could drift in runScheduledInvariantCheck.
• Adding Group 21 to the plan is the right home for the EOL discussion. The plan-only nature means no code review is needed for the implementation; the findings are entirely about pinning the spec before any implementation PR.
• All 4 bd issues tagged pr-155 for filtering: bd list --labels pr-155

[OneTwo3D]

PR #155 — Second-pass review

Commit 65b726da added P8.2 to Group 21: product supplier field + supplier-scoped reorder drafts from forecasts. This commit doesn't touch code — purely a docs/plan.md addition that builds on P8.1 (the existing Group 21 entry).

The first-pass review (against ce4914e6) covered the QG1 invariant CI gate and P8.1 plan addition. Those findings (ejx, ljw, dn2, l7d) still apply.

The P8.2 addition introduces a new product-supplier relationship that doesn't reconcile with existing schema and has subtle workflow semantics that would benefit from explicit spec before implementation.

3 new findings filed in bd on this PR's branch (codex/ci-invariant-gate, commit 9b9bc28f).

Second-pass findings filed in bd

Priority	bd ID	Title
P2	onetwo3d-ims-tep	product.supplier field overlaps with existing SupplierProduct many-to-many
P2	onetwo3d-ims-2uu	"Latest placed PO wins" doesn't handle emergency POs, transition timing, or rollback
P3	onetwo3d-ims-f91	"Preserve forecast evidence on each line" has no schema home today

Why the two P2s matter

tep — SupplierProduct (prisma/schema.prisma:943-958) already exists as a many-to-many between Product and Supplier with per-supplier metadata (supplierSku, lastUnitCost, leadTimeDays). P8.2 proposes a singular product.supplier field with auto-update from POs. The spec doesn't say:

• Whether the new field supplements SupplierProduct (preferred-supplier pointer) or replaces it (loses multi-supplier metadata)
• Backfill policy for existing products
• Multi-supplier products: do they oscillate per-PO, or does the auto-update opt out?

2uu — "Latest placed PO wins" is simple to implement but loses signal in real workflows:

• Emergency / backup POs silently overwrite the primary supplier
• "Placed" is ambiguous: PO_SENT, PARTIALLY_RECEIVED, or RECEIVED?
• No rollback when a PO is cancelled / returned (P now points at a supplier that never delivered)
• Concurrent multi-PO placement ordering not defined

Both findings are about pinning the spec before implementation. The cost of guessing the wrong interpretation is a redo of the relevant action paths + schema migration.

P3 — forecast evidence schema

f91 — the acceptance "lines carry enough forecast metadata to explain the suggested quantity" implies a schema addition that isn't enumerated. Three reasonable shapes (JSON field on PO line, parallel evidence table, activity-log only) have different ergonomics and queryability. Worth picking explicitly.

Notes on the QG1 part

No new code changes since ce4914e6 — first-pass findings on the CI gate (ejx, l7d) and P8.1 (ljw, dn2) still apply. Re-iterating the most actionable:

• ejx: CI runs against empty DB → seed a known-violating fixture to genuinely deliver QG1's acceptance
• ljw: P8.1 needs explicit mapping from existing ProductLifecycleStatus { ACTIVE, NOT_FOR_SALE, ARCHIVED }

Notes

• Group 21 now contains two planned items (P8.1, P8.2) with overlapping concerns: both touch the product schema, both interact with reorder forecast logic. Implementation should sequence P8.1 first (lifecycle states), then P8.2 (supplier field) — 2uu's rules need P8.1's eol/archived states to enforce the "EOL/archived excluded from draft generation" rule.
• All 3 new bd issues tagged pr-155 for filtering: bd list --labels pr-155 (now 7 total).