Jobs home filing: customer = the master file, workflow = derived queues

kerfmaster pin list · UI / workflow decisions

rulingA decision by Aristide or Jordan. True because it was decided; it can be superseded, but it cannot be stale.

Content last changed 2026-09-02 — computed from the item itself, not typed.

Ruled 2026-09-02 (Jordan dictating with Aristide beside him). Born from the real pain: NC files archive under a bare program number — 'the link to the customer is officially severed... I find myself recognizing the shape, but have no idea what the client name was.'

The model

• Customer is the MASTER FILE. Every job binds to a customer-registry entry (pick-from-registry, never free-typed per job, so one client can never split into two folders). All client data in one spot; a program number is an INDEX into it, never a filing home — searching the number lands on the customer/job/version it belongs to, in either direction.
• Who adds customers: sales primary; in a small shop with no sales/operator split anyone may — the setup wizard's flow answer shapes it. Flexibility, not a limitation.
• Structure must not limit the client's base workflow — numbers-based, hyphenated text, date-based, hybrid or free-text styles all sit on the same registry + folders.
• WORKFLOW is the second axis (Gmail model): queues (New / Quoting / Quoted awaiting approval / Production prep / Ready to cut / Done) DERIVED automatically from the job's own stage statuses — the job document is already the workflow state, nobody files anything by hand. Jordan: build one really well and make a case for it, but let shops do their thing — queues renamable, manual flags a shop-defined list (arrays), flags recorded like any override.
• End of the line = G-code generated. Whether it's cut is the shop's business.
• Order reference is FREE TEXT, first-class: not all clients run POs — the client relationship dictates who may put work into production; sometimes it's 'Jim said run.' A PO is one shape of it. It's a search key and a rule trigger; overlapping part numbers across 'packages' land as new jobs under the same customer keyed by their reference.
• Rev-serious customers ride the versioning chain (job-versioning ruling); packages with overlapping part #/file names become new jobs in the customer's folder.
• Reorder fast path: a reorder comes in → search the number or browse the customer → grab the delivered version → push to production again with the new reference recorded. No new G-code, no workflow steps repopulated.
• Rules ('folders we design rules around') — two layers: explicit WHEN field-matches-pattern THEN assign-customer/file/flag rules in a plain form; plus TRAINING — the system watches manual filing and after repeats PROPOSES the rule in plain words, one click ratifies. Never silently learns; every rule recorded with who/when, editable; every auto-action names its rule; a manual move always wins. Seed, never bind.
• Thumbnails on every job/NC row — 'I find myself recognizing the shape' is how the archive is actually browsed. Ruled YES.
• Default home = the workflow inbox, customer tree one click away, per-station preference to flip (ruled 'could this be a preference' → yes).
• Fixture sweep ruled yes: internal test jobs live under a KerfMaster-internal customer.

Build starts on Jordan's go same day ('record it, create the pin, and start building the build blocks'). Brick A = registry + tree + search (pin ui-filing-brick32); queues, rules/training, thumbnails, reorder path follow as their own bricks.