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

package/docs/README.md

@@ -1,254 +0,0 @@
-# Documentation Index
-
-## Quick Links
-
-### Core Documentation
-
-- **[JOURNEY_NODE_BUILDER.md](./JOURNEY_NODE_BUILDER.md)**
-  - Onboarding SDK journey runtime (steps, template nodes, navigation)
-  - How to add a new node safely
-
-- **[navigation-history.md](./navigation-history.md)**
-  - How the step history stack works
-  - `goBack()` vs `setStep()` — when to use which
-  - Session resume and history reconstruction
-  - Common pitfalls
-
-- **[POLLING_SYSTEM.md](./POLLING_SYSTEM.md)** ⭐ **START HERE**
-  - Complete guide to the enhanced polling system
-  - Status mapping and message reference
-  - API response examples
-  - Frontend integration examples
-  - Troubleshooting guide
-  - Database schema reference
-
-### Setup & Configuration
-
-- **[configuration.md](./configuration.md)**
-  - SDK configuration options
-  - Environment setup
-
-- **[dynamic-configuration.md](./dynamic-configuration.md)**
-  - Runtime configuration
-  - Dynamic settings
-
-- **[environment.md](./environment.md)**
-  - Environment variables
-  - Build configuration
-
-### Integration & Migration
-
-- **[sdk_integration_guide.md](./sdk_integration_guide.md)**
-  - How to integrate the SDK into your project
-  - Basic setup
-
-- **[migration-guide.md](./migration-guide.md)**
-  - Upgrading from previous versions
-  - Breaking changes
-
----
-
-## What's New (v2.0.0)
-
-### Enhanced Polling System ✨
-
-The polling system has been completely redesigned to support:
-
-✅ **Multiple analyses per session** - No more conflicts  
-✅ **Accurate progress tracking** - 50% vs 100%  
-✅ **User-friendly messages** - No technical jargon  
-✅ **Document codes** - Deterministic decision making  
-✅ **Real-time updates** - Every 2 seconds  
-✅ **Better error handling** - Distinction between network and analysis errors  
-
----
-
-## Quick Start
-
-### 1. Enable Polling
-
-```typescript
-import { analyzeFiles } from '@datakeen/session-react-sdk';
-
-const result = await analyzeFiles(
-  sessionId,
-  files,
-  documentTypeId,
-  {
-    enablePolling: true,
-    pollingOptions: {
-      onProgress: (status) => {
-        console.log(`${status.progress}%: ${status.message}`);
-      },
-      onComplete: (status) => {
-        console.log('Completed with code:', status.code);
-      },
-    },
-  }
-);
-```
-
-### 2. Understand Status Codes
-
-| Code | Meaning | Action |
-|------|---------|--------|
-| `1.0` | ✅ Approved | Proceed |
-| `2.0` | ❌ Rejected | Show error, allow retry |
-| `3.0` | ❌ Error | Show error, allow retry |
-| `4.0` | ⏳ To Verify | Show pending, wait for manual review |
-
-### 3. Handle Different Outcomes
-
-```typescript
-switch (status.code) {
-  case '1.0': // Approved
-    proceedToNextStep();
-    break;
-  case '2.0': // Rejected
-  case '3.0': // Error
-    showErrorAndAllowRetry();
-    break;
-  case '4.0': // To Verify
-    showPendingMessage();
-    break;
-}
-```
-
----
-
-## Status Reference
-
-### Progress Levels
-
-- **50%** - Analysis is processing (`analysisId = null`)
-- **100%** - Analysis is complete (`analysisId = set`)
-
-### Status Messages
-
-- 50% → "Analyzing your documents..."
-- 100% Approved → "Document verified successfully ✓"
-- 100% Rejected → "Document verification failed"
-- 100% To Verify → "Manual verification required"
-- 100% Error → "Analysis error occurred"
-
-### Backend Statuses
-
-- `ai_approved` → Code `1.0` (Approved)
-- `ai_rejected` → Code `2.0` (Rejected)
-- `to_verify` → Code `4.0` (To Verify)
-- `failed` / `error` → Code `3.0` (Error)
-
----
-
-## Common Tasks
-
-### Display Progress to User
-
-See **[POLLING_SYSTEM.md - React Component Example](./POLLING_SYSTEM.md#react-component-example)**
-
-### Handle Multiple Analyses
-
-See **[POLLING_SYSTEM.md - Multiple Analyses Per Session](./POLLING_SYSTEM.md#multiple-analyses-per-session)**
-
-### Create Reusable Hook
-
-See **[POLLING_SYSTEM.md - React Hook for Reusability](./POLLING_SYSTEM.md#react-hook-for-reusability)**
-
-### Debug Polling Issues
-
-See **[POLLING_SYSTEM.md - Troubleshooting](./POLLING_SYSTEM.md#troubleshooting)**
-
-### Check Database State
-
-See **[POLLING_SYSTEM.md - Monitoring & Debugging](./POLLING_SYSTEM.md#monitoring--debugging)**
-
----
-
-## Architecture
-
-### Backend (NestJS)
-
-**File**: `src/session/session.service.ts`
-
-Key methods:
-- `getAnalysisStatus(sessionId)` - Get current analysis status
-- Uses `analysisId = null` for processing
-- Uses `analysisId = set` for completed
-- Extracts document code from database
-
-### Frontend (React)
-
-**File**: `src/services/pollingService.ts`
-
-Key features:
-- Polls `/session/sdk/{sessionId}/analysis-status` every 2 seconds
-- Converts backend status to user-friendly messages
-- Triggers callbacks: `onProgress`, `onComplete`, `onFailed`
-
-**Component**: `src/components/jdi/JDIProcessing.tsx`
-
-Displays:
-- Progressive step indicators
-- Real-time status messages
-- Final result with appropriate icons
-
----
-
-## Performance
-
-| Metric | Value |
-|--------|-------|
-| Polling interval | 2 seconds |
-| Max polling duration | 10 minutes |
-| Typical analysis time | 5-30 seconds |
-| Request size | ~300 bytes |
-| Response size | ~400 bytes |
-
----
-
-## Support
-
-### For Issues:
-
-1. Check **[POLLING_SYSTEM.md - Troubleshooting](./POLLING_SYSTEM.md#troubleshooting)**
-2. Check browser console logs
-3. Check backend logs: `grep "SESSION" /var/log/app-backend.log`
-4. Check database state using the debugging queries
-
-### For Implementation Questions:
-
-See the example files:
-- `examples/analysis-progress-example.tsx` - Complete working example
-- Look at `src/components/jdi/JDIProcessing.tsx` for real-world usage
-
----
-
-## Version History
-
-### v2.0.0 (Current - November 5, 2025)
-
-✨ **Major Release**
-
-- ✅ Enhanced polling system
-- ✅ Support for multiple analyses per session
-- ✅ Document codes in response
-- ✅ User-friendly status messages
-- ✅ Real-time progress updates
-- ✅ Better error handling
-
-**Migration**: Backward compatible, no breaking changes
-
----
-
-## Next Steps
-
-1. **Read** [POLLING_SYSTEM.md](./POLLING_SYSTEM.md) for complete details
-2. **Check** the examples in `examples/analysis-progress-example.tsx`
-3. **Review** `src/components/jdi/JDIProcessing.tsx` for implementation
-4. **Test** with your documents
-5. **Deploy** with confidence!
-
----
-
-**Last Updated**: November 5, 2025  
-**Status**: ✅ Production Ready

package/docs/SESSION_TOKEN_MIGRATION.md

@@ -1,52 +0,0 @@
-# Migration vers les sessions authentifiées
-
-Le backend protégé refuse l'identifiant de session seul. L'intégrateur récupère
-`token` et `sessionURL` lors de la création côté serveur et remet uniquement le
-credential de cette session à son utilisateur final.
-
-```tsx
-const { SessionComponent } = useSession(sessionId, config, apiBaseUrl, sessionToken);
-// ou : <DatakeenSession sessionId={sessionId} sessionToken={sessionToken} />
-```
-
-Le paramètre est additif côté TypeScript pour les anciens backends, mais requis
-à l'exécution avec le backend durci. `SessionConfig.sessionToken` est aussi accepté.
-Le lien généré par le backend contient `#sessionToken=...` : le fragment n'est pas
-transmis au serveur HTTP ou dans le Referer. Le SDK le lit en mémoire et transmet
-`X-Session-Token` uniquement aux routes de la session correspondante. Le QR de
-transfert mobile conserve ce fragment. Ne pas enregistrer ce lien dans les logs.
-
-Les appels directs doivent transmettre cet en-tête. Les médias générés/signés
-sont chargés par Axios authentifié puis ouverts via une URL Blob locale, révoquée
-au démontage. Aucun credential n'est ajouté à une URL de média.
-
-## Fenêtre de compatibilité
-
-Le backend expose `SESSION_TOKEN_ENFORCED`, **à `false` par défaut**. Pendant cette
-période :
-
-- les liens de session déjà envoyés par courriel ou SMS continuent de fonctionner ;
-- une intégration restée sur une version antérieure du SDK continue de fonctionner ;
-- le backend journalise un avertissement par session
-  (`accessed without X-Session-Token`), ce qui permet d'inventorier les liens
-  encore en circulation ;
-- la tolérance ne s'applique qu'à l'utilisateur final, sur une route du parcours.
-  Les routes purement backoffice (selfie, vidéos et aperçus recto/verso, résumé,
-  chat, informations client) exigent un credential dès le premier jour.
-
-Ordre de déploiement : livrer le backend, puis le backoffice, puis publier le SDK ;
-renouveler les liens et faire migrer les intégrateurs qui construisent leurs liens
-eux-mêmes ; enfin basculer `SESSION_TOKEN_ENFORCED=true` pour fermer la fenêtre.
-Aucune publication de package n'est effectuée par cette migration de source.
-
-## Écriture de l’audit trail
-
-`POST /session/audit-trail` exige désormais un token de session, indépendamment
-de SESSION_TOKEN_ENFORCED. Le SDK joint X-Session-Token depuis son stockage mémoire
-pour l’analysisId (identifiant de session historique) de l’événement. Il n’envoie
-jamais ce token dans une URL. Le serveur impose la cible et refuse toute attribution
-à un opérateur fournie par le client. Les valeurs de userInputs et les métadonnées
-libres ne sont plus conservées : l’audit ne garde que les noms des champs transmis.
-Les lectures de timeline restent réservées au backoffice avec AUDIT_TRAIL:READ.
-Livrer cette version du SDK et fournir sessionToken aux intégrations pour continuer
-à enregistrer les événements du parcours, dont l’ouverture et la fin de signature.