c15 — Initial Plan: Agent Dashboard

This is the executable master plan for the c15 cycle, produced from initial-prompt.md. Phase 1 is complete (see phase1-analysis.md). Phases 2 and 3 are laid out here for a second agent to execute:

• Phase 2 — Wireframing: a divergent lo-fi pass that explores alternative fixes to the Phase 1 deficits (both net-new governance pages and in-place reframes).
• Phase 3 — Mockups: the winning wireframe directions graduate to hi-fi — m1 constrained to existing ../q-nuxt-layer components, m2 unconstrained.

Both phases are scoped from the Phase 1 findings.

Context

Qpoint is shifting toward agent governance. The existing product wireframe (wf1, in ../app.qpoint.io, http://localhost:7878/) is a ~45-page API/traffic observability app with only an emerging agent angle (MCP clients, dataset views, proxy egress control). The cycle re-evaluates that app through an agent-governance lens for three mandate-owners — Security, Finance, Executive — and then mocks up a stronger version.

Headline conclusions from Phase 1 (drive Phase 2):

• Security is structurally well-served but speaks "traffic/PII," not "agents/LLMs."
• Finance is unserved — the app measures bytes, never tokens or dollars. Biggest gap.
• Executive value is scattered across operator pages; no board-level posture surface.
• The app is missing six net-new exec/finance pages; the top three close the mandate.

Phase 1 — Analysis ✅ (complete)

Delivered: phase1-analysis.md — per-page evaluation (purpose + Security/Finance/Executive 0–5 scores + opportunities for all ~45 pages), per-persona evaluation, additional-personas recommendation, and the net-new exec/finance page gaps.

Carry-forward decisions for Phase 2:

• Keep Security / Finance / Executive as headline stakeholder columns; add Engineering/Platform and Compliance/Privacy as secondary columns (they own real pages and the pivot raises their importance).
• The structural fix that lifts the whole app: an agent / model / identity dimension (vs. today's Vendor/Client/Endpoint pivot). Carry this into every mockup.

Phase 2 — Wireframing: explore fixes (for the second agent)

A divergent lo-fi pass that explores alternative fixes to the Phase 1 deficits before committing to hi-fi. Covers both net-new governance pages and in-place reframes of the highest-value existing pages. Each problem gets 2–3 divergent wireframe directions to compare; the winning direction per problem graduates to the Phase 3 mockups. Lo-fi Wire* components, grey aesthetic, definePageMeta({ layout: 'wireframe' }).

P1 — RESOLVED → Direction D (persona-partitioned)

P1 explored four IA bets (feature governance-ia-v1: dedicated-section, dashboard-reframe, lens-overlay, persona-partitioned). Decision: Direction D — persona-partitioned, with all five seats first-class (Security, Finance, Executive, Engineering, Compliance) and pure-D landings (each seat = an at-a-glance strip + a flat grid of its page-cards; content duplicated across seats where a page serves more than one).

Consequence for P2–P5: the deep pages below are no longer organized by feature — they become the deep pages of the persona app (new feature persona-app-v1), reachable from the seat that owns them and re-used (duplicated) across seats per the matrix in persona-partitioned.vue. The persona app shell switches seats client-side; deep pages carry a persona breadcrumb + back-to-seat link.

Problems (now persona-app deep pages) & candidate divergent directions

P1 — Where does governance live? (IA / structural — do first; it frames the rest)

• (a) Dedicated section — a new top-level "Agent Governance" area with its own pages.
• (b) Dashboard reframe — recast the existing overview into three stakeholder lanes (Egress / Spend / Posture); governance becomes the home, not a sub-section.
• (c) Governance lens overlay — a toggle that re-pivots existing traffic/inventory pages by agent and overlays posture/spend; no new section (minimal-change direction).

P2 — Executive posture (net-new: Posture Board; folds in the Risk Register)

• (a) Governance-index scorecard — one headline score + drill-down, board-deck style.
• (b) Coverage & risk control-tower — health dials + open findings + egress stance.
• (c) State-of-governance report — narrative sections + trends, exportable board report.

P3 — Finance spend (net-new Spend Report + bytes→token/$ reframe)

• (a) Spend-by-agent ledger — table-first chargeback view.
• (b) Spend-by-vendor breakdown — budget burn by LLM provider.
• (c) Budget & forecast — trend + burn-down + per-agent spend ceilings/alerts.

P4 — Agent identity (net-new Registry + agent dimension on analytics)

• (a) Agent registry — list of every agent (owner, model, creds, scope, risk, spend).
• (b) Agent profile — one agent's full story (egress, data, spend, policy) + thin index.
• (c) Agent-dimension retrofit — add "by agent" to the existing clients/traffic pages (minimal-change direction; touches the shared GroupBy.vue pivot).

P5 — Egress & data control (net-new Egress Matrix + Sensitive-Data→LLM flow)

• (a) Allow/deny matrix — agents × destinations grid, default-deny posture.
• (b) Data-flow / sankey — agent→model sensitive-data flows, allowed/blocked overlay.
• (c) Policy-pack list — installable governance rule bundles + per-rule coverage.

Directions are starting points, not locked. Confirm which problems to explore and how many directions each before building. Recommended priority: P1 first (it gates the rest), then P2–P4 (the three primary stakeholders), then P5.

Cheap in-place wins (no wireframe needed — call out as direct fixes in briefs)

Re-enable the commented-out Sensitive-Data / Last-Used columns; fill the /orgs/configure Capabilities/Hosting stubs; make the adapter delete verified; add the MCP "All-access" warning badge; add an agent option to traffic/components/usage/GroupBy.vue.

Mechanics

• Files: app/pages/c15/wireframes/wf1/<problem>-v1/<direction>.vue — one feature dir per problem, one page per divergent direction (e.g. posture-board-v1/scorecard.vue, control-tower.vue, report.vue).
• definePageMeta({ layout: 'wireframe' }); Wire* components only (grey borders, dashed placeholders, no shadows); WireViewToggle for in-page mode/section switches; reference .claude/skills/visualization-sketches.md for the matrix / sankey / flow sketches (P5) and .claude/skills/wire-components.md for primitives.
• Briefs: one goal-oriented brief per problem in cycles/c15.agent-dashboard/briefs/ (via /write-brief), each naming the deficit it fixes, the stakeholders served, and the Phase 1 §-seed; generate with /wireframe (wireframe-builder, opus).
• Registry: type: 'wireframe', iteration: 'wf1'; add app/pages/c15/index.vue gallery listing the wireframe features.
• Review & choose: run /review per direction, then pick the winning direction per problem to carry into Phase 3.

Phase 3 — Mockups (for the second agent)

Two hi-fi passes of the winning Phase 2 wireframe directions. m1 uses only existing ../q-nuxt-layer components; m2 is unconstrained and may invent components. The point is a deliberate comparison: what the current design system can express vs. what it should be able to express.

Page set

The chosen wireframe direction per problem from Phase 2 (which themselves came from Phase 1 §6). If Phase 2 is skipped or deferred, fall back to the recommended lead set:

1. Agent Governance Posture Board (Executive, Security) — governed-agent count, coverage %, egress stance (default-deny on/off), open high-risk findings, a governance index trended over time. The net-new executive overview the prompt asks about.
2. Agent Spend & Cost Report (Finance, Executive) — token/$ spend per agent per LLM vendor, budget burn, MoM trend, top cost drivers. Closes the Finance gap.
3. Agent Inventory / Registry (Security, Executive) — every agent as an identity: owner, model/runtime, credentials, data-scope, risk score, last seen, spend.

Strong follow-ons (build if scope allows): Sensitive-Data → LLM Flow; Agent Egress Control Matrix; Agent Risk Register / board report.

m1 — constrained pass (existing ../q-nuxt-layer components only)

Map each target page to the real catalog. Known-good building blocks:

• KPIs / metrics: DataStat, DataMetric* (Base/Simple/Compact/InlineTrend/Spark), DataKeyVal, DataTrendDirection, UxLabelText.
• Trends / charts: DataChartUI (Chart.js line/bar), DataSparkChart, DataTimeline, DataPercentBar / UxPercentBar.
• Health / risk: HealthDial, HealthDialSummary, HealthSummaryItem, SecuritySeverity, SecurityPolicyCard, SecurityViolationsTable, SecurityDataFlow.
• Tables / lists: UxTableList* (Index/Header/ColumnHeader/Search/Sorter/ToggleRow/ ExpandRow/Totals), UxListItem.
• Layout / chrome: LayoutGrid, UxStretchBox, UxHoverBox, UxToggleCard, UxBoxTag, UxTag, UxButton, UxModal, Icon*.

Log where existing components fall short (per the q-nuxt-layer audit) — this gap list is the seed for m2:

• No donut/pie or stacked charts (Spend breakdown by vendor/agent wants these).
• No risk matrix / 2D scatter (posture quadrant).
• No filter / faceted panel or date-range picker.
• No breadcrumb, tooltip/popover, avatar group, or icon+text badge combo.
• No dashboard card-grid with built-in header/trend affordances (compose from UxStretchBox + metrics).
• UxTableList lacks column freeze / grouping / virtual scroll for large inventories.

Where m1 hits a gap, make the honest compromise (e.g. a horizontal DataPercentBar stack instead of a donut) and annotate it so m2 has a clear target.

m2 — unconstrained pass (best component for each job)

Re-mock the same pages choosing the ideal representation, inventing components where m1 had to compromise. Propose each new component as a candidate addition to q-nuxt-layer (name

• one-line purpose + which m1 compromise it replaces), e.g.: DataDonut, DataStackedBar, RiskMatrix, FilterPanel, DateRangePicker, AgentIdentityCard, GovernanceScorecard, EgressMatrix. Keep the design-system aesthetic (grape primary, leaf success, grey; rounded-8/12, shadow-sm) so the proposals read as native.

Mechanics (per bob-wire conventions)

• Files: app/pages/c15/mockups/m1/<feature>-v1/<page>.vue and app/pages/c15/mockups/m2/<feature>-v1/<page>.vue. Suggested feature slugs: posture-board-v1, agent-spend-v1, agent-inventory-v1 (+ follow-ons).
• Each page: definePageMeta({ layout: 'mockup' }); real components only (no Wire*); realistic placeholder data (named agents, real LLM vendors, plausible token/$ figures); no API calls or real auth.
• Registry: add entries to app/data/wireframe-registry.ts with type: 'mockup' and iteration: 'm1' | 'm2'. Per project convention, when running mockup-builder agents in parallel they write .vue only and output registry entries in their report; the orchestrator batches the registry edits after all runs complete.
• Gallery: add app/pages/c15/index.vue listing the c15 features (registry is flat; each cycle gallery lists its own).
• Use /mockup <brief-or-description> (mockup-builder, opus) for generation; reference .claude/skills/ux-components.md and .claude/skills/visualization-sketches.md.

Build order

Phase 2 — wireframing

1. Confirm which problems (P1–P5) to explore and how many directions each (default: P1 first, then P2–P4; ~2–3 directions per problem).
2. Write one goal-oriented brief per problem in cycles/c15.agent-dashboard/briefs/ (via /write-brief), each naming the deficit, stakeholders, and Phase 1 §-seed.
3. Build the divergent wf1 wireframes (via /wireframe); batch the registry entries; add c15/index.vue.
4. Run /review per direction; pick the winning direction per problem with the requester.

Phase 3 — mockups 5. For each winning direction, build m1 (constrained) and capture the component-gap list. 6. Build m2 (unconstrained) for the same pages; document proposed new components. 7. Batch registry entries; update c15/index.vue; run /review on each.

Verification

• npm run dev; visit /c15 gallery and each wireframe / mockup page; confirm clickable and styled.
• Wireframes use Wire* only (grey/dashed aesthetic); divergent directions per problem are visibly comparable side by side.
• Mockups use real components — grep the mockup files for Wire → zero matches.
• npm run build passes.
• Side-by-side m1 vs m2 for each page makes the "what the design system is missing" case explicit, with m2's proposed components listed as q-nuxt-layer candidates.

Open questions for the requester

• Which Phase 2 problems (P1–P5) to explore, and how many divergent directions each.
• Should the secondary persona columns (Engineering/Platform, Compliance/Privacy) appear in the wireframe/mockup framing, or stay analysis-only?
• Are real spend/token figures available to ground the Spend & Cost Report, or use plausible placeholders?