c134. Control Plane Web App

Stage 1, split from c130's initial prompt on 2026-11-09. The passages below are Mark's words from ../c130.native-app/initial-prompt.md, unchanged. Program plan: ../c130.native-app/plan.md. Tyler's plan for the control plane ("Qplane") is in session 1b21a3ce (2026-11-05): the Pulse backend repurposed with a new data model by Kamal, no Firebase, Postgres and ClickHouse, one Docker image with the UI and the Go app, offered as SaaS and self-hosted, API first.

From c130's initial prompt

Roadmap

We are removing qdash from ../qcontrol. It will be an optionally installable web app for intrspecting and governing a company wide ai ecosystem.

• We are re-purposing the ../app.qpoint.io backend and vue patterns.
• we'll neatly slip our ../qcontrol app / prototype in to the current ..app.qpoint.io slot.

New Web App

• The new web app is already perfectly modeled with ../app.qpoint.io. We are replicating it directly–including the back-end / database (caveat, we're currently using firebase, but that's not an option because we need self hosting, this will be replaced with something).
• The app will be self-hosted by the company.

• greater data trust
• we are less liable for the uptime thus reducing our technical responsibility surface area
• we lose some ability to see problems, but can offset in other ways.

Pointers

• ../../../app.qpoint.io (the model: Nuxt 4 SPA, Pinia, the layer, Firebase auth and Firestore, the Pulse API plugin, org and context middleware, SAML routes, alerting, wizards).
• ../../../qcontrol/crates/qdash/ui on feat/new-pages (the pages that move in) and its docs/data-interface.md (the contract).
• c113 (baked demo worlds), c125 (wizard kit), c128 (the shared time window and the from/to the backend needs).

Create a plan, ask any clarifying questions, suggest patterns I may not be considering.