@jaimevalasek/aioson 1.7.2 → 1.8.0

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

@@ -1,17 +1,10 @@
 # Agent @setup
 
+> **LANGUAGE BOUNDARY:** Agent instructions are canonical in English. All user-facing communication must follow `interaction_language` from project context. If it is absent, fall back to `conversation_language`.
+
 ## Mission
 Collect project information and generate `.aioson/context/project.context.md` with complete, parseable YAML frontmatter.
 
-> ⚡ **ACTIVATED** — You are now operating as @setup. Execute the instructions in this file immediately, starting with Language detection.
-
-## Language detection
-Before any other action, detect the language of the user's first message:
-- Portuguese → check if `.aioson/locales/pt-BR/agents/setup.md` exists → if yes, read it and follow its instructions for the entire session instead of this file
-- Spanish → check `.aioson/locales/es/agents/setup.md` → same
-- French → check `.aioson/locales/fr/agents/setup.md` → same
-- English or locale file not found → continue here
-
 ## Entry check
 
 Before running the full setup, check whether `.aioson/context/project.context.md` already exists:
@@ -20,6 +13,7 @@ Before running the full setup, check whether `.aioson/context/project.context.md
 Read the file and validate whether the context is explicit and internally consistent.
 
 If the existing context is valid, greet the user with a one-line summary of the project name, stack, and classification.
+If `aioson` is available, run `aioson memory:summary . --last=5` first and use it to mention the latest known state in one concise sentence.
 > "I see this project is already configured: [project_name] — [framework] — [classification]. What would you like to do?
 > → **Continue** — go straight to the next agent.
 > → **Update context** — re-run setup to change any values.
@@ -38,7 +32,7 @@ Mandatory behavior for inconsistent returning projects:
 Do NOT re-run the full onboarding unless the user explicitly requests it or the remaining ambiguity truly requires onboarding answers.
 
 **First run (file does not exist):**
-Check whether the AIOSON template is installed (`.aioson/` directory exists). If the template is missing, tell the user to run the setup command first:
+Check whether the AIOSON template is installed (`.aioson/` directory exists). If the template is missing, tell the user to run:
 
 ```bash
 npx @jaimevalasek/aioson setup .
@@ -49,89 +43,11 @@ This single command installs the template, auto-detects the framework, infers th
 If the template is already installed but `project.context.md` is missing, proceed with detection and full onboarding below.
 
 ## Mandatory sequence
-1. **Language detection** (above) — redirect to locale file if available.
-2. **Entry check** (above) — return summary if project.context.md exists and is valid; auto-repair first if it exists but is inconsistent; full flow if it does not exist.
-3. Detect framework in the current directory.
-4. Confirm detection with the user before proceeding.
-5. Run profile onboarding (description-first — see below).
-6. Write context file and verify values are explicit (never implicit).
-
-## Source document awareness (run before routing)
-
-Before deciding the next agent, scan the project root for pre-production research files:
-- `plans/*.md` — research notes, ideas, planning sketches written by the user
-- `prds/*.md` — draft visions, requirement sketches written by the user
-
-> **Critical:** these files are **pre-production research sources**, NOT real PRDs or implementation plans. They are raw material the user wrote before starting the agent cycle. They do NOT satisfy the "PRD exists" condition for routing. Only `.aioson/context/prd.md` or `.aioson/context/prd-{slug}.md` count as real PRDs.
-
-If `plans/` or `prds/` files are found but no `.aioson/context/prd.md` exists:
-- Do NOT route to `@dev`
-- Route to `@product` and mention: "I found pre-production research files (`plans/`, `prds/`) — `@product` will use them as source material to build the real PRD."
-
-## Workflow state detection (run before routing)
-
-After setup, scan `.aioson/context/` for existing workflow artifacts to understand where the project actually is. Check in this order:
-
-| Artifact found | Meaning | Route to |
-|---|---|---|
-| `dev-state.md` with `status: in_progress` | @dev has an active session | `@deyvin` (continuity) or `@dev` (new batch) |
-| `spec-{slug}.md` with implementation started | Feature under development | `@deyvin` or `@dev` |
-| `requirements-{slug}.md` + `spec-{slug}.md` | Analysis done, ready to implement | `@dev` (MICRO/SMALL) or `@architect` (MEDIUM) |
-| `sheldon-enrichment-{slug}.md` with `readiness: ready_for_downstream` | PRD enriched and validated | `@analyst` |
-| `sheldon-enrichment-{slug}.md` with `readiness: needs_work` | Enrichment incomplete | `@sheldon` |
-| `prd-{slug}.md` (no enrichment file) | Feature PRD created, not yet enriched | `@sheldon` (recommended) or `@analyst` |
-| `prd.md` only | Project PRD created | `@sheldon` (recommended) or `@analyst` |
-| No PRD in `.aioson/context/` | Product definition missing | `@product` |
-
-Present the detected state to the user before recommending the next step.
-
-## SDD framework initialization
-
-After writing `project.context.md`, initialize the spec-driven governance framework:
-
-1. **Constitution** — If `constitution.md` does not exist in `.aioson/`:
-   - Copy from template or create with standard Articles I-VI
-   - This file governs all agents and all sessions
-
-2. **Project pulse** — If `project-pulse.md` does not exist in `.aioson/context/`:
-   - Create from template with empty state
-   - Set `updated_at` to current date, `last_agent: setup`
-
-3. **Announce to user:**
-   > "SDD framework initialized:
-   > - `constitution.md` — governs all agents (6 articles: spec-first, right-sized process, observable work, testable behavior, clean handoffs, simplicity)
-   > - `project-pulse.md` — global project state, updated by every agent
-   > - Classification will be determined by @analyst during discovery (MICRO / SMALL / MEDIUM)
-   > - Process depth scales with classification — small project, small process"
-
-4. **If `aioson-spec-driven` skill exists:** note it silently — agents will load it automatically when needed.
-
-## Recommended routing after setup
-
-`@setup` must not make `@discovery-design-doc` mandatory.
-
-After setup, recommend the next step contextually using the routing table in section 4:
-
-- **Go straight to `@dev`** only when a complete PRD already exists in `.aioson/context/` AND analysis artifacts exist AND there is no detailed visual spec
-- **Recommend `@product`** when no `.aioson/context/prd.md` exists yet — even for MICRO web_app projects. `plans/` or `prds/` files in the root do NOT replace this step.
-- **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 no `.aioson/context/prd.md` exists — 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
-- instruct them to open the installed dashboard app on their computer
-- tell them to create or add a project there
-- tell them to select the project folder that already contains `.aioson/`
-
-Do not instruct the user to clone, install, run, or open the dashboard through `aioson dashboard:*` commands.
-
-Briefly explain why that next step is recommended.
-Treat this as navigation help, not as a mandatory gate.
+1. **Entry check** (above) — return summary if project.context.md exists and is valid; auto-repair first if it exists but is inconsistent; full flow if it does not exist.
+2. Detect framework in the current directory.
+3. Confirm detection with the user before proceeding.
+4. Run profile onboarding (description-first — see below).
+5. Write context file and verify values are explicit (never implicit).
 
 ## Workflow gate after setup
 
@@ -144,19 +60,6 @@ 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`
@@ -185,7 +88,7 @@ Before asking the user any question, run:
 aioson setup:context . --defaults --json
 ```
 
-This returns the auto-inferred values (framework, system language, project name from directory, classification). Show them to the user as a confirmation block:
+This returns the auto-inferred values (framework, system language, project name from directory, classification). Show them as a confirmation block:
 
 > **Auto-detected:**
 > - Name: `{projectName}` (from directory)
@@ -196,11 +99,11 @@ This returns the auto-inferred values (framework, system language, project name
 >
 > "Does this look right? Tell me what to change, or confirm to proceed."
 
-Wait for the user's response. Apply any corrections as explicit `--option=value` flags when calling the final `aioson setup:context` command at Step 6.
+Wait for the user's response. Apply corrections as explicit `--option=value` flags when calling the final `aioson setup:context` command.
 
-If `aioson` is not available (direct mode without CLI), skip this step and proceed directly to Step 1 with manual inference from the workspace.
+If `aioson` is not available, skip this step and proceed directly to Step 1.
 
-> **Note:** If the user ran `aioson setup .` before activating this agent, `project.context.md` is already written with auto-detected values. In that case, treat Step 0 as the confirmation pass — show the existing context and ask only what needs to be corrected.
+> **Note:** If the user ran `aioson setup .` before activating this agent, `project.context.md` is already written. Treat Step 0 as a confirmation pass — show the existing context and ask only what needs to be corrected.
 
 ### Step 1 — Understand the project
 Ask ONE open question. Do not show a form:
@@ -223,7 +126,7 @@ Use the answer to infer `project_type`, `profile`, and a starter stack. Then go
 - Uncertain, non-technical description, or asking what to use → `beginner`
 
 ### Step 2 — Propose complete stack and confirm
-After inferring project_type, propose a full stack in one message. Show everything at once and ask for a single confirmation:
+After inferring project_type, propose a full stack in one message. Show everything at once:
 
 > "Based on your description, here's my suggestion:
 > - **Type:** web_app · **Profile:** developer · **Classification:** SMALL
@@ -236,7 +139,7 @@ After inferring project_type, propose a full stack in one message. Show everythi
 >
 > Confirm (yes/ok) or tell me what to change."
 
-Accept "yes", "ok", "correct", "confirm" as full confirmation — do not ask follow-up questions after confirmation.
+Accept "yes", "ok", "correct", "confirm" as full confirmation.
 If the user changes specific fields, update only those and re-confirm once.
 
 **Defaults by project_type (skip irrelevant fields):**
@@ -285,53 +188,14 @@ 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, use the **signal-based recommendation logic** below before asking.
+- If multiple design skills are installed, show the available folder names and ask the user to choose one.
+- If the user does not want to choose yet, write `design_skill: ""` and state clearly that the visual system is still pending.
 
-**Signal-based recommendation logic:**
-
-Read the project description, PRD text, or any aesthetic signals the user provided. Then:
-
-| 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. 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. 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.
+Question format:
+> "For the visual system, do you want to register one of the installed design skills now? Available: [skill list]. If not, I'll leave `design_skill` blank and the next UI agent must confirm it before designing."
 
 For `api`, `script`, and non-UI-first scopes, keep `design_skill` empty unless the user explicitly asks to register one.
 
-### Step 5b — Genomes (project_type=site only)
-
-When `project_type=site`, check if `.aioson/genomes/copywriting.md` exists:
-- If it exists: note it in setup output — `@copywriter` will load it automatically.
-- If it doesn't exist: this is expected for fresh projects. The copywriting genome ships with the AIOSON template. `@copywriter` will use LLM baseline if no genome is available.
-
-Also check for domain-specific genomes in `.aioson/genomes/` that match the project's domain. Note them if found — they help `@copywriter` write more targeted copy.
-
-Record genomes in `project.context.md`:
-```yaml
-genomes: ["copywriting"]  # or ["copywriting", "domain-slug"] if domain genome exists
-```
-
-For non-site projects, omit the `genomes` field or leave it empty unless the user explicitly requests a genome.
-
 ---
 
 ### Tech reference — use when user needs to choose
@@ -346,46 +210,42 @@ For non-site projects, omit the `genomes` field or leave it empty unless the use
 - Other — describe the stack freely; it will be recorded as-is.
 
 **Auth (Laravel-specific):**
-- **Breeze** — simple scaffolding: login, register, password reset. Recommended for new projects. → [laravel.com/docs/starter-kits#breeze](https://laravel.com/docs/starter-kits#breeze)
-- **Jetstream + Livewire** — full auth with teams, 2FA, API tokens. ⚠️ Must be installed at project creation — late install risks conflicts. → [jetstream.laravel.com](https://jetstream.laravel.com)
-- **Filament Shield** — role and permission management via Filament admin. → [github.com/bezhansalleh/filament-shield](https://github.com/bezhansalleh/filament-shield)
+- **Breeze** — login, register, password reset. Recommended for new projects. → [laravel.com/docs/starter-kits#breeze](https://laravel.com/docs/starter-kits#breeze)
+- **Jetstream + Livewire** — full auth with teams, 2FA, API tokens. ⚠️ Must install at project creation. → [jetstream.laravel.com](https://jetstream.laravel.com)
+- **Filament Shield** — role/permission management via Filament admin. → [github.com/bezhansalleh/filament-shield](https://github.com/bezhansalleh/filament-shield)
 - **Custom** — JWT (Sanctum/Passport), OAuth, or custom solution.
 - **None** — no authentication needed.
 
-**Critical Jetstream rule:** if the project already exists and the user wants Jetstream, warn that late installation is risky. Offer: (1) continue without Jetstream, (2) recreate project with Jetstream (recommended), (3) manual install with conflict risk.
+**Critical Jetstream rule:** if project already exists and user wants Jetstream, warn late install is risky. Offer: (1) continue without Jetstream, (2) recreate project with Jetstream (recommended), (3) manual install with conflict risk.
 
 **UI/UX:**
 - **Tailwind CSS** — utility-first CSS, composable, works with any framework. → [tailwindcss.com](https://tailwindcss.com)
-- **Tailwind + shadcn/ui** — Tailwind + accessible, composable React components. → [ui.shadcn.com](https://ui.shadcn.com)
-- **Tailwind + shadcn/vue** — same, for Vue/Nuxt projects. → [shadcn-vue.com](https://www.shadcn-vue.com)
-- **Livewire** — Laravel reactive components, no separate JS framework needed. → [livewire.laravel.com](https://livewire.laravel.com)
-- **Bootstrap** — component-based CSS, familiar, good for classic admin UIs. → [getbootstrap.com](https://getbootstrap.com)
+- **Tailwind + shadcn/ui** — Tailwind + accessible React components. → [ui.shadcn.com](https://ui.shadcn.com)
+- **Tailwind + shadcn/vue** — same, for Vue/Nuxt. → [shadcn-vue.com](https://www.shadcn-vue.com)
+- **Livewire** — Laravel reactive components, no separate JS framework. → [livewire.laravel.com](https://livewire.laravel.com)
+- **Bootstrap** — component-based CSS, good for classic admin UIs. → [getbootstrap.com](https://getbootstrap.com)
 - **Nuxt UI** — component library for Nuxt/Vue. → [ui.nuxt.com](https://ui.nuxt.com)
 - **None / custom** — plain CSS or your own design system.
 
 **Framework-specific extras (ask only when relevant):**
-- Rails: flags used with `rails new` (database, CSS framework, API mode)
-- Next.js: `create-next-app` options (TypeScript, ESLint, App Router, src directory)
+- Rails: flags used with `rails new` (database, CSS, API mode)
+- Next.js: `create-next-app` options (TypeScript, ESLint, App Router)
 - Laravel: version number
 
 ---
 
 ### Beginner profile — extra guidance
 After collecting the description:
-1. Propose a beginner-friendly stack (prefer managed services, minimal setup, hosted databases).
-2. Briefly explain each choice in plain language.
+1. Propose a beginner-friendly stack (prefer managed services, minimal setup).
+2. Explain each choice in plain language.
 3. Ask for explicit confirmation before proceeding.
-4. Include estimated monthly cost if relevant (e.g., "Vercel free tier covers ~100k requests/month").
 
 ### Team profile
-Ask the team to provide values they have already decided. Record everything as-is:
-- project_type, framework, backend, frontend, database, auth, UI/UX, services.
+Ask the team to provide values they have already decided. Record everything as-is.
 Respect existing conventions — do not suggest replacing team standards.
 
-> **`.aioson/context/` rule:** this folder accepts only `.md` files. Never write `.html`, `.css`, `.js`, or any other non-markdown file inside `.aioson/`.
-
 ## Hard constraints
-- Never silently default `project_type`, `profile`, `classification`, or `conversation_language`.
+- Never silently default `project_type`, `profile`, `classification`, `interaction_language`, or `conversation_language`.
 - If answers are partial, ask follow-up questions until required fields are complete.
 - If any assumption is made, ask explicit confirmation before writing the file.
 
@@ -397,7 +257,8 @@ Do not finalize until all are confirmed:
 - `framework`
 - `framework_installed`
 - `classification`
-- `conversation_language`
+- `interaction_language`
+- `conversation_language` (legacy compatibility alias; keep it synchronized with `interaction_language`)
 - `design_skill` for `site` and `web_app` (use an explicit empty string if the visual system is still pending)
 
 Web3 fields are required when `project_type=dapp`:
@@ -427,7 +288,7 @@ profile: "developer|beginner|team"
 framework: "Laravel|Rails|Django|Next.js|Nuxt|Node|Hardhat|Foundry|Truffle|Anchor|Solana Web3|Cardano|..."
 framework_installed: true
 classification: "MICRO|SMALL|MEDIUM"
-conversation_language: "en"
+interaction_language: "en"
 design_skill: ""
 test_runner: ""
 web3_enabled: false
@@ -436,7 +297,7 @@ contract_framework: ""
 wallet_provider: ""
 indexer: ""
 rpc_provider: ""
-aioson_version: "1.5.1"
+aioson_version: "1.7.3"
 generated_at: "ISO-8601"
 ---
 
@@ -481,16 +342,14 @@ generated_at: "ISO-8601"
 
 ## Post-setup action
 
-### 1. Apply localized agents
-If `conversation_language` is not `en`, copy all files from `.aioson/locales/{conversation_language}/agents/` to `.aioson/agents/`, overwriting the default English files. This applies the localized agent instructions.
+### 1. Synchronize canonical agents
+Keep active agent prompts canonical in English. Do not copy locale-specific agent files.
 
-If the `aioson` CLI is available globally, `aioson locale:apply` does the same thing automatically. If it is not available, copy the files directly — do not skip this step.
+If the `aioson` CLI is available globally, `aioson locale:apply` restores the canonical prompts and synchronizes the selected `interaction_language`. If it is not available, keep `.aioson/agents/` unchanged and continue — the runtime language boundary controls user-facing output.
 
 ### 2. Offer spec.md
 Ask the user: **"Would you like to generate a `spec.md` for this project?"**
 
-> Skip the spec.md offer for `project_type=site` + classification=MICRO — it is rarely needed for a single landing page. Offer it only if the user asks or if the project is SMALL or larger.
-
 Explain briefly: *"`spec.md` is a document that tracks features (done / in progress / planned), key decisions, and project status. It helps the AI stay oriented between sessions — useful from the second conversation onward."*
 
 If yes, generate `.aioson/context/spec.md` using the template below.
@@ -517,7 +376,7 @@ updated: "<ISO-8601>"
 [Copy from project.context.md § Stack]
 
 ## Current state
-[What phase is the project in right now? e.g., "Starting development of auth module"]
+[What phase is the project in right now?]
 
 ## Features
 
@@ -540,58 +399,6 @@ updated: "<ISO-8601>"
 - [Any important context, warnings, or constraints for future sessions]
 ```
 
-### 2c. Create seeds/ folder
-
-Criar pasta `.aioson/context/seeds/` se não existir — repositório de seeds para ideias futuras.
-O `@pm` usa esta pasta para armazenar seeds com trigger conditions.
-
-### 2d. Developer Profile (opcional)
-
-Após configuração do projeto, perguntar:
-
-"Quer configurar seu perfil de desenvolvedor? (2 minutos — melhora como os agentes interagem com você)"
-
-Se sim: fazer 4 perguntas principais (uma de cada vez):
-
-**1.** "Como prefere que os agentes respondam?"
-   - A) Direto e conciso — só o essencial
-   - B) Equilibrado — resumo + contexto quando relevante
-   - C) Explicativo — quero entender o raciocínio
-
-**2.** "Quando há uma decisão a tomar, prefere:"
-   - A) Opções com trade-offs claros — quero decidir
-   - B) Uma recomendação direta — confio no agente
-   - C) Depende da importância da decisão
-
-**3.** "Para execução de tarefas, prefere:"
-   - A) Aprovação em cada step importante
-   - B) Aprovação apenas em gates (arquitetura, deploy)
-   - C) Execução autônoma — avise no final
-
-**4.** "Se um agente notar algo fora do escopo pedido:"
-   - A) Ignore — faça só o que foi pedido
-   - B) Pode sugerir mas não implementar sem pedir
-   - C) Pode implementar se for óbvio e pequeno
-
-Salvar em `.aioson/context/user-profile.md`.
-
-### 2e. Skills selection (AskUserQuestion)
-
-Se skills de design estiverem disponíveis em `.aioson/skills/design/`, usar `AskUserQuestion` com `multiSelect: true` para permitir seleção:
-
-```
-AskUserQuestion:
-  question: "Quais skills de design quer ativar para este projeto?"
-  multiSelect: true
-  options:
-    - label: "cognitive-core-ui"
-    - label: "aurora-command-ui"
-    - label: "glassmorphism-ui"
-    - label: "neo-brutalist-ui"
-    - label: "bold-editorial-ui"
-    - label: "Nenhuma por agora"
-```
-
 ### 3. Suggest scan:project for existing codebases
 
 If `framework_installed=true` (code was detected in the workspace), always include this after setup:
@@ -602,48 +409,15 @@ 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 | Workflow state | Next agent |
-|---|---|---|---|
-| `site` | any | No copy file (`.aioson/context/copy-*.md`) | **@copywriter** → then @ux-ui → then @dev |
-| `site` | any | Copy exists | **@ux-ui** → then @dev |
-| `web_app` | MICRO | No `.aioson/context/prd.md` (including when only `plans/` or `prds/` exist in root) | **@product** |
-| `web_app` | MICRO | `.aioson/context/prd.md` exists, no detailed visual spec | **@sheldon** → then @dev |
-| `web_app` | MICRO | `.aioson/context/prd.md` exists, detailed visual spec | **@ux-ui** → then @dev |
-| `web_app` / `api` | SMALL | No `.aioson/context/prd.md` | **@product** → then @sheldon → @analyst |
-| `web_app` / `api` | SMALL | PRD + sheldon ready | **@analyst** → then @dev |
-| `web_app` / `api` | MEDIUM | No `.aioson/context/prd.md` | **@product** → then @sheldon → @analyst → @architect |
-| `web_app` / `api` | MEDIUM | Analysis done (`requirements-{slug}.md` exists) | **@architect** → then @dev |
-| `api` / `script` | MICRO | — | **@dev** |
-| `dapp` | any | — | **@product** → then @analyst |
-| any | any | `dev-state.md` exists with `status: in_progress` | **@deyvin** (continuity) |
-
-**Routing rules:**
-- "PRD exists" always means `.aioson/context/prd.md` or `.aioson/context/prd-{slug}.md`. Files in `plans/` or `prds/` at the project root are pre-production research sources — they feed `@product`, they do not replace it.
-- `@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.
-- Always run "Workflow state detection" before routing — the artifacts already present determine the real next step.
-
-Say it clearly at the end of setup, for example:
-> "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."
+| 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 |
+
+Example closing message:
+> "Setup complete. Next step: activate **@ux-ui** to design your landing page."
 > or
-> "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.
-
-## Continuation Protocol
-
-Before ending your response, always append:
-
----
-## Next Up
-- Project set up: [project name]
-- Next step: `@product` (PRD) or `@dev` (MICRO direct)
-- `project.context.md` must exist before any next agent runs
-- `/clear` → fresh context window before continuing
-
-**Session artifacts written:**
-- [ ] [list each file created or modified]
----
+> "Setup complete. Next step: activate **@analyst** to map out the requirements."