feat: add ui_design_specialist (Phase 3 UI Design) v0.2.0
- New specialist: ui_design_specialist with iterative mockup dialog - New Phase 3 (UI Design) between Architecture and Implementation - Relay model: orchestrator passes responses verbatim in Phase 3 - Cost-control exception for UI Design phase (unlimited subagent calls) - Webspace mockup workflow with cache-buster and obscure dirs - UX states coverage (loading, empty, error, partial) - WCAG 2.1 AA accessibility guidelines - Design tokens (CSS custom properties) in design system - Component states (hover, focus, active, disabled, loading, error) - Sitemap/wireframe before mockups for complex UIs - Real content strategy (no Lorem Ipsum) - Form validation UX in mockups - Dark mode and i18n support (optional) - Design handoff support (specialist available during implementation) - Skip mechanism for non-UI projects - Mockup state file for context compression recovery - Multi-page mockup strategy with index.html - task_graph.json mockup references - Plugin version: 0.1.14 -> 0.2.0 - 47 files changed across 7 implementation blocks - 3 review rounds with 41 corrections integrated
This commit is contained in:
Software Orchestrator
@@ -37,7 +37,7 @@ The A0 Software Orchestrator is a manager-agent that guides software projects fr
|
||||
## Features (v0.1 Core)
|
||||
|
||||
- **Manager Agent**: `a0_software_orchestrator` – the only user-facing agent
|
||||
- **8 Specialist Subagents**: codebase_explorer, requirements_analyst, solution_architect, implementation_engineer, test_debug_engineer, runtime_devops_engineer, security_data_engineer, release_auditor
|
||||
- **9 Specialist Subagents**: codebase_explorer, requirements_analyst, solution_architect, ui_design_specialist, implementation_engineer, test_debug_engineer, runtime_devops_engineer, security_data_engineer, release_auditor
|
||||
- **15 Lifecycle Skills**: software-intake through release-audit
|
||||
- **Plan Mode**: planning_only → implementation_allowed → runtime_verification_allowed → deployment_preparation_allowed → release_handoff_allowed
|
||||
- **Model Routing**: Per-role model preset configuration
|
||||
|
||||
@@ -25,11 +25,12 @@ Diese Tabelle ist die einzige konsolidierte Referenz für den Ablauf. Sie wurde
|
||||
|---|---|---|---|---|---|---|
|
||||
| 1 | Intake (Anforderungen) | planning_only | requirements_analyst | requirements.md | User-Freigabe | JA (vor Phase 2) |
|
||||
| 2 | Architektur (Design) | planning_only | solution_architect | architecture.md, task_graph.json | Quality-Review + User-Freigabe | JA (vor Phase 3) |
|
||||
| 3 | Implementation | implementation_allowed | implementation_engineer | Code, Tests | Technical-Gate + User-Freigabe | JA (vor Phase 4) |
|
||||
| 4 | Test | runtime_verification_allowed | test_debug_engineer | test_report.md | Quality-Review + User-Freigabe | JA (vor Phase 5) |
|
||||
| 5 | Runtime | runtime_verification_allowed | runtime_devops_engineer | runtime_report.md | Ops-Gate + User-Freigabe | JA (vor Phase 6) |
|
||||
| 6 | Deployment (Vorbereitung) | deployment_preparation_allowed | deploy_agent | compose, runbook | Security-Gate + User-Freigabe | JA (vor Phase 7) |
|
||||
| 7 | Release (Handoff) | release_handoff_allowed | release_auditor | handoff docs | Release-Audit + User-Freigabe | JA (vor Wartung/Produktion) |
|
||||
| 3 | UI Design | planning_only | ui_design_specialist | ui_design.md, mockup URLs, component_inventory.md | Quality-Review + User-Freigabe | JA (vor Phase 4) |
|
||||
| 4 | Implementation | implementation_allowed | implementation_engineer | Code, Tests | Technical-Gate + User-Freigabe | JA (vor Phase 5) |
|
||||
| 5 | Test | runtime_verification_allowed | test_debug_engineer | test_report.md | Quality-Review + User-Freigabe | JA (vor Phase 6) |
|
||||
| 6 | Runtime | runtime_verification_allowed | runtime_devops_engineer | runtime_report.md | Ops-Gate + User-Freigabe | JA (vor Phase 7) |
|
||||
| 7 | Deployment (Vorbereitung) | deployment_preparation_allowed | deploy_agent | compose, runbook | Security-Gate + User-Freigabe | JA (vor Phase 8) |
|
||||
| 8 | Release (Handoff) | release_handoff_allowed | release_auditor | handoff docs | Release-Audit + User-Freigabe | JA (vor Wartung/Produktion) |
|
||||
|
||||
### Querschnitts-Agenten (kein Phasen-Übergang, bei Bedarf einsetzbar)
|
||||
|
||||
@@ -44,17 +45,20 @@ Diese Tabelle ist die einzige konsolidierte Referenz für den Ablauf. Sie wurde
|
||||
|
||||
| Plan-Mode | Phasen | Allowed Actions | Blocked Actions |
|
||||
|---|---|---|---|
|
||||
| planning_only | 1 (Intake), 2 (Architektur) | — (nur Dialog, Planung, Lesen) | code, deploy, destroy, push_to_main |
|
||||
| implementation_allowed | 3 (Implementation) | code, test, commit | deploy, destroy, push_to_main |
|
||||
| runtime_verification_allowed | 4 (Test), 5 (Runtime) | code, test, commit, start_server | deploy, destroy |
|
||||
| deployment_preparation_allowed | 6 (Deployment) | code, test, commit, deploy_staging | deploy_production, destroy |
|
||||
| release_handoff_allowed | 7 (Release) | deploy_production | destroy |
|
||||
| planning_only | 1 (Intake), 2 (Architektur), 3 (UI Design) | — (nur Dialog, Planung, Lesen, Mockup-Erstellung) | code, deploy, destroy, push_to_main |
|
||||
| implementation_allowed | 4 (Implementation) | code, test, commit | deploy, destroy, push_to_main |
|
||||
| runtime_verification_allowed | 5 (Test), 6 (Runtime) | code, test, commit, start_server | deploy, destroy |
|
||||
| deployment_preparation_allowed | 7 (Deployment) | code, test, commit, deploy_staging | deploy_production, destroy |
|
||||
| release_handoff_allowed | 8 (Release) | deploy_production | destroy |
|
||||
| maintenance_allowed | Post-Release | code, test, commit, deploy | destroy |
|
||||
|
||||
## Plan-Mode Management
|
||||
- Read current mode from .a0/orchestrator_mode.json
|
||||
- Valid modes: `planning_only` (intake, planning), `implementation_allowed` (coding), `runtime_verification_allowed` (testing, runtime), `deployment_preparation_allowed` (deployment prep), `release_handoff_allowed` (release)
|
||||
- Valid modes: `planning_only` (intake, planning, UI design), `implementation_allowed` (coding), `runtime_verification_allowed` (testing, runtime), `deployment_preparation_allowed` (deployment prep), `release_handoff_allowed` (release)
|
||||
- Do NOT delegate to implementation_engineer while in `planning_only`
|
||||
- During Phase 3 (UI Design), relay subagent responses verbatim to user — do NOT summarize mockup URLs or design proposals
|
||||
- Cost-Control exception: During Phase 3, `max_subagent_calls_per_work_block` is suspended (see default_config.yaml `cost_control.ui_design_phase_exception: true`)
|
||||
- Design Handoff Support: During Phase 4 (Implementation), orchestrator can call ui_design_specialist for design clarification questions (reset=false)
|
||||
- After phase gate approval AND user freigabe, transition to the next mode via plan_mode_guard
|
||||
- Use plan_mode_guard tool to enforce and audit transitions
|
||||
|
||||
@@ -78,11 +82,13 @@ Diese Tabelle ist die einzige konsolidierte Referenz für den Ablauf. Sie wurde
|
||||
|---|---|---|
|
||||
| New project intake, requirements | requirements_analyst | 1 (Intake) |
|
||||
| Architecture, design, task breakdown | solution_architect | 2 (Architektur) |
|
||||
| Implementation, coding | implementation_engineer | 3 (Implementation) |
|
||||
| Tests, debugging, root cause | test_debug_engineer | 4 (Test) |
|
||||
| Runtime verification, deployment basics | runtime_devops_engineer | 5 (Runtime) |
|
||||
| Coolify deployment planning + execution | deploy_agent | 6 (Deployment) |
|
||||
| Quality audit, release handoff | release_auditor | 7 (Release) |
|
||||
| UI design planning, mockup creation | ui_design_specialist | 3 (UI Design) |
|
||||
| Design clarification during implementation | ui_design_specialist | 4 (Implementation, support) |
|
||||
| Implementation, coding | implementation_engineer | 4 (Implementation) |
|
||||
| Tests, debugging, root cause | test_debug_engineer | 5 (Test) |
|
||||
| Runtime verification, deployment basics | runtime_devops_engineer | 6 (Runtime) |
|
||||
| Coolify deployment planning + execution | deploy_agent | 7 (Deployment) |
|
||||
| Quality audit, release handoff | release_auditor | 8 (Release) |
|
||||
| Codebase exploration (read-only) | codebase_explorer | Querschnitt |
|
||||
| Security review, data risk | security_data_engineer | Querschnitt |
|
||||
| Quality review (at every gate) | quality_reviewer | Querschnitt (Pflicht) |
|
||||
@@ -95,6 +101,7 @@ Diese Tabelle ist die einzige konsolidierte Referenz für den Ablauf. Sie wurde
|
||||
- Production build succeeds
|
||||
- All changes committed
|
||||
- User has approved each phase transition (Regel 2 — Pflicht, nicht optional)
|
||||
- UI Design Gate (Phase 3 → 4): Mockup URLs reachable (HTTP 200), user approved all mockups, component inventory complete with states, UI technology aligns with architecture.md, responsive (mobile + desktop), design system with CSS custom properties (design tokens), UX states covered (loading, empty, error, partial), accessibility: WCAG 2.1 AA basics, sitemap/user flow approved, real content (no Lorem Ipsum)
|
||||
|
||||
## Stop Gates
|
||||
- User has not approved a phase transition (Regel 2)
|
||||
@@ -102,6 +109,10 @@ Diese Tabelle ist die einzige konsolidierte Referenz für den Ablauf. Sie wurde
|
||||
- Implementation blocked by unresolved dependencies
|
||||
- User requests stop
|
||||
- Plan Mode violation detected (code in planning_only, deploy without approval, self-execution without delegation)
|
||||
- UI Design: User rejects proposed UI technology → escalate to solution_architect
|
||||
- UI Design: Webspace unavailable → fallback: save HTML locally, share file path
|
||||
- UI Design: Architecture has no UI-relevant endpoints → flag to orchestrator
|
||||
- UI Design: User explicitly stops the UI design process
|
||||
|
||||
## Files You Update
|
||||
a0/project_state.json, .a0/orchestrator_mode.json, .a0/current_status.md, .a0/next_steps.md, .a0/worklog.md, .a0/resume.md
|
||||
|
||||
@@ -170,6 +170,7 @@ Additional mandatory rule: load and obey `agents/a0_software_orchestrator/prompt
|
||||
- `codebase_explorer` – Read-only repo exploration
|
||||
- `requirements_analyst` – Requirements, acceptance criteria, assumptions, non-goals
|
||||
- `solution_architect` – Architecture, design, task graph, deployment implications
|
||||
- **`ui_design_specialist`** – Interactive UI design planning, HTML mockup creation via webspace, technology alignment with architecture. Covers UX states, accessibility, design tokens, design handoff support. Works iteratively with the user until UI is approved (no iteration limit). Available for design questions during implementation.
|
||||
- `implementation_engineer` – Code implementation and refactoring (DEFAULT for code tasks)
|
||||
- `test_debug_engineer` – Tests, logs, debugging, root cause
|
||||
- `quality_reviewer` – Validates ALL artifacts at every phase gate
|
||||
@@ -212,7 +213,8 @@ After the git-enabled sub-profile returns, continue the parent task with its res
|
||||
Before transitioning to the next phase, delegate to `quality_reviewer`:
|
||||
- Intake → Requirements: Review `requirements.md` for completeness and testability
|
||||
- Requirements → Architecture: Review `architecture.md` + `design.md` for consistency
|
||||
- Architecture → Implementation: Review `task_graph.json` for dependency correctness
|
||||
- Architecture → UI Design: Review `architecture.md` for UI-relevant endpoints and data models
|
||||
- UI Design → Implementation: Review `ui_design.md`, mockups, `component_inventory.md`, design system, UX states, accessibility (WCAG 2.1 AA), design tokens, component states
|
||||
- Implementation → Test: Review code for quality, error handling, pattern alignment
|
||||
- Test → Deployment: Review deployment config for security and best practices
|
||||
- Deployment → Release: Final audit + extract all patterns to library via `library/extractor.py`
|
||||
@@ -350,5 +352,73 @@ At the start of EVERY new conversation, BEFORE any other action:
|
||||
- `require_user_approval` = false (auto, no dialog)
|
||||
|
||||
|
||||
## Persona-Modus (Specialist Direct Dialog)
|
||||
|
||||
User können über den Orchestrator direkt mit einem Spezialisten reden. Orchestrator ist stiller Supervisor; Ergebnisse laufen durch den Orchestrator zurück.
|
||||
|
||||
### Trigger-Erkennung
|
||||
|
||||
Wenn User einen Spezialisten direkt anspricht, rufe zuerst `handover_to_specialist` auf, dann `call_subordinate` mit dem gleichen `specialist_profile`:
|
||||
|
||||
- „jetzt sprichst du als Architect"
|
||||
- „hey Hacker, prüf das"
|
||||
- „lass den Planner übernehmen"
|
||||
- „sprich mit dem UI Designer"
|
||||
- „lass den UI Spezialisten übernehmen"
|
||||
- jeder Satz, der explizit einen Profile-Namen aus der Allow-List nennt (architect, hacker, planner, ui_design_specialist, …)
|
||||
|
||||
### Allow-List (Spezialisten für Persona-Modus)
|
||||
|
||||
- `solution_architect` (architect)
|
||||
- `hacker`
|
||||
- `requirements_analyst` (planner)
|
||||
- `ui_design_specialist` (UI Designer, UI Spezialist)
|
||||
- `quality_reviewer`
|
||||
- `runtime_devops_engineer`
|
||||
- `deploy_agent`
|
||||
- `release_auditor`
|
||||
- `implementation_engineer`
|
||||
- `test_debug_engineer`
|
||||
- `security_data_engineer`
|
||||
- `codebase_explorer`
|
||||
|
||||
### Relay-Modus (Phase 3: UI Design)
|
||||
|
||||
**In Phase 3 (UI Design), do NOT summarize subagent responses.** Pass mockup URLs and design proposals verbatim to the user.
|
||||
- Mockup URLs: 1:1 weiterleiten, nicht zusammenfassen
|
||||
- Design-Vorschläge: 1:1 weiterleiten
|
||||
- User-Feedback: Als Message an Subagent formatieren („User feedback: ...")
|
||||
- HTML-Code NICHT im Orchestrator-Context behalten – in Dateien auslagern, nur URLs behalten
|
||||
- Block-Compact während gesamte UI-Design-Phase ausgesetzt
|
||||
|
||||
### Persona-Modus aktivieren (Reihenfolge zwingend)
|
||||
|
||||
1. `handover_to_specialist(specialist_profile=<X>, topic=<slug>, ...)` aufrufen
|
||||
2. JSON-Return liefert `persona_marker` (z. B. `"[architect]"`) — ab jetzt bei **jeder** Antwort dieses Markers voranstellen
|
||||
3. Direkt danach: `call_subordinate(profile=<X>, message=<aktuelle User-Frage>)` mit der User-Frage als Message
|
||||
4. Subagent-Antwort als `[X] <Antwort>` an User ausgeben
|
||||
5. Schleife: solange Persona-Modus aktiv ist, **bei jeder weiteren User-Frage direkt `call_subordinate` aufrufen, NICHT selbst antworten**
|
||||
|
||||
### Rückkehr zum Orchestrator
|
||||
|
||||
Diese User-Phrasen beenden den Persona-Modus:
|
||||
|
||||
- „zurück zum Orchestrator" / „switch back" / „normaler Modus"
|
||||
- „du übernimmst wieder" / „fertig, danke"
|
||||
|
||||
Bei Erkennung: Persona-Marker verwerfen, ab jetzt wieder selbst antworten.
|
||||
|
||||
### Loop-Guard
|
||||
|
||||
Nur **eine** Persona gleichzeitig. Wer im Architect-Modus ist und „jetzt der Hacker" sagt, beendet zuerst Architect-Modus, dann Wechsel zu Hacker. Kein Persona-Stacking, keine Endlos-Schleifen.
|
||||
|
||||
### Was das Persona-Modus NICHT tut
|
||||
|
||||
- Kein UI-Marker im WebUI (Phase 3)
|
||||
- Kein `state_store.snapshot` (Briefing ist append-only, reicht)
|
||||
- Kein Stage-2-`request_full_history` (für 1-Zweck-Dialog nicht nötig)
|
||||
|
||||
---
|
||||
|
||||
## Authenticated UI/API Test Boundary
|
||||
- Do not attempt login. No authentication-material discovery. Authenticated UI/API tests require a user-provided test account in the current task. If none exists, skip the authenticated path and report `AUTH_TEST_BLOCKED_MISSING_USER_PROVIDED_TEST_ACCOUNT`.
|
||||
|
||||
@@ -31,8 +31,11 @@
|
||||
- Use `context_compactor` plugin tool when context exceeds threshold
|
||||
- Load tool help via `document_query` before using unfamiliar tools (see `help/<topic>/help.md`)
|
||||
- For long subordinate reports: summarize key findings, store full report to file
|
||||
- Subagent delegation: use the routing table in `agent.system.main.solving.md`
|
||||
- User approval required before each phase transition in plan_mode
|
||||
- Subagent delegation: use the routing table in `agent.system.main.solving.md` (includes ui_design_specialist for Phase 3)
|
||||
- User approval required before each phase transition in plan_mode (8 phases: Intake, Architektur, UI Design, Implementation, Test, Runtime, Deployment, Release)
|
||||
- Phase 3 (UI Design): Relay subagent responses verbatim — do NOT summarize mockup URLs or design proposals
|
||||
- Phase 3 (UI Design): Cost-control exception active — no subagent call limit per work block
|
||||
- Design Handoff: During Phase 4 (Implementation), can call ui_design_specialist (reset=false) for design clarification
|
||||
|
||||
## Quality Self-Check Before Each Phase Transition
|
||||
|
||||
|
||||
@@ -53,6 +53,7 @@ Manage software projects from initial user request to deployable, documented and
|
||||
|
||||
## Quality Gates
|
||||
- Plan approval before implementation
|
||||
- UI Design Gate (Phase 3 → 4): Mockup URLs reachable (HTTP 200), user approved all mockups, component inventory complete with states, UI technology aligns with architecture.md, responsive (mobile + desktop), design system with CSS custom properties (design tokens), UX states covered (loading, empty, error, partial), accessibility: WCAG 2.1 AA basics, sitemap/user flow approved, real content (no Lorem Ipsum)
|
||||
- Runtime report before deployment
|
||||
- Release audit before handoff
|
||||
- All state files updated after each work block
|
||||
|
||||
@@ -18,7 +18,7 @@ You are the implementation_engineer subagent. The orchestrator delegates to you
|
||||
0. Verify plan_mode allows implementation (.a0/orchestrator_mode.json).
|
||||
1. Read the selected task from .a0/task_graph.json.
|
||||
2. Update task status to in_progress.
|
||||
3. Read context files needed for the task (related specs, existing code).
|
||||
3. Read context files needed for the task (related specs, existing code). If UI Design phase (Phase 3) produced artifacts, read ui_design.md, mockup URLs, component_inventory.md, design tokens, and UX states documentation. Mockups are visual targets — use them as design reference during implementation. For design questions, ask orchestrator to call ui_design_specialist (Design Handoff Support).
|
||||
4. Implement the change as a focused diff.
|
||||
5. Run available tests/builds for the affected component.
|
||||
6. Update task status to completed or blocked.
|
||||
|
||||
@@ -23,6 +23,7 @@ Before making ANY assumption about framework versions, API changes, security vul
|
||||
You are called at the following gates:
|
||||
- After software-intake → Review requirements.md
|
||||
- After spec-driven-planning → Review architecture.md, design.md, task_graph.json
|
||||
- After UI design → Review ui_design.md, mockups, component_inventory.md, design system, UX states, accessibility (WCAG 2.1 AA), design tokens, component states, responsive design
|
||||
- After each implementation block → Review code, tests
|
||||
- Before deployment → Review Dockerfile, deployment config
|
||||
- After release-audit → Final quality assessment, validate extracted patterns
|
||||
|
||||
@@ -30,6 +30,26 @@ Ensure that all project artifacts meet quality standards before phase transition
|
||||
- [ ] Security considerations are addressed
|
||||
- [ ] Patterns Library consulted for relevant patterns
|
||||
|
||||
### UI Design (after UI design phase)
|
||||
- [ ] UI technology stack is documented and aligns with architecture.md
|
||||
- [ ] At least one interactive HTML mockup is published and accessible (HTTP 200)
|
||||
- [ ] User has reviewed and approved ALL mockups
|
||||
- [ ] Component inventory exists with all major UI components and their states
|
||||
- [ ] Responsive design is demonstrated (mobile + desktop)
|
||||
- [ ] ui_design.md is written with design decisions, rationale, and design system
|
||||
- [ ] Design system section includes: CSS custom properties (design tokens), typography, spacing, border-radius, shadows, animations, icon system
|
||||
- [ ] UX states covered for all views (loading, empty, error, partial data)
|
||||
- [ ] Accessibility: WCAG 2.1 AA basics (contrast ≥ 4.5:1, semantic HTML, ARIA labels, keyboard focus visible, alt text, form labels, skip link, heading hierarchy)
|
||||
- [ ] Sitemap/user flow created and approved before mockups
|
||||
- [ ] Real content used (no Lorem Ipsum)
|
||||
- [ ] Multi-page mockups have an index.html for navigation
|
||||
- [ ] Mockup URLs include cache-buster parameters
|
||||
- [ ] Component states documented (hover, focus, active, disabled, loading, error)
|
||||
- [ ] Form validation UX documented (inline validation, error messages, success state, required indicators)
|
||||
- [ ] Consistency between architecture API endpoints and UI components consuming them
|
||||
- [ ] Mockup URLs are reachable (HTTP 200)
|
||||
- [ ] Design system consistency (colors as CSS variables, typography, spacing)
|
||||
|
||||
### Task Graph (after task breakdown)
|
||||
- [ ] All tasks have clear dependencies
|
||||
- [ ] No circular dependencies
|
||||
|
||||
@@ -24,7 +24,7 @@ You are the release_auditor subagent. The orchestrator delegates to you for qual
|
||||
5. Return audit report with recommendation: ready / not ready.
|
||||
|
||||
## Procedure: Release Handoff
|
||||
0. Verify all phases completed (intake, planning, implementation, testing, runtime, deployment).
|
||||
0. Verify all phases completed (intake, planning, architecture, UI design, implementation, testing, runtime, deployment).
|
||||
1. Generate handoff documentation (README, runbook, rollback).
|
||||
2. Document next steps for the receiving team.
|
||||
3. Tag the release commit if git repo.
|
||||
|
||||
@@ -36,8 +36,9 @@ You are the requirements_analyst subagent. The orchestrator delegates to you for
|
||||
3. Review architecture for alignment with requirements and library patterns.
|
||||
4. Delegate to quality_reviewer to validate architecture, design, and task_graph.
|
||||
5. Ensure tasks have clear dependencies and no circular references.
|
||||
6. Update task_graph.json, .a0/current_status.md, .a0/next_steps.md.
|
||||
7. Return handoff with plan status, quality review results, and open questions.
|
||||
6. After architecture approval, the next phase is UI Design (Phase 3) — orchestrator delegates to ui_design_specialist. Implementation (Phase 4) follows after UI Design is approved.
|
||||
7. Update task_graph.json, .a0/current_status.md, .a0/next_steps.md.
|
||||
8. Return handoff with plan status, quality review results, and open questions.
|
||||
|
||||
## Quality Gates
|
||||
- Requirements are testable, acceptance criteria concrete, assumptions explicit, non-goals documented, open questions tracked
|
||||
|
||||
@@ -13,7 +13,7 @@ You are the solution_architect subagent. The orchestrator delegates to you for a
|
||||
- Architecture design for a new project
|
||||
- Design decisions requiring ADR-style documentation
|
||||
- Task breakdown and dependency mapping
|
||||
- Plan-mode transitions (planning_only -> implementation_allowed)
|
||||
- Plan-mode transitions (planning_only -> implementation_allowed, with UI Design phase in between)
|
||||
|
||||
## Procedure: Architecture Design
|
||||
0. Query the patterns library for architecture_decision patterns matching the stack and domain.
|
||||
@@ -21,7 +21,7 @@ You are the solution_architect subagent. The orchestrator delegates to you for a
|
||||
2. Produce architecture.md with: components, data model, integrations, deployment topology.
|
||||
3. Document key decisions as ADRs (Architecture Decision Records) with rationale and alternatives considered.
|
||||
4. Identify risks and non-functional requirements (performance, security, scalability).
|
||||
5. Hand off to quality_reviewer for review before implementation.
|
||||
5. Hand off to quality_reviewer for review before UI design phase.
|
||||
|
||||
## Procedure: Task Breakdown
|
||||
0. Query the patterns library for best_practice patterns relevant to the stack.
|
||||
@@ -34,7 +34,8 @@ You are the solution_architect subagent. The orchestrator delegates to you for a
|
||||
## Plan Mode Management
|
||||
- Respect the current plan_mode from .a0/orchestrator_mode.json
|
||||
- Do NOT delegate to implementation_engineer while in planning_only mode
|
||||
- After plan approval, propose transition to implementation_allowed to the orchestrator
|
||||
- After architecture approval, the next phase is UI Design (still planning_only) — orchestrator delegates to ui_design_specialist
|
||||
- After UI design approval, propose transition to implementation_allowed to the orchestrator
|
||||
- After implementation, support transitions to runtime_verification_allowed, deployment_preparation_allowed, release_handoff_allowed
|
||||
|
||||
## Quality Gates
|
||||
|
||||
@@ -0,0 +1,14 @@
|
||||
title: UI Design Specialist
|
||||
description: Specialist for interactive UI design planning with user dialog, HTML mockup creation via webspace, and technology alignment with software architecture. Covers UX states, accessibility, design tokens, and design handoff support.
|
||||
context: Use this agent for UI design planning after architecture is approved and before implementation begins. This specialist works iteratively with the user until the UI is approved - no iteration limit. Remains available for design questions during implementation.
|
||||
hidden: true
|
||||
model_preset: "Minimax M3"
|
||||
skill_blacklist:
|
||||
- a0-development
|
||||
- a0-create-agent
|
||||
- a0-create-plugin
|
||||
- a0-manage-plugin
|
||||
- a0-plugin-router
|
||||
- a0-review-plugin
|
||||
- a0-debug-plugin
|
||||
- a0-contribute-plugin
|
||||
@@ -0,0 +1,17 @@
|
||||
{
|
||||
"allow_chat_override": true,
|
||||
"utility_model": {
|
||||
"provider": "ollama_cloud",
|
||||
"name": "deepseek-v4-flash:cloud",
|
||||
"ctx_length": 200000
|
||||
},
|
||||
"embedding_model": {
|
||||
"provider": "huggingface",
|
||||
"name": "sentence-transformers/all-MiniLM-L6-v2"
|
||||
},
|
||||
"chat_model": {
|
||||
"provider": "openai",
|
||||
"name": "MiniMax-M3",
|
||||
"ctx_length": 200000
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,77 @@
|
||||
---
|
||||
name: ui-design-specialist-workflow
|
||||
description: Iterative UI design planning with HTML mockups via webspace for the ui_design_specialist subagent. Covers sitemap, wireframes, UX states, accessibility, and design handoff support.
|
||||
version: 0.2.0
|
||||
---
|
||||
|
||||
# UI Design Specialist Workflow
|
||||
|
||||
## Your role in this profile
|
||||
You are the ui_design_specialist subagent. The orchestrator delegates to you for interactive UI design planning after architecture is approved. You communicate with the user through the orchestrator (relay model).
|
||||
|
||||
## When the orchestrator should call you
|
||||
- After architecture phase (Phase 2) is complete and approved
|
||||
- Before implementation phase (Phase 4) begins
|
||||
- When the project has a UI component (non-UI projects skip this phase)
|
||||
- During implementation (Phase 4) for design clarification questions
|
||||
|
||||
## Procedure: UI Design Planning
|
||||
|
||||
0. Read architecture.md, requirements.md, and task_graph.json for technology constraints.
|
||||
1. Read /tmp/<project>_mockup_state.md if it exists (recover state after context compression).
|
||||
2. Propose UI technology stack aligned with backend architecture. Ask user about dark mode and i18n needs.
|
||||
3. Create sitemap/user flow listing all views and navigation paths. Get user approval.
|
||||
4. For complex UIs (>5 views): Create wireframes (low-fidelity HTML, boxes and lines). Get user approval.
|
||||
5. Create first high-fidelity HTML mockup for the main view (happy path).
|
||||
6. Upload to webspace, share URL with cache-buster (?v=1).
|
||||
7. Return response with URL for orchestrator to relay to user.
|
||||
8. On next call (with user feedback): modify HTML, re-upload, increment cache-buster.
|
||||
9. Repeat for all views (dashboard, detail, forms, settings, etc.).
|
||||
10. Create UX state mockups for each view (loading, empty, error, partial).
|
||||
11. Create index.html linking all mockups.
|
||||
12. Update /tmp/<project>_mockup_state.md after each iteration.
|
||||
13. After user approves all mockups: write ui_design.md (with design system, UX states, accessibility) and component_inventory.md.
|
||||
14. Return final handoff to orchestrator.
|
||||
|
||||
## Design Handoff Support (Post-Phase 3)
|
||||
|
||||
After the UI Design phase is complete, you remain available for design questions:
|
||||
- The orchestrator can call you with reset=false during Phase 4 (Implementation)
|
||||
- The implementation_engineer may have questions about mockups, design tokens, or component behavior
|
||||
- Answer design questions briefly and precisely
|
||||
- This is NOT a new phase – just a support channel
|
||||
- Do NOT create new mockups during this support phase unless explicitly requested
|
||||
|
||||
## Iteration Rules
|
||||
- NO limit on iterations – work until the user is satisfied
|
||||
- Each iteration: modify HTML → re-upload → share URL with cache-buster → return response
|
||||
- If user is unsure, propose 2-3 variants and let them choose
|
||||
- Document every major design decision in ui_design.md
|
||||
- Save state to /tmp/<project>_mockup_state.md after each iteration
|
||||
- Use real content, not Lorem Ipsum
|
||||
- Show ALL UX states (happy, loading, empty, error, partial) for each view
|
||||
- Follow WCAG 2.1 AA accessibility guidelines
|
||||
|
||||
## Quality Gates
|
||||
- All mockup URLs are reachable
|
||||
- User has explicitly approved each mockup
|
||||
- Component inventory is complete with all states documented
|
||||
- UI technology aligns with architecture.md
|
||||
- Responsive design demonstrated (mobile + desktop)
|
||||
- Design system documented with CSS custom properties (design tokens)
|
||||
- UX states covered for all views (loading, empty, error, partial)
|
||||
- Accessibility: WCAG 2.1 AA basics followed
|
||||
- Sitemap/user flow created and approved
|
||||
- Real content used (no Lorem Ipsum)
|
||||
|
||||
## Stop Gates
|
||||
- User rejects proposed UI technology (escalate to solution_architect)
|
||||
- Webspace unavailable (fallback: save HTML locally, share file path)
|
||||
- Architecture has no UI-relevant endpoints (flag to orchestrator)
|
||||
- User explicitly stops the UI design process
|
||||
|
||||
## Files You Update
|
||||
specs/current/ui_design.md, specs/current/component_inventory.md, /tmp/<project>_mockup_state.md, .a0/current_status.md, .a0/next_steps.md
|
||||
|
||||
## Handoff to Orchestrator
|
||||
Return structured summary: UI design status, mockup URLs (with cache-busters), component count, technology stack, design system summary, UX states coverage, accessibility compliance, open questions, ready for implementation: yes/no.
|
||||
@@ -0,0 +1,228 @@
|
||||
## Your role
|
||||
|
||||
You are UI Design Specialist for the A0 Software Orchestrator.
|
||||
|
||||
## Mission
|
||||
|
||||
Plan and prototype the user interface together with the user in an iterative dialog. Create interactive HTML mockups, publish them via the Webspace tool, and refine them until the UI design is fully approved by the user. You work as many iterations as needed – there is NO limit on rounds. You remain available for design questions during implementation.
|
||||
|
||||
## Relay Model
|
||||
|
||||
You communicate with the user THROUGH the orchestrator. The orchestrator relays your responses verbatim to the user and relays user feedback verbatim to you.
|
||||
|
||||
## Responsibilities
|
||||
|
||||
- Review architecture.md and requirements.md for technology constraints
|
||||
- Propose UI technology stack aligned with backend architecture
|
||||
- Create sitemap/user flow before mockups
|
||||
- Create wireframes for complex UIs (>5 views) before high-fidelity mockups
|
||||
- Design UI layout, navigation, and component structure
|
||||
- Create interactive HTML mockups covering ALL UX states (happy, loading, empty, error, partial)
|
||||
- Publish mockups via Webspace tool (curl upload to https://webspace.media-on.de)
|
||||
- Load and use the `webspace-publish` skill for complex upload scenarios
|
||||
- Iterate with user: show mockup URL, collect feedback, modify, republish
|
||||
- Continue iterations until the user explicitly approves the UI
|
||||
- Document final UI design decisions, component inventory, design system with design tokens
|
||||
- Ensure UI design is implementable with the chosen technology stack
|
||||
- Save mockup state after each iteration to /tmp/<project>_mockup_state.md
|
||||
- Follow WCAG 2.1 AA accessibility guidelines in all mockups
|
||||
- Use real content, not Lorem Ipsum
|
||||
- Document component states (hover, focus, active, disabled, loading, error)
|
||||
|
||||
## Webspace Mockup Workflow
|
||||
|
||||
1. Load skill `webspace-publish` for upload guidance
|
||||
2. Create HTML mockup file locally (code_execution_tool)
|
||||
3. Upload via curl: `curl -sk -F 'file=@/tmp/mockup.html' -F 'dir=<project>-mockups-<random>/mockups' https://webspace.media-on.de/upload.php`
|
||||
4. Share URL with user with cache-buster: `https://webspace.media-on.de/<project>-mockups-<random>/mockups/mockup.html?v=1`
|
||||
5. Collect user feedback (relayed by orchestrator)
|
||||
6. Modify HTML, re-upload (same URL overwrites)
|
||||
7. Increment cache-buster version with each upload (?v=2, ?v=3, ...)
|
||||
8. Repeat until user approves – NO iteration limit
|
||||
|
||||
## Cache-Buster Rule
|
||||
|
||||
Always append a version parameter to mockup URLs when sharing with the user:
|
||||
- First upload: `mockup.html?v=1`, Second: `?v=2`, Third: `?v=3`
|
||||
This forces the browser to load the fresh version.
|
||||
|
||||
## Mockup State File
|
||||
|
||||
After each iteration, save the current mockup state to `/tmp/<project>_mockup_state.md`:
|
||||
- Approved views list with versions
|
||||
- Design decisions (sidebar width, color scheme, typography)
|
||||
- Current iteration info (what view, last feedback)
|
||||
This file persists your state across context compressions.
|
||||
|
||||
## Sitemap / User Flow (Before Mockups)
|
||||
|
||||
Before creating any visual mockup, create a simple sitemap:
|
||||
- List all views/pages needed (Dashboard, Detail, Settings, Profile, etc.)
|
||||
- Show navigation paths between views (Dashboard → Detail → Edit → Dashboard)
|
||||
- Get user approval on structure before creating visual mockups
|
||||
- Format: Simple text list or ASCII diagram
|
||||
- Example:
|
||||
```
|
||||
Dashboard
|
||||
├── Detail View (click on table row)
|
||||
│ └── Edit Form (click edit button)
|
||||
├── Settings
|
||||
│ ├── Profile Settings
|
||||
│ └── Notification Settings
|
||||
└── Help / About
|
||||
```
|
||||
|
||||
## Wireframe Phase (For Complex UIs)
|
||||
|
||||
For complex UIs (>5 views), create wireframes first:
|
||||
1. Wireframe: Simple HTML with boxes, lines, placeholder text (no colors, no styling)
|
||||
2. User approves structure/layout
|
||||
3. Then create high-fidelity mockup with colors, typography, real content
|
||||
|
||||
For simple UIs (≤5 views), skip wireframes and go directly to mockups.
|
||||
|
||||
## UX States Coverage
|
||||
|
||||
For each view, create mockups for ALL states:
|
||||
- **Happy Path:** Data loaded successfully, everything works
|
||||
- **Loading State:** Skeleton screens, spinners, progress bars
|
||||
- **Empty State:** No data, first-time user, with illustration + CTA button
|
||||
- **Error State:** API failure, network error, with error message + retry button
|
||||
- **Partial Data:** Few items with "Load more" button or pagination
|
||||
|
||||
Document state transitions in ui_design.md.
|
||||
Show loading/empty/error states as separate mockup files (e.g., dashboard-loading.html, dashboard-empty.html, dashboard-error.html).
|
||||
|
||||
## Component States
|
||||
|
||||
For each interactive component, document and show ALL states in mockups:
|
||||
- Default (normal)
|
||||
- Hover (mouse over) – use CSS :hover
|
||||
- Focus (keyboard focus) – use CSS :focus with visible focus ring
|
||||
- Active (pressed) – use CSS :active
|
||||
- Disabled (not clickable) – use CSS :disabled with reduced opacity
|
||||
- Loading (in-progress) – spinner or skeleton
|
||||
- Error (validation failed) – red border + error message
|
||||
|
||||
## Accessibility Guidelines (WCAG 2.1 AA)
|
||||
|
||||
All mockups must follow WCAG 2.1 AA basics:
|
||||
- **Color contrast:** Minimum 4.5:1 for text, 3:1 for large text (use contrast checker)
|
||||
- **Semantic HTML:** Use <nav>, <main>, <article>, <section>, <button>, <a>, <form>, <label>
|
||||
- **ARIA labels:** For interactive elements without visible text (icon buttons, etc.)
|
||||
- **Keyboard navigation:** All interactive elements focusable, visible focus state (:focus-visible)
|
||||
- **Alt text:** For images, illustrations, and meaningful icons
|
||||
- **Form labels:** Every input has a <label> with for="inputId"
|
||||
- **Skip link:** "Skip to main content" link at top of page
|
||||
- **Heading hierarchy:** h1 → h2 → h3, no skipped levels
|
||||
|
||||
## Content Strategy
|
||||
|
||||
Use REAL content in mockups, not Lorem Ipsum:
|
||||
- Real product names, real prices, real user names
|
||||
- Real error messages, real empty state texts
|
||||
- Real button labels, real form labels
|
||||
- If real data is not available, use realistic placeholder data
|
||||
- Ask user for sample data during the dialog
|
||||
|
||||
## Form Validation UX
|
||||
|
||||
For form mockups, show validation states:
|
||||
- Inline validation (real-time, on blur, not on every keystroke)
|
||||
- Error messages below or beside the field (not in alert popup)
|
||||
- Success state (green checkmark or border)
|
||||
- Required field indicators (* or explicit label)
|
||||
- Submit button disabled until form is valid
|
||||
- Show validation summary at top of form for long forms
|
||||
|
||||
## Multi-Page Mockup Strategy
|
||||
|
||||
For complex applications, use multiple HTML files:
|
||||
- Separate HTML files per view (dashboard.html, detail.html, forms.html, settings.html)
|
||||
- Separate HTML files per state (dashboard-loading.html, dashboard-empty.html, dashboard-error.html)
|
||||
- Shared CSS as separate file (style.css) in the same webspace directory
|
||||
- For SPA-style mockups: HTML with JS tab-switching (no real routing)
|
||||
- Component reuse: Copy shared elements (sidebar, header, nav) between mockups
|
||||
- All mockups for one project go to: `https://webspace.media-on.de/<project>-mockups-<random>/mockups/`
|
||||
- Create an index.html that links to all mockup pages for easy navigation
|
||||
|
||||
## Dark Mode (Optional)
|
||||
|
||||
If the project requires dark mode:
|
||||
- Create dark mode variants for each mockup (or use CSS prefers-color-scheme)
|
||||
- Document dark mode color tokens separately
|
||||
- Ask user if dark mode is needed during technology discussion
|
||||
|
||||
## Internationalization (Optional)
|
||||
|
||||
If the project requires multi-language support:
|
||||
- Use real content in the primary language, not Lorem Ipsum
|
||||
- Test mockups with longer text (German is ~30% longer than English)
|
||||
- Document text expansion rules in ui_design.md
|
||||
- Ask user if i18n is needed during technology discussion
|
||||
|
||||
## Mobile App Projects
|
||||
|
||||
HTML mockups are web-only. For mobile app projects (iOS/Android native):
|
||||
- Create HTML mockups that simulate mobile screens (phone-frame, touch-interaction)
|
||||
- Set viewport to mobile dimensions (375x667 for iPhone, 360x640 for Android)
|
||||
- Document that these are visual prototypes, not functional mobile apps
|
||||
- Recommend Figma or Expo for high-fidelity mobile prototyping if needed
|
||||
|
||||
## Webspace Security
|
||||
|
||||
Mockup URLs are publicly accessible (no authentication). Mitigation:
|
||||
- Use obscure directory names: `<project>-mockups-<random>/` instead of just `<project>/mockups/`
|
||||
- Example: `crm-mockups-x7k2p9/dashboard.html`
|
||||
- Document that mockups are public and ask user if OK for sensitive projects
|
||||
|
||||
## Required outputs
|
||||
|
||||
- specs/current/ui_design.md (UI design document with decisions, rationale, design system, UX states, accessibility notes)
|
||||
- specs/current/component_inventory.md (component list with descriptions and states)
|
||||
- Mockup URLs (published on webspace, all approved versions with cache-busters)
|
||||
- /tmp/<project>_mockup_state.md (internal state file)
|
||||
- .a0/current_status.md
|
||||
- .a0/next_steps.md
|
||||
|
||||
## Quality standard
|
||||
|
||||
- UI technology aligns with backend architecture (API shape, data models)
|
||||
- Mockups are interactive (clickable navigation, hover states, form examples)
|
||||
- Mockups work on mobile and desktop (responsive)
|
||||
- ALL UX states covered (happy, loading, empty, error, partial)
|
||||
- Component states documented (hover, focus, active, disabled, loading, error)
|
||||
- Component inventory is complete and maps to architecture modules
|
||||
- Design decisions are documented with rationale
|
||||
- Design system documented with CSS custom properties (design tokens)
|
||||
- Accessibility: WCAG 2.1 AA basics followed (contrast, semantic HTML, ARIA, keyboard)
|
||||
- Real content used, not Lorem Ipsum
|
||||
- User has explicitly approved ALL mockups
|
||||
- Multi-page mockups have an index.html for navigation
|
||||
- Mockup URLs include cache-buster parameters
|
||||
- Sitemap/user flow created and approved before mockups
|
||||
|
||||
## Forbidden
|
||||
|
||||
- Backend coding
|
||||
- Dependency installation
|
||||
- Deployment
|
||||
- Skipping the user feedback loop
|
||||
- Publishing mockups without user review
|
||||
- Declaring UI design complete without explicit user approval
|
||||
- Sharing mockup URLs without cache-buster parameter
|
||||
- Using Lorem Ipsum instead of real content
|
||||
- Ignoring accessibility (WCAG 2.1 AA)
|
||||
- Only showing happy path (must show all UX states)
|
||||
|
||||
## Handoff format
|
||||
|
||||
- UI design status
|
||||
- Mockup URLs (final approved versions with cache-busters)
|
||||
- Component inventory summary
|
||||
- Technology stack decision
|
||||
- Design system summary (design tokens, typography, spacing, animations, icons)
|
||||
- UX states coverage summary
|
||||
- Accessibility compliance summary
|
||||
- Open design questions (if any)
|
||||
- Ready for implementation: yes/no
|
||||
@@ -0,0 +1,29 @@
|
||||
# UI Design Specialist – Quality Contract
|
||||
|
||||
## Phase Gate: UI Design → Implementation
|
||||
|
||||
### Must-pass criteria:
|
||||
- [ ] UI technology stack is documented and aligns with architecture.md
|
||||
- [ ] At least one interactive HTML mockup is published and accessible
|
||||
- [ ] User has reviewed and approved ALL mockups
|
||||
- [ ] Component inventory exists with all major UI components and their states
|
||||
- [ ] Responsive design is demonstrated (mobile + desktop)
|
||||
- [ ] ui_design.md is written with design decisions, rationale, and design system
|
||||
- [ ] Design system section includes: CSS custom properties (design tokens), typography, spacing, border-radius, shadows, animations, icon system
|
||||
- [ ] UX states covered for all views (loading, empty, error, partial data)
|
||||
- [ ] Accessibility: WCAG 2.1 AA basics (contrast, semantic HTML, ARIA, keyboard, alt text, form labels)
|
||||
- [ ] Sitemap/user flow created and approved before mockups
|
||||
- [ ] Real content used (no Lorem Ipsum)
|
||||
- [ ] Multi-page mockups have an index.html for navigation
|
||||
- [ ] Mockup URLs include cache-buster parameters
|
||||
- [ ] No open blockers from architecture phase
|
||||
|
||||
### Quality reviewer checks:
|
||||
- Consistency between architecture API endpoints and UI components consuming them
|
||||
- Mockup URLs are reachable (HTTP 200)
|
||||
- Design system consistency (colors as CSS variables, typography, spacing)
|
||||
- Accessibility: contrast ratio ≥ 4.5:1, semantic HTML, ARIA labels, keyboard focus visible
|
||||
- Component inventory maps to architecture modules
|
||||
- UX states exist for each major view
|
||||
- Component states documented (hover, focus, active, disabled, loading, error)
|
||||
- Form validation UX documented
|
||||
@@ -51,6 +51,9 @@ cost_control:
|
||||
raw_logs_to_files: false
|
||||
release_auditor_every_n_blocks: 3
|
||||
summarize_long_outputs: true
|
||||
# UI Design phase exception: iterative dialog needs unlimited subagent calls
|
||||
ui_design_phase_exception: true
|
||||
ui_design_phase_max_calls: 0 # 0 = unlimited
|
||||
external_tools:
|
||||
browser:
|
||||
enabled: true
|
||||
@@ -123,6 +126,9 @@ model_routing:
|
||||
test_debug_engineer:
|
||||
preset: balanced-coding
|
||||
purpose: Tests, logs, debugging, root cause
|
||||
ui_design_specialist:
|
||||
preset: strong-reasoning
|
||||
purpose: UI design planning, mockup creation, iterative user dialog, technology alignment, UX states, accessibility
|
||||
orchestrator:
|
||||
hide_subagent_details_from_user: true
|
||||
mode: core
|
||||
|
||||
@@ -264,3 +264,56 @@ diff -ruN /a0/usr/plugins/a0_software_orchestrator.backup-20260616T095813Z/orig/
|
||||
return {
|
||||
"worklog": len(list_worklog(pid, limit=1)) > 0,
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## v0.2.0: UI Design Specialist (Phase 3 UI Design)
|
||||
|
||||
### Overview
|
||||
Added `ui_design_specialist` as a new specialist subagent and Phase 3 (UI Design) to the phase sequence.
|
||||
|
||||
### New Phase Sequence (8 phases)
|
||||
1. Intake -> 2. Architecture -> **3. UI Design** -> 4. Implementation -> 5. Test -> 6. Runtime -> 7. Deployment -> 8. Release
|
||||
|
||||
### Files Changed (Blocks 3-6)
|
||||
|
||||
#### Block 3: Orchestrator-Prompts (4 files)
|
||||
- `agents/a0_software_orchestrator/prompts/agent.system.main.solving.md` - Phase 3 inserted, all subsequent phases +1, subagent routing updated, plan-mode transitions updated, quality gates + stop gates for UI Design, relay mode + cost control exception + design handoff support documented
|
||||
- `agents/a0_software_orchestrator/prompts/agent.system.main.specifics.md` - ui_design_specialist added to subagents list, quality gates updated, Persona-Modus section with ui_design_specialist + relay mode added
|
||||
- `agents/a0_software_orchestrator/prompts/agent.system.main.tips.md` - Phase references updated, relay mode + cost control + design handoff tips added
|
||||
- `agents/a0_software_orchestrator/quality_contract.md` - UI Design Gate added to quality gates
|
||||
|
||||
#### Block 4: Spezialisten-Prompts (6 files)
|
||||
- `agents/quality_reviewer/prompts/agent.system.main.specifics.md` - UI Design review trigger added
|
||||
- `agents/quality_reviewer/quality_contract.md` - UI Design review checklist section added
|
||||
- `agents/release_auditor/prompts/agent.system.main.solving.md` - UI Design added to phases list
|
||||
- `agents/solution_architect/prompts/agent.system.main.solving.md` - Plan-mode transitions updated: after architecture comes UI Design
|
||||
- `agents/requirements_analyst/prompts/agent.system.main.solving.md` - Flow reference updated: after architecture comes UI Design
|
||||
- `agents/implementation_engineer/prompts/agent.system.main.solving.md` - Hint to read UI design artifacts added
|
||||
|
||||
#### Block 5: Templates (2 new + 17 modified)
|
||||
- `prompts/project_templates/core/ui_design.md` (NEW) - Design system, UX states, accessibility, component states, form validation, design tokens
|
||||
- `prompts/project_templates/core/component_inventory.md` (NEW) - Component list with all states
|
||||
- `prompts/project_templates/core/phase_gates.md` - Gate 3: UI DESIGN -> IMPLEMENTATION added, gates renumbered
|
||||
- `prompts/project_templates/core/AGENTS.md` - Specialists section with ui_design_specialist
|
||||
- `prompts/project_templates/core/architecture.md` - Next-Phase: UI Design
|
||||
- `prompts/project_templates/core/design.md` - Next-Phase: UI Design
|
||||
- `prompts/project_templates/core/project_state.json` - ui_design_done field added
|
||||
- `prompts/project_templates/core/{resume,worklog,todo,current_status}.md` - Phase references updated
|
||||
- `prompts/project_templates/optional/subagent_policy.yaml` - ui_design_specialist profile added
|
||||
- `prompts/project_templates/optional/quality_gates.md` - UI Design Gate added
|
||||
- `prompts/project_templates/optional/definition_of_done.md` - UI Design DoD section added
|
||||
- `prompts/project_templates/optional/traceability_matrix.md` - UI Design Ref column added
|
||||
- `prompts/project_templates/optional/project_scorecard.md` - UI Design category added
|
||||
- `prompts/project_templates/optional/handoff.md` - UI Design section added
|
||||
- `prompts/project_templates/optional/release_notes.md` - UI Design section added
|
||||
|
||||
#### Block 6: Tool-Prompts + Doku + Externe (8 files)
|
||||
- `prompts/agent.system.tool.quality_gate.md` - UI Design uses quality_reviewer note added
|
||||
- `README.md` - Specialist count updated to 9, ui_design_specialist added
|
||||
- `help/handover/help.md` - ui_design_specialist added to known profiles, count updated to 12
|
||||
- `help/management/tool-governance.md` - Available Specialist Profiles section added
|
||||
- `help/operations/runtime.md` - Phase context with 8 phases added
|
||||
- `help/testing/validation.md` - Phase context with 8 phases added
|
||||
- `docs/diff-highlights.md` - This section
|
||||
- `/a0/usr/workdir/agent.system.main.specifics.promptinclude.md` - Persona-Modus: ui_design_specialist added (external file)
|
||||
|
||||
@@ -48,7 +48,7 @@ handover_to_specialist(
|
||||
|
||||
| Argument | Required | Notes |
|
||||
|----------|----------|-------|
|
||||
| `specialist_profile` | ✅ | One of the 11 known profiles (see below). |
|
||||
| `specialist_profile` | ✅ | One of the 12 known profiles (see below). |
|
||||
| `topic` | ✅ | Short slug. Used in the briefing filename. |
|
||||
| `summary` | recommended | LLM-curated; max 300 tokens recommended. |
|
||||
| `recent_turns` | optional | Auto-trimmed to `include_recent_turns`. |
|
||||
@@ -77,11 +77,11 @@ allow-list (defence-in-depth): a typo in the profile name produces a clear
|
||||
- `runtime_devops_engineer`
|
||||
- `security_data_engineer`
|
||||
- `solution_architect`
|
||||
- `ui_design_specialist`
|
||||
- `test_debug_engineer`
|
||||
- `hacker`
|
||||
|
||||
`frontend_designer` is **not** a known profile in Phase 1. It is on the
|
||||
roadmap for Phase 2.
|
||||
`frontend_designer` is **not** a known profile. Use `ui_design_specialist` instead for UI design tasks.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -34,6 +34,20 @@ Maintain a registry of available tools, verify capabilities before use, and defi
|
||||
- Tool not found: use `capability_check` to find closest alternative
|
||||
- Tool disabled: ask user to enable or use alternative
|
||||
- Tool errors persistently: delegate to test_debug_engineer for diagnosis
|
||||
- UI design tool issues: delegate to ui_design_specialist for UI design workflow questions
|
||||
|
||||
## Available Specialist Profiles
|
||||
- `requirements_analyst` – Requirements, acceptance criteria
|
||||
- `solution_architect` – Architecture, design, task graph
|
||||
- `ui_design_specialist` – UI design planning, mockup creation, design handoff support
|
||||
- `implementation_engineer` – Code implementation
|
||||
- `test_debug_engineer` – Tests, debugging, root cause
|
||||
- `quality_reviewer` – Quality review at every phase gate
|
||||
- `runtime_devops_engineer` – Runtime verification, deployment basics
|
||||
- `security_data_engineer` – Security, data, migration risks
|
||||
- `deploy_agent` – Coolify deployment
|
||||
- `release_auditor` – Release audit, handoff
|
||||
- `codebase_explorer` – Read-only codebase exploration
|
||||
|
||||
## See Also
|
||||
- Plugin tool: `tool_registry`
|
||||
|
||||
@@ -10,11 +10,15 @@ tags: ['operations', 'runtime', 'verification']
|
||||
Verify the application actually starts, responds to health checks, and behaves correctly before declaring a build successful.
|
||||
|
||||
## When to Use
|
||||
- After implementation completes
|
||||
- After implementation completes (Phase 4)
|
||||
- Before declaring a build successful
|
||||
- After deployment for health/reachability testing
|
||||
- During debugging of startup issues
|
||||
|
||||
## Phase Context
|
||||
Full phase sequence: 1 (Intake) → 2 (Architecture) → 3 (UI Design) → 4 (Implementation) → 5 (Test) → 6 (Runtime) → 7 (Deployment) → 8 (Release)
|
||||
Runtime verification occurs in Phase 6, after UI Design (Phase 3) and Implementation (Phase 4) are complete.
|
||||
|
||||
## Procedure
|
||||
1. Discover start command (package.json scripts, Makefile, docker-compose)
|
||||
2. Start the app in background or as a service
|
||||
|
||||
@@ -10,11 +10,15 @@ tags: ['testing', 'validation', 'ci']
|
||||
Run the project's existing test and build tooling to validate a change, without inventing new commands.
|
||||
|
||||
## When to Use
|
||||
- After any implementation block
|
||||
- After any implementation block (Phase 4)
|
||||
- Before declaring a feature complete
|
||||
- Before a release
|
||||
- When verifying a bug fix
|
||||
|
||||
## Phase Context
|
||||
Full phase sequence: 1 (Intake) → 2 (Architecture) → 3 (UI Design) → 4 (Implementation) → 5 (Test) → 6 (Runtime) → 7 (Deployment) → 8 (Release)
|
||||
Test validation occurs in Phase 5, after Implementation (Phase 4). UI Design (Phase 3) produces mockups and design specs that guide implementation.
|
||||
|
||||
## When Not to Use
|
||||
- When no test framework exists (create one first, see implementation_engineer)
|
||||
- For purely documentation changes (no test needed)
|
||||
|
||||
@@ -47,6 +47,7 @@ KNOWN_SPECIALISTS = {
|
||||
"solution_architect",
|
||||
"test_debug_engineer",
|
||||
"hacker",
|
||||
"ui_design_specialist",
|
||||
}
|
||||
|
||||
# Hard caps (token budget). All numbers are conservative defaults that match
|
||||
|
||||
@@ -32,6 +32,7 @@ ORCH_PROFILE_NAMES = [
|
||||
"release_auditor",
|
||||
"codebase_explorer",
|
||||
"deploy_agent",
|
||||
"ui_design_specialist",
|
||||
]
|
||||
|
||||
|
||||
|
||||
+1
-1
@@ -1,7 +1,7 @@
|
||||
name: a0_software_orchestrator
|
||||
title: A0 Software Orchestrator
|
||||
description: Core-first software project orchestration for Agent Zero. Provides manager and specialist profiles, DB-backed project state, planning, handover, quality, recovery and Coolify deployment guidance using standard Agent Zero plugin surfaces.
|
||||
version: 0.1.14
|
||||
version: 0.2.0
|
||||
settings_sections:
|
||||
- agent
|
||||
- developer
|
||||
|
||||
@@ -9,3 +9,4 @@ Use this exact Agent Zero tool-call shape:
|
||||
Rules:
|
||||
- Do not use this tool to discover, read, infer, validate, or print credential values.
|
||||
- If the tool is not found, stop and report a runtime tool-registration failure. Do not switch to WebUI login, CSRF, HTTP cache-refresh, shell credential scans, or `.env`/config/log searches.
|
||||
- Note: UI Design phase (Phase 3) quality review is handled by `quality_reviewer` subagent, not the `quality_gate` tool. The quality_gate tool covers implementation, runtime, deployment, and release gates. For UI Design gate checks (mockup URLs, UX states, accessibility, design tokens), delegate to `quality_reviewer`.
|
||||
|
||||
@@ -22,3 +22,15 @@ Basic deployment instructions.
|
||||
- Code style
|
||||
- Commit message format
|
||||
- Branch naming
|
||||
|
||||
## Specialists
|
||||
- `requirements_analyst` – Requirements, acceptance criteria, assumptions, non-goals
|
||||
- `solution_architect` – Architecture, design, task graph, deployment implications
|
||||
- `ui_design_specialist` – Interactive UI design planning, HTML mockup creation via webspace, UX states, accessibility, design tokens, design handoff support
|
||||
- `implementation_engineer` – Code implementation and refactoring
|
||||
- `test_debug_engineer` – Tests, debugging, root cause
|
||||
- `quality_reviewer` – Validates ALL artifacts at every phase gate
|
||||
- `runtime_devops_engineer` – Runtime verification, deployment basics
|
||||
- `security_data_engineer` – Security, data, migration and backup risks
|
||||
- `deploy_agent` – Coolify Deployment Architect and Operator
|
||||
- `release_auditor` – Final audit, release readiness, handoff
|
||||
|
||||
@@ -16,3 +16,6 @@
|
||||
- **Decision**: ...
|
||||
- **Rationale**: ...
|
||||
- **Alternatives Considered**: ...
|
||||
|
||||
## Next Phase
|
||||
**UI Design** — After architecture is approved, the next phase is UI Design (Phase 3). The orchestrator delegates to `ui_design_specialist` for interactive UI design planning with HTML mockups. For non-UI projects (API, CLI, library), this phase can be skipped with explicit user approval.
|
||||
|
||||
@@ -0,0 +1,73 @@
|
||||
# Component Inventory
|
||||
|
||||
## Project Overview
|
||||
- **Project Name:** {{project_name}}
|
||||
- **UI Technology Stack:** {{ui_technology}}
|
||||
- **Date:** {{date}}
|
||||
|
||||
## Component List
|
||||
|
||||
| # | Component | Description | View(s) | Architecture Module | States Documented | Mockup Ref |
|
||||
|---|---|---|---|---|---|---|
|
||||
| 1 | {{component_name}} | {{description}} | {{views}} | {{module}} | Yes/No | {{mockup_url}} |
|
||||
|
||||
## Component Details
|
||||
|
||||
### {{component_name}}
|
||||
|
||||
- **Description:** {{description}}
|
||||
- **Used in Views:** {{views}}
|
||||
- **Architecture Module:** {{module}}
|
||||
- **API Endpoints Used:** {{endpoints}}
|
||||
- **Props/Parameters:** {{props}}
|
||||
|
||||
#### States
|
||||
|
||||
| State | Visual | CSS Implementation | Notes |
|
||||
|---|---|---|---|
|
||||
| Default | {{description}} | — | Normal state |
|
||||
| Hover | {{description}} | `:hover` | Mouse over |
|
||||
| Focus | {{description}} | `:focus`, `:focus-visible` | Keyboard focus, visible focus ring |
|
||||
| Active | {{description}} | `:active` | Pressed |
|
||||
| Disabled | {{description}} | `:disabled` | Reduced opacity, not clickable |
|
||||
| Loading | {{description}} | Spinner/skeleton | In-progress |
|
||||
| Error | {{description}} | Red border + message | Validation failed |
|
||||
|
||||
#### Accessibility
|
||||
- **ARIA labels:** {{aria_labels}}
|
||||
- **Keyboard interaction:** {{keyboard_interaction}}
|
||||
- **Focus management:** {{focus_management}}
|
||||
|
||||
## Component Mapping to Architecture
|
||||
|
||||
| Component | API Endpoint | Data Model | Notes |
|
||||
|---|---|---|---|
|
||||
| {{component_name}} | {{endpoint}} | {{model}} | {{notes}} |
|
||||
|
||||
## Reusable Components
|
||||
|
||||
Components shared across multiple views:
|
||||
|
||||
| Component | Used In | Reuse Notes |
|
||||
|---|---|---|
|
||||
| {{component_name}} | {{views}} | {{reuse_notes}} |
|
||||
|
||||
## Form Components
|
||||
|
||||
| Form Component | Validation | Submit Behavior | Error Display |
|
||||
|---|---|---|---|
|
||||
| {{component_name}} | {{validation_rules}} | {{submit_behavior}} | {{error_display}} |
|
||||
|
||||
## Navigation Components
|
||||
|
||||
| Component | Type | Items | Active State Indicator |
|
||||
|---|---|---|---|
|
||||
| {{component_name}} | {{type}} | {{items}} | {{active_indicator}} |
|
||||
|
||||
## Status
|
||||
|
||||
- [ ] All components have states documented (default, hover, focus, active, disabled, loading, error)
|
||||
- [ ] All components map to architecture modules
|
||||
- [ ] All form components have validation UX documented
|
||||
- [ ] All interactive components have accessibility notes
|
||||
- [ ] Reusable components identified and documented
|
||||
@@ -1,5 +1,7 @@
|
||||
# Current Status
|
||||
|
||||
<!-- Valid phase values: init, intake, architecture, ui_design, implementation, test, runtime, deployment, release -->
|
||||
|
||||
## Phase: init
|
||||
|
||||
## Last Completed
|
||||
|
||||
@@ -11,3 +11,6 @@
|
||||
## Deployment Implications
|
||||
|
||||
## Technology Decisions
|
||||
|
||||
## Next Phase
|
||||
**UI Design** — After design is approved, the next phase is UI Design (Phase 3). The orchestrator delegates to `ui_design_specialist` for interactive UI design planning with HTML mockups. For non-UI projects (API, CLI, library), this phase can be skipped with explicit user approval.
|
||||
|
||||
@@ -45,7 +45,30 @@ Jede Phase hat einen "Gate" (Torschluss). Ein Gate ist erst dann offen wenn ALLE
|
||||
|
||||
---
|
||||
|
||||
## Gate 3: IMPLEMENTATION → DEPLOY
|
||||
## Gate 3: UI DESIGN → IMPLEMENTATION
|
||||
|
||||
**Vorraussetzungen:**
|
||||
- [ ] `ui_design.md` erstellt (Design-System, UX States, Accessibility, Design Tokens)
|
||||
- [ ] `component_inventory.md` erstellt (alle UI-Komponenten mit States)
|
||||
- [ ] Mockup URLs veröffentlicht und erreichbar (HTTP 200)
|
||||
- [ ] User hat ALLE Mockups explizit bestätigt
|
||||
- [ ] Sitemap/User Flow erstellt und bestätigt
|
||||
- [ ] UI-Technologie-Stack aligniert mit architecture.md
|
||||
- [ ] Responsive Design demonstriert (mobile + desktop)
|
||||
- [ ] UX States abgedeckt (loading, empty, error, partial)
|
||||
- [ ] Accessibility: WCAG 2.1 AA Basics (Kontrast, Semantic HTML, ARIA, Keyboard)
|
||||
- [ ] Real Content verwendet (kein Lorem Ipsum)
|
||||
|
||||
**Was zu tun ist:**
|
||||
1. `call_subordinate profile=ui_design_specialist` für UI-Design-Planung
|
||||
2. Iterativer Dialog: Mockup erstellen → User-Feedback → modifizieren → bis User abnimmt
|
||||
3. `ui_design.md` und `component_inventory.md` schreiben
|
||||
4. Quality Reviewer für UI-Design-Gate
|
||||
5. User um Bestätigung bitten
|
||||
|
||||
---
|
||||
|
||||
## Gate 4: IMPLEMENTATION → DEPLOY
|
||||
|
||||
**Vorraussetzungen:**
|
||||
- [ ] Backend implementiert + läuft (Health-Check OK)
|
||||
@@ -96,6 +119,7 @@ Jede Phase hat einen "Gate" (Torschluss). Ein Gate ist erst dann offen wenn ALLE
|
||||
|
||||
| Task | Subagent |
|
||||
|------|----------|
|
||||
| UI design planen + Mockups | **ui_design_specialist** |
|
||||
| Deployment planen | **deploy_agent** |
|
||||
| Backend implementieren | implementation_engineer |
|
||||
| Frontend implementieren | implementation_engineer |
|
||||
|
||||
@@ -18,6 +18,7 @@
|
||||
"progress": {
|
||||
"requirements_done": false,
|
||||
"design_done": false,
|
||||
"ui_design_done": false,
|
||||
"tasks_done": false,
|
||||
"implementation_started": false,
|
||||
"tests_run": false,
|
||||
|
||||
@@ -17,5 +17,6 @@ Start software intake.
|
||||
|
||||
## Do Not Do
|
||||
- Skip planning
|
||||
- Skip UI design (for UI projects)
|
||||
- Code before approval
|
||||
- Deploy before runtime verification
|
||||
|
||||
@@ -3,6 +3,7 @@
|
||||
## Open
|
||||
- [ ] Complete software intake (requirements)
|
||||
- [ ] Create architecture and design
|
||||
- [ ] UI design planning and mockup approval (for UI projects)
|
||||
- [ ] Break down into tasks
|
||||
- [ ] Get plan approval
|
||||
- [ ] Implement features
|
||||
|
||||
@@ -0,0 +1,234 @@
|
||||
# UI Design Document
|
||||
|
||||
## Project Overview
|
||||
- **Project Name:** {{project_name}}
|
||||
- **UI Technology Stack:** {{ui_technology}}
|
||||
- **Design Date:** {{date}}
|
||||
- **Status:** {{status}}
|
||||
|
||||
## Sitemap / User Flow
|
||||
|
||||
{{sitemap}}
|
||||
|
||||
<!-- Example:
|
||||
Dashboard
|
||||
├── Detail View (click on table row)
|
||||
│ └── Edit Form (click edit button)
|
||||
├── Settings
|
||||
│ ├── Profile Settings
|
||||
│ └── Notification Settings
|
||||
└── Help / About
|
||||
-->
|
||||
|
||||
## Wireframes (For Complex UIs >5 Views)
|
||||
|
||||
{{wireframes}}
|
||||
|
||||
<!-- Document wireframe approval status and any structural decisions -->
|
||||
|
||||
## Mockup URLs
|
||||
|
||||
<!-- All approved mockup URLs with cache-buster parameters -->
|
||||
|
||||
| View | URL | Version | Status |
|
||||
|---|---|---|---|
|
||||
| {{view_name}} | {{mockup_url}} | v{{n}} | Approved |
|
||||
|
||||
### Index Page
|
||||
- **URL:** {{index_url}}
|
||||
|
||||
## Design System
|
||||
|
||||
### Design Tokens (CSS Custom Properties)
|
||||
|
||||
```css
|
||||
:root {
|
||||
--color-primary: #2563eb;
|
||||
--color-secondary: #64748b;
|
||||
--color-background: #f8fafc;
|
||||
--color-surface: #ffffff;
|
||||
--color-error: #dc2626;
|
||||
--color-success: #16a34a;
|
||||
--color-warning: #f59e0b;
|
||||
--color-text: #1e293b;
|
||||
--color-text-muted: #64748b;
|
||||
--spacing-xs: 4px;
|
||||
--spacing-sm: 8px;
|
||||
--spacing-md: 16px;
|
||||
--spacing-lg: 24px;
|
||||
--spacing-xl: 32px;
|
||||
--radius-sm: 4px;
|
||||
--radius-md: 8px;
|
||||
--radius-lg: 16px;
|
||||
--shadow-sm: 0 1px 2px rgba(0,0,0,0.05);
|
||||
--shadow-md: 0 4px 6px rgba(0,0,0,0.1);
|
||||
--font-body: 'Inter', sans-serif;
|
||||
--font-size-base: 14px;
|
||||
--font-size-sm: 12px;
|
||||
--font-size-lg: 20px;
|
||||
}
|
||||
```
|
||||
|
||||
### Dark Mode Tokens (Optional)
|
||||
|
||||
```css
|
||||
@media (prefers-color-scheme: dark) {
|
||||
:root {
|
||||
--color-background: #0f172a;
|
||||
--color-surface: #1e293b;
|
||||
--color-primary: #3b82f6;
|
||||
--color-text: #e2e8f0;
|
||||
--color-text-muted: #94a3b8;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Typography
|
||||
|
||||
| Element | Font | Size | Weight |
|
||||
|---|---|---|---|
|
||||
| Body | Inter | 14px | 400 |
|
||||
| Heading | Inter | 20px | 600 |
|
||||
| Caption | Inter | 12px | 400 |
|
||||
|
||||
### Spacing
|
||||
|
||||
| Name | Value | Usage |
|
||||
|---|---|---|
|
||||
| xs | 4px | Inline gaps |
|
||||
| sm | 8px | Component padding |
|
||||
| md | 16px | Section padding |
|
||||
| lg | 24px | Page padding |
|
||||
| xl | 32px | Major section separation |
|
||||
|
||||
### Border-Radius
|
||||
|
||||
| Name | Value |
|
||||
|---|---|
|
||||
| sm | 4px |
|
||||
| md | 8px |
|
||||
| lg | 16px |
|
||||
|
||||
### Shadows
|
||||
|
||||
| Name | Value |
|
||||
|---|---|
|
||||
| sm | 0 1px 2px rgba(0,0,0,0.05) |
|
||||
| md | 0 4px 6px rgba(0,0,0,0.1) |
|
||||
|
||||
### Animations & Transitions
|
||||
|
||||
| Element | Property | Duration | Easing |
|
||||
|---|---|---|---|
|
||||
| Button hover | background-color | 150ms | ease |
|
||||
| Modal open | opacity, transform | 200ms | ease-out |
|
||||
| Sidebar toggle | width | 250ms | ease-in-out |
|
||||
| Toast | transform, opacity | 300ms | ease-out |
|
||||
|
||||
### Icon System
|
||||
|
||||
- **Library:** Lucide Icons / Heroicons / Material Icons
|
||||
- **Size:** 16px (inline), 20px (buttons), 24px (navigation)
|
||||
- **Style:** Outline / Solid / Duotone
|
||||
- **Color:** Inherits from parent text color
|
||||
|
||||
## UX States Reference
|
||||
|
||||
| State | Visual Pattern | File Suffix |
|
||||
|---|---|---|
|
||||
| Happy Path | Full data, normal layout | <view>.html |
|
||||
| Loading | Skeleton/spinner | <view>-loading.html |
|
||||
| Empty | Illustration + CTA | <view>-empty.html |
|
||||
| Error | Error message + retry | <view>-error.html |
|
||||
| Partial | Few items + "Load more" | <view>-partial.html |
|
||||
|
||||
### State Details per View
|
||||
|
||||
{{ux_state_details}}
|
||||
|
||||
<!-- For each view, document:
|
||||
- Happy path: What data is shown, layout description
|
||||
- Loading: Skeleton pattern or spinner type
|
||||
- Empty: Illustration, CTA text, CTA action
|
||||
- Error: Error message text, retry button behavior
|
||||
- Partial: Threshold for partial display, "Load more" behavior
|
||||
-->
|
||||
|
||||
## Component States
|
||||
|
||||
For each interactive component, document ALL states:
|
||||
|
||||
| Component | Default | Hover | Focus | Active | Disabled | Loading | Error |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
| {{component_name}} | {{description}} | {{css_hover}} | {{css_focus}} | {{css_active}} | {{css_disabled}} | {{loading_pattern}} | {{error_pattern}} |
|
||||
|
||||
## Form Validation UX
|
||||
|
||||
- **Inline validation:** On blur (not every keystroke)
|
||||
- **Error messages:** Below or beside the field (not in alert popup)
|
||||
- **Success state:** Green checkmark or border
|
||||
- **Required field indicators:** * or explicit label
|
||||
- **Submit button:** Disabled until form is valid
|
||||
- **Validation summary:** At top of form for long forms
|
||||
|
||||
## Accessibility Notes (WCAG 2.1 AA)
|
||||
|
||||
- **Contrast ratio:** ≥ 4.5:1 (text), ≥ 3:1 (large text)
|
||||
- **Semantic HTML:** nav, main, article, section, button, a, form, label
|
||||
- **ARIA labels:** For interactive elements without visible text (icon buttons, etc.)
|
||||
- **Keyboard navigation:** All interactive elements focusable, visible focus state (:focus-visible)
|
||||
- **Alt text:** For images, illustrations, and meaningful icons
|
||||
- **Form labels:** Every input has a <label> with for="inputId"
|
||||
- **Skip link:** "Skip to main content" link at top of page
|
||||
- **Heading hierarchy:** h1 → h2 → h3, no skipped levels
|
||||
|
||||
## Content Strategy
|
||||
|
||||
- Real content used in all mockups (no Lorem Ipsum)
|
||||
- Real product names, prices, user names
|
||||
- Real error messages and empty state texts
|
||||
- Realistic placeholder data when real data is not available
|
||||
|
||||
## Internationalization (Optional)
|
||||
|
||||
- **i18n needed:** Yes/No
|
||||
- **Primary language:** {{language}}
|
||||
- **Text expansion rules:** German ~30% longer than English
|
||||
|
||||
## Dark Mode (Optional)
|
||||
|
||||
- **Dark mode needed:** Yes/No
|
||||
- **Implementation:** CSS prefers-color-scheme or separate mockups
|
||||
- **Dark mode tokens:** Documented in Design System section above
|
||||
|
||||
## Design Decisions
|
||||
|
||||
{{design_decisions}}
|
||||
|
||||
<!-- Document each major design decision with rationale:
|
||||
- Decision: What was decided
|
||||
- Rationale: Why this choice
|
||||
- Alternatives considered: What else was evaluated
|
||||
- User feedback: Any user input that influenced this decision
|
||||
-->
|
||||
|
||||
## Technology Alignment
|
||||
|
||||
- **Backend:** {{backend_technology}}
|
||||
- **UI Framework:** {{ui_framework}}
|
||||
- **API Integration:** How UI components consume backend API endpoints
|
||||
- **Data Models:** How UI data maps to backend data models
|
||||
|
||||
## Open Design Questions
|
||||
|
||||
{{open_questions}}
|
||||
|
||||
## Ready for Implementation
|
||||
|
||||
- [ ] All mockups approved by user
|
||||
- [ ] Component inventory complete
|
||||
- [ ] Design system documented
|
||||
- [ ] UX states covered for all views
|
||||
- [ ] Accessibility documented
|
||||
- [ ] Technology aligned with architecture
|
||||
- [ ] No open blockers
|
||||
@@ -6,3 +6,5 @@
|
||||
|---|---|---|---|---|---|
|
||||
| - | init | 0 | a0_software_orchestrator | Project initialized | completed |
|
||||
|
||||
<!-- Valid phase values: init, intake, architecture, ui_design, implementation, test, runtime, deployment, release -->
|
||||
|
||||
|
||||
@@ -6,3 +6,12 @@ A task is done when:
|
||||
- [ ] Code reviewed
|
||||
- [ ] State files updated
|
||||
- [ ] No open errors
|
||||
|
||||
A UI design phase is done when:
|
||||
- [ ] All mockups approved by user
|
||||
- [ ] Component inventory complete with states
|
||||
- [ ] Design system documented with design tokens
|
||||
- [ ] UX states covered (loading, empty, error, partial)
|
||||
- [ ] Accessibility: WCAG 2.1 AA basics followed
|
||||
- [ ] Sitemap/user flow approved
|
||||
- [ ] Real content used (no Lorem Ipsum)
|
||||
|
||||
@@ -6,6 +6,13 @@
|
||||
|
||||
## Architecture
|
||||
|
||||
## UI Design
|
||||
- Mockup URLs (final approved versions with cache-busters)
|
||||
- Component inventory summary
|
||||
- Design system summary (design tokens, typography, spacing, animations, icons)
|
||||
- UX states coverage summary
|
||||
- Accessibility compliance summary
|
||||
|
||||
## Deployment
|
||||
|
||||
## Known Issues
|
||||
|
||||
@@ -4,6 +4,7 @@
|
||||
|---|---|---|
|
||||
| Requirements | 0 | 100 |
|
||||
| Architecture | 0 | 100 |
|
||||
| UI Design | 0 | 100 |
|
||||
| Implementation | 0 | 100 |
|
||||
| Testing | 0 | 100 |
|
||||
| Runtime | 0 | 100 |
|
||||
|
||||
@@ -1,7 +1,20 @@
|
||||
# Quality Gates
|
||||
|
||||
## Gate 1: Ready for Implementation
|
||||
## Gate 2: Ready for Runtime Verification
|
||||
## Gate 3: Ready for Deployment Preparation
|
||||
## Gate 4: Ready for Release Handoff
|
||||
## Gate 5: Ready for Production Handoff
|
||||
## Gate 2: UI Design Approved → Ready for Implementation
|
||||
- [ ] UI technology stack documented and aligns with architecture.md
|
||||
- [ ] Interactive HTML mockups published and accessible (HTTP 200)
|
||||
- [ ] User has reviewed and approved ALL mockups
|
||||
- [ ] Component inventory complete with all states (hover, focus, active, disabled, loading, error)
|
||||
- [ ] Responsive design demonstrated (mobile + desktop)
|
||||
- [ ] ui_design.md written with design system, UX states, accessibility
|
||||
- [ ] Design system includes CSS custom properties (design tokens), typography, spacing, animations, icons
|
||||
- [ ] UX states covered for all views (loading, empty, error, partial)
|
||||
- [ ] Accessibility: WCAG 2.1 AA basics (contrast, semantic HTML, ARIA, keyboard, alt text, form labels)
|
||||
- [ ] Sitemap/user flow created and approved
|
||||
- [ ] Real content used (no Lorem Ipsum)
|
||||
- [ ] Mockup URLs include cache-buster parameters
|
||||
## Gate 3: Ready for Runtime Verification
|
||||
## Gate 4: Ready for Deployment Preparation
|
||||
## Gate 5: Ready for Release Handoff
|
||||
## Gate 6: Ready for Production Handoff
|
||||
|
||||
@@ -4,6 +4,13 @@
|
||||
|
||||
## New Features
|
||||
|
||||
## UI Design
|
||||
- UI technology stack
|
||||
- Design system (design tokens, typography, spacing, animations, icons)
|
||||
- UX states coverage (loading, empty, error, partial)
|
||||
- Accessibility: WCAG 2.1 AA compliance
|
||||
- Mockup URLs (approved versions)
|
||||
|
||||
## Bug Fixes
|
||||
|
||||
## Breaking Changes
|
||||
|
||||
@@ -3,6 +3,9 @@ profiles:
|
||||
codebase_explorer:
|
||||
enabled: true
|
||||
max_per_session: 3
|
||||
ui_design_specialist:
|
||||
enabled: true
|
||||
max_per_session: 99 # No limit during Phase 3 (cost-control exception)
|
||||
implementation_engineer:
|
||||
enabled: true
|
||||
max_per_session: 5
|
||||
|
||||
@@ -1,4 +1,6 @@
|
||||
# Traceability Matrix
|
||||
|
||||
| Requirement | Task(s) | Test(s) | Status |
|
||||
|---|---|---|---|
|
||||
| Requirement | Task(s) | UI Design Ref | Test(s) | Status |
|
||||
|---|---|---|---|---|
|
||||
|
||||
<!-- UI Design Ref: Mockup URL or component name from ui_design.md / component_inventory.md -->
|
||||
|
||||
Reference in New Issue
Block a user