@atlashub/smartstack-cli 2.9.0 → 3.1.0

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

@@ -0,0 +1,136 @@
+# 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/questionnaire.md

@@ -258,66 +258,75 @@
 
 ---
 
-## Conditional Categories (loaded only if relevant)
+## Categories conditionnelles (chargees selon le contexte)
 
-### Category 11: Data Lifecycle (questionnaire/11-data-lifecycle.md)
-> Loaded if: entities have retention/archival/GDPR requirements
+### Categorie 11 : Cycle de vie des donnees (questionnaire/11-data-lifecycle.md)
+> Charge si : les entites ont des exigences de retention, d'archivage ou de conformite
 
-### Category 12: Migration (questionnaire/12-migration.md)
-> Loaded if: data migration from existing system needed
+### Categorie 12 : Migration (questionnaire/12-migration.md)
+> Charge si : migration de donnees depuis un systeme existant
 
-### Category 13: Cross-Module Impact (questionnaire/13-cross-module.md)
-> Loaded if: feature interacts with existing modules
+### Categorie 13 : Impact inter-modules (questionnaire/13-cross-module.md)
+> Charge si : la fonctionnalite interagit avec des modules existants
+
+### Categorie 14 : Risques et hypotheses (questionnaire/14-risk-assumptions.md)
+> Charge : TOUJOURS (noyau, integre au cadrage)
+
+### Categorie 15 : Criteres de reussite (questionnaire/15-success-metrics.md)
+> Charge : TOUJOURS (noyau, integre au cadrage)
 
 ---
 
-## Questionnaire Usage
+## Utilisation des questionnaires
 
-### Phase Mapping
+### Correspondance avec les phases
 
-| Phase | Categories Used |
-|-------|----------------|
-| step-01-cadrage | 00 (if app mode), 01, 02, 03, + conditionals (05, 06, 08, 09, 10) |
-| step-03-specify (per module) | 04, 07, 11, 12, 13 (loaded per module) |
+| Phase | Categories utilisees |
+|-------|---------------------|
+| step-01-cadrage | 00 (si mode application), 01, 02, 03, 14, 15 + conditionnelles (05, 06, 08, 09, 10) |
+| step-03-specify (par module) | 04, 07, 11, 12, 13 (chargees par module) |
 
-### Cadrage Phase
+### Phase de cadrage
 
-1. **Start:** Begin with Category 0 (if application mode), then Category 1 (Business Context)
-2. **Adapt:** Skip questions not relevant to the context
-3. **Deepen:** Ask follow-up questions on vague answers
-4. **Challenge:** Don't accept "we'll see later" on Must-Have
-5. **Batch:** Present 3-4 questions per interaction (AskUserQuestion)
+1. **Debut :** Commencer par la categorie 0 (si mode application), puis la categorie 1 (Contexte metier)
+2. **Adapter :** Sauter les questions non pertinentes selon le contexte
+3. **Approfondir :** Poser des questions de relance sur les reponses vagues
+4. **Challenger :** Ne pas accepter "on verra plus tard" sur les fonctionnalites indispensables
+5. **Par lots :** Presenter 3 a 4 questions par interaction (AskUserQuestion)
+6. **Risques et succes :** TOUJOURS poser les categories 14 et 15 en fin de cadrage
 
-### Follow-up Questions
+### Questions de relance
 
-For each vague answer, use:
-- "Can you give a concrete example?"
-- "How do you measure that today?"
-- "What happens if this rule is not respected?"
-- "Who is impacted by this decision?"
+Pour chaque reponse vague, utiliser :
+- "Pouvez-vous me donner un exemple concret ?"
+- "Comment mesurez-vous cela aujourd'hui ?"
+- "Que se passe-t-il si cette regle n'est pas respectee ?"
+- "Qui est impacte par cette decision ?"
 
-### Dev-Relevance Filter
+### Filtre de pertinence
 
-Each question kept passes this test:
-> "Does the answer change something in the generated code?"
-> Yes -> Keep | No -> Remove
+Chaque question conservee passe ce test :
+> "La reponse change-t-elle quelque chose dans le systeme a construire ?"
+> Oui → Conserver | Non → Supprimer
 
 ---
 
-## Summary
-
-| Category | Questions | Phase | Focus |
-|----------|-----------|-------|-------|
-| 0. Application Identity | 8 | step-01 (app mode) | Application name, modules, roles |
-| 1. Business Context | 4 | step-01 | Problem + AS-IS/TO-BE |
-| 2. Stakeholders | 8 | step-01 | Roles + needs |
-| 3. Functional Scope | 8 | step-01 | Priority levels + flows |
-| 4. Data | 8 | step-03 (per module) | Entities + rules |
-| 5. Integrations | 8 | step-01 (conditional) | Systems + flows |
-| 6. Security | 8 | step-01 (conditional) | Permissions + restrictions |
-| 7. UI | 8 | step-03 (per module) | Screens + experience |
-| 8. Performance | 4 | step-01 (conditional) | Response time + tests |
-| 9. Constraints | 4 | step-01 (conditional) | Tech stack + deps |
-| 10. Documentation | 4 | step-01 (conditional) | User + tech docs |
-| **Total Core** | **72** | | |
-| 11-13 (conditional) | ~24 | step-03 (per module) | Lifecycle, migration, cross-module |
+## Synthese
+
+| Categorie | Questions | Phase | Focus |
+|-----------|-----------|-------|-------|
+| 0. Identite de l'application | 8 | step-01 (mode application) | Nom, domaines, profils |
+| 1. Contexte metier | 12 | step-01 | Probleme, situation actuelle, vision, declencheur |
+| 2. Parties prenantes | 14 | step-01 | Utilisateurs, taches, acces, changement |
+| 3. Perimetre fonctionnel | 12 | step-01 | Priorites, parcours, besoins transversaux |
+| 4. Donnees | 8 | step-03 (par module) | Entites et regles |
+| 5. Integrations | 8 | step-01 (conditionnel) | Systemes et flux |
+| 6. Securite et acces | 8 | step-01 (conditionnel) | Permissions et restrictions |
+| 7. Interface utilisateur | 8 | step-03 (par module) | Ecrans et experience |
+| 8. Performance et qualite | 4 | step-01 (conditionnel) | Temps de reponse et tests |
+| 9. Contraintes | 4 | step-01 (conditionnel) | Technologies et dependances |
+| 10. Documentation | 4 | step-01 (conditionnel) | Guides et formation |
+| 14. Risques et hypotheses | 8 | step-01 | Risques, hypotheses, lecons du passe |
+| 15. Criteres de reussite | 8 | step-01 | Indicateurs de succes, conditions d'acceptation |
+| **Total noyau** | **~86** | | |
+| 11-13 (conditionnel) | ~24 | step-03 (par module) | Cycle de vie, migration, impact inter-modules |

package/templates/skills/business-analyse/steps/step-00-init.md

@@ -36,6 +36,7 @@ context: business
 question_mode: false
 refactor_mode: false
 micro_mode: false
+extract_mode: false
 interactive_mode: false
 application_mode: false    # Multi-module application analysis
 ```
@@ -52,6 +53,7 @@ application_mode: false    # Multi-module application analysis
 | `-r` | `--refactor` | Refactoring mode | next arg = FEAT-ID, remaining = change description |
 | `-m` | `--micro` | Micro feature mode | none |
 | `-i` | `--interactive` | Interactive mode | none |
+| `-x` | `--extract` | Extract mode: import from interactive HTML export | next arg = JSON file path |
 | `-app` | `--application` | Application mode: multi-module analysis | none |
 
 **Remaining arguments after flag removal = feature_description**
@@ -62,6 +64,8 @@ IF question_mode = true:
   use_case = "question"
 ELSE IF refactor_mode = true:
   use_case = "refactoring"
+ELSE IF extract_mode = true:
+  use_case = "extract"
 ELSE IF micro_mode = true:
   use_case = "micro"
 ELSE:
@@ -125,6 +129,23 @@ ba -r FEAT-001 "Add support for multi-language feature names"
 ba -m "Add email notification on approval"
 ```
 
+### Extract Mode (-x)
+```
+1. Parse: extract_mode = true, json_path = first remaining arg
+2. Validate JSON file exists at {json_path}
+3. Read JSON file content
+4. Load step-06-extract.md with {json_data} = parsed content
+5. EXIT after extraction — step-06 handles everything
+```
+
+**Example:**
+```
+ba -x ./docs/business/MyApp/ba-export.json
+```
+
+> **Note:** The JSON file is the export from the interactive HTML document (`ba-interactive.html`).
+> The extract step maps ALL client data to feature.json format with zero information loss.
+
 ### Default Mode (New Feature)
 ```
 1. Set use_case = "new"
@@ -557,17 +578,18 @@ NEXT STEP: step-01-analyse ({use_case} mode)
 
 ## Step 13: Load Next Step
 
-**All modes except question (-q) and micro (-m):**
+**All modes except question (-q), micro (-m), and extract (-x):**
 After showing initialization summary, proceed to `./step-01-cadrage.md`
 
 **Question mode (-q):** EXIT after ba-reader answers the question.
 **Micro mode (-m):** Load `./step-05-handoff.md` directly.
+**Extract mode (-x):** Load `./step-06-extract.md` with `{json_data}` from parsed JSON file.
 
 **Pass context variables:**
 ```yaml
 feature_id: string
 feature_description: string
-use_case: "new" | "question" | "refactoring" | "micro" | "application"
+use_case: "new" | "question" | "refactoring" | "micro" | "extract" | "application"
 application_name: string
 module_name: string
 language: string

package/templates/skills/business-analyse/steps/step-01-cadrage.md

@@ -104,35 +104,46 @@ After each batch: Apply ULTRATHINK + Elicitation Techniques.
 
 ### 4. Core Questionnaires (always)
 
-Load these categories in order:
+Load these categories in order. Each questionnaire contains its own batching strategy and elicitation guide.
 
-**Category 01 - Context** (`questionnaire/01-context.md`)
-- Q1.1-Q1.4: Problem, AS-IS, TO-BE, trigger
-- 1 AskUserQuestion batch
+**Categorie 01 - Contexte metier** (`questionnaire/01-context.md`)
+- Q1.1-Q1.12 : Probleme, situation actuelle, vision, declencheur
+- 3 lots AskUserQuestion (probleme, processus actuel, vision et urgence)
+- ULTRATHINK : Identifier la douleur reelle, pas la solution imaginee
 
-**Category 02 - Stakeholders** (`questionnaire/02-stakeholders.md`)
-- Q2.1-Q2.8: Roles, tasks, frequency, pain points
-- 2 AskUserQuestion batches
-- ULTRATHINK: Map stakeholders to application roles
+**Categorie 02 - Parties prenantes** (`questionnaire/02-stakeholders.md`)
+- Q2.1-Q2.14 : Utilisateurs, taches, acces, conduite du changement
+- 4 lots AskUserQuestion
+- ULTRATHINK : Mapper les parties prenantes vers les profils d'acces
 
-**Category 03 - Scope** (`questionnaire/03-scope.md`)
-- Q3.1-Q3.8: Priority levels (Essentiel/Important/Optionnel/Hors périmètre), flows, errors
-- 2 AskUserQuestion batches
-- ULTRATHINK: Ensure scope items map to modules
+**Categorie 03 - Perimetre fonctionnel** (`questionnaire/03-scope.md`)
+- Q3.1-Q3.12 : Priorites (indispensable/important/optionnel/hors perimetre), parcours, besoins transversaux
+- 3 lots AskUserQuestion
+- ULTRATHINK : S'assurer que le perimetre couvre les besoins identifies
+
+**Categorie 14 - Risques et hypotheses** (`questionnaire/14-risk-assumptions.md`)
+- Q14.1-Q14.8 : Risques, hypotheses non verifiees, lecons du passe
+- 2 lots AskUserQuestion
+- TOUJOURS charge (noyau) - ne jamais sauter cette categorie
+
+**Categorie 15 - Criteres de reussite** (`questionnaire/15-success-metrics.md`)
+- Q15.1-Q15.8 : Definition du succes, objectifs mesurables, conditions d'acceptation
+- 2 lots AskUserQuestion
+- TOUJOURS charge (noyau) - ne jamais sauter cette categorie
 
 ### 5. Conditional Questionnaires
 
 Based on feature description analysis, load additional categories:
 
-| Condition | Category | Questionnaire |
-|-----------|----------|---------------|
-| Security concerns mentioned | 06 | `questionnaire/06-security.md` |
-| Integration with external systems | 05 | `questionnaire/05-integrations.md` |
-| Performance requirements | 08 | `questionnaire/08-performance.md` |
-| Technical constraints | 09 | `questionnaire/09-constraints.md` |
-| Documentation requirements | 10 | `questionnaire/10-documentation.md` |
+| Condition | Categorie | Questionnaire |
+|-----------|-----------|---------------|
+| Securite ou conformite mentionnee | 06 | `questionnaire/06-security.md` |
+| Integration avec des systemes externes | 05 | `questionnaire/05-integrations.md` |
+| Exigences de performance | 08 | `questionnaire/08-performance.md` |
+| Contraintes techniques | 09 | `questionnaire/09-constraints.md` |
+| Besoins de documentation | 10 | `questionnaire/10-documentation.md` |
 
-> **Categories 04 (data), 07 (ui), 11 (data-lifecycle), 12 (migration), 13 (cross-module) are per-module and loaded in step-03.**
+> **Categories 04 (donnees), 07 (interface), 11 (cycle de vie), 12 (migration), 13 (inter-modules) sont par module et chargees dans step-03.**
 
 ### 6. Application Roles Definition
 

package/templates/skills/business-analyse/steps/step-03-specify.md

@@ -447,6 +447,7 @@ For EACH section confirmed in 3a, build the `specification.sections[]` structure
 #### 3b. For Each Section: Generate MANDATORY ASCII Mockup
 
 > **BLOCKING RULE:** Every section MUST have a wireframe. No section proceeds to entity definition (step 6) without a validated mockup stored in `specification.uiWireframes[]`.
+> **HTML INTEGRATION:** These wireframes are also rendered in the interactive HTML document (`ba-interactive.html`) deployed at handoff. The client can review and annotate mockups directly in their browser.
 
 For each confirmed section, generate an ASCII mockup and validate with client:
 
@@ -1262,6 +1263,62 @@ ba-writer.updateStatus({module_feature_id}, "specified")
 ba-writer.updateModuleStatus({feature_id}, {currentModule.code}, "specified")
 ```
 
+### 11-bis. Deploy Incremental Interactive HTML (MANDATORY)
+
+> **After each module is specified, deploy/update the interactive HTML document with all available data.**
+> This allows the client to review completed modules while the next module is being specified.
+> The HTML is incrementally enriched: after module 1, only module 1 specs appear; after module 2, both appear; etc.
+
+**Source:** `html/ba-interactive.html` (relative to skill root = `~/.claude/skills/business-analyse/html/`)
+
+**Destination:** `docs/business/{app}/business-analyse/v{version}/ba-interactive.html`
+
+**Steps:**
+
+1. **Read sources:**
+   - Read the HTML template from skill directory
+   - Read the master feature.json (application level — now updated with current module status)
+   - Read EACH completed module's feature.json (including the one just specified)
+
+2. **Build FEATURE_DATA object:**
+
+   > **Use the EXACT SAME mapping defined in step-05-handoff.md section 9d.**
+   > The mapping is identical — the only difference is that `moduleSpecs` only includes completed modules.
+   > Modules not yet specified will NOT appear in `moduleSpecs` (their entry in `modules[]` will show `status: "pending"`).
+
+   Follow step-05 section 9d "Step 2: Build FEATURE_DATA object" for the complete mapping pseudocode:
+   - `metadata`, `cadrage`, `modules[]`, `dependencies[]` → from master feature.json
+   - `moduleSpecs[moduleCode]` → only for modules with status "specified" (completed so far)
+   - `consolidation` → empty `{ interactions: [], e2eFlows: [] }` (not yet consolidated)
+   - `handoff` → empty `{}` (not yet handed off)
+
+3. **Replace placeholders in template:**
+   - Serialize the FEATURE_DATA object as JSON (2-space indentation)
+   - Replace `{{FEATURE_DATA}}` with the serialized JSON
+   - Replace `{{APPLICATION_NAME}}` → `{application_name}`
+   - Replace `{{APPLICATION_ID}}` → `{feature_id}`
+   - Replace `{{VERSION}}` → `{version}`
+   - Replace `{{CREATED_AT}}` → `{ISO timestamp}`
+
+4. **Write and confirm:**
+
+```
+✓ Interactive HTML updated (incremental):
+  Path: docs/business/{app}/business-analyse/v{version}/ba-interactive.html
+  Modules included: {completedModules.length}/{totalModules} specified
+    - {completedModule1}: {uc_count} UCs, {br_count} BRs, {entity_count} entities
+    - {completedModule2}: ...
+  Remaining: {pendingModules.join(', ')} (will be added after specification)
+  → Client can open in browser to review completed modules now.
+```
+
+> **WHY incremental?** The client doesn't have to wait until handoff to start reviewing.
+> While module 2 is being specified, the client can already give feedback on module 1.
+> Each incremental deployment OVERWRITES the previous HTML (latest state always).
+> The FINAL deployment at step-05 (handoff) will include consolidation and handoff data.
+
+---
+
 ### 12. Loop Decision
 
 ```
@@ -1337,6 +1394,7 @@ Read metadata.workflow.currentModule
 - Client confirmed module specification
 - Module feature.json written
 - Master updated with module status
+- **Interactive HTML deployed/updated with completed module data (incremental)**
 - Loop advanced correctly
 
 ## FAILURE MODES