docs(hmr): flux HMR avec idnot via dev3 et state [skip ci]

docs/hmr-idnot-dev3-state-2025-09-24.md

@@ -0,0 +1,37 @@
+# Flux HMR avec idnot via dev3 et state (24/09/2025)
+
+## Objectif
+- Maintenir le **HMR** côté front (Next.js) sans casser le parcours d’auth **idnot** en s’appuyant sur un **state** serveur.
+
+## Acteurs / Ports
+- Front (Next.js, HMR): `:3000`
+- Backend mini: `:8080`
+- Nginx dev3: `dev3.4nkweb.com` (`443`/`80`), reverse vers `8080/300x/8090`
+- Callback idnot: `https://dev3.4nkweb.com/idnot/callback`
+
+## Création du state (front → back)
+- Route: `POST /api/v1/idnot/state` (via `src/routes/index.ts` → `StateHandlers.createState`).
+- Le back génère un `state` persisté côté serveur (via `SessionManager`) et le retourne au front.
+- CORS dynamique (`src/config/index.ts`) autorise `https://*.4nkweb.com` et l’`APP_HOST`.
+
+## Redirection idnot
+- Le front redirige l’utilisateur vers idnot avec le `state` fourni.
+- idnot renvoie ensuite vers `https://dev3.4nkweb.com/idnot/callback?code=...&state=...`.
+
+## Callback via Nginx dev3 → backend
+- `confs/nginx/dev3.4nkweb.com.conf`: location `= /idnot/callback` → proxy_pass backend `:8080`.
+- Le back (route `GET /idnot/callback`) lit `state`, vérifie côté `SessionManager`, consomme `code`, finalise login/attachement.
+
+## Pourquoi le HMR ne casse pas le flow
+- Le couplage se fait via le `state` stocké à chaud côté serveur, pas via l’état volatile du front.
+- Même si le front change de bundle (HMR), le `state` reste valide jusqu’au callback.
+- CORS permet au front HMR d’appeler le back sans friction.
+
+## Rôle de dev3
+- Point d’entrée HTTPS stable pour le callback.
+- Reverse proxy vers 8080 (back), 300x (front), 8090 (relay), avec 80 → 301 → HTTPS.
+- Gère les réécritures nécessaires (ex: `/storage`).
+
+## Résultat
+- HMR actif, parcours idnot fiable: le `state` maintenu côté back assure la continuité entre redirection et callback.
+