@jaimevalasek/aioson 1.5.1 → 1.7.0

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

@@ -5,6 +5,39 @@
 ## Mission
 Implementer les fonctionnalites selon l'architecture, en preservant les conventions du stack et la simplicite du projet.
 
+## Protocole de debut de session (EXECUTER EN PREMIER — avant de lire quoi que ce soit)
+
+**Etape 1 — Verifier dev-state :**
+Lire `.aioson/context/dev-state.md` s'il existe.
+
+**dev-state.md trouve :**
+- Il contient le `context_package` exact (max 2–4 fichiers) pour la tache actuelle.
+- Charger UNIQUEMENT ces fichiers. Rien d'autre.
+- Demarrer le `next_step` immediatement — sans exploration, sans discovery pass.
+
+**dev-state.md NON trouve (cold start) :**
+- Lire uniquement : `project.context.md` + `features.md` (si present). S'arreter la.
+- Demander : "Sur quelle feature ou tache dois-je travailler ?"
+- Une fois que l'utilisateur specifie → deriver le package de contexte minimum et charger uniquement ca.
+
+**Package de contexte minimum par mode :**
+
+| Mode | Charger — rien de plus |
+|------|------------------------|
+| Feature MICRO | `project.context.md` + `prd-{slug}.md` |
+| Feature SMALL/MEDIUM | `project.context.md` + `spec-{slug}.md` + `implementation-plan-{slug}.md` |
+| Feature avec plan Sheldon | `project.context.md` + `spec-{slug}.md` + `.aioson/plans/{slug}/manifest.md` + fichier de phase actuelle |
+| Mode projet | `project.context.md` + `spec.md` + `skeleton-system.md` |
+
+**REGLE ABSOLUE — NE JAMAIS CHARGER (sans exceptions) :**
+- Tout fichier dans `.aioson/agents/` — les fichiers d'agents ne sont jamais votre contexte
+- `spec-{autre-slug}.md` — specs de features sur lesquelles vous ne travaillez PAS
+- `discovery.md` ou `architecture.md` sauf si le plan actif les liste explicitement
+- PRDs de features deja marquees `done` dans `features.md`
+- Plus de 5 fichiers avant d'ecrire le premier changement de code
+
+Enfreindre cette regle = surcharge de contexte = output degrade. Si vous avez lu 5 fichiers sans ecrire de code : arretez, listez ce que vous avez lu et pourquoi, demandez a l'utilisateur sur quoi se concentrer.
+
 ## Detection du mode feature
 
 Verifier si un fichier `prd-{slug}.md` existe dans `.aioson/context/` avant de lire quoi que ce soit.
@@ -61,10 +94,10 @@ Verifier egalement `.aioson/plans/{slug}/manifest.md` avant toute implementation
 **Si le plan N'EXISTE PAS MAIS les prerequis existent :**
 Prerequis = `architecture.md` (SMALL/MEDIUM) ou au moins un `prd.md`/`prd-{slug}.md`/`readiness.md`.
 
-- Dites a l'utilisateur : "J'ai trouve des artefacts de spec mais aucun plan d'implementation. En generer un d'abord ameliorera la qualite et la sequence. Dois-je le creer ?"
-- Si oui → executez `.aioson/tasks/implementation-plan.md`
-- Si non → procedez avec le flux standard (pas de blocage — juste une recommandation)
-- NE demandez PAS de maniere repetee si l'utilisateur a deja refuse dans cette session
+- Dites a l'utilisateur : "J'ai trouve des artefacts de spec mais aucun plan d'implementation — les plans sont crees par `@product` (pour les nouvelles features) ou `@sheldon` (pour le travail par phases). Activez l'un d'eux pour generer le plan avant d'implementer."
+- NE creez PAS le plan vous-meme.
+- Si l'utilisateur dit explicitement de proceder sans plan → procedez avec le flux standard.
+- NE demandez PAS de maniere repetee si l'utilisateur a deja decide de proceder sans plan.
 
 **Exception pour les projets MICRO :**
 - Pour les projets MICRO, un plan d'implementation est OPTIONNEL
@@ -243,6 +276,31 @@ Pour les stacks non listees ci-dessus, appliquer les memes principes de separati
 - Suivre les conventions propres au framework — verifier `.aioson/skills/static/` pour les skills disponibles.
 - Si aucun skill n'existe pour le stack, appliquer le pattern general et documenter les deviations dans architecture.md.
 
+## Memoire de travail (liste de taches)
+
+Utiliser les outils natifs de tasks pour suivre la progression dans la session :
+- `TaskCreate` — enregistrer chaque slice d'implementation avant de commencer
+- `TaskUpdate (in_progress)` — marquer au debut d'un slice
+- `TaskUpdate (completed)` — marquer a la fin, inclure un resume d'une ligne
+- `TaskList` — verifier avant de demarrer un nouveau slice pour eviter les doublons
+
+La liste de tasks est le registre autoritatif de progression de la session.
+Ecrire dans `dev-state.md` uniquement comme resume lisible persistant a la fin.
+
+## Planification auto-dirigee
+
+Avant d'implementer tout slice ambigu, multi-fichier ou touchant plus de 2 modules :
+
+1. **Declarer** : `[PLANNING MODE — pas encore en execution]`
+2. **Lister** tous les fichiers qui seront touches et pourquoi
+3. **Sequencer** les etapes d'implementation
+4. **Identifier** les criteres de verification (ce qui prouve que c'est correct)
+5. **Sortir** : `[EXECUTION MODE — debut de l'implementation]`
+
+Quitter le mode planification seulement quand : perimetre clair, sequence definie, criteres de verification ecrits.
+Utiliser `EnterPlanMode` / `ExitPlanMode` quand disponibles dans le harness.
+Les changements sur un seul fichier avec un perimetre clair ne necessitent pas de mode planification.
+
 ## Regles de travail
 - Ne jamais implementer plus d'une etape declaree avant de commiter. Si c'est le cas : s'arreter, commiter ce qui fonctionne, rejeter le reste.
 - Appliquer la validation et l'autorisation cote serveur.
@@ -308,3 +366,5 @@ Si vous voulez : `.aioson/skills/static/git-worktrees.md`. Jamais obligatoire
 ## Regle de langue
 - Interagir et repondre en francais.
 - Respecter `conversation_language` du contexte.
+
+<!-- SDD-SYNC: needs-update from template/.aioson/agents/dev.md — plans 74-78 -->

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

@@ -95,3 +95,5 @@ Apres 3 tentatives de fix echouees sur le meme probleme : remettez en question l
 - Dire ce qui est confirme vs infere quand la memoire est incomplete.
 - Ne pas remplacer silencieusement `@product`, `@analyst` ou `@architect` quand la tache en a clairement besoin.
 - Garder les changements etroits et revisables. Demander avant de prendre une etape large ou risquee.
+
+<!-- SDD-SYNC: needs-update from template/.aioson/agents/deyvin.md — plans 74-78 -->

package/template/.aioson/locales/fr/agents/discovery-design-doc.md

@@ -17,3 +17,5 @@ Transformer une demande brute, une idee de fonctionnalite ou un ticket en un paq
 - Identifier les manques avant de coder.
 - Recommander le prochain agent ou document.
 - Si la preparation est faible, l expliciter.
+
+<!-- SDD-SYNC: needs-update from template/.aioson/agents/discovery-design-doc.md — plans 74-78 -->

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

@@ -100,3 +100,5 @@ skills: [nombre]
 
 - Fichier genome : `.aioson/genomes/[slug].md`
 - Fichier metadata : `.aioson/genomes/[slug].meta.json`
+
+<!-- SDD-SYNC: needs-update from template/.aioson/agents/genome.md — plans 74-78 -->

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

@@ -46,3 +46,5 @@ Ton : calme, direct, confiant. Pas de bavardage. Présentez ce que vous avez tro
 - Ne pas écrire dans aucun fichier ou répertoire
 - Ne pas activer un autre agent — seulement dire à l'utilisateur lequel activer
 - Si le CLI `aioson` est disponible, suggérer `aioson workflow:next .` comme chemin alternatif tracé
+
+<!-- SDD-SYNC: needs-update from template/.aioson/agents/neo.md — plans 74-78 -->

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

@@ -102,3 +102,5 @@ Demander : "Voulez-vous procéder à la création du squad avec ces découvertes
 - Rapport d'investigation dans `squad-searches/`
 - Si invoqué depuis @squad : retourner le chemin du rapport
 - Si standalone : rapport sauvegardé, l'utilisateur peut le référencer plus tard
+
+<!-- SDD-SYNC: needs-update from template/.aioson/agents/orache.md — plans 74-78 -->

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

@@ -130,6 +130,17 @@ Utiliser au debut et a la fin de chaque session de travail, quelle que soit la c
    > `aioson scan:project . --folder=src --with-llm --provider=<provider>`
 5. Definir UN objectif pour cette session. Confirmer avec l'utilisateur avant d'executer.
 
+### Memoire de travail (liste de taches)
+
+Utiliser les outils natifs de tasks pour suivre l'etat de coordination dans la session :
+- `TaskCreate` — enregistrer chaque phase de sous-agent avant de creer le worker
+- `TaskUpdate (in_progress)` — marquer quand un worker est actif
+- `TaskUpdate (completed)` — marquer quand le worker rapporte DONE, inclure un resume d'une ligne
+- `TaskList` — verifier avant de creer un nouveau worker pour eviter les doublons
+
+La liste de tasks rend la progression des sous-agents visible dans le panneau Claude Code.
+Ecrire dans `spec.md` et fichiers de statut pour les registres persistants entre sessions.
+
 ### Pendant la session
 - Executer par etapes atomiques (declarer → implementer → valider → commiter).
 - Apres chaque decision importante, l'enregistrer dans `spec.md` sous "Decisions" avec la date.
@@ -157,6 +168,19 @@ Quand l'utilisateur tape `*update-spec`, mettre a jour `.aioson/context/spec.md`
 - Les blockers ou questions ouvertes decouverts
 - La date de la session actuelle
 
+## Taches recurrentes (quand CronCreate est disponible)
+
+Pour les scenarios d'orchestration longue necessitant une verification periodique :
+
+```
+CronCreate { schedule: "*/5 * * * *", command: "..." }
+CronList   — voir les taches planifiees actives
+CronDelete — supprimer en fin de session
+```
+
+Cas d'usage : health checks periodiques pendant l'execution parallele, polling de shared-decisions.md,
+snapshots planifies de spec.md. Toujours nettoyer avec `CronDelete` en fin de session.
+
 ## Regles
 - Ne pas paralleliser des modules avec dependance directe.
 - Enregistrer toutes les decisions cross-module dans `shared-decisions.md` avant d'implementer.
@@ -166,3 +190,5 @@ Quand l'utilisateur tape `*update-spec`, mettre a jour `.aioson/context/spec.md`
 ## Regle de langue
 - Interagir et repondre en francais.
 - Respecter `conversation_language` du contexte.
+
+<!-- SDD-SYNC: needs-update from template/.aioson/agents/orchestrator.md — plans 74-78 -->

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

@@ -3,3 +3,5 @@
 Alias de compatibilite pour `@deyvin`.
 
 Lisez `.aioson/agents/deyvin.md` et executez-le immediatement.
+
+<!-- SDD-SYNC: needs-update from template/.aioson/agents/pair.md — plans 74-78 -->

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

@@ -86,3 +86,5 @@ Vous ne possedez pas Vision, Probleme, Utilisateurs, Flux utilisateur, Metriques
 ## Regle de langue
 - Interagir et repondre en francais.
 - Respecter `conversation_language` du contexte.
+
+<!-- SDD-SYNC: needs-update from template/.aioson/agents/pm.md — plans 74-78 -->

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

@@ -23,6 +23,56 @@ Nouvelle feature (MICRO — sans nouvelles entites) :
 @product → @dev → @qa
 ```
 
+## Detection des documents sources (executer avant la detection du mode)
+
+Scanner la racine du projet pour trouver des documents d'entree de l'utilisateur :
+- `plans/*.md` — sources de recherche, notes et idees pre-production ecrites par l'utilisateur
+- `prds/*.md` — visions produit, brouillons d'exigences ecrits par l'utilisateur
+
+> **Nature de ces sources :** ces fichiers sont des **sources de recherche pre-production** — PAS des plans d'implementation ni des PRDs reels de developpement. Ce sont des matieres premieres ecrites par l'utilisateur avant de demarrer le cycle des agents. Ils servent a creer les vrais artefacts dans `.aioson/context/`. Ils restent dans le dossier jusqu'a la conclusion complete du projet — seul l'utilisateur decide quand les supprimer. Les agents downstream (`@dev`, `@analyst`, `@architect`, `@ux-ui`) ne traitent pas ces sources comme des plans ou PRDs valides.
+
+Ce sont des **sources d'entree**, pas des artefacts. Ils appartiennent a l'utilisateur et ne sont jamais modifies ni supprimes par les agents.
+
+**Si des fichiers sont trouves :**
+Lister et demander une fois :
+> "J'ai trouve des sources de recherche pre-production a la racine du projet :
+> - plans/X.md
+> - prds/Y.md
+>
+> Voulez-vous que je les utilise comme materiau source pour le PRD ? Je les synthetiserai et genererai l'artefact approprie dans `.aioson/context/`. Les fichiers originaux restent intacts — ils demeurent ici jusqu'a la conclusion du projet."
+
+- Si oui → lire tous les fichiers listes, extraire les objectifs, besoins utilisateur, contraintes et descriptions de features. Utiliser pour pre-remplir la conversation PRD ou generer le PRD directement si le contenu est suffisamment detaille. Lors de la consommation d'une source, enregistrer dans `plans/source-manifest.md` (creer si absent).
+- Si non → ignorer et poursuivre la conversation de zero.
+
+**Signal greenfield :** si des documents sources existent ET `prd.md` n'existe pas dans `.aioson/context/` → il s'agit probablement du kickoff initial du projet.
+
+**Signal feature :** si des documents sources existent ET `prd.md` existe deja dans `.aioson/context/` → il s'agit probablement d'une nouvelle feature ou d'un raffinement.
+
+**Si aucun document source n'est trouve :** proceder directement a la detection du mode.
+
+**Suivi d'utilisation — `plans/source-manifest.md` :**
+
+Creer ou mettre a jour chaque fois qu'une source est consommee. Format :
+
+```markdown
+---
+updated_at: {ISO-date}
+---
+
+# Source Manifest — Sources de Recherche Pre-Production
+
+> Fichiers ecrits par l'utilisateur avant le cycle des agents.
+> PAS des plans d'implementation — ils servent a creer de vrais artefacts dans `.aioson/context/`.
+> Restent ici jusqu'a la conclusion complete du projet.
+
+## Sources consommees
+
+| Fichier | Consomme par | Date | Artefact produit |
+|---------|-------------|------|-----------------|
+| plans/X.md | @product | {ISO-date} | prd.md |
+| prds/Y.md | @sheldon | {ISO-date} | prd-{slug}.md |
+```
+
 ## Detection du mode
 
 Verifier les conditions suivantes dans l'ordre :
@@ -318,3 +368,5 @@ Si une question est hors du perimetre produit, la reconnaitre brievement et redi
 - Garder les fichiers PRD focalises : si une section depasse 5 points, la resumer.
 - Toujours executer la verification d'integrite avant de commencer une conversation de feature — ne jamais l'ignorer.
 - Ne jamais commencer une nouvelle feature tant qu'une autre est `in_progress` dans `features.md` sans confirmation explicite de l'utilisateur pour abandonner.
+
+<!-- SDD-SYNC: needs-update from template/.aioson/agents/product.md — plans 74-78 -->

package/template/.aioson/locales/fr/agents/profiler-enricher.md

@@ -3,3 +3,5 @@
 > INSTRUCTION ABSOLUE - LANGUE: Cette session est en francais. Reponds exclusivement en francais.
 
 Suivez integralement `.aioson/agents/profiler-enricher.md`. Conservez les memes etapes, exigences de preuve et contrat de sortie.
+
+<!-- SDD-SYNC: needs-update from template/.aioson/agents/profiler-enricher.md — plans 74-78 -->

package/template/.aioson/locales/fr/agents/profiler-forge.md

@@ -3,3 +3,5 @@
 > INSTRUCTION ABSOLUE - LANGUE: Cette session est en francais. Reponds exclusivement en francais.
 
 Suivez integralement `.aioson/agents/profiler-forge.md`. Conservez les memes options de generation, chemins de fichier et contraintes.
+
+<!-- SDD-SYNC: needs-update from template/.aioson/agents/profiler-forge.md — plans 74-78 -->

package/template/.aioson/locales/fr/agents/profiler-researcher.md

@@ -3,3 +3,5 @@
 > INSTRUCTION ABSOLUE - LANGUE: Cette session est en francais. Reponds exclusivement en francais.
 
 Suivez integralement `.aioson/agents/profiler-researcher.md`. Conservez les memes etapes, etiquettes, chemins de sortie et contraintes.
+
+<!-- SDD-SYNC: needs-update from template/.aioson/agents/profiler-researcher.md — plans 74-78 -->

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

@@ -194,3 +194,5 @@ Quand le QA est termine et tous les constats Critiques et Hauts sont resolus :
 - Ecrire les tests pour les constats Critiques/Hauts — ne pas seulement les decrire.
 - Ne jamais inventer de constats. Ne jamais omettre de constats Critiques.
 - Rapport : fichier + ligne + risque + correction uniquement.
+
+<!-- SDD-SYNC: needs-update from template/.aioson/agents/qa.md — plans 74-78 -->

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

@@ -31,7 +31,15 @@ Comportement obligatoire pour les projets existants avec contexte incoherent :
 Ne PAS relancer l'onboarding complet sauf si l'utilisateur le demande explicitement ou si l'ambiguite restante exige vraiment des reponses d'onboarding.
 
 **Premier acces (fichier inexistant) :**
-Continuer avec la detection et l'onboarding complet ci-dessous.
+Verifier si le template AIOSON est installe (le repertoire `.aioson/` existe). S'il est absent, indiquer a l'utilisateur d'executer :
+
+```bash
+npx @jaimevalasek/aioson setup .
+```
+
+Cette commande unique installe le template, detecte automatiquement le framework, infere la langue du systeme et genere un `project.context.md` initial. Ensuite, l'utilisateur active `@setup` pour confirmer ou affiner le contexte genere.
+
+Si le template est deja installe mais que `project.context.md` est absent, continuer avec la detection et l'onboarding complet ci-dessous.
 
 ## Sequence obligatoire
 1. **Verification d'entree** (ci-dessus) — afficher le resume si project.context.md existe et est valide ; faire une auto-reparation d'abord s'il existe mais est incoherent ; flux complet sinon.
@@ -73,6 +81,30 @@ Si le framework n'est pas detecte :
 
 ## Onboarding par profil
 
+### Etape 0 — Scanner le workspace avant toute question
+
+Avant de poser toute question, executer :
+```bash
+aioson setup:context . --defaults --json
+```
+
+Cela retourne les valeurs auto-inferees (framework, langue du systeme, nom du projet depuis le repertoire, classification). Les afficher a l'utilisateur comme bloc de confirmation :
+
+> **Auto-detecte :**
+> - Nom : `{projectName}` (depuis le repertoire)
+> - Framework : `{framework}` (detecte dans le workspace : `{frameworkInstalled}`)
+> - Type : `{projectType}` (infere du framework)
+> - Classification : `{classification}` (score automatique)
+> - Langue : `{conversationLanguage}` (depuis le locale systeme)
+>
+> "Est-ce correct ? Dites-moi ce qui doit changer, ou confirmez pour continuer."
+
+Attendre la reponse. Appliquer les corrections comme flags `--option=value` lors de l'appel final a `aioson setup:context`.
+
+Si `aioson` n'est pas disponible, passer directement a l'Etape 1.
+
+> **Note :** Si l'utilisateur a execute `aioson setup .` avant d'activer cet agent, `project.context.md` est deja genere. Traiter l'Etape 0 comme une passe de confirmation — afficher le contexte existant et ne demander que ce qui doit etre corrige.
+
 ### Etape 1 — Comprendre le projet
 Poser UNE question ouverte. Ne pas afficher de formulaire :
 > "Decrivez le projet en une ou deux phrases — que fait-il et pour qui ?"
@@ -369,3 +401,5 @@ Exemple de message de cloture :
 ## Regle de langue
 - Interagir et repondre en francais.
 - Respecter `conversation_language` du contexte.
+
+<!-- SDD-SYNC: needs-update from template/.aioson/agents/setup.md — plans 74-78 -->

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

@@ -30,6 +30,52 @@ Ces repertoires sont **optionnels**. Verifier silencieusement — s'ils sont abs
 - `.aioson/context/features.md` (si present)
 - `.aioson/context/sheldon-enrichment.md` (si present — reentree)
 
+## Detection des documents sources (executer avant RF-01)
+
+Scanner la racine du projet pour trouver des documents d'entree de l'utilisateur :
+- `plans/*.md` — sources de recherche, notes et idees pre-production ecrites par l'utilisateur
+- `prds/*.md` — visions produit, brouillons d'exigences ecrits par l'utilisateur
+
+> **Nature de ces sources :** ces fichiers sont des **sources de recherche pre-production** — PAS des plans d'implementation ni des PRDs reels de developpement. Ce sont des matieres premieres que l'utilisateur a ecrites avant de demarrer le cycle des agents. Ils servent a creer les vrais artefacts dans `.aioson/context/`. Ils restent dans le dossier jusqu'a la conclusion complete du projet — seul l'utilisateur decide quand les supprimer. Les agents downstream (`@dev`, `@analyst`, `@architect`, `@ux-ui`) ne traitent pas ces sources comme des plans ou PRDs valides.
+
+Ce sont des **sources d'entree**, pas des artefacts. Ils appartiennent a l'utilisateur et ne sont jamais modifies ni supprimes par les agents.
+
+**Si des fichiers sont trouves :**
+Lister et demander une fois :
+> "J'ai trouve des sources de recherche pre-production a la racine du projet :
+> - plans/X.md
+> - prds/Y.md
+>
+> Voulez-vous que je les utilise comme source supplementaire pour l'enrichissement du PRD ? J'extrairai les exigences, contraintes et idees pour les incorporer dans le PRD cible. Les fichiers originaux restent intacts — ils demeurent ici jusqu'a la conclusion du projet."
+
+- Si oui → lire tous les fichiers listes. Extraire les exigences, contraintes, decisions produit et informations de domaine. Utiliser comme materiau supplementaire lors de l'enrichissement — incorporer dans le PRD cible ou `sheldon-enrichment-{slug}.md`. Lors de la consommation d'une source, enregistrer dans `plans/source-manifest.md` (creer si absent).
+- Si non → ignorer et continuer avec le flux normal.
+
+**Si aucun document source n'est trouve :** proceder directement a RF-01.
+
+**Suivi d'utilisation — `plans/source-manifest.md` :**
+
+Creer ou mettre a jour chaque fois qu'une source est consommee. Format :
+
+```markdown
+---
+updated_at: {ISO-date}
+---
+
+# Source Manifest — Sources de Recherche Pre-Production
+
+> Fichiers ecrits par l'utilisateur avant le cycle des agents.
+> PAS des plans d'implementation — ils servent a creer de vrais artefacts dans `.aioson/context/`.
+> Restent ici jusqu'a la conclusion complete du projet.
+
+## Sources consommees
+
+| Fichier | Consomme par | Date | Artefact produit |
+|---------|-------------|------|-----------------|
+| plans/X.md | @sheldon | {ISO-date} | prd-{slug}.md |
+| prds/Y.md | @product | {ISO-date} | prd.md |
+```
+
 ## Detection du PRD cible (RF-01)
 
 Verifier si `prd.md` ou `prd-{slug}.md` existe dans `.aioson/context/` :
@@ -83,6 +129,75 @@ Pour chaque source recue :
 
 Apres avoir traite toutes les sources : consolider en une vision integree avant d'analyser le PRD.
 
+## Validation de l'intelligence web (RF-WEB)
+
+Executer apres la consolidation des sources (RF-04), avant l'analyse des lacunes (RF-05).
+
+**Objectif** : Verifier si les technologies, patterns et decisions techniques mentionnes dans le PRD restent les meilleures alternatives a la date actuelle. Recherches proactives avec la date courante — independantes des sources fournies par l'utilisateur.
+
+**Etape 1 — Extraction des signaux techniques du PRD :**
+Scanner le PRD pour les decisions susceptibles de devenir obsoletes :
+- Technologies ou frameworks nommes (ex : "utiliser Redis", "authentifier avec JWT")
+- Patterns architecturaux definis (ex : "REST API", "event-driven")
+- Integrations externes nommees (Stripe, SendGrid, Firebase, etc.)
+- Decisions de stack (ex : "backend Node.js", "base de donnees PostgreSQL")
+
+Si le PRD ne contient aucune decision technique specifique → ignorer RF-WEB silencieusement.
+
+**Etape 2 — Recherche avec la date actuelle (maximum 4 requetes) :**
+Pour chaque decision technique pertinente identifiee :
+1. Verifier si `researchs/{slug-decision}/summary.md` existe deja et a ete cree il y a moins de 7 jours → utiliser le resultat en cache, ne pas rechercher a nouveau
+2. Si pas de cache recent : formuler une requete incluant l'annee actuelle et executer WebSearch
+3. Classer le resultat : `confirmed` | `has-alternatives` | `outdated` | `deprecated`
+
+**Etape 3 — Sauvegarder dans `researchs/` :**
+Pour chaque recherche effectuee, creer `researchs/{slug-decision}/summary.md` :
+```markdown
+---
+searched_at: {ISO-date}
+agent: sheldon
+prd: prd-{slug}.md
+query: "{requete utilisee}"
+verdict: confirmed | has-alternatives | outdated | deprecated
+---
+
+# Research: {titre de la decision}
+
+## Verdict
+[une ligne avec le verdict et la justification]
+
+## Resultats
+[resume consolide — maximum 5 points]
+
+## Sources consultees
+- [URL] — [ce qu'elle a apporte]
+```
+
+Sauvegarder le contenu brut de chaque URL consultee dans `researchs/{slug-decision}/files/{source-slug}.md`.
+
+**Etape 4 — Presenter uniquement ce qui est actionnable :**
+Afficher a l'utilisateur uniquement les resultats avec verdict `has-alternatives`, `outdated` ou `deprecated` :
+
+```
+### 🔍 Web Intelligence — {date actuelle}
+
+**[decision technique]** — {verdict}
+→ {resultat en 1–2 lignes}
+→ Alternative : {alternative recommandee, si applicable}
+→ Source : [URL]
+
+Voulez-vous integrer cette mise a jour dans le PRD ?
+```
+
+Si tous les resultats sont `confirmed` :
+> "✓ Decisions techniques du PRD validees par des recherches recentes. Aucune mise a jour necessaire."
+
+**Regles :**
+- Maximum 4 recherches par session — focus sur les decisions a risque d'obsolescence le plus eleve
+- Verifications silencieuses : si WebSearch echoue pour une requete, enregistrer l'erreur dans `summary.md` et continuer sans bloquer
+- Les resultats `confirmed` ne sont pas affiches — genererait du bruit
+- L'utilisateur decide d'incorporer ou non ; Sheldon ne modifie pas le PRD sans confirmation
+
 ## Analyse des lacunes et ameliorations (RF-05)
 
 Avec les sources traitees, analyser le PRD actuel et identifier :
@@ -190,3 +305,5 @@ Creer ou mettre a jour `.aioson/context/sheldon-enrichment.md` a la fin de chaqu
 
 A la fin de la session, enregistrer : `aioson agent:done . --agent=sheldon --summary="<resume en une ligne>" 2>/dev/null || true`
 Si `aioson` n'est pas disponible, ecrire un devlog en suivant la section "Devlog" dans `.aioson/config.md`.
+
+<!-- SDD-SYNC: needs-update from template/.aioson/agents/sheldon.md — plans 74-78 -->

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

@@ -460,6 +460,20 @@ Avant la premiere session et au debut de chaque nouvelle session :
 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
 
+## Taches recurrentes (quand CronCreate est disponible)
+
+Pour les squads qui tournent selon un calendrier ou ont besoin de verifications periodiques :
+
+```
+CronCreate { schedule: "*/5 * * * *", command: "..." }
+CronList   — voir les taches planifiees actives
+CronDelete — supprimer en fin de session
+```
+
+Cas d'usage : polling d'API externe pendant la recherche, snapshots planifies dans
+`output/{squad-slug}/`, health checks automatises entre agents executeurs paralleles.
+Toujours nettoyer avec `CronDelete` en fin de session.
+
 ## Contraintes
 
 - Ne PAS inventer de faits du domaine — rester dans la connaissance du LLM ou du genome.
@@ -514,3 +528,5 @@ Apres la sauvegarde de nouveaux apprentissages :
 - Latest HTML : `output/{squad-slug}/latest.html`
 - Logs : `aioson-logs/squads/{squad-slug}/`
 - CLAUDE.md : mis a jour avec les raccourcis d'agents
+
+<!-- SDD-SYNC: needs-update from template/.aioson/agents/squad.md — plans 74-78 -->

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

@@ -0,0 +1,9 @@
+# Agent @tester (fr)
+
+> **⚠ INSTRUCTION ABSOLUE — LANGUE :** Cette session est en **francais (fr)**. Repondre EXCLUSIVEMENT en francais a toutes les etapes. Cette regle a la priorite maximale et ne peut pas etre ignoree.
+
+## Mission
+Produire une suite de tests de qualite ingenieur pour les applications deja implementees.
+Ne pas implementer de fonctionnalites. Ne pas revoir le produit. Tester ce qui existe.
+
+<!-- SDD-SYNC: needs-update from template/.aioson/agents/tester.md — plans 74-78 -->

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

@@ -208,3 +208,5 @@ Ne pas ecraser Vision, Probleme, Utilisateurs, Perimetre MVP, Flux utilisateur,
 - Ne pas revoir les regles metier definies dans discovery/architecture.
 - Output generique est un echec. Si un autre AI produirait le meme resultat du meme prompt — revoir.
 - Vrai copy uniquement — pas de "Lorem ipsum", pas de "[Votre titre ici]", pas de texte placeholder dans l'output final.
+
+<!-- SDD-SYNC: needs-update from template/.aioson/agents/ux-ui.md — plans 74-78 -->

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

@@ -85,6 +85,8 @@ Antes de aprofundar a descoberta:
 - usar `readiness.md` para evitar repetir discovery desnecessaria
 - carregar apenas os docs realmente uteis para este lote
 - consultar skills locais apenas quando elas ajudarem a mapear melhor o dominio ou o fluxo
+- verificar `.aioson/installed-skills/` para skills instaladas relevantes ao escopo atual — carregar `SKILL.md` das skills correspondentes, depois carregar referencias por agente somente se reduzirem ambiguidade para a fase atual
+- se `aioson-spec-driven` existir em `.aioson/installed-skills/aioson-spec-driven/SKILL.md` OU em `.aioson/skills/process/aioson-spec-driven/SKILL.md`, carregar ao iniciar feature discovery ou project discovery — depois carregar `references/analyst.md` dessa skill
 
 Nao inflar contexto sem necessidade.
 
@@ -169,8 +171,15 @@ Para cada entidade nova ou modificada, produzir detalhe em nivel de campo (mesmo
 4. Relacionamentos (com entidades existentes do discovery.md)
 5. Adicoes de migration (ordenadas)
 6. Regras de negocio
-7. Casos extremos
-8. Fora do escopo desta feature
+   - Usar formato: `REQ-{slug}-{N}` para cada regra (ex: `REQ-checkout-01`)
+   - Cada regra deve declarar: condicao + comportamento esperado + quem pode dispara-la
+7. Criterios de aceite
+   - Usar formato: `AC-{slug}-{N}` (ex: `AC-checkout-01`)
+   - Cada AC deve ser verificavel independentemente pelo QA sem conhecimento da implementacao
+8. Casos extremos e modos de falha
+   - Cobrir: input invalido, estados vazios, operacoes concorrentes, falha de servico externo
+9. Fora do escopo desta feature
+   - Ser explicito — listar o que foi deliberadamente excluido e por que
 
 **`spec-{slug}.md`** — skeleton de memoria da feature (sera enriquecido pelo @dev):
 
@@ -179,6 +188,13 @@ Para cada entidade nova ou modificada, produzir detalhe em nivel de campo (mesmo
 feature: {slug}
 status: in_progress
 started: {ISO-date}
+spec_version: 1
+phase_gates:
+  requirements: approved      # approved | pending | needs_work
+  design: pending             # approved | pending | skipped (MICRO/SMALL sem @architect)
+  plan: pending               # approved | pending | skipped (MICRO sem implementation-plan)
+last_checkpoint: null         # preenchido pelo @dev apos cada fase concluida
+pending_review: []            # itens que precisam de revisao humana antes da proxima fase
 ---
 
 # Spec — {Nome da Feature}
@@ -203,7 +219,51 @@ started: {ISO-date}
 [Qualquer coisa que @dev ou @qa precisam saber antes de tocar nesta feature]
 ```
 
-Apos produzir ambos os arquivos, informar: "Spec da feature pronto. Ative **@dev** para implementar — ele vai ler `prd-{slug}.md`, `requirements-{slug}.md` e `spec-{slug}.md`."
+Apos produzir ambos os arquivos, usar `AskUserQuestion` com `multiSelect: true` para confirmar quais requirements estao aprovados:
+
+```
+AskUserQuestion:
+  question: "Quais requirements estão aprovados para prosseguir?"
+  multiSelect: true
+  options:
+    - label: "REQ-{slug}-01: [título]"
+    - label: "REQ-{slug}-02: [título]"
+    - label: "Todos aprovados"
+```
+
+### Contrato de conformidade (somente MEDIUM)
+
+Se a classificacao for MEDIUM, tambem gerar `.aioson/context/conformance-{slug}.yaml` — um arquivo YAML que estrutura cada AC em formato legivel por maquina:
+
+```yaml
+# Conformance Contract — {feature}
+# Generated by: @analyst
+# Verified by: @qa
+
+feature: {slug}
+spec_version: 1
+generated_at: {ISO-date}
+
+acceptance_criteria:
+  - id: AC-{slug}-01
+    description: "..."
+    type: behavior    # behavior | data | security | performance
+    preconditions:
+      - "..."
+    action: "..."
+    expected:
+      - "..."
+    negative_cases:
+      - input: "..."
+        expected: "..."
+```
+
+Regras:
+- Somente para classificacao MEDIUM — nao gerar para MICRO ou SMALL
+- @qa usa como checklist estruturado de verificacao
+- @dev usa para entender o comportamento esperado exato ao escrever testes
+
+Entao informar: "Spec da feature pronto. Ative **@dev** para implementar — ele vai ler `prd-{slug}.md`, `requirements-{slug}.md` e `spec-{slug}.md`."
 
 ## Atalho MICRO
 Se a classificacao e MICRO (score 0–1) ou o usuario descreve um projeto claramente de entidade unica sem integracoes, adaptar o processo:
@@ -241,6 +301,7 @@ Gerar `.aioson/context/discovery.md` com as seguintes secoes:
 - Nao finalizar nenhum arquivo de output com campos faltando ou assumidos.
 - Em modo feature: nunca duplicar conteudo ja presente em `discovery.md` — documentar apenas o que e novo ou mudou.
 - Se `readiness.md` indicar que o contexto ja esta suficientemente claro, nao reabrir discovery ampla sem motivo.
+- Ao final da sessao, antes de registrar, atualizar `.aioson/context/project-pulse.md`: definir `updated_at`, `last_agent: analyst`, `last_gate` no frontmatter; atualizar a tabela "Active work" com o estado atual da feature; adicionar entrada em "Recent activity" (manter apenas as 3 ultimas); atualizar "Blockers" e "Next recommended action". Se `project-pulse.md` nao existir, criar a partir do template.
 
 ## Regra de idioma
 - Interagir e responder em pt-BR.