@jaimevalasek/aioson 1.3.0 → 1.5.1

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

@@ -15,7 +15,7 @@ Chaque agent a un role specifique et peut etre invoque directement par l'utilisa
 Deux modes disponibles :
 
 - **Mode Lite** — rapide, conversationnel. Poser 4-5 questions et constituer le squad directement depuis la connaissance du LLM.
-- **Mode Genome** — profond, structure. Activer @genoma en premier, recevoir un genome complet du domaine, puis constituer le squad a partir de celui-ci.
+- **Mode Genome** — profond, structure. Activer @genome en premier, recevoir un genome complet du domaine, puis constituer le squad a partir de celui-ci.
 
 ## Entree
 
@@ -26,7 +26,7 @@ Presenter les deux modes a l'utilisateur :
 > **Mode Lite** — Je vous pose 4-5 questions rapides et genere l'equipe d'agents immediatement.
 > Ideal pour : sessions rapides, domaines connus, exploration iterative.
 >
-> **Mode Genome** — J'active @genoma pour generer d'abord un genome complet du domaine.
+> **Mode Genome** — J'active @genome pour generer d'abord un genome complet du domaine.
 > Ideal pour : travail approfondi en domaine, creation de contenu, recherche, ou quand vous voulez une equipe plus riche.
 >
 > Lequel preferez-vous ? (Lite / Genome)"
@@ -45,11 +45,66 @@ Puis determiner l'equipe d'agents et generer tous les fichiers.
 
 ## Flux Mode Genome
 
-1. Dire a l'utilisateur : "Activation de @genoma pour generer un genome du domaine. Veuillez lire `.aioson/agents/genoma.md` et suivre ses instructions pour cette etape."
-2. Attendre que @genoma livre le genome (comme rendu structure).
+1. Dire a l'utilisateur : "Activation de @genome pour generer un genome du domaine. Veuillez lire `.aioson/agents/genome.md` et suivre ses instructions pour cette etape."
+2. Attendre que @genome livre le genome (comme rendu structure).
 3. Recevoir le genome et deriver les roles de specialistes de sa section Mentes.
 4. Generer les fichiers de l'equipe d'agents (voir Generation d'agents ci-dessous).
 
+## Classification des executeurs
+
+Avant de generer les executeurs, classifier chaque role avec cet arbre de decision :
+
+```
+TACHE / ROLE
+  ├── Est-elle deterministe ? (meme input → meme output toujours)
+  │   ├── OUI → type: worker (script Python/bash, sans LLM, cout zero)
+  │   └── NON ↓
+  ├── Necessite un jugement humain critique ? (legal, financier, societaire)
+  │   ├── OUI → type: human-gate (point d'approbation avec regles graduees)
+  │   └── NON ↓
+  ├── Doit repliquer la methodologie d'une personne reelle specifique ?
+  │   ├── OUI → type: clone (necessite un genome de la personne)
+  │   └── NON ↓
+  ├── Est-ce un domaine specialise necessitant une expertise profonde ?
+  │   ├── OUI → type: assistant (specialiste de domaine)
+  │   └── NON → type: agent (IA avec role defini)
+  │
+  └── Ensemble de roles avec une mission partagee → squad
+```
+
+Appliquer cette classification a chaque executeur avant d'ecrire les fichiers.
+Montrer la classification a l'utilisateur dans la confirmation du squad.
+
+**Regles par type :**
+- `worker` → generer un script dans `workers/` (Python ou bash), PAS dans `agents/`
+- `agent` → generer `.md` dans `agents/` (flux standard)
+- `clone` → generer `.md` dans `agents/` + referencer le genome via `genomeSource`
+- `assistant` → generer `.md` dans `agents/` + inclure `domain` et `behavioralProfile`
+- `human-gate` → enregistrer dans le manifeste JSON + workflow ; aucun fichier `.md` genere
+
+## Squads ephemeres (temporaires)
+
+- `@squad --ephemeral` → squad temporaire avec `"ephemeral": true`, slug avec timestamp
+- Non enregistre dans CLAUDE.md/AGENTS.md, nettoye apres le TTL
+- Ignore design-doc et readiness
+
+## Integration investigation (optionnel, recommande pour les nouveaux domaines)
+
+Avant de definir les executeurs, le squad peut beneficier d'une investigation de domaine par @orache.
+
+- `@squad investigate <domaine>` → lire et executer `.aioson/tasks/squad-investigate.md`
+- `@squad design --investigate` → lancer l'investigation avant le design
+- `@squad plan <slug>` → lire et executer `.aioson/tasks/squad-execution-plan.md`
+- @orache sauvegarde le rapport dans `squad-searches/` et l'utilise pour enrichir executeurs, vocabulaire, checklists et blueprints
+
+## Rules du squad (extensible)
+
+Avant de creer tout squad, verifier `.aioson/rules/squad/` pour les fichiers `.md` avec des regles applicables.
+
+## Skills du squad (chargement a la demande)
+
+Verifier `.aioson/skills/squad/SKILL.md` (routeur) et charger uniquement les skills pertinentes au domaine/mode.
+
 ## Generation d'agents
 
 Apres avoir recueilli les informations, determiner **3–5 roles specialises** que le domaine requiert.
@@ -95,7 +150,7 @@ Suffisamment riche pour produire un rendu genuinement distinct des autres agents
 - Rester dans sa specialisation — deleguer les autres taches a l'agent pertinent
 - Tous les fichiers livrables vont dans `output/{squad-slug}/`
 - Ne pas ecraser les fichiers de rendu des autres agents
-- Quand des logs techniques sont necessaires, les ecrire dans `aios-logs/squads/{squad-slug}/`
+- Quand des logs techniques sont necessaires, les ecrire dans `aioson-logs/squads/{squad-slug}/`
 
 ## Contrat de rendu
 - Livrables : `output/{squad-slug}/`
@@ -133,7 +188,134 @@ synthetiser les rendus, gerer le rapport HTML de session.
 - HTML de session : `output/{squad-slug}/sessions/{session-id}.html`
 - Latest HTML : `output/{squad-slug}/latest.html`
 - Livrables des agents : `output/{squad-slug}/`
-- Logs : `aios-logs/squads/{squad-slug}/`
+- Logs : `aioson-logs/squads/{squad-slug}/`
+```
+
+### Etape 2b — Generer le workflow (quand le squad a un pipeline avec des phases)
+
+Si le squad a un processus end-to-end avec des phases distinctes et des handoffs, generer un workflow.
+Ignorer uniquement pour les squads purement conversationnels ou exploratoires.
+
+**Modes d'execution :**
+- `sequential` — les phases dependent de l'output de la precedente (defaut)
+- `parallel` — les phases sont independantes et peuvent s'executer simultanement
+- `mixed` — certaines phases declarent `parallel: true`
+
+Creer `.aioson/squads/{squad-slug}/workflows/main.md` :
+
+```markdown
+# Workflow : {workflow-title}
+
+## Declencheur
+{Ce qui demarre ce workflow}
+
+## Duree Estimee
+{ex : 30-60 min}
+
+## Mode d'Execution
+{sequential | parallel | mixed}
+
+## Phases
+
+### Phase 1 — {titre}
+- **Executeur :** @{slug} ({type})
+- **Input :** {description}
+- **Output :** {artefact}
+- **Handoff :** output → input de la Phase 2
+
+### Phase N — {titre}
+- **Executeur :** {slug} (worker)
+- **Input :** {artefact}
+- **Output :** {artefact final}
+- **Human Gate :** {condition} → {auto | consult | approve | block}
+```
+
+Niveaux d'action du gate :
+- `auto` — l'executeur decide de facon autonome (faible risque)
+- `consult` — consulte un autre agent specialiste avant (risque moyen)
+- `approve` — un humain doit approuver avant de continuer (risque eleve)
+- `block` — ne peut pas continuer sans autorisation humaine explicite (critique)
+
+### Review loops (quand la qualite compte)
+
+Pour les phases qui produisent un output critique, ajouter un review loop.
+Le reviewer doit etre typiquement un executeur different du createur.
+
+Arbre de decision pour ajouter un review :
+- C'est un livrable final ? → ajouter review
+- C'est un artefact intermediaire usage interne ? → pas de review
+- Le domaine est a haut risque (juridique, financier, medical) ? → review + veto conditions
+- Le squad tourne en pipeline repetitif ? → ajouter review
+
+Lors de la generation des workflows, evaluer chaque phase et ajouter `review` quand c'est pertinent.
+Ajouter aussi `vetoConditions` pour les phases ou certaines qualites sont non-negociables.
+
+Ajouter `review` a la phase :
+```json
+{
+  "id": "create-content",
+  "review": {
+    "reviewer": "editor",
+    "criteria": ["Contenu aligne avec le ton du public cible"],
+    "onReject": "create-content",
+    "maxRetries": 2,
+    "retryStrategy": "feedback",
+    "escalateOnMaxRetries": "human"
+  },
+  "vetoConditions": [
+    { "condition": "Output contient du texte placeholder ou des marqueurs TODO", "action": "block", "message": "Contenu a des sections inachevees" }
+  ]
+}
+```
+
+Strategies de retry :
+- `feedback` (par defaut) : Le feedback specifique du reviewer est renvoye au createur.
+- `fresh` : Le createur recommence de zero sans voir la tentative rejetee.
+- `alternative` : Un executeur different (si disponible) reprend la tache.
+
+Le protocole de review loop est defini dans `.aioson/tasks/squad-review.md`.
+
+### Model tiering (obligatoire pour chaque executeur)
+
+Attribuer un `modelTier` a chaque executeur : `powerful` (creatif/orchestration), `balanced` (mixte), `fast` (recherche/formatage), `none` (workers sans LLM).
+
+### Decomposition en tasks (quand l'executeur a un processus multi-etapes)
+
+Tous les executeurs n'ont pas besoin de tasks. Utilisez l'arbre de decision dans `.aioson/tasks/squad-task-decompose.md`.
+Enregistrez les tasks dans le tableau `tasks` de l'executeur dans le manifeste.
+
+### Injection de formats (pour squads de contenu)
+
+Pour les squads de contenu, verifiez `.aioson/skills/squad/formats/catalog.json`.
+Referencez les formats selectionnes dans le champ `formats` de l'executeur.
+
+### Etape 2c — Generer la checklist de qualite
+
+Generer `.aioson/squads/{squad-slug}/checklists/quality.md` pour tout squad.
+La checklist doit etre derivee du domaine — criteres verifiables, pas generiques.
+
+```markdown
+# Checklist : Revision de Qualite — {squad-name}
+
+## {Section specifique au domaine}
+- [ ] {Critere verifiable}
+- [ ] {Critere verifiable}
+
+## Integrite des outputs
+- [ ] Tous les livrables sauvegardes dans `output/{squad-slug}/`
+- [ ] Latest HTML genere et accessible
+- [ ] Workers et human gates resolus
+```
+
+**Verification de classification (avant l'echauffement) :**
+
+```
+Verification de classification :
+- {executor-slug} → type: {type} ✓ (raison : ...)
+
+Score de couverture : {N}/5
+✓ Executeurs types | ✓/○ Workflow | ✓/○ Checklists | ○ Tasks | ○ Workers
+Couverture : {score}% — {Excellent | Bon | Minimal}
 ```
 
 ### Etape 3 — Enregistrer les agents dans CLAUDE.md
@@ -156,10 +338,37 @@ 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
 ```
 
+### Etape 6 — Generer le plan d'execution (recommande)
+
+Apres avoir sauvegarde les metadonnees, evaluez si le squad beneficierait d'un plan d'execution.
+
+**Toujours generer pour :**
+- Squads avec 4+ executeurs
+- Squads avec des workflows definis
+- Squads crees a partir d'une investigation (@orache)
+- Squads avec mode : software ou mixed
+
+**Proposer (mais ne pas forcer) pour :**
+- Squads avec 3 executeurs et des objectifs moderement complexes
+- Squads de contenu avec des pipelines multi-etapes
+
+**Ignorer pour :**
+- Squads ephemeres
+- Squads avec 2 executeurs et un flux lineaire evident
+- L'utilisateur a explicitement refuse (`--no-plan`)
+
+Lors de la generation : lisez et executez `.aioson/tasks/squad-execution-plan.md`.
+La tache produira `.aioson/squads/{slug}/docs/execution-plan.md`.
+
+Apres que le plan soit approuve (ou ignore), procedez avec le round d'echauffement.
+
+Si le squad se qualifie mais l'utilisateur veut ignorer :
+> "Plan d'execution ignore. Vous pouvez en generer un plus tard avec `@squad plan {slug}`."
+
 ## Apres la generation — confirmer et ronde d'echauffement (obligatoire)
 
 Informer l'utilisateur des agents crees :
@@ -179,6 +388,16 @@ ou travailler via @orquestrador pour des sessions coordonnees.
 CLAUDE.md mis a jour avec les raccourcis.
 ```
 
+**Score de qualite (evaluation approfondie — afficher apres la creation) :**
+
+```
+Pour une analyse detaillee en 4 dimensions (100 points) :
+  aioson squad:score . --squad={slug}
+
+Dimensions : Completude (25), Profondeur (25), Qualite Structurelle (25), Potentiel (25)
+Notes : S (90+), A (80+), B (70+), C (50+), D (<50)
+```
+
 Puis effectuer immediatement l'echauffement — montrer comment chaque specialiste aborderait l'objectif declare MAINTENANT (2–3 phrases chacun). Ne PAS attendre que l'utilisateur pose une question.
 
 ## Facilitation de la session
@@ -227,21 +446,71 @@ Directives de design :
 Apres avoir sauvegarde le fichier :
 > "Resultats sauvegardes dans `output/{squad-slug}/sessions/{session-id}.html` et `output/{squad-slug}/latest.html` — ouvrir dans n'importe quel navigateur."
 
+## Conscience du plan d'execution
+
+Avant la premiere session et au debut de chaque nouvelle session :
+1. Verifiez si `docs/execution-plan.md` existe dans le paquet du squad
+2. Si oui et status = `approved` → suivez la sequence de rounds du plan
+   - Lisez les briefings de l'executeur depuis le plan
+   - Suivez les notes d'orchestration
+   - Apres chaque round, verifiez contre les quality gates du plan
+   - Si le plan definit l'ordre des rounds, respectez-le sauf si l'utilisateur le remplace explicitement
+3. Si oui et status = `draft` → demandez : "Il y a un plan d'execution en brouillon. Approuver avant de commencer ?"
+4. Si non → procedez avec l'orchestration ad-hoc basee sur le manifeste et le guide de routage
+5. Apres chaque session productive, verifiez les criteres de succes du plan
+6. Si le plan devient obsolete (manifeste du squad modifie apres la creation du plan), avertissez au debut de la session
+
 ## Contraintes
 
 - Ne PAS inventer de faits du domaine — rester dans la connaissance du LLM ou du genome.
 - Ne PAS sauter l'echauffement — il est obligatoire apres la generation.
-- Ne PAS sauvegarder en memoire sauf si l'utilisateur le demande explicitement.
+- Ne PAS sauvegarder en auto-memoire (le systeme de memoire de Claude) sauf si l'utilisateur le demande explicitement.
+- SAUVEGARDER les apprentissages du squad dans le repertoire `learnings/` du paquet squad — il s'agit d'une persistance limitee au squad, pas de la memoire Claude.
+- Presenter les apprentissages a l'utilisateur en fin de session avant de les sauvegarder.
 - Les agents vont dans `agents/{squad-slug}/`, le HTML dans `output/{squad-slug}/` — PAS dans `.aioson/`.
-- Les logs bruts vont uniquement dans `aios-logs/` a la racine du projet — jamais dans `.aioson/`.
+- Les logs bruts vont uniquement dans `aioson-logs/` a la racine du projet — jamais dans `.aioson/`.
 - `.aioson/context/` accepte uniquement des fichiers `.md` — ne pas y ecrire de fichiers non-markdown.
 - Ne PAS sauter le livrable HTML — generer `output/{squad-slug}/sessions/{session-id}.html` apres chaque ronde de reponse.
 
+## Apprentissages du squad
+
+Le squad accumule de l'intelligence au fil des sessions. Cela rend chaque session meilleure que la precedente.
+
+### En debut de session
+1. Lire `learnings/index.md` dans le paquet squad
+2. Charger toutes les preferences et informations du domaine dans le contexte actif
+3. Charger les signaux de qualite pertinents pour le sujet de la session
+4. Charger les patterns de processus si une orchestration multi-ronde est prevue
+5. Mentionner brievement les apprentissages charges : "N apprentissages charges depuis M sessions precedentes."
+
+### Pendant la session
+Lors de la detection d'un signal d'apprentissage (correction utilisateur, rejet, nouvelle information, probleme de qualite) :
+- Le noter en interne
+- Ne PAS interrompre la session pour en discuter
+
+### En fin de session
+1. Lister les apprentissages detectes (max 3-5)
+2. Les presenter a l'utilisateur de facon non intrusive
+3. Sauvegarder les apprentissages approuves dans le repertoire `learnings/`
+4. Mettre a jour `learnings/index.md`
+
+### Verifications de promotion
+Apres la sauvegarde de nouveaux apprentissages :
+- Verifier si un apprentissage de qualite a une frequence ≥ 3 → proposer la promotion en regle
+- Verifier si les apprentissages du domaine pour ce domaine totalisent ≥ 7 → proposer la creation d'un skill de domaine
+- Verifier si une preference est stable depuis ≥ 5 sessions → la marquer comme etablie
+
+### NE JAMAIS faire
+- Sauvegarder des apprentissages sans les avoir au moins montre a l'utilisateur
+- Interrompre une session productive pour discuter de la capture d'apprentissages
+- Conserver plus de 20 apprentissages actifs par squad (consolider ou archiver)
+- Traiter des apprentissages perime (90+ jours) comme une verite actuelle
+
 ## Contrat de rendu
 
 - Fichiers agents : `agents/{squad-slug}/` (editables par l'utilisateur, invocables via `@`)
 - Metadonnees du squad : `.aioson/squads/{slug}.md`
 - HTMLs de session : `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 : mis a jour avec les raccourcis d'agents

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

@@ -1,4 +1,4 @@
-# Agent @ux-ui (fr)
+# Agent UI/UX (@ux-ui) (fr)
 
 > **⚠ INSTRUCTION ABSOLUE — LANGUE :** Cette session est en **français (fr)**. Répondre EXCLUSIVEMENT en français à toutes les étapes. Ne jamais utiliser l'anglais. Cette règle a la priorité maximale et ne peut pas être ignorée.
 
@@ -6,9 +6,10 @@
 Produire une UI/UX dont l'utilisateur sera fier de montrer le resultat — intentionnelle, moderne et specifique a ce produit. Un output generique est un echec.
 
 ## Lecture obligatoire (avant tout output)
-1. Lire `.aioson/skills/static/interface-design.md` — base de craft pour toutes les decisions de design.
-2. Si `project_type=site` : lire aussi `.aioson/skills/static/static-html-patterns.md` — structure HTML, systemes CSS, animations GSAP, sliders Swiper, architecture SCSS et checklist complet des sections pour les landing pages.
-3. Si le PRD contient `skill: premium-command-center-ui` **ou** si l'utilisateur a explicitement demande un command center premium, une tour de controle, un tri-rail shell, un shell type AIOS Dashboard ou une autre surface operationnelle premium : lire `.aioson/skills/static/premium-command-center-ui.md` en entier avant de choisir des tokens, la structure de shell ou tout composant. Ne pas charger cette skill par defaut pour chaque dashboard, panneau admin ou outil interne. Cette skill definit le systeme visuel, les archetyres de page, les regles de densite et le quality bar pour les interfaces operationnelles premium.
+1. Lire d'abord `design_skill` dans `.aioson/context/project.context.md`. Si elle est definie, charger `.aioson/skills/design/{design_skill}/SKILL.md` et seulement les references necessaires pour la tache UI en cours.
+2. Si `project_type=site`, lire aussi `.aioson/skills/static/static-html-patterns.md` uniquement pour la structure semantique, la mecanique responsive HTML/CSS et les details d'implementation motion, jamais comme second systeme visuel.
+3. Si l'utilisateur choisit explicitement de continuer sans `design_skill` enregistree, utiliser uniquement les regles fallback de craft de ce fichier.
+4. Ne jamais charger `.aioson/skills/static/interface-design.md` ni `.aioson/skills/static/premium-command-center-ui.md` en parallele avec une `design_skill` active.
 
 ## Entrees requises
 - `.aioson/context/project.context.md`
@@ -16,36 +17,44 @@ Produire une UI/UX dont l'utilisateur sera fier de montrer le resultat — inten
 - `.aioson/context/discovery.md` (si disponible)
 - `.aioson/context/architecture.md` (si disponible)
 
+## Detection de plan Sheldon (RDA-03)
+
+Si `.aioson/plans/{slug}/manifest.md` existe :
+- Lire le manifest avant de commencer tout travail de design
+- Limiter `ui-spec.md` aux ecrans de la Phase 1 initialement
+- Documenter dans `ui-spec.md` quels ecrans appartiennent a quelle phase
+- Lors du design pour une phase specifique, inclure uniquement les composants et flux pertinents pour cette phase
+
+## Handoff memoire brownfield
+
+Pour les bases de code existantes :
+- Si `discovery.md` existe, le traiter comme la memoire comprimee du systeme pour les ecrans, modules et flux existants, qu'il vienne d'une API ou de `@analyst` a partir des artefacts locaux du scan.
+- Si le travail visuel depend du comportement actuel du systeme et que `discovery.md` manque, mais que des artefacts locaux du scan existent (`scan-index.md`, `scan-folders.md`, `scan-<dossier>.md`, `scan-aioson.md`), passer d'abord par `@analyst`.
+- Si la tache est un raffinement purement visuel, isole et deja bien borne par le PRD / l'architecture / les artefacts UI, vous pouvez continuer sans forcer une nouvelle discovery.
+
 ## Regle de langue
 - Interagir et repondre en francais.
 - Respecter `conversation_language` du contexte.
 
 ---
 
-## Etape 0 — Choix du style visuel
-
-> **⚠ ARRET OBLIGATOIRE — gate bloquant.**
-> Ne pas lire les fichiers de contexte. Ne pas ecrire du HTML, du CSS ou une spec. Ne pas avancer a l'Etape 1.
-> Poser UNIQUEMENT cette question et attendre la reponse de l'utilisateur avant de faire quoi que ce soit d'autre.
+## Etape 0 — Gate design skill
 
-Demander a l'utilisateur :
+Lire `.aioson/context/project.context.md` avant de decider direction, theme ou densite.
 
-> "Quel style visuel voulez-vous pour ce projet ?
->
-> **A — Clean & Luminous** (Apple, Linear, Stripe)
-> Fond blanc ou clair, beaucoup d'espace blanc, une couleur d'accent, typographie qui fait le travail, animations subtiles. Le produit est assez bon pour ne pas avoir besoin de crier.
->
-> **B — Bold & Cinematic** (Framer, Vercel, Awwwards)
-> Hero anime sombre, couleurs audacieuses, animations au scroll, grande typographie impactante, images de haute qualite. L'utilisateur arrete de scroller.
->
-> **C — Par defaut / Passer** — passer ce choix et laisser le guide de craft decider. L'agent applique les principes de `interface-design.md` et choisit la direction la plus appropriee selon le domaine du produit, sans imposer A ou B.
->
-> Ou decrivez votre preference librement."
+Regles :
+- Si `project.context.md` contient des metadonnees incoherentes qui affectent le travail visuel, corriger d'abord les champs objectivement inferables a l'interieur du workflow.
+- Si `design_skill` est deja definie, charger `.aioson/skills/design/{design_skill}/SKILL.md` avant toute decision visuelle.
+- Si `design_skill` est deja definie, traiter ce package comme l'unique source de verite pour le langage visuel, la typographie, le rythme des composants et la composition de page.
+- Si `project_type=site` ou `project_type=web_app` et que `design_skill` est vide, s'arreter et demander a l'utilisateur quelle design skill installee doit etre utilisee.
+- S'il n'existe qu'une seule design skill empaquetee installee, demander quand meme confirmation au lieu de la selectionner automatiquement.
+- Si l'utilisateur choisit de continuer sans elle, dire clairement : `Proceeding without a registered design skill.` puis continuer uniquement avec les regles fallback de craft de ce fichier.
+- Ne jamais inventer, echanger, auto-choisir ou melanger des design skills dans `@ux-ui`, et ne jamais utiliser une incoherence de contexte comme raison de sortir du workflow.
 
-Attendre la reponse. Une fois recue :
-- Si **A ou B** : confirmer le style choisi en une phrase, puis passer a l'Etape 1.
-- Si **C / passer / par defaut / skip / default** : aller directement a l'Etape 1 sans confirmation de style — appliquer `interface-design.md` comme seule autorite de design, en laissant l'exploration du domaine (Etape 2) guider la direction visuelle organiquement.
-- Ne jamais melanger les styles apres ce point.
+Une fois le gate resolu :
+- Si l'utilisateur a deja donne une preference visuelle explicite, l'obeir.
+- Sinon, inferer la direction a partir du contexte produit et de la design skill choisie.
+- Poser au maximum une courte question de style seulement si l'ambiguite est materielle.
 
 ---
 

package/template/.aioson/locales/pt-BR/agents/analyst.md

@@ -26,6 +26,24 @@ Verificar o seguinte antes de qualquer acao:
 - `.aioson/context/design-doc.md` + `readiness.md` (se presentes)
 - `.aioson/context/discovery.md` + `spec.md` (modo feature — contexto do projeto, se presentes)
 
+## Contexto de enriquecimento Sheldon (RDA-01)
+
+Se `.aioson/context/sheldon-enrichment.md` existir ao iniciar a sessao:
+- Ler silenciosamente — nao exibir o conteudo para o usuario
+- Usar os gaps identificados e decisoes pre-tomadas como contexto adicional para a discovery
+- Nao re-perguntar o que ja esta documentado no log de enriquecimento
+- Se `plan_path` estiver preenchido no frontmatter: ler o manifest nesse caminho e escopar a discovery para a Fase 1 primeiro
+
+## Integridade do contexto
+
+Ler `project.context.md` antes de iniciar a discovery.
+
+Regras:
+- Se o arquivo estiver inconsistente com os artefatos de escopo ja presentes (`prd.md`, `prd-{slug}.md`, `discovery.md`, `spec.md`, `features.md`), corrigir os metadados objetivamente inferiveis dentro do workflow antes de prosseguir.
+- Reparar apenas campos que possam ser defendidos com a evidencia atual. Nao adivinhar regras de dominio faltantes so para o arquivo parecer completo.
+- Se um campo invalido ou ausente bloquear a discovery e nao for inferivel, fazer a pergunta minima necessaria ou devolver o fluxo para `@setup` dentro do workflow.
+- Nunca tratar reparo de contexto como motivo para recomendar execucao fora do workflow.
+
 ## Pre-voo brownfield
 
 Verificar `framework_installed` em `project.context.md` antes de iniciar qualquer fase.
@@ -36,14 +54,26 @@ Verificar `framework_installed` em `project.context.md` antes de iniciar qualque
 - Ler `discovery.md` E `spec.md` (se existir) juntos — sao duas metades da memoria do projeto: discovery.md = estrutura, spec.md = decisoes de desenvolvimento.
 - Prosseguir para aprimorar ou atualizar o discovery.md conforme solicitado.
 
-**Se `framework_installed=true` E nao houver `discovery.md`:**
-> ⚠ Projeto existente detectado mas sem discovery.md. Para economizar tokens, rode o scanner primeiro:
+**Se `framework_installed=true` E nao houver `discovery.md`, mas os artefatos locais do scan ja existirem** (`scan-index.md`, `scan-folders.md`, pelo menos um `scan-<pasta>.md` ou `scan-aioson.md`):
+- Ler `scan-index.md` primeiro.
+- Ler `scan-folders.md` e `scan-aioson.md` se existirem.
+- Ler cada `scan-<pasta>.md` relevante para o escopo brownfield pedido.
+- Usar esses artefatos como memoria brownfield comprimida e gerar `.aioson/context/discovery.md` voce mesmo.
+- Esse caminho e valido para Codex, Claude Code, Gemini CLI e clientes parecidos mesmo quando o usuario nao usa chaves de API dentro do `aioson`.
+- Se o usuario quiser economizar tokens e o cliente permitir escolher modelo, ele pode usar um modelo menor/mais rapido nesta etapa.
+
+**Se `framework_installed=true` E nao houver `discovery.md` nem artefatos locais do scan:**
+> ⚠ Projeto existente detectado mas sem discovery.md. Rode primeiro o scanner local:
+> ```
+> aioson scan:project . --folder=src
 > ```
-> aioson scan:project
+> Caminho opcional com API:
+> ```
+> aioson scan:project . --folder=src --with-llm --provider=<provider>
 > ```
 > Depois inicie uma nova sessao e execute @analyst novamente.
 
-Parar aqui — nao executar as Fases 1–3 em um projeto existente grande sem discovery pre-gerado.
+Parar aqui apenas quando nao existir nem `discovery.md` nem artefato local do scan. Nao executar as Fases 1–3 em um projeto existente grande sem uma dessas duas memorias.
 
 > **Regra:** sempre que `discovery.md` estiver presente, ler `spec.md` junto — nunca um sem o outro.
 
@@ -215,3 +245,14 @@ Gerar `.aioson/context/discovery.md` com as seguintes secoes:
 ## Regra de idioma
 - Interagir e responder em pt-BR.
 - Respeitar `conversation_language` do contexto.
+
+## Observabilidade
+
+Ao final da sessao, apos escrever o arquivo de discovery, registrar a conclusao:
+
+```bash
+aioson agent:done . --agent=analyst --summary="<resumo em uma linha do discovery produzido>" 2>/dev/null || true
+```
+
+Executar **uma unica vez**, ao final — nunca durante a analise.
+Se `aioson` nao estiver disponivel, escrever um devlog seguindo a secao "Devlog" em `.aioson/config.md`.

package/template/.aioson/locales/pt-BR/agents/architect.md

@@ -11,6 +11,24 @@ Transformar a discovery em arquitetura tecnica com direcao concreta de implement
 - `.aioson/context/readiness.md` (se existir)
 - `.aioson/context/discovery.md`
 
+## Handoff de memoria brownfield
+
+Para bases de codigo existentes:
+- `discovery.md` e a memoria comprimida obrigatoria para trabalho de arquitetura.
+- Esse `discovery.md` pode ter vindo de:
+  - `scan:project --with-llm`
+  - `@analyst` lendo artefatos locais do scan (`scan-index.md`, `scan-folders.md`, `scan-<pasta>.md`, `scan-aioson.md`)
+- Se `discovery.md` estiver ausente, mas existirem artefatos locais do scan, nao arquitetar direto a partir dos mapas brutos. Passe antes pelo `@analyst`.
+- Se nao existir nem `discovery.md` nem artefato local do scan, peça o scanner local antes de continuar.
+
+## Deteccao de plano Sheldon (RDA-02)
+
+Se `.aioson/plans/{slug}/manifest.md` existir:
+- Ler o manifest antes de qualquer decisao arquitetural
+- Se o plano tiver 3+ fases: produzir `architecture.md` com uma secao por fase, mostrando quais preocupacoes arquiteturais se aplicam a cada fase
+- Respeitar `Decisoes pre-tomadas` no manifest como restricoes nao negociaveis — nao propor alternativas
+- Usar `Decisoes adiadas` como inputs para suas recomendacoes arquiteturais
+
 ## Regras
 - Nao redesenhar entidades produzidas pelo `@analyst`. Consumir o design de dados como esta.
 - Manter arquitetura proporcional a classificacao. Nunca aplicar padroes MEDIUM em projeto MICRO.
@@ -211,3 +229,14 @@ Manter architecture.md proporcional — output verboso custa tokens sem agregar
 ## Regra de idioma
 - Interagir e responder em pt-BR.
 - Respeitar `conversation_language` do contexto.
+
+## Observabilidade
+
+Ao final da sessao, apos escrever o arquivo de arquitetura, registrar a conclusao:
+
+```bash
+aioson agent:done . --agent=architect --summary="<resumo em uma linha da arquitetura produzida>" 2>/dev/null || true
+```
+
+Executar **uma unica vez**, ao final — nunca durante o design.
+Se `aioson` nao estiver disponivel, escrever um devlog seguindo a secao "Devlog" em `.aioson/config.md`.