design

Head of Production — design notes

Web flow, canonical Atlas shell at 1440. Sidebar + topbar, .pg-wrap of .pg-view pages, nav() router, centred .dlg for confirmations, toast() for confirmation.

Persona

The Head of Production owns production across every line — output against plan, capacity, the holds stopping a line, and the line managers’ requests for items the catalogue does not carry. Production Managers work the floor in Forge; this console plans and monitors.

Navigation

Sidebar, two groups: Overview (Dashboard) · Production (Work orders, Item requests). Item requests carries a .sb-count badge with the pending count. Notifications (topbar bell) and Settings (account menu) are inner pages reached from the shell and each opens with a .pg-back.

Views

Slug	View id	What it does
dashboard	v-dashboard	Landing view. .pstat row: units built today, plan attainment, open work orders, item requests pending (the last two route on click). Awaiting your approval card lists the pending item requests, row click opens the record. Output by line card holds planned against built per line with an attainment badge.
work-orders	v-work-orders	Production work orders. .pstat status row (All · In progress · On hold · Complete) with counts, clickable to filter. .tbl-card-head carries .filt-search left and .filt-select filters right (status, line, date opened). Columns: Work order · Line · Model · Planned · Built · Status · Date opened.
item-requests	v-item-requests	Approval inbox for items a Production Manager needs that are not in the catalogue. See below.
—	v-request-detail	The item request record. Inner page, .pg-back to Item requests, .rec-grid of .card.
—	v-notifications	New item requests, holds and stock movements as .ntf-row entries under .ntf-sec day headings. Mark all read clears the bell dot.
—	v-settings	Two-pane .settings-layout: My Profile · Notifications · Preferences · Security.

New item requests

A Production Manager who needs an item the catalogue does not carry raises a request against it. The request lands here for the Head of Production to decide.

List — status summary .pstat row (All · Pending approval · Approved · Rejected) with counts, clickable to filter, above a .tbl-card whose head carries .filt-search plus .filt-select filters for status, location and urgency and a date-requested range. Columns: Request · Item · Category · Unit · Qty · Requester · Location · Need by · Date requested · Status. Cells stay short; the long text lives on the record.

Record (v-request-detail) — item name, category, unit and quantity needed, then why it is needed, then the industry standard or spec, then location, requester with role, need-by date, urgency, the attached photo and the date requested. Below that, Closest catalogue items as a .tbl-card with a match badge per row so a duplicate is obvious, then the decision (Decided by, Decided on, Item created, Procurement request), the rejection reason where there is one, and the audit trail as .fr rows.

Actions on a pending record — Approve (.btn-pri) and Reject (.btn-danger-out). Approving flips the status to Approved · with Procurement, creates the item in the catalogue and raises an ordinary request to Procurement for the quantity, both stamped onto the audit trail, and confirms with a toast naming the created item and the request to Procurement. Rejecting opens #dlg-reject, a centred .dlg with a required reason; the reason is stored on the record and shown on the detail only. A decided record carries no actions.

Seeded requests: REQ-IT-2041, REQ-IT-2038 (pending) · REQ-IT-2035, REQ-IT-2027 (approved) · REQ-IT-2031, REQ-IT-2022 (rejected).

Send feedback

Topbar .icon-action with a message icon opens #dlg-feedback: Type (Bug / Improvement) · Impact (Blocking / Slows me down / Minor) · Where (this console’s pages, preselected to the page it was raised from) · Details · optional Screenshot. sendFeedback() validates the four required fields, each with its own toast, and confirms with one on success.

Goals (dashboard)

The delivery target is set by the Product Manager (Tricycle Hardware), not here: 400 battery packs by 31 Aug. This console carries the same figures the PM and the delivery owner see, so all three read one number: progress with a marker for where we should be by now, delivered against what is left, the rate we are running at, the rate needed from here to land it, where the current pace finishes, and the split by line showing where the output is coming from. The head does not edit the goal - the badge names the delivery owner who does the work against it.

Several goals can run at once, so this page renders one card per goal the PM has running for this unit, each with its own target, deadline, delivery owner and state - not started, on track, behind pace, met or missed. A met or missed goal keeps its card (delivered against target, how far over or short, the average a day, the window) until the PM closes it; closed goals drop off this page. Goals are set and closed on the PM console, not here - the accountable head reads them and delivers against them.

Goals

A goal leaves the live list the moment it finishes, so the dashboard shows only what is still running. Finished goals sits underneath as a table — reference, target, delivered, result, window and, for a goal the PM voided, the reason they gave. pgDone decides which list a goal belongs to and pgResult states how it ended: met — +12, 190 short, or voided. Nothing is overwritten and nothing disappears; a voided goal keeps its record and its reason on this side too, so the person delivering it sees why it stopped.

The strip and the page do different jobs

On the dashboard, one line. Whether anything is behind pace, and which goal is furthest behind — 5,000 conversions · 432 behind. The whole strip is the click target. The goal cards are no longer on the dashboard.

On the page, the work. A roll-up across the live goals (running, delivered, still to go, met), the live goal cards, and the finished-goal history. A finished-goal row opens that goal, including the reason the PM voided it.

One name: Targets

A delivery push and a standing service level are both the thing you are held to, so a persona does not have to learn two words for it. The nav item, the page, the strip and the page copy read Targets on every console that carries either. What each console measures is unchanged: Production and Retrofit still track delivery against pace, and a finished one still moves to Finished targets with its result and, where the PM voided it, the reason.

The tables

Two things came out of driving the runtime probe to zero on this console.

Wide tables fold, they do not shrink. A qualifying field goes under the field it qualifies as a .td-sub: the category under the item it classifies, the serial under the tracking mode that produced it, the location under the person at it, the date a return was actioned under the outcome. Nothing was dropped to make the count.

A table whose rows have nothing behind them says so. A breakdown by line, a log of what changed, the line items on one note, an admin list whose rows carry their own Edit and Disable links — none of those has a record to open, and demanding a row handler would only produce one that goes nowhere. Those tables carry data-canon="allow-static-rows" with the reason written beside them. Where a record did exist, the row opens it instead.

The page spaces its own sections. Each section used to carry whatever margin its own atom happened to have, which left the summary strip 4px from the section under it here and 0px on the head consoles. #goals-page now zeroes its children’s bottom margin and put a single 20px between them, so the gap does not depend on which atom comes next. The two tables also stopped declaring an inline margin-top, which would have won against the page rule.

The card says what moves the number

Each target names the work item it delivers, drawn from what this console records rather than free text, and states the record set its progress is counted from — Counted from retrofit orders closed at QA. The finished-target detail repeats it, so a closed target can still be checked against its source.

Progress is counted, not typed

done was a seeded number, so nothing about it answered to the window, the model, or any work actually recorded. DELIVLOG is now an output log of closed work orders — 678 records — each carrying what it delivered, for which model, on what date and how many units. delivDone sums the records matching a target’s deliverable, its model and its window up to TODAY_ISO; delivElapsed derives the days elapsed from the same dates. So narrowing a window drops the figure (G-114 goes 321 to 132 when its start moves to 1 August), switching the model changes it, and Any model sums both.

The segments make the unit ramp across the year, which is why the same deliverable pays out differently in different windows — and it is why a target that was authored to look on pace can come out behind once the number is actually counted.

Item requests cover what the catalogue already holds

The page only ever carried requests for something the catalogue does not hold. Inventory can also flag an item it does carry — the expensive ones, the ones a unit can only justify case by case — and those take the same approval before the warehouse will fulfil them.

Every request now states which kind it is under its id, new item or existing item, with a filter beside Status for either. A request for VCUs after two failed on one batch reads the same way a request for something not yet stocked does, because the decision is the same decision.

An approved request goes to Inventory, not past it. The status used to read “with Procurement”, which skipped the warehouse; it reads with Inventory, which fulfils from stock or raises it onward. Approving creates the catalogue item, raises the request on Inventory, notifies the warehouse and tells the requester in-app and by email — all four on the audit trail.

An existing item is here because Inventory flagged it

A request for something the catalogue already holds only reaches this page because Inventory flagged that item, and the row said only “Existing item”, which left the reason to be guessed. It reads Existing item · Inventory flagged.

The seeds name items from Inventory’s own flagged list rather than parts that list has never carried, so one request can be followed from the floor through this desk to the VP and back without the item changing its name on the way.

Procurement is copied on the approval

Approving creates the catalogue item, raises the request on Inventory, notifies the warehouse, tells the requester in-app and by email, and copies Procurement, who is who will have to source it. All five are on the audit trail.

A warehouse request and a purchase request are two references

One row called Procurement request held whichever of the two a record happened to have, and approving minted a REQ- id for something that lives on Inventory, where requests are TRF-. The record showed a warehouse request under Procurement name, in Procurement numbering, for something Procurement had not seen. They are separate stages and now separate rows: Inventory request is what an approved existing item becomes at once, Procurement request is what Inventory raises when it cannot fulfil from stock or once a new item exists to buy.

An existing-item request could not be opened

The record page was written for a new item and read the closest catalogue items, the audit trail, the specification and the photograph unconditionally. An existing item has none of them, so clicking one threw on the first and the record never opened: the page that shows whether an existing item was approved was the one page that would not open. The optional blocks are optional now, the closest-items card appears only where there is something to compare, and every request carries a trail.

Approving creates the item

The composer asks for the item type, the descriptor, the specs, a version, the classification, the unit, the standard and a photograph, which is a catalogue record. That is what it is for: approving a new item mints it on the catalogue and raises the warehouse request against it in the same action. An existing item is raised the same way, without the creation.