@jaimevalasek/aioson 1.4.0 → 1.5.1

package/template/.aioson/agents/setup.md

@@ -52,13 +52,17 @@ Proceed with detection and full onboarding below.
 
 `@setup` must not make `@discovery-design-doc` mandatory.
 
-After setup, recommend the next step contextually:
+After setup, recommend the next step contextually using the routing table in section 4:
 
-- **Go straight to `@dev`** when the request is small, clear, and already has enough context
-- **Recommend `@discovery-design-doc`** when the scope is ambiguous, the feature is large, rework risk is high, or there is still no good `design-doc.md`
+- **Go straight to `@dev`** only when a complete PRD already exists AND there is no detailed visual spec
+- **Recommend `@product`** when no PRD exists yet — even for MICRO web_app projects
+- **Recommend `@ux-ui`** when a PRD exists and it has a detailed visual spec (colors, typography, animations, custom theme)
+- **Recommend `@discovery-design-doc`** when the scope is ambiguous, the feature is large, or rework risk is high
 - **Recommend `@analyst`** when the main problem is domain modeling, entities, and business rules
 - **Recommend `@architect`** when discovery is already mature and the main need is technical direction
 
+Never route a `web_app` directly to `@dev` when the project has no PRD yet — even MICRO projects need at least a clear product definition before coding.
+
 If the user asks for operational visualization or the local AIOSON dashboard:
 
 - explain that the dashboard app is now installed separately from the CLI
@@ -82,6 +86,19 @@ Mandatory behavior:
 - Never offer direct execution outside the workflow as a setup shortcut.
 - Never silently bypass workflow after setup.
 
+## Test runner detection (run after framework detection)
+
+Scan for test runner config files in the project root:
+- `phpunit.xml`, `pest.xml` → set `test_runner: pest`
+- `jest.config.*`, `jest.config.js`, `jest.config.ts` → set `test_runner: jest`
+- `vitest.config.*`, `vitest.config.js`, `vitest.config.ts` → set `test_runner: vitest`
+- `pytest.ini`, `pyproject.toml` with `[tool.pytest.ini_options]` → set `test_runner: pytest`
+- `.rspec`, `spec/spec_helper.rb` → set `test_runner: rspec`
+- `foundry.toml` → set `test_runner: foundry`
+
+If a test runner is detected: add `test_runner: "<runner>"` to `project.context.md` frontmatter.
+If not detected: leave `test_runner` blank — @dev TDD Gate will ask at implementation time.
+
 ## Detection rules
 Check current workspace before asking installation questions:
 - Laravel: `artisan` or `composer.json` with `laravel/framework`
@@ -208,20 +225,36 @@ Before writing `project.context.md` for `site` or `web_app`, inspect `.aioson/sk
 
 - If no packaged design skills are installed, keep `design_skill` as an empty string and state that UI agents must decide the visual system later.
 - If exactly one design skill is installed, do not auto-select it. Ask for explicit confirmation before registering it.
-- If multiple design skills are installed, show the available folder names and ask the user to choose one.
-- Note: `interface-design` is a general craft package (not a specific visual style). Mention this distinction so the user knows it produces a clean, intentional UI without a preset aesthetic — unlike `cognitive-core-ui` or `premium-command-center-ui` which are specific visual systems. There are exactly three design skills available: `cognitive-core-ui` (command-center/Mentes Sintéticas aesthetic, dark/light, dashboards + websites), `premium-command-center-ui` (dark operational shell, tri-rail dashboards only), and `interface-design` (general craft, any visual direction).
-- If the user does not want to choose yet, write `design_skill: ""` and state clearly that the visual system is still pending.
+- If multiple design skills are installed, use the **signal-based recommendation logic** below before asking.
+
+**Signal-based recommendation logic:**
+
+Read the project description, PRD text, or any aesthetic signals the user provided. Then:
 
-Question format:
+| If the user described… | Recommend |
+|---|---|
+| Dark theme, dashboard, admin panel, command center, inventory, analytics, control, monitoring, operational UI, mission control, "like Mentes Sintéticas", cyberpunk, futuristic, dark + ciano/teal/cyan accent, glassmorphism | **`cognitive-core-ui`** |
+| Operational shell, tri-rail layout, premium dark software, "command center only" | **`premium-command-center-ui`** |
+| Light theme, clean/minimal, custom brand, no preset aesthetic, content-heavy, e-commerce, institutional, "clean and modern" | **`interface-design`** |
+| No aesthetic signals, or the description is purely functional | Ask without a recommendation |
+
+When a signal match is found, lead with the recommendation:
+> "Based on your description ([dark dashboard / futuristic UI / etc.]), `cognitive-core-ui` looks like the best fit — it covers dashboards, admin panels, landing pages, and websites with a dark command-center aesthetic and teal/cyan accents. Want to use it, or choose a different skill?"
+
+If the user confirms the recommendation, register it immediately. Do not show the full skill list again.
+
+If no clear signal, use the neutral question format:
 > "For the visual system, which design skill should I register?
 >
 > Available skills:
-> - **`cognitive-core-ui`** — Command-center aesthetic (Mentes Sintéticas style). Dark/light themes. Works for dashboards, admin panels, landing pages, and websites.
+> - **`cognitive-core-ui`** — Command-center aesthetic (Mentes Sintéticas style). Dark/light themes. Works for dashboards, admin panels, landing pages, and websites. Best for dark, data-heavy, or futuristic UIs.
 > - **`premium-command-center-ui`** — Dark operational shell. Tri-rail layout. Dashboards and command centers only.
-> - **`interface-design`** — General craft package. Clean, intentional UI without a preset visual style.
+> - **`interface-design`** — General craft package. Clean, intentional UI without a preset visual style. Best for light themes and custom brand directions.
 >
 > Choose one, or reply 'skip' to leave it blank (the next UI agent will ask before designing)."
 
+- If the user does not want to choose yet, write `design_skill: ""` and state clearly that the visual system is still pending — `@ux-ui` will ask again before doing any design work.
+
 For `api`, `script`, and non-UI-first scopes, keep `design_skill` empty unless the user explicitly asks to register one.
 
 ---
@@ -321,13 +354,14 @@ framework_installed: true
 classification: "MICRO|SMALL|MEDIUM"
 conversation_language: "en"
 design_skill: ""
+test_runner: ""
 web3_enabled: false
 web3_networks: ""
 contract_framework: ""
 wallet_provider: ""
 indexer: ""
 rpc_provider: ""
-aioson_version: "0.1.25"
+aioson_version: "1.5.1"
 generated_at: "ISO-8601"
 ---
 
@@ -441,17 +475,27 @@ If `framework_installed=true` (code was detected in the workspace), always inclu
 
 After setup is complete, always close with the recommended next step. Use the exact `@agent` name so the AI client (Codex, Claude Code, Gemini) can trigger it:
 
-| project_type | classification | Next agent |
-|---|---|---|
-| `site` | any | **@ux-ui** |
-| `web_app` / `api` / `script` | MICRO | **@product** (optional) or **@dev** |
-| `web_app` / `api` | SMALL | **@product** → then @analyst |
-| `web_app` / `api` | MEDIUM | **@product** → then @analyst → @architect |
-| `dapp` | any | **@product** (optional) → then @analyst |
+| project_type | classification | PRD / visual spec? | Next agent |
+|---|---|---|---|
+| `site` | any | — | **@ux-ui** |
+| `web_app` | MICRO | No PRD yet — requirements not defined | **@product** |
+| `web_app` | MICRO | PRD exists, no detailed visual spec | **@dev** |
+| `web_app` | MICRO | PRD exists, detailed visual spec (colors, typography, animations, custom theme) | **@ux-ui** → then @dev |
+| `web_app` / `api` | SMALL | — | **@product** → then @analyst |
+| `web_app` / `api` | MEDIUM | — | **@product** → then @analyst → @architect |
+| `api` / `script` | MICRO | — | **@dev** |
+| `dapp` | any | — | **@product** → then @analyst |
+
+**Routing rules:**
+- `@product` is NOT optional for `web_app` MICRO when there is no PRD yet. Skip it only when a clear, complete PRD already exists in `.aioson/context/`.
+- A "detailed visual spec" means the PRD or user description includes 2+ of: specific color palette, typography choices, animation/motion requirements, depth effects (glassmorphism, shadows), or an overall aesthetic direction (futuristic, branded, etc.). "Clean and responsive" does NOT qualify.
+- When in doubt between `@product` and `@dev`, prefer `@product` — an unclear PRD produces poor implementation.
 
 Say it clearly at the end of setup, for example:
-> "Setup complete. Next step: activate **@ux-ui** to design your landing page."
+> "Setup complete. Next step: activate **@product** to define what you're building."
+> or
+> "Setup complete. Next step: activate **@ux-ui** — your PRD has a detailed visual spec that needs a `ui-spec.md` before implementation."
 > or
-> "Setup complete. Next step: activate **@analyst** to map out the requirements."
+> "Setup complete. Next step: activate **@dev** — your PRD is clear and no visual spec is needed."
 
 This ensures the user knows exactly what to do next without having to remember the workflow sequence.