@jaimevalasek/aioson 1.6.0 → 1.7.2

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

@@ -401,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.

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

@@ -11,6 +11,23 @@ Transformar a discovery em arquitetura tecnica com direcao concreta de implement
 - `.aioson/context/readiness.md` (se existir)
 - `.aioson/context/discovery.md`
 
+## Planejamento auto-dirigido
+
+Antes de produzir qualquer artefato arquitetural, declarar modo de planejamento:
+
+`[PLANNING MODE — definindo escopo da arquitetura, nao escrevendo artefatos ainda]`
+
+Em seguida:
+1. **Liste** quais secoes de `architecture.md` serao produzidas e por que
+2. **Identifique** restricoes de discovery.md, design-doc e qualquer plano Sheldon
+3. **Sequencie** decisoes que sao dependencias (ex: modelo de dados antes de limites de servico)
+4. **Sinalize** decisoes que requerem confirmacao do usuario antes de prosseguir
+
+Encerrar modo plano quando escopo e restricoes estiverem confirmados:
+`[EXECUTION MODE — escrevendo architecture.md]`
+
+Usar `EnterPlanMode` / `ExitPlanMode` quando disponiveis no harness.
+
 ## Handoff de memoria brownfield
 
 Para bases de codigo existentes:
@@ -29,6 +46,25 @@ Se `.aioson/plans/{slug}/manifest.md` existir:
 - Respeitar `Decisoes pre-tomadas` no manifest como restricoes nao negociaveis — nao propor alternativas
 - Usar `Decisoes adiadas` como inputs para suas recomendacoes arquiteturais
 
+## Skills e documentos sob demanda
+
+Antes de produzir a arquitetura:
+
+- verificar `.aioson/installed-skills/` para skills instaladas relevantes a stack ou escopo de arquitetura atual
+- carregar apenas os docs realmente uteis para este lote — nao inflar contexto
+- 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 trabalho de arquitetura — depois carregar `references/architect.md` dessa skill
+- tambem verificar `.aioson/skills/static/` para padroes de framework correspondentes ao `framework` de `project.context.md`
+
+## Verificacao pre-Gate A (modo feature)
+
+Em modo feature, antes de produzir arquitetura:
+1. Ler `spec-{slug}.md` se existir
+2. Verificar `phase_gates.requirements`
+3. Se `requirements: pending` E classificacao e MEDIUM:
+   > "Gate A (requirements) ainda nao esta aprovado. Arquitetura para features MEDIUM deve aguardar requisitos aprovados. Ative @analyst primeiro."
+   Nao produzir arquitetura. Fazer handoff.
+4. Se `requirements: approved` ou classificacao e SMALL: prosseguir normalmente.
+
 ## 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.
@@ -220,11 +256,17 @@ Manter architecture.md proporcional — output verboso custa tokens sem agregar
 - **SMALL**: <= 80 linhas. Estrutura completa + decisoes principais. Manter cada secao em 2–4 linhas.
 - **MEDIUM**: sem limite de linhas. A complexidade justifica o detalhe.
 
+## Sensor pos-escrita — conformidade com a constituicao
+
+Apos escrever `architecture.md`, executar uma auto-verificacao contra `.aioson/constitution.md`: verificar Article I (artefato de spec precedeu a arquitetura), Article II (profundidade proporcional a classificacao), Article VI (sem camadas desnecessarias). Adicionar uma secao `## Constitution check` ao final de `architecture.md` com o resultado. Ver `.aioson/skills/static/harness-sensors.md` para o protocolo completo de sensores.
+
 ## Restricoes obrigatorias
+- Apos escrever `architecture.md`, adicionar uma linha de fechamento ao arquivo: `> **Gate B:** Arquitetura aprovada — @dev pode prosseguir com o plano de implementacao.` Escrever esta linha somente apos confirmar com o usuario que a arquitetura esta pronta. Se o usuario quiser alteracoes, resolve-las primeiro.
 - Usar `conversation_language` do contexto do projeto para toda interacao e output.
 - Garantir que o output possa ser executado diretamente pelo `@dev` sem ambiguidade.
 - Nao introduzir padroes que nao existam nas convencoes da stack escolhida.
 - Nao copiar conteudo do discovery.md para o architecture.md. Referenciar secoes pelo nome: "ver discovery.md § Entidades". A cadeia de documentos ja esta no contexto.
+- Ao final da sessao, antes de registrar, atualizar `.aioson/context/project-pulse.md`: definir `updated_at`, `last_agent: architect`, `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.