REQ-PRODUCTION-007: Phase-14 ProductionUnit lifecycle and startup safety #635

Goal

Implement permanent REQ-PRODUCTION-007: the minimum deterministic M4 ProductionUnit lifecycle for PLANNED, ACTIVE, MOTHBALLED, and CLOSING units, including explicit startup readiness, consecutive-review transitions, owner-funded startup cash, next-tick status effects, and safe retirement without residual canonical stock or references.

Evidence

• Current master is 31ceb3f71acb243ee97b6d8c5da15c584db36d13; REQ-PRODUCTION-001..006 and the M4 population rows through REQ-POPULATION-003 are integrated.
• Canonical Drive Handoff/05 §§22–25 assigns startup/lifecycle decisions to Phase 14. A PLANNED unit has no normal hiring/production, may accumulate startup investment goods, activates only after real capital/infrastructure/operating-cash readiness, and activation applies next tick. Mothball/reactivation/closing use configured consecutive-review counters; retirement is forbidden while canonical stock or references remain.
• ProductionConfig already owns the lifecycle cadence/threshold/count controls, and ProductionSignalState already persists viable/nonviable counters plus lastLifecycleReviewTick.
• The current live model is intentionally pre-lifecycle: ProductionUnitState has no mutable status; execution/planning still reads immutable unit.seed.status; ProductionUnitSeed.status has only ACTIVE | PLANNED | MOTHBALLED; CLOSING is absent; and PendingTransitions has no ProductionUnit lifecycle transition. This seam must be repaired by this requirement rather than treating scenario seed status as mutable runtime authority.
• Current Phase-2 planning returns zero normal activity and zero investment intents for every non-ACTIVE unit, so the PLANNED startup-investment path required by Handoff/05 is still absent.
• The registry row is READY, OPEN_QUESTIONS.md has no unresolved M4 blocker for this boundary, and there is no existing open canonical Issue dedicated to REQ-PRODUCTION-007.

Scope

• Add one authoritative live ProductionUnit lifecycle status to ProductionUnitState, initialized from scenario seed status. Runtime status must support PLANNED | ACTIVE | MOTHBALLED | CLOSING; never mutate seed.status and never introduce a second status authority.
• Preserve existing scenario compatibility: genesis seed status remains starting data; CLOSING is a runtime lifecycle state and need not become a normal baseline seed state unless the canonical schema explicitly requires it.
• Implement deterministic Phase-14 lifecycle review in stable ProductionUnitId order using live state, recipe requirements, current effective infrastructure/legal fixtures, home-currency cash, lifecycle signals/counters, and the configured cadence/threshold/count values already owned by ProductionConfig.
• Enforce next-tick lifecycle semantics. A Phase-14 decision must not retroactively make a freshly activated unit eligible for current-tick Phase 15 or any earlier normal activity. Use an explicit pending/next-state transition or an equivalently narrow mechanism with this causal guarantee.
• PLANNED units must remain excluded from normal labor demand, input procurement, and production, but may use the contract-owned startup investment path to accumulate required investment goods and capital. Activation requires real installedCapital, infrastructure and operating-cash readiness; no same-tick Phase-12 capital formation can enable current-tick production.
• Add an explicit owner-to-unit home-currency funding transition for startup cash when the lifecycle fixture requests it. Funding is a transfer only: owner treasury decreases by exactly the unit-wallet increase; no hidden FX, subsidy, credit, equity/debt instrument or money creation.
• ACTIVE review: update viable/nonviable counters only on due lifecycle reviews; reset the opposite counter deterministically; transition to MOTHBALLED only after the configured consecutive nonviable-review threshold.
• MOTHBALLED review: keep normal hiring/input procurement/production disabled; reactivation requires the configured consecutive viable-review threshold plus the same legal/infrastructure/capital/cash readiness gates as startup. Prolonged nonviability may enter CLOSING only through the configured close threshold.
• CLOSING units perform no new hiring, normal production, or new investment. Retirement/removal is allowed only after wallets/inventories/capital and every canonical reference owned by this M4 boundary are cleared within canonical tolerances; otherwise the unit remains CLOSING.
• Update all existing M4 production consumers that currently read unit.seed.status to read the new live status authority, with focused regressions preventing seed/runtime divergence from changing behavior.
• Add truthful REQ-PRODUCTION-007 = IMPLEMENTED ledger evidence only when the full lifecycle boundary is mechanically earned; keep MERGE_COMMIT blank until integration.

Non-goals

• No autonomous Clan/State strategy for choosing new business opportunities, ownership politics, dividends, equity, debt or M6 institution dynamics.
• No M5 trade/FX, M6 fiscal/Clan mutable institutions, M7 monetary dynamics, M8 demography/migration, or M9+ shocks.
• No redesign of Phase-2 ACTIVE planning, Phase-5 production, or Phase-12 capital formation beyond the minimum status/startup seams this requirement needs.
• No mutation of immutable scenario seeds and no edits under docs/spec/mirror/**.
• No removal of a unit that still owns money, INPUT/OUTPUT/INVESTMENT goods, material capital, or a live canonical reference.

Acceptance criteria

1. ProductionUnitState has exactly one mutable runtime lifecycle status; genesis deterministically initializes it from the seed, all runtime production/labor/lifecycle consumers use it, and seed.status remains immutable starting data.
2. Non-ACTIVE units never perform normal production or normal hiring/input procurement. PLANNED startup investment/funding is explicit and bounded; MOTHBALLED/CLOSING units cannot accidentally re-enter ordinary ACTIVE flows.
3. PLANNED → ACTIVE requires the canonical capital, infrastructure, legality and operating-cash readiness gates and becomes effective only next tick; a unit made ready by current-tick Phase 12 cannot produce in that same tick.
4. ACTIVE → MOTHBALLED, MOTHBALLED → ACTIVE and MOTHBALLED → CLOSING require the configured consecutive due-review counts with deterministic counter/reset behavior; off-cadence ticks do not advance review counters.
5. Owner funding is zero-sum in the settlement currency: exact owner debit equals exact unit credit, with no money creation/destruction and no implicit FX/credit.
6. CLOSING retirement fails closed while any material canonical wallet/inventory/capital/reference remains and removes the unit only when the safe-retirement contract is satisfied.
7. Lifecycle decisions/evidence are deterministic under shuffled map insertion order and reject stale/tampered/wrong-unit transition evidence; input WorldState remains immutable and persistence returns a new state.
8. Sensitive tests cover startup-not-ready, startup-ready-next-tick, same-tick Phase-12 non-leakage, owner-funding conservation, three consecutive nonviable reviews, viable-counter reset, reactivation, closing, residual-stock retirement refusal, safe retirement, and seed/live-status divergence.
9. Exact-head TypeScript typecheck/tests/build, retained .NET restore/build/test, policy/generated-status/ledger checks and mergeability are green before handoff. The IMPLEMENT run stops at the producer→judgement boundary for SLOPSTER.

Verification

Run focused lifecycle/startup regressions plus the repository TypeScript gates, retained .NET gates, implementation-status generation/check, policy checks and exact-head mergeability. Inspect the final diff for one live lifecycle authority, explicit next-tick semantics, no money/stock creation, no unsafe retirement, no mirror edit and no M5+ scope creep.