design

Technical Specialist · KaaG

Job to be done

Give one P0 technical owner an end-to-end workspace that spans the former Technical Officer and Embedded Systems Engineer responsibilities: commission field hardware, verify the first heartbeat, inspect decoded and raw telemetry, diagnose device and data-quality faults, manage signed firmware, and send audit-recorded remote controls.

Information architecture

• Technical overview: six KPI cards, the last-seen honesty strip (Reporting now / Quiet / Silent / Offline / Dark), a combined work queue, system health, and a needs-attention fleet table.
• Commissioning: real identity capture (VC25 serial, Rechaj<MAC> NVS fallback, APN onomondo, IMEI/ICCID honestly marked not-captured), SIM/GPS/firmware checks, first-heartbeat validation against the retained LWT on will/<device_id>, and a display-link check (SOC push + vehicle-lights frame freshness).
• Telemetry & raw: dense RADR fleet table (age chips, uptime sparkbars, SOC bars, SOH, carrier+RSSI, MCU·VCU·BMS·DU system chips, mono FW) plus the live raw MQTT console on pub/<device_id> with real wire fields (mwv, mwc, mpd, trq, tp1, soc, soh, batv, inv, blk, fvr), gap/backfill markers, pause, offline session-tail honesty, and a decoded-signal table with live sparklines. Retention footnote: raw 90 d, 1 m/1 h aggregates.
• Diagnostics: warning thresholds (SOC < 20%, battery > 55 °C, motor > 95 °C), unauthorized-move flag (key_state=0 while moving), and the honest data-quality register — fault register parsed-but-not-published (RUNBOOK §4.4), pub/ vs vcu/pub/ namespace mismatch, derived heading, IMEI/ICCID backlog.
• Firmware: releases with adoption bars, staged waves, OTA guardrails card, and a stalled/failed straggler table with resume positions.
• Command audit: kill-switch banner (radr.commands.enabled), the real command set (IMMOBILIZE→MECHOFF with typed confirm token, REACTIVATE→MECHON, KAAG_ON/KAAG_OFF→INVON/INVOFF, AUTO, battery unlock), SENT vs QUEUED outcomes, idempotency note, [radar-command-audit] tag.
• Deliveries to Inventory (TH-234): the team’s own register of deliveries it pushed to the warehouse, a four-step push, and a record per delivery. See the section below.
• Unit technical detail: RADR identity card, status strip, live decoded signals, full raw console, 24 h connectivity timeline, commands panel, and a Display & indicators section sourced from the MCU vehicle-lights frame 0x18F86590 (no networked DU, no DU commands — the DU chip reflects display-link health).

Access boundary

Technical Specialist can update commissioning checklists, validate hardware and first heartbeat, access raw MQTT payloads, diagnose telemetry and firmware, and send the full audit-recorded command set including destructive IMMOBILIZE (typed confirm token required). The role does not edit rider profiles, decide product rollout or adoption policy, or approve KaaG commercial eligibility.

Canon

Web 1440 Atlas shell at RADR visual parity (kaag-radr-foundation.css loads last). Uses .pstat KPI tiles, .pseg filters, .tbl-card > .tscroll > .tbl tables, RADR cell widgets (age chips, SOC bars, uptime sparkbars, RSSI cells, system fault chips), the dark #0E0F12 MQTT console, canonical badges, outline icons, centered .dlg confirmations with required reasons, and top-center toasts. Cards have no visible borders. Every confirm is audit-logged.

Deliveries to Inventory (TH-234)

Telpo sometimes delivers spare VCUs and display units straight to this team, and Procurement never raised an order for them. The team has to hand that stock to the warehouse, and before this the only route was a message to the Inventory Manager, which no receipt and no stock count could see. So the team pushes the delivery to Inventory from a new Inventory group in the sidebar (#page-deliveries), and each line lands on the Inventory Manager’s Receipts tab as a Pending receipt, counted in there exactly as one from Procurement (inventory-manager/design.md, Receipts from other teams). The push belongs to the team that holds the goods, never to Receiving: a warehouse that could create its own expected deliveries could receive goods nobody sent.

One section, written for any team. Every id is td-*/tdp-*/tdr-* and the team’s name comes from one constant, TD_TEAM. The three telematics seats share one Inventory module in Atlas, so they mount it once; a facility or another team that takes vendor deliveries mounts the same section with its own name, and the warehouse reads each as one more value in its Source column.

The register (#page-deliveries) has four .pstat cards that partition every push, Pending at Inventory, Partly received, Received and Cancelled, and each filters the table. The table (#td-tbl) reads Delivery (with the paperwork beneath) · Vendor · Items (first + “+N”, units beneath) · To · Delivered (with who on the team took it) · Status, search on the left and a status .filt-select on the right. A row opens the record.

The push is a wizard screen (#scr-push), not a dialog. It holds four kinds of information, the delivery, its lines and their serials, its proof, and a review, and PATTERNS.md sends a form like that to the onboarding wizard shell rather than to a taller .dlg. The steps are:

1. The delivery. Vendor, from the existing vendor list only (.combo, a vendor that is not on it is Procurement’s to add). Destination warehouse, from the existing locations; a warehouse with nobody receiving at it is in the list, disabled with its reason (“nobody receives here yet”), because a push to it would mint receipts that no inventory manager can see. The date the vendor delivered it to the team, and who on the team took it and when.
2. Items and serials. Per line: catalogue item (.combo), quantity and unit cost. Unit cost may be left blank, and a blank cost is recorded and shown as Not known, never ₦0, because the paperwork from a vendor often has no price on it. A serialized item takes one serial per unit in one field: scan it, type it and press Enter, or upload a CSV, the same capture the warehouse uses. Each serial is a .ser-line naming what happens to it: New, or refused by name, Already in stock or On another open push, because either would fail at the count.
3. Proof of delivery. What the paperwork is, a free label with suggestions (Waybill, Invoice, Message from the vendor, Photos on arrival, Other), since the ticket’s rule is that the push accepts the delivery whatever its paperwork is called. An optional reference. At least one file, photo or PDF.
4. Review and push. Restates each step with an Edit back to it, and says what Inventory will get: N pending receipts at that warehouse, nothing in stock until it is counted.

The record (#page-delivery) is a details page: three .pstat (units sent, counted in at Inventory, value sent with the units that carry no known cost named), the delivery and its proof side by side (files open in the lightbox, #td-img-view), and the lines with their receipt number and status at Inventory. The team reads progress here; the count itself is the warehouse’s.

Cancel while nothing is counted. #tdr-cancel opens #dlg-td-cancel, which takes a required reason and withdraws every pending receipt. Once Inventory has counted any line the button stays on the page, disabled, with the reason in its title, because a delivery half in stock cannot be undone from here. Receiving has no cancel, so without this a mis-keyed push would wait in the warehouse’s queue for ever.