Odoo-Modules/fusion_plating/docs/superpowers/specs/2026-04-25-fp-native-job-model-design.md

# Native Plating Job Model — Design

**Date:** 2026-04-25
**Module scope:** All modules in `fusion_plating/` that touch `mrp.production` or
`mrp.workorder` (~12 modules). Net effect: replace Odoo MRP integration with a
native plating job model.
**Status:** Design approved 2026-04-25. All §10 decisions locked per recommendations
(see §10 footer). Implementation plan written: `docs/superpowers/plans/2026-04-25-fp-native-job-model.md`.
**Owner:** Nexa Systems
**Predecessor:** entech is currently in production on the MRP-bridged model
(`fusion_plating_bridge_mrp`). This spec replaces that model.

---

## 1. Why we're doing this

Plating is **not assembly**. Odoo MRP is built around BoM consumption, multi-level
assembly, and material-driven scheduling. Plating is process: parts in → baths →
parts out. The "BoM" is bath chemistry (already its own model), not stock items.
Steelhead, ProShop, PROPLATE, JobBOSS — none of them model plating as MRP. They
all use a job/router model because plating IS different.

We bridged into Odoo MRP three months ago to get free machinery (kanban, work-centre
cost, MRP menus). The cost has been:

- Operators see **N work orders for one job** (8 WOs for a typical recipe).
- Three different views to understand one job (MO form, WO form, Plant Overview).
- 5,000+ LOC in `fusion_plating_bridge_mrp` whose only job is keeping MRP and our
  plating models in sync.
- Recipe overrides, work-centre mapping fallbacks, WO state syncing — most of our
  hardest bugs come from this sync.
- Future features (operator mobile app, AI step suggestions, IoT auto-actions) get
  more expensive every time we add coupling.

**With the user's "I don't care about MRP dependencies" call, the trade-off flips.**
Native model is simpler today, simpler tomorrow, and the data model finally matches
the domain.

## 2. Goal

Replace `mrp.production` and `mrp.workorder` (in the plating context) with a
native job model:

- **`fp.job`** — one record per plating job. Replaces `mrp.production`.
- **`fp.job.step`** — one record per operation within the job. Replaces `mrp.workorder`.
- The recipe template (`fusion.plating.process.node`) is **unchanged** — it's
  already domain-correct. `fp.job.step` instantiates from it via `recipe_node_id`.

Operator UX target: scan a sticker → land on the job page → see the process tree →
tap an operation → start/finish/hold. **One screen, one mental model.**

Manager UX target: list of jobs (kanban or tree), drill into a job, see the same
process tree with cost/time aggregates.

## 3. In scope

1. **New models:** `fp.job`, `fp.job.step`. Field schema in §4.
2. **SO → job hook:** `sale.order.action_confirm()` creates `fp.job` directly
   (replaces the current SO → MO bridge in `fusion_plating_bridge_mrp/models/sale_order.py`).
3. **Recipe → steps generator:** `fp.job._generate_steps_from_recipe()` walks the
   recipe tree and creates `fp.job.step` rows (replaces `_generate_workorders_from_recipe`).
4. **Refactor 12 modules** to use `fp.job` / `fp.job.step` instead of
   `mrp.production` / `mrp.workorder`. Module-by-module plan in §6.
5. **Migrate live data** from entech: every `mrp.production` row becomes an
   `fp.job` row; every `mrp.workorder` row becomes an `fp.job.step`. Migration
   spec in §7.
6. **New views:** Job form (with embedded process tree), job kanban, step form
   (manager-only), redesigned tablet station and plant overview.
7. **Reports** rewritten against new model: WO sticker, job traveller, WO margin,
   bill of lading, packing slip.
8. **Cert generation, notifications, deliveries, invoicing, batches, holds** —
   all rebound to `fp.job` / `fp.job.step`.
9. **Drop** `sale_mrp` and `mrp` dependencies from the `fusion_plating_*` chain
   except where genuinely needed (TBD per §10).

## 4. Out of scope

- Recipe template model (`fusion.plating.process.node`) stays as-is. No schema
  changes, no migration needed for it.
- The customer portal (`fusion_plating_portal`) UI — only its model link
  (`x_fc_production_id` → `x_fc_job_id`).
- Bath chemistry model (`fusion.plating.bath.log`) and IoT data ingestion — they
  link to baths/tanks, not to MOs/WOs.
- KPI definitions (`fusion.plating.kpi`) — only the rollup queries.
- Customer-facing terminology — operators still say "WO #00033". The label format
  is preserved; only the underlying model changes.
- Removing `mrp` module entirely from Odoo. We just stop depending on it from
  our modules. If managers still want the standard Manufacturing menu for any
  reason, they can — but our flow doesn't use it.

---

## 5. Data Model

### 5.1 `fp.job`

Replaces `mrp.production` for plating jobs. One record per shop-floor job.

**Module ownership:** `fp.job` lives in `fusion_plating` core. Cross-module fields
(referencing models from `fusion_plating_configurator`, `_portal`, `_logistics`,
`_quality`, `_bridge_mrp`) **cannot** live in core without inverting the dependency
graph. Each owning module extends `fp.job` via `_inherit` to add its field. The
Phase 2 module `fusion_plating_jobs` becomes the umbrella that pulls all the
extensions together. Ownership is called out in the **Module** column below.

| Field | Type | Module | Notes |
|---|---|---|---|
| `name` | Char | core | Sequence: `WH/JOB/00033`. The legacy "WH/MO/00033" labels stay only on migrated records (see §7). |
| `state` | Selection | core | `draft`, `confirmed`, `in_progress`, `done`, `cancelled`, `on_hold` |
| `partner_id` | Many2one(res.partner) | core | Customer; copied from SO |
| `product_id` | Many2one(product.product) | core | Reference part product (for inventory only) |
| `qty` | Float | core | Quantity to plate |
| `qty_done` | Float | core | Quantity completed |
| `qty_scrapped` | Float | core | Quantity scrapped (rolled up from holds) |
| `date_deadline` | Datetime | core | Promised completion date |
| `date_planned_start` | Datetime | core | Planned start |
| `date_started` | Datetime | core | Actual start (first step start) |
| `date_finished` | Datetime | core | Actual completion |
| `origin` | Char | core | SO name for traceability |
| `sale_order_id` | Many2one(sale.order) | core | Source SO (sale_management is in core depends) |
| `sale_order_line_ids` | Many2many(sale.order.line) | core | Lines that fed this job (group_tag collapse) |
| `recipe_id` | Many2one(fusion.plating.process.node) | core | The recipe template used |
| `step_ids` | One2many(fp.job.step, job_id) | core | The operations |
| `step_count` | Integer | core | Computed |
| `step_done_count` | Integer | core | Computed |
| `step_progress_pct` | Float | core | Computed: `step_done_count / step_count * 100` |
| `current_step_id` | Many2one(fp.job.step) | core | The operation currently in progress (or next ready) |
| `facility_id` | Many2one(fusion.plating.facility) | core | Hard gate at confirm |
| `manager_id` | Many2one(res.users) | core | Plating manager |
| `priority` | Selection | core | `low`, `normal`, `high`, `rush` (operator-relevant ordering) |
| `invoice_ids` | Many2many(account.move) | core | Linked invoices (account is reachable via sale_management → sale → account) |
| `quoted_revenue` | Monetary | core | From SO |
| `actual_cost` | Monetary | core | Computed from steps + consumables |
| `margin` | Monetary | core | Computed |
| `margin_pct` | Float | core | Computed |
| `start_at_node_id` | Many2one(fusion.plating.process.node) | core | Rework: start at this recipe node |
| `current_location` | Char | core | Computed: "Queued: Bath 3" / "In progress: Oven A" / "Ready to ship" |
| `mail.thread, mail.activity.mixin` | Inherits | core | Chatter |
| `part_catalog_id` | Many2one(fp.part.catalog) | **`fusion_plating_configurator`** (`_inherit = 'fp.job'`) | The actual part being plated; primary identifier |
| `coating_config_id` | Many2one(fp.coating.config) | **`fusion_plating_configurator`** | The coating spec |
| `customer_spec_id` | Many2one(fusion.plating.customer.spec) | **`fusion_plating_quality`** | Optional spec |
| `portal_job_id` | Many2one(fusion.plating.portal.job) | **`fusion_plating_portal`** | Customer portal binding |
| `delivery_id` | Many2one(fusion.plating.delivery) | **`fusion_plating_logistics`** | The shipment |
| `qc_check_id` | Many2one(fusion.plating.quality.check) | **`fusion_plating_jobs`** (Phase 2) | Active QC check; model lives in current bridge_mrp, will move to jobs module |
| `certificate_ids` | One2many(fp.certificate, job_id) | **`fusion_plating_certificates`** | Certs generated |
| `batch_ids` | One2many(fp.batch, job_id) | **`fusion_plating_batch`** | Batches that ran through |
| `quality_hold_ids` | One2many(fp.quality.hold, job_id) | **`fusion_plating_quality`** | Holds raised |
| `consumption_ids` | One2many(fp.job.consumption, job_id) | **`fusion_plating_jobs`** (Phase 2) | Consumables |
| `override_ids` | One2many(fp.job.node.override, job_id) | **`fusion_plating_jobs`** (Phase 2) | Per-job opt-in/out |

**State machine:**
```
draft → confirmed → in_progress → done
            ↓                       ↑
        cancelled            (can revert to confirmed if rework)
            
on_hold can be entered from confirmed/in_progress
```

### 5.2 `fp.job.step`

Replaces `mrp.workorder`. One record per operation node from the recipe.

| Field | Type | Notes |
|---|---|---|
| `name` | Char | Operation name (from recipe node) |
| `job_id` | Many2one(fp.job, ondelete=cascade) | Parent job |
| `sequence` | Integer | Order (10, 20, 30...) |
| `recipe_node_id` | Many2one(fusion.plating.process.node) | Source recipe operation |
| `state` | Selection | `pending`, `ready`, `in_progress`, `paused`, `done`, `skipped`, `cancelled` |
| `kind` | Selection | `wet`, `bake`, `mask`, `rack`, `inspect`, `other` (computed from equipment/name; today on WO as `x_fc_kind`) |
| `work_centre_id` | Many2one(fp.work.centre) | New native model — see §5.3 |
| `bath_id, tank_id, rack_id, oven_id` | Many2one | Equipment — same as today |
| `masking_material_id` | Many2one | Mask kind |
| `assigned_user_id` | Many2one(res.users) | Operator assignment |
| `started_by_user_id` | Many2one(res.users) | Audit |
| `finished_by_user_id` | Many2one(res.users) | Audit |
| `signoff_user_id` | Many2one(res.users) | Audit (sign-off gates) |
| `date_started` | Datetime | First start (timer) |
| `date_finished` | Datetime | Last finish |
| `duration_expected` | Float | Minutes |
| `duration_actual` | Float | Minutes (sum of intervals) |
| `time_log_ids` | One2many(fp.job.step.timelog) | Start/stop intervals — gives us the granularity Odoo had |
| `instructions` | Html | Step-level instructions (formatted from child `step` nodes of the recipe) |
| `thickness_target` | Float | For plating WOs |
| `thickness_uom` | Selection | µm/mil/in |
| `dwell_time_minutes` | Float | Recipe-spec'd dwell |
| `bake_setpoint_temp` | Float | Bake WOs only |
| `bake_actual_duration` | Float | Bake WOs only |
| `bake_chart_recorder_ref` | Char | Nadcap audit |
| `requires_signoff` | Boolean | Related from recipe_node_id |
| `auto_complete` | Boolean | Related from recipe_node_id |
| `is_manual` | Boolean | Related from recipe_node_id |
| `customer_visible` | Boolean | Related from recipe_node_id |
| `contract_review_user_ids` | Many2many(res.users) | For contract review approver gate |
| `work_role_id` | Many2one(fp.work.role) | Required role for assignee |
| `cost_per_hour` | Monetary | From work centre (or operator) |
| `cost_total` | Monetary | Computed: duration × rate |
| `quality_hold_ids` | One2many(fp.quality.hold, step_id) | Holds raised at this step |
| `is_release_ready` | Boolean | Computed: required fields filled per kind |

**State machine:**
```
pending → ready → in_progress → done
            ↓         ↓ ↑
        skipped     paused
                       ↓
                   cancelled
```
- `pending` = step exists but earlier siblings not done
- `ready` = predecessors done (or first step of job)
- `in_progress` = operator started timer
- `paused` = operator stopped timer without finishing (intentional break, end of shift)
- `done` = operator finished + sign-off (if required) recorded
- `skipped` = opt-in step that wasn't activated for this job, OR start-at-node skipped this step
- `cancelled` = job cancelled or rework removed this step

### 5.3 `fp.work.centre` (new model)

We replace `mrp.workcenter` with our own model since work centres for plating are
domain-specific (a tank line, a bake oven, a rack station — not assembly cells).

| Field | Type | Notes |
|---|---|---|
| `name` | Char | "Bath Line 1", "Oven A", "Rack Station" |
| `code` | Char | Short code |
| `facility_id` | Many2one(fp.facility) | Which facility |
| `kind` | Selection | `wet_line`, `bake`, `mask`, `rack`, `inspect`, `other` |
| `cost_per_hour` | Monetary | For margin calculations |
| `default_bath_id, default_tank_id` | Many2one(`fusion.plating.bath`/`.tank`) | Single-line shop convenience |
| `default_oven_id` | Many2one(`fusion.plating.bake.oven`) | **Deferred to `fusion_plating_jobs` bridge module via `_inherit`** — `bake.oven` is defined in `fusion_plating_shopfloor` which `fusion_plating` core cannot depend on. Bridge module *can* depend on shopfloor and adds this field there. |
| `active` | Boolean | |

This replaces `x_fc_mrp_workcenter_id` mapping that the recipe operations have today.

### 5.4 `fp.job.step.timelog`

Granular start/stop tracking. Each timer pause creates a record.

| Field | Type | Notes |
|---|---|---|
| `step_id` | Many2one(fp.job.step) | |
| `user_id` | Many2one(res.users) | |
| `date_started` | Datetime | |
| `date_finished` | Datetime | NULL while running |
| `duration_minutes` | Float | Computed |

### 5.5 What stays unchanged

- `fusion.plating.process.node` (recipe template) — unchanged
- `fusion.plating.process.node.input` (operator inputs) — unchanged
- `fp.batch`, `fp.certificate`, `fp.thickness.reading` — only their backlink fields rename
- `fp.portal.job` — only its `x_fc_production_id` field renames to `job_id`
- `fp.delivery` — only its job-back-reference rebinds
- `fp.quality.hold`, `fp.ncr`, `fp.capa` — only backlinks rebind
- `fp.notification.template`, `fp.notification.log` — trigger event names update
- IoT (`fusion_plating_iot`), bath chemistry (`fusion.plating.bath.log`),
  KPIs (`fusion.plating.kpi`) — none touch jobs/steps directly, no changes

---

## 6. Module-by-module refactor plan

Listed in dependency order — refactor can/should happen along this gradient.

### 6.1 `fusion_plating` (core)
**Effort: 3 days**

- Define `fp.job`, `fp.job.step`, `fp.job.step.timelog`, `fp.work.centre` models.
- Sequences (`ir.sequence` records for `fp.job`, `fp.job.step`).
- Security (groups already exist: Operator/Supervisor/Manager/Admin; ACLs added).
- Move `fusion.plating.job.node.override` from `bridge_mrp` into core, rebind to `fp.job`.

### 6.2 `fusion_plating_bridge_mrp` → `fusion_plating_jobs` (rename + gut)
**Effort: 5 days**

The current bridge module becomes the home of SO→job hooks, recipe→steps generator,
and computed rollups. Most of its weight (the WO sync logic) goes away.

- Rename module dir to `fusion_plating_jobs`.
- Migrate `_fp_auto_create_mo` → `_fp_auto_create_job` on `sale.order`.
- Migrate `_generate_workorders_from_recipe` → `fp.job._generate_steps_from_recipe`.
  Simpler: no MRP work-centre mapping fallback, no `mrp.workorder.create` quirks.
- Move all `x_fc_*` fields that currently sit on `mrp.production` to `fp.job` natively.
- Move all `x_fc_*` fields on `mrp.workorder` to `fp.job.step` natively.
- Drop `sale_mrp` from `__manifest__.py` depends. Drop `mrp` if confirmed (§10 Q3).
- Quality check, racking inspection, cert generator, delivery hooks — all rebind.

### 6.3 `fusion_plating_batch`
**Effort: 0.5 day**

- `workorder_id` → `step_id` (Many2one fp.job.step)
- `production_id` (related) → `job_id` (related from step_id.job_id)
- Views and access rules trivial rename.

### 6.4 `fusion_plating_quality`
**Effort: 1 day**

- `fp.quality.hold` adds `job_id`, `step_id` fields (replaces production_id, workorder_id from bridge).
- NCR and CAPA reference holds via current relations — no schema change.
- Views: hold form refers to job/step instead of MO/WO.

### 6.5 `fusion_plating_certificates`
**Effort: 0.5 day**

- `fp.certificate.production_id` → `fp.certificate.job_id`
- `fp.thickness.reading.production_id` → `fp.thickness.reading.job_id`
- Cert auto-creation hook moves from MO done to `fp.job.button_mark_done`.

### 6.6 `fusion_plating_invoicing`
**Effort: 0.5 day**

- Invoice → portal job linkage stays; just walks via job instead of MO.
- Account hold gating (on SO confirm, invoice post, delivery) stays — same partner-level field.

### 6.7 `fusion_plating_logistics`
**Effort: 0.5 day**

- `fp.delivery.job_ref` resolution rebinds: from MO.name to fp.job.name (same string format if we use `WH/JOB/00033`).
- Delivery auto-creation hook on `fp.job.button_mark_done`.

### 6.8 `fusion_plating_portal`
**Effort: 0.5 day**

- `fp.portal.job.x_fc_production_id` → `job_id` (Many2one fp.job).
- Portal templates: same — they read MO.name; if we keep `WH/JOB/...` format, no UI change.
- Auto-create on `fp.job.action_confirm()`.

### 6.9 `fusion_plating_configurator`
**Effort: 1 day**

- Configurator wizard already creates SO lines; no direct MO touch.
- The `action_view_mrp_production` button on SO becomes `action_view_jobs`.
- Recipe assignment paths stay (part catalog → coating config → job).

### 6.10 `fusion_plating_notifications`
**Effort: 1 day**

- Trigger event names: `mo_confirmed` → `job_confirmed`, `mo_complete` → `job_complete`, `wo_started` → `step_started`, etc.
- Existing customer-facing template content unchanged (uses partner/SO/cert vars).
- Hook from `fp.job.button_mark_done` and `fp.job.step.button_finish`.

### 6.11 `fusion_plating_shopfloor`
**Effort: 6 days** ← biggest single chunk

This is where operators live. Full rewrite of the operator UI.

- **Plant Overview** (kanban): one card per `fp.job.step` in `ready` or `in_progress`,
  grouped by `fp.work.centre`. Drag-drop changes work centre on the step.
- **Tablet Station**: scan job sticker → land on job page. Job page shows:
  process tree (the IS-the-job tree) + ready/in-progress steps highlighted +
  start/finish/hold/sign-off buttons.
- **Process Tree client action**: now the *primary* job view (not a separate
  drill-down). Renders `fp.job.step` records as cards with state colours,
  hierarchy from `recipe_node_id.parent_id` chain.
- **Manager Dashboard**: list of jobs with progress %, current step location,
  manager actions (assign worker, take over, raise hold).
- All RPC routes (`/fp/shopfloor/start_wo` etc.) renamed and rebound.

### 6.12 `fusion_plating_reports`
**Effort: 3 days**

- WO Box Sticker — already mostly model-agnostic; rebind the inner template's
  `_mo` resolution. Print URL `/fp/job/<id>` instead of `/fp/wo/<id>`.
- Job Traveller — loops over `fp.job.step_ids` instead of `mrp.production.workorder_ids`.
- WO Margin Report — same rollup, different model.
- BoL, Packing Slip, Invoice — all read from sale_order anyway, only the
  cross-ref to job needs updating.
- Hide-default-reports XML: drop the `mrp.production` / `mrp.workorder` hides
  (they're no longer in our app).

### 6.13 `fusion_plating_kpi`
**Effort: 0.5 day**

- KPI rollup queries: `mrp.production` → `fp.job`, `mrp.workorder` → `fp.job.step`.
- KPI definitions stay; SQL/ORM domain rewrites.

### 6.14 `fusion_plating_receiving`
**Effort: 0.5 day**

- Soft gate hook on `fp.job.action_confirm` (currently on MO confirm).
- `fp.racking.inspection.production_id` → `job_id`.

### 6.15 Other modules with MRP touchpoints

- `fusion_plating_aerospace`, `fusion_plating_nuclear`, `fusion_plating_cgp`,
  `fusion_plating_safety`: minimal — none reference MO/WO directly per the audit.
  Verify in §7 testing.
- `fusion_plating_compliance` and bridge_quality, bridge_documents,
  bridge_maintenance, bridge_sign: light touch — rebind any MO/WO refs to job/step.

### 6.16 Data scripts / tests
**Effort: 2 days**

- 10+ scripts in `scripts/` and `docs/superpowers/tests/` query `mrp.production`/`mrp.workorder`. Rewrite to query `fp.job`/`fp.job.step`.

### Total effort estimate

| Phase | Days |
|---|---|
| Core models + sequences + security | 3 |
| `fusion_plating_jobs` (gut + rebuild) | 5 |
| Modules 6.3–6.10 (8 modules, light) | 5.5 |
| Configurator | 1 |
| Notifications | 1 |
| Shopfloor (full rewrite) | 6 |
| Reports | 3 |
| KPI + Receiving + other | 1.5 |
| Scripts + tests rewrite | 2 |
| Migration script (§7) | 3 |
| Test on entech-clone | 5 |
| Cutover + burn-in | 3 |
| **Total** | **39 working days ≈ 8 weeks** |

Calendar time with iteration: **9–11 weeks**.

---

## 7. Migration strategy

entech is in production. Migration must be reversible until we're confident, and
must preserve every link operators / accounting depend on.

### 7.1 Approach: Big-bang with scripted migration + 2-week shadow period

1. Build new models alongside existing ones in a feature branch. Both coexist
   in the codebase.
2. Run migration script on a **clone** of entech (not entech itself). Validate
   E2E: every report renders, every cert PDF reproduces, every link resolves.
3. Cutover weekend on entech: ~4 hour window. Steps in §7.4.
4. **Shadow period (weeks 1–2 post-cutover):** keep `mrp.production` /
   `mrp.workorder` tables as read-only snapshots. If anything goes wrong, we can
   revert to the snapshot via a reverse migration script.
5. After 2 weeks of stable operation, drop the MRP tables.

### 7.2 Migration script

Location: `fusion_plating_jobs/migrations/19.0.8.0.0/post-migration.py`

For each `mrp.production` row:
1. Create `fp.job` with same id (use `fp_job_id_seq` aligned to MRP id space, or
   keep separate sequence and store the legacy id in `legacy_mrp_production_id` for
   audit).
2. Copy fields: name, partner_id, product_id, product_qty → qty, dates, origin,
   state (mapping in §7.3), all `x_fc_*` extension fields.
3. For each child `mrp.workorder`, create `fp.job.step` with all `x_fc_*` fields.
4. Migrate `mrp.workorder.time_ids` (if present) to `fp.job.step.timelog`.
5. Rebind every cross-reference: cert.production_id, batch.production_id,
   delivery.job_ref, portal_job.x_fc_production_id, etc.
6. Preserve chatter: copy `mail.message` records from MO/WO to corresponding
   job/step (Odoo's `res_id` + `model` rebinding).
7. Audit log: write `fp_migration.log` with row counts, mismatches, warnings.

### 7.3 State mapping

| MRP state | fp.job state |
|---|---|
| `draft` | `draft` |
| `confirmed` | `confirmed` |
| `progress` | `in_progress` |
| `to_close` | `in_progress` (will be `done` after final ops) |
| `done` | `done` |
| `cancel` | `cancelled` |

| MRP WO state | fp.job.step state |
|---|---|
| `pending` | `pending` |
| `waiting` | `pending` |
| `ready` | `ready` |
| `progress` | `in_progress` |
| `done` | `done` |
| `cancel` | `cancelled` |

### 7.4 Cutover plan (single weekend window)

**Friday 6pm:** Stop operators. Final MOs of the week wrapped up.
**Friday 8pm:** Backup full database. Tag as `pre_fp_job_migration`.
**Friday 9pm:** Deploy new module bundle to entech. Run migration script. Estimated 30 min.
**Friday 10pm:** Smoke test — open a recent job, print sticker, scan, render CoC,
generate margin report. If anything fails, restore from 8pm backup; abort.
**Saturday/Sunday:** Live shop is offline anyway (weekend). Time to fix anything
that surfaced.
**Monday 7am:** Operators come in. Manager + tech on site for the first 2 hours.
**Following 2 weeks:** Daily check-ins. Active monitoring of error logs. MRP
tables still present (read-only).

### 7.5 Rollback plan

If the cutover fails or unrecoverable issues surface within 7 days:
1. Stop operators.
2. Restore Friday 8pm DB backup.
3. Revert deploy to previous module bundle.
4. Reopen as previous-MRP system.

After 7 days, rollback becomes "forward fix only" — too much new shop activity to
restore.

### 7.6 Data preservation guarantees

- **Every** historical job remains queryable. Old MOs become old `fp.job` records.
- **Every** chatter message preserved (Odoo's `mail.message.res_id` rebinding).
- **Every** PDF attachment preserved (`ir.attachment.res_id` rebinding).
- **Every** cert, thickness reading, batch, hold preserved with intact links.
- **Audit-trail integrity for Nadcap / aerospace customers** is critical; the
  migration script must verify zero loss before commit. We'll add a pre-migration
  audit script that snapshots counts and a post-migration audit that re-validates.

---

## 8. Test strategy

### 8.1 Unit tests
- `fp.job` state machine transitions
- `fp.job.step` state machine transitions
- `_generate_steps_from_recipe` with: simple recipe, nested sub_processes,
  opt-in/out overrides, start-at-node rework, missing work-centre mapping
- Migration script: round-trip a snapshot of entech data through migrate, verify
  every row's fields match expectation

### 8.2 Integration tests (end-to-end on a fresh DB)
- Quote → SO → confirm → job created → recipe assigned → steps generated → start
  step → log time → finish step → all steps done → job done → portal job
  ready_to_ship → delivery created → CoC generated → invoice posted → portal job
  complete
- Quality hold raised mid-job → blocks finish → released → job continues
- Rework (start-at-node) job → only later steps generated
- Cancel a confirmed job → all steps cancelled → portal job cancelled → no cert

### 8.3 E2E on entech-clone
- Restore entech production DB to a staging container.
- Run migration script.
- Replay last 30 days of operator actions through the new UI.
- Run every report, every cert, every notification trigger.
- Diff against pre-migration snapshot: identify any data drift.

### 8.4 Performance baseline
- Plant Overview load time with 1000 active steps: target < 1.5s
- Job form open with 50-step recipe: target < 800ms
- Report rendering (CoC, traveller, sticker): target < 3s

---

## 9. Risk register

| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Migration script silently drops chatter on a record | Medium | Medium | Pre/post-migration audit scripts compare message counts |
| A module we forgot still references mrp.workorder, fails at runtime | Medium | Medium | CI grep in pre-deploy that fails on `mrp.workorder` / `mrp.production` references in our code |
| Cert PDF differs vs current (audit/Nadcap impact) | Low | High | Render 100 sample CoCs pre-migration, render same post-migration, byte-diff |
| Operators confused by new UI | High | Medium | Beta with 2 operators 1 week before cutover; live training Monday morning |
| Plant Overview slower than current | Medium | Low | Performance baseline test in §8.4; index `fp_job_step.state`, `work_centre_id` |
| Account hold gate breaks → invoices post that shouldn't | Low | High | Unit tests + integration test for held-customer invoice attempt |
| Rollback needed >7 days post-cutover | Low | High | Forward-fix only after day 7; treat the new model as canonical |
| `mrp` Odoo module updates break our coexistence | Low | Low | We're un-depending; if mrp updates, we don't care |
| Missed dependency causes module install failure | Medium | Low | Test install on fresh DB before cutover |

---

## 10. Open decisions (sign-off needed)

These need a yes/no from you before I write the implementation plan:

### Q1. Naming: `fp.job` vs `fp.work.order`?
Operators currently say "WO #00033". The label format is independent of the model
name — we can call the model `fp.job` and still print "WO #00033" on the sticker.

**Recommendation:** `fp.job`. Cleaner, doesn't pretend to be Odoo MRP, "work order"
is a UI label not a model name.

**Your call:** ___ `fp.job` ___ `fp.work.order` ___ other:______

### Q2. Sticker/sequence label format: keep `WH/MO/00033` or switch to `WH/JOB/00033`?
Existing labels printed on real boxes around the shop say `WH/MO/00033`. Reprinting
all of them is a real cost.

**Recommendation:** Keep `WH/MO/...` for migrated records (preserve the label that's
on the box). Use `WH/JOB/...` for new records going forward. Both formats render
identically on the sticker as "WO #...".

**Your call:** ___ keep `WH/MO/...` for everything ___ switch new ones to `WH/JOB/...` ___ switch all (re-label boxes) ___ other:______

### Q3. Drop `mrp` module dependency entirely, or keep it installed but unused?
Removing `mrp` removes the standard Manufacturing app from the menu — managers
who occasionally peek at standard MRP views lose them. Keeping it installed means
~150MB of unused tables in the DB.

**Recommendation:** Keep `mrp` *installed* (low cost) but drop it from our
modules' `depends`. We don't use it; it sits idle. We can revisit removing later.

**Your call:** ___ keep installed ___ uninstall fully ___ other:______

### Q4. `fp.work.centre` — new model, or extend `mrp.workcenter`?
We could keep `mrp.workcenter` as the work-centre table even though we drop the rest
of MRP. Saves us 1 model worth of refactor.

**Recommendation:** New `fp.work.centre`. Plating work centres are different from
assembly work centres (kind = wet_line / bake / mask / rack), and we already have
`x_fc_facility_id`, `x_fc_fp_work_center_id` extensions on `mrp.workcenter`. Cleaner
to start fresh.

**Your call:** ___ new `fp.work.centre` ___ keep `mrp.workcenter` ___ other:______

### Q5. Step model granularity — operations only, or full recipe tree?
**Option A:** `fp.job.step` = operations only (matches current MRP WO behaviour).
Container nodes (recipe / sub_process) and step nodes (instructions) are pulled
from the recipe template at render time.
**Option B:** `fp.job.step` mirrors the full recipe tree (operations + containers + steps).

**Recommendation:** Option A. Simpler model, current working pattern, render
hierarchy via JOIN at view time. Steelhead's UX achievable without DB-level tree.

**Your call:** ___ A (ops only) ___ B (full tree) ___ other:______

### Q6. Migration approach — big-bang weekend cutover, or parallel-run?
Parallel-run = both systems live for 2 weeks, jobs created in both, comparing
output. More robust but more complex.

**Recommendation:** Big-bang with shadow period (§7.1). Simpler, lower error
surface. Cutover is ~4 hours on a weekend.

**Your call:** ___ big-bang ___ parallel-run ___ other:______

### Q7. Implementation pace — single sprint or phased?
- Single sprint: 8–10 weeks one engineer, full cutover at end.
- Phased: ship `fp.job`/`fp.job.step` models first (week 4); migrate one module
  per week thereafter; cutover at the end (week 12+). More UI churn for operators
  during the transition.

**Recommendation:** Single sprint. Operators only switch UI once.

**Your call:** ___ single sprint ___ phased ___ other:______

---

### Decisions locked (2026-04-25)

| # | Decision | Locked answer |
|---|---|---|
| Q1 | Model name | **`fp.job`** |
| Q2 | Sticker label format | **Keep `WH/MO/...` for migrated records; new records use `WH/JOB/...`. Both render as "WO #..." on the sticker.** |
| Q3 | `mrp` Odoo module | **Keep installed but drop from our `depends`** |
| Q4 | Work centre model | **New `fp.work.centre`** |
| Q5 | Step model granularity | **Option A — operations only (flat list, hierarchy via JOIN at view time)** |
| Q6 | Migration approach | **Big-bang weekend cutover with 2-week shadow period** |
| Q7 | Implementation pace | **Single sprint, ~8 weeks engineering** |

## 11. Next steps

After you sign off on §10:

1. I write the **implementation plan** (`docs/superpowers/plans/...`) — concrete
   per-day task breakdown, branch strategy, commit cadence.
2. We create a feature branch: `feat/fp-native-job-model`.
3. We start with §6.1 (core models) and follow the dependency order through §6.16.
4. End-of-week demos to you against an entech-clone.
5. Cutover weekend scheduled with 4 weeks notice to give the shop time to plan.

If something in §10 or anywhere else is wrong / unclear / debatable, flag it now —
fixing the spec is cheap; fixing committed code is not.