# 37 — Adversarial Review of the Client-Workflow Addendum Set (md/30..36)

> Reviewed: `md/30` (requirements), `md/31` (coverage audit), `md/32` (ERP evidence),
> `md/33` (pharma domain), `md/34` (Cycle-1 design), `md/35` (Cycle-2 design),
> `md/36` (consolidated plan amendments) — against each other, against the client interview
> (verbatim summary), and against the published `md/20-mapping.md`, `md/22-contracts.md`,
> `md/23-roadmap.md`.
>
> Verdict up front: the addendum set covers the interview's spine well, but **md/34, md/35 and
> md/36 are NOT one design — they are three partially incompatible designs**, and md/36 (the
> "single consolidated delta") silently discards md/34's canonical naming and md/35's central
> entity. Several findings are blocking for the Phase-0 ratification gate.

---

## 1. Interview requirements with NO (or materially incomplete) coverage

Walking the interview line by line, the funnel (RFQ → draft BOM → preliminary cost → quote),
the trial cycle, the formal order, BOM finalization, planning/readiness, the deposit gate,
reservation, MO → issue → manufacture → FG receipt, order-pegged lineage, and stage screens are
all addressed somewhere in 30–36. The following are the holes:

| # | Interview line | Gap |
|---|---|---|
| U-1 | "the factory usually **purchases raw materials on behalf of the customer**" | Only the *gate* is designed. The **billing-back mechanics of on-behalf-procured materials are designed nowhere**: 31 C-06 / 36 Phase-4 add only a "billable-to-customer tag" on MRP POs, while 30 R-16 / 22 §4 bill the customer **conversion fee only** (DR Customer / CR Toll-service revenue). Who owns the RM bought on the customer's behalf (own stock? customer property on arrival?), whether material cost is passed through on the final invoice or consumed by the advance, and the JE for the pass-through are all unspecified in all 7 docs. The advance (sized as "% of own-procured material cost", 36 D-25) settles against an invoice that, per the only documented toll JE, contains no material line — the cash math does not close. |
| U-2 | "the customer may ALSO supply his own raw materials which remain HIS property" | Consignment *holding/issuing* is covered (D-15, M-10, tracking-only issue). **The intake document is not**: no Action, no `mfg_*` document, no `InventoryReceipt` path is defined anywhere for *receiving* customer free-issue material into the consignment warehouse. md/35 has only a screen button (`reserve-desk`: "Receive customer free-issue") and a permission (`production.case.consignment_receive`) with no rail behind them — see V-2. Likewise the **return / reconciliation of UNUSED customer material at order close** is uncovered (D-30/OQ-4 covers scrap only). |
| U-3 | "a test/sample batch is produced **for the customer to evaluate**" | The trial production run is fully designed, but the **physical hand-over of the trial sample to the customer** is not: no delivery document, no warehouse/ownership treatment of trial output (31 C-05's "trial/evaluation bucket, not sellable FG" never reappears in 34/35/36). The trial closes with a normal FG receipt and then the sample teleports to the customer. |
| U-4 | "issue materials … finish … receive into finished-goods warehouse" then bill | The **toll conversion-fee invoice creation rail is missing**: 35 row 11 ("final invoice posted") and 30 R-16 require Production to trigger a Sales service invoice, but no forward Sales Action exists for it — 36 §2.2 adds `UpsertQuotationPricing` and `ConvertQuotationToOrder` but **no `CreateInvoice`-type Action**, and direct controller/table use is forbidden (22 §0.1). B18 names the need; no addendum closes it. |
| U-5 | "dedicated SCREENS for **every production stage** (واجهات لكل مرحلة إنتاجية)" | All addenda interpret "stage" as *commercial case stages*; **in-production manufacturing stages remain a single `InProduction` stage** whose screens are the Phase-5 operator terminals. If the client meant per-manufacturing-stage screens (mixing/granulation/compression/packaging — plausible for pharma), nothing before Phase 5 serves him, and the interpretation was never logged as an open question (it is absent from OQ-1..OQ-8 and D-23..D-30). Additionally 36 ships only a "pipeline-board MVP" in Phase 2 and defers all per-stage workbenches to Phase 5 — 35's ten workspaces have no committed early phase in the consolidated plan. |
| U-6 | "customer MUST pay a DEPOSIT … **because** the factory purchases raw materials on behalf of the customer" | The causal rule (deposit gates the *purchasing*) is broken in md/35 — see C-5. The interview ties the deposit to procurement, not only to reservation/release. |

---

## 2. Contradictions between md/34, md/35, md/36 (and back into 30/31)

| # | Contradiction | Detail |
|---|---|---|
| C-1 | **Canonical table names reversed without notice** | md/34 opens with "Naming reconciliation (canonical, **supersedes** provisional names)": `mfg_cost_estimates` + `mfg_cost_estimate_versions`. md/35 §0.1 still uses `quotation_id FK mfg_quotations` and counts `mfg_quotations`/`mfg_quotation_costings` in its tally; md/36 M-01/M-02 (the *final consolidated sheet*) ratifies `mfg_quotations` + `mfg_quotation_costings` and never mentions 34's pair. Same two entities, two competing canonical names, with the "supersedes" arrow pointing both ways. Every FK, sequence key (`cost_estimate` vs `quotation`), permission slice (`production.estimates.*`) and event name downstream forks on this. |
| C-2 | **md/35's central entity is absent from md/36** | md/35 §0 spends a page ratifying `mfg_order_cases` as THE entity decision (14-stage case machine; "7 of 14 stages exist when no production order exists — columns would have no row to live on"; `mfg_order_stage_gates` **re-keyed to `case_id`**; advances keyed to case). md/36 contains **no `mfg_order_cases` at all**: M-09 keys stage gates back to `production_order_id` (nullable → `quotation_id`) and grafts 3 pre-states `{Quotation, Trial, AwaitingAdvance}` onto the ratified order machine — exactly the design md/35 explicitly rejected as "would corrupt the Phase-1 state machine". Mutually exclusive architectures, both published the same day. |
| C-3 | **Table-count math disagrees three ways** | md/34: Cycle-1 net-new = 2. md/35: +6 (24 → 30, includes `mfg_order_cases`). md/36: +5 (24 → 29, no case table). At least one of 35/36 is wrong by construction. |
| C-4 | **Deposit anchor & voucher reference diverge** | md/30 R-11: advance keyed `sales_order_id`/`production_order_id`, JE `source_type='production_order'`. md/35: advance keyed **`case_id`**, voucher `reference_type='mfg_order_case'`. md/36 M-06/M-08: keyed `sales_order_id`/`production_order_id`, voucher `reference_type='sales_order'`. md/32 itself had proposed `'sales_order'` *or* `'mfg_production_order'`. Three live answers to "what does the deposit hang off?" — the gate query (Σ vouchers ≥ required) cannot be written until one wins. |
| C-5 | **Deposit-gate vs purchasing sequence** | md/30 R-11 and md/31 R-07: NO purchasing-on-behalf until the advance is `Received/Waived` ("received and verified BEFORE materials are reserved/**purchased**"). md/35 row 5 raises `CreatePurchaseRequest` PRs for own shortages at **`PlanningChecked` — before `DepositGate`** (rows 6–7). md/36 gates only snapshot+reserve (§2.2 last row) and schedules the billable-PO tag in Phase 4 with no gate statement. The consolidated design lets the factory buy on the customer's behalf before the deposit the client said exists *precisely to fund that buying*. |
| C-6 | **Trial accounting: four new JE types vs "no new JE family"** | md/35 §1.1/§3 defines `trial_cost_policy {Bill, Absorb, CreditOnWin}` with four new entry_types (`production_trial_absorb/_defer/_apply/_writeoff`) and two new accounts (Deferred Trial Cost, R&D Expense). md/36 §2.3 states for the trial run: "**No new JE family** … changes only the final Sales-invoice line, never the production JEs", and D-23 ratifies only `{Customer, Absorbed}` (CreditOnWin dropped). But `Absorbed` *requires* at least the reclass JE md/35 specified — md/36's D-23 even says "(Absorbed ⇒ R&D expense JE reclass)" while §2.3 denies any new family two tables up. |
| C-7 | **Settlement entry_type name** | md/35: `production_advance_settlement`. md/36 §2.3: `production_advance_application`. Same JE (DR Customer Advances / CR AR), two names. |
| C-8 | **Three colliding D-23..D-30 schemes** | md/30 §6: D-23..D-30 = OQ-1..OQ-8 in order. md/31 §4: D-23 = pre-sales scope, D-24 = trial modeling, D-25 = deposit enforcement, … D-29 = reuse. md/36 §4: D-23 = trial cost policy, D-25 = deposit %, D-30 = scrap ownership. md/34 cites "D-23 (build the funnel)" — md/31's meaning, which under md/36's final table denotes *trial cost policy*. Any board member ratifying "D-23" is signing three different decisions depending on which doc they read. (Same disease at R-level: md/30 defines R-01..R-18, md/31 redefines R-01..R-09 differently — R-07 is "trial evaluation" in 30 and "deposit gate" in 31; 35/36 cite both schemes.) |
| C-9 | **Phase placement & a false prerequisite claim** | md/30 §6: "Phase 1.5 … after Phase 1 *and* Phase 2". md/34 §8: Phase 1.5 needs only "Phase 1 master data (BOM lifecycle, **WC rates**)" — **factually wrong against md/23**: `labor_cost_rate`/`machine_cost_rate`/`cost_driver` land in **Phase 2** (23-roadmap L89). md/35 §7: "Phase 1.5 exactly as scheduled in md/30 §6". md/36 renames it Phase 2.5 and gives the correct rationale (rates arrive in Phase 2). 34/35 therefore schedule the costing funnel before its labor/OH inputs exist. |
| C-10 | **Draft-BOM trial carve-out vs the "never" rule** | md/30 R-02 and md/34 invariant #2 (both citing ratified md/20 row 2): an `Engineering/Draft` BOM can **never** be snapshotted into a production order. md/35 row 2 introduces a carve-out: Trial orders MAY snapshot a Draft BOM (`production.trial_allow_draft_bom`). md/36 is silent — yet its own M-03/M-04 sequence (trial runs *before* BOM finalization at M-09's `Trial` pre-state) is **impossible** under the un-amended rule. Either the carve-out is ratified (amending md/20 row 2, which 35's own preamble claims it never does) or the trial flow deadlocks. |
| C-11 | **Disjoint event vocabularies for the same milestones** | md/34: `CostEstimateRequested, DraftBomReady, EstimateQuoted, EstimateWon, EstimateLost`. md/35: 12 `Case*` events (`CaseTrialDecided`, `CaseDepositSatisfied`, …). md/36 §2.1: 5 *different* events (`QuotationCosted, TrialEvaluated, CustomerAdvanceReceived, StageAdvanced, GoodsReceiptQualityResolved`). Zero overlap between the consolidated sheet and either design doc — e.g. quote-priced is `EstimateQuoted` (34) vs `QuotationCosted` (36); deposit-satisfied is `CaseDepositSatisfied` (35) vs `CustomerAdvanceReceived` (36). |
| C-12 | **Permission slice taxonomy** | md/34: `production.estimates.*`; md/35: `production.case.*` (waive = `production.case.deposit_waive`); md/36 M-17: `production.rnd.bom.*`, `production.trial.*`, waive = `production.advance.waive`. Same actions, three namespaces — the Phase-0 seeder cannot be written from these docs. |
| C-13 | Minor: md/32 §3 offers `WarehouseType::Consignment` as option 1, ignoring that D-15 already ratified the `warehouses.is_consignment` flag (md/20 row 17, md/22 §1); md/33 and md/36 M-10 correctly follow D-15. Also md/32 §7's proposed chain has `MaterialsReserved → Released` while md/20 row 13 ratifies reservation as a *side-effect of* Release (md/30 R-12/R-13 has the same circular ordering: R-12's actor is `ReleaseProductionOrder`, yet R-13 "Release" is triggered by "reservation done"). |

---

## 3. Violations of the ratified rules

Rails: EXTEND `Modules/Production` · `production.*` permissions · `mfg_*` tables · GL **only** via
`CreateJournalEntry` (22 §5.4) · stock **only** via `ApproveIssue`/`ApproveReceipt` documents
(22 §1 Inventory row) · no module reads `mfg_*` (22 §5.2). Module identity, prefixes and the
no-reads law are respected everywhere (36 §2 even adds push-Actions to keep Sales out of `mfg_*` —
good). The breaches:

| # | Violation | Detail |
|---|---|---|
| V-1 | **New GL path bypassing `CreateJournalEntry`** | The deposit posts its DR Cash / CR Customer-Advances **inside `ApproveReceiptVoucher`** (35 §3; 36 M-08 + §2.2 #16), i.e. a Production-initiated GL posting that does not ride `CreateJournalEntry`. 22 §5.4 says "GL exclusively via `CreateJournalEntry`" and 36's preamble claims "no dependency rule is re-opened" — the law needed an explicit amendment and didn't get one. Worse, 36 lists BOTH #16 (voucher posts the advance) and #17 (`CreateJournalEntry` with `entry_type='production_customer_advance'` "with the voucher") — as written, the advance is posted **twice**, or the entry_type is stamped on a JE the voucher engine creates (capability unverified in md/32). |
| V-2 | **Stock movement without an Approve* document** | Customer free-issue intake into the consignment warehouse (U-2) has no `InventoryReceipt`/`ApproveReceipt` (or mfg doc) anywhere — only a screen button and a permission in md/35. Any implementation would have to touch balances directly, which 22 §1 forbids ("increaseStock/decreaseStock are NEVER called directly"). Similarly 36 §2.1's `GoodsReceiptQualityResolved` consumer performs a "Quarantine→FG warehouse transfer (Inventory transfer rail)" — a rail that appears in no ratified contract (22 §3 lists only Issue/Receipt/StockService). |
| V-3 | **Ratified order state machine quietly widened** | 36 M-09 adds pre-states `{Quotation, Trial, AwaitingAdvance}` to "the ratified order machine" while §3 declares "the order state machine … explicitly unchanged". If the pre-states live on `production_orders.status`, the Phase-1 enum/migration (20 row 13, 23 Phase 1) is re-opened; if not, they have no table — md/35 solved exactly this with `mfg_order_cases`, which md/36 dropped (C-2). The consolidated sheet is self-contradictory on its own "nothing re-opened" guarantee. |
| V-4 | **Controller called as a forward entry point** | md/34 §6 step 1 routes conversion through `SalesOrderController::convertFromQuotation()` — Production may only call foreign **Actions** (22 §0.1). md/36 #19 fixes this by extracting `Modules\Sales\Actions\ConvertQuotationToOrder`, but md/34 (the binding Cycle-1 design) still names the controller. |
| V-5 | **Draft-BOM snapshot guard** | md/35's `production.trial_allow_draft_bom` carve-out breaches the ratified md/20 row 2 guard (see C-10) without a decision row; absent the carve-out, the ratified flow itself is unimplementable for trials. Needs an explicit D-row either way. |
| V-6 | (Minor) The toll fee invoice (U-4) currently has no compliant creation path — implementing 35 row 11 as written would force either a controller call or direct Sales table writes, both illegal under 22 §0/§5. |

---

## 4. Reuse misses (md/32 proved it exists; designed net-new anyway)

| # | Miss | Detail |
|---|---|---|
| RM-1 | **`mfg_quotations` duplicates the `SalesQuotation` funnel** | md/32 §1 proved the full lifecycle exists (`Draft→Sent→Accepted→Rejected/Expired→Converted` + `duplicate` + `convertFromQuotation`) and §6 explicitly recommended "Reuse `SalesQuotation` as the RFQ record — cheapest". md/36 M-01 nevertheless ratifies a NEW `mfg_quotations` with its own parallel status machine `{Requested, InRnD, InCosting, Quoted, Converted, Expired, Rejected}` — `Quoted/Converted/Expired/Rejected` mirror `QuotationStatus` 1:1, creating a dual-state-machine sync problem md/34 had reduced (its estimate header carries only `{Draft, Estimated, Quoted, Won, Lost}` with the commercial states delegated to Sales). The mfg-side costing data needs a home; the duplicated commercial funnel states do not. |
| RM-2 | **Bespoke `mfg_order_stage_gates` beside the Core approval engine** | md/32 §5 proved `ApprovalWorkflow`/`ApprovalLog` exist and recommended reusing them "instead of building bespoke approval logic". md/36 does BOTH: M-13 registers `ApprovalModule::Production` + 4 document types, AND M-09 builds the bespoke gate/audit table. Two overlapping sign-off/audit mechanisms for the same transitions, with no rule on which gates use which. |
| RM-3 | **`mfg_trial_batches` as a separate entity** | md/32 §4's evidence-based recommendation: "model the trial as a `ProductionOrder` with `kind=trial` + `sales_order_id`, so the trial inherits all costing/stock plumbing" — i.e. *no new entity*. 30/35/36 add the `order_type=Trial` enum (good) **and** a separate `mfg_trial_batches` table whose payload (`trial_quantity`, `actual_unit_cost`, `result`, `evaluated_at`) is one quantity column, one rolled-up cost the order already carries, and an evaluation verdict that RM-2's approval engine could record. Defensible, but never argued against the md/32 recommendation. |
| RM-4 | **md/30's advance design missed `ReceiptVoucher`** | md/30 R-11/§4 books the advance via bare `CreateJournalEntry` and its `mfg_customer_advances` has only `journal_entry_id` — unaware of the `ReceiptVoucher`+`ApproveReceiptVoucher` cash-in rail md/32 §2 proved exists. 35/36 corrected (added `receipt_voucher_id`), but md/30 §4 was never amended and now contradicts the consolidated sheet it feeds. |
| RM-5 | md/34 reuses the conversion *logic* but not the house **extraction recipe** (controller→Action, the `CreatePurchaseRequest` pattern) — see V-4; 36 #19 supplies the fix 34 should have specified. |

---

## 5. What is solid

- md/32 is the strongest doc: every claim file-and-line cited, verdicts honest, and its
  ReceiptVoucher/2104, `reserved_quantity`-dormant, CRM-is-ticketing and CMMS-is-not-R&D findings
  prevented four bad designs.
- md/33 correctly reclassifies severities without inventing engines, and its P2 default-flip +
  P3 pull-forward both landed in md/36 (M-14, Phase 6 note).
- The deposit-as-liability treatment (never `SalesPayment`, child of 2104, settlement JE at
  invoicing, refund per OQ-6) is consistently right across 32/35/36.
- The no-`mfg_*`-reads law is actively protected (36's `UpsertQuotationPricing` push, HRM-style).
- Trial = real costed order on the unchanged Release→Issue→Confirm→Receive rail is the right call
  and consistent in 30/32/35/36 (modeling mechanism aside, C-8/D-24 resolved it explicitly).

## 6. Required actions before the Phase-0 ratification gate

1. **Pick one naming + entity model** (C-1, C-2, C-3): either md/34+md/35 (estimates + cases) or
   md/36 (quotations + pre-states) — then regenerate the loser docs. Recommendation: 34's
   estimate pair (avoids RM-1's dual funnel) + 35's case umbrella (avoids V-3), and rewrite 36.
2. **Renumber decisions and requirements once** (C-8): single authoritative D-23..D-3x and a
   single R-numbering; fix md/34's citations.
3. **Resolve the deposit posting** (V-1, C-4, C-7): one anchor, one reference_type, one
   entry_type, and an explicit law amendment for the voucher rail (or wrap it so the JE still
   flows through `CreateJournalEntry`).
4. **Move PR-raising behind the deposit gate** or get the owner's explicit waiver (C-5, U-6).
5. **Design the four missing documents**: consignment free-issue receipt (U-2/V-2), trial-sample
   hand-over (U-3), toll-fee invoice Action (U-4/V-6), material pass-through billing (U-1).
6. **Ratify the trial Draft-BOM carve-out** as a D-row (C-10/V-5).
7. **Ask the client what مرحلة إنتاجية means** (U-5) and log it as OQ-9.