Two coherent feature drops shipping together because their fp_job_step
edits overlap. Both target operator workflow correctness.
## Sub 13 — Sequential step enforcement (recipe + per-step)
Background:
Investigation on WH/JOB/00339 showed operators starting Incoming
Inspection while Contract Review was still in_progress. Audit:
98.7% of recipe operations system-wide had requires_predecessor_done
= false (the legacy per-step opt-in defaults off, recipe authors
rarely tick the box).
Architecture:
Recipe-level toggle + per-step opt-out (Option A from /investigate).
* fusion.plating.process.node.enforce_sequential — Boolean on the
recipe root. Default True. When True, every operation under this
recipe waits for earlier-sequence steps to finish before it can
start.
* fusion.plating.process.node.parallel_start — Boolean on operation
nodes. When True, this step bypasses the sequential gate (e.g.
paperwork or QA review that runs alongside production).
* Mirrored on fp.step.template (parallel_start) so library steps
carry the flag into snapshots.
* fp.job.enforce_sequential — related from recipe_id. Snapshotted
at job creation so a recipe author flipping the recipe's flag
AFTER job generation does NOT change behaviour mid-run.
* fp.job.step.parallel_start — related from recipe_node_id.
* Decision matrix (encapsulated in
fp.job.step._fp_should_block_predecessors):
recipe.enforce_sequential | step.parallel_start | step.req_pred_done | block?
--------------------------|---------------------|--------------------|------
True | False | any | YES
True | True | any | no
False | any | True | YES
False | any | False | no
* Manager bypass via context fp_skip_predecessor_check=True (existing).
Runtime gates:
* fp.job.step.button_start — calls _fp_should_block_predecessors;
raises UserError naming the blocking earlier step(s).
* fp.job.step.can_start — computed Boolean for view-side disable.
* Move wizard predecessor check
(fusion_plating_shopfloor/controllers/move_controller.py) — uses
the same helper so tablet + backend behave identically.
UI surface:
* Recipe form (fp_process_node_views.xml) — enforce_sequential
toggle on recipe root, parallel_start checkbox on operations.
* Step template form — parallel_start checkbox.
* Simple Recipe Editor (inline library form) — Parallel Start
checkbox + legacy flag demoted with muted styling + supervisor
group gate.
* Recipe Tree Editor (properties panel) — both flags exposed,
only-show on the right node_type.
* Controllers updated to allowlist + payload the new fields.
Migration:
fusion_plating/migrations/19.0.18.12.0/post-migrate.py — sets
enforce_sequential = TRUE on every existing recipe-root node.
Idempotent. User confirmed dev-stage data, so retroactive flip
is safe (no production jobs to disrupt).
Tests:
TestSequentialEnforcement (10 tests) covering:
* sequential mode blocks out-of-order start
* first step always startable
* predecessor finish/skip unlocks next
* parallel_start opts out of gate
* free-flow mode bypasses gate
* legacy requires_predecessor_done still honoured in free-flow
* manager bypass via context
* can_start compute reflects state correctly
* library template parallel_start snapshots into recipe-node
## Sub 12e — Record Inputs Wizard v3 (card layout, dark-mode aware)
Background:
v2 wizard was a 17-column wide editable table. Operators got lost
finding which value column applied to their row's type, horizontal
scroll required on tablets, composite types crammed into one row.
New layout:
* Each measurement renders as a stacked card (CSS Grid + display
transformation on the existing list widget — preserves inline
editing, no JS rewrite).
* Card header: prompt name (large, bold) + type/unit pills.
* Card body: ONLY the value widget for this row's type
(number / boolean / date / text / photo / multi-point / panel).
* Composite types (multi-point thickness 5x reading + avg, bath
panel 4 fields) get inline sub-grid inside the card.
* Empty state ("no measurement prompts") with friendly CTA.
Dark mode:
* SCSS branches at compile time on $o-webclient-color-scheme
(per fusion-plating/CLAUDE.md note).
* Tokens: 7 surface colours + 4 ink levels with light/dark hex
pairs, all behind var(--fp-*) custom properties for per-deploy
override.
* Registered in BOTH web.assets_backend AND web.assets_web_dark
so each bundle compiles its own palette.
Tablet polish:
@media (max-width: 900px) — collapse meta below prompt + bump
numeric input min-height to 56px.
Defensive:
* v2 view kept in the XML file (instant rollback by changing one
view_id ref).
* `:has(.o_invisible_modifier)` rule drops empty cells out of the
grid so Odoo's invisible="..." doesn't punch holes in layout.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Fusion Plating — Shop Floor
Tablet / operator ergonomics layer for the fusion_plating core.
Part of the Fusion Plating product family by Nexa Systems Inc. Copyright (c) 2026 Nexa Systems Inc. All rights reserved. Licensed under OPL-1 (Odoo Proprietary License v1.0).
What this module adds
| Feature | Model |
|---|---|
| Tablet station registration | fusion.plating.shopfloor.station |
| Bake oven master + chart recorder ref | fusion.plating.bake.oven |
| Hydrogen embrittlement bake-window enforcer | fusion.plating.bake.window |
| First-piece inspection gate | fusion.plating.first.piece.gate |
| Operator next-up queue (transient) | fusion.plating.operator.queue |
Bake-window enforcer
When a high-strength-steel part exits the plating tank, a clock starts. Customer specification dictates the window (typically 1-4 hours) inside which the relief bake must begin. Missing the window requires scrap or rework — there is no retroactive fix.
The module models this as a first-class entity with:
plate_exit_time— clock startwindow_hours— customer specbake_required_by— computed deadlinestate—awaiting_bake -> bake_in_progress -> baked, withmissed_window/scrappedexit paths- A 5-minute cron that flips records past their deadline to
missed_windowautomatically - A kanban board grouped by state with theme-aware status colours
Tablet client
A backend OWL component (Odoo 19 conventions) registered as the
fp_shopfloor_tablet client action. It hosts:
- QR scan input (wedge scanner or on-screen keyboard friendly)
- Live tank / bath / job preview cards
- One-tap Start Bake / End Bake buttons
- Live operator next-up queue
JSON-RPC endpoints (Odoo 19 type='jsonrpc'):
POST /fp/shopfloor/scanPOST /fp/shopfloor/log_chemistryPOST /fp/shopfloor/start_bakePOST /fp/shopfloor/end_bakePOST /fp/shopfloor/queue
QR code conventions
| Prefix | Resolves to |
|---|---|
FP-TANK:<code> |
fusion.plating.tank |
FP-BATH:<name> |
fusion.plating.bath |
FP-STATION:<code> |
fusion.plating.shopfloor.station |
FP-JOB:<name> |
fusion.plating.bake.window |
FP-OVEN:<code> |
fusion.plating.bake.oven |
Security
Reuses the four core Fusion Plating groups (operator, supervisor, manager,
admin) defined in fusion_plating. No new groups, no new privilege block.
ACLs are graded operator (read/write logs), supervisor (create), manager
(full).
Theme
All styling is theme-aware: CSS custom properties + color-mix() against
Bootstrap / Odoo tokens. No hex codes, no media queries — works in light
and dark mode out of the box.
Install / update
docker exec odoo-dev-app odoo -d fusion-dev -u fusion_plating_shopfloor --stop-after-init