XIOPro Production Blueprint v5.0¶

Part 6 — UI / Control Center¶

1. Purpose of This Part¶

This document defines the human control surface of XIOPro.

It specifies:

what the UI is for
how the founder interacts with brains
how governed human intervention works
how ContextPrompting appears in the operator workflow
how modules, research, governance, and cost become visible and actionable
how the system is expressed as a widget-based web application
how the same surface adapts to desktop and mobile use

The UI is not the execution engine.

It is:

the governed human interaction, supervision, and optimization surface

2. Core UI Principle¶

XIOPro is headless first and web based.

The UI is not required for execution correctness.

But the UI is required for:

low-friction human supervision
high-bandwidth collaboration with brains
intervention, approval, and recovery
visibility into work, cost, risk, and knowledge
research navigation and synthesis
deliberate control of prompting and module selection

The UI must never become the only place where important state exists.

All meaningful changes must become durable backend state.

3. Platform Principle¶

The XIOPro UI should be implemented as:

a web application
a widget-based control surface
a runtime-flexible grid layout
a mobile-capable responsive system

This gives XIOPro:

modularity
easier implementation
easier replacement and upgrades
clearer per-widget ownership
role-based and use-case-based layouts
future extensibility without redesigning the entire UI

4. UI Philosophy¶

The XIOPro UI must feel like:

a control center
a conversation surface
a work cockpit
a knowledge and research console
a governed intervention layer

It must not feel like:

a consumer chatbot clone
a fragile shell over hidden logic
a dashboard disconnected from execution
a UI-only workflow trap

5. Primary UI Goals¶

The UI must enable the founder/operator to:

talk to brains
collaborate with brains
see which brains are active
see what work is running
see what is blocked
see where cost is accumulating
see which module is being used and why
attach files, images, and research materials
choose Prompting Mode
choose search vs research behavior
choose style/output mode
use voice/audio when appropriate
approve, reject, redirect, or constrain work
navigate knowledge and research outputs
recover from drift or failure without confusion
use the same system from desktop and mobile with appropriate adaptation

6.1 Core Principle¶

Everything visible in XIOPro should be represented as a widget or as a layout container that hosts widgets.

The page is not the primary unit.

The widget is the primary unit.

This makes it easier to:

implement incrementally
update isolated functionality
compose different control surfaces
tailor layouts for different workflows
support desktop and mobile variations cleanly

Widgets are composable visual units, but they must not become isolated mini-apps with hidden local truth.

Each widget must remain backed by durable system objects.

Every widget should define at least:

Data Contract¶

What backend objects it reads.

Examples:

ticket
task
session
runtime
module recommendation
research output
alert
cost telemetry

Action Contract¶

What it may create or mutate.

Examples:

approve
reject
constrain
reroute
attach file
create research task
switch layout
request clarification

Refresh Contract¶

How live it is.

Examples:

hot
warm
cold

Layout Contract¶

Where it may appear and how it prefers to appear.

Examples:

center
side rail
bottom panel
modal only
mobile primary
mobile hidden
full-width capable

A widget may cache, stage, and draft local state.

But it must not become the only place where meaningful state exists.

Widgets must communicate through durable backend objects and an event/state layer, not through implicit UI coupling.

This prevents:

ghost state
hidden dependencies
inconsistent cross-widget behavior
layout changes breaking logic

7. Runtime-Flexible Grid Layout¶

7.1 Principle¶

The overall screen should be a runtime-flexible grid composed of widgets.

This grid should support:

resize
reorder
collapse
expand
dock/undock where justified
save preset
restore preset

7.2 Controlled Flexibility Rule¶

XIOPro should not begin as a fully unrestricted dashboard builder.

It should begin with:

a governed widget catalog
blessed layout presets
controlled rearrangement

This keeps:

documentation cleaner
support/debugging easier
operator experience more predictable
performance more manageable

7.3 Layout Presets¶

XIOPro should ship with at least these presets:

Control Center
Brain Collaboration
Research Desk
Module Portfolio
Governance / Recovery
Mobile Fast Board

7.4 Layout Persistence¶

Layouts should be persistable by:

user
workspace
preset
device class

8. Web and Mobile Principle¶

8.1 Web-Based First¶

XIOPro should be implemented as a browser-based application.

This makes it easier to support:

desktop
laptop
tablet
phone
remote access
future embedding or admin surfaces

8.2 Mobile Rule¶

Mobile support is required, but mobile should be a reduced-surface control mode, not a forced copy of the desktop experience.

8.3 Device-Class Behavior¶

Desktop / Large Screen¶

Optimized for:

multiple simultaneous widgets
side-by-side comparison
heavy operational visibility
research and governance work

Tablet¶

Optimized for:

two-pane or simplified multi-widget views
approvals
research review
moderate collaboration

Phone¶

Optimized for:

approvals
escalations
voice input
active brain conversation
quick research review
quick status and recovery guidance

9. Core UI Zones¶

flowchart TD
    TopBar[Top Bar / Global Status]
    LeftRail[Left Rail / Navigation]
    Center[Center Workspace Grid]
    RightRail[Right Rail / Context / Governance]
    BottomPanel[Bottom Panel / Logs / Cost / Trace]

    TopBar --> Center
    LeftRail --> Center
    Center --> RightRail
    Center --> BottomPanel

9.1 Top Bar¶

Minimum contents:

workspace / project
environment
global health
global cost pulse
active alert count
active escalation count
quick search
quick create action
operator identity
emergency pause access if allowed

9.2 Left Rail¶

Primary navigation spine.

Minimum sections:

Control Center
Brains
Tickets / Tasks
Research Center
Knowledge / Librarian
Governance / Alerts
Module Portfolio
Infrastructure / Ops
History / Decisions
Settings / Profiles

9.3 Center Workspace Grid¶

Primary widget grid area.

This is where the active preset is rendered.

9.4 Right Rail¶

Structured context and control surface.

Typical contents:

session context
task metadata
module details
active constraints
approvals required
knowledge refs
research refs

9.5 Bottom Panel¶

Operational trace surface.

Typical tabs:

activity log
task timeline
session timeline
cost / usage
module routing trail
errors / retries
raw events

10.1 Global / Shell Widgets¶

Shows:

system health
environment
cost pulse
alert count
escalation count
active brains

Refresh class: hot

Universal launcher for search, navigation, and actions.

Refresh class: warm

The Attention Queue is the primary surface where XIOPro communicates what it needs from the user. It is not a static list -- it revolves automatically based on system state. Items are auto-created when the system detects conditions requiring human attention, and auto-dismissed when those conditions clear.

Refresh class: hot (SSE push on every create/dismiss/update)

Auto-generated from system state:

attention_queue:
  auto_generated_from:
    - pending_escalations: "Creates todo when escalation needs human decision"
    - critical_alerts: "Creates todo when critical/warning alert fires"
    - agent_errors: "Creates todo when an agent enters error state"
    - stale_tasks: "Creates todo when tasks are stuck > 24 hours"
    - budget_warnings: "Creates todo when cost approaches monthly threshold"
    - pending_approvals: "Creates todo when governance requires approval"
    - context_rotation: "Creates todo when session context is approaching limits"

  auto_dismissed_when:
    - escalation_resolved: "Linked todo auto-completed"
    - alert_acknowledged: "Linked todo auto-completed"
    - agent_recovered: "Linked todo auto-completed"
    - task_unstuck: "Linked todo auto-completed"

  properties_per_item:
    - unique_number: sequential (UUID primary key)
    - title: short description
    - description: detailed (expandable)
    - priority: critical | high | medium | low
    - environment: where the action is needed (dns, github, hetzner, paperclip, devxio, bus, etc.)
    - linked_object: reference to the source (linked_type + linked_id)
    - linked_url: clickable link to the relevant object
    - created_at: when it was generated
    - created_by: system | GO | agent_name
    - assigned_to: user name (from User entity)
    - status: open | in_progress | done | dismissed
    - completed_at: when it was resolved (auto-set on done/dismissed)
    - sort_order: manual reordering within priority bands

Deduplication rule: Each auto-generated todo is keyed on linked_type + linked_id. If an open todo already exists for the same linked object, no duplicate is created. This makes the generation cycle idempotent and safe to run on any interval.

Generation triggers: 1. 60-second interval timer in the Bus server 2. Piggyback on SSE push events to the UI channel

Data contract: reads from user_todos table (Bus DB), escalation_requests (XIOPro DB), alerts (Bus DB), agent_registry (Bus DB), tasks (XIOPro DB), cost_ledger (XIOPro DB)

Action contract: mark done, dismiss, change priority, reassign, navigate to linked object

Layout contract: center or side rail, mobile primary

Condensed briefing of what changed, what matters, what is blocked, and what needs decision.

Refresh class: warm

10.2 Brain Interaction Widgets¶

Fast switching between brains with session awareness.

Refresh class: hot

Compact summary of a brain.

Shows:

role
status
current task
current module
cost pulse
attention state

Refresh class: hot

Primary human-to-brain conversation surface.

Must support:

exploratory conversation
execution-bound discussion
approvals
recovery conversation
promoted decisions
references and attachments

Implemented capabilities (as of 2026-03-29): - 9 chat panel features including message threading and history - ContextPrompting integration: prompting mode visible in panel header - SSE-streamed messages: responses stream in real-time via SSE, no polling required

Refresh class: hot

Shows:

runtime
session
linked ticket/task
constraints
assumptions
unresolved questions
escalation state

Refresh class: hot

Shows recent actions, tool calls, transitions, outputs, and errors.

Refresh class: hot

Focused surface for retry, reroute, resume, and escalation decisions.

Refresh class: hot when relevant, hidden otherwise

10.3 Prompting / Interaction Widgets¶

The most important widget.

Must support:

text input
add file
add image
drag-and-drop
paste image
voice/audio input
draft preservation
send / submit
current brain awareness

Refresh class: hot

Human-facing selector backed by ContextPrompting.

Values:

Direct
Governed
Clarify
Collaborate

Default:

Collaborate

This may be embedded inside Prompt Composer or rendered as an adjacent widget.

Shows current blocking and optional questions from the prompt steward role.

Refresh class: hot when active

Shows active assumptions, with ability to confirm, revise, or clarify.

Refresh class: warm

Shows the assembled execution package:

goal
constraints
assumptions
rule refs
skill refs
human answers
relevant context refs

Refresh class: warm

10.4 Work Graph Widgets¶

High-level ticket workspace.

Refresh class: warm

Task hierarchy, dependencies, blockers, and state.

Refresh class: warm

Per-task or per-session activity sequence.

Refresh class: warm

Artifacts, outputs, exports, and previews.

Refresh class: warm

10.5 Research Center Widgets¶

Scheduled and active research tasks.

Refresh class: warm

Recurring research jobs and refresh cycles.

Refresh class: warm

Curated research packets.

Refresh class: warm

Digest, comparison, briefing, or synthesis output.

Refresh class: warm

Packet-prep and export visibility for NotebookLM-oriented workflows.

Refresh class: warm

Topic-linked exploration surface for governed knowledge navigation.

Refresh class: warm

Candidate module and technology scans, including Hugging Face and related research results.

Refresh class: warm

10.6 Knowledge Widgets¶

Search by metadata, text/content, or context.

Refresh class: warm

Document viewer with lineage, version, and classification info.

Refresh class: warm

Inspection and comparison of governed behavior-shaping assets.

Refresh class: warm

Source → synthesis → governed asset / output lineage.

Refresh class: cold/warm

10.7 Governance Widgets¶

Severity-coded alerts with acknowledgement and drill-down.

Implemented capabilities (as of 2026-03-29): - Priority icons and severity filtering (critical / warning / info) - Flash threshold: alerts flash on new critical events - Click-to-dialog: clicking an alert opens a detail dialog with full context and action options - Acknowledgement per alert - Browser notifications for critical alerts and task assignments

Refresh class: hot

Breaker type, state, evidence, action, and override availability.

Refresh class: hot when active

Why a policy action occurred and what it affected.

Refresh class: warm

Pending approvals and constrained decisions.

Refresh class: hot

Controlled override surface with explicit audit warning.

Refresh class: warm/hot

Review of approvals, redirects, rejects, and constraints.

Refresh class: warm

10.8 Module Portfolio Widgets¶

Current, recommended, and fallback module selection surface.

Refresh class: warm/hot

Reasoning behind the current recommendation.

Refresh class: warm

Compare quality, latency, cost, trust, access path, and fallback posture.

Refresh class: warm

Visibility into subscription-backed, API-backed, and self-hosted availability.

Refresh class: warm

Can a candidate run on Mac, cloud node, GPU node, or hybrid path?

Refresh class: warm

New candidates, subscriptions, and self-hosted leads under evaluation.

Refresh class: warm

10.9 Cost / Telemetry Widgets¶

Live high-level cost signal.

Refresh class: hot

Project / ticket / task / runtime / session breakdown.

Refresh class: warm

Usage by module, access path, and task class.

Refresh class: warm

Instability and hidden-cost signal.

Refresh class: warm/hot

Compute, memory, bandwidth, and queue pressure.

Refresh class: warm

10.10 Ops / Infrastructure Widgets¶

Hetzner / Mac / GPU / product node health.

Refresh class: warm/hot

Service placement and current health.

Refresh class: warm

Current version, migration state, last deploy, and current rollout posture.

Refresh class: warm

Backup status and restore-drill status.

Refresh class: warm

Embedded terminal surface for direct command execution on connected hosts.

Implemented capabilities (as of 2026-03-29): - xterm.js-backed terminal emulator with full VT100 support - Echo mode: local command echo before remote response arrives - Connected to agent host via Bus relay

Refresh class: hot when active

Dropdown/selector for switching active project context across the Control Center.

Implemented capabilities (as of 2026-03-29): - Loads real project list from /projects API - lifecycle_phase displayed per project (discovery / active / paused / complete) - Selection propagates project context to connected widgets

Refresh class: warm

11. Primary Workspaces / Layout Presets¶

11.1 Control Center¶

Recommended widgets:

Global Status Bar
Attention Queue
Alerts
Approvals Inbox
Active Brain Cards
Cost Pulse
Daily Brief

11.2 Brain Collaboration¶

Recommended widgets:

Brain Conversation
Prompt Composer
Session Context
Brain Trace
Inquiry Queue
Assumptions
Prompt Package Inspector

11.3 Research Desk¶

Recommended widgets:

Research Queue
Research Calendar
Source Bundle
Research Output
NotebookLM Packet
Obsidian Topic Map
Candidate Scan

11.4 Module Portfolio¶

Recommended widgets:

Module Compare
Subscription Coverage
Hosting Feasibility
Candidate Discovery
Module Usage
Cost by Scope

11.5 Governance / Recovery¶

Recommended widgets:

Alerts
Breaker State
Governance Decision
Approvals Inbox
Recovery Widget
Human Decision Log

11.6 Mobile Fast Board¶

Recommended widgets:

Active Brain / Brain Switcher
Prompt Composer with voice
Approvals Inbox
Alerts
Attention Queue
Daily Brief

11A. T1P UI Scope (v5.0 Addition)¶

11A.1 Purpose¶

The full widget catalog and layout preset list above represents the complete XIOPro UI vision. For T1P, the UI must be scoped to what can be built, tested, and proven within the T1P timeline without becoming a multi-month frontend project.

11A.2 Must Have (First Wave)¶

These are required for T1P to be functional as a human control surface.

The shell (top bar + left rail + center grid) is the structural frame that hosts everything else. It is the prerequisite, not a widget.

The 6 must-have T1P widgets are:

Agent Status Grid -- shows registered agents, their roles, status (active/idle/offline), current task, last heartbeat. Data source: Control Bus agent registry. Refresh: hot (SSE push on heartbeat/status change).
Task Board -- kanban-style board with columns: todo / in_progress / done / blocked. Filterable by project, agent, priority. Data source: ODM task table via Bus API. Refresh: warm (poll every 30s or SSE on task state change).
Alerts Panel -- active alerts and interventions from the governor. Severity-coded (critical/warning/info). Acknowledge button per alert. Data source: governance events via Bus API. Refresh: hot (SSE push on new alert).
Cost Summary -- running cost per agent, per project. Daily/weekly/monthly view toggle. Data source: cost ledger via Bus API. Refresh: warm (poll every 60s).
Prompt Composer -- unified input surface for interacting with any agent via RC. Supports: text input, file attach, send, brain selector. Data source: writes to Bus messaging API. Refresh: hot (conversation is real-time).
Activity Feed -- real-time SSE feed of recent activities across all agents. Shows: agent, action, target, timestamp. Data source: SSE event stream from Control Bus. Refresh: hot (streaming).
Attention Queue -- revolving user todo list, auto-populated from system state. Shows: pending escalations, unacknowledged alerts, agent errors, stale tasks, budget warnings, pending approvals. Each item links to its source object. Items auto-dismiss when the condition clears. Data source: Bus user_todos table + auto-generation from escalations, alerts, agents, tasks, cost_ledger. Refresh: hot (SSE push on create/dismiss).

These 7 widgets plus the shell frame provide the minimum viable Control Center for XIOPro.

The Control Center preset arranges all 6 widgets in the center grid. The Brain Collaboration preset reuses the Prompt Composer and Activity Feed with an added session context viewer.

11A.3 Second Wave¶

These should follow once the first wave is proven:

Approval/alert widgets -- structured approval inbox, severity-coded alerts with drill-down
Research Desk basics -- research queue, research output viewer, source bundle viewer
Mobile reduced-surface mode -- phone-optimized view with approvals, alerts, brain conversation, voice

11A.4 Defer¶

These are architecturally valid but should not be built in T1P:

Module Portfolio workspace (full widget set)
Full Governance workspace (override console, breaker state, governance decision log)
All 50+ widget catalog items
Advanced layout customization (drag-and-drop grid rearrangement, custom presets, dock/undock)
NotebookLM Packet widget (NotebookLM not deployed)
Obsidian Topic Map widget (Obsidian not deployed)
Candidate Scan / Hosting Feasibility widgets (module steward starts narrow)

11A.5 Scoping Rule¶

The T1P UI must prove:

the shell works
prompting works
brain collaboration works
basic operational visibility works

Before expanding into the full widget catalog, these four capabilities must be functional and tested.

12. Prompt Composer Specification¶

See resources/DESIGN_rc_architecture.md for the Remote Control architecture design covering how the Prompt Composer connects to Open WebUI, Claude RC, and other interaction surfaces through the Control Bus.

12.1 Purpose¶

The prompt composer is the unified interaction composer for XIOPro brains.

It is not a simple chat textbox.

12.2 Required Controls¶

It should support at least:

text input
file upload
image upload
drag-and-drop
paste image
voice/audio input
send
draft persistence
Prompting Mode
search vs research toggle
style selector
module/model selector

12.3 Prompting Mode¶

UI label:

Prompting Mode

Values:

Direct
Governed
Clarify
Collaborate

Architecture backing:

ContextPrompting / prompt steward role

12.4 Search vs Research¶

The composer should separate:

Search
Research

Search = direct lookup Research = deeper multi-step investigation and synthesis

12.5 Style Control¶

Styles may come from:

built-in styles
project styles
founder styles
imported writing samples
role-specific styles

12.6 Module / Model Controls¶

Expose:

selected module
recommended module
fallback module
access path
constraint warning if applicable

12.7 Persistence Rule¶

Not every message must mutate workflow.

But if input materially changes:

execution direction
constraints
approval state
recovery path
task interpretation
module choice

it must become durable operational state.

13. VS Code Boundary¶

13.1 Principle¶

Not all editing belongs in the XIOPro web UI.

Where IDE-style editing is more efficient, it may remain in VS Code.

13.2 Keep in VS Code First¶

For T1P, these can remain primarily VS Code-based:

rules
skills
activations
protocol docs
YAML-heavy policies
runbooks
configuration templates
migration and deployment files

13.3 XIOPro Config Editor Future¶

A later VS Code extension may provide:

governed asset tree
custom editors
diff-aware editing
prompt-assisted editing
API/MCP link to XIOPro validation and approval flows

The web UI does not need to replace VS Code immediately.

14. Performance Rules¶

14.1 Core Principle¶

A widget-based runtime grid is correct for XIOPro, but performance discipline is mandatory.

14.2 Live-Tier Classification¶

Widgets should be classified as:

hot
warm
cold

Hot¶

Live or near-live widgets.

Examples:

alerts
active conversation
approvals
cost pulse
attention queue

Warm¶

Moderately refreshed widgets.

Examples:

task tree
module compare
research queue
cost breakdown

Cold¶

Load on demand.

Examples:

archived logs
older lineage views
historical research bundles

14.3 Lazy Loading Rule¶

Heavy widgets should load data only when:

visible
opened
expanded
explicitly refreshed

14.4 Virtualization Rule¶

Long lists must be virtualized.

Examples:

conversation threads
logs
traces
large tables
research result lists

14.5 Subscription Rule¶

Each widget should subscribe only to the events it actually needs.

Avoid page-wide state floods.

14.6 Layout Rule¶

Moving or resizing a widget should not force heavy data reload unless necessary.

15. Open-Source Component Direction¶

The UI architecture should remain compatible with a stack such as:

React
shadcn/ui
React-Grid-Layout
TanStack Query
TanStack Table
React Virtuoso
Recharts

This is an implementation direction, not a hard product dependency, but it aligns well with XIOPro's needs.

16. Mobile / Reduced-Surface Mode¶

16.1 Purpose¶

Mobile mode preserves critical founder control without forcing full desktop parity.

16.2 Priorities¶

Mobile should prioritize:

active brain conversation
voice input
alerts
approvals
escalations
quick status
quick research review
lightweight recovery guidance

16.3 Non-Goal¶

Phone mode should not attempt to render every desktop widget simultaneously.

17. UI State Principles¶

17.1 No UI-Only Truth¶

All meaningful state changes must persist in backend objects.

17.2 Low Friction, High Clarity¶

The UI should reduce friction without hiding reality.

17.3 Progressive Complexity¶

Expose rich power, but not all at once.

17.4 Explainability¶

The UI should help the founder understand:

what the system is doing
why it is doing it
what can be changed
what needs approval

18. Current State & Dashboard Migration Path (v5.0 Addition)¶

18.1 Current Dashboard¶

dashboard.struxio.ai (React) is the current operational dashboard.

It provides basic visibility into system state but does not support the full XIOPro interaction model (brain collaboration, prompting, governance, research).

18.2 Migration Path¶

The current dashboard keeps running during the XIOPro UI transition.

Migration strategy:

Parallel operation: New XIOPro Control Center is built alongside the existing dashboard. Both run simultaneously.
Feature parity checkpoint: The new Control Center must reach functional parity with the existing dashboard before any cutover is considered.
Cutover: When the new Control Center provides equivalent or better visibility, the old dashboard is retired.
No big-bang: There is no point where the old dashboard is removed before the new one is proven.

18.3 Rule¶

The existing dashboard is not removed, deprecated, or disrupted until the XIOPro Control Center can fully replace it. Parallel operation is the default during transition.

19. UI Success Criteria¶

The UI is successful when:

the founder can talk to brains naturally
collaboration with brains improves outcomes
execution-linked conversations remain traceable
module choice and cost are visible and understandable
research becomes easy to create, review, and reuse
governance actions are legible and actionable
attachments, voice, style, and search/research controls feel native
desktop and mobile both remain useful without becoming separate products
the UI accelerates XIOPro without becoming its hidden dependency

20. Final Statement¶

The XIOPro UI is not a chatbot shell.

It is a widget-based, web-first, mobile-capable governed control center for:

conversation
collaboration
supervision
research
intervention
optimization
trust-preserving execution

21. Design Concept Prompts¶

21.1 Research Desk Design Concept¶

An external design pass emphasized that the Research Desk preset should feel meaningfully different from the Control Center and Brain Collaboration presets.

The Research Desk should shift the UI focus from real-time execution supervision toward:

deep knowledge synthesis
source lineage
fact-checking
curated source bundles
dataset and document comparison
research task execution and review

Recommended visual emphasis:

a large central Research Synthesis widget as the primary reading and reasoning surface
a right-side knowledge panel for:
indexed documents
trusted internal sources
active research workers
topic-map exploration
a research-adapted Prompt Composer with defaults oriented toward:
deeper inquiry
knowledge-aware prompting
research-specific model selection
a lower trace surface focused on:
search queries
token cost
knowledge graph traversal
source lineage

The design goal is to preserve the same XIOPro product identity while making the Research Desk feel like a true research workstation, not merely a variation of the execution dashboard.

Design Rule¶

Each layout preset should preserve the common XIOPro design system, but visibly prioritize the dominant workflow of that preset.

For the Research Desk, that dominant workflow is:

collection → curation → synthesis → lineage review → knowledge promotion

Changelog¶

Version	Date	Author	Changes
4.1.0	2026-03-27	BM	Initial v4.1 release
4.2.0	2026-03-28	BM	Added: T1P UI scope narrowing (11A) -- must-have, second wave, and deferred items. Added: Current dashboard migration path (18) -- parallel operation, no big-bang cutover. Fixed: "Rufio" renamed to "Ruflo" globally (no occurrences in Part 6). Added: Current State section (18) with dashboard migration details. Added: Changelog section. Updated version header to 4.2.0.
4.2.2	2026-03-28	000	Agent naming migration: P01 replaced with prompt steward role. M01 replaced with module steward role. Changelog author entries preserved as historical.
4.2.9	2026-03-28	000	Wave 1-2 BP fixes: Rewrote Section 11A.2 Must Have (First Wave) — replaced 4 abstract deliverables with 6 concrete, buildable T1P widgets: Agent Status Grid, Task Board, Alerts Panel, Cost Summary, Prompt Composer, Activity Feed. Each widget specifies data source, refresh class, and key functionality.
4.2.10	2026-03-29	BM	Attention Queue Widget: Expanded Section 10.1 Attention Queue from one-liner to full specification with auto-generation triggers, auto-dismiss rules, dedup contract, YAML schema, and data/action/layout contracts. Added Attention Queue as 7th must-have T1P widget in Section 11A.2.
4.2.13	2026-03-29	000	Batch BP update from recent tickets: Alerts Widget (10.7) — priority icons, filters, flash, click-to-dialog, browser notifications. Brain Conversation Widget (10.2) — 9 chat features, ContextPrompting, SSE messages. Added Terminal Widget (10.10) — xterm.js, echo mode. Added Project Selector Widget (10.10) — real /projects data, lifecycle_phase.
4.2.12	2026-03-29	BM	Cross-references: Added pointer to `resources/DESIGN_rc_architecture.md` in Section 12 (Prompt Composer) — RC architecture design for multi-surface interaction routing through the Control Bus.

XIOPro Production Blueprint v5.0¶

Part 6 — UI / Control Center¶

1. Purpose of This Part¶

2. Core UI Principle¶

3. Platform Principle¶

4. UI Philosophy¶

5. Primary UI Goals¶

6. Widget-Based UI Architecture¶

6.1 Core Principle¶

6.2 Widget System Rule¶

6.3 Widget Contract Model¶

Data Contract¶

Action Contract¶

Refresh Contract¶

Layout Contract¶

6.4 No Widget-Only Truth¶

6.5 Widget Interaction Backbone¶

7. Runtime-Flexible Grid Layout¶

7.1 Principle¶

7.2 Controlled Flexibility Rule¶

7.3 Layout Presets¶

7.4 Layout Persistence¶

8. Web and Mobile Principle¶

8.1 Web-Based First¶

8.2 Mobile Rule¶

8.3 Device-Class Behavior¶

Desktop / Large Screen¶

Tablet¶

Phone¶

9. Core UI Zones¶

9.1 Top Bar¶

9.2 Left Rail¶

9.3 Center Workspace Grid¶

9.4 Right Rail¶

9.5 Bottom Panel¶

10. Widget Catalog¶

10.1 Global / Shell Widgets¶

Global Status Bar Widget¶

Command Palette Widget¶

Attention Queue Widget (User ToDo / Revolving Attention Queue)¶

Daily Brief Widget¶

10.2 Brain Interaction Widgets¶

Brain Switcher Widget¶

Brain Card Widget¶

Brain Conversation Widget¶

Session Context Widget¶

Brain Trace Widget¶

Recovery Widget¶

10.3 Prompting / Interaction Widgets¶

Prompt Composer Widget¶

Prompting Mode Widget¶

Inquiry Queue Widget¶

Assumptions Widget¶

Prompt Package Inspector Widget¶

10.4 Work Graph Widgets¶

Ticket Board Widget¶

Task Tree Widget¶

Activity Timeline Widget¶

Deliverables Widget¶

10.5 Research Center Widgets¶

Research Queue Widget¶

Research Calendar Widget¶

Source Bundle Widget¶

Research Output Widget¶

NotebookLM Packet Widget¶

Obsidian Topic Map Widget¶

Candidate Scan Widget¶

10.6 Knowledge Widgets¶

Librarian Search Widget¶

Knowledge Document Widget¶

Rule / Skill / Activation Widget¶

Knowledge Lineage Widget¶

10.7 Governance Widgets¶

Alerts Widget¶

Breaker State Widget¶

Governance Decision Widget¶

Approvals Inbox Widget¶

Override Console Widget¶

Human Decision Log Widget¶

10.8 Module Portfolio Widgets¶