@atlashub/smartstack-cli 4.18.0 → 4.19.0

package/templates/skills/business-analyse/questionnaire.md

@@ -1,9 +1,9 @@
 # Elicitation Questionnaire - Business Analysis
 
-> **Usage:** Structured questions for step-01-cadrage and step-03a-data
+> **Usage:** Structured questions for step-01-cadrage and step-03-specify
 > **Standard:** BABOK v3 - Elicitation Techniques (Interactive analysis)
 > **Model:** OPUS with ULTRATHINK
-> **Total:** ~68 targeted questions (dev-relevant only)
+> **Total:** ~90 targeted questions across 5 questionnaire files
 
 ---
 
@@ -30,250 +30,15 @@
 
 ---
 
-## Category 0: Application Identity (8 questions)
+## Questionnaire Files (v2)
 
-> **Loaded when:** workflow.mode = "application" (multi-module)
-> **Phase:** step-01-cadrage (before core questionnaires)
-> **File:** `questionnaire/00-application.md`
-
-### 0.1 Application Identity
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q0.1 | Quel est le nom de l'application ? | PascalCase identifier |
-| Q0.2 | En 1-2 phrases, quel est l'objectif principal ? | Free text |
-
-### 0.2 Module Landscape
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q0.3 | Combien de domaines fonctionnels distincts identifiez-vous ? | Number + names |
-| Q0.4 | Lesquels sont indispensables pour la première version ? | List (must-haves) |
-
-### 0.3 Application Roles
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q0.5 | Les 4 rôles standards (Admin, Manager, Contributor, Viewer) conviennent-ils ? | Yes/Customize |
-| Q0.6 | Certains rôles sont-ils spécifiques à certains modules ? | Per-role restrictions |
-
-### 0.4 Cross-Module Expectations
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q0.7 | Quels processus métier traversent plusieurs modules ? | List of E2E flows |
-| Q0.8 | Quel rôle par défaut pour les nouveaux utilisateurs ? | Role selection |
-
----
-
-## Category 1: Business Context (4 questions)
-
-### 1.1 Fundamental Need
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q1.1 | What business problem should this module/feature solve? | Free text |
-| Q1.2 | What is the current situation (AS-IS)? | Description |
-| Q1.3 | What is the target situation (TO-BE)? | Description |
-| Q1.4 | What happens if this module is NOT developed? | Impact |
-
-> **Trimmed:** KPIs, ROI, savings, timeline (project management scope)
-
----
-
-## Category 2: Stakeholders (8 questions)
-
-### 2.1 Identification
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q2.1 | Who are the direct end users? | List of roles |
-| Q2.2 | Who are the indirect beneficiaries? | List |
-| Q2.3 | Who is the sponsor/final decision maker? | Name + role |
-| Q2.4 | Who can block the project? | List + reasons |
-
-### 2.2 Needs by Role
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q2.5 | For each role: What tasks should they accomplish? | Per role |
-| Q2.6 | What frequency of use per role? | Daily/Weekly/Monthly |
-| Q2.7 | What level of technical expertise per role? | Novice/Intermediate/Expert |
-| Q2.8 | What current frustrations per role? | List of pain points |
-
----
-
-## Category 3: Functional Scope (8 questions)
-
-### 3.1 Functionality
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q3.1 | List ESSENTIAL features (Must-Have) | List |
-| Q3.2 | List DESIRED features (Should-Have) | List |
-| Q3.3 | List OPTIONAL features (Could-Have) | List |
-| Q3.4 | What is EXPLICITLY excluded? | List of exclusions |
-
-### 3.2 Business Process
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q3.5 | Describe the main user flow | Steps |
-| Q3.6 | What are the decision points in the flow? | List |
-| Q3.7 | What alternative flows exist? | Per condition |
-| Q3.8 | What are the possible error cases? | List |
-
----
-
-## Category 4: Data (8 questions)
-
-### 4.1 Entities
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q4.1 | What are the main entities handled? | List |
-| Q4.2 | For each entity: important attributes? | Per entity |
-| Q4.3 | What relationships exist between entities? | Text schema |
-| Q4.4 | Expected data volume? | Estimation |
-
-### 4.2 Data Rules
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q4.5 | What validations on data? | List of rules |
-| Q4.6 | Which fields are required vs optional? | Per field |
-| Q4.7 | What specific formats/constraints? | List |
-| Q4.8 | Sensitive data to protect? | List + level |
-
----
-
-## Category 5: Integrations (8 questions)
-
-### 5.1 Existing Systems
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q5.1 | What internal systems should we integrate with? | List |
-| Q5.2 | What external systems? | List |
-| Q5.3 | Existing APIs to use? | Documentation |
-| Q5.4 | Data to import from another system? | List + format |
-
-### 5.2 Data Flows
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q5.5 | Flow direction? (inbound/outbound/bidirectional) | Per system |
-| Q5.6 | Synchronization frequency? | Real-time/Batch |
-| Q5.7 | Data conflict management? | Strategy |
-| Q5.8 | Fallback if external system unavailable? | Behavior |
-
----
-
-## Category 6: Security & Permissions (8 questions)
-
-### 6.1 Access
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q6.1 | Who can VIEW data? | List of roles |
-| Q6.2 | Who can CREATE entries? | List of roles |
-| Q6.3 | Who can MODIFY? | List of roles |
-| Q6.4 | Who can DELETE? | List of roles |
-
-### 6.2 Restrictions
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q6.5 | Geographic restrictions? | Countries/regions |
-| Q6.6 | Time-based restrictions? (hours, periods) | Ranges |
-| Q6.7 | Audit trail required? Which actions? | List |
-| Q6.8 | Regulatory compliance? (GDPR, etc.) | List of standards |
-
----
-
-## Category 7: User Interface (8 questions)
-
-### 7.1 Experience
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q7.1 | Target devices? (desktop, mobile, tablet) | List |
-| Q7.2 | Browsers to support? | List + versions |
-| Q7.3 | Accessibility required? (WCAG level) | A/AA/AAA |
-| Q7.4 | Dark/light mode required? | Yes/No |
-
-### 7.2 Screens
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q7.5 | Main screens needed? | List |
-| Q7.6 | Existing mockups/wireframes? | Documents |
-| Q7.7 | Key information per screen? | Per screen |
-| Q7.8 | Possible actions per screen? | Per screen |
-
----
-
-## Category 8: Performance & Quality (4 questions)
-
-### 8.1 Performance & Quality
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q8.1 | Acceptable response time? | Milliseconds |
-| Q8.2 | Expected load peaks? | When + volume |
-| Q8.3 | Specific tests required? | Types |
-| Q8.4 | Overall acceptance criteria? | List |
-
-> **Trimmed:** Concurrent users, SLA, error rate, test environments (ops/infra scope)
-
----
-
-## Category 9: Constraints (4 questions)
-
-### 9.1 Technical
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q9.1 | Mandated tech stack? | Technologies |
-| Q9.2 | Infrastructure limitations? | Description |
-| Q9.3 | Technology dependencies? | List |
-| Q9.4 | Compatibility constraints? | List |
-
-> **Trimmed:** Budget, deadline, resources, approval process (PM scope)
-
----
-
-## Category 10: Documentation & Support (4 questions)
-
-### 10.1 Documentation
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q10.1 | User documentation needed? | Yes/No + type |
-| Q10.2 | Technical documentation needed? | Yes/No + type |
-| Q10.3 | User training planned? | Plan |
-| Q10.4 | Knowledge base to create? | Scope |
-
-> **Trimmed:** Support level, L1/L2, escalation, monitoring (ops scope)
-
----
-
-## Categories conditionnelles (chargees selon le contexte)
-
-### 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
-
-### Categorie 12 : Migration (questionnaire/12-migration.md)
-> Charge si : migration de donnees depuis un systeme existant
-
-### 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)
+| File | Questions | Phase | Focus |
+|------|-----------|-------|-------|
+| `questionnaire/01-context.md` | ~20 | step-01-cadrage | Problem, current state, vision, triggers, application identity |
+| `questionnaire/02-stakeholders-scope.md` | ~25 | step-01-cadrage | User profiles, priorities, scope boundaries, MoSCoW |
+| `questionnaire/03-data-ui.md` | ~20 | step-03-specify (per module) | Data entities, UI expectations, integrations |
+| `questionnaire/04-risks-metrics.md` | ~15 | step-01-cadrage | Risks, success criteria, constraints, performance |
+| `questionnaire/05-cross-module.md` | ~10 | step-03-specify (conditional) | Cross-module dependencies, shared data, E2E flows |
 
 ---
 
@@ -281,19 +46,24 @@
 
 ### Correspondance avec les phases
 
-| Phase | Categories utilisees |
-|-------|---------------------|
-| step-01-cadrage | 00 (si mode application), 01, 02, 03, 14, 15 + conditionnelles (05, 06, 08, 09, 10) |
-| step-03a-data (par module) | 04, 07, 11, 12, 13 (chargees par module) |
+| Phase | Questionnaires charges |
+|-------|----------------------|
+| step-01-cadrage | 01-context, 02-stakeholders-scope, 04-risks-metrics |
+| step-03-specify (par module) | 03-data-ui, conditionnellement 05-cross-module |
 
-### Phase de cadrage
+### Phase de cadrage (step-01)
 
-1. **Debut :** Commencer par la categorie 0 (si mode application), puis la categorie 1 (Contexte metier)
+1. **Debut :** Commencer par 01-context (contexte metier, identite application)
 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
+6. **Risques et succes :** Charger 04-risks-metrics en fin de cadrage
+
+### Phase de specification (step-03)
+
+1. **Par module :** Charger 03-data-ui pour chaque module en cours de specification
+2. **Cross-module :** Charger 05-cross-module si le module a des dependances identifiees en step-02
 
 ### Questions de relance
 
@@ -307,31 +77,4 @@ Pour chaque reponse vague, utiliser :
 
 Chaque question conservee passe ce test :
 > "La reponse change-t-elle quelque chose dans le systeme a construire ?"
-> Oui → Conserver | Non → Supprimer
-
----
-
-## Synthese
-
-| Categorie | Questions | Phase | Focus |
-|-----------|-----------|-------|-------|
-| 0. Identite de l'application | 18 | step-01 (mode application) | Nom, domaines, profils |
-| 1. Contexte metier | 32 | step-01 | Probleme, situation actuelle, vision, declencheur |
-| 2. Parties prenantes | 33 | step-01 | Utilisateurs, taches, acces, changement |
-| 3. Perimetre fonctionnel | 32 | step-01 | Priorites, parcours, besoins transversaux |
-| 4. Donnees | 15 | step-03 (par module) | Entites et regles |
-| 5. Integrations | 14 | step-01 (conditionnel) | Systemes et flux |
-| 6. Securite et acces | 13 | step-01 (conditionnel) | Permissions et restrictions |
-| 7. Interface utilisateur | 19 | step-03 (par module) | Ecrans et experience |
-| 8. Performance et qualite | 8 | step-01 (conditionnel) | Temps de reponse et tests |
-| 9. Contraintes | 6 | step-01 (conditionnel) | Technologies et dependances |
-| 10. Documentation | 7 | step-01 (conditionnel) | Guides et formation |
-| 11. Cycle de vie donnees | 14 | step-03 (conditionnel) | Retention, archivage, RGPD |
-| 12. Migration et transition | 14 | step-03 (conditionnel) | Donnees existantes, cutover |
-| 13. Impact inter-modules | 14 | step-03 (conditionnel) | Dependances, evenements |
-| 14. Risques et hypotheses | 16 | step-01 | Risques, hypotheses, lecons du passe |
-| 15. Criteres de reussite | 17 | step-01 | Indicateurs de succes, conditions d'acceptation |
-| **Total noyau (01-03, 14-15)** | **130** | | **Toujours charges** |
-| **Total avec app (00)** | **148** | | **Si mode application** |
-| **Total conditionnel (04-13)** | **124** | | **Selon contexte** |
-| **Total maximum possible** | **272** | | **Noyau + app + tous conditionnels** |
+> Oui -> Conserver | Non -> Supprimer

package/templates/skills/business-analyse/react/application-viewer.md

@@ -2,7 +2,7 @@
 
 > **Usage:** React component for application-level BA documentation within SmartStack web app
 > **Route:** `/docs/{app}` (application overview)
-> **Data source:** `docs/{app}/business-analyse/v{X.Y}/feature.json` (scope: "application")
+> **Data source:** `docs/{app}/business-analyse/v{X.Y}/index.json` (scope: "application")
 > **Linked to:** Module viewers at `/docs/{app}/{module}`
 
 ---
@@ -205,7 +205,7 @@ export async function loadApplicationFeature(
   version: string
 ): Promise<ApplicationFeatureJson> {
   const response = await fetch(
-    `/docs/${app}/business-analyse/v${version}/feature.json`
+    `/docs/${app}/business-analyse/v${version}/index.json`
   );
   return response.json();
 }

package/templates/skills/business-analyse/react/components.md

@@ -1,9 +1,9 @@
 # React Components - Business Analyse Viewer
 
-> **Usage:** React component that renders feature.json directly
-> **Loaded in:** step-05b-deploy.md
-> **Data source (module):** `docs/{app}/{module}/business-analyse/v{X.Y}/feature.json`
-> **Data source (application):** `docs/{app}/business-analyse/v{X.Y}/feature.json`
+> **Usage:** React component that renders index.json directly
+> **Loaded in:** step-05-deploy.md
+> **Data source (module):** `docs/{app}/{module}/business-analyse/v{X.Y}/index.json`
+> **Data source (application):** `docs/{app}/business-analyse/v{X.Y}/index.json`
 > **Related:** `react/application-viewer.md` for application-level view
 > **Context7:** /facebook/react, /lucide-icons/lucide-react
 

package/templates/skills/business-analyse/react/i18n-template.md

@@ -3,7 +3,7 @@
 > **Usage:** Translation templates for BusinessAnalyseViewer
 > **Loaded in:** step-04-handoff.md
 > **Languages:** FR (source), EN, IT, DE
-> **Data source:** feature.json sections aligned
+> **Data source:** index.json sections aligned
 
 ---
 

package/templates/skills/business-analyse/react/schema.md

@@ -1,9 +1,9 @@
 # TypeScript Schema - Feature JSON Types
 
-> **Usage:** TypeScript interfaces aligned with feature-schema.json and application-schema.json
-> **Loaded in:** step-05b-deploy.md (for web app rendering)
-> **Source (module):** `docs/{app}/{module}/business-analyse/v{X.Y}/feature.json`
-> **Source (application):** `docs/{app}/business-analyse/v{X.Y}/feature.json`
+> **Usage:** TypeScript interfaces aligned with index.json and application-schema.json
+> **Loaded in:** step-05-deploy.md (for web app rendering)
+> **Source (module):** `docs/{app}/{module}/business-analyse/v{X.Y}/index.json`
+> **Source (application):** `docs/{app}/business-analyse/v{X.Y}/index.json`
 
 ---
 
@@ -13,11 +13,11 @@
 // web/smartstack-web/src/types/docs.ts
 
 // ===================================================================
-// APPLICATION-LEVEL TYPES (master feature.json, scope: "application")
+// APPLICATION-LEVEL TYPES (master index.json, scope: "application")
 // ===================================================================
 
 /**
- * Application-level Feature JSON structure
+ * Application-level index.json structure
  * Matches schemas/application-schema.json
  * Master document for multi-module BA
  */
@@ -180,11 +180,11 @@ export interface E2EFlowStep {
 }
 
 // ===================================================================
-// MODULE-LEVEL TYPES (per-module feature.json, scope: "module")
+// MODULE-LEVEL TYPES (per-module index.json, scope: "module")
 // ===================================================================
 
 /**
- * Module-level Feature JSON structure
+ * Module-level index.json structure
  * Matches schemas/feature-schema.json
  * Progressively enriched by each BA step
  */
@@ -664,7 +664,7 @@ export interface FileSpec {
   linkedFRs?: string[];        // FR-XXX references
   linkedUCs?: string[];        // UC-XXX references
   category?: 'core' | 'business';  // For seedData files
-  source?: string;             // Derivation source in feature.json
+  source?: string;             // Derivation source in index.json
   description?: string;
 }
 
@@ -700,7 +700,7 @@ export interface FeatureSuggestion {
 }
 
 export interface ChangelogEntry {
-  step?: string;               // step-01-analyse, step-02-specify, etc.
+  step?: string;               // step-01-cadrage, step-03-specify, etc.
   version?: string;
   timestamp: string;
   author?: string;
@@ -720,7 +720,7 @@ export interface ChangelogEntry {
 import type { FeatureJson, ApplicationFeatureJson } from '../types/business-analyse';
 
 /**
- * Load module-level feature.json from docs path
+ * Load module-level index.json from docs path
  * The web app reads the JSON directly - no transformation needed
  */
 export async function loadFeature(
@@ -729,20 +729,20 @@ export async function loadFeature(
   version: string
 ): Promise<FeatureJson> {
   const response = await fetch(
-    `/docs/${app}/${module}/business-analyse/v${version}/feature.json`
+    `/docs/${app}/${module}/business-analyse/v${version}/index.json`
   );
   return response.json();
 }
 
 /**
- * Load application-level (master) feature.json
+ * Load application-level (master) index.json
  */
 export async function loadApplicationFeature(
   app: string,
   version: string
 ): Promise<ApplicationFeatureJson> {
   const response = await fetch(
-    `/docs/${app}/business-analyse/v${version}/feature.json`
+    `/docs/${app}/business-analyse/v${version}/index.json`
   );
   return response.json();
 }

package/templates/skills/business-analyse/references/acceptance-criteria.md

@@ -1,8 +1,8 @@
 # Module Acceptance Criteria (Shared Reference)
 
-> **Loaded by:** step-03d-validate (section 11-POST-CHECK-BASH), step-05a-handoff (pre-handoff gate), ralph-loop step-01-task (input validation)
+> **Loaded by:** step-03-specify (post-check), step-05-deploy (pre-handoff gate), ralph-loop step-01-task (input validation)
 > **Purpose:** Define measurable, bash-verifiable acceptance criteria that a module MUST pass before being marked "specified".
-> **Key principle:** These checks read the REAL feature.json file on disk — NOT in-memory data the model "thinks" it wrote.
+> **Key principle:** These checks read the REAL JSON files on disk — NOT in-memory data the model "thinks" it wrote.
 
 ---
 
@@ -38,8 +38,8 @@ All previous checks were **pseudocode interpreted by the model**. The model can
 
 ## Bash Verification Script (node -e)
 
-> **Usage:** Called from step-03d section 11-POST-CHECK-BASH after writing module feature.json.
-> Also callable standalone for debugging: `node -e "..." path/to/feature.json`
+> **Usage:** Called from step-03 post-check after writing module JSON files.
+> Also callable standalone for debugging: `node -e "..." path/to/index.json`
 
 ```bash
 MODULE_JSON="{module_feature_json_path}"
@@ -132,19 +132,19 @@ console.log('PASS: All acceptance criteria met (AC-01 to AC-17)');
 
 ## Integration Points
 
-### 1. step-03d-validate.md (section 11-POST-CHECK-BASH)
+### 1. step-03-specify.md (post-check)
 
-After writing module feature.json, run the bash script above.
+After writing module JSON files, run the bash script above.
 IF FAIL → re-execute section 11 write with corrected data → re-run until PASS.
 
-### 2. step-05a-handoff.md (pre-handoff gate)
+### 2. step-05-deploy.md (pre-handoff gate)
 
-Before writing handoff for each module (section 7a step 3), run the bash script on the module feature.json.
+Before writing handoff for each module, run the bash script on the module index.json.
 IF FAIL → STOP handoff for this module, report which criteria failed.
 
 ### 3. ralph-loop step-01-task.md (input validation)
 
-At PRD load time, run the bash script on each module feature.json.
+At PRD load time, run the bash script on each module index.json.
 IF FAIL → BLOCKING: "Module {name} does not meet acceptance criteria — run /business-analyse to fix".
 This prevents ralph-loop from generating code from incomplete specifications.
 
@@ -154,16 +154,16 @@ This prevents ralph-loop from generating code from incomplete specifications.
 
 | Criterion | Recovery |
 |-----------|----------|
-| AC-01/02 | Re-run step-03a2-analysis (entity definition) |
-| AC-03/04 | Re-run step-03c-compile sections 8b/8c |
-| AC-05/06/07 | Re-run step-03b-ui (wireframe generation) — step-03b now writes intermediately |
-| AC-08 | Re-run step-03b section 3a-bis (section definition) |
-| AC-09 | Re-run step-03c section 8f-bis (seedDataCore transform) |
+| AC-01/02 | Re-run step-03 entity specification |
+| AC-03/04 | Re-run step-03 use case / functional requirements |
+| AC-05/06/07 | Re-run step-03 wireframe generation |
+| AC-08 | Re-run step-03 section definition |
+| AC-09 | Re-run step-03 seedDataCore transform |
 | AC-10 | Auto-fix: wrap in array `[gherkinScenarios]` |
-| AC-11 | Re-run step-03c section 8k |
-| AC-12 | Re-run step-03c section 8i |
-| AC-13 | Re-run step-03c section 8h |
-| AC-14 | Auto-fix: rename title→screen, ascii→mockup (done by step-03c/03d auto-fix) |
-| AC-15 | Auto-fix: wrap string in array `[rules]` (done by step-03c ABSOLUTE FORMAT CHECKS) |
-| AC-16 | Auto-fix: copy `description` → `message` (done by step-03c ABSOLUTE FORMAT CHECKS) |
-| AC-17 | Re-run step-03c section 8g — ensure each gherkin entry has `feature` string + `scenarios` array |
+| AC-11 | Re-run step-03 API endpoints |
+| AC-12 | Re-run step-03 messages |
+| AC-13 | Re-run step-03 validations |
+| AC-14 | Auto-fix: rename title→screen, ascii→mockup |
+| AC-15 | Auto-fix: wrap string in array `[rules]` |
+| AC-16 | Auto-fix: copy `description` → `message` |
+| AC-17 | Re-run step-03 gherkin — ensure each entry has `feature` string + `scenarios` array |

package/templates/skills/business-analyse/references/analysis-semantic-checks.md

@@ -1,10 +1,10 @@
 # Semantic Validation Checks for Analysis
 
-Complete reference for step-04b semantic validation, permission coherence, and complexity assessment.
+Complete reference for step-04 semantic validation, permission coherence, and complexity assessment.
 
 ## Semantic Validation Checks (13 checks total)
 
-Execute for EACH module feature.json:
+Execute for EACH module in step-04:
 
 | # | Check | Rule | Severity |
 |---|-------|------|----------|
@@ -42,7 +42,7 @@ Execute for EACH module feature.json:
 
 ## Complexity Calculation
 
-For each module in feature.json.modules[], calculate:
+For each module in index.json modules[], calculate:
 
 ```json
 {

package/templates/skills/business-analyse/references/compilation-structure-cards.md

@@ -1,6 +1,6 @@
 # Compilation Structure Cards Reference
 
-Exact JSON format templates for specification compilation (step-03c). All data MUST fit these schemas exactly.
+Exact JSON format templates for specification compilation (step-03). All data MUST fit these schemas exactly.
 
 ## STRUCTURE CARD: analysis.entities[].attributes[]
 

package/templates/skills/business-analyse/references/consolidation-structural-checks.md

@@ -1,6 +1,6 @@
 # Consolidation Structural Schema Conformity Checks
 
-> Post-generation validation. After semantic checks, verify ALL module feature.json files conform to JSON schema.
+> Post-generation validation. After semantic checks, verify ALL module JSON files conform to JSON schema.
 
 ## A. Required Sections Presence
 
@@ -17,7 +17,7 @@
 | `specification.functionalRequirements[]` | YES | Must have >=1 FR |
 | `specification.permissionMatrix` | YES | Must be `{permissions[], roleAssignments[]}` (NOT flat array) |
 | `specification.sections[]` | YES | Must have >=1 section with resources |
-| `specification.uiWireframes[]` | YES | Must have >=1 wireframe with `layout` object |
+| `specification.wireframes[]` | YES | Must have >=1 wireframe with `layout` object |
 | `specification.lifeCycles[]` | IF entities have status | States must be objects (NOT strings) |
 | `specification.seedDataCore` | YES | Must have 9 arrays: navigationApplications, applicationRoles, navigationModules, navigationSections, navigationResources, navigationTranslations, permissions, rolePermissions, permissionConstants |
 | `specification.seedDataBusiness` | NO (WARNING) | Business seed data is generated during implementation (ralph-loop), not during BA. If present, validates format. |
@@ -28,13 +28,13 @@
 
 ## B. Field Name Conformity
 
-> **Two-phase entity schema:** In the **analysis** phase (step-03a2), entity attributes use a business-friendly format WITHOUT `type`.
-> In the **compilation** phase (step-03c), `type` is auto-inferred and added to each attribute.
+> **Two-phase entity schema:** In the **analysis** phase (step-03), entity attributes use a business-friendly format WITHOUT `type`.
+> In the **compilation** phase (step-03), `type` is auto-inferred and added to each attribute.
 > Therefore `type` is FORBIDDEN in the raw analysis input but MANDATORY after compilation.
 
 | Section | FORBIDDEN fields | Correct fields |
 |---------|-----------------|----------------|
-| `entities[].attributes[]` | `values`, `rules` | `type` (added by step-03c compilation), `description`, `unique`, `validation` |
+| `entities[].attributes[]` | `values`, `rules` | `type` (added by step-03 compilation), `description`, `unique`, `validation` |
 | `businessRules[]` | `rule`, `condition` (singular) | `name`, `statement`, `conditions[]` |
 | `useCases[]` | `actor`, `linkedBRs`, `linkedFRs` | `primaryActor`, `linkedRules` |
 | `functionalRequirements[]` | `name`, `description`, `linkedUCs`, `linkedBRs` | `statement`, `linkedUseCases`, `linkedRules` |