# 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`](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 ```text 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`](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`