docs(jobs): detail Phase 2 task breakdown — parallel module strategy

Phase 2 was previously outlined as 'rename bridge_mrp → jobs'.
That's destructive on entech. Revised strategy: build
fusion_plating_jobs IN PARALLEL with bridge_mrp. A settings flag
(x_fc_use_native_jobs) controls which path SO confirm takes.
Default False = legacy MO flow stays. Cutover (Phase 9) flips
the flag.

Phase 2 breakdown into 11 tasks (2.1–2.11), totaling ~5 days
engineering. All preserve bridge_mrp untouched until cutover.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

fusion_plating/docs/superpowers/plans/2026-04-25-fp-native-job-model.md

@@ -1642,19 +1642,55 @@ If any item fails, stop. Don't start Phase 2 with a broken foundation.
 
 ---
 
-## Phase 2 (outline only — detail before starting)
+## Phase 2 (detailed 2026-04-25 after Phase 1 landed)
 
-**Goal:** Move SO→MO bridge logic and recipe→WO generator to native job model. Strip MRP coupling from `fusion_plating_bridge_mrp`; rename to `fusion_plating_jobs`.
+**Goal:** Build `fusion_plating_jobs` alongside `fusion_plating_bridge_mrp`. The
+new module routes SO confirm → `fp.job`, runs the recipe → `fp.job.step` generator,
+auto-creates portal jobs / deliveries / certs against the native models, and adds
+the 6 cross-module fields deferred from Phase 1.
 
-Key tasks (detail before starting):
-- Module rename + manifest cleanup
-- `_fp_auto_create_job` on `sale.order.action_confirm`
-- `fp.job._generate_steps_from_recipe` (port logic from `_generate_workorders_from_recipe`)
-- Migrate every `x_fc_*` field on `mrp.production` and `mrp.workorder` to native fields on `fp.job` / `fp.job.step`
-- Quality check, racking inspection, cert generator, delivery hooks rebound to job events
-- Drop `sale_mrp` from `__manifest__.py` depends
+**Strategy revision (vs. original plan):** original said "rename bridge_mrp → jobs."
+Renaming is destructive on entech (a live system). Instead, **build the new module
+in parallel**:
 
-Estimated: 5 days.
+- `fusion_plating_bridge_mrp` STAYS installed and primary. Operators keep using
+  the existing MO-based flow. No regression risk.
+- `fusion_plating_jobs` is NEW. It creates `fp.job` records on SO confirm only
+  when a settings flag (`x_fc_use_native_jobs`) is True. Default: False.
+- Both modules can be installed simultaneously without conflict.
+- Phase 9 cutover flips the flag for entech, deprecating bridge_mrp's MO creation.
+- Phase 10 burn-in keeps bridge_mrp installed read-only as a safety net.
+- Eventual deprecation of bridge_mrp = future task, not blocked by this work.
+
+Branch strategy: same `feat/fp-native-job-model` branch.
+
+### Task breakdown
+
+| # | Task | Detail | Effort |
+|---|---|---|---|
+| 2.1 | Create `fusion_plating_jobs` skeleton | New module dir, manifest with all needed depends (fusion_plating + configurator + portal + logistics + quality + certificates), empty `models/__init__.py`, security ACL stub. Verify clean install on entech. | 0.5d |
+| 2.2 | Add cross-module fields to `fp.job` via `_inherit` | The 6 deferred fields (part_catalog_id, coating_config_id, customer_spec_id, portal_job_id, delivery_id, qc_check_id) added in jobs module. Tests. | 0.5d |
+| 2.3 | Port `fusion.plating.job.node.override` to jobs module | Move from bridge_mrp; rebind from `mrp.production` to `fp.job`. Keep the bridge_mrp version of this model alive on `mrp.production` for now (parallel). Tests. | 0.5d |
+| 2.4 | Recipe → steps generator on `fp.job` | Port `_generate_workorders_from_recipe` from bridge_mrp into a new `fp.job._generate_steps_from_recipe` method. Walks recipe, creates `fp.job.step`. Tests. | 1d |
+| 2.5 | Add settings flag `x_fc_use_native_jobs` + SO confirm hook | New flag on res.config.settings (default False). When True, `sale.order.action_confirm` creates `fp.job` instead of `mrp.production`. Tests cover both flag values. | 0.5d |
+| 2.6 | Portal job binding from `fp.job` | `fusion.plating.portal.job` gains `x_fc_job_id` Many2one. Auto-create portal job on `fp.job.action_confirm`. Tests. | 0.25d |
+| 2.7 | Quality check auto-create | When customer has `x_fc_requires_qc=True`, fp.job.action_confirm spawns a `fusion.plating.quality.check` linked to the job. Tests. | 0.25d |
+| 2.8 | Delivery + cert auto-create on done | `fp.job.button_mark_done` creates `fusion.plating.delivery` (draft) and triggers cert generator (CoC + thickness report) like bridge_mrp does for MO done. Tests. | 0.5d |
+| 2.9 | Account.move (invoice) hook | When invoice posts, find the linked `fp.job` (via SO origin), update portal_job state to 'complete' and stamp invoice_ref. Mirrors bridge_mrp. Tests. | 0.25d |
+| 2.10 | Drop `sale_mrp` from jobs module's depends | Verify zero remaining `sale_mrp`-dependent code paths in jobs. Note: bridge_mrp keeps its sale_mrp dep until cutover. | 0.25d |
+| 2.11 | Tag `phase-2-complete` + demo checklist | Full test run, push, tag, demo path on entech with the flag flipped on a test SO. | 0.25d |
+
+**Total: ~5 days engineering, plus review cycles.**
+
+### Demo target after Phase 2
+
+A manager on entech can:
+1. Open a fresh sale.order, add a plating line.
+2. Toggle `x_fc_use_native_jobs=True` in settings (or per-SO override).
+3. Confirm the SO → instead of MO appearing, a `WH/JOB/00001` lands in the new menu.
+4. Recipe steps auto-generate as `fp.job.step` rows.
+5. Operator (still in old UI for now) doesn't see the fp.job — but a manager can drive it through the admin views.
+6. Toggle off the flag → next SO confirm goes back to MO. Bridge_mrp untouched.
 
 ---