Eryxon Flow

## Problem The operator terminal needs to be more user-friendly and guide operators through their work. ## Proposed solution Cells in the operator terminal should have: Custom colors mapped to cell state (pending/active/done/blocked), type (scan/cut/bend/weld/QC), and priority (normal/rush) Per-cell operation instructions displayed contextually to guide operators through each step Example: a scan cell might show 'Scan the QR code on the traveler — align barcode in viewfinder' ## Scope UX design for color system instruction display Engineering implementation in the operator terminal UI Tracking: Linear ERY-234

Customer problem: simple averages hide setup time and produce weak quoting data. We're considering a better way to separate setup time from per-piece cycle time so quote feedback and production learning are more trustworthy. This is especially relevant for shops where setup-heavy work distorts simple averages.

Customer problem: operators need a quick way to leave context for the next shift without falling back to paper notes or side conversations. We're considering a lightweight work-order remark field for shift handoff and operator notes. The goal is to make it easier to pass along context without creating a heavy messaging system inside the product.

Customer problem: supervisors need a faster way to see progress, bottlenecks, and work-at-risk without chasing updates across the floor. We're considering a rolled-up production view for managers who need job progress, bottleneck visibility, and exception awareness in one place. The aim is to reduce manual status chasing while keeping the floor and management views aligned.

Customer problem: operators still rely on USB sticks or shared folders to move NC programs to machines. We're considering a direct DNC handoff path so NC files can move from work orders to machines without USB sticks or ad hoc network-share workflows. This would target a common last-mile problem on the shop floor.

Customer problem: operators lose trust quickly when login, scan, or launch behavior differs between native, PWA, and browser paths or when plant connectivity is inconsistent. We're improving how scan, login, and operator entry points behave across native apps, the installable PWA, and browser fallback paths. The goal is simple: no guesswork for operators, and fewer rollout surprises in real plants with inconsistent connectivity.

We already have early planning and ERP groundwork in place. The next question is which production-ready connector path matters most: deeper Odoo support, more planning coverage, or a broader standard connector package that reduces rollout friction for non-custom deployments.

We're expanding Eryxon Flow beyond the browser with guided native iPhone/iPad and Android paths plus an installable PWA. The goal is a predictable touch-first operator experience across the devices metalworking teams already use, without changing the core backend or rollout model.