c134 Phase 0: inventory of both apps

As of: 2026-11-09. Read from the trees, no servers started. Sources: ../app.qpoint.io (last code commit a6fae09, 2026-03-12; later commits are layer bumps), ../qcontrol/crates/qdash/ui on feat/new-pages (app last touched 4af4df15, 2026-10-02), ../qcontrol/crates/qdash/src/web.rs (a7de3f68a, 2026-09-26, 11,680 lines). Rules referenced: the bible ui/docs/data-interface.md (R13, R15, R23, R25, R31) and ui/LAYER-CANDIDATES.md. Reader: Mark; Tyler and Kamal for §6–§9; the c135 executor for §8. Shape of the finding: app.qpoint.io is a frame (sign-in, orgs, members, contexts, settings, install) around traffic pages that are being retired; qdash is pages (44, one data discipline) with no frame at all. The seam is exactly where the plan put it (D1).

1. Side by side

2. app.qpoint.io mapped

2.1 The frame

• Sign-in and sign-up (app/pages/sign-in.vue, sign-up.vue, session/components/Oauth.vue): email + password, three OAuth popups, and useSSO(email) which queries connectors by the email's domain and swaps the form for "Sign in with SSO" → /sso/<provider>/sign-in?domain=. /forgot-password is linked but no page exists. On success dataLayer.push (GTM) then the pre-auth path or /.
• SSO (app/pages/sso/, server/routes/sso/saml/): saml/sign-in asks $api /sso/saml/auth for authUrl and redirects; the IdP posts to the Nitro route assert.ts, which 302s to saml/callback?assertion=; the callback posts /sso/saml/token and signs in with a Firebase custom token. metadata.xml.ts redirects to the API's metadata. OIDC is the same dance with /sso/oidc/auth and /sso/oidc/token (code, state, redirectUri). Per-org settings in orgs/{id}/settings/sso {provider, domain, url, config} (settings/sso.vue, sso/components/provider/OIDC|SAML.vue).
• After sign-in (app/pages/index.vue): a three-stage wait on Cloud Functions: profile created (users/{uid}), invitations accepted (users/{uid}/invitations), permissions synced (users/{uid}/orgs/{orgId}.roles/.permissions); then /orgs/new or /orgs/overview?orgId=.
• Org and context (stores/auth.ts, composables/context.js, middleware/context.global.ts): the org is a query param, remembered in localStorage; the Pulse token is re-minted per (org, context) through /jwt/tokens {service, contextId, role}; the org switcher (orgs/components/Selector.vue) and the "View:" context selector (contexts/Selector.vue) sit in the top nav (layouts/components/nav/Top.vue) with PageMessages and the user popover (nav/User.vue: Account, Contact Us, Sign Out).
• Permissions (composables/user/orgs.js useOrgPermissions): twelve strings read from the user-org doc (traffic.view, security.view, payload.view, log.view, org.config, org.manage, org.team, traffic.manage, security.manage, context.manage, …); roles are chosen as checkboxes on invite (settings/team/manage.vue, save text "Invite").
• Self-hosting hint already present: orgs/{id}/settings/hosting holds pulseUrl, pulseSecret, warehouseUrl, screenshotUrl (composables/org/settings/hosting.js useSelfHostedSettings); the Pulse plugin points at it when set.

2.2 Data access

2.3 Pages by section (nav in pages/<section>/components/Nav.vue)

2.4 Alerting (composables/alerting/, pages/alerting/components/)

Rules are Pulse entities {name, description, enabled, kind, config, query, checkInterval, reportFrequency} with four kinds and an adapter form each: threshold (metric, operator, threshold, group by), delta (metric, increase/decrease %, group by), discover (new vendor / endpoint / client / PII / token), risk (source and destination define-by, risk labels). Templates or custom (rules/Edit.vue). Integrations are Pulse entities with one UI adapter, Webhook (method, URL, token); rules link integrations through /alerts/{id}/integrations. Events (events.js) join /events/alerts with the rules and draw lines per alert. Scanners (scanner.js) are the vulnerability side. qdash's counterpart: lib/catalogs/connectors.ts + lib/integration-setup.ts recipes (Slack, PagerDuty, email digest, webhook previews), /api/channels routing, /api/integrations config, no engine and no sender.

2.5 Wizards

The kit (app/components/wizard/: Steps, EduHarness, PingListener, ToggleHarness, FinalStep; utils/sequin.js) was replicated by c125 into design app/components/replicas/wizard/ (plus the mask-image radar) and demoed at /pages/phase4/wizard-kit; it is still not in the layer. Flows: Install Qtap (orgs/components/install/qtap/: Name → Choose your Environment → Installation with Docker / Kubernetes / Linux instructions → wait for first traffic (deployment.active) → Installation Successful; mounted by orgs/install.vue on the default deployment's token), Install Qscan (Environment → Install, Docker / Kubernetes), Deploy Qproxy and Connect an app (dev mocks only: dev/components/mock/wizards/), the onboarding checklist (orgs/{id}/tasks: QtapDeploy, QscanDeploy, S3Configure; onboarding/Checklist.vue), preferences (Capabilities, Hosting), create a View (Name → Filter → Members), the security activate wizards (data types, stacks, persistence; scanner categories), MCP configure (Claude / Codex / Other instructions).

3. qdash UI mapped

3.1 Shell

app/layouts/default.vue: AppSidebar (three sections MONITOR / GOVERN + SECURE / ADMIN, disclosures per c109, footer with Working and Experimental toggles and the theme toggle), BackendBanner (unreachable → one banner; 2+ missed polls → "last updated" tag), UxStickyBand with the title pinned beside the filter (c104/c106), GlobalFilterBar (the one layer Filter; keys from composables/shell/filter-keys.ts FILTER_KEYS: team, provider, user, host, agent, posture, kind, source, status, flagged, attention, server, model, workspace, adapter; the permanent when: pill), ToastStack. / is the index of micros (pages/index.vue, c109); middleware/team-routes.global.ts redirects moved routes (lib/moved-routes.ts). Shell composables auto-import; domain and primitives import explicitly (bible §14).

3.2 Pages → composables → routes

Routes no UI module reads: /api/activity, /api/attestations. /api/security-packet is read by the Policies evidence packet.

3.3 Served, derived, staged (R23)

• Served: everything in §3.2's routes column, typed in types/api/*.ts with the handler's field names.
• Derived: lib/*-rollups.ts and *-bands.ts (pure, specced): posture, findings (group, SLA, status), people, endpoints, harnesses, costs, team cost trend, alerts, compliance, index micros, surface, and the live view's virtual rows.
• Staged state (R25, local() / localBlob): framework activation and control toggles (compliance/frameworks.ts), policy enablement, exceptions, lists, detectors, thresholds (compliance/policies.ts). Each names the contract that retires it: GET /api/frameworks (+/frameworks/<slug>), GET /api/policies.
• Staged values (R24, lib/projected/*.ts, 66 ledger entries): alerts 19 (delivery, connector registry, secrets at rest, default routing, source heuristic), compliance 30 (catalogs, requirements, level counts, detector hits, quota thresholds, exception fixtures, framework links), fleet 7 (guardrail rule, enforcement, factor points, credential risk, label join), inventory 6 (tool success, provider labels, workspace git), people 4 (seats, team assignment), security 10 (SLA rubric, event log, operator assignee, expiry in note, DLP labels), session 4 (summary, provider of session). Every entry's contract field is a backend ask; §6 consolidates them.

4. The qdash backend: 38 /api/* routes (web.rs lines 59–132)

SQLite behind every route (db.rs); period_span (web.rs:2334) accepts only 24h / 7d / 30d; no from / to; no auth; no org column.

5. What moves, what is replaced, what is dropped

• Moves (frame, re-homed on the new identity and API): sign-in / sign-up / sign-out / profile, SSO (SAML routes kept, OIDC added, D2), orgs and members with roles and permissions, invitations, the org switcher and user popover, settings (Organization, Team, SSO, Capabilities, Tokens / deployments with the first-ping wait, Snapshot), the onboarding checklist, the wizard kit and the Install flow (Choose environment → instructions → wait for the first ping → done), the Pulse plugin's one-client pattern (already the bible's R14), useList / useEntity's protocol (already the primitives').
• Moves (pages, as they are): all 40 qdash pages with data, their shell, filter, when: pill, honest states, types/api, rollups and specs. Transport swap only (R2).
• Replaced: app.qpoint.io Inventory → qdash Inventory + Organization; Security overview and data-risk → Findings, Posture, DLP; app.qpoint.io alerting rules, events and webhooks → qdash Alerts + Integrations fed by a real engine (D7: the rule kinds threshold / delta / discover / risk and the webhook adapter are the spec of that engine); Firestore live subscriptions → polling (or an API stream) per R1; Cloud Functions (profile, invitations, permissions) → the Go app; contexts ("Views") → the global filter unless Tyler keeps member-scoped views.
• Dropped: Traffic (performance, availability, bandwidth, connections, requests), Stacks (adapters, rules, routing), the $warehouse client, GTM and Sentry wiring as built, the /dev and /lib showcases, agent/focus and agent/reveal on the plane (they belong to the native app, c131 / c137), DesignInProgress placeholders, the demo=true query flow (c113's worlds replace it, D5).

6. The API gap list

What the qdash pages (and the frame) need that the 38 routes do not serve. Sources: types/api/* headers, lib/projected/*.ts contract fields, page comments, c128 data-inventory.md, c105, c131, c136, c137.

Thirty gaps; the window (1–4) and identity (5–9) groups block the most pages.

7. Backend asks, consolidated

8. For c135: what the web app needs that the layer (0.9.37) does not have

Start from ui/LAYER-CANDIDATES.md (17 staged components in ui/app/components/lib/: ProjectedBadge, ProjMark, ProjectedRing, SimulatedBadge, Panel, StatTile, Spark, MetricCell, BarList, AttentionStrip / Message / List / Reasons, JsonTree, AlertHandlers, SkeletonRows, StateEmpty; the composable useVirtualRows; and the state port for DataTable, UxTableList, BarList, DataMachine) plus the Opus track's 59 fixes (git show archive/qdash-opus-5.5:crates/qdash/apps/claude-code-opus-5.5/LAYER-CANDIDATES.md). Add, from app.qpoint.io's frame (all app-local there, none in q-nuxt-layer/components/):

Not needed if D1 holds: app.qpoint.io's PageMain / TopNav / teleported filter slot (qdash's shell is the frame's body), ux/Teleport, the traffic cells (HttpStatus, RequestMethod, table-list/td/*).

9. Open questions for Tyler and Kamal

1. Is Pulse's source readable by design? Which of its patterns survive: the server-side filter grammar, /contexts (member-scoped views), the alert rule kinds?
2. Identity: OIDC plus local accounts for self-hosted, SAML kept (D2). Who issues the session, and is it a cookie or a bearer the UI holds? Where do invitations live?
3. Tenancy: one org per install (D3). Does the schema carry org_id on every row from day one so SaaS multi-org is a flag, not a migration?
4. The window: from / to on every list and rollup, with period kept as presets; cut back from the wall clock or from the data's anchor (the baked worlds depend on the anchor)?
5. Alerting (D7): does the Go app run the rule engine and the senders, with app.qpoint.io's four rule kinds and webhook adapter as the first spec, or is alerting a later phase?
6. The live tail: a stream from the Go app over ClickHouse with a cursor, or polling only at first?
7. Endpoint connect (c131 D13): credential format, enrolment, heartbeat cadence; does the heartbeat carry sensor version and health (gap 27)?
8. Contract generation: TypeScript (and Rust for the native app) from the Go handlers or a shared schema, per c131 R3?
9. demo.qpoint.io: do c113's baked worlds survive the new routes (they are keyed by URL), or is the demo re-baked against the new API?
10. Host-local actions (agent/focus, agent/reveal): confirm they leave the plane for the native app.
11. The qproxy settings (proxy, TLS, stacks, qtap filters): dropped, or does qproxy return under the plane?