smart_ide/services/docv/enso-docs/PLAN_REALISATION_DOCV_ENSO.md

Plan de réalisation — docv / enso

Ce document décrit le plan de réalisation du monorepo enso pour docv (socle commun, backend Rust, front moderne, PostgreSQL dédiée) et enso (avocats). docv est hérité par enso pour les structures et données par défaut. Le projet reprend les règles de lint et les règles Cursor du projet (voir section 10).

---

1. Modèle d’héritage (récap)

Dimension	docv	enso
Base de données	Sa BDD ; porte la structure et les données par défaut pour tous	Sa BDD (hérite structure/défauts docv)
Textes (i18n)	Ses textes ; porte la structure des textes et textes par défaut pour tous	Ses textes (hérite structure/défauts docv)
Design / front	Son design ; porte la structure des fronts et le design par défaut pour tous	Son design (hérite structure/défauts docv)
Rôles	Son paramétrage ; porte la structure des rôles et rôles par défaut pour tous	Son paramétrage rôles (hérite docv)
Documents	Son paramétrage ; porte la structure des documents et paramétrage par défaut pour tous	Son paramétrage documents (hérite docv)
Dossiers	Son paramétrage ; porte la structure des dossiers et paramétrage par défaut pour tous	Son paramétrage dossiers (hérite docv)
Membres des rôles	Son paramétrage ; porte la structure des membres et membres par défaut pour tous	Son paramétrage membres (hérite docv)
API tiers	Consomme API IA et API d’ancrage (serveur services, projet Bitcoin api-anchorage)	Consomme API IA + ancrage côté back uniquement

• docv : socle commun avec backend Rust, front moderne/propre, et PostgreSQL dédiée. Pour le code partagé back/front (validation, formatage, constantes, règles métier pures), utiliser WebAssembly (WASM) si c’est plus pratique : une crate Rust partagée (ex. docv-shared) compilée en natif pour les backs et en WASM pour les fronts.
• enso : hérite docv (structure + défauts) ; données, textes, design et paramétrages propres au périmètre avocat. Les API externes (ancrage, IA) sont consommées par les backends exclusivement ; les fronts n’appellent que enso-back. L’API d’ancrage est celle du serveur services (infra 4NK), projet Bitcoin api-anchorage. L’API IA est développée dans le sous-module Git ai (https://git.4nkweb.com/4nk/ai.git), en TypeScript ; voir section 2ter du document d’architecture.

---

2. Phases et ordre de réalisation

Phase 0 — Cadrage et règles (préalable à tout code)

• Environnement de développement : la machine dispose d’Ollama, Obsidian, AnythingLLM, Node.js, PostgreSQL, et de modèles préinstallés pour Ollama et AnythingLLM. L’API IA consommée par les backends s’appuie sur ce socle et est développée dans le sous-module ai.
• Sous-module Git ai : importer le dépôt https://git.4nkweb.com/4nk/ai.git en sous-module (ex. git submodule add https://git.4nkweb.com/4nk/ai.git ai depuis la racine enso, après validation). Ce sous-module sert à développer l’API IA en TypeScript et à interagir avec le socle IA (Ollama, AnythingLLM). Les backends docv et enso consomment cette API ; ils n’appellent pas directement Ollama ou AnythingLLM.
• Définir et versionner les règles Cursor du projet (.cursor/rules/) : reprise des règles qualité, lint, clôture évolution, correction d’erreurs (cf. section 10).
• Créer la structure du monorepo (workspaces, docs/, deploy/, .secrets/) et le fichier de règles de lint (ESLint / équivalent Rust) aligné sur les règles Cursor (max-lines, max-lines-per-function, max-params, complexity, etc.).
• Documenter dans docs/ : architecture (déjà en place), plan de réalisation (ce document), conventions de code et lint (référence aux règles Cursor).
• Livrable : repo enso structuré, règles Cursor et lint appliquables, pas encore de code métier.

---

Phase 1 — docv (socle commun)

Objectif : application docv autonome, parité fonctionnelle avec la cartographie des écrans (docs/SCREENS_AND_FUNCTIONS_MAP.md) mais réécrite, avec backend Rust, front moderne, PostgreSQL dédiée, et portage des structures + données par défaut pour tous.

1.1 Backend docv (Rust)

• Choix du stack Rust : framework HTTP (Axum / Actix), connexion PostgreSQL (SQLx ou Diesel), migrations, logging structuré, gestion d’erreurs typées.
• Code partagé back/front : si plus pratique, introduire une crate Rust partagée (ex. docv-shared) compilable en natif (pour docv-back et enso-back) et en WASM (pour les frontends via wasm-bindgen / wasm-pack). Y mettre validation, formatage, constantes, règles métier pures ; utiliser WASM dès que cela évite la duplication et garantit la même logique partout.
• Schéma BDD docv : reprendre les entités métier attendues (users, contacts, addresses, offices, office_folders, document_types, roles, office_roles, role_permissions_matrix, site_texts, system_configuration, etc.) en une structure agnostique (sans champs réservés à un métier notaire dans le noyau).
• Migrations SQL versionnées ; données de référence par défaut : rôles, permissions, types de documents, structure des dossiers, textes site, configuration système (clés communes).
• API REST (ou équivalent) : auth (agnostique, sans IdNot), CRUD dossiers, documents, membres, rôles, paramétrage documents/dossiers, textes (i18n), configuration.
• API IA et API d’ancrage : les backends consomment l’API d’ancrage (serveur services, projet Bitcoin api-anchorage) et l’API IA (développée dans le sous-module ai, TypeScript, qui s’appuie sur Ollama, AnythingLLM et les modèles préinstallés). Aucune de ces API n’est appelée par les frontends (consommation back exclusivement).
• Logging, validation des entrées, pas de secrets en dur, respect des règles Cursor (pas de fallback, erreurs remontées, pas de contournement).
• Livrable : service Rust docv qui démarre, expose les endpoints, lit/écrit la BDD docv, et consomme les API ancrage (services, api-anchorage) et IA depuis le back uniquement.

1.2 Frontend docv (moderne / propre)

• Stack front : choix (ex. Next.js ou autre) aligné avec « moderne et propre » ; pas de reprise à l’identique d’une base front historique externe.
• Code partagé avec le back : si une crate Rust partagée est compilée en WASM (ex. docv-shared), l’importer dans le front (wasm-pack pkg/) pour validation, formatage, constantes ; utiliser WASM lorsque c’est plus pratique que de dupliquer la logique en TypeScript.
• Structure des écrans et fonctionnalités : couvrir toutes les fonctionnalités décrites dans la cartographie (dossiers, documents, rôles, membres, paramétrage, textes, etc.) mais réécrites (composants, hooks, appels API).
• Design system docv : structure des thèmes, composants de base, tokens (couleurs, typo, espacements) ; design par défaut utilisable comme base par enso.
• Consommation de l’API docv ; gestion d’état, erreurs, chargements ; textes via structure i18n (clés + défauts docv).
• Respect des règles Cursor : helpers centralisés, pas de code mort, max-lines / max-lines-per-function, typecheck, lint.
• Livrable : front docv utilisable en autonome sur la BDD et le back docv.

1.3 Données et paramétrage par défaut (docv)

• BDD : seeds / migrations pour rôles par défaut, matrice de permissions par défaut, types de documents par défaut, structure dossiers par défaut, membres/rôles par défaut.
• Textes : structure des clés (scope, locale, version) + jeu de textes par défaut (fr, en).
• Configuration : clés system_configuration (ou équivalent) par défaut pour toute l’app.
• Livrable : une instance docv déployée contient toutes les structures et données par défaut réutilisables pour enso.

---

Phase 2 — enso (avocats)

• Création des répertoires enso-front et enso-back (mêmes langages et frameworks que docv : Rust pour le back, même stack front que docv-front).
• Code : héritage de docv ; pas de duplication. Configuration : BDD enso, seeds, paramétrage (écrans, actions, options, rôles, types de documents/dossiers, textes, thème). Spécifiques : tout spécifique enso (écrans, actions, services, intégrations) doit être listé et confirmé avant implémentation ; voir docs/features/SPECIFIQUES_PROJETS.md.
• BDD enso : schéma dérivé de la structure docv (migrations SQL, même modèle logique) ; données spécifiques avocat (pas de données notaire).
• Backend enso (Rust) : même stack que docv-back ; consomme les API externes (ancrage : serveur services, api-anchorage ; IA) côté back uniquement ; logique métier avocat (dossiers, mandats, etc.) dans services/lawyer/ ; pas d’IdNot, pas de Mailchimp/OVH/Stripe/API notaire.
• Front enso : même stack que docv-front ; héritage du design system docv (structure + défauts) ; surcharges thème/couleurs/texte pour « enso » ; textes et paramétrages spécifiques avocat.
• Textes, rôles, documents, dossiers, membres : structure identique à docv ; données et paramétrages spécifiques enso (avec possibilité d’importer les défauts docv en amont).
• Livrable : application enso déployable avec sa BDD, ses textes, son design, ses paramétrages ; les API (ancrage, IA) sont consommées par enso-back uniquement.

---

Phase 3 — hors périmètre actuel du dépôt

Produit métier notaire : non suivi dans ce clone pour l’instant. Orientation : docs/HORS_PERIMETRE_NOTAIRE.md.

---

Phase 4 — Convergence et qualité

• Documentation : mettre à jour docs/ARCHITECTURE_DOCV_ENSO.md et docs/PLAN_REALISATION_DOCV_ENSO.md avec l’état réel (Rust, stack front, schémas BDD).
• Règles Cursor et lint : vérifier que tout le code docv et enso respecte les règles ; corriger les écarts ; pas de contournement de lint.
• Déploiement : scripts dans deploy/ pour build et déploiement de docv et enso (avec leurs BDD respectives).
• Clôture : pour chaque livrable, appliquer le workflow de clôture (helpers, i18n, fallback, modifications similaires, optimisation, sécurité, code mort, lint, types, compilation, documentation).

---

3. Dépendances entre phases

Phase 0 (Cadrage) ──────────────────────────────────────────────────────────┐
       │                                                                     │
       ▼                                                                     │
Phase 1 (docv) ───► Backend Rust + BDD + consommation API ancrage (services, api-anchorage) + API IA                       │
       │           Front moderne + design system + structure textes/rôles/…   │
       │                                                                     │
       ├────────────────────────────────────────────────────────────────────┤
       ▼                                                                     │
Phase 2 (enso) ───► BDD enso, back enso, front enso (héritent docv)         │
       │                                                                     │
       ▼                                                                     │
Phase 4 (Convergence) ──► Doc, lint, déploiement, clôture                   │

• Phase 1 doit être suffisamment avancée (structure BDD + API + design system) pour qu’enso puisse « hériter » (structure + défauts).
• Les backends docv et enso consomment l’API d’ancrage (serveur services, projet api-anchorage) et l’API IA (sous-module ai, TypeScript, socle Ollama/AnythingLLM) ; ces API doivent être accessibles et contrats stables avant intégration.

---

4. Récapitulatif des livrables par phase

Phase	Livrables principaux
0	Monorepo structuré ; règles Cursor et lint définies et appliquées ; docs d’architecture et plan à jour.
1	Backend docv (Rust), crate docv-shared (natif + WASM si pertinent), BDD docv (structure + données par défaut), consommation API ancrage (services, api-anchorage) + API IA (sous-module ai, TypeScript, socle Ollama/AnythingLLM ; back uniquement) ; front docv (écrans complets, design system, textes/rôles/documents/dossiers/membres par défaut ; pas d’appel direct aux API externes).
2	BDD enso ; backend enso (Rust, consomme API ancrage + IA côté back uniquement) ; front enso (même stack que docv-front, hérite design/textes/paramétrages docv, surcharges avocat).
3	— hors périmètre actuel du dépôt — voir HORS_PERIMETRE_NOTAIRE.md.
4	Documentation à jour ; conformité Cursor/lint ; scripts de déploiement ; clôture des évolutions.

---

5. Règles Cursor et lint à respecter

Le projet doit reprendre les règles de lint et les règles Cursor du projet. À intégrer dans .cursor/rules/ et dans la config lint (ESLint pour le front/TypeScript, Clippy / format pour Rust) :

• Général : répondre en français ; code, documentation et commits en anglais ; ne pas écrire en base (scripts dédiés) ; ne pas masquer les sorties ; pas de certificats auto-signés ; pas de modification des variables d’environnement ; pas d’alternative HTTP à HTTPS ; validation avant déploiement/certificats ; pas d’exécution en arrière-plan.
• Processus : priorité aux questions posées ; validation avant implémentation ; identifier et corriger la root cause avant de corriger les bugs ; pas de contournement.
• Qualité : clôture systématique (helpers, i18n, fallback, modifications similaires, optimisation, sécurité, code mort, lint, types, compilation, documentation) ; vérification des fichiers (logs, code mort, commentaires) ; pas de bypass lint par commentaires.
• Code : factorisation et réutilisation ; pas de code mort ; max 250 lignes/fichier, 40 lignes/fonction ; max-params 4, max-depth 4, complexity 10, max-nested-callbacks 3 ; pas de lazy imports ; imports par défaut nommés ; types de retour explicites ; pas de any ; gestion d’erreurs explicite, pas de fallback implicite.
• Sécurité : validation des entrées ; pas de secrets en dur ; pas de log de données sensibles ; soft-delete pris en compte.
• Documentation : mise à jour de docs/ (features, fixKnowledge, architecture) ; rationalisation ; pas de doublons.
• Commits : format avec Motivations, Root causes, Correctifs, Evolutions, Pages affectées ; auteur 4NK ou Nicolas Cantu uniquement (pas de Co-authored-by Cursor).

Pour le backend Rust : définir des règles équivalentes (format, Clippy, pas de unwrap en production, erreurs typées, logging structuré) et les documenter dans docs/.

Règles de coding spécifiques au projet (placement du code, API, auth, paramétrage, conventions, interdictions) : docs/REGLES_CODING_PROJET.md.

---

6. Références

• Plan de développement (jalons et ordre des travaux) : docs/PLAN_DEVELOPPEMENT.md
• Architecture, structure détaillée de chaque sous-projet et API externes / socle IA : docs/ARCHITECTURE_DOCV_ENSO.md (sections 2bis, 2ter, 3 et 3.1 à 3.4)
• Point d’entrée documentation docv : docs/docv/README.md (périmètre docv, zones 1–15, ordre de réalisation Phase 1)
• Point d’entrée documentation enso : docs/enso/README.md (périmètre enso, zones 1–15 + 17, correspondance spécifiques E1–E31, liens specs/IMPL/référentiel)
• Périmètre notaire (hors dépôt actuel) : docs/HORS_PERIMETRE_NOTAIRE.md
• Cartographie écrans et fonctions : docs/SCREENS_AND_FUNCTIONS_MAP.md (wording générique, référence pour docv et enso)
• Spécifications par fonctionnalité : docs/features/specs/README.md (référentiel des specs par zone : objectif, écrans, actions, règles métier, API, déploiement, analyse)
• Référentiel écrans et actions : docs/features/REFERENTIEL_ECRANS_ACTIONS.md (identifiants stables, routes, actions 18.x)
• Description technique d’implémentation : docs/features/implementation/README.md (IMPL_xx par zone : routes, front, back, BDD)
• Règles Cursor : à créer dans .cursor/rules/ en reprenant les modèles qualité / lint / clôture / correction d’erreurs déjà utilisés sur les dépôts 4NK.
• Référence fonctionnelle : cartographie et specs dans docs/ (sans dépendre d’un dépôt applicatif externe dans ce clone).
• Sous-module API IA : https://git.4nkweb.com/4nk/ai.git (TypeScript, interaction avec Ollama, AnythingLLM)
• Grands principes IA (dossier ↔ workspace AnythingLLM, librairies, workflow cloud optionnel, Cursor instrumenté) : docs/features/IA_GRANDS_PRINCIPES.md