alexis-mbp

Composition notes

• Question: is this machine covered, and what runs on it? Coverage is a fact about the machine against the Okta/Jamf denominator (c21 §2.2 — never the sensor's own sightings); "what runs" is what the sensor or egress has seen, monitored or only detected. Two halves, in that order.
• Verdict line is verdicts.deviceDetail with its sub line enriched in derived/device-detail.ts: seat held with no sensor (investigate), Okta-vs-Jamf disagreement, installed-never-run, sensor behind fleet-latest. Hygiene never changes the tone — drift is a fact, not an alarm (the overlay's own rule for Marcus's stale install).
• Coverage block = c21's adoption checklist as a five-step stepper (known to identity source → MDM-enrolled → sensor deployed → observing → enforcing), each step done / partial / missing with the fact behind it. The partial and empty states are the same component with steps unlit, not a different page. A Windows platform gap and a macOS deployment gap are different reasons with different next actions, and the gap strip says which — plus the other devices that share it. Under the stepper, two witness columns keep the denominator (Okta/Jamf) and the observation (the sensor) visibly separate.
• Agents on this device is a DataTable over deviceInstances(): technology mark, monitored / detected-only (with why: install scan vs egress), version with fleet-latest when behind, account licensing badge + chip, sessions 7d, last seen, → Agent detail. No sensor collapses the body: agents, hygiene, sessions and the actor web are sensor observations, so a device without one prints a single line under the coverage block instead of four empties (the c81 review's ruling); a platform-gap device with an egress-detected install keeps the agents table and actor web, hides hygiene and sessions. The next step lives once, in the gap strip.
• Hygiene is teams-strip-windows' block re-derived: sensor version vs fleet-latest for the same OS (with the stated consequence — observe-only below the policy engine's minimum), per-install version lag, zombie installs (no session on record after 14d), and proc: shadow processes. Only shadow rows count against coverage; the receipt line says so and prints the thresholds.
• Fabricated minimums (all TODO(reconcile) in the derived file): the shadow-process table (one row: ollama serve on jonah-mbp, mapped to the Hermes install, hidden once that install is monitored), the policy engine's minimum sensor version and fleet policy name, the zombie threshold, and enrolment as an upper bound (owner start date, else earliest agent sighting) because devices carry no enrolment date.
• Actor web through Phase1EntityChip: owner, installs, accounts, models, MCP servers (configured ∪ connected, unreviewed / undeclared / not-connected flagged), repos from cwd, endpoints reached from this device (not-allowlisted flagged), sessions. Gap-mates link sideways to other device pages; the fleet number links up to Teams & Users, which owns the roster.
• Both states: the all-clear overlay gives Alexis's mac a sensor, a Jamf record, a Claude Code install and sessions on record — every step lights, hygiene reads clean, the tables fill. The Windows boxes get the 1.15.0-win sensor, so Grok on kai-win-01 turns monitored; their MDM step stays missing because Windows has no Jamf, and the page says so rather than lighting it.
• Open: whether "enforcing" belongs on an inventory page at all this cycle (governance is quiet here — it is kept as one step with no controls); whether enrolment date should come from Jamf directly; the label for the technology level ("agents" vs "installs") follows Inventory.