## Introduction

Le skill Business Analyse v3.0 est un workflow VibeCoding en 5 etapes qui transforme un besoin utilisateur en specification fonctionnelle complete, prete pour l'implementation. Il repose sur une architecture JSON-First ou un unique fichier `feature.json` est enrichi progressivement a chaque etape.

The Business Analyse v3.0 skill is a VibeCoding workflow in 5 steps that transforms a user need into a complete functional specification, ready for implementation. It relies on a JSON-First architecture where a single `feature.json` file is progressively enriched at each step.

⚠

##### Principe fondamental

##### Core Principle

Comprendre avant de specifier. Les etapes 00-01 se concentrent sur la DECOUVERTE (langage utilisateur), les etapes 02-04 sur la SPECIFICATION et le HANDOFF (langage technique).

Understand before specifying. Steps 00-01 focus on DISCOVERY (user language), steps 02-04 on SPECIFICATION and HANDOFF (technical language).

🧠

##### ULTRATHINK

Les etapes critiques (01 Analyse, 02 Specify, 04 Handoff) utilisent ULTRATHINK avec le modele Opus pour une reflexion approfondie. Les etapes simples (00 Init, 03 Validate) utilisent Haiku pour la rapidite.

Critical steps (01 Analyse, 02 Specify, 04 Handoff) use ULTRATHINK with the Opus model for deep reasoning. Simple steps (00 Init, 03 Validate) use Haiku for speed.

📊

##### 4 cas d'usage

##### 4 Use Cases

Le skill supporte 4 modes : Nouvelle feature (workflow complet), Question (interroger une feature existante), Refactoring (creer une version delta), Micro-feature (analyse minimale).

The skill supports 4 modes: New feature (full workflow), Question (query an existing feature), Refactoring (create a delta version), Micro-feature (minimal analysis).

## Architecture JSON-First JSON-First Architecture

Contrairement a l'ancienne approche multi-fichiers markdown, la v3.0 utilise un unique fichier `feature.json` enrichi progressivement par chaque etape. Cela reduit le contexte de ~70% par phase et elimine les fichiers intermediaires.

Unlike the previous multi-file markdown approach, v3.0 uses a single `feature.json` file progressively enriched by each step. This reduces context by ~70% per phase and eliminates intermediate files.

    docs/business/{app}/{module}/business-analyse/
    ├── v1.0/
    │   └── feature.json    ← Single enriched JSON (progressively filled)
    ├── v1.1/
    │   └── feature.json    ← Delta version (refactoring)
    └── v2.0/
        └── feature.json    ← Major revision

    .ralph/
    ├── prd.json            ← Task breakdown (generated by step-04)
    └── progress.txt        ← Progress tracker

#### Enrichissement progressif

#### Progressive enrichment

Etape Step | Sections enrichies Enriched sections | Status | Modele Model
--- | --- | --- | ---
00 - Init | `metadata` | draft | Haiku
01 - Analyse | `discovery`, `analysis`, `suggestions` | analysed | Opus
02 - Specify | `specification` | specified | Sonnet
03 - Validate | `validation` | approved | Haiku
04 - Handoff | `handoff` | handed-off | Opus

#### Structure du feature.json

#### feature.json structure

    {
      "id": "FEAT-001",
      "version": "1.0",
      "status": "draft | analysed | specified | approved | handed-off",
      "metadata": {
        "title": "...",
        "application": "...",
        "module": "...",
        "language": "fr",
        "featureType": "data-centric | integration | ui-centric | workflow | reporting | full-module | micro",
        "steps": {
          "init":     { "status": "completed", "startedAt": "...", "completedAt": "..." },
          "analyse":  { "status": "in-progress" },
          "specify":  { "status": "pending" },
          "validate": { "status": "pending" },
          "handoff":  { "status": "pending" }
        }
      },
      "discovery":     { "codebaseContext": {}, "questionnaire": {} },
      "analysis":      { "businessRules": [], "entities": [], "objectives": [], "risks": [] },
      "specification": { "actors": [], "useCases": [], "requirements": [], "permissions": {} },
      "validation":    { "completeness": {}, "consistency": {}, "decision": "APPROVED" },
      "handoff":       { "fileMapping": {}, "apiEndpoints": [], "testPlan": {} },
      "suggestions":   [],
      "changelog":     []
    }

📚

##### Schema JSON

Le schema complet est defini dans `schemas/feature-schema.json` (JSON Schema 2020-12). Toutes les ecritures sont validees par le `ba-writer` agent.

The complete schema is defined in `schemas/feature-schema.json` (JSON Schema 2020-12). All writes are validated by the `ba-writer` agent.

## Quick Start

`/business-analyse` SKILL

Lancez l'analyse metier complete ou choisissez un mode specifique selon votre besoin.

Launch the complete business analysis or choose a specific mode based on your need.

    /business-analyse [description] [flags]

#### Exemples rapides

#### Quick examples

    # Nouvelle feature (workflow complet 5 etapes)
    /business-analyse Order management module

    # Question sur une feature existante
    /business-analyse -q FEAT-001 "What permissions does the manager have?"

    # Refactoring (delta sur feature existante)
    /business-analyse -r FEAT-001 "Add export PDF functionality"

    # Micro-feature (analyse minimale)
    /business-analyse -m Add a status field to orders

## 4 Cas d'usage 4 Use Cases

Cas d'usage Use Case | Flag | Commande Command | Parcours Flow | Sortie Output
--- | --- | --- | --- | ---
Nouvelle feature New feature | (aucun)(none) | `/business-analyse Order module` | 00 → 01 → 02 → 03 → 04 | `feature.json` v1.0 + `prd.json`
Question | `-q` | `/business-analyse -q FEAT-001 "..."` | 00 → ba-reader → EXIT | Reponse textuelle Text answer
Refactoring | `-r` | `/business-analyse -r FEAT-001 "Add PDF"` | 00 (delta) → 01 → 02 → 03 → 04 | `feature.json` v1.1 + `prd.json`
Micro-feature | `-m` | `/business-analyse -m Add status field` | 00 → 01 (4 Q) → 02 (min) → 03 (auto) → 04 | `feature.json` v1.0 (micro)

#### Routage des cas d'usage

#### Use case routing

    question (-q)  → ba-reader.answerQuestion()  → EXIT
    refactor (-r)  → ba-writer.createVersion()   → step-01 (delta) → ... → step-04
    micro    (-m)  → step-00 (minimal)           → step-01 (micro) → ... → step-04
    default        → step-00                     → step-01 (full)  → ... → step-04

## Flags & Modes

Flag | Long | Effet Effect
--- | --- | ---
`-a` | `--auto` | Mode autonome : saute les confirmations utilisateur Autonomous mode: skip user confirmations
`-e` | `--economy` | Mode economique : pas de sous-agents, utilise Glob/Grep directement Economy mode: no subagents, uses Glob/Grep directly
`-q FEAT-ID "text"` | `--question` | Mode question : interroge une feature existante (lecture seule, EXIT) Question mode: query an existing feature (read-only, EXIT)
`-r FEAT-ID "text"` | `--refactor` | Mode refactoring : cree une version delta (v1.0 → v1.1) Refactoring mode: creates a delta version (v1.0 → v1.1)
`-m` | `--micro` | Micro-feature : analyse minimale (4 questions max) Micro-feature: minimal analysis (4 questions max)
`-i` | `--interactive` | Mode interactif : configuration guidee des flags Interactive mode: guided flag configuration

## Workflow

## Step 00 — Init

`step-00-init` Haiku Rapide Fast

Mission : Parser les flags, router vers le bon cas d'usage, creer le `feature.json` initial.

Mission: Parse flags, route to the correct use case, create the initial `feature.json`.

#### Actions principales

#### Main actions

1. Parser les flags de commande (`-a`, `-e`, `-q`, `-r`, `-m`, `-i`)
2. Parse command flags (`-a`, `-e`, `-q`, `-r`, `-m`, `-i`)
3. Router vers le handler (question / refactor / micro / new)
4. Route to handler (question / refactor / micro / new)
5. Health check MCP (non-bloquant)
6. MCP health check (non-blocking)
7. Determiner application et module cible
8. Determine target application and module
9. Generer l'ID feature (`FEAT-NNN`)
10. Generate feature ID (`FEAT-NNN`)
11. Creer le dossier de sortie et le `feature.json` initial via `ba-writer`
12. Create output directory and initial `feature.json` via `ba-writer`
13. Mettre a jour `.business-analyse/config.json`
14. Update `.business-analyse/config.json`

🔄

##### Mode Question (-q)

##### Question Mode (-q)

Le mode question charge le `ba-reader`, repond a la question depuis le `feature.json` existant, puis termine immediatement (EXIT). Aucun fichier n'est modifie.

Question mode loads the `ba-reader`, answers the question from the existing `feature.json`, then exits immediately (EXIT). No files are modified.

Sortie : `feature.json` (status: `draft`)

Output: `feature.json` (status: `draft`)

## Step 01 — Analyse

`step-01-analyse` Opus ULTRATHINK

Mission : Decouverte fusionnee + analyse metier. Exploration du codebase, questionnaire progressif, regles metier, entites, suggestions proactives.

Mission: Merged discovery + business analysis. Codebase exploration, progressive questionnaire, business rules, entities, proactive suggestions.

#### Detection du type de feature

#### Feature type detection

Type | Mots-cles Keywords | Categories questionnaire Questionnaire categories
--- | --- | ---
Data-centric | management, CRUD, entity | 01, 02, 03, 04, 06, 11
Integration | API, sync, import/export | 01, 02, 03, 05, 06
UI-centric | screen, form, dashboard | 01, 02, 03, 06, 07
Workflow | process, validation, steps | 01, 02, 03, 06, 09
Reporting | report, export, KPI | 01, 02, 03, 04, 08
Full-module | (complet) (comprehensive) | Toutes (01-13) All (01-13)
Micro | `-m` flag | 01, 02, 03, 06

#### Pre-recherche codebase (3 phases)

#### Codebase pre-research (3 phases)

1. Phase 3a : Appels MCP (`analyze_extension_points`, `api_docs`, `validate_conventions`)
2. Phase 3a: MCP calls (`analyze_extension_points`, `api_docs`, `validate_conventions`)
3. Phase 3b : Agents paralleles (entites, integrations, patterns UI) — desactive en mode `-e`
4. Phase 3b: Parallel agents (entities, integrations, UI patterns) — disabled in `-e` mode
5. Phase 3c : Mode economique (`-e`) — Glob/Grep directement
6. Phase 3c: Economy mode (`-e`) — Glob/Grep directly

#### 5 techniques d'elicitation

#### 5 elicitation techniques

# | Technique | Objectif Purpose
--- | --- | ---
1 | Solution → Problem | Recadrer si l'utilisateur decrit une solution Reframe if user describes a solution
2 | 5 Whys | Analyse de cause racine Root cause analysis
3 | Scenario concret Concrete scenario | Extraire un exemple reel Extract a real-world example
4 | Test d'absence Absence test | Que se passe-t-il sans cette feature ? What happens without this feature?
5 | Sondage de completude Completeness probing | Challenger chaque reponse de type liste Challenge every list-type answer

#### Sorties produites

#### Produced outputs

- Regles metier (BR-{category}-NNN) avec priorite MUST/SHOULD/COULD
- Business rules (BR-{category}-NNN) with MUST/SHOULD/COULD priority
- Entites (vue metier uniquement, pas de champs techniques)
- Entities (business view only, no technical fields)
- Objectifs mesurables (OBJ-NNN)
- Measurable objectives (OBJ-NNN)
- Flux de processus (points d'entree, decisions, actions)
- Process flows (entry points, decisions, actions)
- Suggestions proactives depuis le catalogue de patterns
- Proactive suggestions from the pattern catalog
- Analyse de risques (probabilite x impact)
- Risk analysis (probability x impact)

Sortie : `feature.json` enrichi avec `discovery`, `analysis`, `suggestions` (status: `analysed`)

Output: `feature.json` enriched with `discovery`, `analysis`, `suggestions` (status: `analysed`)

## Step 02 — Specify

`step-02-specify` Sonnet Spec

Mission : Specification detaillee — cas d'usage (UC), exigences fonctionnelles (FR), acteurs, permissions, wireframes, scenarios Gherkin, validations, cycle de vie, SeedData.

Mission: Detailed specification — use cases (UC), functional requirements (FR), actors, permissions, wireframes, Gherkin scenarios, validations, lifecycle, SeedData.

#### Sections specifiees

#### Specified sections

Section | Contenu Content | Format
--- | --- | ---
Acteurs & Permissions Actors & Permissions | Matrice acteurs x ressources x operations Actors x resources x operations matrix | Read, Create, Update, Delete, Approve, Delegate, Execute
Cas d'usage Use Cases | UC-001, UC-002... | Lies aux BR, categories CRUD/Workflow/Reports Linked to BRs, CRUD/Workflow/Reports categories
Exigences fonctionnelles Functional Requirements | FR-001, FR-002... | Priorite MoSCoW, lies aux UC et BR MoSCoW priority, linked to UCs and BRs
SeedData | 5 tables obligatoires par module 5 mandatory tables per module | Status, Priority, Category, Type, Department
Navigation | Hierarchie 3 niveaux 3-level hierarchy | Level 1 → Level 2 → Level 3
Wireframes | Ecrans cles (List, Create, Detail) Key screens (List, Create, Detail) | Layout, components, actions
Scenarios Gherkin Gherkin Scenarios | Given / When / Then | Happy path, alternatives, erreurs Happy path, alternatives, errors
Cycle de vie Data Lifecycle | Machine a etats par entite State machine per entity | Transitions, visibilite, permissions par etat Transitions, visibility, permissions per state

⚠

##### 5 SeedData obligatoires

##### 5 Mandatory SeedData

Sans ces 5 fichiers, le module est invisible et retourne 403 : `NavigationModuleConfiguration`, `NavigationTranslationConfiguration`, `PermissionConfiguration`, `Permissions.cs`, `RolePermissionConfiguration`.

Without these 5 files, the module is invisible and returns 403: `NavigationModuleConfiguration`, `NavigationTranslationConfiguration`, `PermissionConfiguration`, `Permissions.cs`, `RolePermissionConfiguration`.

Sortie : `feature.json` enrichi avec `specification` (status: `specified`)

Output: `feature.json` enriched with `specification` (status: `specified`)

## Step 03 — Validate

`step-03-validate` Haiku Porte qualite Quality gate

Mission : Porte qualite avant le handoff — decision binaire APPROVED / REJECTED.

Mission: Quality gate before handoff — binary decision APPROVED / REJECTED.

#### Controles effectues

#### Checks performed

Controle Check | Verification Verification | Impact si echec Impact on failure
--- | --- | ---
Completude Completeness | Toutes sections requises presentes All required sections present | REJECT
Coherence Consistency | UC ↔ FR, FR ↔ BR, Actor ↔ Permission | REJECT (error) / WARN (warning)
Conventions SmartStack SmartStack conventions | Nommage PascalCase, UC-NNN, FR-NNN, BR-NNN Naming PascalCase, UC-NNN, FR-NNN, BR-NNN | REJECT
Risques Risks | Scope creep, securite, complexite Scope creep, security, complexity | REJECT (critical) / USER (high)
RBAC | Guest ⊂ User ⊂ Manager ⊂ Admin Guest ⊂ User ⊂ Manager ⊂ Admin | REJECT

#### En cas de rejet

#### On rejection

- Auto-revision : corrections automatiques (orphelins, nommage, references invalides)
- Auto-revise: automatic corrections (orphans, naming, invalid references)
- Revision manuelle : retour a step-02
- Manual revision: return to step-02
- Force-approve : override avec avertissement
- Force-approve: override with warning

⚡

##### Mode Micro

##### Micro Mode

En mode micro (`-m`), la validation est automatique — auto-approve sans interaction utilisateur.

In micro mode (`-m`), validation is automatic — auto-approve without user interaction.

Sortie : `feature.json` enrichi avec `validation` (status: `approved`)

Output: `feature.json` enriched with `validation` (status: `approved`)

## Step 04 — Handoff

`step-04-handoff` Opus ULTRATHINK

Mission : Generer le package de handoff pour le developpement — mapping fichiers, endpoints API, plan de tests, i18n, et generation du `prd.json` pour Ralph Loop.

Mission: Generate the development handoff package — file mapping, API endpoints, test plan, i18n, and `prd.json` generation for Ralph Loop.

#### Contenu du handoff

#### Handoff content

Section | Contenu Content
--- | ---
Mapping fichiers File mapping | Backend (Entity, Service, Controller, Repository, Migration, Tests) + Frontend (Pages, Components, API Client, Redux) Backend (Entity, Service, Controller, Repository, Migration, Tests) + Frontend (Pages, Components, API Client, Redux)
Sequence d'implementation Implementation sequence | Domain → SeedData → Application → Infrastructure → API → Frontend
Endpoints API API endpoints | Routes RESTful pour tous les UC, parametres, corps de reponse, codes d'erreur RESTful routes for all UCs, parameters, response bodies, error codes
Plan de tests Test plan | Tests unitaires, integration, E2E Unit, integration, E2E tests
i18n | Cles de traduction (en, fr, it, de) pour menus, titres, champs, validations, messages Translation keys (en, fr, it, de) for menus, titles, fields, validations, messages
Regles metier → Code Business rules → Code | Points d'implementation par BR (Domain, Infrastructure, API, Frontend) Implementation points per BR (Domain, Infrastructure, API, Frontend)

#### Fichiers generes

#### Generated files

    .ralph/
    ├── prd.json        # v2.0.0 schema, 15 tasks across 9 layers
    └── progress.txt    # Progress tracker with daily update template

#### Choix utilisateur au final

#### User choices at the end

- Feature Full — Scaffolding rapide (~70-80% couverture) Fast scaffolding (~70-80% coverage)
- Ralph Loop — Developpement iteratif (~95-100% couverture) Iterative development (~95-100% coverage)
- End BA — Developpement manuel Manual development

Sortie : `feature.json` enrichi avec `handoff` (status: `handed-off`) + `.ralph/prd.json` + `.ralph/progress.txt`

Output: `feature.json` enriched with `handoff` (status: `handed-off`) + `.ralph/prd.json` + `.ralph/progress.txt`

## Questionnaire

Le questionnaire est compose de 13 categories chargees progressivement selon le type de feature detecte. Le chargement intelligent reduit le nombre de questions posees tout en garantissant la couverture.

The questionnaire consists of 13 categories loaded progressively based on the detected feature type. Smart loading reduces the number of questions asked while ensuring coverage.

# | Categorie Category | Questions Questions | Charge quand Loaded when
--- | --- | --- | ---
01 | Context | 4 | Toujours Always
02 | Stakeholders | 8 | Toujours Always
03 | Scope | 8 | Toujours Always
04 | Data | 8 | Data-centric / Full
05 | Integrations | 8 | Integration / Full
06 | Security | 8 | Toujours (minimal) Always (minimal)
07 | UI | 8 | UI-centric / Full
08 | Performance | 4 | Reporting / Critical
09 | Constraints | 4 | Si contraintes If constraints
10 | Documentation | 4 | Si doc requise If doc required
11 | Data Lifecycle | 8 | Conditionnel Conditional
12 | Migration | 8 | Conditionnel Conditional
13 | Cross-Module | 8 | Conditionnel Conditional

💬

##### Protocole d'elicitation

##### Elicitation protocol

Les questions sont posees par lots de max 4 via `AskUserQuestion`. Apres chaque categorie, un resume est affiche pour validation. Les reponses vagues declenchent des questions de suivi ciblees.

Questions are asked in batches of max 4 via `AskUserQuestion`. After each category, a summary is displayed for validation. Vague answers trigger targeted follow-up questions.

⚡

##### Mode Micro

##### Micro Mode

En mode micro (`-m`), seule la categorie 01 (Context) est chargee avec 4 questions maximum.

In micro mode (`-m`), only category 01 (Context) is loaded with 4 questions maximum.

## Versioning

Chaque feature suit un systeme de versioning semantique. Les versions sont stockees dans des dossiers separes pour permettre le suivi de l'evolution.

Each feature follows a semantic versioning system. Versions are stored in separate folders to track evolution.

Cas Case | Version | Declencheur Trigger
--- | --- | ---
Nouvelle feature New feature | `v1.0` | `/business-analyse Order module`
Refactoring mineur Minor refactoring | `v1.1`, `v1.2`... | `/business-analyse -r FEAT-001 "Add PDF export"`
Revision majeure Major revision | `v2.0` | Changement d'architecture ou de perimetre Architecture or scope change

    docs/business/{app}/{module}/business-analyse/
    ├── v1.0/feature.json    # Initial version
    ├── v1.1/feature.json    # Delta: "Add PDF export" (previousVersion: v1.0)
    ├── v1.2/feature.json    # Delta: "Add bulk import" (previousVersion: v1.1)
    └── v2.0/feature.json    # Major revision

En mode refactoring (`-r`), le `feature.json` de la version delta contient un champ `previousVersion` et un `changeReason` pour tracer l'evolution.

In refactoring mode (`-r`), the delta version's `feature.json` contains a `previousVersion` and `changeReason` field to track evolution.

## Agents

Le skill Business Analyse utilise des agents specialises pour la gestion du `feature.json`.

The Business Analyse skill uses specialized agents for `feature.json` management.

Agent | Role Role | Methodes principales Key methods | Utilise dans Used in
--- | --- | --- | ---
ba-writer | Ecrit et met a jour le feature.json Writes and updates feature.json | `createFeature`, `enrichSection`, `updateStatus`, `createVersion` | Toutes les etapes (00-04) All steps (00-04)
ba-reader | Lit le feature.json pour le contexte Reads feature.json for context | `findFeature`, `readSection`, `answerQuestion`, `getSummaryForSkill` | Toutes les etapes (00-04) + mode -q All steps (00-04) + -q mode

🤖

##### Mode economique

##### Economy mode

En mode `-e`, les sous-agents d'exploration (recherche codebase) sont desactives. Seuls `ba-writer` et `ba-reader` restent actifs. Les recherches utilisent directement Glob/Grep.

In `-e` mode, exploration subagents (codebase search) are disabled. Only `ba-writer` and `ba-reader` remain active. Searches use Glob/Grep directly.

## Sorties Output

#### Fichiers produits

#### Produced files

Fichier File | Emplacement Location | Genere par Generated by | Contenu Content
--- | --- | --- | ---
feature.json | `docs/business/{app}/{module}/business-analyse/v{X.Y}/` | Toutes les etapes All steps | Source unique de verite — enrichi progressivement Single source of truth — progressively enriched
prd.json | `.ralph/prd.json` | Step 04 | Decomposition en 15 taches sur 9 couches (schema v2.0.0) Breakdown into 15 tasks across 9 layers (v2.0.0 schema)
progress.txt | `.ralph/progress.txt` | Step 04 | Suivi de progression avec template de mise a jour quotidienne Progress tracker with daily update template

#### Templates et schemas

#### Templates and schemas

Fichier File | Objectif Purpose | Utilise dans Used in
--- | --- | ---
`schemas/feature-schema.json` | Schema de validation JSON (JSON Schema 2020-12) JSON validation schema (JSON Schema 2020-12) | Toutes les etapes All steps
`templates/tpl-frd.md` | Template de specification fonctionnelle (reference) Functional requirements document template (reference) | Step 02
`templates/tpl-handoff.md` | Template de handoff developpement (reference) Development handoff template (reference) | Step 04
`patterns/suggestion-catalog.md` | Catalogue de suggestions proactives Proactive suggestions catalog | Step 01
`questionnaire/*.md` | 13 categories de questionnaire 13 questionnaire categories | Step 01

## Exemple complet Complete example

#### Nouvelle feature : Module Commandes

#### New feature: Orders Module

    /business-analyse Order management module

00
Init — Parse flags, cree `FEAT-001`, initialise `feature.json` (v1.0, status: draft) Parse flags, create `FEAT-001`, initialize `feature.json` (v1.0, status: draft)
01
Analyse — Type detecte: `data-centric`. Questionnaire categories 01, 02, 03, 04, 06, 11. Extraction de 12 regles metier, 3 entites, 2 risques. 4 suggestions proactives presentees. Type detected: `data-centric`. Questionnaire categories 01, 02, 03, 04, 06, 11. Extraction of 12 business rules, 3 entities, 2 risks. 4 proactive suggestions presented.
02
Specify — 8 UC, 15 FR, matrice permissions 4 roles, 5 SeedData, wireframes List/Create/Detail, 12 scenarios Gherkin, machine a etats (Draft → Confirmed → Shipped → Delivered). 8 UCs, 15 FRs, 4-role permission matrix, 5 SeedData, List/Create/Detail wireframes, 12 Gherkin scenarios, state machine (Draft → Confirmed → Shipped → Delivered).
03
Validate — Completude OK, coherence OK (8 UC ↔ 15 FR ↔ 12 BR), conventions OK. Decision: APPROVED. Completeness OK, consistency OK (8 UCs ↔ 15 FRs ↔ 12 BRs), conventions OK. Decision: APPROVED.
04
Handoff — Mapping de 25 fichiers (backend + frontend), 8 endpoints API, plan de tests (18 unit, 8 integration, 4 E2E), cles i18n (4 langues). Generation de `prd.json` (15 taches, ~28h). 25 files mapped (backend + frontend), 8 API endpoints, test plan (18 unit, 8 integration, 4 E2E), i18n keys (4 languages). Generated `prd.json` (15 tasks, ~28h).

#### Resultat final

#### Final result

    docs/business/MyApp/Orders/business-analyse/v1.0/feature.json  # Complete BA
    .ralph/prd.json                                                 # 15 tasks for Ralph Loop
    .ralph/progress.txt                                             # Progress tracker

#### Ensuite : Refactoring

#### Next: Refactoring

    # Ajouter l'export PDF (cree v1.1)
    /business-analyse -r FEAT-001 "Add PDF export functionality"

    # Resultat :
    docs/business/MyApp/Orders/business-analyse/v1.1/feature.json  # Delta version
    # previousVersion: "1.0", changeReason: "Add PDF export functionality"

#### Ensuite : Question

#### Next: Question

    # Interroger la feature existante
    /business-analyse -q FEAT-001 "What permissions does the manager have?"

    # Reponse textuelle depuis feature.json → EXIT (aucun fichier modifie)