6 Commits

Author SHA1 Message Date
gsinghpal
7fa54d8fc9 feat(plating): per-step compliance gates + backfill — 0 CRITICAL gaps
Per-step audit caught real enforcement bugs across all 9 WO kinds.
Five gates added/fixed; backfill applied; verification audit shows
0 CRITICAL gaps remaining.

**1. Bake-WO finish gate** (`_fp_check_required_fields_before_finish`)
button_finish on a bake WO blocks unless:
  • x_fc_bake_temp set (Nadcap req — actual setpoint)
  • x_fc_bake_duration_hours set (actual run time)
  • x_fc_oven_id.chart_recorder_ref set on the oven
    (so the chart for THIS run can be retrieved by an auditor)

**2. Rack-WO start gate** added to button_start.

**3. Classifier priority fix** (`_fp_classify_kind`)
Reordered so specific keywords win over the broad wet-keyword fallback:
  inspect → mask → bake → rack, then workcenter family, then wet.
"Post-plate Inspection" now → inspect (was wrongly → wet).
"Oven bake (Post de-rack)" now → bake (was wrongly → rack).

**4. Auto-populate** target_thickness + dwell_time at WO generation.
Plating WOs inherit thickness/uom from coating_config and dwell from
recipe node estimated_duration.

**5. Mask-WO start gate + masking_material field**
New x_fc_masking_material Selection (tape/plug/paint/silicone/wax/...).
Required to start mask/de-mask WO. Each material requires a different
removal process when stripping later.

**View** — Process Details tab branches by kind:
  wet → Bath/Tank/Rack/Thickness/Dwell
  bake → Oven/Temp/Duration
  rack → Rack/Fixture
  mask → Masking Material
  inspect/other → informational alerts

**Backfill** (`scripts/fp_backfill.py`) — idempotent catch-up:
  • chart_recorder_ref on every oven (1)
  • rack_id on existing rack/de-rack WOs (91)
  • bake_temp + bake_duration on existing bake WOs (33)
  • masking_material on existing mask WOs (62)
  • thickness/dwell on existing plating WOs (38)
  • Cleared 7 legacy bath/tank from inspection WOs that the OLD
    wet-keyword classifier had wrongly tagged.

**Per-step audit** (`scripts/fp_per_step_audit.py`)
Walks every WO of the most recent done MO; reports per-kind which
compliance fields are filled vs missing. Re-runnable for regressions.

**Final verification** on freshly-run MO:
  • 0 CRITICAL gaps across all 9 WO steps
  • 2 IMPORTANT (dwell_time + rack_id on E-Nickel Plating — both
    inherited from recipe node data, not enforcement bugs)
  • Classifier correct for all 9 step types

12 negative tests still passing.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-19 11:42:12 -04:00
gsinghpal
2804168d9e feat(plating): per-WO-kind equipment fields + smart auto-fill defaults
User caught two related issues from screenshots of the WO form:

  1. The "Plating Details" tab was meaningless for non-wet WOs —
     bath/tank/dwell/thickness all show as empty for masking, oven
     bake, racking, and inspection steps. A shop with multiple ovens
     had no way to record which oven a bake WO ran in.

  2. When there's only ONE option (single oven, single bath), forcing
     the manager to pick it on every WO is busywork — pin it
     automatically.

**1. WO classification + per-kind equipment**

New `x_fc_wo_kind` (compute, non-stored) Selection field that buckets
each WO into one of: wet / bake / mask / rack / inspect / other.
Classification by priority:
  • bath linked → wet
  • oven linked → bake
  • workcenter's process families wet → wet
  • WO name keyword match (bake/oven/cure → bake;
    mask/de-mask → mask; rack/de-rack → rack;
    inspect/qa/qc/fai → inspect; default → other)

New equipment fields per kind:
  • `x_fc_oven_id` (m2o fp.bake.oven) for bake WOs
  • `x_fc_bake_temp`, `x_fc_bake_duration_hours` — bake parameters
  • Existing bath/tank/rack/thickness reused for wet
  • Existing rack reused for rack WOs

**2. Required-fields gate extended**

button_start now also requires `x_fc_oven_id` for bake WOs (alongside
the existing operator + bath/tank rules). Without an oven the
chart-recorder trail can't be tied back to the WO for compliance.

**3. View reorganized**

Process Details tab now shows only the equipment groups that apply
to this WO's kind (using `invisible="x_fc_wo_kind != 'bake'"` etc.).
Mask + Inspection + Other show informational alerts instead of
empty form fields. WO header shows a colour-coded kind badge.

**4. Smart auto-fill defaults**

New `_fp_autofill_default_equipment()` method on mrp.workorder. When
the facility has exactly ONE active option, it pre-pins:
  • Bath → if facility has 1 active bath
  • Tank → if the chosen bath has 1 active tank
  • Oven → if facility has 1 active oven

Hooked from:
  • `@api.onchange('workcenter_id', 'x_fc_facility_id', 'x_fc_bath_id')`
    → fills as user edits in the form
  • Recipe → WO generation `_generate_workorders_from_recipe()`
    → fills at creation time so single-line shops never see an
    empty bath/oven field

None of this overwrites an already-set value. Multi-line shops still
get a blank field to choose from.

**Simulator updates** (scripts/fp_e2e_workforce.py)
  • Creates an oven if none exists
  • Pins per-kind equipment in Hannah's planning step
  • New PASS check: bake-WO auto-pinned to default oven
  • New negative test 2b: bake WO with oven stripped → blocked

**Final E2E**: 54 PASS / 2 WARN / 0 FAIL out of 56 checks.
12 negative tests passing — all gates fire when triggered:
  Tests 1-2 + 2b: WO start (operator + bath/tank + oven)
  Tests 3-7: MO facility, cert spec, delivery POD, invoice
             payment terms, thickness cal std
  Tests 8-11: NCR close, CAPA close, discharge close, invoice ref

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-19 10:47:01 -04:00
gsinghpal
c118b7c6b5 feat(plating): close compliance gaps 7-9 — NCR + CAPA + discharge + invoice ref
**7a. NCR close gate** (fusion.plating.ncr.action_close)
Block close unless these are filled in:
  • Description (what happened)
  • Containment Actions (immediate response)
  • Root Cause (why it happened)
  • Disposition (use-as-is / rework / scrap / RTV decision)

A closed NCR without these is useless for AS9100 audits — it's
the entire point of an NCR to document what went wrong, why, and
how we responded. Empty-HTML strings like "<p><br></p>" are
detected as empty too.

**7b. CAPA close gate** (fusion.plating.capa.action_close)
Block close unless:
  • Root Cause Analysis filled in
  • Action Plan filled in
  • Verification (date + verifier) recorded
  • Effectiveness Notes filled when CAPA was marked Not Effective

AS9100 §10.2 / Nadcap require evidence of root-cause analysis,
the corrective/preventive action plan, AND that effectiveness
was verified before the loop is closed.

**8. Invoice ref defensive default** (account.move.create)
Auto-fills `ref` from the source SO's client_order_ref or
x_fc_po_number when the invoice is created with invoice_origin set
but no ref. Already populated on the SO confirm path; this catches
manually-created invoices that would otherwise miss it. Customer
AP teams reject invoices that don't quote their PO# back.

**9. Discharge sample close gate** (fusion.plating.discharge.sample.action_close)
Block close unless:
  • Lab Report # set
  • Results Received Date set
  • At least one parameter reading on file
  • Lab certificate/report attached

Without lab evidence the record fails any environmental compliance
audit — the whole point is to document the test was performed and
what the lab said.

**Simulator** (scripts/fp_e2e_workforce.py)
Adds 4 new negative tests (Test 8-11), all wrapped in savepoints:
  ✓ Test 8 : NCR close without RC/containment/disposition → blocked
  ✓ Test 9 : CAPA close without analysis/plan/verification → blocked
  ✓ Test 10: Discharge sample close without lab evidence → blocked
  ✓ Test 11: Invoice ref auto-fills from SO.client_order_ref → asserted

**Final E2E**: 52 PASS / 2 WARN / 0 FAIL out of 54 checks.
Both remaining WARNs are expected (bake-window auto-create,
first-piece gate — coating-driven, this coating doesn't trigger them).

11 negative tests in total now, every gate fires when triggered.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-19 10:35:27 -04:00
gsinghpal
db8b79d22e feat(plating): close 6 compliance gaps from required-fields audit
Following the workforce-E2E + required-fields audit, ship the first 6
high-priority gates so critical workflow + compliance fields can no
longer be left empty by accident.

**1. Invoice payment terms (account.move)**
- create() now auto-inherits `invoice_payment_term_id` from
  partner.property_payment_term_id when missing
- action_post() raises UserError if still missing — accountant must
  pick one before posting (prevents silent "immediate" due-date)

**2. MO facility (mrp.production)**
- action_confirm() auto-derives `x_fc_facility_id` if unset, in order:
  SO override → res.company.x_fc_default_facility_id → first active
  facility — then HARD GATES: raises UserError if still empty.
  Without facility every downstream record (WO, batch, bath log,
  cert) is missing the "where" half of the audit trail.

**3. WO facility (mrp.workorder)**
- Switched `x_fc_facility_id` from related (workcenter only) to a
  proper compute that falls back to production_id.x_fc_facility_id.
  Stub workcenters auto-created from process node names usually have
  no facility — the MO always does (from #2 above).

**4. Thickness reading calibration_std (fp.thickness.reading)**
- `calibration_std_ref` is now `required=True` with sensible default
  ("NiP/Al STD SET SN 100174568"). Nadcap mandates which calibration
  standard the gauge was checked against — without it the cert
  data has no chain back to a metrology record.

**5. Delivery POD gate (fusion.plating.delivery)**
- action_mark_delivered() raises UserError if no `pod_id`. Driver
  must capture POD on the iPad (recipient signature + photos +
  notes) BEFORE marking delivered. Without POD there's no signed
  receipt to back the invoice or defend a delivery dispute.

**6. Certificate spec_reference gate (fp.certificate)**
- action_issue() raises UserError if no `spec_reference`. The cert
  ATTESTS to a spec — leaving it blank produces a piece of paper
  that AS9100 / Nadcap auditors will (rightfully) reject.

**Simulator updated**: scripts/fp_e2e_workforce.py
- Sets net-30 on the test customer + ensures a default facility
- New PHASE 4c: 5 negative tests (one per new gate), each wrapped
  in a SAVEPOINT so SQL constraint violations don't abort the txn
- Driver now creates POD on iPad BEFORE marking delivered

**Final E2E**: 48 PASS / 2 WARN / 0 FAIL out of 50 checks.
The 2 remaining WARNs (bake-window auto-create, first-piece gate)
are expected behaviour — both are coating-driven and the test
coating intentionally doesn't trigger them.

All 7 negative tests now pass:
  ✓ Test 1: WO start without operator → blocked
  ✓ Test 2: WO start on wet WO without bath/tank → blocked
  ✓ Test 3: MO confirm without facility → blocked
  ✓ Test 4: Cert issue without spec_reference → blocked
  ✓ Test 5: Delivery delivered without POD → blocked
  ✓ Test 6: Invoice post without payment terms → blocked
  ✓ Test 7: Thickness reading without cal std → blocked (DB NOT NULL)

Audit script (scripts/fp_required_fields_audit.py) committed too —
it's the diagnostic that surfaced these gaps and can be re-run to
catch new ones.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-19 10:07:00 -04:00
gsinghpal
4161f04b0f feat(plating): hard-required fields on WO start — operator + bath + tank
Some checks failed
fusion_accounting CI / test (fusion_accounting_ai) (push) Has been cancelled
fusion_accounting CI / test (fusion_accounting_core) (push) Has been cancelled
fusion_accounting CI / test (fusion_accounting_migration) (push) Has been cancelled
User audit caught: in the workforce E2E run we had no idea which bath /
which tank ran the job. For aerospace traceability that's a deal-
breaker. Add a validation gate on mrp.workorder.button_start so
operators can't tap START without the data the shop floor MUST capture.

**Three new pieces on mrp.workorder:**

1. `_fp_is_wet_process()` — best-effort "does this WO involve a
   chemistry bath?" check. Three signals in priority order:
   a. A bath is already linked → definitely wet
   b. The workcenter's FP work-centre supports a wet process family
      (plating, pre/post-treatment, strip, passivation)
   c. WO name contains a wet-process keyword (plat, nickel, chrome,
      anodiz, zinc, etch, clean, rinse, strip, passivat, electroless…)
   The keyword fallback is needed because most existing recipes have
   no process_type_id set on their operation nodes.

2. `_fp_check_required_fields_before_start()` — runs before the
   existing certification check. Rules:
   • Every WO needs an assigned operator (x_fc_assigned_user_id).
     Without it, productivity records can't be attributed and the
     proficiency tracker has no employee to credit.
   • Wet WOs additionally need x_fc_bath_id + x_fc_tank_id. So we
     know exactly which chemistry bath ran the job and which physical
     tank it sat in.
   Raises a clear UserError listing the missing fields if any.

3. `x_fc_requires_bath` (compute, non-stored) — surfaces the wet check
   to the form view so bath + tank fields render with `required=`.

**View changes:**
- `x_fc_assigned_user_id` is now `required="1"` on the form
- `x_fc_bath_id` + `x_fc_tank_id` use `required="x_fc_requires_bath"`
  → red asterisk only when the WO is actually wet

**Simulator updates** (scripts/fp_e2e_workforce.py):
- Hannah now explicitly assigns bath + tank to wet WOs during planning,
  AND pre-issues operator certifications for the bath's process type
  (real shop manager workflow).
- Two negative tests added that PROVE the gates fire:
  • Test 1: strip the operator → button_start raises "missing Assigned Operator"
  • Test 2: strip bath/tank on a wet WO → button_start raises "missing Bath/Tank"

**Final E2E:** 42 PASS / 2 WARN / 0 FAIL out of 44 checks.
Both remaining WARNs (bake-window auto-create, first-piece gate) are
expected behaviour — those are coating-driven and the test coating
intentionally doesn't trigger them.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-19 09:47:31 -04:00
gsinghpal
bbbd222b89 feat(plating): close 2 workflow gaps surfaced by workforce E2E simulation
Built a comprehensive simulator (scripts/fp_e2e_workforce.py) that
role-plays 10 employees driving an order quote → invoice using real
operator timers (button_start / button_finish with elapsed time.sleep).

Initial run: 31 PASS / 2 WARN / 0 FAIL exposed two gaps that would
hurt a real shop:

**Gap 1 — Thickness readings never reached the CoC**
The Fischerscope readings inspectors take during post-plate inspection
had no path to the CoC. The cert came out empty, useless for AS9100
or aerospace audits.

Fixes:
- New tablet endpoint `/fp/shopfloor/log_thickness_reading` so the
  inspector can record one reading at a time during the inspection WO
  (auto-numbers, defaults the operator, supports microscope image).
- mrp_production._fp_mark_done_post_actions now bulk-links any
  orphan thickness readings (those with production_id=mo.id but no
  certificate_id) to the freshly-created CoC. So inspectors can log
  during inspection AND the cert PDF picks them up automatically.

**Gap 2 — Operator queue leaked other people's work + simulator missed it**
fusion.plating.operator.queue.build_for_user pulled EVERY ready /
in-progress WO regardless of assignment. Tom would see John's masking
WO in his "Up Next" list — bad for aerospace traceability where you
want strict per-operator accountability.

Fix: build_for_user now filters MRP WOs by
`(x_fc_assigned_user_id == user_id OR x_fc_assigned_user_id == False)`.
Operators see their own assigned tasks first, plus any unassigned
tasks anyone can grab. Other operators' assigned WOs no longer leak
through.

Also caught: simulator was using wrong field name on the queue model.
Fixed and added a "queue isolation" check that verifies no operator
sees another operator's assigned WOs.

After fixes: **39 PASS / 2 WARN / 0 FAIL** (out of 41 checks).
Remaining WARNs are both expected behaviour:
  - bake-window auto-create: this coating doesn't require_bake_relief
    (the recipe has an inline Oven step instead)
  - first-piece gate: same — coating-driven, only fires when needed

Areas validated end-to-end:
- quote → SO with PO# carried into client_order_ref
- SO confirm → MO + portal job auto-created
- receiving qty prefill + accept
- 9 WOs generated from recipe + assigned to specific operators
- All 9 WOs ran with real elapsed timers + 17 productivity records
  across 4 distinct operators
- MO done triggers CoC auto-issue with 5 thickness readings linked,
  319 KB rich PDF, customer-slug filename
- Delivery auto-created with prefilled date + driver + CoC link
- Delivery delivered, 2 chain-of-custody entries
- Invoice posted (NOT auto-paid)
- All 5 customer notifications fired (so_confirmed +
  parts_received + mo_complete + shipped + invoice_posted) with
  correct attachments
- Portal job → complete, SO workflow_stage → invoicing
- Chemistry log persisted, operator proficiency tracked

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-19 09:30:56 -04:00