Odoo-Modules/fusion_plating/docs/superpowers/specs/2026-04-27-simple-recipe-editor-steelhead-screens.md

# Steelhead "Move Parts" Screen Inventory — Simple Recipe Editor

Working notes captured during brainstorming. Each screenshot the user
provides is logged here so we can fold the field requirements into the
final design. Do NOT lose these notes — they drive the data shape on
`fp.step.template.transition.input` and the eventual transition dialog
on the tablet.

## Common dialog header (all screens)

- **Title bar**: "Move Parts"
- **Cancel** + red **MOVE (n)** button at footer (n = part count being moved)

## Screenshot 1 — node→node move (no station)

| Field | Type | Example | Notes |
|---|---|---|---|
| Part Count | Integer (with stepper) | 1 | "Available: 1" hint shown beneath the input |
| Part Number | Read-only link | TEST225451 | resolves back to part record |
| From Node | Read-only link | Contract Review | current node operator is leaving |
| Transfer Type | Selection | Step | (other values likely: Step / Hold / Scrap / Return — TBD as more screens come in) |
| To Node | Read-only link | Ready for Incoming Inspection | destination node |
| To Location | Selection + camera icon | Global | location picker; camera icon = take photo evidence inline |
| Number of Customer WOs | Char | (blank) | optional; only present on this screen |
| Billed Labor | section with timer icon + "Reset All Edits" button | — | per-operator timer breakdown follows |
| **Per-operator labor row** | composite | Kris Pathinather, Timer Duration: 56s (100.0% billed), WO #4521 PN: TEST225451 Qty: 1, hrs/min/sec edit fields | reconcilable timer vs. billed split; the small icon top-right of the row appears to be "edit notes" |

## Screenshot 2 — node→node move with station picker (between two real shop steps)

| Field | Type | Example | Notes |
|---|---|---|---|
| Part Count | Integer (stepper) | 49 | Available: 49 |
| Part Number | Read-only link | TEST225451 | |
| From Node | Read-only link | Ready for Incoming Inspection | |
| Transfer Type | Selection | Step | |
| To Node | Read-only link | Incoming Inspection | |
| **To Station** | Selection | Incoming Inspection | NEW field on this variant — appears when destination node has multiple stations to choose from. Defaults to a sensible value but is editable. |
| To Location | Selection + camera | Global | |
| Billed Labor | section | — | (not expanded on this screen — implies optional / collapsed by default when timer hasn't accrued) |

## Screenshot 3 — second node→node move with From Station

| Field | Type | Example | Notes |
|---|---|---|---|
| Part Count | Integer (stepper) | 49 | Available: 49 |
| Part Number | Read-only link | TEST225451 | |
| From Node | Read-only link | Incoming Inspection | |
| **From Station** | Read-only link | Incoming Inspection | NEW — appears when the source node had a station selected previously |
| Transfer Type | Selection | Step | |
| To Node | Read-only link | Adhesion Test Coupon | |
| To Location | Selection + camera | Global | |
| Billed Labor | section with "Reset All Edits" button | — | |
| Per-operator labor row | composite | Kris Pathinather, Timer Duration: 4s (100.0% billed), WO #4521 PN: TEST225451 Qty: 49, hrs/min/sec edit fields | same shape as screenshot 1 |

## Patterns emerging across screenshots so far

1. **Variable field set per transition.** Some moves show "Number of Customer WOs", some don't. Some show "To Station" / "From Station", some don't. The recipe author needs to be able to declare which fields appear on which transitions — that's what `fp.step.template.transition.input` is for.

2. **Read-only context fields are always present** (Part Count, Part Number, From Node, To Node, From/To Station when applicable, To Location, Transfer Type). These are *system-derived* — the recipe author doesn't author them, they come from the runtime context. Our model only needs to capture the *author-defined* prompts (extra compliance fields).

3. **Camera icon next to To Location** = inline photo capture, attached to the transition log. Implies the runtime needs a `photo` input type that can either upload a file or trigger device camera (mobile / tablet).

4. **Billed Labor is a separate concern** — it's a labor reconciliation widget, not a recipe-defined input. Operator can edit hrs/min/sec to reconcile timer vs. actual time billed. Per-operator row with Timer Duration + "100.0% billed" indicator. "Reset All Edits" button reverts all manual reconciliations to timer values. This is its own sub-system; goes outside `fp.step.template` (it's a runtime feature, not authored on a recipe).

5. **Transfer Type values seen so far**: `Step`. More variants expected (Hold, Scrap, Return, Rework). Each variant likely has its own required field subset.

## Screenshot 4 — Adhesion Test Coupon → Ready for racking (no station, no labor block)

| Field | Type | Example | Notes |
|---|---|---|---|
| Part Count | Integer (stepper) | 49 | Available: 49 |
| Part Number | Read-only link | TEST225451 | |
| From Node | Read-only link | Adhesion Test Coupon | |
| Transfer Type | Selection | Step | |
| To Node | Read-only link | Ready for racking | |
| To Location | Selection + camera | Global | |
| Billed Labor | section icon only | — | not expanded — implies no timer accrued on this leg |

Pattern: short transitions between QA-style intermediate nodes don't
expand the labor reconciliation panel. Labor block expands only when a
non-zero timer has accrued OR when an operator has a row to reconcile.

## Screenshot 5 — Ready for racking → Racking (no station, no labor)

| Field | Type | Example | Notes |
|---|---|---|---|
| Part Count | Integer (stepper) | 49 | Available: 49 |
| Part Number | Read-only link | TEST225451 | |
| From Node | Read-only link | Ready for racking | |
| Transfer Type | Selection | Step | |
| To Node | Read-only link | Racking | |
| To Location | Selection + camera | Global | |
| Billed Labor | section icon only | — | collapsed |

Pattern: same as screenshot 4. "Ready for X" nodes are gating-only
(parts wait there) — moving past one accrues no measurable labor.

## Screenshot 6 — Racking → Ready For Plating + amber **rack-required warning**

| Field | Type | Example | Notes |
|---|---|---|---|
| Part Count | Integer (stepper) | 49 | Available: 49 |
| Part Number | Read-only link | TEST225451 | |
| From Node | Read-only link | Racking | |
| Transfer Type | Selection | Step | |
| To Node | Read-only link | Ready For Plating | |
| **To Station** | Selection | SP Line | destination has multiple plating lines; SP Line is the auto-pick |
| To Location | Selection + camera | Global | |
| **WARNING BLOCK** (amber, with ⚠ icon) | banner | "Parts are currently at a RACKING node and are not racked." | Soft block — informs operator the parts haven't been associated with a physical rack yet |
| Billed Labor | section icon only | — | collapsed |
| Footer | THREE buttons | Cancel · **RACK PARTS** (red secondary) · **MOVE (49)** (red primary) | RACK PARTS opens a separate Rack Parts dialog (screenshots 7–8) |

**Critical pattern**: a node's **type** (e.g. Racking) can require
auxiliary records (rack assignment) BEFORE the move is allowed. The UI
warns but doesn't hard-block — operator can still hit MOVE if they
choose, presumably escalating an audit flag. RACK PARTS is the
"resolve the warning" path.

This implies the recipe author needs a way to declare:
> "This step's destination requires a rack assignment before move." —
> a node-type-level rule, not a transition-input rule.

→ NEW field on `fp.step.template` and `fusion.plating.process.node`:
`requires_rack_assignment` Boolean. When True and the operator hasn't
linked a rack to this batch of parts yet, the tablet shows the amber
warning + RACK PARTS button.

## Screenshot 7 — Rack Parts dialog (overlay on top of Move Parts)

| Field | Type | Example | Notes |
|---|---|---|---|
| Title | "Rack Parts" with QR-scanner icon top-right | — | scanner icon = scan rack QR to auto-fill To Rack |
| To Rack | Search-and-select dropdown | (blank → "Search Racks…") | M2O picker against a rack registry |
| Per-line row | composite | TEST225451 on WO 4521 (49) — Unit: **Count** dropdown — Amount: **49** | shows the part being racked + qty in the chosen unit |
| Unit | Selection | Count | (other values likely: Count / Pieces / Lbs / Kg / Sheets — TBD) |
| Amount | Number | 49 | usually = Part Count from Move Parts but editable |
| Billed Labor | section icon only | — | collapsed; same widget as Move Parts |
| Footer | THREE buttons | Cancel · **SAVE** (disabled until To Rack set) · **SAVE + PRINT** (disabled until To Rack set) | SAVE + PRINT prints rack travel ticket / barcode |

## Screenshot 8 — Rack Parts dropdown expanded

| Element | Notes |
|---|---|
| Searchable dropdown | Free-text "Search Racks…" filters list |
| Shows list of named racks: Rack 3, Rack 4, Rack 5, Rack 6, Rack 7, Rack 9, Rack 11 ... | Gaps in numbering (no Rack 8, no Rack 10) imply **active filter** — dropdown only shows racks currently empty / available. Numbers persist; full list is sparser than the index range. |
| Highlighted on hover | Rack 3 shown highlighted, indicating standard combobox UX |

**Implication for our model**: a `fp.rack` registry already has the
shape we need (`name`, `active`, `state` for empty/in-use). Need a
M2O on the racking transition log: `rack_id`. Selection is filtered
to `state='empty'` by default, with an override to show all.

The QR scanner icon implies a scan-to-fill flow on the tablet — same
mechanism we already use elsewhere (`/fp/shopfloor/scan` endpoint
resolves a scanned QR to a tank/job/etc.). For racks, we'd extend the
scan endpoint with a `fp-rack:<id>` token resolver.

## Patterns updated after screens 4–8

6. **Three transition-time prompt families now visible**:
   - **Author-defined compliance prompts** (per-step on
     `fp.step.template.transition.input`) — variable per step.
   - **Always-on context fields** (Part Count, From/To Node, etc.) —
     system-derived, not authored.
   - **Step-type-driven side dialogs** — declared by Boolean flags on
     the step (e.g. `requires_rack_assignment`) — open a separate
     mini-dialog (Rack Parts) before the main move can complete.
     Other likely flags: `requires_bake_window`, `requires_qc_check`,
     `requires_signature`. Each maps to an existing or new sub-dialog.

7. **Move button label reflects qty**: `MOVE (49)` vs `MOVE (1)`.
   Operator confidence cue — they see exactly how many parts they're
   committing to move before tapping.

8. **Soft-block vs hard-block UI language**:
   - **Amber warning + clickable resolution button** = soft block
     (operator may proceed with audit log).
   - **Red error + disabled MOVE** = hard block (operator cannot
     proceed). Not yet seen in any screenshot, but pattern is implied
     by the amber design.

## Screenshot 9 — Compact part-row card (paused timer)

| Element | Notes |
|---|---|
| Checkbox (left) | bulk-select for cross-row actions |
| Red **paused** icon (∥∥) | visual cue: timer is currently paused on this row |
| Inline summary | "1 TEST225451 \| Rack 3 \| Racking" — Qty + part link + rack link + node link, all clickable navigations |
| Sub-line | "Kris Pathinather: 27s" — operator name + accrued timer duration on this row |

Pattern: this is a Plant Overview / Tablet row — a **per-batch
position card** showing a single chunk of parts at a single node, with
the operator who currently owns its labor timer + its rack assignment
inline. Clicking any blue link drills into that record.

## Screenshot 10 — Stop User Labor Timer dialog

| Field | Type | Example | Notes |
|---|---|---|---|
| Title | "Stop User Labor Timer" | — | Distinct dialog from Move Parts; fires when operator pauses without moving |
| Billed Labor | section | Kris Pathinather, Timer Duration: 32s (100.0% billed) | with **RESET ALL EDITS** button |
| Per-row | composite | "WO #4521 PN: TEST225451 Qty: 1" + Product Select + hrs/min/sec inputs | NEW: **Product** dropdown — operator can split timer time onto multiple products. Defaults to current PN. |
| Footer | THREE buttons | Cancel · **SAVE** · **SAVE & START NEW TIMER** | Distinguished from Move Parts which is Cancel/MOVE — labor reconciliation is its own action |

**Critical insight**: labor reconciliation is a **standalone flow**,
not embedded in Move Parts. Operator can stop the timer without moving
parts. This implies our model needs:
- A persistent **labor timer record** (`fp.labor.timer`?) per
  (operator × WO × part × node), independent of the move log.
- A **labor reconciliation** action that closes a timer with a billed
  hrs/min/sec breakdown, optionally splitting across multiple products.

## Screenshot 11 — Move Rack: tyut (full-rack move dialog)

| Field | Type | Example | Notes |
|---|---|---|---|
| Title | "Move Rack: tyut" | — | rack name (here "tyut") in the title — ties move to a specific rack record |
| **Rack Labels** | M2M with `+` button | (empty) | tag rack with shop labels (priority colours, customer codes, etc.) |
| **Parts** section | static list of contained parts | "49 TEST225451 Parts on WO 4521" + "1 TEST225451 Parts on WO 4521" | shows ALL parts on the rack at once — moving a rack moves everything on it as one unit |
| Type | Selection | Step | same as Move Parts |
| **To Node** | Selection (read-only here, "Soak Clean (SP-1)") | Soak Clean (SP-1) | greyed-out — auto-derived from current step's recipe path |
| **To Station** | Selection | Soak Clean (SP-1) | editable; defaults to first compatible station |
| Billed Labor | section + RESET ALL EDITS | — | per-batch row breakdown: each contained part qty gets its own hrs/min/sec inputs |
| Per-row | composite (×2 in this rack) | "WO #4521 PN: TEST225451 Qty: 49" → 0/0/6 + "WO #4521 PN: TEST225451 Qty: 1" → 0/0/0 | individual labor split per chunk on the rack |
| Footer | TWO buttons | Cancel · **SAVE** | no separate MOVE button — SAVE commits the move |

**Critical pattern**: Move Rack is a **rack-as-unit move**, distinct
from Move Parts (parts-as-unit). When parts are racked, they MUST move
as a rack — Steelhead enforces this by not surfacing the per-part Move
button (see screenshot 12: those buttons are disabled/greyed when
racked). The recipe author doesn't author move-rack rules; they're
runtime-enforced based on whether the parts are currently on a rack.

## Screenshot 12 — Plant overview: Racks vs Parts panes (rack collapsed UI)

| Section | Notes |
|---|---|
| **Racks** header | with red "UNRACK MULTIPLE" button — bulk unrack action |
| Rack row | red ∥∥ pause icon · "50 Parts" · rack name "tyut" (Rack 3) · current node breadcrumb "Soak Clean (SP-1) / Soak Clean (SP-1)" · "Kris Pathinather: 14s" labor stamp · **MOVE RACK** primary button on the right |
| **Parts** header | with `+ ADD NEW PARTS` button + filters (Part Number ▾, Part Account ▾) + search box "Search by PN or group" |
| Parts row(s) | qty + PN + rack + node breadcrumb + operator/timer + per-row buttons: **MOVE PARTS** (greyed out / disabled because racked) + QR icon + ribbon icon + ⋮ kebab + ⌄ expand |

**Critical UI rule emerging**: when parts are racked, **the per-part
Move Parts button greys out**. The only way to move racked parts is
via **MOVE RACK**. This is enforced by the disabled button state, not
by error message. Operator UX is: "You can't accidentally move just
some of these parts — they're racked together, move the rack."

This implies a runtime guard on `fp.job.step` (or wherever the move
controller lives): if `rack_id` is set on the part-batch, reject
move-parts calls and require move-rack.

## Screenshot 13 — Move Rack: tyut (different destination, station picker shows non-default station)

| Field | Type | Example | Notes |
|---|---|---|---|
| Title | "Move Rack: tyut" | — | same dialog shape as screenshot 11 |
| Rack Labels | M2M + button | (empty) | |
| Parts list | static | "49 TEST225451 Parts on WO 4521" + "1 TEST225451 Parts on WO 4521" | same contents as 11 |
| Type | Selection | Step | |
| To Node | Selection (read-only) | Rinse (SP-2) | rack has advanced one step from screenshot 11 (Soak Clean → Rinse) |
| **To Station** | Selection | "Cold Water Rinse …" (truncated) | NEW: shows that one node can have **multiple stations** with descriptive names, not just SP-numbered codes. The SP-2 prefix is the tank code; "Cold Water Rinse" is the station's display name. |
| Billed Labor | section + RESET ALL EDITS | — | per-batch labor split as before; total Timer Duration: 10s |
| Footer | TWO buttons | Cancel · **SAVE** | |

**New insight**: stations have both a **code** (SP-2) AND a **friendly
name** (Cold Water Rinse). Our model already has `name` + `code` on
`fusion.plating.tank` — confirming our existing design matches
Steelhead's naming model 1:1.

## Patterns updated after screens 9–13

9. **Labor timer is a first-class persistent entity**, not a UI
   ephemeral. It has a stop-without-move flow (screen 10), it can be
   reset, it splits across products. Probably its own model
   `fp.labor.timer` with states: `running / paused / stopped /
   reconciled`.

10. **Rack-vs-parts move duality**: parts-not-racked → Move Parts
    dialog; parts-racked → Move Rack dialog (MOVE PARTS greys out).
    Move Rack moves all rack contents at once with per-chunk labor
    breakdown. Need `rack_id` on the move-controller decision.

11. **Rack Labels** as a tagging surface — M2M against a tag-like
    registry. Not yet authored on `fp.step.template` (it's a runtime
    rack metadata feature). Goes on `fp.rack` directly when we build
    that registry.

12. **Plant Overview shape**: top section "Racks" with rack-level
    primary action (MOVE RACK) + bulk action (UNRACK MULTIPLE);
    bottom section "Parts" with per-part actions (greyed when
    racked) + filters + search. This is the layout the simple-mode
    customer probably also wants on their plant overview — but
    that's a separate sub-project from the recipe editor.

13. **"To Node" vs "To Station" hierarchy is consistent**: To Node is
    read-only (auto-derived from recipe sequence), To Station is
    editable (operator picks among compatible stations on that
    node). For our simple recipe editor, this means each step's
    `tank_ids` M2M is the **authoritative compatible-station list**
    that the runtime uses to populate the To Station dropdown. The
    recipe author's job is to declare the ALLOWED set; the operator
    picks among them at run time.

## Screenshot 14 — Move Rack: tyut → Ready For DeRack (no station picker)

| Field | Type | Example | Notes |
|---|---|---|---|
| Title | "Move Rack: tyut" | — | rack name in title |
| Rack Labels | M2M + button | (empty) | |
| Parts list | static | "49 TEST225451 Parts on WO 4521" + "1 TEST225451 Parts on WO 4521" | full rack contents |
| Type | Selection | Step | |
| **To Node** | Selection (read-only, greyed) | "Ready For DeRac…" (truncated; full = "Ready For DeRack") | gating-only node — no station to choose, no plating action |
| **No To Station field** | — | — | confirms: when destination is a single-station / gating node, the To Station row does not render |
| Billed Labor | section + RESET ALL EDITS | — | per-batch breakdown |
| Per-row labor | composite | "WO #4521 PN: TEST225451 Qty: 49" → 0/0/4 + "WO #4521 PN: TEST225451 Qty: 1" → 0/0/0 | |
| Footer | TWO buttons | Cancel · **SAVE** | |

**Pattern**: gating nodes (anything starting with "Ready For…") are
single-station and skip the To Station selector. Move Rack and Move
Parts both honour this. Our model should treat any node with exactly
one tank in `tank_ids` (or none — implying "any global location") as a
node that hides the station picker.

## Screenshot 15 — Move Parts with **soft-block: missing spec measurements** (MOVE button DISABLED)

| Field | Type | Example | Notes |
|---|---|---|---|
| Part Count | Integer (stepper) | 49 | Available: 49 |
| Part Number | Read-only link | TEST225451 | |
| From Node | Read-only link | Bake | |
| **From Station** | Read-only link | Bake | |
| Transfer Type | Selection | Step | |
| To Node | Read-only link | Adhesion Testing | |
| To Location | Selection + camera | Global | |
| **WARNING BLOCK** (amber, ⚠ icon) | banner | "Additional Spec Measurements are required for this part." | distinct from the rack-required warning |
| Billed Labor | section + RESET ALL EDITS | — | Timer Duration: 7s |
| Per-row labor | composite | "WO #4521 PN: TEST225451 Qty: 49" → 0/0/7 | |
| Footer | TWO buttons | Cancel · **MOVE (49)** (DISABLED / greyed) | **HARD BLOCK** — operator can't proceed until spec measurements are recorded |

**Critical pattern — first hard block we've seen**:
- Steelhead shows the same amber colour for both soft-block (rack
  warning) and hard-block (missing spec). The DIFFERENCE is the
  primary button state: soft-block leaves MOVE enabled (audit and
  proceed); hard-block greys MOVE out (must resolve first).
- Steelhead does NOT explain HOW to record the missing measurements
  in this dialog — the operator is left to figure out where to enter
  them. This is what the user means by "Steelhead is limited."

**Where we improve over Steelhead**:
- The amber banner should have a **clickable resolution button** like
  the rack warning's "RACK PARTS" button — e.g. **"RECORD MEASUREMENTS"**
  that opens the spec-measurement input dialog inline.
- After recording, the banner clears + MOVE re-enables. No screen
  hunting.
- Distinguish soft vs hard visually: amber for soft (proceed-with-
  audit), red for hard (must-resolve).

## Patterns updated after screens 14–15

14. **Gating nodes (Ready For …)** are single-station / no-station
    nodes — UI hides the To Station selector for them. Our recipe
    editor's step-template form should let the author mark a step as
    "gating" (no tanks/stations needed) and the runtime auto-hides
    the station picker.

15. **Soft-block vs hard-block protocol**:
    - **Soft-block**: amber banner + resolution button + MOVE stays
      enabled (rack-required warning, screen 6).
    - **Hard-block**: amber banner + MOVE disabled until resolved
      (missing spec measurements, screen 15).
    - **Steelhead's gap**: hard-block doesn't tell operator where to
      go to resolve. **Our improvement**: every blocker (hard or
      soft) gets an inline resolution button.

16. **Spec measurements vs operation measurements vs transition
    inputs**: three distinct concepts now visible:
    - **Operation measurements** (`input_template_ids` on
      `fp.step.template`) — recorded *during* a step, e.g. "Actual #
      of parts" mid-bake.
    - **Transition inputs** (`transition_input_ids`) — recorded
      *when leaving* a step, e.g. "Customer WO #" or photo evidence.
    - **Spec measurements** (NEW from screen 15) — part-level
      specs that are required *for the part itself* across multiple
      steps, e.g. "thickness reading" required after Adhesion
      Testing. These don't belong on the step template — they belong
      on the **part** record (or on a part × step rule). The amber
      block fires when the part hasn't satisfied a spec rule.

    → Implies a separate authoring surface: per part (or per
    customer × part), a list of "required spec measurements" with
    their trigger node. Out of scope for this sub-project but worth
    flagging in the design as a hand-off point.

17. **MOVE button label DISABLED state**: greyed background, greyed
    text, still shows count "MOVE (49)". Steelhead does NOT show a
    tooltip explaining why — another improvement opportunity for us.

## Screenshots 16, 17, 18 — Paper Job Traveller (3-page WO #023633-1, Amphenol Canada, ENP-Aluminum)

These are the **manual paper job travellers** the client fills in by
pen as the parts move. They're the gold-standard spec of what data
flows through a real plating job today. Every column on these sheets
is a candidate for digital capture in our recipe → step-template →
runtime stack.

### Header (repeats on every page)

| Column | Example | Where it lives in our model |
|---|---|---|
| WO # | 023633-1 | `fp.job.name` (already exists) |
| Barcode | (1D barcode of WO #) | `fp.job.qr_code` (already auto-generated; switch to 1D Code 128 for traveller print) |
| Date In | 29-11-2024 | `fp.job.date_received` (already exists, comes from `fp.receiving`) |
| Due Date | 11-12-2024 | `fp.job.date_due` (already exists, from SO commitment date) |
| Type | ENP-ALUMINUM | `fp.job.coating_config_id.name` (already exists) |
| Order No. | 023633 | `fp.job.sale_order_id.name` (already exists) |
| P.O. No. | 731830 | `fp.job.sale_order_id.client_order_ref` (already exists) |
| Customer | AMPHENOL CANADA + address + phone | `fp.job.partner_id.*` (already exists) |
| WO Generated By | RIYA | `fp.job.create_uid.name` (already exists) |

→ **No new model fields needed for the header.** Existing job fields
cover everything. The traveller-print report just needs to pull them.

### Item Information block (page 1, top)

| Column | Example | Where it lives |
|---|---|---|
| Item informations / Part # | VS-E0443220025 | `fp.part.catalog.part_number` (already exists) |
| Rev. | 1F | `fp.part.catalog.revision` (already exists) |
| Mat. (material) | 6061-T6511 | NEW field on `fp.part.catalog`: `base_material` Char (e.g. "6061-T6511 aluminum"). Currently we have implicit material via coating config — making it explicit per-part is small. |
| Catg. (category) | ENP-ALUMINUM | derived from `fp.part.catalog.coating_config_id.name` |
| S/N (serial #) | (blank for batch) | already exists as `x_fc_serial_number` (Sub 5) |
| Item-Name / Process Description | "SHELL RECEPTACLE / 01 - ELECTROLESS NICKEL PLATING PER E499-303-00-002 OF AMPHENOL SPEC # E499-303-00-XXX REV : 1F" | `fp.part.catalog.name` + `fp.part.catalog.customer_facing_description` (already exist; just need to merge in the report) |
| Qty Rec. | 5850 → 5839, 5835 (multiple counted lines) | NEW: traveller needs to show **received qty** AND **per-stage running counts**. Stages: Received → Inspected → Racked → Plated → Final-counted. Capture per-stage. |
| VIS INSP. | 0 (visual inspection rejects/holds during incoming) | NEW: integer column on `fp.job` for "qty rejected at incoming inspection" |
| Rework | (blank) | NEW: integer column for "qty sent to rework" |
| Special Requirements | "MID PHOS / PANEL THICKNESS: 0.0224"-0.0228" (PLATING THICKNESS: 0.0005"-0.0007") / BAKE @ 250 DEG F FOR 1 HOUR / *****RUN EACH LOAD WITH 3 TEST PANELS AND VERIFY THE PLATING THICKNESS USING XRF PRIOR TO REMOVING PARTS FROM THE TANK..." | NEW: `fp.job.special_requirements` Text (free-form). Today this lives in customer specs but isn't pulled onto the traveller. |
| Stamp + Date | initials "LY" + "06.12.24" | runtime sign-off — captured per-section by the inspector |

### Process-Sheet header (page 1, middle)

| Column | Example | Where it lives |
|---|---|---|
| Process name 1 | "ENIP (A) BAKE (GENERIC)" | `fp.job.process_node_id.name` (root recipe) |
| Process name 2 | "ENIP (A) BAKE" | sub-process node name (already exists in tree) |
| Catg. | ELECTROLESS NICKEL | from coating config |
| Special Req. | (blank in this WO) | `fp.job.special_requirements` |
| Spec / Info block | (blank, reserved for sticker / inspector notes) | print-only blank |

### Step rows (the heart of the traveller)

Each step row carries:

| Column | Type / format | Notes |
|---|---|---|
| **Step #** | Integer (1, 2, 3, ... 25) | already on our model as `sequence` (auto-numbered in the OWL editor) |
| **Tank** | Char code (A-1, A-2, A-13, blank) | comes from `tank_ids` M2M chosen at runtime → `fp.job.step.tank_id` |
| **Operation** | Operation name (e.g. "Soak clean", "Etch", "E-Nickel Plate", "Inspection") | `fp.step.template.name` |
| **Operation actual-data column** (multi-row, hand-written) | Free-form actuals filled in pen — varies per step. Examples: "Actual Qty: 5839", "Actual Time: 04 min", "Actual Temperature: 170 ºF", "Actual time: 01 min / Actual temperature: 190 ºF / Plating thickness: 0.0005"", "PASS: ✓ FAIL: ___", "Actual thickness: 0.00057" | THIS IS THE OPERATION-MEASUREMENT INPUT LIST. Each value the operator pencils in is a `fp.step.template.input` row. |
| **Instruction** | Free-form instructions tied to a Work Instruction reference | "Immerse parts in alkaline soak cleaner for 4-6 minutes @ 150-170 ºF as per WI 10.07." / "Verify plating thickness is as per customer requirements and as per WI 10.09" / "Verify the job traveler was filled out completely and the information is correct." | maps to `fp.step.template.description` (Html) |
| **Unit** | Char (each / Minutes / Seconds / mils / min / ºF / blank) | NEW: `fp.step.template.unit` Char or Selection. Currently NOT in our model. Operators need to know what unit the actual-time / actual-thickness etc. should be in. |
| **Material** | mostly N/A; some steps have "MID PHOS" written | this column is for **chemistry callout** when the step has a material-specific bath. Maps to `fp.step.template.process_type_id` (already exists) — the process type's name prints here. |
| **Voltage** | mostly N/A | electrolytic steps only. NEW: optional `voltage_target` Float on step template. |
| **Viscosity** | mostly N/A | bath-quality callout. NEW: optional `viscosity_target` Float. |
| **Time (min)** | range, e.g. "4 - 6" / "55 - 65" / "25 - 35" | the **target range** the operator must hit. NEW: `time_min_target` + `time_max_target` Float on step template. |
| **Temp.** | (mostly empty in target column; pencilled in actual) | the **target range**. NEW: `temp_min_target` + `temp_max_target` + `temp_unit` Selection (F/C). |
| **Stamp** | initials column | runtime per-step sign-off. Captured as `fp.job.step.signoff_user_id` + signoff datetime. |
| **Date** | dd.mm.yy format | per-step completion date (auto-stamped on `Mark Done`). Already exists as `fp.job.step.date_finished`. |

### Concrete examples from the WO that show the data shape

| Step # | Tank | Operation | Targets (printed) | Actuals (handwritten) |
|---|---|---|---|---|
| 1 | — | Part verification and quantity check | unit=each | "Actual Qty: 5839" |
| 2 | — | Issue Panels | — | (no actual; just stamp/date) |
| 3 | — | Rack | — | "Actual Qty: 5839" |
| 4 | A-1 | Soak clean | 4-6 min @ 150-170 °F | "Actual time: 04 min, Actual Temperature: 170 °F" |
| 5 | A-2 | Rinse | — | (stamp only) |
| 6 | — | Water Break Test | — | "PASS: ✓" |
| 7 | A-3 | Etch | 55-65 sec | "Actual Time: 60 sec." |
| 9 | A-5 | Desmut | 55-65 sec | "Actual Time: 60 sec." |
| 11 | A-7 | Zincate | 25-35 sec | "Actual Time: 25 sec." |
| 13 | A-5 | Strip Zincate | 15-25 sec | "Actual Time: 25 sec." |
| 17 | A-13 | E-Nickel Plate | 185-190 °F | "Actual time: 01 min, Actual temperature: 190 °F, Plating thickness: 0.0005"" |
| 22 | — | Baking | (Time In / Time Out) °F | "Time In: 10:00, Time Out: 11:00, Actual temperature: 250 °F" |
| 23 | — | Inspection | mils | "Actual thickness: 0.00057, PASS: ✓" |
| 24 | — | Final Inspection | — | "Verify the job traveler was filled out completely…" |
| 25 | — | Shipping | — | "Actual Qty: 5839" |

## What the traveller tells us about our data model gaps

### Step template — NEW fields needed

| Field | Type | Reason |
|---|---|---|
| `unit` | Char or Selection | Print "each / Minutes / Seconds / mils / ºF / N/A" so operator knows units |
| `time_min_target` | Float | Lower bound of operation time |
| `time_max_target` | Float | Upper bound; runtime warns if outside |
| `time_unit` | Selection (`sec / min / hr`) | how to interpret time fields |
| `temp_min_target` | Float | Lower bound of operation temperature |
| `temp_max_target` | Float | Upper bound |
| `temp_unit` | Selection (`F / C`) | how to interpret temp fields |
| `voltage_target` | Float (optional) | electrolytic steps |
| `viscosity_target` | Float (optional) | bath-quality |
| `material_callout` | Char (optional) | "MID PHOS" — short string printed in the Material column. Defaults to `process_type_id.name` if not set. |

### Step template input list (`fp.step.template.input`) — likely defaults

For the traveller to render a useful actual-data column, each step
template should pre-populate its input list with the right entries:

- **Cleaning / etch / desmut / zincate / acid steps**: `Actual Time
  (sec or min)` + (optional) `Actual Temperature (°F)`.
- **Plating step**: `Actual time (min)` + `Actual temperature (°F)` +
  `Plating thickness (")`.
- **Bake step**: `Time In (HH:MM)` + `Time Out (HH:MM)` + `Actual
  temperature (°F)`.
- **Receiving / racking / shipping**: `Actual Qty`.
- **Inspection (visual)**: `PASS / FAIL` selection.
- **Inspection (thickness measurement)**: `Actual thickness
  (mils)` + `PASS / FAIL`.
- **Water break test**: `PASS / FAIL` selection.
- **Rinse / dry**: no input — sign-off only.

These defaults come "out of the box" when the customer drops a
library step into a recipe — no need for them to author the input
list every time. They can override / add later.

### Job-level NEW fields

| Field | Type | Reason |
|---|---|---|
| `qty_received` | Integer | "Qty Rec." column on traveller header |
| `qty_visual_inspection_rejects` | Integer | "VIS INSP." column |
| `qty_rework` | Integer | "Rework" column |
| `special_requirements` | Text | "Special Requirements" block (long free text from customer spec) |
| `qty_at_stage` (computed One2many?) | per-step running count | NEW — would let "Qty Rec.: 5850 → 5839 → 5835" auto-render on the traveller. Computed from `fp.job.step.qty_done` chain. |

### Part catalog NEW fields

| Field | Type | Reason |
|---|---|---|
| `base_material` | Char | "6061-T6511 aluminum" — currently implicit |

### Traveller report (new QWeb template)

`fusion_plating_reports/report/report_fp_job_traveller_v2.xml` — landscape A4 multi-page:

1. **Page 1**: header + Item Information block + Process-Sheet header + first 6–8 steps.
2. **Pages 2..N**: continuation rows for the remaining steps.
3. **Last page**: Footer / final inspection / shipping rows + room for stamps / dates.

The current `report_fp_job_traveller.xml` (in `fusion_plating_jobs`,
shipped in S5/S18) is portrait and minimal. We rebuild it to match
this paper format.

### What we'll auto-capture instead of pencilling in

| Pencilled today | Auto-captured by us |
|---|---|
| Actual Qty | comes from `fp.job.qty_done` chain (already exists) |
| Actual Time | timer on `fp.job.step` (already exists, S1/S2 stuff) |
| Actual Temperature | IoT sensor reading (already exists in `fusion_iot/fusion_plating_iot/`) — ties to step's tank, snapshot saved at sign-off |
| Plating thickness | Fischerscope auto-extract (already exists in `fusion_plating_certificates/fp.thickness.reading`, S19) |
| Time In / Time Out (bake) | bake-window record (already exists, S6/S15) |
| PASS/FAIL | QC checklist (already exists in `fusion_plating_quality`, S18/S19) |
| Stamp (initials) | per-step `signoff_user_id` (already exists) |
| Date | per-step `date_finished` (already exists) |

Most of the runtime capture machinery already exists. **The gap is
making the recipe editor expose target ranges + units + per-step
input list defaults** so the traveller can render the targets next to
the actuals.

## Patterns updated after screens 16–18

18. **Paper traveller is the spec for what's authored on a step
    template.** Every column on the paper sheet maps to either:
    - an authored field on `fp.step.template` (target range, unit,
      material callout, voltage, viscosity), OR
    - a runtime-captured field on `fp.job.step` (actual time, actual
      temp, sign-off, date), OR
    - a runtime-captured input value (`fp.job.step.input.value`)
      tied to a `fp.step.template.input` definition.

19. **Step "Actual" data is multi-field per step**, not just one
    "actual" value. E.g. an etch step has Actual Time only; a
    plating step has Actual Time + Actual Temp + Plating Thickness;
    a bake has Time In + Time Out + Actual Temp. The input list per
    step template must be flexible enough to model this — which it
    already is via `input_template_ids`. We just need sane defaults
    so the customer doesn't have to author them from scratch.

20. **Target ranges (e.g. 4-6 minutes, 150-170 °F)** are first-class
    authored data. They drive: traveller print, runtime overrun
    warnings (S7), out-of-spec alerts on IoT readings (existing),
    and the operator UX cue ("you're at 7 min, target is 4-6 — log
    a deviation?"). Currently we have `estimated_duration` (single
    value) on `process.node` — needs to extend to min/max per step.

21. **Customer-spec callout** ("MID PHOS", "BAKE @ 250 DEG F FOR 1
    HOUR", "RUN EACH LOAD WITH 3 TEST PANELS…") is per-job, not
    per-step. It's the **job-header special-requirements** field
    (free text, copied from customer spec library). Already covered
    by `fusion.plating.customer.spec` model — needs to be pulled
    onto the traveller print.

22. **Multi-pass through same tank** (e.g. step 11 = A-7 Zincate,
    step 13 = A-5 Strip Zincate, step 15 = A-7 Zincate AGAIN). Our
    recipe model handles this fine — each step is its own node
    instance. Worth confirming the simple editor renders this
    visually (e.g. "Zincate" appears twice in the ordered list,
    each with its own SP-7 station tag). The screenshots from the
    customer's other system in the original brainstorm already
    showed this pattern (Primary Rinse appeared twice in the
    Selected list).

## Screenshots 19–22 — Steelhead's auto-generated CoC traveller PDF (7-page report)

These pages are the **digital output** Steelhead produces after a job
completes — a multi-page PDF traveller showing the full chain of
custody, every step transition, every captured measurement, the
operator who recorded each value, and the timestamp. This is what
gets sent to the customer with the parts. Functionally equivalent to
our own `fp.certificate` flow + the new traveller report we plan to
build.

**Critical context**: this is the OUTPUT that Steelhead generates from
its captured data. Everything on these pages is something we MUST be
able to capture + render to match feature parity. Job:
- Customer: (printed at top, e.g. cert-style header)
- Part: 2144A6201-5 OUTER CYLINDER ASSY
- Description: "ELECTROLESS NICKEL PLATING & BAKE PER LGPS 1104G & IAW
  TECHNIQUE#: QA-016-36 REV.1, PLATING THICKNESS: 0.0019",
  HYDROGEN EMBRITTLEMENT RELIEF BAKING @ 375ºF FOR 23 HOURS"
- Quantity: 1
- WO#: 620, PO#: 980806214, Date: 2025-09-23
- Specification(s): "Electroless Nickel Plating"
- Footer: "Cert Created At: 2025-09-23", page #/total, **Nadcap Accredited** logo, **ENTECH** logo

### Page 1 — Header + first 3 step transitions (no captured data yet)

Steps shown:
1. **Ready for Incoming Inspection** — Moved By: Riya Bhatt, Time: Sep 18, 2025 07:22:31 AM
2. **Ready For Plating** — Moved By: Kris Pathinather, Time: Sep 18, 2025 07:25:00 AM
3. **Soak Clean (S-3)** — Moved By: Kris Pathinather, Time: Sep 18, 2025 07:31:26 AM

**Pattern**: each step heading shows `Step Name (station code)` —
"Soak Clean (S-3)" combines the step's name with the chosen station.
Below the heading, "Part Number" and "Moved By: <user> Time:
<datetime>" are always rendered. Then if the step has captured
measurements, a sub-table follows.

### Page 2 — Step transitions with captured measurement tables

Each step that captured operator inputs renders a 4-column table:
**Name | Description | Value | Recorded By**

Sample tables:

**Soak Clean** sub-table (between page 1 step heading and page 2 next
step heading):
| Name | Description | Value | Recorded By |
|---|---|---|---|
| Soak Clean Time (5-10 min.) | (blank) | 00:05:22 | Kris Pathinather |
| Soak Clean Temp 165-195 (ºF) | (blank) | 170 | Kris Pathinather |

**ElectroClean (S-3)** sub-table:
| Name | Description | Value | Recorded By |
|---|---|---|---|
| ElectroClean Time 30-90 Seconds | (blank) | 00:00:55 | Kris Pathinather |
| ElectroClean Amperage (A) | (blank) | 280 | Kris Pathinather |
| Surface Area (FT2) | (blank) | 7 | Kris Pathinather |
| ElectroClean (SP-1) Temperature (ºF) | (blank) | 170 | Kris Pathinather |

**Water Break Free Test** sub-table (test-style measurement):
| Name | Description | Value | Recorded By |
|---|---|---|---|
| Water Break Free Test | "Perform water break test on parts as per WI 10.08. Observe parts for 30 – 60 seconds after removing from the soap rinse and observe if the production parts exhibit a water break free surface. If test fails, repeat from step Soak Clean." | PASS | Kris Pathinather |

### Page 3 — Mid-job step transitions (HCl Activation, Rinses, Plating, Porosity)

Sample tables:

**Acid Dip** sub-table (HCl Activation step — the input description
includes the WI reference):
| Name | Description | Value | Recorded By |
|---|---|---|---|
| Acid Dip Time | "Immerse parts in HCl tank for 20-40 seconds as per WI 10.07." | 00:00:30 | Kris Pathinather |

**Electroless Nickel Plating (S-10)** sub-table — KEY step, multiple
measurements:
| Name | Description | Value | Recorded By |
|---|---|---|---|
| E-Nickel Plate Temp (187-193ºF) | (blank) | 190 | Kris Pathinather |
| Final Panel Thickness | (blank) | 0.0248 | Kris Pathinather |
| Actual Thickness (") | "Immerse parts with test panels in E-Nickel tank as per WI 10.07." | 0.0018 | Kris Pathinather |

**Porosity Test** — minimal heading-only entry with one inline
"Results: PASS" text under the step name (instead of a table).

### Pages 4–5 — More transitions (DeRacking, Ready for De-Masking, De-Masking, Ready for bake, Bake)

Heading-only step transitions (no captured data table):
- **DeRacking** — Moved By: Ryan Persaud, Time: Sep 18, 2025 02:16:45 PM
- **Ready for De-Masking** — Moved By: Ryan Persaud, Time: Sep 18, 2025 02:20 PM
- **De-Masking** — Moved By: Ryan Persaud, Time: Sep 18, 2025 02:21:05 PM
- **Ready for bake** — Moved By: Ryan Persaud, Time: Sep 18, 2025 02:44:52 PM
- **Bake** — Moved By: Ryan Persaud, Time: Sep 18, 2025 2:45:27 PM

**Pattern**: gating / no-input steps still render a heading + "Moved
By + Time" but no measurement table. They contribute to the
chain-of-custody trail without measurements.

### Page 6/7 — Bake captured data + Adhesion Test + EN Final Inspection (final pass/fail)

**Bake** sub-table:
| Name | Description | Value | Recorded By |
|---|---|---|---|
| Hydrogen Embrittlement Time | (blank) | 23:48:19 | Ryan Persaud |
| Hydrogen Embrittlement Relief Temp (ºF) | (blank) | 375 | Ryan Persaud |

**Post Plate Inspection** (heading-only, gating)
- Moved By: Brett Kinzett, Time: Sep 22, 2025 08:22:01 AM

**Final EN inspection** sub-table — pass/fail summary:
| Name | Description | Value | Recorded By |
|---|---|---|---|
| Adhesion Test | (blank) | PASS | Brett Kinzett |
| EN Final Inspection | (blank) | PASS | Brett Kinzett |

## What this PDF tells us (key insights)

1. **Steelhead's CoC traveller is a chronological audit log**, NOT a
   recipe traveller. It walks the actual transition history (not the
   authored recipe order) and prints captured data per step. Useful
   for AS9100 / Nadcap audit because it shows EXACTLY what happened,
   in time order, by whom.

2. **Every captured input has 4 attributes**:
   - **Name** (e.g. "Soak Clean Time (5-10 min.)") — the input
     definition's display name. The target range is **embedded in
     the name** ("(5-10 min.)") rather than a separate column. This
     is a Steelhead UX choice — we should do better and put min/max
     in their own columns so the auditor can see authored vs actual
     side-by-side.
   - **Description** (long-form WI reference) — pulled from the
     step's `description` (Html) field. Sometimes blank. Usually
     populated for inspection-type steps (where the operator needs
     the procedure text), not for routine measurements.
   - **Value** (the recorded value) — type varies: time HH:MM:SS,
     number (with implicit unit), PASS/FAIL, etc.
   - **Recorded By** — operator's full name.

3. **Time values are always in HH:MM:SS** even for sub-minute
   readings ("00:00:55"). Steelhead uses one consistent time
   format. We should do the same on the report — it's noise for
   the operator entering the data ("how do I type 55 seconds?")
   but clean on the report.

4. **Step heading has the station baked in** — "Soak Clean (S-3)",
   "Electroless Nickel Plating (S-10)". This means our report needs
   to render the **station code** chosen at runtime, not just the
   step name. Already in our model (`fp.job.step.tank_id.code`).

5. **Sub-tables only appear when there's captured data**. Heading-
   only steps (Ready For X, gating nodes, racking moves) just show
   the chain-of-custody line. Our report should follow the same
   pattern — clean PDF with no empty tables.

6. **Same input name with different runtime captures** — "Rinse
   (S-11 / S-13)" is a single transition heading covering BOTH a
   rinse pass through tank S-11 AND tank S-13 (two physical rinse
   tanks operators dipped through in sequence). Steelhead collapses
   them into one heading. Our model has each as a separate step;
   we'd render two headings unless we add a "merge consecutive
   identical steps" report option. **Decision later** — for now,
   keep them separate.

7. **Multi-day jobs are normal**. The bake spans 23h 48min, post-
   plate inspection happens days later (Sep 19 / Sep 22). The
   traveller knows because each transition has its own timestamp.
   Our chain-of-custody log already captures this.

8. **Two operators on the same job** — Riya Bhatt does receiving,
   Kris Pathinather does the wet-line, Ryan Persaud handles
   masking/bake, Brett Kinzett does final inspection. The "Moved By"
   field changes per step, reflecting hand-offs. Already supported
   by our model.

9. **Footer branding** — "Nadcap Accredited (Administered by PRI)"
   logo + ENTECH company logo. Per-page. Page numbering "n/total".
   Plus "Cert Created At: <date>". Our existing `fp.certificate`
   PDF flow can render this footer; we just need to add the Nadcap
   logo asset + company logo configurable.

## What this means for our recipe editor + traveller report

### Step template input list — render targets in their OWN columns

Steelhead embeds "(5-10 min.)" in the input name. We should split
this into two authored fields:

| Field | Type | Notes |
|---|---|---|
| `target_min` | Float | Lower bound (e.g. 5) |
| `target_max` | Float | Upper bound (e.g. 10) |
| `target_unit` | Char | "min" / "ºF" / "A" / "FT2" / "in" / "%" / "(blank for pass-fail)" |
| `display_label` | Char (compute) | "Soak Clean Time" or "Soak Clean Temp" — clean name without the embedded range |

Report renders 5 columns per measurement table:
**Name** | **Description** | **Target** | **Actual** | **Recorded By**

The Target column shows "5-10 min" (or "165-195 ºF" or "30-90 sec"
auto-formatted from the three new fields).

### Job traveller report = chronological audit, NOT step-order

Build the report to walk `fp.job.step` records ordered by
`date_started` (or `date_finished`), not by `sequence`. This matches
Steelhead's chain-of-custody ordering and is what auditors expect.

### Heading format for each step transition

`<Step Name> (<Tank code>)` — already supported by our model. No
gap.

### Time format

Use HH:MM:SS for all duration values on the report, even sub-minute.
On entry (tablet input), accept "55 sec" or "00:00:55" — convert to
canonical HH:MM:SS for storage.

### Pass/Fail value rendering

For boolean inputs, render "PASS" / "FAIL" in caps. Already
straightforward.

### Step description field carries the WI reference

Already supported by our `fp.step.template.description` Html field.
The report just needs to render it stripped of HTML tags inline
(plain-text in the table cell).

### Each operator's name comes from `res.users.name`

Our existing pattern. No gap.

## Patterns updated after screens 19–22

23. **The CoC PDF is a chronological audit, not a recipe-order
    print.** Different report from the operator-facing traveller
    (which prints in recipe order so the operator knows what's
    next). We need both:
    - **Operator traveller** (recipe-order, paper-style, A4
      landscape, blank actual columns) — what Riya prints when
      Carlos starts a job.
    - **Customer CoC** (chronological, captured-data, formal,
      portrait, branded) — what gets attached to the cert and sent
      to the customer.
    Today we ship the CoC via `fp.certificate` (S18/S19). Need to
    extend it to walk the chain-of-custody and render measurement
    sub-tables.

24. **Target ranges should be authored as min/max + unit, not
    embedded in the name string.** Steelhead embeds them which is
    a UX bug — auditors can't filter by "all jobs where Soak Clean
    Temp was out of range" because the range only exists as text.
    By splitting into structured fields, we get free queryability
    AND can colour-code the value cell on the report
    (green if in range, red if not).

25. **Step description vs input description**: Steelhead uses the
    "Description" column on the input table to show the WI
    reference. That's the **step-level** description repeated on
    the input row. Our model already has `description` on the step
    template — we just render it once at the input table header
    instead of per-row. Saves report space.

26. **Inputs can be multi-valued per step** — ElectroClean has 4
    inputs, E-Nickel Plate has 3, Soak Clean has 2. Our
    `input_template_ids` One2many already handles this. Confirmed
    by real data.

27. **"PASS" entries can be standalone (no table)** — Porosity Test
    just prints "Results: PASS" inline, no input table. This is a
    Steelhead simplification. We should normalize: every step with
    a captured input renders a table, even if it's a single
    pass/fail row. Cleaner audit trail.

28. **Move-By trail is the operator chain-of-custody. CRITICAL for
    aerospace / Nadcap.** Our existing `fp.job.step.signoff_user_id`
    + `date_finished` already provides this. The report just walks
    them in time order.

## Screenshot 23 — Page 7/7 of CoC: Final Inspection / Packaging + Ready For Shipping

Step transitions on this page:
- **Ready For Final Inspection / Packaging** — Moved By: Brett Kinzett, Sep 22, 2025 08:42:22 AM (heading-only, gating)
- **Final Inspection / Packaging** — Moved By: Brett Kinzett, Sep 23, 2025 11:39:47 AM (heading + measurement table)
- **Ready For Shipping** — Moved By: Brett Kinzett, Sep 24, 2025 01:45:49 PM (heading-only, gating)
- (unnamed transitions) — Sep 24, 2025 02:03:29 PM and 02:06:16 PM

**Final Inspection / Packaging** sub-table:
| Name | Description | Value | Recorded By |
|---|---|---|---|
| Outgoing Part Count | (blank) | PASS | Brett Kinzett |
| Thickness Test Pass / Fail | (blank) | PASS | Brett Kinzett |
| Qty Accepted | (blank) | 1 | Brett Kinzett |
| Qty Rejected | (blank) | 0 | Brett Kinzett |
| Actual Coating Thickness - Final | (blank) | 0.0018 | Brett Kinzett |

Notes:
- "Outgoing Part Count" with value "PASS" is odd — looks like Steelhead conflated a count check with a pass/fail input. Our model should keep them separate (`Qty Accepted` integer + `Outgoing Part Count Verified` boolean).
- "Qty Accepted" + "Qty Rejected" are the **final disposition split** at packaging time. Non-negotiable for AS9100 shipment audit.
- "Actual Coating Thickness - Final" duplicates the mid-job thickness reading captured at E-Nickel Plate. Steelhead re-takes it at final inspection as a sanity-check before sign-off.
- The two unnamed transition rows at the bottom are likely "Shipped" / "Closed" gating moves whose headings got cut off the screenshot.

## Screenshot 24 — Cert sign-off footer (last block on the CoC)

Two side-by-side panels:

**Left panel — "Certified By:"**
- Embedded signature image (handwritten "K Pathinathn" — Kris Pathinather signed)
- Printed name below: "Name: Kris Pathinather"

**Right panel — "Certification Statement: Ref. WO# 620"** (top half) + **"Other Comments:"** (bottom half), both blank-but-bordered for handwritten or template-rendered cert language.

This is the **certificate of conformance attestation block** — a
named individual takes legal responsibility for the cert. Required
for Nadcap, AS9100, CGP. Already supported by our existing
`fp.certificate.signoff_user_id` + signature image (S18). Just need
to surface the signed image + the printed name + the cert statement
in our PDF footer.

The "Certification Statement" body in our existing CoC is already
authored on the certificate template — Steelhead leaves it blank in
this screenshot suggesting the full statement was on a different
page. We DO render it (boilerplate "We certify that the parts
conform to specification…" language).

## Patterns updated after screens 23–24

29. **Final inspection captures the disposition split** — Qty
    Accepted / Qty Rejected as integer fields at the last QC step.
    These should appear as `input_template_ids` on a "Final
    Inspection" library step (sane defaults). Plus a redundant
    "final coating thickness" reading. We model these as standard
    operation-measurement inputs.

30. **Certificate sign-off block is a 2-column footer**:
    left = signature image + name, right = cert statement + other
    comments. Already supported by `fp.certificate` (S18). Just
    confirm our PDF template arranges them this way.

31. **CoC renders gating "Shipped / Closed" transitions** as
    chain-of-custody entries with no measurement tables — same
    treatment as "Ready For X" gating nodes.

## Screenshot inventory closed (24 screenshots logged total)

All Steelhead screens captured. The data model + UI implications
have been folded into the Pending-Questions section below. We can
now resume the brainstorm with the full picture in hand.

## Pending questions to ask user once screenshots are done

- What other Transfer Type values exist? (Hold / Scrap / Rework / Return / Splits?)
- Does Billed Labor show up on every screen or only certain ones?
- Are From Station / To Station always editable, or read-only when single-station nodes?
- What does the camera icon save against — the part record, the transition log, or the job?
- Is "Number of Customer WOs" a free-text count or a multi-select of existing customer POs?
- Is there a way to **split** a move (e.g. send 40 to next step, hold 9)? Steelhead's Part Count selector hints at it.