docs(CLAUDE.md): note Windows-side browser preview limitation

User is on Mac via Tailscale into this Windows host. Browser previews
bound to Windows localhost are unreachable from the Mac browser. Default
to text-based design discussion on this host instead of spinning up the
brainstorming visual companion. Has bitten three times now.

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

fusion_plating/CLAUDE.md

@@ -197,6 +197,53 @@ The kiosk login (`fp_tablet_kiosk@enplating.local` at creation time) is a `noupd
 
 **Audit log** (`fp.tablet.session.event`): append-only model with Owner-only read ACL + Python `write`/`unlink` overrides (only the force-lock cron + retention crons bypass via context flags `fp_tablet_audit_admin_write` / `fp_tablet_audit_admin_purge`). Captures every unlock / failed_unlock / manual_lock / idle_lock / ceiling_lock / force_lock / admin_reset event with sha256(session sid), ip, user-agent, acting_uid, duration. View under Plating → Configuration → Tablet Audit Log (Owner-only menu). Per-user 7-day count smart button on `res.users` form.
 
+## Mail templates: `email_from` MUST match the active mail server's `from_filter` (or M365 greylists)
+Entech relays through Gmail OAuth as `orders@enplating.ca` (the mail server's `from_filter`). When a `mail.template` renders `email_from` to ANY other address (e.g. `{{ object.company_id.email }}` → `sales@enplating.ca`), Odoo logs `WARNING ir_mail_server: No mail server matches the from_filter, using <X> as fallback` and ships the message anyway — but the message has misaligned authentication:
+- SMTP-AUTH = `orders@enplating.ca`
+- `From:` header = `sales@enplating.ca`
+- DKIM signs the `mail-from` domain, NOT the `From:` domain
+- DMARC alignment check at recipient FAILS
+
+Recipients on Microsoft 365 (like nexasystems.ca) react to DMARC fail by **greylisting for 5–15 minutes** before delivery — or routing straight to junk. The user feels this as "the email takes a while" or "I never got it."
+
+**Rule:** every mail.template's `email_from` must resolve to an address inside the mail server's `from_filter`. Easiest pattern — add a helper on the template's target model that picks the active mail server's `from_filter` dynamically, then reference it from the template:
+
+```xml
+<field name="email_from">{{ object._fp_resolve_from_header() }}</field>
+<field name="reply_to">{{ object._fp_resolve_from_header() }}</field>
+```
+
+`res.users._fp_resolve_from_header()` (in `fusion_plating_shopfloor/models/res_users.py`) is the reference implementation — sudo-search `ir.mail_server`, prefer `from_filter` (if it's an `addr@domain` form, not a wildcard), then `smtp_user`, then fall back to `company.email`. Reuse it on other models by either inheriting `res.users`-style helpers or duplicating the same lookup pattern (the lookup is 6 lines).
+
+**Also avoid emojis in subject lines for cross-provider mail.** M365's spam classifier bumps emoji-containing subjects ~1.5–2 points; combined with cross-provider routing it pushes mail to junk or delay. PIN-reset codes / invoice notifications / shipment alerts — keep the subject plain.
+
+If you must use a different From for branding reasons, the proper fix is multi-step (add the From address as a verified "Send as" alias on the Gmail account, ensure SPF lists Gmail's IPs for that domain, set up DKIM signing for the From domain). That's a config-side change, not a code change — flag it for the admin instead of working around it in the template.
+
+## `send_mail(force_send=False)` is broken for interactive flows on entech
+Entech's `Mail: Email Queue Manager` cron (id 3) runs every **1 hour**, not the per-minute default that vanilla Odoo demos use. A controller that queues an email with `force_send=False` for an interactive flow (PIN reset code, password reset, "click here for a one-time link", any flow where the user is staring at the screen waiting for the email) will sit in the outbox for up to 60 minutes. The mail row stays at `state='outgoing'`, no error is logged, the user thinks it never sent. Bit us 2026-05-25 on tablet PIN reset — codes 2253 and 7780 sat queued for 36+ minutes before we noticed.
+
+**Rule:** for any interactive email flow, use `force_send=True` in `template.send_mail(res_id, force_send=True)`. The synchronous send adds ~1s of latency but the user gets the email before they can tab to their inbox. The cron is for batch / fire-and-forget notifications where the user isn't watching (NCR escalations, daily digests, etc.).
+
+**Don't change the cron interval to "fix" this** — the hourly schedule is intentional on entech (Gmail SMTP daily quota mitigation + reduced relay overhead for the 95% of notifications that aren't time-sensitive). Per-flow `force_send=True` is the right knob.
+
+When `force_send=True`, errors propagate (Gmail SMTP refusal, from_filter mismatch, etc.). Wrap with try/except and log, but consider returning a user-visible `{ok: false, error: 'email_send_failed'}` so the operator knows to retry or ask the manager — better than silent success that never arrives.
+
+## Brainstorming visual previews — the user is on Mac, this Windows host can't show them
+The user runs Claude Code from a **Mac** via Tailscale into this Windows host (`Home`). Any browser preview server bound to `localhost` on the Windows side (`http://localhost:8765`, the brainstorm script's preview server, `python -m http.server`, etc.) is unreachable from the Mac browser. Has bitten us three times now — Quality Dashboard redesign (2026-05-23), and twice during the Express Orders brainstorm (2026-05-25).
+
+**Rule:** when running on this Windows host, do NOT spin up the `superpowers:brainstorming` visual companion (or any other browser-preview-style server) unless the user explicitly asks for it. Default to text-based design discussion — ASCII tables, structured lists, reference to existing files. The Excel mockup or screenshot the user provides is plenty of reference. If a visual companion IS requested anyway, the only path that works is binding to the Windows host's Tailscale IP (`100.87.38.59` on `Home`) — but even that requires firewall coordination and isn't worth the friction.
+
+**Mac-side sessions:** localhost previews work fine; this rule doesn't apply. The user typically switches to a native Mac Claude Code session for visual-heavy work.
+
+## Deleting an OWL component — also audit the localStorage / shared state it wrote
+When you delete an OWL component (delete .js/.xml/.scss + drop manifest entries), the component's code is gone, but **any localStorage keys it wrote remain on every browser that ever rendered it**. If another live component reads those keys (with the deleted component's name in the key), the stale value still feeds into requests.
+
+Concrete failure 2026-05-25: deleted `fp_shopfloor_landing` (which used `localStorage.fp_landing_station_id` to pair the tablet to a station). `tablet_lock.js` was reading the same key to scope the lock-screen tile query (`/fp/tablet/tiles?station_id=…`). After the delete, every tablet that had ever paired via the old component kept sending that stale id; the kiosk session can't read `fusion.plating.shopfloor.station` (locked-down ACL), so the endpoint hit AccessError and returned an empty tile list. The lock screen rendered "no operators." Took us ten minutes of "but my code didn't break anything" before finding it.
+
+**Mandatory grep before deleting an OWL component:** `grep -rn '<key-the-component-wrote>' --include='*.js' static/src/`. For every hit in OTHER files: decide (a) read a different source, (b) clear-on-read and read a different source, or (c) keep the key and add a server-side endpoint that writes it. Also clear the key from the surviving components on next load so existing tablets self-heal — don't make the user clear browser storage.
+
+Same audit applies to: window globals the component attached (`window.fpFoo = …`), CustomEvents it dispatched, IndexedDB stores it created, ServiceWorker registrations, BroadcastChannel topics.
+
 ## Removing menus/records — Odoo does NOT auto-delete orphans
 Deleting a `<menuitem>` (or any `<record>`) from a data XML file does NOT remove the corresponding database row. The XML loader only updates records it sees; orphans persist in `ir.ui.menu` / `ir.model.data` until you delete them explicitly. Symptom: the menu still appears in the UI after `-u`. Fix — add a `<delete>` directive in a data file with `noupdate="0"`:
 ```xml
@@ -204,6 +251,8 @@ Deleting a `<menuitem>` (or any `<record>`) from a data XML file does NOT remove
 ```
 Caught 2026-05-22 when the Phase 3 Plant Overview menu kept showing alongside the new Workstation menu after deploy.
 
+**`<delete>` is single-use — remove it after the deploy that fires it.** Subsequent `-u` runs against a missing xmlid raise `ValueError: External ID not found in the system: <module>.<xmlid>` because the XML loader evaluates the `id="..."` ref at parse time. The error is non-fatal (load continues), but it bloats the log on every restart and obscures real failures. Workflow: ship the `<delete>` directive in deploy N, then DELETE the directive itself in deploy N+1 (or replace with a comment noting when the row was removed). The `<delete>` is not idempotent against an already-missing row. Caught 2026-05-25 when `<delete model="ir.ui.menu" id="fusion_plating_shopfloor.menu_fp_shopfloor_plant_overview"/>` in legacy_menu_hide.xml had been firing this error for weeks after the menu was already gone.
+
 ## Odoo 19 ir.cron — `numbercall` and `doall` are gone
 The legacy `numbercall=-1` (run-forever) and `doall=False` (catch-up-missed) fields were removed from `ir.cron` in Odoo 19. Including them in `<record model="ir.cron">` data XML produces:
 ```
@@ -345,7 +394,7 @@ Use only: `name`, `model_id`, `state`, `code` (or `function`/`model`), `interval
 18. **Portal list pages — no pagination, 500-record cap**: All FP portal list routes (quote requests, jobs, certifications, deliveries) load up to 500 records and rely on client-side JS filtering. Do NOT re-add `portal_pager` to these routes. The `fp_portal_list_controls` macro + `fp_portal_list_search.js` handle filtering, counting, and the sort dropdown. Hidden `<td class="d-none">` cells inside each row carry extra searchable text (part number, customer PO, contact) that isn't displayed but is matched by the JS.
 19. **QWeb `t-value` is Python, not Jinja**: `t-value="orders|length"` does NOT call a filter — Python parses `|` as bitwise/recordset OR, so on a non-empty recordset it tries `recordset | length_var` and raises `TypeError: unsupported operand types in: sale.order(…) | None` (when `length` is undefined) or returns a merged recordset (when `length` happens to be another recordset). Use `len(orders)` or `bool(orders)` or `(orders and orders[0]) or False` — explicit Python. Same trap applies to `|default`, `|first`, `|join`, etc. — none of these Jinja filters exist in QWeb. Bit us 2026-05-18 on `fp_sale_order_portal.xml` injecting `result_total` into the list-controls macro.
 20. **OWL templates expose `Math` but NOT `String` / `Number` / `Array` / `Object` / `Boolean` / `JSON` / `parseInt` / `parseFloat`**: writing `t-on-click="() => this._press(String(d))"` (or similar coercion inside any template expression) throws `Uncaught TypeError: v2 is not a function` at click time — `v2` is OWL's compiled reference to a global that doesn't exist in template scope. The click handler dies before its body runs, so the bug looks like "nothing happens when I press" (no error in the UI, only DevTools shows the trace). **Fixes, in order of preference**: (a) eliminate the coercion entirely — store data in the right type up front, e.g. `t-foreach="['1','2','3']"` instead of `[1,2,3]` so `d` is already a string. (b) Use a JS-side coercion: pass the raw value to the handler and call `String(digit)` inside the component method. (c) Use a pure-expression workaround like string concatenation: `'' + d` does work because `+` is an operator, not a function. **Do NOT try to monkey-patch `String` onto the component (e.g. `this.String = String`) or onto `env` — leaks the global into every component and is fragile across OWL upgrades.** Bit us 2026-05-23 on `pin_pad.xml` — operators couldn't tap PIN digits at all because the click handler died on `String(d)`; the SCSS, reactivity, and `_press` method were all fine, the template scope was the entire bug. Same trap applies to OWL templates anywhere in the codebase: `move_parts_dialog.xml`, `manager_dashboard.xml`, `fp_record_inputs_dialog.xml`, etc. — grep all `t-on-click`, `t-att-*`, and `t-out` expressions for `String(`, `Number(`, `Array(`, `parseInt(`, `parseFloat(`, `JSON.` before merging.
-21. **`ir.actions.act_window_close` is a no-op when the current action was opened with `target: "current"`**: replacing the current action wipes the breadcrumb backstack, so there's nothing to close back to. The user clicks "Back" and nothing happens (no error, no navigation). This bites every OWL client-action surface that calls another client action via `doAction({..., target: "current"})` — the destination has no way to return to the source. **Fix pattern for "Back" buttons in OWL client actions**: navigate EXPLICITLY to the landing/parent action by tag, e.g. `this.action.doAction({ type: "ir.actions.client", tag: "fp_shopfloor_landing", target: "current" })` — works regardless of how the action was reached (kanban tap, QR scan, smart button, direct URL). **Do NOT rely on `act_window_close`, `history.back()`, or `this.env.config.breadcrumbs`** — all three are unreliable across navigation paths. Bit us 2026-05-23 on the Job Workspace Back button after the kanban opened the workspace with `target: "current"`. The same pattern applies to every other "Back" button in shopfloor / manager / portal OWL surfaces — explicit destination via `tag:` is the only robust answer.
+21. **`ir.actions.act_window_close` is a no-op when the current action was opened with `target: "current"`**: replacing the current action wipes the breadcrumb backstack, so there's nothing to close back to. The user clicks "Back" and nothing happens (no error, no navigation). This bites every OWL client-action surface that calls another client action via `doAction({..., target: "current"})` — the destination has no way to return to the source. **Fix pattern for "Back" buttons in OWL client actions**: navigate EXPLICITLY to the landing/parent action by tag, e.g. `this.action.doAction({ type: "ir.actions.client", tag: "fp_plant_kanban", target: "current" })` — works regardless of how the action was reached (kanban tap, QR scan, smart button, direct URL). **Do NOT rely on `act_window_close`, `history.back()`, or `this.env.config.breadcrumbs`** — all three are unreliable across navigation paths. Bit us 2026-05-23 on the Job Workspace Back button after the kanban opened the workspace with `target: "current"`. The same pattern applies to every other "Back" button in shopfloor / manager / portal OWL surfaces — explicit destination via `tag:` is the only robust answer.
 22. **Odoo 19 HTML fields auto-wrap plain-string writes**: writing `co.report_header = 'Plating & Finishing'` to an HTML field (like `res.company.report_header`, `res.partner.comment`, `mail.template.body_html`, `product.template.description_sale`) stores `<p>Plating &amp; Finishing</p>` after Odoo's HTML sanitizer runs. Equality tests against the raw input string FAIL (`payload['tagline'] != 'Plating & Finishing'`). **Three implications**: (a) **In tests**, don't `assertEqual` against the literal string you wrote — strip tags first, OR write the wrapped form (`<p>Plating & Finishing</p>`), OR write an explicit `Markup('<p>...</p>')` so the round-trip stays stable. (b) **In display code**, render HTML fields with `t-out` (QWeb) or `markup(...)` (OWL) — `t-esc` would render the literal `<p>` tags as text. (c) **In comparison logic**, normalize first: `from markupsafe import escape; escape(input_str)` produces the same shape the field stores. Bit us 2026-05-24 testing the lock-screen tagline source (`_lock_company_payload` reads `res.company.report_header`); the test that wrote a plain string and asserted equality failed because the value came back wrapped. The fix was to delete the brittle equality test — the helper's responsibility is just "use the field's value when present, else fall back," which is covered by the empty-field test. Generalizes to ANY HTML-typed Odoo field. Distinct from the `mail.template.body_html is Markup + jsonb` gotcha noted earlier in this file — that's about Markup objects vs strings; this is about the sanitizer wrapping plain strings on write.
 23. **`res.users.group_ids` vs `all_group_ids` for domain filters**: in Odoo 19, `res.users` carries TWO M2M-to-`res.groups` fields and they have different membership semantics. `group_ids` is the user's DIRECTLY-assigned groups (what the user record literally wrote). `all_group_ids` is the TRANSITIVE set — direct groups PLUS every group implied via `implied_ids` chains. **For domain filters on user pickers** (e.g. "show users who can act as a Quality Manager"), ALWAYS use `all_group_ids`, never `group_ids`. An Owner user only carries `group_fp_owner` directly; the QM capability comes via `implied_ids → group_fp_quality_manager`, so a `domain="[('group_ids', 'in', [ref('...quality_manager')])]"` excludes Owners and the picker looks empty. Use `domain="[('all_group_ids', 'in', [ref('...quality_manager'), ref('...owner')])]"` instead. Compute helpers (`@api.depends('group_ids')`) and write vals (`{'group_ids': [(4, gid)]}`) still use `group_ids` because those operate on direct assignments — only domain filters need the transitive set. Bit us 2026-05-24 on the CGP DO + Nadcap Authority pickers on `res.company`. Same gotcha applies to ANY domain that needs "does this user effectively have role X" semantics across user-facing pickers, ACL rules, server actions, and search filters.
 24. **`env.get('model.name')` returns an EMPTY recordset (falsy), NOT None — never use it as a presence check**: `self.env.get('fp.notification.template')` returns `fp.notification.template()` (empty recordset) when the model IS registered. Empty recordsets are falsy in Python, so `if not Template: return` silently exits even when the model exists and the call should proceed. Same gotcha for `env.get('any.model')` — they all return empty recordsets. **Fix: use the membership check first, then index:**
@@ -502,7 +551,7 @@ Spec: [docs/superpowers/specs/2026-05-22-shopfloor-tablet-redesign-design.md](do
 Plan: [docs/superpowers/plans/2026-05-22-shopfloor-tablet-redesign-plan.md](docs/superpowers/plans/2026-05-22-shopfloor-tablet-redesign-plan.md)
 
 **Three OWL client actions** (registered under `registry.category("actions")`):
-- `fp_shopfloor_landing` — Workstation kanban entry. Station-scoped or All-Plant mode toggle. Tap a card → JobWorkspace. Replaces the legacy `fp_shopfloor_tablet` and folds in `fp_plant_overview`.
+- `fp_plant_kanban` — sole Shop Floor surface as of 2026-05-25. One card per `fp.job` grouped into 9 fixed columns. Inline QR scanner (camera + wedge text drawer) + station pairing via `/fp/landing/pair_work_centre`. Tap a card → JobWorkspace. (The legacy `fp_shopfloor_landing` component was deleted entirely on 2026-05-25 — its inline QR feature was ported here. The earlier `fp_shopfloor_tablet` and `fp_plant_overview` xmlids still exist but their `tag` re-points at `fp_plant_kanban` for bookmark back-compat.)
 - `fp_job_workspace` — Full-screen single-WO surface. Sticky header (WO #, customer, qty, workflow chip), sticky 9-stage workflow bar, step list with GateViz blockers, side panel (spec/attachments/chatter), sticky action rail (Hold/Note/Milestone). Opens from kanban tap, smart button, QR scan, or manager card tap.
 - `fp_manager_dashboard` — Manager Desk with 4 sibling tabs: **Workflow Funnel** (default), **Approval Inbox**, **Plant Board** (existing 3-column), **At-Risk** (trending late + hold reasons + bottleneck heatmap).
 
@@ -540,7 +589,12 @@ Plan: [docs/superpowers/plans/2026-05-22-shopfloor-tablet-redesign-plan.md](docs
 **Deprecated but still live** (cleanup is Phase 5):
 - OWL components: `fp_shopfloor_tablet`, `fp_plant_overview` — registered but no menu points at them
 - Endpoints: `/fp/shopfloor/tablet_overview`, `plant_overview`, `queue` — marked DEPRECATED with INFO log lines, bodies intact for back-compat
-- `/fp/shopfloor/plant_overview/move_card` is **NOT** deprecated — the new Landing component uses it for drag-and-drop
+- `/fp/shopfloor/plant_overview/move_card` is **NOT** deprecated — the new plant kanban uses it for drag-and-drop
+
+**Retired entirely 2026-05-25** (do NOT re-introduce):
+- OWL component `fp_shopfloor_landing` + its JS / XML / SCSS files — deleted. The inline QR scanner (text/wedge drawer + camera component) was ported into `plant_kanban`. The landing resolver always returns `action_fp_plant_kanban` for technicians + shop managers regardless of the orphaned `fusion_plating_shopfloor.layout` ir.config_parameter.
+- The `/fp/landing/kanban` endpoint is no longer used by any live client (was only consumed by `fp_shopfloor_landing`). The new endpoint is `/fp/landing/plant_kanban`. Don't accidentally bind a new client to the old one.
+- Station pairing via `localStorage[fp_landing_station_id]` is gone — pairing now writes `res.users.paired_work_centre_ids` server-side via the new `/fp/landing/pair_work_centre` endpoint, and the kanban reads it back via `request.env.user.paired_work_centre_ids[:1]`. Per-tablet localStorage pairing won't survive a browser cache wipe; per-user server-side pairing does.
 
 **Old patterns to avoid:**
 - Don't read `fp.job.name` for display — use `display_wo_name` everywhere on tablet/dashboard
@@ -550,11 +604,13 @@ Plan: [docs/superpowers/plans/2026-05-22-shopfloor-tablet-redesign-plan.md](docs
 
 ## Shop Floor — Plant View kanban (2026-05-23 redesign)
 
-**Default Shop Floor surface** for new installs (gated by feature flag
-`ir.config_parameter['fusion_plating_shopfloor.layout']`, values `legacy`
-or `v2`). Legacy per-step kanban (`fp_shopfloor_landing`) remains
-accessible by flipping the flag back to `legacy` in Settings → Fusion
-Plating.
+**Sole Shop Floor surface** for every install as of 2026-05-25. The
+legacy per-step kanban (`fp_shopfloor_landing`) was deleted the same
+day, after porting its inline QR scanner into plant_kanban. The
+`ir.config_parameter['fusion_plating_shopfloor.layout']` flag is now
+orphaned — flipping it has no effect on the landing surface. The
+setting UI stays for one release cycle so it can be ripped out in a
+separate sweep without breaking migrations.
 
 **Why redesign:** the per-step kanban produced one card per recipe step
 per column, so a 14-step recipe spawned 9+ cards for ONE job across the