@jaimevalasek/aioson 1.3.0

package/template/.aioson/skills/references/premium-command-center-ui/master-application-prompt.md

@@ -0,0 +1,79 @@
+# Master Application Prompt
+
+Use the prompt below when another agent needs to apply `premium-command-center-ui` to a new project.
+
+---
+
+## Prompt
+
+```text
+Apply the `premium-command-center-ui` skill to this project.
+
+Your job is to produce a premium operational interface derived from the real AIOS Dashboard patterns, not a generic dark admin panel.
+
+Work from the current codebase and data model first. Do not invent abstract design systems disconnected from the implementation.
+
+Required behavior:
+1. Inspect the existing routes, components, and real domain objects before proposing layout changes.
+2. Identify the true operational nouns and verbs of the product.
+3. Translate raw domain records into UI-native objects when needed (for example: lanes, queues, memory assets, grouped registries, current signal summaries).
+4. Choose the right page archetype per route:
+   - command center overview
+   - queue / control tower
+   - workflow catalog
+   - knowledge explorer
+   - grouped registry
+5. If the product has enough complexity, use a tri-rail shell on desktop:
+   - left navigation
+   - center workspace
+   - right contextual activity rail
+6. Preserve the visual system:
+   - deep graphite or cool-mist base
+   - aurora page atmosphere
+   - borders-first depth
+   - 3 surface levels max
+   - compact density
+   - restrained semantic tones
+7. Preserve the interaction system:
+   - search-first top bar
+   - command palette if route count justifies it
+   - direct drill-down actions inside major cards
+   - styled empty states
+   - contextual status/history/metrics support
+8. Keep the result responsive by collapsing progressively rather than inventing a disconnected mobile UI.
+9. Avoid generic solutions:
+   - no flat card wall
+   - no washed-out contrast
+   - no oversized spacing
+   - no random gradients
+   - no equal importance for every section
+10. Implement real code, not a moodboard.
+
+Before coding, state briefly:
+- visual direction
+- shell decision
+- page archetype per affected route
+- primary reusable components you will create or reuse
+
+During implementation, maintain these quality rules:
+- runtime / primary operations appear before infrastructure
+- one focal block per page
+- every major card has a next action when relevant
+- semantic colors mean something specific
+- compact density is preserved
+- premium feel comes from behavior as much as appearance
+
+Final output must include:
+- what changed in the UI and why
+- which components or routes were updated
+- responsive notes
+- validation against the premium-command-center-ui checklist
+```
+
+---
+
+## How to use this prompt
+
+- Use it when the target project is operational, multi-module, and needs a premium shell.
+- Pair it with the visual system and UX playbook references, not by itself.
+- If the project is a landing page or marketing site, do not use this prompt; use a site-focused skill instead.

package/template/.aioson/skills/references/premium-command-center-ui/operational-ux-playbook.md

@@ -0,0 +1,253 @@
+# Operational UX Playbook
+
+> This reference documents the UX logic extracted from the AIOS Dashboard implementation.
+> Use it when defining navigation, hierarchy, grouping, page composition, and interaction patterns.
+
+---
+
+## 1. Core UX principle
+
+This system treats the product like an operating surface.
+
+That means:
+
+- the user should see current pressure first
+- the next useful action should be one click away
+- supporting history and metrics should stay available without taking over the page
+- the UI should guide the user through live state, not just display records
+
+---
+
+## 2. Hierarchy rules extracted from the dashboard
+
+### Rule 1: runtime before infrastructure
+
+Operational signals must appear above:
+
+- paths
+- configuration
+- administrative utilities
+- long explanatory blocks
+
+This was applied directly in the dashboard: runtime, agents, tasks, workflows, and memory lanes moved above lower-priority infrastructure.
+
+### Rule 2: one dominant section per screen
+
+Each premium route has one primary working area:
+
+- overview: runtime pulse
+- tasks: control tower
+- workflows: execution topology + catalog
+- memories: memory model + fresh assets
+
+Everything else is secondary support.
+
+### Rule 3: grouped meaning beats flat listing
+
+Do not show long ungrouped lists when the records can be grouped by origin, momentum, layer, or domain.
+
+Real examples from the implementation:
+
+- agents split into official vs squad agents
+- squad agents grouped by squad
+- workflows represented as lanes per squad
+- memories grouped into foundation / generated / capabilities
+
+---
+
+## 3. Navigation pattern
+
+The navigation stack has three layers:
+
+### Left rail
+
+Permanent product modules and project switching.
+
+Use it for:
+
+- top-level routes
+- project/workspace selector
+- persistent product identity
+
+### Top search bar
+
+This is a search-first control strip.
+
+Include:
+
+- command palette entry point
+- active route label
+- active project chip
+- system utility such as theme toggle or live status chip
+
+### Right activity rail
+
+Keep contextual panels visible on desktop.
+
+The shipped pattern uses three tabs:
+
+- `Status`
+- `History`
+- `Metrics`
+
+This is important: the right rail should never be decorative. It must summarize the current route context and provide quick drill-downs.
+
+---
+
+## 4. Search-first interaction
+
+The premium feel improved because navigation stopped depending only on the left rail.
+
+Required behaviors:
+
+- command palette open via `Ctrl/Cmd + K`
+- close via `Esc`
+- immediate focus on the search field
+- searchable items drawn from real routes and project context
+- result items should be clickable cards, not plain text rows
+
+If a dashboard has many modules and no fast command surface, it will feel slower than it looks.
+
+---
+
+## 5. Page archetypes extracted from the implementation
+
+### A. Command center overview
+
+Use when the user needs a system pulse before drilling deeper.
+
+Composition:
+
+- metrics row
+- runtime pulse block
+- project snapshot
+- momentum boards for workflows, queue, memory
+
+### B. Queue / control tower
+
+Use when a route is primarily about active work items.
+
+Composition:
+
+- metrics row
+- left column: load mix + active queue
+- right column: backlog / recent history
+- bottom: grouped load map or concentration map
+
+### C. Workflow catalog
+
+Use when a route represents grouped execution lanes or modules.
+
+Composition:
+
+- metrics row
+- left: capacity topology / featured lanes
+- right: dense lane catalog
+
+### D. Knowledge explorer
+
+Use when surfacing memory, assets, documents, or learned context.
+
+Composition:
+
+- metrics row
+- model explanation or layer summary
+- recent asset stream
+- grouped knowledge columns
+
+### E. Grouped registry
+
+Use when a route is still index-like but should not feel flat.
+
+Composition:
+
+- metrics row
+- registry header
+- segmented groups with direct actions inside each group
+
+---
+
+## 6. Data modeling for premium UX
+
+A key implementation pattern was to build UI-specific records instead of binding components directly to raw data.
+
+Reuse this pattern in new projects:
+
+- create aggregated task records that already know their group, counts, and latest signal
+- create workflow records that already know momentum and capability volume
+- create memory or asset records that already know scope, kind, and source
+
+This lets the UI stay concise and intentional.
+
+---
+
+## 7. Interaction patterns to preserve
+
+### Project switcher
+
+- collapsible panel in the left rail
+- active project clearly highlighted
+- switching should preserve current route when possible
+
+### State tabs
+
+- use compact segmented controls for status / history / metrics
+- active state gets a premium fill, not just bold text
+
+### Direct action cards
+
+- every major card should offer the next drill-down
+- do not force the user to navigate back to the left rail for everything
+
+### Empty states
+
+- use styled empty states with dashed border and an orientation sentence
+- explain what will populate this area and where the user should go next
+
+### Theme toggle
+
+- small persistent utility
+- should feel integrated, not like a floating widget
+
+---
+
+## 8. Responsive playbook
+
+The responsive strategy is progressive collapse, not redesign.
+
+- keep the same route structure on mobile/tablet
+- hide the right rail below desktop
+- stack split sections vertically
+- let chips and actions wrap naturally
+- keep titles, helper text, and action labels short enough to survive narrower widths
+
+Avoid shipping a dense desktop layout with no collapse strategy.
+
+---
+
+## 9. Anti-patterns extracted from what was improved
+
+Avoid these regressions:
+
+- placing paths, IDs, and infrastructure blocks above runtime-critical information
+- leaving all cards with the same visual weight and no focal block
+- separating related items into different screens when grouped cards would work better
+- over-expanding padding and gaps until the dashboard feels empty
+- making the premium layer only visual, with no navigation or interaction upgrade
+- using status colors as decoration rather than meaning
+- rendering every route as the same metric-row-plus-card-grid template without adapting to the job of the page
+
+---
+
+## 10. What creates the premium feel in UX terms
+
+The premium effect is the combination of:
+
+- a productized shell
+- faster route entry through search
+- contextual side information always available
+- clear operational hierarchy
+- grouped drill-downs that match how the user thinks
+- reduced friction between reading and acting
+
+If the UI looks expensive but still feels slow to operate, the premium bar was missed.

package/template/.aioson/skills/references/premium-command-center-ui/quality-validation-checklist.md

@@ -0,0 +1,82 @@
+# Quality Validation Checklist
+
+> Run this before shipping any UI that claims to follow `premium-command-center-ui`.
+
+---
+
+## A. Visual system
+
+- [ ] The page uses a clear premium direction, not a default dark theme.
+- [ ] There are no more than 3 major surface levels.
+- [ ] Borders are visible and consistent across major panels.
+- [ ] Shadows belong to one family only.
+- [ ] Semantic colors are limited to clear roles (`accent`, `success`, `warning`, `danger`, `violet`, `neutral`).
+- [ ] The background atmosphere is intentional and restrained.
+
+## B. Typography and density
+
+- [ ] Eyebrows, headings, helper text, and monospace metadata follow a consistent hierarchy.
+- [ ] Titles use stronger weight and tighter tracking than body copy.
+- [ ] Density feels compact and operational, not empty and oversized.
+- [ ] Repeated paddings, radii, and gaps follow one compact scale.
+
+## C. Layout and hierarchy
+
+- [ ] The primary operational signal is above infrastructure and secondary metadata.
+- [ ] Each page has one obvious focal block.
+- [ ] The route composition matches its job (overview, queue, catalog, explorer, registry).
+- [ ] Long flat lists were replaced by grouped or segmented structures where appropriate.
+- [ ] Important counts or statuses are visible without scrolling deep into the page.
+
+## D. Shell and navigation
+
+- [ ] The shell feels like a product operating surface, not just page chrome.
+- [ ] Left navigation exposes real first-class modules only.
+- [ ] Top search or command access exists when route count or complexity justifies it.
+- [ ] Contextual status/history/metrics are available somewhere persistent when needed.
+- [ ] Cards or grouped rows expose direct drill-down actions.
+
+## E. Component quality
+
+- [ ] Major cards have clear default and hover states.
+- [ ] Active or selected states are visually distinct.
+- [ ] Empty states are intentionally designed, not plain paragraphs.
+- [ ] Error and warning surfaces use the semantic tone system.
+- [ ] Utility controls (toggle, tabs, segmented filters, search triggers) feel integrated into the shell.
+
+## F. Responsiveness
+
+- [ ] The desktop shell collapses progressively instead of breaking.
+- [ ] Split sections stack cleanly below large breakpoints.
+- [ ] Action rows and chips wrap safely.
+- [ ] No critical context disappears without an alternate access path.
+- [ ] Text labels remain legible and do not overflow in common viewport widths.
+
+## G. Accessibility
+
+- [ ] Interactive elements remain keyboard reachable.
+- [ ] Focus states are visible.
+- [ ] Body text contrast is comfortable for long reading.
+- [ ] Meaning is not conveyed by color alone.
+- [ ] Modals, overlays, and drawers have obvious close behavior.
+
+## H. Premium feel audit
+
+- [ ] The interface feels faster to use, not only more decorated.
+- [ ] The shell, search, context rail, and grouped cards work together as one system.
+- [ ] The result does not look like a generic template from a dashboard kit.
+- [ ] The visual identity would still be recognizable if labels changed.
+- [ ] The user can tell where to act next on every important screen.
+
+---
+
+## Hard fail conditions
+
+If any of these are true, the skill was not applied correctly:
+
+- the page is just a dark background with default cards
+- every section has the same weight and the same composition
+- runtime-critical areas are buried below paths, config, or explanatory prose
+- the UI is still washed out or low-contrast
+- the interface feels spacious but not useful
+- navigation improved visually but not operationally

package/template/.aioson/skills/references/premium-command-center-ui/visual-system-and-component-patterns.md

@@ -0,0 +1,270 @@
+# Visual System And Component Patterns
+
+> This reference captures the actual visual language implemented in the AIOS Dashboard.
+> Use it when you need the concrete token system, density rules, shell proportions, and component patterns.
+
+---
+
+## 1. Visual direction
+
+**Direction name:** Premium Dark Platform
+
+**Core feel:** an operating surface, not a gallery of cards.
+
+The premium effect comes from combining:
+
+- deep graphite base instead of pure black
+- aurora radial fields in orange, magenta, cyan
+- strong but disciplined borders
+- blurred glass surfaces with inset highlight
+- compact density
+- semantic accents with restrained hue count
+
+---
+
+## 2. Extracted token system
+
+### Dark foundation
+
+- `background`: `#060818`
+- `panel`: `#0b1230`
+- `panel-elevated`: `#121c46`
+- `panel-soft`: `rgba(10, 16, 42, 0.8)`
+- `panel-contrast`: `rgba(7, 12, 33, 0.92)`
+- `panel-contrast-hover`: `rgba(18, 31, 72, 0.96)`
+- `foreground`: `#f4f7ff`
+- `muted`: `#a5b3d9`
+- `border`: `rgba(104, 144, 238, 0.34)`
+- `accent`: `#28a5ff`
+- `accent-soft`: `rgba(40, 165, 255, 0.26)`
+- `surface-soft`: `rgba(82, 122, 232, 0.18)`
+- `surface-fill`: `rgba(82, 122, 232, 0.24)`
+- `surface-fill-strong`: `rgba(110, 148, 255, 0.34)`
+- `success`: `#46d5a7`
+- `warning`: `#f2bb59`
+- `danger`: `#ff7d8d`
+- `violet`: `#b18cff`
+- `shadow`: `0 20px 64px rgba(3, 8, 30, 0.55)`
+
+### Light foundation
+
+The light theme is not a plain white inversion. It uses cool mist surfaces:
+
+- `background`: `#edf3ff`
+- `panel`: `#f8faff`
+- `panel-elevated`: `#ffffff`
+- `panel-soft`: `rgba(248, 251, 255, 0.95)`
+- `panel-contrast`: `rgba(225, 236, 255, 0.88)`
+- `panel-contrast-hover`: `rgba(209, 224, 252, 0.94)`
+- `foreground`: `#112041`
+- `muted`: `#3f5b89`
+- `border`: `rgba(41, 86, 170, 0.22)`
+- `accent`: `#166fff`
+- `shadow`: `0 18px 44px rgba(20, 50, 108, 0.18)`
+
+---
+
+## 3. Background and depth rules
+
+### Page background
+
+The page background uses 4 radial aurora spots over a deep cool gradient.
+
+Rules:
+
+- use orange, magenta, cyan, and soft violet as atmospheric fields
+- keep them diffused and large
+- apply them to the page and shell backdrop, not every card
+- avoid neon glow and avoid rainbow clutter inside content panels
+
+### Depth strategy
+
+This system is **borders-first** with blur and one shadow family.
+
+Use:
+
+- visible border on every major surface
+- inset highlight on premium surfaces
+- one shared shadow family only
+- blurred panels for shell and premium overlays
+
+Do not mix:
+
+- flat cards, heavy shadows, and shadowless cards in the same route
+- multiple shadow families
+
+---
+
+## 4. Typography extracted from implementation
+
+### UI font stack
+
+Use the actual shipped stack, not a generic default:
+
+- `"Segoe UI", "SF Pro Text", "Helvetica Neue", Arial, sans-serif`
+
+### Monospace stack
+
+- `"SFMono-Regular", "JetBrains Mono", "Cascadia Code", "Fira Code", monospace`
+
+### Hierarchy
+
+- micro eyebrow: `0.68rem`, uppercase, wide tracking (`0.22em` to `0.32em`)
+- page heading: large, semibold, negative tracking (`-0.03em` to `-0.04em`)
+- section titles: `text-2xl` or `text-lg`, semibold
+- helper/body text: `text-sm`, generous line-height (`1.6` to `1.8`)
+- paths and runtime metadata: monospace, small size, safe wrapping
+
+The premium feel depends on **micro-label + strong title + muted helper** repeating consistently.
+
+---
+
+## 5. Density and spacing
+
+Base grid is `8px`, but the dashboard uses a compact mode layer that compresses common Tailwind spacing values:
+
+- `p-6 -> 18px`
+- `p-5 -> 15px`
+- `p-8 -> 22px`
+- `gap-6 -> 14px`
+- `space-y-6 -> 14px`
+
+Rounded values are also compressed:
+
+- `28px -> 16px`
+- `24px -> 14px`
+- `22px -> 13px`
+- `20px -> 12px`
+- `30px -> 18px`
+
+Use this to avoid the "too expanded" feeling that often makes dashboards look amateur.
+
+---
+
+## 6. Shell composition
+
+### Desktop shell
+
+On wide screens the shell is:
+
+- left rail: `248px`
+- center workspace: fluid
+- right activity rail: `320px`
+
+The top search bar sits above the main workspace content, not inside the left rail.
+
+### Main page pattern
+
+Most premium routes follow this order:
+
+1. metric row
+2. primary operational split section
+3. secondary support section
+
+This is what makes the interface feel curated rather than randomly assembled.
+
+---
+
+## 7. Extracted component patterns
+
+### SurfacePanel
+
+Use for major containers.
+
+- `panel-soft`
+- visible border
+- blur
+- shared shadow
+- generous but compact padding
+
+### MetricTile
+
+Use for top-row metrics.
+
+Structure:
+
+- eyebrow label
+- large number
+- one short helper sentence
+- semantic tone gradient in the panel background
+
+### StatusBadge
+
+Use for semantic pills, counts, and momentum labels.
+
+Rules:
+
+- rounded full pill
+- semantic tint only
+- small uppercase tracking
+- never the main source of meaning by color alone
+
+### SignalBar
+
+Use for compact ratio visualization inside operational cards.
+
+Rules:
+
+- thin track
+- semantic gradient fill
+- numeric label on the right
+- useful only when it answers a decision question quickly
+
+### Empty state panel
+
+Use dashed border + premium surface, never plain text floating on the page.
+
+### Grouped operational card
+
+Used in tasks, workflows, agents, memories.
+
+Structure:
+
+- eyebrow / source / scope
+- title
+- one helper line or summary
+- status or count pills
+- direct action link when available
+
+---
+
+## 8. Semantic tone map
+
+Keep tones disciplined:
+
+- `accent` = primary runtime / navigation / live importance
+- `success` = running / healthy / available
+- `warning` = queued / caution / capability volume
+- `danger` = failed / broken / urgent
+- `violet` = knowledge / memory / warming / secondary momentum
+- `neutral` = contextual or inactive information
+
+This limited palette is a big part of the premium feel.
+
+---
+
+## 9. Hover, active, and premium polish
+
+The actual implementation uses:
+
+- stronger border on hover
+- slightly brighter surface on hover
+- active nav items with gradient fill + inset highlight
+- top shell glow and shell backdrop aura
+- blurred modal overlay for command palette
+
+Do not add gratuitous motion. The premium feel here comes more from shell behavior and disciplined layering than from animation.
+
+---
+
+## 10. Responsive behavior
+
+Responsive strategy is desktop-first but not desktop-only:
+
+- right activity rail hides below `xl`
+- shell collapses to one content column below `xl`
+- metric grids move through `md` and `xl` column counts
+- action clusters use `flex-wrap`
+- page sections become stacked rather than replaced
+
+Preserve the same hierarchy when stacking. Do not invent a separate mobile composition unless the product truly requires it.