# RESUME — ISS-2026-9105 (production partial-issue + over-issue approval) — ✅ COMPLETE

**Status:** All 4 WPs done, reviewed, tested. On `hazemdev2` (both repos). NOT merged to main / NOT shipped — awaiting owner `/fullpush`.
**Date completed:** 2026-07-16.

## What shipped
Fix for the ISS-9105 bug (an order completed with un-issued materials → no way to issue the rest) + the client-requested over-issue approval:

| WP | Capability | Commits |
|----|-----------|---------|
| WP1 | Completing an order with un-issued materials now asks for explicit confirmation (confirm-gate, not a hard block). | BE `7f89b82e2` + test `51cd9e1ab` · FE `8efc19eca` + fix `f6c5d3a46` |
| WP2 | "Reopen for issue" action (Completed→InProcess) — fixes orders already stuck completed with un-issued materials (e.g. PRD-2026-00022), reverses no journals. | BE `2482d13a5` · FE `6ac1c78bc` |
| WP3 | Clearer material-issue action (tooltip) + clearer insufficient-stock message. | FE `b726b7458` |
| WP4 [FIN] | Over-issue approval cycle: issuing beyond planned (setting `production.over_issue_requires_approval`, default ON) is held pending a separate approval (`production.orders.approve_over_issue`) with a mandatory reason (waste/scrap/rework). Excess capitalises into FG value + surfaces via reporting cost variance — NO new GL code. Independent of the ISS-9103 warehouse-keeper approval. | BE `1e6472e3c` + fix `57f297342` · FE `882e5c0d7` |

## Verification
- Full relevant suite: **54 passed (331 assertions)**, 0 new failures vs baseline (29/0).
- Reviews: WP1 Codex (HIGH produced_qty race → fixed); WP2 [FIN] APPROVE (double-post proven impossible); WP4 architect design gate (GO-WITH-CHANGES, 6 must-dos) + [FIN] code review (2 HIGH → fixed: per-material allowance aggregation + keeper-path tests); final cross-WP review APPROVE.
- Migration `2026_07_16_000001_create_production_over_issue_approvals_table` ran on `moonui2_dev_be`. Setting + permissions seeded on dev.
- FE built + deployed to `/app` (moonui2 dev) for client testing.

## Key design facts (for future work)
- Over-issue is a GATE-ONLY mechanism (permits the existing IssueMaterials path to exceed planned) — no new accounting. CHECK (permit-or-422) before draft creation; CONSUME (used_quantity, per-material aggregate, lockForUpdate) inside applyEffects (exactly-once on both inline + keeper paths). Gated only when `$requireApprovalGate===true` → backflush never gated. OFF-path byte-for-byte.
- Reopen is a pure status flip; WIP→FG settlement posts only at CLOSE (from Completed), idempotency-keyed; reopen blocked from Closed → no double-post.

## Deferrals (recorded in LEDGER)
1. WP4 pre-existing consumed_quantity lost-update on duplicate same-material issue lines (predates 9105; separate Production bug to surface to owner).
2. WP2 Low: add reopen→re-complete→close single-settlement e2e test; direct StockBalance/Event assertions.
3. Final-review Low: `production.orders.reopen` depends only on `orders.view` (latent permission nuance).

## Next
Owner runs `/fullpush` to merge hazemdev2→main (both repos) + ship. Main session publishes the portal verification on ISS-2026-9105 (client tests on moonui2 dev /app).