design

Head of Retrofit — 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 Retrofit owns retrofit across every station — conversion output against plan, quality of build, the holds stopping a station, and the station managers’ requests for items the catalogue does not carry. Retrofit Station Managers work the floor in Forge; this console plans and monitors.

Navigation

Sidebar, two groups: Overview (Dashboard) · Retrofit (Retrofit 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 converted today, plan attainment, open retrofit 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 station card holds planned against converted per station with an attainment badge.
retrofit-orders	v-retrofit-orders	Conversion orders by station. .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, station, date opened). Columns: Retrofit order · Station · Model · Planned · Converted · Status · Date opened.
item-requests	v-item-requests	Approval inbox for items a Retrofit Station 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 Retrofit Station Manager who needs an item the catalogue does not carry raises a request against it. The request lands here for the Head of Retrofit 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-3044, REQ-IT-3041 (pending) · REQ-IT-3037, REQ-IT-3033 (approved) · REQ-IT-3029, REQ-IT-3024 (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: 5,000 conversions 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 bay 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, and those take the same approval before the warehouse will fulfil them. Every request states which kind it is under its id, with a filter for either — a request for BLDC motors holding up drivetrain refits reads the same way a request for something not yet stocked does.

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

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. The row reads Existing item · Inventory flagged rather than leaving the reason to be guessed, and the seeds name items from Inventory’s own flagged list so a request keeps its name all the way to the VP’s desk.

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.

A warehouse request and a purchase request are two references

Inventory request is what an approved existing item becomes at once, in Inventory own numbering; Procurement request is what Inventory raises when it cannot fulfil from stock or once a new item exists to buy. One row was holding both under Procurement name.

An existing-item request could not be opened

The record read the closest catalogue items, the audit trail, the specification and the photograph unconditionally, and an existing item has none of them, so the record threw rather than opening. Each is optional now and the closest-items card appears only where there is something to compare.

Approving creates the item

The composer collects a catalogue record, so approving a new item mints it on the catalogue and raises the warehouse request against it in the same action.