App Consolidation

The product shifted to AI agent security & monitoring and took shape organically in the engineers' hands inside the qcontrol Rust monorepo. The result is a fractured application state: three separate front-ends (qdash fleet dashboard with two coexisting UIs, qglass live log inspector on a different Vue stack, qtray native macOS menu bar) plus the cloud control plane (qplane / app.qpoint.io) and a marketing product lineup (qcontrol / qtap / qplane / devtools / qscan) that doesn't map cleanly to the actual surfaces. A design effort is needed to understand everything, converge on one coherent ecosystem, and make every use case clearly demonstrable.

Six hard objectives:

1. Understand what each app does — captured in research/ (done at cycle creation).
2. Implement a Nuxt front-end using q-nuxt-layer — building on the engineers' existing beachhead at qcontrol/crates/qdash/ui/ (Nuxt 4 on @qpoint-io/q-nuxt-layer, branch feat/qdash-nuxt-redesign). New components created where appropriate (design-site-first, then released to the layer). Subtle dark mode — human-driven.
3. Use-case-driven structure — every core use case (run, scan, tap, monitor, inspect, dashboard) is clearly demonstrable and demo-able. Simple, makes sense.
4. Docs site — design + populate a new dedicated docs project (docs.qpoint.io) consuming q-nuxt-layer.
5. Fix the cookies permission on www.qpoint.io — research shows this is a build, not a fix: no consent system exists in code.
6. Adopt useful qcontrol agent processes — the to-prd → to-plan pipeline transfers to design work.

• ../qcontrol/crates/qdash/ui/ — the consolidation target front-end
• ../q-nuxt-layer/ — new/extended components and dark-mode tokens
• New docs project (to be scaffolded, sibling directory)
• ../www.qpoint.io/ — cookie consent build
• design/.claude/skills/ — adopted process skills
• This cycle's docs: research/ (four research docs), plan.md (workstream plan)

• ✓ Researched the qcontrol suite (17 crates, 3 UIs, CLI surface, event contract, qdash API/DB), the qcontrol team's agent process skills, www.qpoint.io cookie state, qplane/app.qpoint.io, and docs-site state — saved as research/apps.md, research/use-cases.md, research/agent-process.md, research/web-properties.md
• ✓ Decisions: build on crates/qdash/ui/ (not a fresh app); docs site is a new dedicated project
• ✓ Wrote plan.md — five workstreams (ecosystem understanding, consolidated front-end, docs site, cookie consent, process adoption)
• ✓ Component gap analysis (research/component-gaps.md) — inventoried qdash UI + qglass against the layer's 116 components. qdash locals mostly wrap layer primitives (promote: Panel, AppSidebar shell, AttentionStrip, BarList; converge DataTable/PermissionTable); true new builds come from qglass absorption: tabs, resizable side panel, tree multi-select, virtualized table
• ✓ App inventory (research/app-inventory.md) — product-level catalog of every piece of data and every affordance across qdash's 13 Nuxt pages, qglass's inspector (incl. the event-family taxonomy), and the 8 legacy-dashboard surfaces the port lacks. Key finding: the Nuxt port is 100% read-only — every write path (finding workflow, egress decisions, teams, channels, attestations, campaigns, controls) lives only in the legacy UI