fleet-overview-reports

The 2026-08-20 product review with Mark M (Mark Peterson — external security-advisory-board member, fractional CISO at Moto, Vanta customer advisory board; runs SOC 2 + NIST 800-53 moderate programs) produced Tyler's organizing concept: "the fleet overview, which is the landing page, is really just a summary of those 4 reports" — each summary card launches into its full report; each report drills into controls, inventory, or specific agent sessions. This cycle is the design head-start on a ~6-week paid consulting engagement with Mark M (pending September 2026 availability) to define fleet overview and reporting.

Full source material: background.md. Extraction/transcript in market-analyst repo (data/processed/2100ac03-7f66-4558-96ca-908858a3cb4a.json).

The four reports mocked at full depth on the design site, a summary-card treatment chosen via bake-off, and a fleet-overview-v3 landing composition where the four cards are the spine. "Done" looks like: report chassis + four report pages + card bake-off + landing mock, all registered and smoke-checked — concrete input for the Mark M engagement.

• New pages in app/pages/pages/: report-anatomy-v1, report-{compliance,sla,inventory,board}-v1, report-card-ideas, fleet-overview-v3
• New fixtures: app/data/report-fixtures.ts (extends the c59/c68 fleet story)
• Registry: new reports group + overview entry in app/data/page-registry.ts
• Read-only inputs: c68 landing mocks, c59/c60 inventory pages, c77 session pages (drill targets)
• Out: qdash/qcontrol port, real export/scheduling engines, new session work, c68's open treatment picks (c68 closes separately)

• Stage 1 (2026-08-20): initial-prompt.md + background.md — capture from the Mark Peterson product review: the four reports, format/delivery requirements, personas, session-drill expectations.
• Kick-off (2026-08-21): plan.md (approved staged plan), this CYCLE.md, reconciliation.md (c68 mapping + personas). Five scoping decisions recorded above.
• Stage 1 — fixtures (2026-08-21): app/data/report-fixtures.ts — the Meridian world at report altitude. Compliance (SOC 2 + NIST 800-53 controls, evidence items, passing-% trends), SLA Insights (quarter rollups, findings with unresolved-reasons, 7/30/90/180d placeholder rubric, slaBreaches()), Inventory (harnesses, models, MCP servers, shadow installs with personal-vs-enterprise account flag, coverage trend), snapshot shelves per report. Board report and all four summary cards are derived (deriveBoardReport, deriveCardSummaries), never authored; 3/6-month windows are slices of one stored 12-month series (slicePeriod).
• Stage 2 — chassis (2026-08-21): /pages/report-anatomy-v1 built and registered (new reports group). Six organs defined at Compliance depth: header (identity + observation-period cursor), verdict band (score + spark trend + delta), body (control rows expanding into period-scoped evidence, session drill link), export bar (PDF/JSON/CSV + schedule), snapshot shelf (retained runs, re-run, diff flagged as open thread), and the document face (white paper artifact + machine JSON stub). Chassis rulings recorded on-page: organs 1–4 are one object; period is a cursor not a filter; evidence sampled on screen, complete in the artifact; verdicts derived; instances swap body grain, never organ order. Smoke-checked: 200, clean log.
• Stage 3 — the four instances (2026-08-21): /pages/report-compliance-v1, /pages/report-sla-v1, /pages/report-inventory-v1, /pages/report-board-v1 built and registered. Chassis organs factored into local components (app/components/report/ — Header with period cursor, Verdict, ExportBar, SnapshotShelf; layer extraction is an open thread). Body grains per audience: controls+evidence (auditors), findings-vs-SLA with quarter rollups and mandatory unresolved-reasons (compliance/security), asset tables with the personal-vs-enterprise shadow signal (IT ops), and the derived board view with document-forward packet (execs). Derivation check caught and fixed a real inconsistency: strict passing-only scoring (42%) contradicted the authored trend (83%) — ruled auditor semantics: failing = non-compliant, attention = compliant with a noted exception; marcus's sandbox finding downgraded to attention accordingly. All five report pages smoke-checked 200, clean log, derived numbers agree everywhere.
• Stage 4 — card bake-off (2026-08-21): /pages/report-card-ideas built and registered — four treatments of "how does a full report compress to a card," each shown as its complete four-card landing row: (1) metric register (score · delta · spark), (2) worst-thing-first (single urgent line + open count), (3) last-run receipt (snapshot id/timestamp/score — the auditor's register), (4) mini-document (report-as-thumbnail, artifact identity). All values from deriveCardSummaries(); one attention device per card per c68's queue lesson. Judging law on-page: a card earns a device only if it answers "do I need to open this report?" better than a number would. Provisional verdict recorded (final pick is Mark's): merge register spine + one worst line, receipt id as footer whisper; mini-doc redirected to shelf/export surfaces. Smoke-checked 200, clean log.
• Stage 5 — landing composition (2026-08-21): /pages/fleet-overview-v3 built and registered (overview group) — Tyler's concept composed: derived verdict line, four-card spine wearing the stage-4 merged treatment (register spine + worst line + receipt whisper), estate funnel as the quiet footer; cards link into their reports, reports drill onward. c68 reconciliation taken deliberately: queue distributed into card worst lines, trust band compressed to the funnel — both reversible if Mark's c68 picks say otherwise. Attention world derives from the report fixtures; the all-clear world is an authored second fixture world (calm, not empty). New finding recorded: cross-report double counting — one underlying event surfaces in several reports (the failing control is the open high finding; shadow installs are the coverage gap), so the verdict counts reports needing attention, never summed items; fleet-wide item counts need entity resolution first. Smoke-checked 200, clean log.
• Thread — card-minidocs (2026-08-24): Mark's pick against the stage-4 lean: expand the mini-document, don't shelve it. /pages/report-card-minidocs built and registered — seven versions where typographic hierarchy (weight, size) is the instrument, each promoting a different derived fact to the top of the type scale: headline (score), lede (worst item as a real sentence), stamp (verdict as a rotated audit mark), contents (derived mini-TOC locating the trouble section), marginalia (page opened to the highlighted finding), cover (identity, the stage-4 control condition), ticker (delta + embedded spark figure). Mid-thread ruling: no "Qpoint" masthead — each card leads with its own title (cover uses the audience line). On-paper ink is fixed palette, never themed (white page in both themes); one device per card holds, including exactly one lit TOC row. Provisional verdict on-page: headline spine + lede sentence is the natural merge; stamp is alert-world dressing only; contents/marginalia belong on drill/export surfaces; final pick Mark's. Thread files: card-minidocs-prompt.md, card-minidocs-plan.md. Smoke-checked 200.
• Thread — card-minidocs, iteration 3 (2026-08-24): Mark's ruling: no greek lines — every piece of the mini report must communicate. /pages/report-card-minidocs-v2 built and registered: a content audit per report (one card-altitude question each; a slot survives only if it serves it — the board headline lost its slot for restating its three source rows) followed by two compositions of the audited content: briefing (hero score + spark, toned alarm lines with owners, quiet register) and ledger (same content as a uniform table, the no-hero control). New slots surfaced by the audit: SLA nearest-to-target finding and Q3 found-vs-resolved throughput debt; inventory personal-account shadow split and newest-shadow named; compliance evidence volume. New emphasis rule: weight marks most-informative, color remains the single genuine-tone device — importance and urgency on separate channels. Cards widened 168 → 200px. Provisional verdict: briefing (hero numeral keeps four-up triage scannable); ledger belongs one level down (hover / snapshot shelf). Smoke-checked 200, derived figures verified in rendered output.
• Thread — card-minidocs, iteration 4 (2026-08-24): attention-device bake-off on the v2 cards. /pages/report-card-minidocs-v3 built and registered — ten devices for calling out areas of concern, in four families: line-level (ink control, highlighter), object-level (border, spine, pink-slip tint), boundary-breakers (merit-badge seal with count, flag tab, dog-ear, notification chip), and the stamp as labeler (the only device that names the problem class, and the only one with a positive state). Discipline held: one tone carrier per card — under any card-level device the text goes neutral and keeps weight; SLA's clean card is the absence test in every section. Transfer check re-shows the two leaders (badge, highlighter) on the ledger. Real bug found and fixed: the layer's Tailwind config sets red: '#FF0033' flat, which clobbers the default red-* scale — every red-600-style class on iterations 2–3 silently generated no CSS (alert ink rendered neutral); all three mini-doc pages switched to rose-*, gotcha saved to memory. Provisional verdict: merit badge (silhouette + magnitude + absence-is-calm), highlighter as line-level runner-up, and a new thought recorded — devices may be escalation rungs (ink → badge → pink-slip), not rivals. Smoke-checked 200 across all three pages, rose classes verified in generated CSS.

• 2026-08-21 (Mark): Reports first, landing last · c68 stays open and closes separately (reconciliation memo records the mapping only) · full mock page for each of the four reports, Board included — start with all the info, trim later · ignore Cam's dashboard directives for this cycle · chassis v1 first, competing chassis formats only when the time is ripe (bake-off energy goes to the summary-card treatment).
• Derivation ethic (carried from c77): card summaries and the entire Board report derive mechanically from report fixture data — never authored.

• Format duality: dashboard-first with dual export — human PDF ("a nice PDF you can hand someone") and machine JSON/CSV; the exported artifact is itself a design surface.
• Time-series > static score: "we wanna know if we're moving the needle" — observation-period selector (3/6/12 mo) as a first-class control.
• Snapshots: schedulable, retained, re-runnable — the auditor evidence trail; snapshot diff is a natural follow-on.
• Composability: Qpoint's reports must stand beside Wiz/Aikido exports in a CISO's aggregate posture.
• Session drill: violations drop into the specific session (targets are c77 mocks).
• Naming: product is Qpoint; internal code name never appears in design artifacts.

• Mark's picks: card treatment — the candidates have converged: stage-4 merge (register spine + worst line) vs. mini-doc v2 briefing (report-card-minidocs-v2, the content-audited card; provisional lean). Winner gets re-composed into the v3 spine for a side-by-side. The two v3 reconciliation positions (queue distributed vs. its own band; trust band compressed to funnel) also await reaction — then /document-cycle (captures, archive, history) closes the cycle.
• Attention-device escalation ladder: iteration 4's devices may be severity rungs rather than rivals (ink → badge → pink-slip = noted → needs you → on fire); adopting it needs a derived severity rule from the fixtures, not taste.
• Layer extraction: the four Report* organs (app/components/report/) graduate to q-nuxt-layer once the chassis stabilizes past the Mark M engagement.
• Cross-report entity resolution: the double-counting finding (stage 5) — any fleet-wide item count needs one identity per underlying event across reports.
• SLA rubric: 7/30/90/180d day targets are placeholders pending Mark M's actual rubric.
• Snapshot diff view (re-run for consistency checks implies compare) — noted, not built.
• Machine-readable JSON schema — stub exists on the chassis document face; the real composability contract is engagement scope.
• SLA resolution workflow (acknowledge/ignore/exception/escalate/enforce + audit record) is a product gap the SLA report depends on — design assumes it exists in fixture form only.