datakeen-session-react 1.1.195-dev.7 → 1.1.195-dev.9

package/docs/configuration.md

@@ -1,113 +0,0 @@
-# SDK Configuration Dynamique
-
-Le SDK Datakeen Session React supporte maintenant la configuration dynamique de l'URL API pour s'adapter aux différents environnements.
-
-## Configuration par Props (Recommandée)
-
-```tsx
-import { DatakeenSession } from "datakeen-session-react";
-
-function App() {
-  return (
-    <DatakeenSession
-      sessionId="your-session-id"
-      sessionConfig={{ selfie: true }}
-      apiBaseUrl={import.meta.env.VITE_API_URL} // Configuration dynamique
-    />
-  );
-}
-```
-
-## Configuration par Variables d'Environnement
-
-Le SDK recherche automatiquement les variables d'environnement dans l'ordre suivant :
-
-1. `VITE_API_BASE_URL`
-2. `VITE_API_URL`
-3. Fallback: `http://localhost:8888`
-
-### Dans votre app-frontend
-
-```bash
-# .env.local, .env.dev, .env.staging, etc.
-VITE_API_URL=https://api-dev.datakeen.co
-```
-
-## Configuration Runtime (Avancée)
-
-Pour des configurations plus complexes, vous pouvez également définir la configuration au runtime :
-
-```tsx
-// Définir la configuration avant le rendu
-window.ENV = {
-  VITE_API_URL: "https://api-staging.datakeen.co",
-};
-
-// Puis utiliser le composant normalement
-<DatakeenSession sessionId="..." />;
-```
-
-## Migration depuis l'ancienne version
-
-### Avant
-
-```tsx
-// L'URL était hardcodée ou dépendante de VITE_API_BASE_URL
-<DatakeenSession sessionId="..." />
-```
-
-### Maintenant
-
-```tsx
-// Option 1: Via props (recommandée)
-<DatakeenSession
-  sessionId="..."
-  apiBaseUrl={import.meta.env.VITE_API_URL}
-/>
-
-// Option 2: Via variables d'environnement
-// Renommez VITE_API_BASE_URL en VITE_API_URL dans votre .env
-// ou gardez les deux pour la rétrocompatibilité
-<DatakeenSession sessionId="..." />
-```
-
-## Exemples par Environnement
-
-### Développement local
-
-```bash
-VITE_API_URL=http://localhost:8888
-```
-
-### Développement (dev2)
-
-```bash
-VITE_API_URL=https://api-dev2.datakeen.co
-```
-
-### Staging
-
-```bash
-VITE_API_URL=https://api-staging.datakeen.co
-```
-
-### Production
-
-```bash
-VITE_API_URL=https://api.datakeen.co
-```
-
-## Avantages
-
-1. **Flexibilité**: Un seul package SDK pour tous les environnements
-2. **Rétrocompatibilité**: L'ancienne configuration continue de fonctionner
-3. **Configuration explicite**: Plus de clarté sur quelle API est utilisée
-4. **Runtime flexibility**: Possibilité de changer l'API sans rebuild
-
-## Debugging
-
-Pour debug quelle URL est utilisée, vous pouvez ajouter un log temporaire :
-
-```tsx
-console.log("API URL utilisée:", import.meta.env.VITE_API_URL);
-```

package/docs/dynamic-configuration.md

@@ -1,97 +0,0 @@
-# Configuration Dynamique du SDK
-
-## Problème
-
-Le SDK utilisait des variables d'environnement statiques qui étaient compilées lors du build du SDK, ne permettant pas d'adapter l'URL de l'API selon l'environnement d'exécution.
-
-## Solution
-
-Nous avons implémenté une configuration dynamique qui permet de définir l'URL de base de l'API au runtime.
-
-## Méthodes de Configuration
-
-### 1. Configuration via fonction (Recommandée)
-
-```typescript
-import { configureApiBaseURL } from 'client-sessions-react-sdk';
-
-// Configurer l'URL de base du SDK
-configureApiBaseURL('https://api.production.datakeen.co/backend/session');
-```
-
-### 2. Configuration via window.VITE_API_BASE_URL
-
-Le SDK vérifie automatiquement si `window.VITE_API_BASE_URL` est définie et l'utilise comme URL de base.
-
-```typescript
-// Dans votre application
-window.VITE_API_BASE_URL = 'https://api.production.datakeen.co/backend/session';
-```
-
-### 3. Configuration via variables d'environnement (fallback)
-
-Si aucune configuration dynamique n'est fournie, le SDK utilise les variables d'environnement classiques.
-
-## Ordre de Priorité
-
-1. URL configurée via `configureApiBaseURL()`
-2. `window.VITE_API_BASE_URL`
-3. `import.meta.env.VITE_API_BASE_URL`
-4. URL par défaut: `http://localhost:8888/backend/session`
-
-## Utilisation dans votre Application
-
-### Configuration automatique (recommandée)
-
-Créez un fichier de configuration qui s'exécute avant l'utilisation du SDK :
-
-```typescript
-// src/config/sdk.ts
-import { getSdkApiBaseUrl } from '@/config/environment';
-import { configureApiBaseURL } from 'client-sessions-react-sdk';
-
-// Configurer l'URL de base du SDK dynamiquement
-const sdkApiBaseUrl = getSdkApiBaseUrl();
-configureApiBaseURL(sdkApiBaseUrl);
-
-export const sdkConfig = {
-  apiBaseUrl: sdkApiBaseUrl,
-};
-```
-
-### Configuration manuelle
-
-```typescript
-import { configureApiBaseURL } from 'client-sessions-react-sdk';
-
-// Selon l'environnement
-const baseURL = process.env.NODE_ENV === 'production' 
-  ? 'https://api.datakeen.co/backend/session'
-  : 'https://staging-api.datakeen.co/backend/session';
-
-configureApiBaseURL(baseURL);
-```
-
-## Mise à jour dynamique
-
-Vous pouvez changer l'URL de base à tout moment :
-
-```typescript
-import { configureApiBaseURL } from 'client-sessions-react-sdk';
-
-// Changer d'environnement dynamiquement
-configureApiBaseURL('https://staging-api.datakeen.co/backend/session');
-```
-
-## Tests
-
-Pour les tests, vous pouvez configurer une URL de test :
-
-```typescript
-import { configureApiBaseURL } from 'client-sessions-react-sdk';
-
-// Dans vos tests
-beforeEach(() => {
-  configureApiBaseURL('http://localhost:3001/backend/session');
-});
-```

package/docs/environment.md

@@ -1,27 +0,0 @@
-# Environment Configuration
-
-This SDK uses environment variables for configuration. Below are the environment variables used:
-
-## Required Environment Variables
-
-- `VITE_API_BASE_URL`: The base URL for the API. Default: `http://localhost:8888`
-
-## Setting Up Environment Variables
-
-1. Create a `.env` file in the root of the project
-2. Add the following line to the `.env` file:
-   ```
-   VITE_API_BASE_URL=http://localhost:8888
-   ```
-3. For production, create a `.env.production` file with the production URL:
-   ```
-   VITE_API_BASE_URL=https://api.datakeen.co
-   ```
-
-## Using in Development
-
-When developing locally, you can modify the `.env` file to point to your local backend or a staging environment.
-
-## Using in Demo Application
-
-The demo application also uses the same environment variables. Make sure to create a `.env` file in the demo folder as well.

package/docs/migration-guide.md

@@ -1,120 +0,0 @@
-# Guide de Migration - Configuration API Dynamique
-
-## ✅ Mise à jour réussie !
-
-Le SDK a été mis à jour pour supporter la configuration dynamique des environnements. Voici ce qui a été fait et comment l'utiliser.
-
-## Ce qui a changé
-
-### ✅ Nouvelles fonctionnalités
-
-- Support de l'`apiBaseUrl` en paramètre
-- Détection automatique de `VITE_API_URL` et `VITE_API_BASE_URL`
-- Configuration runtime via `window.ENV`
-- Rétrocompatibilité complète
-
-### ✅ APIs mises à jour
-
-- `DatakeenSession` : nouveau paramètre `apiBaseUrl?`
-- `useSession` : nouveau paramètre `apiBaseUrl?`
-- Tous les services internes utilisent la configuration dynamique
-
-## Migration
-
-### Avant (continue de fonctionner)
-
-```tsx
-import useSession from "datakeen-session-react";
-
-function App() {
-  const { SessionComponent } = useSession("session-id");
-  return SessionComponent;
-}
-```
-
-### Maintenant (recommandé)
-
-#### Option 1: Via useSession
-
-```tsx
-import useSession from "datakeen-session-react";
-
-function App() {
-  const { SessionComponent } = useSession(
-    "session-id",
-    { selfie: true },
-    import.meta.env.VITE_API_URL // Configuration dynamique
-  );
-  return SessionComponent;
-}
-```
-
-#### Option 2: Via DatakeenSession
-
-```tsx
-import { DatakeenSession } from "datakeen-session-react";
-
-function App() {
-  return (
-    <DatakeenSession
-      sessionId="session-id"
-      sessionConfig={{ selfie: true }}
-      apiBaseUrl={import.meta.env.VITE_API_URL}
-    />
-  );
-}
-```
-
-## Configuration par environnement
-
-### Variables d'environnement supportées
-
-1. `VITE_API_URL` (nouveau, recommandé)
-2. `VITE_API_BASE_URL` (ancien, toujours supporté)
-3. Configuration runtime via `window.ENV.VITE_API_URL`
-
-### Exemples par environnement
-
-```bash
-# .env.local
-VITE_API_URL=http://localhost:8888
-
-# .env.dev
-VITE_API_URL=https://api-dev.datakeen.co
-
-# .env.staging
-VITE_API_URL=https://api-staging.datakeen.co
-
-# .env.production
-VITE_API_URL=https://api.datakeen.co
-```
-
-## Vérification que tout fonctionne
-
-1. **Vérifiez les logs** : Le SDK loggera l'URL utilisée
-2. **Testez les environnements** : Changez `VITE_API_URL` et relancez
-3. **Mode développement** : Le lien npm continue de fonctionner
-
-## Avantages
-
-✅ **Un seul package pour tous les environnements**  
-✅ **Configuration explicite et claire**  
-✅ **Aucune breaking change**  
-✅ **Runtime flexibility**  
-✅ **Meilleur debugging**
-
-## Actions à faire dans app-frontend
-
-1. **Optionnel** : Passer l'`apiBaseUrl` explicitement
-2. **Recommandé** : Utiliser `VITE_API_URL` comme variable standard
-3. **Test** : Vérifier que les appels API pointent vers le bon environnement
-
-## Debug
-
-Pour vérifier quelle URL est utilisée :
-
-```tsx
-console.log("API URL:", import.meta.env.VITE_API_URL);
-```
-
-Le SDK utilisera automatiquement cette URL pour tous ses appels.

package/docs/multi-runs.md

@@ -1,111 +0,0 @@
-# Multi-runs — Pré-remplissage par run avec `userInputList`
-
-## Vue d'ensemble
-
-Un parcours peut contenir une **boucle** : un nœud `condition` avec `conditionFalseMode: "loop"` pointe via son edge "false" vers un nœud antérieur (ex: `information-input`). Cela permet de faire saisir des données à plusieurs personnes successivement dans la même session (ex: déclaration de plusieurs bénéficiaires).
-
-Ce guide explique comment pré-remplir le formulaire différemment à chaque passage.
-
----
-
-## Convention `_list`
-
-À la **création de session**, l'intégrateur peut passer un tableau de pré-remplissages via la clé réservée `_list` dans `userInput` :
-
-```json
-POST /backend/api/v1/session
-{
-  "journeyId": "...",
-  "userInput": {
-    "_list": [
-      { "firstName": "Alice", "lastName": "Dupont" },
-      { "firstName": "Bob",   "lastName": "Martin" }
-    ]
-  }
-}
-```
-
-- `_list[0]` → pré-rempli au **1er passage** sur le nœud
-- `_list[1]` → pré-rempli au **2e passage**
-- Si l'index est hors borne → **formulaire vide** (pas de reprise des valeurs du run précédent)
-
-> **Aucun changement de schéma backend requis.** La clé `_list` est stockée dans le champ `userInput` (Json) existant.
-
----
-
-## Index de passage (run) et `retryCounts`
-
-Ne pas confondre deux notions distinctes :
-
-**1. Index du passage courant (`runIndex`, 0-indexé)** : calculé côté SDK dans `TemplateNodeRenderer` (nœud `information-input`) à partir de l'historique de navigation (`stepHistory`) : nombre de visites du step courant moins 1. Il n'est **pas persisté** et n'est **pas** stocké dans `session.retryCounts`. C'est lui qui sélectionne `_list[runIndex]`. Un retour arrière (`goBack()`) retire l'entrée d'historique et ne fait donc pas avancer le passage.
-
-**2. `session.retryCounts[nodeId]`** : compteur **par nœud** de tentatives échouées, lu via `getNodeRetryCount(session, nodeId)` (`retryService.ts`) et persisté via `PATCH /session/sdk/:id` (`updateNodeRetryCount` / `incrementNodeRetryCount`). Il est incrémenté :
-- par `DocumentCollection.tsx` et `DocumentCheck.tsx` à chaque tentative de vérification documentaire qui échoue (il alimente `maxResubmissionAttempts` / `allowResubmission`) ;
-- par `ConditionNodeHandler.tsx` **uniquement** lorsque `conditionFalseMode === "retry"` et que la condition évalue à `false` (il alimente `conditionMaxRetries`). En mode `"loop"`, le handler navigue simplement vers l'edge `false` **sans toucher à `retryCounts`**.
-
-Conséquences :
-- `retryCounts[nodeId]` n'est **pas** l'index de passage de la boucle et ne sélectionne jamais une entrée de `_list`.
-- Côté backend, `retryCounts[nodeId] > 0` sur un nœud `document-collection`, `identity-control` ou `controle-jdi` sert à ne pas facturer les tentatives de resoumission (voir `LAGO_BILLING_INTEGRATION.md` du backend). Limites : le passage d'une boucle sur un même nœud n'incrémente pas ce compteur ; un échec technique compte comme tentative côté SDK ; la mise à jour est asynchrone (`PATCH` non bloquant).
-
-Il n'y a **rien à configurer** pour `_list` : le SDK sélectionne automatiquement la bonne entrée à partir de l'historique de navigation.
-
----
-
-## Comportement détaillé
-
-| Situation | `initialUserInput` reçu par le formulaire |
-|-----------|------------------------------------------|
-| `userInput` sans `_list` (1er passage **ou** ré-entrée) | `userInput` global persisté |
-| `_list` présent, run 0 | `_list[0]` |
-| `_list` présent, run 1 | `_list[1]` |
-| `_list` présent, run N ≥ longueur | `{}` (formulaire vide) |
-
-> **Sans `_list`, le formulaire est toujours pré-rempli depuis le `userInput` persisté**, y compris lors d'une ré-entrée (boucle `condition` de correction, retour arrière, bouton « Corriger ma saisie »). Une ré-entrée sans `_list` correspond à *corriger les mêmes données*, pas à en saisir de nouvelles — on ne vide donc pas le formulaire.
->
-> ⚠️ **L'énumération de plusieurs entités distinctes (ex: plusieurs bénéficiaires) doit passer par `_list`.** Sans `_list`, chaque ré-entrée ré-affiche les données précédentes (pas de formulaire vierge par run).
-
----
-
-## Retour arrière
-
-Le bouton "Retour" utilise `goBack()` qui remonte dans l'historique de navigation vers le **nœud précédent dans le graphe**. Il ne revient pas au run précédent sur le même nœud.
-
----
-
-## Exemple de parcours complet
-
-```
-start → information-input → condition (loop si false) → end
-                   ↑_____________________|
-```
-
-Payload de création avec 2 personnes à déclarer :
-```json
-{
-  "journeyId": "journey-id",
-  "userInput": {
-    "_list": [
-      { "firstName": "Alice", "lastName": "Dupont", "birthDate": "1990-01-15" },
-      { "firstName": "Bob",   "lastName": "Martin", "birthDate": "1985-06-22" }
-    ]
-  }
-}
-```
-
-**Déroulé :**
-1. Run 0 → formulaire pré-rempli avec Alice → condition évalue les données → false → retour sur le formulaire
-2. Run 1 → formulaire pré-rempli avec Bob → condition évalue → true → fin
-3. Run 2 (si prévu) → formulaire vide
-
----
-
-## Fichiers de référence
-
-| Fichier | Rôle |
-|---------|------|
-| `src/services/sessionService.ts` | `getRunPrefillData(userInput, runIndex)` |
-| `src/components/template/TemplateNodeRenderer.tsx` | Calcul de `initialUserInput` pour `information-input` |
-| `src/services/retryService.ts` | `getNodeRetryCount` / `incrementNodeRetryCount` (compteur d'échecs par nœud) |
-| `src/components/template/ConditionNodeHandler.tsx` | Incrémente `retryCounts` en mode `retry` uniquement (pas en `loop`) |
-| `src/components/document-collection/DocumentCollection.tsx`, `src/components/session/DocumentCheck.tsx` | Incrémentent `retryCounts[nodeId]` à chaque échec de vérification |
-| `src/hooks/useStepNavigation.ts` | `goBack()` — retour au nœud précédent |

package/docs/navigation-history.md

@@ -1,163 +0,0 @@
-# Navigation History — Guide développeur
-
-## Vue d'ensemble
-
-Le SDK gère la navigation entre les étapes d'un parcours via un système d'historique interne, implémenté dans `src/hooks/useStepNavigation.ts`. Il ne s'appuie **pas** sur React Router ou l'historique du navigateur.
-
----
-
-## Architecture
-
-### Représentation de l'état
-
-```typescript
-step: number          // étape courante (0 = écran de démarrage, 1+ = nœuds du template)
-history: number[]     // pile d'étapes visitées, ex: [0, 1, 3, 4]
-```
-
-L'index des étapes est **1-based** pour les nœuds du template : le nœud à l'index 0 dans `getOrderedJourneySteps()` correspond au step `1`.
-
-### Les primitives exposées via `stepObject`
-
-| Primitive | Description |
-|-----------|-------------|
-| `step` | Étape courante |
-| `setStep(n, skipHistory?)` | Navigue vers l'étape `n`. Par défaut ajoute `n` à l'historique sauf si `skipHistory = true` |
-| `goBack()` | Dépile l'historique et navigue vers l'étape précédente |
-| `goToNextStep(nodeId, template, handle?)` | Suit le graphe d'edges depuis `nodeId` pour déterminer la prochaine étape |
-| `goToNextStepCommitted(nodeId, template, handle?)` | Suit le graphe puis remplace l'historique par le nœud d'arrivée, qui devient un point de non-retour |
-| `canGoBack` | `true` si `history.length > 1` |
-
----
-
-## Cycle de vie de l'historique
-
-### 1. Initialisation
-
-Au montage, l'historique est initialisé à `[0]` (état d'attente de `initialStep`).
-
-Quand `initialStep` arrive depuis la base de données (via l'API), le hook initialise **une seule fois** (`hasInitialized.current`). Il distingue deux cas :
-
-```
-histoire déjà > 1 élément   →  l'utilisateur a navigué avant l'arrivée d'initialStep
-                                → l'historique existant est conservé
-
-histoire = 1 élément         →  reprise de session (page rouverte à mi-parcours)
-                                → l'historique est reconstruit via le graphe
-                                → reconstructHistoryToStep(initialStep, template)
-```
-
-### 2. Navigation forward
-
-`goToNextStep` suit les edges du template (définis dans `template.edges`) pour trouver l'index du nœud suivant. Il appelle ensuite `setStep(nextIndex)`, qui ajoute l'index à l'historique :
-
-```
-[0] → [0, 1] → [0, 1, 3] → [0, 1, 3, 4]
-```
-
-> Note : les indexes ne sont pas nécessairement consécutifs (+1) car le graphe peut avoir des sauts ou des branches.
-
-### 3. Navigation backward — `goBack()`
-
-`goBack()` dépile l'historique et saute automatiquement les nœuds **auto-exécutants** :
-
-```typescript
-const AUTO_EXECUTING_TYPES = new Set(["external-verification", "condition"]);
-```
-
-Exemple avec un nœud `condition` au step 3 :
-
-```
-history: [0, 1, 3, 4]
-
-1. pop() → candidate: 3 (condition) → skipped
-2. pop() → candidate: 1 (information-input) → stop
-
-→ navigation vers step 1
-```
-
-`setStep` est appelé avec `skipHistory = true` pour ne pas polluer l'historique lors d'un retour.
-
-### Point de non-retour — `goToNextStepCommitted()`
-
-Certaines étapes payantes ou définitives, comme la validation biométrique du selfie, ne doivent
-pas pouvoir être rejouées. Elles avancent avec `goToNextStepCommitted()` : la destination est
-résolue via les mêmes edges et persistée comme avec `goToNextStep()`, puis l'historique devient
-`[nextStepIndex]`. Sur le nœud d'arrivée, `canGoBack` vaut donc `false` et aucun bouton Retour ne
-doit être rendu.
-
-Si la destination est auto-exécutante (`condition` ou `external-verification`), le commit est
-propagé jusqu'au premier nœud interactif. Lors d'un rechargement, la reconstruction tronque de
-même le chemin après le dernier selfie déjà franchi : le point de non-retour reste donc effectif
-sans ajouter de champ au contrat de session.
-
-Cette primitive est réservée aux points de non-retour métier explicites. Les autres nœuds
-continuent d'utiliser `goToNextStep()` et conservent leur historique normal.
-
-### 4. Déduplication
-
-`setStep` ne pousse jamais deux fois le même index consécutivement :
-
-```typescript
-setHistory((prev) => {
-  if (prev[prev.length - 1] === newStep) return prev;
-  return [...prev, newStep];
-});
-```
-
-Cela évite le doublon `[..., 4, 4]` qui se produisait quand `initialStep` arrivait de l'API alors que l'utilisateur était déjà sur ce step.
-
----
-
-## Reconstruction de l'historique (`reconstructHistoryToStep`)
-
-Définie dans `src/services/sessionService.ts`, cette fonction est utilisée lors d'une reprise de session.
-
-Elle suit les edges par défaut (première edge sortante de chaque nœud) depuis le step 0 jusqu'à `targetStep` :
-
-```typescript
-reconstructHistoryToStep(4, template)
-// → [0, 1, 2, 3, 4]  si le chemin linéaire existe dans le graphe
-// → [0, 4]           fallback si le graphe ne peut pas atteindre targetStep
-```
-
-> **Limitation** : la reconstruction suit toujours la première edge sortante de chaque nœud. Si le parcours réel a emprunté une branche conditionnelle (ex: `condition → true`), l'historique reconstruit peut différer du parcours original. Le retour sera correct tant que les nœuds intermédiaires sont rendus correctement.
-
----
-
-## Pièges courants
-
-### Ne pas utiliser `setStep(step - 1)` pour le bouton retour
-
-```typescript
-// INCORRECT — décrémentation arithmétique, ignore le graphe réel
-const goOnPreviousStep = () => setStep(step - 1);
-
-// CORRECT — utilise l'historique
-const goOnPreviousStep = () => goBack();
-```
-
-`step - 1` peut pointer vers un step inexistant (si les indexes ne sont pas consécutifs), ou sauter par-dessus des nœuds auto-exécutants qui doivent être ignorés.
-
-### Ne pas appeler `setStep` directement depuis un composant pour naviguer en avant
-
-Préférer `goToNextStep(node.id, template)` qui résout automatiquement l'index suivant via le graphe. `setStep` est réservé aux cas où l'index de destination est déjà connu (ex: reprise de session, `goBack`).
-
-### Reprise d'une session déjà terminée : ne jamais rejouer un nœud `end`
-
-La reprise se fait **par index** (`currentStep`) sur `getOrderedJourneySteps()` (nœuds triés par `order`, puis par `id`). Si le parcours est modifié après coup — par exemple un nœud `end` ajouté avec le même `order` qu'une étape existante — l'index persisté peut désigner un autre nœud qu'au moment de la sauvegarde. Une session rouverte peut alors « atterrir » sur une fin jamais empruntée, et `EndFlow` enverrait `ended` + l'id de cette fin au montage (incident Quadient, sept. 2026 : dossiers signés passés en `ai_rejected`).
-
-Protection : `isSessionFinished(status)` (`src/utils/sessionStatus.ts`) — vrai pour `ended` et les statuts consolidés (`verify`, `ai_approved`, `ai_rejected`, `user_approved`, `user_rejected`), **faux pour `conform`** (posé après la signature, avant le vrai nœud `end`). `useStepNavigation`, `TemplateNodeRenderer` et `SessionContent` l'utilisent pour afficher directement l'écran de fin ; pour un statut consolidé, `EndFlow` reçoit `alreadyFinished` : **aucun PATCH** au montage, écran calculé depuis le statut connu. Le backend ignore de son côté un second `ended` sur une session déjà terminée (voir `backend/docs/SESSION_STATUS_CALCULATION.md`).
-
-La reprise par index reste une limite connue : la remplacer par une reprise par id de nœud est un chantier séparé.
-
----
-
-## Fichiers de référence
-
-| Fichier | Rôle |
-|---------|------|
-| `src/hooks/useStepNavigation.ts` | Implémentation complète de l'historique |
-| `src/services/sessionService.ts` | `getOrderedJourneySteps`, `getNextStepIndex`, `reconstructHistoryToStep` |
-| `src/hooks/useUserInputForm.ts` | Exemple d'utilisation de `goBack()` dans un formulaire |
-| `src/components/session/ContactInfoForm.tsx` | Autre exemple de bouton retour correct |

package/docs/sdk_integration_guide.md

@@ -1,58 +0,0 @@
-# Intégration du SDK dans un projet Vite + React + TypeScript
-
-Ce guide explique comment intégrer manuellement le SDK dans un projet React TypeScript basé sur Vite.
-
-## Étapes à suivre
-
-### 1. Créer un nouveau projet Vite avec React et TypeScript
-
-```bash
-npm create vite@latest my-app -- --template react-ts
-cd my-app
-npm install
-```
-
-### 2. Nettoyer le projet
-
-Supprimez tous les fichiers dans `src/` sauf :
-
-- `main.tsx`
-- `App.tsx`
-
-Vous pouvez les modifier ensuite pour les adapter au SDK.
-
-### 3. Copier le contenu du `src/` du SDK
-
-Copiez **tout le contenu du dossier `src/`** du SDK dans le `src/` de ce nouveau projet **Vite**.
-
-> ⚠️ N'incluez **pas** le fichier `index.ts` du SDK, il peut entrer en conflit avec l’entrée du projet Vite.
-
-### 4. Mettre à jour les dépendances
-
-Ouvrez le `package.json` du SDK et copiez toutes les dépendances (`dependencies` et éventuellement `devDependencies`) dans celui du projet Vite.
-
-Ensuite, installez les nouvelles dépendances :
-
-```bash
-npm install
-```
-
-> ✅ Assurez-vous de ne pas écraser les dépendances existantes (comme `react`, `vite`, etc.). Fusionnez intelligemment les deux blocs.
-
-### 5. Lancer le projet
-
-Une fois tout copié et installé :
-
-```bash
-npm run dev
-```
-
-Votre projet est maintenant prêt avec le SDK intégré.
-
----
-
-## Notes
-
-- Si le SDK utilise des variables d’environnement, pensez à les définir dans un fichier `.env`.
-- Vérifiez les éventuels alias dans `tsconfig.json` et `vite.config.ts` si le SDK en dépend.
-- Si le SDK a des styles globaux, importez-les dans `main.tsx` ou `App.tsx`.