@jaimevalasek/aioson 1.8.0 → 1.9.1

package/template/.aioson/skills/design/premium-command-center-ui/SKILL.md

@@ -1,62 +1,62 @@
----
-name: premium-command-center-ui
-description: Premium Command Center UI is a packaged visual system for tri-rail dashboards, dark operational shells, and premium command-center software. Use it only when `design_skill: premium-command-center-ui` is selected or the user explicitly chooses this package.
----
-
-# Premium Command Center UI
-
-This is a specialized operational design skill.
-It is not the default for every dashboard.
-
-## Package structure
-
-```text
-.aioson/skills/design/premium-command-center-ui/
-  SKILL.md
-  references/
-    visual-system.md
-    patterns.md
-    operations.md
-    validation.md
-```
-
-## Activation rules
-
-- Apply this package only when `design_skill: premium-command-center-ui` is selected.
-- Do not load it in parallel with `cognitive-ui`, `interface-design`, or any other design skill.
-- Use it when the product genuinely needs a premium operational shell, not merely a dark dashboard.
-
-## Responsibility boundary
-
-This skill defines:
-- dark premium operational tone
-- tri-rail composition rules
-- density discipline
-- grouped operational cards and contextual rails
-- quality bar for command surfaces
-
-This skill does not decide framework, component library, or delivery format.
-
-## Loading guide
-
-| Task | Load |
-|---|---|
-| Any visual work | `references/visual-system.md` |
-| Dashboard shell and layout | `references/visual-system.md` + `references/patterns.md` |
-| Operational page hierarchy | `references/visual-system.md` + `references/patterns.md` + `references/operations.md` |
-| Final QA | add `references/validation.md` |
-
-## Positioning
-
-Use this package for:
-- command centers
-- control towers
-- orchestration software
-- activity-heavy internal operating surfaces
-- premium dark operational products
-
-Do not use it for:
-- landing pages
-- editorial or calm consumer products
-- simple CRUD screens that should stay neutral
-- generic SaaS dashboards without command-center pressure
+---
+name: premium-command-center-ui
+description: Premium Command Center UI is a packaged visual system for tri-rail dashboards, dark operational shells, and premium command-center software. Use it only when `design_skill: premium-command-center-ui` is selected or the user explicitly chooses this package.
+---
+
+# Premium Command Center UI
+
+This is a specialized operational design skill.
+It is not the default for every dashboard.
+
+## Package structure
+
+```text
+.aioson/skills/design/premium-command-center-ui/
+  SKILL.md
+  references/
+    visual-system.md
+    patterns.md
+    operations.md
+    validation.md
+```
+
+## Activation rules
+
+- Apply this package only when `design_skill: premium-command-center-ui` is selected.
+- Do not load it in parallel with `cognitive-ui`, `interface-design`, or any other design skill.
+- Use it when the product genuinely needs a premium operational shell, not merely a dark dashboard.
+
+## Responsibility boundary
+
+This skill defines:
+- dark premium operational tone
+- tri-rail composition rules
+- density discipline
+- grouped operational cards and contextual rails
+- quality bar for command surfaces
+
+This skill does not decide framework, component library, or delivery format.
+
+## Loading guide
+
+| Task | Load |
+|---|---|
+| Any visual work | `references/visual-system.md` |
+| Dashboard shell and layout | `references/visual-system.md` + `references/patterns.md` |
+| Operational page hierarchy | `references/visual-system.md` + `references/patterns.md` + `references/operations.md` |
+| Final QA | add `references/validation.md` |
+
+## Positioning
+
+Use this package for:
+- command centers
+- control towers
+- orchestration software
+- activity-heavy internal operating surfaces
+- premium dark operational products
+
+Do not use it for:
+- landing pages
+- editorial or calm consumer products
+- simple CRUD screens that should stay neutral
+- generic SaaS dashboards without command-center pressure

package/template/.aioson/skills/design/premium-command-center-ui/references/operations.md

@@ -1,74 +1,74 @@
-# Operations — Premium Command Center UI
-
----
-
-## Hierarchy rules
-
-1. **Show live pressure first.** Runtime operations appear above infrastructure or metadata.
-2. **Group cards by operational meaning**, not by raw data type.
-3. **Convert backend shapes into UI-native view models** when the user needs lanes, signals, grouped cards, or contextual summaries — not table rows.
-4. **Expose the next useful action** from every major block. Never leave the user without a clear path forward after reading a card.
-
----
-
-## UI view model concept
-
-Do not render storage records directly as UI rows. Instead, aggregate backend data into objects shaped for operational reading.
-
-Examples from the AIOS Dashboard:
-- `GlobalTaskRecord` — combines task status, lane assignment, priority, and direct action into one card
-- `WorkflowRecord` — shows lifecycle stage, progress, blockers, and the one next step
-- `MemoryAssetRecord` — surfaces type, recency, source, and retrieval action
-
-Apply this in every new product: ask *"what does the user need to decide?"* and build the view model around that answer.
-
----
-
-## How to preserve quality
-
-The quality bar is preserved when all of the following remain true:
-
-- Runtime or primary operations appear **above** infrastructure or metadata
-- Every screen has **one obvious focal block**
-- Cards are grouped by **operational meaning**, not just by data type
-- The shell behaves like a **product operating surface** — not a page of links
-- Semantic colors are **limited and consistent** — no rainbow status colors
-- Empty states are **styled and intentional** — never raw blank space
-- Search, navigation, and context **work together** instead of competing
-- Density is **compact but not cramped** — operational readability, not marketing whitespace
-
----
-
-## When the system is working
-
-The result should feel like an operating surface:
-- Search and navigation reduce friction without competing with the workspace
-- Contextual rails support the current task without overloading the viewport
-- Live signals, queue state, history, and drill-downs coexist without collision
-- A user arriving at any screen can immediately read: *what is happening, what is next, what do I do*
-
----
-
-## When to use this skill
-
-Apply `premium-command-center-ui` when:
-
-- The product is an operational dashboard or internal tool
-- The user asks for a premium, high-contrast, high-trust interface
-- The current UI feels washed out, generic, or too expanded
-- The app has multiple modules that need one shared shell and consistent hierarchy
-- The interface must surface live signals, queue state, history, and deep links
-
----
-
-## When NOT to use this skill
-
-Do not apply this skill when:
-
-- The project is a landing page or campaign site
-- The product is intentionally minimal, calm, editorial, or consumer-soft
-- The existing brand system already conflicts with aurora-glass language
-- The screen is simple CRUD that should stay neutral and utilitarian
-- The domain demands conventional enterprise neutrality over expressiveness
-
-In those cases, borrow only the pieces that fit: density control, hierarchy discipline, grouped operational cards, or contextual rails.
+# Operations — Premium Command Center UI
+
+---
+
+## Hierarchy rules
+
+1. **Show live pressure first.** Runtime operations appear above infrastructure or metadata.
+2. **Group cards by operational meaning**, not by raw data type.
+3. **Convert backend shapes into UI-native view models** when the user needs lanes, signals, grouped cards, or contextual summaries — not table rows.
+4. **Expose the next useful action** from every major block. Never leave the user without a clear path forward after reading a card.
+
+---
+
+## UI view model concept
+
+Do not render storage records directly as UI rows. Instead, aggregate backend data into objects shaped for operational reading.
+
+Examples from the AIOS Dashboard:
+- `GlobalTaskRecord` — combines task status, lane assignment, priority, and direct action into one card
+- `WorkflowRecord` — shows lifecycle stage, progress, blockers, and the one next step
+- `MemoryAssetRecord` — surfaces type, recency, source, and retrieval action
+
+Apply this in every new product: ask *"what does the user need to decide?"* and build the view model around that answer.
+
+---
+
+## How to preserve quality
+
+The quality bar is preserved when all of the following remain true:
+
+- Runtime or primary operations appear **above** infrastructure or metadata
+- Every screen has **one obvious focal block**
+- Cards are grouped by **operational meaning**, not just by data type
+- The shell behaves like a **product operating surface** — not a page of links
+- Semantic colors are **limited and consistent** — no rainbow status colors
+- Empty states are **styled and intentional** — never raw blank space
+- Search, navigation, and context **work together** instead of competing
+- Density is **compact but not cramped** — operational readability, not marketing whitespace
+
+---
+
+## When the system is working
+
+The result should feel like an operating surface:
+- Search and navigation reduce friction without competing with the workspace
+- Contextual rails support the current task without overloading the viewport
+- Live signals, queue state, history, and drill-downs coexist without collision
+- A user arriving at any screen can immediately read: *what is happening, what is next, what do I do*
+
+---
+
+## When to use this skill
+
+Apply `premium-command-center-ui` when:
+
+- The product is an operational dashboard or internal tool
+- The user asks for a premium, high-contrast, high-trust interface
+- The current UI feels washed out, generic, or too expanded
+- The app has multiple modules that need one shared shell and consistent hierarchy
+- The interface must surface live signals, queue state, history, and deep links
+
+---
+
+## When NOT to use this skill
+
+Do not apply this skill when:
+
+- The project is a landing page or campaign site
+- The product is intentionally minimal, calm, editorial, or consumer-soft
+- The existing brand system already conflicts with aurora-glass language
+- The screen is simple CRUD that should stay neutral and utilitarian
+- The domain demands conventional enterprise neutrality over expressiveness
+
+In those cases, borrow only the pieces that fit: density control, hierarchy discipline, grouped operational cards, or contextual rails.

package/template/.aioson/skills/design/premium-command-center-ui/references/patterns.md

@@ -1,116 +1,116 @@
-# Patterns — Premium Command Center UI
-
----
-
-## Application flow
-
-Follow this sequence. Do not start from components. Start from operational pressure.
-
-### 1. Inspect the product before drawing anything
-
-Identify the real operational nouns and verbs:
-
-- What is the **live signal**? (running tasks, active events, real-time state)
-- What is the **queue**? (pending work, backlog, staged items)
-- What is the **grouped catalog**? (squads, agents, workflows, resources)
-- What deserves **persistent navigation**?
-- What belongs in **context**, not in the primary column?
-
-### 2. Translate raw data into UI-native objects
-
-Do not render tables straight from storage shape when the user actually needs lanes, signals, grouped cards, or contextual summaries.
-
-Convert backend records into view models. Examples from the AIOS Dashboard:
-- `GlobalTaskRecord` — aggregated task signal with lane/priority/status
-- `WorkflowRecord` — lifecycle-aware workflow with stage and next action
-- `MemoryAssetRecord` — knowledge item with type, source, and recency
-
-Apply the same principle in new projects. Ask: *what shape does the user need to think in?*
-
-### 3. Choose the shell intentionally
-
-Use the **tri-rail shell** when the product has:
-- 5+ first-class modules
-- Live or near-live context
-- A need for persistent navigation + persistent context panel
-- Enough desktop usage to justify a right rail
-
-Collapse progressively below the desktop breakpoint — do not build a separate mobile design system.
-
-**Tri-rail layout:**
-```
-┌────────────────────────────────────────────────────────┐
-│  TOP BAR: [Logo] [Search] [Workspace picker] [Actions] │
-├──────────┬─────────────────────────────────┬───────────┤
-│  LEFT    │                                 │  RIGHT    │
-│  NAV     │     CENTER WORKSPACE            │  ACTIVITY │
-│  RAIL    │     (primary column)            │  RAIL     │
-│  200px   │     one focal block per page    │  280px    │
-│  module  │     operational priority first  │  state    │
-│  icons   │                                 │  history  │
-│  + labels│                                 │  metrics  │
-└──────────┴─────────────────────────────────┴───────────┘
-```
-
-### 4. Choose the page archetype
-
-Pick the pattern that matches the page's job:
-
-| Archetype | Job | Focal block |
-|---|---|---|
-| **Command overview** | Surface live signals and current operational state | Priority queue or status summary |
-| **Queue / control tower** | Show pending work in processing order | Task lane or control grid |
-| **Grouped registry** | Browse and act on a categorized catalog | Group headers with inline actions |
-| **Workflow catalog** | Track multi-step flows from start to completion | Status-aware workflow cards |
-| **Knowledge explorer** | Find, filter, and inspect reference assets | Search bar + metadata panels |
-
-Use the UX playbook (operations.md) to decide which archetype fits each route.
-
-### 5. Apply the visual language without diluting it
-
-Preserve these moves together — removing any one degrades the whole:
-
-- Dark graphite or cool mist foundation
-- Aurora background fields on the page and shell — not on every card
-- Borders-first depth with one shadow family only
-- Three surface levels maximum
-- Compact spacing and short helper copy
-- Semantic badges and gradient fills tied to meaning, not decoration
-
-### 6. Build direct next actions into the UI
-
-Every major card must expose the next useful step:
-- Open the squad / agent / workflow
-- Inspect the task
-- View logs / history
-- Switch workspace
-- Drill into detail or source
-
-Premium feel comes from reduced friction, not only from color.
-
----
-
-## Shell guardrails
-
-- Do not create equal-weight card walls for every section.
-- Every screen needs one obvious focal block.
-- Context and supporting data belong in side rails, not in the main narrative column.
-- Search and navigation must reduce friction — they cannot compete with the workspace.
-
----
-
-## How to adapt this skill to new projects
-
-Adapt the system structurally, not literally.
-
-- Replace `squads` with the domain grouping that matters in the new product.
-- Replace `tasks` with the domain queue or active work item.
-- Replace `memories` with the project's knowledge layer, asset layer, or context layer.
-- Replace `activity rail` content with the three slices that matter most: current state, history, metrics.
-- Keep the same visual grammar and density discipline even when labels and data change.
-
-If the new project already has a design system:
-1. Port the hierarchy rules first
-2. Port the page archetypes second
-3. Port the shell behaviors third
-4. Port colors only if they do not violate brand or accessibility
+# Patterns — Premium Command Center UI
+
+---
+
+## Application flow
+
+Follow this sequence. Do not start from components. Start from operational pressure.
+
+### 1. Inspect the product before drawing anything
+
+Identify the real operational nouns and verbs:
+
+- What is the **live signal**? (running tasks, active events, real-time state)
+- What is the **queue**? (pending work, backlog, staged items)
+- What is the **grouped catalog**? (squads, agents, workflows, resources)
+- What deserves **persistent navigation**?
+- What belongs in **context**, not in the primary column?
+
+### 2. Translate raw data into UI-native objects
+
+Do not render tables straight from storage shape when the user actually needs lanes, signals, grouped cards, or contextual summaries.
+
+Convert backend records into view models. Examples from the AIOS Dashboard:
+- `GlobalTaskRecord` — aggregated task signal with lane/priority/status
+- `WorkflowRecord` — lifecycle-aware workflow with stage and next action
+- `MemoryAssetRecord` — knowledge item with type, source, and recency
+
+Apply the same principle in new projects. Ask: *what shape does the user need to think in?*
+
+### 3. Choose the shell intentionally
+
+Use the **tri-rail shell** when the product has:
+- 5+ first-class modules
+- Live or near-live context
+- A need for persistent navigation + persistent context panel
+- Enough desktop usage to justify a right rail
+
+Collapse progressively below the desktop breakpoint — do not build a separate mobile design system.
+
+**Tri-rail layout:**
+```
+┌────────────────────────────────────────────────────────┐
+│  TOP BAR: [Logo] [Search] [Workspace picker] [Actions] │
+├──────────┬─────────────────────────────────┬───────────┤
+│  LEFT    │                                 │  RIGHT    │
+│  NAV     │     CENTER WORKSPACE            │  ACTIVITY │
+│  RAIL    │     (primary column)            │  RAIL     │
+│  200px   │     one focal block per page    │  280px    │
+│  module  │     operational priority first  │  state    │
+│  icons   │                                 │  history  │
+│  + labels│                                 │  metrics  │
+└──────────┴─────────────────────────────────┴───────────┘
+```
+
+### 4. Choose the page archetype
+
+Pick the pattern that matches the page's job:
+
+| Archetype | Job | Focal block |
+|---|---|---|
+| **Command overview** | Surface live signals and current operational state | Priority queue or status summary |
+| **Queue / control tower** | Show pending work in processing order | Task lane or control grid |
+| **Grouped registry** | Browse and act on a categorized catalog | Group headers with inline actions |
+| **Workflow catalog** | Track multi-step flows from start to completion | Status-aware workflow cards |
+| **Knowledge explorer** | Find, filter, and inspect reference assets | Search bar + metadata panels |
+
+Use the UX playbook (operations.md) to decide which archetype fits each route.
+
+### 5. Apply the visual language without diluting it
+
+Preserve these moves together — removing any one degrades the whole:
+
+- Dark graphite or cool mist foundation
+- Aurora background fields on the page and shell — not on every card
+- Borders-first depth with one shadow family only
+- Three surface levels maximum
+- Compact spacing and short helper copy
+- Semantic badges and gradient fills tied to meaning, not decoration
+
+### 6. Build direct next actions into the UI
+
+Every major card must expose the next useful step:
+- Open the squad / agent / workflow
+- Inspect the task
+- View logs / history
+- Switch workspace
+- Drill into detail or source
+
+Premium feel comes from reduced friction, not only from color.
+
+---
+
+## Shell guardrails
+
+- Do not create equal-weight card walls for every section.
+- Every screen needs one obvious focal block.
+- Context and supporting data belong in side rails, not in the main narrative column.
+- Search and navigation must reduce friction — they cannot compete with the workspace.
+
+---
+
+## How to adapt this skill to new projects
+
+Adapt the system structurally, not literally.
+
+- Replace `squads` with the domain grouping that matters in the new product.
+- Replace `tasks` with the domain queue or active work item.
+- Replace `memories` with the project's knowledge layer, asset layer, or context layer.
+- Replace `activity rail` content with the three slices that matter most: current state, history, metrics.
+- Keep the same visual grammar and density discipline even when labels and data change.
+
+If the new project already has a design system:
+1. Port the hierarchy rules first
+2. Port the page archetypes second
+3. Port the shell behaviors third
+4. Port colors only if they do not violate brand or accessibility

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

@@ -1,47 +1,47 @@
-# Validation — Premium Command Center UI
-
-Run this checklist before every handoff.
-
----
-
-## Pre-ship checklist
-
-1. The page has **one dominant focal block** — not a grid of equal-weight cards.
-2. Density is **compact but not cramped** — operational readability, not marketing padding.
-3. Semantic colors are **limited and consistent** — no rainbow palette, no decorative gradients.
-4. The shell **supports the task** instead of decorating the viewport.
-5. There is a **direct next action** visible after reading each major block.
-6. The result does **not look like a generic dark dashboard with random gradients**.
-7. **Empty states are styled** — never raw blank space with no guidance.
-8. **Search, navigation, and context** work together without competing.
-
----
-
-## Non-negotiable quality bar
-
-The following are absolute failures if present:
-
-- Flat, washed-out backgrounds without depth or surface levels
-- Equal-emphasis card grids for every section on every page
-- Giant padding values that make the product feel empty
-- Rainbow status colors without consistent semantic meaning
-- Shadow-heavy cards mixed with border-heavy cards on the same screen
-- No visible next step after the user reads a major card
-- Infrastructure-first hierarchy (metadata before live operations)
-- Top-level pages without a clear route back to the operating workflow
-
-If any of the above are present, the skill was not applied correctly.
-
----
-
-## Expected output
-
-When this skill is applied to a new product, the deliverable must include:
-
-1. Explicit visual direction and density choice
-2. Shell structure and route hierarchy
-3. Page archetype selection per major screen
-4. Reusable component set with token assignments
-5. State handling: default / hover / active / empty / loading / error
-6. Responsive behavior notes (collapse strategy)
-7. Validation against this checklist before handoff
+# Validation — Premium Command Center UI
+
+Run this checklist before every handoff.
+
+---
+
+## Pre-ship checklist
+
+1. The page has **one dominant focal block** — not a grid of equal-weight cards.
+2. Density is **compact but not cramped** — operational readability, not marketing padding.
+3. Semantic colors are **limited and consistent** — no rainbow palette, no decorative gradients.
+4. The shell **supports the task** instead of decorating the viewport.
+5. There is a **direct next action** visible after reading each major block.
+6. The result does **not look like a generic dark dashboard with random gradients**.
+7. **Empty states are styled** — never raw blank space with no guidance.
+8. **Search, navigation, and context** work together without competing.
+
+---
+
+## Non-negotiable quality bar
+
+The following are absolute failures if present:
+
+- Flat, washed-out backgrounds without depth or surface levels
+- Equal-emphasis card grids for every section on every page
+- Giant padding values that make the product feel empty
+- Rainbow status colors without consistent semantic meaning
+- Shadow-heavy cards mixed with border-heavy cards on the same screen
+- No visible next step after the user reads a major card
+- Infrastructure-first hierarchy (metadata before live operations)
+- Top-level pages without a clear route back to the operating workflow
+
+If any of the above are present, the skill was not applied correctly.
+
+---
+
+## Expected output
+
+When this skill is applied to a new product, the deliverable must include:
+
+1. Explicit visual direction and density choice
+2. Shell structure and route hierarchy
+3. Page archetype selection per major screen
+4. Reusable component set with token assignments
+5. State handling: default / hover / active / empty / loading / error
+6. Responsive behavior notes (collapse strategy)
+7. Validation against this checklist before handoff