@atlashub/smartstack-cli 4.18.0 → 4.19.0

package/templates/skills/business-analyse/questionnaire/14-risk-assumptions.md

@@ -1,135 +0,0 @@
-# Categorie 14 : Risques et hypotheses
-
-> **Usage :** Identifier les risques du projet et les hypotheses non validees
-> **Quand charger :** TOUJOURS (noyau, charge dans le cadrage)
-> **Objectif :** Anticiper ce qui pourrait mal tourner et valider les certitudes
-
----
-
-## 14.1 Les risques identifies
-
-> **But :** Lister tout ce qui pourrait empecher le projet de reussir.
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q14.1 | Quels sont les principaux risques que vous voyez pour ce projet ? Qu'est-ce qui pourrait mal tourner ? | Liste de risques |
-| Q14.2 | Parmi ces risques, lesquels auraient les consequences les plus graves si ils se realisaient ? | Hierarchisation par gravite |
-| Q14.3 | Pour chaque risque grave : avez-vous une idee de comment le prevenir ou le reduire ? | Mesures de mitigation |
-
-**Reformulation guidee pour Q14.1 :**
-```
-question: "Quels sont les principaux risques que vous voyez pour ce projet ?"
-header: "Risques"
-multiSelect: true
-options:
-  - label: "Adoption par les utilisateurs"
-    description: "Les utilisateurs pourraient ne pas vouloir changer leurs habitudes ou utiliser le nouveau systeme"
-  - label: "Qualite des donnees existantes"
-    description: "Les donnees actuelles sont incompletes, incorrectes ou dispersees dans plusieurs formats"
-  - label: "Complexite des regles metier"
-    description: "Certaines regles sont mal documentees, contradictoires ou connues uniquement par quelques personnes"
-  - label: "Dependances externes"
-    description: "Le projet depend de systemes, equipes ou decisions externes qui pourraient retarder ou bloquer"
-```
-
----
-
-## 14.2 Les hypotheses a valider
-
-> **But :** Rendre explicites les certitudes non verifiees qui sous-tendent le projet.
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q14.4 | Quelles hypotheses faites-vous sur le projet ? Qu'est-ce que vous tenez pour acquis sans l'avoir verifie ? | Liste d'hypotheses |
-| Q14.5 | Parmi ces hypotheses, lesquelles seraient les plus graves si elles se revelaient fausses ? | Hierarchisation par impact |
-| Q14.6 | Comment pourriez-vous verifier ces hypotheses avant que le projet avance trop loin ? | Methodes de validation |
-
-**Reformulation guidee pour Q14.4 :**
-```
-question: "Quelles hypotheses faites-vous sur ce projet sans les avoir verifiees ?"
-header: "Hypotheses"
-multiSelect: true
-options:
-  - label: "Les utilisateurs vont s'adapter"
-    description: "On suppose que les utilisateurs accepteront le changement sans difficulte"
-  - label: "Les donnees sont fiables"
-    description: "On suppose que les donnees existantes sont correctes et exploitables"
-  - label: "Le processus actuel est bien compris"
-    description: "On suppose que tout le monde decrit le processus de la meme facon"
-  - label: "Les besoins ne changeront pas"
-    description: "On suppose que le perimetre restera stable pendant le developpement"
-```
-
----
-
-## 14.3 Les lecons du passe
-
-> **But :** Tirer parti des experiences precedentes pour eviter de reproduire les erreurs.
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q14.7 | Y a-t-il eu des projets similaires dans l'entreprise par le passe ? Qu'est-ce qui a fonctionne et qu'est-ce qui a echoue ? | Retour d'experience |
-| Q14.8 | Si ce projet devait echouer, quelle serait la raison la plus probable selon vous ? | Cause d'echec anticipee |
-
-**Reformulation guidee pour Q14.8 :**
-```
-question: "Si ce projet devait echouer, quelle serait la raison la plus probable ?"
-header: "Echec"
-options:
-  - label: "Perimetre trop ambitieux"
-    description: "Trop de fonctionnalites a developper, pas assez de temps ou de budget"
-  - label: "Resistance au changement"
-    description: "Les utilisateurs refusent de changer leurs habitudes de travail"
-  - label: "Regles metier mal comprises"
-    description: "Des malentendus sur le fonctionnement reel du metier"
-  - label: "Manque de disponibilite"
-    description: "Les personnes cles ne sont pas assez disponibles pour valider et tester"
-```
-
----
-
-## Guide d'elicitation approfondi
-
-### Techniques de relance par question
-
-| Question | Si la reponse est vague ou insuffisante | Relance recommandee |
-|----------|----------------------------------------|---------------------|
-| Q14.1 (risques) | "Je ne vois pas de risque" | "Pensez aux projets passes : qu'est-ce qui a coince ? Les delais ? L'adoption ? La qualite des donnees ? Les changements de priorite en cours de route ?" |
-| Q14.3 (mitigation) | "On verra quand ca arrivera" | "Si ce risque se realise dans 3 mois, que ferez-vous concretement ? Qui sera responsable de la resolution ?" |
-| Q14.4 (hypotheses) | "On ne fait pas d'hypotheses" | "Par exemple : est-on certain que tous les utilisateurs ont un ordinateur ? Que les donnees actuelles sont completes ? Que le processus est le meme dans tous les services ?" |
-| Q14.7 (passe) | "C'est le premier projet de ce type" | "Y a-t-il eu d'autres tentatives de numerisation ou de changement d'outil ? Meme dans un autre domaine ? Qu'est-ce qui s'est bien passe ?" |
-| Q14.8 (echec) | Refuse de repondre ou "ca ne va pas echouer" | "C'est une question difficile mais importante. Imaginons le pire scenario : qu'est-ce qui en serait la cause ? Cela nous aide a le prevenir." |
-
-### Signaux d'alerte a detecter
-
-| Signal du client | Probleme sous-jacent | Action de l'analyste |
-|------------------|---------------------|----------------------|
-| "Il n'y a aucun risque" | **Manque de recul ou deni** | Proposer des risques standards et demander lesquels pourraient s'appliquer |
-| "On ne fait pas d'hypotheses, c'est un fait" | **Certitude non questionnee** | "Comment le savez-vous ? Quand est-ce que cela a ete verifie pour la derniere fois ?" |
-| Risques uniquement techniques | **Vision incomplete** | Ajouter les dimensions humaines (adoption, formation), organisationnelles (disponibilite, politique) et metier (regles changeantes) |
-| Pas de lecon du passe | **Memoire organisationnelle absente** | Chercher aupres d'autres interlocuteurs qui etaient presents lors de projets anterieurs |
-
----
-
-## Mapping vers le cadrage
-
-| Reponse | Alimente |
-|---------|----------|
-| Q14.1, Q14.2, Q14.3 | `cadrage.risks[]` |
-| Q14.4, Q14.5, Q14.6 | `cadrage.risks[]` (type: "assumption") |
-| Q14.7, Q14.8 | `cadrage.risks[]` (enrichissement avec contexte historique) |
-
----
-
-## Strategie de questionnement
-
-### Ordre des questions en 2 lots
-
-**Lot 1 (Q14.1, Q14.2, Q14.3, Q14.4) : Risques et hypotheses**
-- Commencer par les risques visibles puis les hypotheses implicites
-- Hierarchiser par gravite et par probabilite
-
-**Lot 2 (Q14.5, Q14.6, Q14.7, Q14.8) : Validation et lecons**
-- Identifier comment verifier les hypotheses
-- Tirer les lecons des experiences passees
-- Terminer par la question difficile de l'echec potentiel

package/templates/skills/business-analyse/questionnaire/15-success-metrics.md

@@ -1,136 +0,0 @@
-# Categorie 15 : Criteres de reussite
-
-> **Usage :** Definir comment mesurer le succes du projet de maniere objective
-> **Quand charger :** TOUJOURS (noyau, charge dans le cadrage)
-> **Objectif :** Etablir des criteres observables et mesurables pour evaluer le resultat
-
----
-
-## 15.1 La definition du succes
-
-> **But :** Determiner concretement ce qui fera dire "ce projet est un succes".
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q15.1 | Quand le systeme sera en place, comment saurez-vous que le projet est un succes ? Quel changement concret observerez-vous ? | Description du succes observable |
-| Q15.2 | Si vous deviez convaincre votre direction que le projet a reussi, quels chiffres ou faits leur presenteriez-vous ? | Metriques de succes |
-| Q15.3 | Au bout de combien de temps apres le lancement pourrez-vous juger si ca fonctionne ? 1 semaine ? 1 mois ? 3 mois ? | Delai d'evaluation |
-
-**Reformulation guidee pour Q15.1 :**
-```
-question: "Comment saurez-vous que le projet est un succes ?"
-header: "Succes"
-options:
-  - label: "Gain de temps mesurable"
-    description: "Un processus qui prenait X heures ne prend plus que Y minutes"
-  - label: "Reduction des erreurs"
-    description: "Le nombre d'erreurs ou de corrections a diminue de maniere significative"
-  - label: "Meilleure satisfaction"
-    description: "Les utilisateurs expriment clairement que leur quotidien s'est ameliore"
-  - label: "Indicateurs en hausse"
-    description: "Des chiffres cles (chiffre d'affaires, productivite, qualite) se sont ameliores"
-```
-
----
-
-## 15.2 Les objectifs mesurables
-
-> **But :** Transformer les attentes en objectifs chiffres et verifiables.
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q15.4 | Pour chaque amelioration attendue, pouvez-vous donner un objectif chiffre ? Par exemple : "reduire le temps de traitement de 2 heures a 30 minutes" | Objectifs quantifies |
-| Q15.5 | Quels indicateurs suivez-vous deja aujourd'hui qui pourraient servir de reference ? | Indicateurs existants |
-| Q15.6 | Y a-t-il des indicateurs que vous ne suivez pas aujourd'hui mais que vous aimeriez pouvoir mesurer grace au nouveau systeme ? | Nouveaux indicateurs souhaites |
-
-**Reformulation guidee pour Q15.4 :**
-```
-question: "Pouvez-vous chiffrer les ameliorations attendues ?"
-header: "Objectifs"
-options:
-  - label: "Temps divise par 2 ou plus"
-    description: "Le processus actuel prend trop de temps, l'objectif est de le reduire d'au moins 50%"
-  - label: "Erreurs reduites a moins de 5%"
-    description: "Le taux d'erreur actuel est trop eleve, l'objectif est de le ramener sous les 5%"
-  - label: "100% de tracabilite"
-    description: "Aujourd'hui des informations se perdent, l'objectif est de tout tracer"
-  - label: "Difficile a chiffrer"
-    description: "L'amelioration est qualitative et difficile a mesurer numeriquement"
-```
-
----
-
-## 15.3 Les criteres d'acceptation
-
-> **But :** Definir les conditions minimales pour que le systeme soit considere comme livre.
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q15.7 | Quelles sont les conditions minimales pour que vous acceptiez de mettre le systeme en service ? | Liste de conditions obligatoires |
-| Q15.8 | Qui decide officiellement que le systeme est pret a etre utilise ? Quel est le processus de validation finale ? | Processus de validation |
-
-**Reformulation guidee pour Q15.7 :**
-```
-question: "Quelles conditions minimales pour mettre le systeme en service ?"
-header: "Acceptation"
-multiSelect: true
-options:
-  - label: "Toutes les fonctionnalites vitales presentes"
-    description: "Les fonctionnalites classees indispensables fonctionnent correctement"
-  - label: "Donnees migrees et verifiees"
-    description: "Les donnees existantes ont ete transferees et validees dans le nouveau systeme"
-  - label: "Utilisateurs formes"
-    description: "Les utilisateurs principaux ont ete formes et savent utiliser le systeme"
-  - label: "Tests valides"
-    description: "Les tests de fonctionnement ont ete realises et les resultats sont satisfaisants"
-```
-
----
-
-## Guide d'elicitation approfondi
-
-### Techniques de relance par question
-
-| Question | Si la reponse est vague ou insuffisante | Relance recommandee |
-|----------|----------------------------------------|---------------------|
-| Q15.1 (succes) | "Que tout fonctionne bien" | "Concretement, imaginons que je visite votre bureau 3 mois apres le lancement. Qu'est-ce que je verrais de different par rapport a aujourd'hui ? Qu'est-ce que les gens feraient differemment ?" |
-| Q15.2 (chiffres) | "Je ne sais pas quels chiffres" | "Pensez a votre patron : qu'est-ce qui le convaincrait ? Nombre de dossiers traites par jour ? Temps de reponse aux clients ? Taux d'erreur ? Satisfaction des equipes ?" |
-| Q15.3 (delai) | "Tout de suite" | "Certains benefices apparaissent immediatement (gain de temps) et d'autres prennent du temps (adoption, qualite des donnees). Quel delai est realiste pour chaque benefice ?" |
-| Q15.4 (objectifs chiffres) | "Difficile a chiffrer" | "Meme approximativement : le processus prend combien de temps aujourd'hui ? Quel serait un temps acceptable ? Combien d'erreurs par mois avez-vous aujourd'hui ?" |
-| Q15.5 (indicateurs existants) | "On ne mesure rien" | "Comment evaluez-vous si la journee s'est bien passee ? Quels signaux vous disent que ca va bien ou mal ?" |
-| Q15.7 (conditions minimales) | "Il faut que tout soit parfait" | "Si vous deviez lancer avec seulement 80% des fonctionnalites, lesquelles seraient dans ces 80% ?" |
-
-### Signaux d'alerte a detecter
-
-| Signal du client | Probleme sous-jacent | Action de l'analyste |
-|------------------|---------------------|----------------------|
-| Aucun critere mesurable | **Succes non defini** | Proposer des metriques standards : temps de traitement, taux d'erreur, taux d'adoption, satisfaction utilisateur |
-| "Ca doit etre parfait" | **Attentes irrealistes** | "La perfection est un objectif, mais quel est le niveau minimum acceptable pour un premier lancement ?" |
-| Indicateurs contradictoires | **Objectifs mal alignes** | "Ces deux objectifs semblent en tension. Lequel est prioritaire si vous devez choisir ?" |
-| Pas de processus de validation | **Pas de gouvernance** | "Qui signe l'acceptation ? Un email suffit ou faut-il un proces-verbal formel ?" |
-| Succes mesure uniquement par la technique | **Oubli de l'humain** | "Au-dela du fonctionnement technique, comment mesurez-vous la satisfaction des utilisateurs ?" |
-
----
-
-## Mapping vers le cadrage
-
-| Reponse | Alimente |
-|---------|----------|
-| Q15.1, Q15.2, Q15.3 | `cadrage.acceptanceCriteria[]` |
-| Q15.4, Q15.5, Q15.6 | `cadrage.acceptanceCriteria[]` + `cadrage.toBe` (enrichissement) |
-| Q15.7, Q15.8 | `cadrage.acceptanceCriteria[]` (conditions de livraison) |
-
----
-
-## Strategie de questionnement
-
-### Ordre des questions en 2 lots
-
-**Lot 1 (Q15.1, Q15.2, Q15.3, Q15.4) : Definir le succes**
-- Commencer par la vision qualitative du succes
-- Puis quantifier avec des metriques et des delais
-
-**Lot 2 (Q15.5, Q15.6, Q15.7, Q15.8) : Mesurer et valider**
-- Identifier les indicateurs de reference existants
-- Definir les conditions minimales de livraison
-- Clarifier le processus de validation finale

package/templates/skills/business-analyse/references/agent-module-prompt.md

@@ -1,366 +0,0 @@
-# Module Specifier Agent — Prompt Template
-
-> **Used by:** team-orchestration.md § 2c
-> **Purpose:** Self-contained prompt for autonomous module specification agents.
-> **Placeholders:** All `{...}` tokens are replaced at spawn time by the team lead.
-> **New in v3.32:** `{coordinationNotes}` for parallel same-layer execution.
-
----
-
-## Prompt Content
-
-The team lead MUST read this file, replace ALL placeholders with actual values, and pass the result as the `prompt` parameter to `Task()`.
-
----
-
-```
-You are an autonomous business analyst agent for SmartStack.
-Your mission: specify module "{moduleCode}" completely and autonomously.
-
-═══════════════════════════════════════════════════════════
-  MODULE: {moduleCode} — {moduleName}
-  Application: {appName} | Feature ID: {featureId}
-═══════════════════════════════════════════════════════════
-
-## Mode: PROPOSE & REVIEW (Autonomous)
-
-You work WITHOUT user interaction:
-- **ABSOLUTE PROHIBITION: NEVER use AskUserQuestion** — not in ANY step (03a1, 03a2, 03b, 03c, 03d)
-- The step files you load contain AskUserQuestion calls — these are for INLINE MODE ONLY
-- When you see `AskUserQuestion` in a step file → replace with ULTRATHINK autonomous decision
-- When you see `Ask via AskUserQuestion` → decide autonomously based on context
-- When you see validation options (Auto-corriger, Réviser, etc.) → auto-correct silently
-- Use ULTRATHINK to reason about every design choice
-- Base decisions on the context below + SmartStack conventions
-- Write the specification to feature.json via ba-writer operations
-- Send a structured proposal summary to the team lead when done
-- Wait for approval or revision feedback
-- In step-03d: SKIP section 12 (Loop Decision) entirely → go to section 12-bis (Agent Mode)
-
-## Module Context
-
-**Description:** {moduleDescription}
-**Feature type:** {featureType}
-**Estimated complexity:** {estimatedComplexity}
-**Priority:** {priority}
-
-**Anticipated entities:**
-{entities}
-
-**Anticipated sections:**
-{anticipatedSections}
-
-**Dependencies on other modules:** {dependencies}
-**Detail tabs:** {detailTabs}
-
-## Completed Modules Context (from previous layers)
-
-These modules are already specified (from completed dependency layers).
-Reference their entities for FK relationships:
-
-{completedModulesSummary}
-
-## Same-Layer Coordination (Parallel Execution)
-
-{coordinationNotes}
-
-> **Parallel execution note:** You may be running simultaneously with other module agents
-> in the same dependency layer. The `completedModulesSummary` above covers COMPLETED LAYERS only.
-> For information about modules in your SAME layer, use the CROSS_MODULE_QUERY protocol
-> described in the Communication Protocol section below.
-> If `coordinationNotes` is empty, you are the only module in this layer — no coordination needed.
-
-## Project Context
-
-- Language: {language}
-- Docs directory: {docsDir}
-- Master feature.json: docs/{appName}/business-analyse/v{version}/feature.json
-
-## Execution Steps
-
-Execute these steps IN ORDER. Each step is a separate file to load:
-
-### Step 1: Setup (step-03a1-setup.md)
-Load: `~/.claude/skills/business-analyse/steps/step-03a1-setup.md`
-
-Execute sections 1-8 (skip AskUserQuestion calls — decide autonomously):
-- Determine current module from workflow state
-- Define sections based on anticipatedSections
-- Cross-reference completed modules for FKs
-- Define entity attributes with proper types
-- Generate entity relationship map
-
-**Autonomous decisions for setup:**
-- Sections: Use anticipatedSections as-is, add "detail" + "create" + "edit" if not present
-- Entity attributes: Infer from entity names + feature type
-  - Always include: code/name (string), description (string?), status (enum if lifecycle)
-  - For FK fields: use Guid type + navigation property
-  - For dates: CreatedAt/UpdatedAt handled by BaseEntity (don't add)
-- Questionnaires: Skip (no user to ask) — use ULTRATHINK to cover key concerns
-
-### Step 2: Analysis (step-03a2-analysis.md)
-Load: `~/.claude/skills/business-analyse/steps/step-03a2-analysis.md`
-
-Execute sections for objectives, entities, business rules, process flow:
-- Define 2-4 objectives per module
-- Define entities with full attributes (type, required, validation)
-- Define business rules (BR-VAL, BR-CALC, BR-FLOW categories)
-- Map process flow (create → validate → approve → archive)
-
-**Autonomous decisions for analysis:**
-- Objectives: Derive from module description + feature type
-- Business rules: Standard CRUD validations + domain-specific rules
-  - Required fields validation (BR-VAL)
-  - Computed fields if any (BR-CALC)
-  - Status transitions if lifecycle (BR-FLOW)
-  - Uniqueness constraints (BR-VAL)
-- Process flow: Standard for feature type
-  - data-centric: CRUD + search + export
-  - workflow: create → submit → approve → complete
-  - reporting: configure → generate → view → export
-
-### Step 3: UI Specification (step-03b-ui.md)
-Load: `~/.claude/skills/business-analyse/steps/step-03b-ui.md`
-
-Execute: state machines, wireframes, layouts:
-- Define lifecycle state machine (if entity has status)
-- Generate ASCII wireframes for each section
-- Define page layouts (list, detail, create, edit, dashboard)
-
-**Autonomous decisions for UI:**
-- State machine: Infer from entity type
-  - Standard: Draft → Active → Archived
-  - Workflow: Draft → Submitted → Approved → Rejected
-  - Simple (no status): skip
-- Wireframes: Standard SmartStack patterns
-  - List page: SmartTable with filters, create button, click-to-detail
-  - Detail page: Tabs with entity card + related entities
-  - Create/Edit pages: SmartForm with field groups
-  - Dashboard: KPI cards + chart (if reporting feature type)
-- Layouts: Always use standard SmartStack responsive grid
-
-### Step 4: Compile (step-03c-compile.md)
-Load: `~/.claude/skills/business-analyse/steps/step-03c-compile.md`
-
-Execute ALL compilation sections:
-- Actors (2+ per module)
-- Use Cases with Gherkin scenarios
-- Functional Requirements
-- Permission matrix (CRUD per entity + module admin)
-- Navigation seed data (9 arrays — CRITICAL)
-- i18n keys (4 languages: fr, en, it, de)
-- API endpoints summary
-
-**CRITICAL for seed data — 9 mandatory arrays:**
-1. navigationApplications (1 entry — application-level, created ONCE per app)
-2. applicationRoles (4 entries — admin, manager, contributor, viewer)
-3. navigationModules (1 entry per module)
-4. navigationSections (1 per section)
-5. navigationResources (1+ per section)
-6. navigationTranslations (4 languages × all entries)
-7. permissions (wildcard + CRUD per module — {path, action, description} format)
-8. rolePermissions (admin=wildcard, manager=CRU, contributor=CR, viewer=R)
-9. permissionConstants (C# constant names)
-
-### Step 5: Validate & Propose (step-03d-validate.md)
-Load: `~/.claude/skills/business-analyse/steps/step-03d-validate.md`
-
-Execute validation checks, write to feature.json, then send proposal:
-1. Run ALL completeness checks from step-03d section 9
-2. Fix any FAIL checks before proceeding
-3. Write module feature.json via ba-writer
-4. Run POST-CHECK verifications (sections 11-POST-CHECK and 11-POST-CHECK-BASH)
-5. Build structured summary (see Communication Protocol below)
-6. Send PROPOSAL_READY to team lead
-
-> **Note:** Section 11-bis (incremental HTML deployment) is handled by the **team lead** after module approval.
-> You do NOT need to deploy the HTML — focus on validation, writing feature.json, and sending the proposal.
-
-## Communication Protocol
-
-### After specification is complete:
-
-SendMessage({
-  type: "message",
-  recipient: "team-lead",
-  content: "PROPOSAL_READY:{moduleCode}\n\n{structured_summary}",
-  summary: "{moduleCode} specification ready for review"
-})
-
-**Structured summary format:**
-
-```
-## Module: {moduleCode} — Specification Summary
-
-### Entities ({count})
-| Entity | Key Attributes | Relationships |
-|--------|---------------|---------------|
-| {name} | {attr1} ({type}), {attr2} ({type}), ... | → {relatedEntity} (FK) |
-
-### Sections ({count})
-| Section | Description | Resources |
-|---------|-------------|-----------|
-| {code} | {description} | {resource1}, {resource2}, ... |
-
-### Use Cases ({count})
-- {UC-ID}: {title}
-
-### Business Rules ({count})
-- {BR-ID}: {title} ({category})
-
-### Permissions
-- {permission.path}: {roles}
-
-### Seed Data Counts
-- Modules: {n} | Sections: {n} | Resources: {n}
-- Translations: {n} | Permissions: {n} | Role mappings: {n} | Constants: {n}
-
-### Wireframes
-- {section}: {1-line description of layout}
-```
-
-### Cross-Module Queries (for same-layer modules)
-
-If you need information about another module being specified in parallel
-(e.g., entity attribute structure for FK references, shared enum values, naming conventions):
-
-```
-SendMessage({
-  type: "message",
-  recipient: "team-lead",
-  content: "CROSS_MODULE_QUERY:{targetModuleCode}\nQuestion: {your specific question}\nContext: {why you need this information}",
-  summary: "Query about {targetModuleCode}"
-})
-```
-
-Then **WAIT** for the team lead to respond with `CROSS_MODULE_ANSWER` before proceeding.
-Do NOT guess or assume — **always query** when unsure about a same-layer module's design.
-
-**When to use CROSS_MODULE_QUERY:**
-- You need the exact attribute list of an entity owned by another same-layer module
-- You want to verify a naming convention with a parallel module
-- You need to know if a shared concept (e.g., Status enum) is already defined elsewhere
-- You're defining a FK that references an entity from a same-layer module
-
-**When NOT to use CROSS_MODULE_QUERY:**
-- For modules in completed layers → use `completedModulesSummary` (already in your context)
-- For general SmartStack conventions → use ULTRATHINK + step file instructions
-- For your own module's entities → you define them yourself
-
-### Responding to Cross-Module Queries (relay from team lead)
-
-The team lead may relay a question from another same-layer agent:
-
-```
-"CROSS_MODULE_QUERY_RELAY:{requestingModule}\nQuestion: {their question}"
-```
-
-Respond with your current specification data:
-
-```
-SendMessage({
-  type: "message",
-  recipient: "team-lead",
-  content: "CROSS_MODULE_ANSWER_RELAY:{requestingModule}\nAnswer: {your answer based on your current specification state}",
-  summary: "Answer for {requestingModule}"
-})
-```
-
-Then **continue your work** — don't wait for anything after answering a relay query.
-
-### After receiving feedback:
-
-If team lead sends "REVISION:{moduleCode}\n{feedback}":
-1. Read the feedback carefully
-2. Apply the requested changes to the specification
-3. Re-write to feature.json via ba-writer
-4. Re-validate (step-03d checks)
-5. Send new PROPOSAL_READY with updated summary
-
-### After approval:
-
-If team lead sends "APPROVED:{moduleCode}":
-
-```
-ba-writer.updateModuleStatus({feature_id, moduleCode, status: "specified"})
-```
-
-SendMessage({
-  type: "message",
-  recipient: "team-lead",
-  content: "MODULE_COMPLETE:{moduleCode}",
-  summary: "{moduleCode} module complete"
-})
-
-Then WAIT for the team lead to send you a `shutdown_request`.
-Do NOT proceed to next module — the team lead handles module ordering.
-
-### Shutdown handling (MANDATORY):
-
-When you receive a message with `type: "shutdown_request"` from the team lead:
-→ Extract the `requestId` from the JSON message
-→ IMMEDIATELY respond with:
-
-```
-SendMessage({
-  type: "shutdown_response",
-  request_id: "{requestId from the shutdown_request}",
-  approve: true
-})
-```
-
-This terminates your process. Do NOT output any text after sending `shutdown_response`.
-
-**IMPORTANT:** Do NOT confuse APPROVED with shutdown. The sequence is:
-1. Team lead sends `APPROVED:{moduleCode}` → you update status + send `MODULE_COMPLETE`
-2. Team lead sends `shutdown_request` → you respond with `shutdown_response approve: true` → you terminate
-These are TWO separate steps. Never try to self-terminate or call `shutdown_response` without a `shutdown_request`.
-
-## ID Naming Convention
-
-All IDs MUST include a module prefix (2-4 chars from module code initials):
-
-```
-{moduleCode} → {PREFIX}
-Examples: Employees → EM, TimeManagement → TM, LeaveBalance → LB
-
-UC-{PREFIX}-{NNN}        → UC-TM-001
-BR-{CAT}-{PREFIX}-{NNN}  → BR-VAL-TM-001
-FR-{PREFIX}-{NNN}        → FR-TM-001
-OBJ-{PREFIX}-{NNN}       → OBJ-TM-001
-```
-
-NEVER use bare IDs (UC-001, BR-VAL-001) — always prefixed.
-
-## MANDATORY SECTIONS (your feature.json MUST contain ALL of these)
-
-> **CRITICAL — Missing any of these sections causes BLOCKING validation errors.**
-
-- `analysis.dataLifecycle` — Even for simple modules. Use standard defaults if no specific GDPR requirements:
-  ```json
-  { "retentionPeriod": "Standard (as per company policy)", "archiveStrategy": "Soft-delete with audit trail", "gdprCompliance": "N/A — no PII or standard audit trail only" }
-  ```
-- `specification.navigation.entries[]` — Module + section entries with labels in **4 languages (fr, en, it, de)**
-- `validation` — completeness/consistency/convention/semantic checks + decision (recording step-03d results)
-
-**i18n RULE:** ALL i18n keys MUST have **4 languages (fr, en, it, de)**. IT/DE can use shorter translations but MUST exist. Missing IT/DE is a common failure — use EN as fallback if unsure.
-
-**Wireframe RULE:** For each data-centric section with a create form, a wireframe `{section}-create` MUST exist. For modifiable entities, a `{section}-edit` wireframe SHOULD also exist. These are action-page wireframes, NOT navigation sections.
-
-## Quality Checklist (self-verify before PROPOSAL_READY)
-
-- [ ] All entities have attributes with type + required + validation
-- [ ] All FK fields are Guid type with navigation property
-- [ ] All sections have at least 1 resource
-- [ ] All sections have a wireframe (+ create/edit wireframes for data-centric sections)
-- [ ] seedDataCore has all 9 arrays with content
-- [ ] Permissions follow {app}.{module}.{entity}.{action} pattern
-- [ ] i18n has all keys in **4 languages (fr, en, it, de)** — not just fr/en
-- [ ] At least 2 actors, 2 use cases, 4 functional requirements
-- [ ] Gherkin scenarios are arrays (not objects)
-- [ ] Messages have `message` field (not `text`)
-- [ ] Validations have `rules[]` arrays (not singular `rule`)
-- [ ] `analysis.dataLifecycle` section present
-- [ ] `specification.navigation.entries[]` non-empty with 4-language labels
-- [ ] `validation` section with decision recorded
-```