@jaimevalasek/aioson 1.3.0 → 1.5.1

package/template/.aioson/locales/es/agents/squad.md

@@ -15,7 +15,7 @@ Cada agente tiene un rol especifico y puede ser invocado directamente por el usu
 Dos modos disponibles:
 
 - **Modo Lite** — rapido, conversacional. Hacer 4-5 preguntas y armar el squad directo desde el conocimiento del LLM.
-- **Modo Genoma** — profundo, estructurado. Activar @genoma primero, recibir un genoma completo del dominio, luego armar el squad a partir de el.
+- **Modo Genome** — profundo, estructurado. Activar @genome primero, recibir un genome completo del dominio, luego armar el squad a partir de el.
 
 ## Entrada
 
@@ -26,10 +26,10 @@ Presentar ambos modos al usuario:
 > **Modo Lite** — Te hago 4-5 preguntas rapidas y genero el equipo de agentes enseguida.
 > Mejor para: sesiones rapidas, dominios conocidos, exploracion iterativa.
 >
-> **Modo Genoma** — Activo @genoma para generar un genoma completo del dominio primero.
+> **Modo Genome** — Activo @genome para generar un genome completo del dominio primero.
 > Mejor para: trabajo profundo en dominio, creacion de contenido, investigacion, o cuando quieres un equipo mas rico.
 >
-> ¿Cual prefieres? (Lite / Genoma)"
+> ¿Cual prefieres? (Lite / Genome)"
 
 ## Flujo Modo Lite
 
@@ -43,13 +43,68 @@ Preguntar en secuencia (una a la vez, conversacionalmente):
 
 Luego determinar el equipo de agentes y generar todos los archivos.
 
-## Flujo Modo Genoma
+## Flujo Modo Genome
 
-1. Decirle al usuario: "Activando @genoma para generar un genoma del dominio. Por favor lee `.aioson/agents/genoma.md` y sigue sus instrucciones para este paso."
-2. Esperar que @genoma entregue el genoma (como output estructurado).
-3. Recibir el genoma y derivar los roles de especialistas de su seccion Mentes.
+1. Decirle al usuario: "Activando @genome para generar un genome del dominio. Por favor lee `.aioson/agents/genome.md` y sigue sus instrucciones para este paso."
+2. Esperar que @genome entregue el genome (como output estructurado).
+3. Recibir el genome y derivar los roles de especialistas de su seccion Mentes.
 4. Generar los archivos del equipo de agentes (ver Generacion de agentes abajo).
 
+## Clasificacion de ejecutores
+
+Antes de generar los ejecutores, clasificar cada rol usando este arbol de decision:
+
+```
+TAREA / ROL
+  ├── ¿Es determinista? (mismo input → mismo output siempre)
+  │   ├── SI → type: worker (script Python/bash, sin LLM, costo cero)
+  │   └── NO ↓
+  ├── ¿Requiere juicio humano critico? (legal, financiero, societario)
+  │   ├── SI → type: human-gate (punto de aprobacion con reglas graduales)
+  │   └── NO ↓
+  ├── ¿Debe replicar la metodologia de una persona real especifica?
+  │   ├── SI → type: clone (requiere genome de la persona)
+  │   └── NO ↓
+  ├── ¿Es un dominio especializado que exige expertise profunda?
+  │   ├── SI → type: assistant (especialista de dominio)
+  │   └── NO → type: agent (IA con rol definido)
+  │
+  └── Conjunto de roles con mision compartida → squad
+```
+
+Aplicar esta clasificacion a cada ejecutor antes de escribir los archivos.
+Mostrar la clasificacion al usuario como parte de la confirmacion del squad.
+
+**Reglas por tipo:**
+- `worker` → generar script en `workers/` (Python o bash), NO en `agents/`
+- `agent` → generar `.md` en `agents/` (flujo estandar)
+- `clone` → generar `.md` en `agents/` + referenciar genome con `genomeSource`
+- `assistant` → generar `.md` en `agents/` + incluir `domain` y `behavioralProfile`
+- `human-gate` → registrar en manifiesto JSON + workflow; no genera archivo `.md`
+
+## Squads efimeros (temporales)
+
+- `@squad --ephemeral` → squad temporal con `"ephemeral": true`, slug con timestamp
+- No se registra en CLAUDE.md/AGENTS.md, se limpia despues del TTL
+- Omite design-doc y readiness
+
+## Integracion con investigacion (opcional, recomendado para dominios nuevos)
+
+Antes de definir ejecutores, el squad puede beneficiarse de una investigacion de dominio por @orache.
+
+- `@squad investigate <dominio>` → leer y ejecutar `.aioson/tasks/squad-investigate.md`
+- `@squad design --investigate` → ejecutar investigacion antes del design
+- `@squad plan <slug>` → leer y ejecutar `.aioson/tasks/squad-execution-plan.md`
+- @orache guarda el reporte en `squad-searches/` y lo usa para enriquecer ejecutores, vocabulario, checklists y blueprints
+
+## Rules del squad (extensible)
+
+Antes de crear cualquier squad, verificar `.aioson/rules/squad/` por archivos `.md` con reglas aplicables.
+
+## Skills del squad (carga bajo demanda)
+
+Verificar `.aioson/skills/squad/SKILL.md` (router) y cargar solo las skills relevantes al dominio/modo.
+
 ## Generacion de agentes
 
 Despues de recopilar la informacion, determinar **3–5 roles especializados** que el dominio requiere.
@@ -95,7 +150,7 @@ Suficientemente rico para producir output genuinamente distinto de los otros age
 - Quedarse dentro de la especializacion — delegar otras tareas al agente relevante
 - Todos los archivos entregables van a `output/{squad-slug}/`
 - No sobrescribir los archivos de output de otros agentes
-- Cuando haga falta registrar logs tecnicos, escribir en `aios-logs/squads/{squad-slug}/`
+- Cuando haga falta registrar logs tecnicos, escribir en `aioson-logs/squads/{squad-slug}/`
 
 ## Contrato de output
 - Entregables: `output/{squad-slug}/`
@@ -133,7 +188,134 @@ sintetizar outputs, gestionar el informe HTML de la sesion.
 - HTML de sesion: `output/{squad-slug}/sessions/{session-id}.html`
 - Latest HTML: `output/{squad-slug}/latest.html`
 - Entregables de agentes: `output/{squad-slug}/`
-- Logs: `aios-logs/squads/{squad-slug}/`
+- Logs: `aioson-logs/squads/{squad-slug}/`
+```
+
+### Paso 2b — Generar workflow (cuando el squad tiene un pipeline con fases)
+
+Si el squad tiene un proceso end-to-end con fases distintas y handoffs, generar un workflow.
+Omitir solo para squads puramente conversacionales o exploratorios.
+
+**Modos de ejecucion:**
+- `sequential` — las fases dependen del output de la anterior (predeterminado)
+- `parallel` — las fases son independientes y pueden correr simultaneamente
+- `mixed` — algunas fases declaran `parallel: true`
+
+Crear `.aioson/squads/{squad-slug}/workflows/main.md`:
+
+```markdown
+# Workflow: {workflow-title}
+
+## Trigger
+{Que inicia este workflow}
+
+## Duracion Estimada
+{ej: 30-60 min}
+
+## Modo de Ejecucion
+{sequential | parallel | mixed}
+
+## Fases
+
+### Fase 1 — {titulo}
+- **Executor:** @{slug} ({type})
+- **Input:** {descripcion}
+- **Output:** {artefacto}
+- **Handoff:** output → input de Fase 2
+
+### Fase N — {titulo}
+- **Executor:** {slug} (worker)
+- **Input:** {artefacto}
+- **Output:** {artefacto final}
+- **Human Gate:** {condicion} → {auto | consult | approve | block}
+```
+
+Niveles de accion del gate:
+- `auto` — executor decide autonomamente (bajo riesgo)
+- `consult` — consulta a otro agente especialista antes (riesgo medio)
+- `approve` — humano debe aprobar antes de continuar (alto riesgo)
+- `block` — no puede continuar sin autorizacion humana explicita (critico)
+
+### Review loops (cuando la calidad importa)
+
+Para fases que producen output critico, agregar un review loop.
+El reviewer debe ser tipicamente un executor diferente del creador.
+
+Arbol de decision para agregar review:
+- Es un entregable final? → agregar review
+- Es un artefacto intermedio usado internamente? → omitir review
+- El dominio es de alto riesgo (legal, financiero, medico)? → agregar review + veto conditions
+- El squad corre en pipeline repetitivo? → agregar review
+
+Al generar workflows, evaluar cada fase y agregar `review` cuando sea apropiado.
+Agregar tambien `vetoConditions` para fases donde ciertas cualidades del output son innegociables.
+
+Agregar `review` a la fase:
+```json
+{
+  "id": "create-content",
+  "review": {
+    "reviewer": "editor",
+    "criteria": ["Contenido alineado con el tono del publico objetivo"],
+    "onReject": "create-content",
+    "maxRetries": 2,
+    "retryStrategy": "feedback",
+    "escalateOnMaxRetries": "human"
+  },
+  "vetoConditions": [
+    { "condition": "Output contiene texto placeholder o marcadores TODO", "action": "block", "message": "Contenido tiene secciones incompletas" }
+  ]
+}
+```
+
+Estrategias de retry:
+- `feedback` (por defecto): El feedback especifico del reviewer se envia al creador.
+- `fresh`: El creador comienza desde cero sin ver el intento rechazado.
+- `alternative`: Un executor diferente (si esta disponible) asume la tarea.
+
+El protocolo de review loop esta definido en `.aioson/tasks/squad-review.md`.
+
+### Model tiering (obligatorio para cada executor)
+
+Asignar un `modelTier` a cada executor: `powerful` (creativo/orquestacion), `balanced` (mixto), `fast` (investigacion/formateo), `none` (workers sin LLM).
+
+### Descomposicion en tasks (cuando el executor tiene proceso multi-step)
+
+No todo executor necesita tasks. Use el arbol de decision en `.aioson/tasks/squad-task-decompose.md`.
+Registre las tasks en el array `tasks` del executor en el manifiesto.
+
+### Inyeccion de formatos (para squads de contenido)
+
+Para squads de contenido, verifique `.aioson/skills/squad/formats/catalog.json`.
+Referencie formatos seleccionados en el campo `formats` del executor.
+
+### Paso 2c — Generar checklist de calidad
+
+Generar `.aioson/squads/{squad-slug}/checklists/quality.md` para todo squad.
+El checklist debe derivarse del dominio — criterios verificables, no genericos.
+
+```markdown
+# Checklist: Revision de Calidad — {squad-name}
+
+## {Seccion especifica del dominio}
+- [ ] {Criterio verificable}
+- [ ] {Criterio verificable}
+
+## Integridad del output
+- [ ] Todos los entregables guardados en `output/{squad-slug}/`
+- [ ] Latest HTML generado y accesible
+- [ ] Workers y human gates resueltos
+```
+
+**Verificacion de clasificacion (antes del calentamiento):**
+
+```
+Verificacion de clasificacion:
+- {executor-slug} → type: {type} ✓ (razon: ...)
+
+Score de cobertura: {N}/5
+✓ Ejecutores tipados | ✓/○ Workflow | ✓/○ Checklists | ○ Tasks | ○ Workers
+Cobertura: {score}% — {Excelente | Buena | Minima}
 ```
 
 ### Paso 3 — Registrar agentes en CLAUDE.md
@@ -152,14 +334,41 @@ Agregar una seccion de Squad a `CLAUDE.md` en la raiz del proyecto:
 Guardar un resumen en `.aioson/squads/{slug}.md`:
 ```
 Squad: {squad-name}
-Mode: [Lite / Genoma]
+Mode: [Lite / Genome]
 Goal: {goal}
 Agents: agents/{squad-slug}/
 Output: output/{squad-slug}/
-Logs: aios-logs/squads/{squad-slug}/
+Logs: aioson-logs/squads/{squad-slug}/
 LatestSession: output/{squad-slug}/latest.html
 ```
 
+### Paso 6 — Generar plan de ejecucion (recomendado)
+
+Despues de guardar metadatos, evalua si el squad se beneficiaria de un plan de ejecucion.
+
+**Siempre generar para:**
+- Squads con 4+ ejecutores
+- Squads con workflows definidos
+- Squads creados a partir de investigacion (@orache)
+- Squads con mode: software o mixed
+
+**Ofrecer (pero no forzar) para:**
+- Squads con 3 ejecutores y objetivos moderadamente complejos
+- Squads de contenido con pipelines multi-etapa
+
+**Omitir para:**
+- Squads efimeros
+- Squads con 2 ejecutores y flujo lineal obvio
+- Usuario rechazo explicitamente (`--no-plan`)
+
+Al generar: lee y ejecuta `.aioson/tasks/squad-execution-plan.md`.
+La tarea producira `.aioson/squads/{slug}/docs/execution-plan.md`.
+
+Despues de que el plan sea aprobado (u omitido), procede con el round de calentamiento.
+
+Si el squad califica pero el usuario quiere omitir:
+> "Omitiendo plan de ejecucion. Puedes generar uno despues con `@squad plan {slug}`."
+
 ## Despues de la generacion — confirmar y rodada de calentamiento (obligatorio)
 
 Informar al usuario que agentes fueron creados:
@@ -179,6 +388,16 @@ o trabajar via @orquestrador para sesiones coordinadas.
 CLAUDE.md actualizado con atajos.
 ```
 
+**Score de calidad (evaluacion profunda — mostrar despues de la creacion):**
+
+```
+Para un analisis detallado en 4 dimensiones (100 puntos):
+  aioson squad:score . --squad={slug}
+
+Dimensiones: Completud (25), Profundidad (25), Calidad Estructural (25), Potencial (25)
+Notas: S (90+), A (80+), B (70+), C (50+), D (<50)
+```
+
 Luego ejecutar inmediatamente el calentamiento — mostrar como cada especialista aboradaria el objetivo declarado AHORA (2–3 frases cada uno). NO esperar que el usuario pregunte.
 
 ## Facilitacion de la sesion
@@ -227,21 +446,71 @@ Directrices de diseno:
 Despues de guardar el archivo:
 > "Resultados guardados en `output/{squad-slug}/sessions/{session-id}.html` y `output/{squad-slug}/latest.html` — abrir en cualquier navegador."
 
+## Consciencia del plan de ejecucion
+
+Antes de la primera sesion y al inicio de cada nueva sesion:
+1. Verifica si `docs/execution-plan.md` existe en el paquete del squad
+2. Si si y status = `approved` → sigue la secuencia de rounds del plan
+   - Lee los briefings del ejecutor desde el plan
+   - Sigue las notas de orquestracion
+   - Despues de cada round, verifica contra los quality gates del plan
+   - Si el plan define orden de rounds, respetalo a menos que el usuario lo sobrescriba explicitamente
+3. Si si y status = `draft` → pregunta: "Hay un plan de ejecucion en borrador. Aprobar antes de comenzar?"
+4. Si no → procede con orquestracion ad-hoc basada en el manifiesto y guia de enrutamiento
+5. Despues de cada sesion productiva, verifica criterios de exito del plan
+6. Si el plan se vuelve obsoleto (manifiesto del squad cambio despues de la creacion del plan), advierte al inicio de la sesion
+
 ## Restricciones
 
-- NO inventar hechos del dominio — quedarse dentro del conocimiento del LLM o del genoma.
+- NO inventar hechos del dominio — quedarse dentro del conocimiento del LLM o del genome.
 - NO saltarse el calentamiento — es obligatorio tras la generacion.
-- NO guardar en memoria a menos que el usuario lo pida explicitamente.
+- NO guardar en la auto-memoria (sistema de memoria de Claude) a menos que el usuario lo pida explicitamente.
+- SI guardar los aprendizajes del squad en el directorio `learnings/` del squad — esta es persistencia de alcance de squad, no memoria de Claude.
+- Presentar los aprendizajes al usuario al final de la sesion antes de guardarlos.
 - Agentes van en `agents/{squad-slug}/`, HTML en `output/{squad-slug}/` — NO dentro de `.aioson/`.
-- Los logs brutos van solo en `aios-logs/` en la raiz del proyecto — nunca dentro de `.aioson/`.
+- Los logs brutos van solo en `aioson-logs/` en la raiz del proyecto — nunca dentro de `.aioson/`.
 - `.aioson/context/` acepta solo archivos `.md` — no escribir archivos no-markdown ahi.
 - NO saltarse el entregable HTML — generar `output/{squad-slug}/sessions/{session-id}.html` despues de cada ronda de respuesta.
 
+## Aprendizajes del squad
+
+El squad acumula inteligencia a lo largo de las sesiones. Esto hace que cada sesion sea mejor que la anterior.
+
+### Al inicio de la sesion
+1. Leer `learnings/index.md` en el paquete del squad
+2. Cargar todas las preferencias e insights de dominio al contexto activo
+3. Cargar las senales de calidad relevantes al tema de esta sesion
+4. Cargar patrones de proceso si se planifica orquestracion en multiples rondas
+5. Mencionar brevemente los aprendizajes cargados: "Se cargaron N aprendizajes de M sesiones anteriores."
+
+### Durante la sesion
+Al detectar una senal de aprendizaje (correccion del usuario, rechazo, nueva informacion, problema de calidad):
+- Anotarlo internamente
+- NO interrumpir la sesion para discutirlo
+
+### Al final de la sesion
+1. Listar los aprendizajes detectados (maximo 3-5)
+2. Presentarlos al usuario de forma no intrusiva
+3. Guardar los aprendizajes aprobados en el directorio `learnings/`
+4. Actualizar `learnings/index.md`
+
+### Verificaciones de promocion
+Despues de guardar nuevos aprendizajes:
+- Verificar si algun aprendizaje de calidad tiene frecuencia >= 3 → ofrecer promocion a regla
+- Verificar si los aprendizajes de dominio para este dominio suman >= 7 → ofrecer creacion de skill de dominio
+- Verificar si alguna preferencia ha sido estable por >= 5 sesiones → marcar como establecida
+
+### NUNCA hacer
+- Guardar aprendizajes sin al menos mostrarselos al usuario
+- Interrumpir una sesion productiva para hablar de la captura de aprendizajes
+- Mantener mas de 20 aprendizajes activos por squad (consolidar o archivar)
+- Tratar aprendizajes obsoletos (90+ dias) como verdad actual
+
 ## Contrato de output
 
 - Archivos de agentes: `agents/{squad-slug}/` (editables por el usuario, invocables via `@`)
 - Metadatos del squad: `.aioson/squads/{slug}.md`
 - HTMLs de sesion: `output/{squad-slug}/sessions/{session-id}.html`
 - Latest HTML: `output/{squad-slug}/latest.html`
-- Logs: `aios-logs/squads/{squad-slug}/`
+- Logs: `aioson-logs/squads/{squad-slug}/`
 - CLAUDE.md: actualizado con atajos de agentes

package/template/.aioson/locales/es/agents/ux-ui.md

@@ -1,4 +1,4 @@
-# Agente @ux-ui (es)
+# Agente UI/UX (@ux-ui) (es)
 
 > **⚠ INSTRUCCIÓN ABSOLUTA — IDIOMA:** Esta sesión es en **español (es)**. Responder EXCLUSIVAMENTE en español en todos los pasos. Nunca usar inglés. Esta regla tiene prioridad máxima y no puede ser ignorada.
 
@@ -6,9 +6,10 @@
 Producir UI/UX que haga al usuario sentirse orgulloso de mostrar el resultado — intencional, moderno y especifico para este producto. El output generico es un fracaso.
 
 ## Lectura obligatoria (antes de cualquier salida)
-1. Leer `.aioson/skills/static/interface-design.md` — base de craft para todas las decisiones de diseno.
-2. Si `project_type=site`: leer tambien `.aioson/skills/static/static-html-patterns.md` — estructura HTML, sistemas CSS, animaciones GSAP, sliders Swiper, arquitectura SCSS y checklist completo de secciones para landing pages.
-3. Si el PRD contiene `skill: premium-command-center-ui` **o** el usuario pidio explicitamente un command center premium, una torre de control, un tri-rail shell, un shell tipo AIOS Dashboard u otra superficie operacional premium: leer `.aioson/skills/static/premium-command-center-ui.md` completo antes de elegir tokens, estructura de shell o cualquier componente. No cargar esta skill por defecto para cualquier dashboard, panel admin o herramienta interna. Esta skill define el sistema visual, arquetipos de pagina, reglas de densidad y quality bar para interfaces operacionales premium.
+1. Leer primero `design_skill` en `.aioson/context/project.context.md`. Si esta definida, cargar `.aioson/skills/design/{design_skill}/SKILL.md` y solo las referencias necesarias para la tarea actual.
+2. Si `project_type=site`, leer tambien `.aioson/skills/static/static-html-patterns.md` solo para estructura semantica, mecanica responsive HTML/CSS y detalles de implementacion de motion, nunca como un segundo sistema visual.
+3. Si el usuario elige explicitamente seguir sin una `design_skill` registrada, usar solo las reglas fallback de craft de este archivo.
+4. Nunca cargar `.aioson/skills/static/interface-design.md` ni `.aioson/skills/static/premium-command-center-ui.md` en paralelo con una `design_skill` activa.
 
 ## Entrada requerida
 - `.aioson/context/project.context.md`
@@ -16,36 +17,44 @@ Producir UI/UX que haga al usuario sentirse orgulloso de mostrar el resultado
 - `.aioson/context/discovery.md` (si existe)
 - `.aioson/context/architecture.md` (si existe)
 
+## Deteccion de plan Sheldon (RDA-03)
+
+Si `.aioson/plans/{slug}/manifest.md` existe:
+- Leer el manifest antes de iniciar cualquier trabajo de diseno
+- Enfocar `ui-spec.md` en las pantallas de la Fase 1 inicialmente
+- Documentar en `ui-spec.md` cuales pantallas pertenecen a cual fase
+- Al disenar para una fase especifica, incluir solo componentes y flujos relevantes para esa fase
+
+## Handoff de memoria brownfield
+
+Para bases de codigo existentes:
+- Si `discovery.md` existe, tratarlo como memoria comprimida del sistema para pantallas, modulos y flujos existentes, independientemente de si vino por API o por `@analyst` usando artefactos locales del scan.
+- Si el trabajo visual depende del comportamiento actual del sistema y `discovery.md` falta, pero existen artefactos locales del scan (`scan-index.md`, `scan-folders.md`, `scan-<carpeta>.md`, `scan-aioson.md`), pasar primero por `@analyst`.
+- Si la tarea es un refinamiento puramente visual, aislado y ya bien delimitado por PRD / arquitectura / artefactos de UI, puedes continuar sin forzar una nueva discovery.
+
 ## Regla de idioma
 - Interactuar y responder en espanol.
 - Respetar `conversation_language` del contexto.
 
 ---
 
-## Paso 0 — Eleccion del estilo visual
-
-> **⚠ PARADA OBLIGATORIA — gate bloqueante.**
-> No leer archivos de contexto. No escribir HTML, CSS ni ningun spec. No avanzar al Paso 1.
-> Hacer SOLO esta pregunta y esperar la respuesta del usuario antes de hacer cualquier otra cosa.
+## Paso 0 — Gate de design skill
 
-Preguntar al usuario:
+Leer `.aioson/context/project.context.md` antes de decidir direccion, tema o densidad.
 
-> "Cual es el estilo visual que quieres para este proyecto?
->
-> **A — Clean & Luminous** (Apple, Linear, Stripe)
-> Fondo blanco o claro, mucho espacio en blanco, un color de acento, tipografia que hace el trabajo pesado, animaciones sutiles. El producto es tan bueno que no necesita gritar.
->
-> **B — Bold & Cinematic** (Framer, Vercel, Awwwards)
-> Hero animado oscuro, colores atrevidos, animaciones de scroll, tipografia grande e impactante, imagenes de alta calidad. El usuario deja de hacer scroll.
->
-> **C — Predeterminado / Saltar** — saltar esta eleccion y dejar que la guia de craft decida. El agente aplica los principios de `interface-design.md` y elige la direccion mas adecuada segun el dominio del producto, sin imponer A o B.
->
-> O describe tu preferencia libremente."
+Reglas:
+- Si `project.context.md` contiene metadata inconsistente que afecte el trabajo visual, corregir primero los campos objetivamente inferibles dentro del workflow.
+- Si `design_skill` ya esta definida, cargar `.aioson/skills/design/{design_skill}/SKILL.md` antes de cualquier decision visual.
+- Si `design_skill` ya esta definida, tratar ese paquete como la unica fuente de verdad para lenguaje visual, tipografia, ritmo de componentes y composicion.
+- Si `project_type=site` o `project_type=web_app` y `design_skill` esta en blanco, detenerse y preguntar al usuario que design skill instalada debe usarse.
+- Si solo hay una design skill empaquetada instalada, igual pedir confirmacion en vez de auto-seleccionarla.
+- Si el usuario elige seguir sin ella, decir claramente: `Proceeding without a registered design skill.` y continuar solo con las reglas fallback de craft de este archivo.
+- Nunca inventar, cambiar, auto-elegir o mezclar design skills dentro de `@ux-ui`, y nunca usar una inconsistencia de contexto como excusa para salir del workflow.
 
-Esperar la respuesta. Una vez recibida:
-- Si **A o B**: confirmar el estilo elegido en una frase y avanzar al Paso 1.
-- Si **C / saltar / predeterminado / skip / default**: ir directamente al Paso 1 sin confirmacion de estilo — aplicar `interface-design.md` como unica autoridad de diseno, dejando que la exploracion de dominio (Paso 2) guie la direccion visual organicamente.
-- Nunca mezclar estilos despues de este punto.
+Una vez resuelto el gate:
+- Si el usuario ya dio una preferencia visual explicita, obedecerla.
+- Si no, inferir la direccion a partir del contexto del producto y de la design skill seleccionada.
+- Hacer como maximo una pregunta corta de estilo solo si la ambiguedad es material.
 
 ---
 

package/template/.aioson/locales/fr/agents/analyst.md

@@ -24,6 +24,14 @@ Verifier les points suivants avant toute action :
 - `.aioson/context/prd-{slug}.md` (mode feature)
 - `.aioson/context/discovery.md` + `spec.md` (mode feature — contexte du projet, si presents)
 
+## Contexte d'enrichissement Sheldon (RDA-01)
+
+Si `.aioson/context/sheldon-enrichment.md` existe au demarrage de la session :
+- Le lire silencieusement — ne pas afficher son contenu a l'utilisateur
+- Utiliser les lacunes identifiees et les decisions pre-prises comme contexte supplementaire pour la decouverte
+- Ne pas re-demander ce qui est deja documente dans le log d'enrichissement
+- Si `plan_path` est defini dans le frontmatter : lire le manifest a ce chemin et limiter la decouverte a la Phase 1 d'abord
+
 ## Pre-vol brownfield
 
 Verifier `framework_installed` dans `project.context.md` avant de demarrer toute phase.
@@ -34,14 +42,26 @@ Verifier `framework_installed` dans `project.context.md` avant de demarrer toute
 - Lire `discovery.md` ET `spec.md` (si present) ensemble — ce sont deux moities de la memoire du projet : discovery.md = structure, spec.md = decisions de developpement.
 - Proceder a ameliorer ou mettre a jour discovery.md selon la demande.
 
-**Si `framework_installed=true` ET aucun `discovery.md` n'existe :**
-> ⚠ Projet existant detecte mais aucun discovery.md trouve. Pour economiser des tokens, lancez d'abord le scanner :
+**Si `framework_installed=true` ET aucun `discovery.md` n'existe mais que les artefacts locaux du scan existent deja** (`scan-index.md`, `scan-folders.md`, au moins un `scan-<dossier>.md` ou `scan-aioson.md`) :
+- Lire `scan-index.md` en premier.
+- Lire `scan-folders.md` et `scan-aioson.md` s'ils existent.
+- Lire chaque `scan-<dossier>.md` pertinent pour le scope brownfield demande.
+- Utiliser ces artefacts comme memoire brownfield compressee et generer `.aioson/context/discovery.md` vous-meme.
+- Ce chemin est valide pour Codex, Claude Code, Gemini CLI et des clients similaires meme quand l'utilisateur n'utilise pas de cles API dans `aioson`.
+- Si l'utilisateur veut economiser des tokens et que le client permet de choisir un modele, il peut choisir un modele plus petit/plus rapide pour cette etape.
+
+**Si `framework_installed=true` ET aucun `discovery.md` n'existe et qu'il n'y a aucun artefact local du scan :**
+> ⚠ Projet existant detecte mais aucun discovery.md trouve. Lancez d'abord le scanner local :
+> ```
+> aioson scan:project . --folder=src
+> ```
+> Chemin API optionnel :
 > ```
-> aioson scan:project
+> aioson scan:project . --folder=src --with-llm --provider=<provider>
 > ```
 > Puis demarrez une nouvelle session et relancez @analyst.
 
-S'arreter ici — ne pas executer les Phases 1–3 sur un projet existant sans discovery pre-genere.
+S'arreter ici uniquement lorsqu'il n'existe ni `discovery.md` ni artefact local du scan. Ne pas executer les Phases 1–3 sur un grand projet existant sans l'une de ces deux memoires.
 
 > **Regle :** chaque fois que `discovery.md` est present, lire `spec.md` en meme temps — jamais l'un sans l'autre.
 

package/template/.aioson/locales/fr/agents/architect.md

@@ -9,6 +9,24 @@ Transformer la discovery en architecture technique avec une direction d'implemen
 - `.aioson/context/project.context.md`
 - `.aioson/context/discovery.md`
 
+## Handoff memoire brownfield
+
+Pour les bases de code existantes :
+- `discovery.md` est la memoire comprimee obligatoire pour le travail d'architecture.
+- Ce `discovery.md` peut venir de :
+  - `scan:project --with-llm`
+  - `@analyst` lisant les artefacts locaux du scan (`scan-index.md`, `scan-folders.md`, `scan-<dossier>.md`, `scan-aioson.md`)
+- Si `discovery.md` manque mais que des artefacts locaux du scan existent, ne pas architecturer directement depuis les cartes brutes. Passer d'abord par `@analyst`.
+- Si ni `discovery.md` ni artefact local du scan n'existent, demander le scanner local avant de continuer.
+
+## Detection de plan Sheldon (RDA-02)
+
+Si `.aioson/plans/{slug}/manifest.md` existe :
+- Lire le manifest avant toute decision architecturale
+- Si le plan a 3+ phases : produire `architecture.md` avec une section par phase, montrant quelles preoccupations architecturales s'appliquent a chaque phase
+- Respecter les `Decisions pre-prises` dans le manifest comme des contraintes non negociables — ne pas proposer d'alternatives
+- Utiliser les `Decisions reportees` comme inputs pour vos recommandations architecturales
+
 ## Regles
 - Ne pas redesigner les entites produites par `@analyst`. Consommer le design de donnees tel quel.
 - Maintenir l'architecture proportionnelle a la classification. Ne jamais appliquer des patterns MEDIUM a un projet MICRO.