Wire-Bob
Rapid wireframe prototyping. Agent-driven workflow for turning specs into clickable HTML wireframes.
View deployed wireframes →GitHub Pages Deploy
c7April 2026Static deploy to GitHub Pages. One command to publish.
npm run deploy — runs nuxt generate then gh-pages -d .output/public. Publishes the full static site to the gh-pages branch.
app.baseURL: '/bob-wire/' added to nuxt.config.ts so NuxtLinks resolve correctly under the GitHub Pages subpath.
Narrative
Devs needed to review wireframes without running a local server. The solution: generate the static site locally and push to GitHub Pages with a single command. The gh-pages package handles branch management; the baseURL config ensures internal navigation works under the subpath.
This is a temporary solution until bob-wire gets a Cloudflare Pages deployment like the design site. For now, npm run deploy publishes the full prototype to qpoint-io.github.io/bob-wire.
Dashboard Prototype
c6March 202625 wireframe pages. The full AI agent observability dashboard, clickable end-to-end.
WireDashGlobalNav + WireDashCategoryNav — shared navigation shell across all 25 pages. No WireHeader; navigation IS the chrome.
Home, Security, Alerting, Inventory hub, and list + detail views for all 10 entity types (Sessions, Agents, Users, MCP Servers, Models, API Keys, Endpoints, Capabilities, Files, Secondary Calls). Settings placeholder.
All list rows navigate to their respective detail pages. Full cross-page flow wired.
Narrative
C5 built the data model. C6 turned it into a walkable prototype. The navigation shell — a persistent global nav plus a per-section category nav — provides orientation across 25 pages without per-page chrome overhead. Every list row links to its detail page; every detail page links back.
The inventory section is the core of the prototype. Ten entity types, each with a list page and a detail page, all sharing the same nav shell and layout pattern. The consistency was intentional — operators need to develop muscle memory across entity types, not re-learn the interface for each one.
Dashboard Reframing
c5March 2026Shifted framing from vendor egress to AI agent observability. Data model first.
Full enumeration of observable data from privileged system-level oversight: network, MCP, file system, process metadata.
10 inventory entities across 5 categories — Core (Agent, Session), Identity (User), Provider (Model), Capabilities (MCP Server, Capability, File), Exposure (Endpoint, API Key, Secondary Call).
Agent inventory prototype: overview, sessions, detail pages as proof-of-concept for the inventory UI pattern.
Narrative
The original dashboard framed Qpoint as vendor egress monitoring. This cycle reframed it around a more complete question: what is every AI agent in this organization doing, and is that behavior safe? The reframe required establishing a data model before designing any UI.
Ten inventory entities cover the full observability surface — from the agent identity and session history at the core, to the models and MCP servers it calls, to the files it touches and the secondary network calls it makes. The model feeds directly into c6, which maps it to a complete navigable prototype.
AI Agents Entity
c4March 2026First AI-native entity: autonomous AI systems as observable actors.
AI Agent entity — represents autonomous AI systems (Claude Code, LangChain, Cursor) whose API traffic flows through Qpoint.
Agent index (multi-perspective: by agent, user, cost, model), Sessions list (per-agent history), Session detail (events timeline, metrics, proxy data).
Drill-down flow: index → sessions → session detail.
Narrative
AI agents are increasingly autonomous actors in enterprise environments — making API calls, invoking tools, reading files. Qpoint already observes their traffic. This cycle turned that raw observability into a designed entity with a coherent information architecture.
The multi-perspective index was the key design decision: the same agents can be analyzed by agent identity, by the user who triggered them, by cost center, or by model usage. Each lens surfaces different operational questions. Session detail went deep — events timeline, token metrics, context growth — because understanding a session's behavior is the core value proposition.
Dataflows
c3March 2026New entity IA: Dataflow as a first-class pathway between endpoints.
Dataflow entity — represents a pathway between two endpoints with sensitivity classification, data types, and policy coverage.
Overview (health dashboard + governance gaps), Listing (sortable table with 6 filters + expand-to-card), Detail (informational + configuration split).
Full flow connected via WireNav + contextual links. Cross-feature link to policy-compliance violation page.
Narrative
The Dataflow entity addresses a recurring question in enterprise data governance: not just what's talking to what, but what data is crossing which boundaries. The three-page IA — overview, listing, detail — mirrors the pattern established for policy compliance: landscape health, filterable inventory, full entity view.
The listing page carries most of the analytical weight. Six simultaneous filters (source, destination, sensitivity, coverage, protocol, encryption) let operators slice the inventory by risk dimension. Expand-to-card reveals the full flow profile inline — data type badges, connection preview — before committing to the detail view.
Situation Room
c1March 2026A problem-space command center for data governance. First instance: Policy Compliance.
Situation Room pattern — systemic health overview, problem areas, context, and remediation pathways. Reusable pattern class, not a single page.
policy-compliance-v1 — Situation Room applied to the Policy Compliance domain.
Narrative
The Situation Room started as a wireframe for a single page but evolved into a reusable pattern class. The idea: a command center that shows systemic health, highlights problem areas, provides context for each problem, and offers remediation pathways. The first instance targets Policy Compliance.
Grounding the wireframe in real customer language (from market-analyst data) made the design decisions concrete rather than hypothetical. Pain points from actual sales calls shaped the information hierarchy — what goes front and center versus what lives in drill-down views.
Foundation
c0February 2026Wireframe primitives, agent pipeline, and the first prototypes.
13 Wire* components: WireBox, WireCard, WireForm, WireTable, WireHeader, WireNav, WireList, WireSidebar, WireChart, WireMetric, WireButton, WireInput, WireToggle.
8 specialized agents: write-brief, ingest, wireframe, mockup, review, iterate, flow, cycle.
wireframe-registry.ts — central metadata for all wireframes and mockups with version tracking.
Policies (v1, v2) and Vendors (v1) — policy management overview, editor, exceptions views.
Narrative
Wire-Bob operates at two fidelity levels. Wireframes use Wire* components — grey borders, dashed placeholders, minimal styling. Mockups use real design system components from q-nuxt-layer. The two levels serve different conversations: wireframes for structure and flow, mockups for visual validation.
The agent pipeline turns this into a repeatable workflow. Write a brief, generate a wireframe, review it against the brief, iterate with specific changes. Each agent has a narrow focus and structured input/output. The registry tracks every version so nothing gets lost.