Nicolas Cantu
bc3c75e15f
- Copy enso/docs tree to services/docv/enso-docs (refresh via cp -a from enso repo) - Document mirror and refresh command in services/docv/README.md - Ignore services/docv/target for local Rust workspace - Track docv-service-integration, API docv.md, and related doc index updates
439 lines
27 KiB
Markdown
439 lines
27 KiB
Markdown
# Proposition de découpage et organisation — docv / enso
|
||
|
||
Ce document décrit une organisation possible du dépôt **enso** pour héberger le socle commun **docv** (agnostique métier) et la déclinaison **enso** (avocats). **Périmètre actuel du dépôt :** implementation et documentation centrées sur docv et enso ; les sections historiques mentionnant d’autres dépôts ou produits restent comme référence sans livraison dans ce clone.
|
||
|
||
---
|
||
|
||
## 1. Objectif
|
||
|
||
- **docv** : partie rendue commune et agnostique (types, contrats, i18n de base, utilitaires, éventuellement composants UI de base). Pour la logique partagée entre back et front, utiliser **WebAssembly (WASM)** si c’est plus pratique (crate Rust compilée en natif + WASM).
|
||
- **enso** : déclinaison pour les avocats (front + back consommant docv).
|
||
|
||
**Consommation prioritaire des API docv (docv-back) par les fronts produits pour le périmètre métier commun.** Détail d’implémentation (zones, stack, surface API) : [docs/docv/IMPLEMENTATION.md](docv/IMPLEMENTATION.md) (entête) ; déclinaison **enso** : [docs/enso/README.md](enso/README.md) §4.1.
|
||
|
||
### 1bis. Paramétrabilité des écrans, actions et options
|
||
|
||
Chaque **écran**, chaque **action** (fonctionnalité) et chaque **option d’implémentation** doit être **paramétrable** (activation, visibilité, droits, libellés, choix techniques ou métier) sans modification de code. Les niveaux de paramétrage sont : plateforme, office, type de dossier, rôle, préférence utilisateur. Référence : `docs/SCREENS_AND_FUNCTIONS_MAP.md` (principe de paramétrabilité) et `docs/features/PARAMETRAGE_ECRANS_ACTIONS.md`.
|
||
|
||
### 1ter. Code dans docv, configuration et spécifiques dans enso
|
||
|
||
- **Code** : le code applicatif (back et front) est développé dans **docv**. docv porte la structure, les composants, les services, les écrans et les actions génériques (agnostiques métier).
|
||
- **Configuration** : le projet **enso** **configure** ce qu’il utilise (paramétrage des écrans, des actions, des options d’implémentation, des données par défaut : rôles, types de documents, types de dossiers, textes, thème). Pas de duplication de code : il hérite docv et surcharge par configuration (BDD, seeds, system_configuration, paramétrage par office).
|
||
- **Spécifiques uniques** : **enso** peut avoir des **spécifiques uniques** (écrans, actions, services métier, intégrations API ou libellés non présents dans docv). Chaque spécifique doit être **listé et confirmé** avant implémentation. Aucun spécifique ne doit être codé sans avoir été validé et documenté. Référence : `docs/features/SPECIFIQUES_PROJETS.md`.
|
||
- **Authentification** : docv fournit un **login par défaut** (identifiant / mot de passe, session, choix d’office) pour tous les types de membres (rôles, dossiers, offices). **enso** l’utilise par défaut.
|
||
|
||
---
|
||
|
||
## 2. Référence fonctionnelle (sans dépôt applicatif externe obligatoire)
|
||
|
||
La cartographie des écrans et des règles attendues est tenue dans `docs/SCREENS_AND_FUNCTIONS_MAP.md`, les specs par zone dans `docs/features/specs/`, et les spécifiques enso dans `docs/features/SPECIFIQUES_PROJETS.md`. Aucun autre dépôt n’est requis dans ce clone pour décrire ou implémenter docv / enso.
|
||
|
||
---
|
||
|
||
## 2bis. API externes et consommation côté back uniquement
|
||
|
||
- **API d’ancrage** : c’est celle du serveur **services** (infrastructure 4NK), dans son projet Bitcoin **api-anchorage**. Service externe ; les backends **docv** et **enso** la **consomment** (aucune implémentation de l’API d’ancrage dans le dépôt enso).
|
||
- **Consommation des API** : **toutes les API externes** (ancrage, IA, etc., selon le périmètre déployé) sont **consommées par les backends exclusivement**. Les frontends n’appellent que leur propre backend ; ils ne parlent jamais directement aux API tierces.
|
||
- **API IA** : développée dans un **sous-module Git** `ai` (dépôt https://git.4nkweb.com/4nk/ai.git), en **TypeScript**, pour interagir avec le socle IA de la machine (voir section 2ter).
|
||
|
||
---
|
||
|
||
## 2ter. Environnement de développement et socle IA
|
||
|
||
La machine de développement dispose de :
|
||
|
||
- **Ollama**, **AnythingLLM**, **Obsidian**
|
||
- **Node.js**, **PostgreSQL**
|
||
- **Modèles préinstallés** pour Ollama et AnythingLLM
|
||
|
||
L’**API IA** consommée par les backends (**docv**, **enso**) est développée dans un **sous-module Git** :
|
||
|
||
- **URL** : https://git.4nkweb.com/4nk/ai.git
|
||
- **Rôle** : développer l’API IA en **TypeScript** et faire le lien avec ce socle IA (Ollama, AnythingLLM, modèles préinstallés).
|
||
- **Intégration** : le dépôt enso doit importer ce dépôt en **sous-module Git** (ex. `ai/` à la racine ou dans un répertoire dédié). Les backends appellent cette API IA (ex. service local ou déployé) ; ils ne parlent pas directement à Ollama ou AnythingLLM.
|
||
- **Grands principes IA** : dossier synchronisé sur un workspace AnythingLLM ; pré-traitement par librairies (traductions vers anglais uniquement, extractions vers JSON uniquement, vérification de vraisemblance des codes/IDs/clés en amont, prétraitement images/formats non convertibles) ; IA pour les opérations demandées ; workflow optionnel (anonymisation, décontextualisation, appel IA cloud, recontextualisation) ; déclenchement des fonctionnalités IA via un Cursor instrumenté pour l’API, avec utilisation systématique des agents, subagents, commandes, skills et plans par le code et les hooks. Détail : `docs/features/IA_GRANDS_PRINCIPES.md`.
|
||
|
||
Commande pour ajouter le sous-module (à exécuter depuis la racine du dépôt enso, après validation) :
|
||
|
||
```bash
|
||
git submodule add https://git.4nkweb.com/4nk/ai.git ai
|
||
```
|
||
|
||
---
|
||
|
||
## 3. Structure détaillée de chaque sous-projet
|
||
|
||
### 3.0 Code partagé back/front et WebAssembly
|
||
|
||
Lorsque du **code doit être partagé entre backends (Rust) et frontends** (ex. validation, formatage, constantes, règles métier pures), **utiliser WebAssembly (WASM) si c’est plus pratique** que de dupliquer la logique (ex. en TypeScript côté front et Rust côté back) ou que de maintenir deux implémentations.
|
||
|
||
- **Principe** : une **crate Rust partagée** (ex. `docv-shared`) est compilée :
|
||
- en **natif** pour les backends (docv-back, enso-back), qui l’utilisent comme dépendance Rust classique ;
|
||
- en **WASM** (`target wasm32-unknown-unknown` ou `wasm32-wasi`) pour les frontends, qui l’importent via `wasm-bindgen` / `wasm-pack` (ou équivalent) et l’appellent depuis le JavaScript/TypeScript.
|
||
- **Contenu typique** : validation de champs, formatage dates/montants, constantes métier, codes erreur, règles de calcul ou de cohérence sans I/O. Tout ce qui est pure logique et doit être identique back et front.
|
||
- **Quand privilégier WASM** : logique partagée non triviale, besoin de garantir la même implémentation partout, réutilisation déjà en Rust côté back. **Quand ne pas forcer WASM** : simple partage de types/contrats (garder docv-core en TS ou génération depuis OpenAPI), ou logique très légère où le coût d’intégration WASM (build, chargement) l’emporte.
|
||
- **Place dans l’arborescence** : la crate partagée vit sous docv (ex. `docv/docv-shared/`) et est consommée par docv-back, docv-front (en WASM), et éventuellement par enso-back, enso-front si la logique est commune.
|
||
|
||
Les arborescences ci-dessous décrivent la structure cible de chaque sous-projet. **Les backends** (**docv**, **enso**) utilisent **le même langage et les mêmes frameworks** (Rust, même stack HTTP et PostgreSQL). **Les frontends** (**docv**, **enso**) utilisent **le même langage et les mêmes frameworks** (ex. Next.js, TypeScript). docv inclut un backend Rust et un frontend ; **enso** a un front et un back sur cette même base technique, qui consomment ou héritent de docv.
|
||
|
||
### 3.1 docv
|
||
|
||
**Documentation dédiée docv :** point d’entrée `docs/docv/README.md` (périmètre zones 1–15, ordre de réalisation Phase 1, liens vers specs et implémentation).
|
||
|
||
docv est le socle commun : backend Rust, frontend moderne, BDD PostgreSQL dédiée. Il porte les structures et données par défaut (BDD, textes, design, rôles, documents, dossiers, membres). Pour l’ancrage et l’IA : les backends **consomment** l’API d’ancrage (serveur services, projet Bitcoin api-anchorage) et les API IA ; ces API ne sont jamais appelées depuis les fronts (voir section 2bis).
|
||
|
||
```text
|
||
docv/
|
||
├── package.json # Workspace root docv (scripts build/lint pour front + back)
|
||
├── Cargo.toml # Workspace Rust (docv-shared, docv-back)
|
||
│
|
||
├── docv-shared/ # Crate Rust partagée back/front (optionnel WASM)
|
||
│ ├── Cargo.toml # lib, target natif + [target.'cfg(target_arch = "wasm32")'].dependencies (wasm-bindgen)
|
||
│ ├── src/
|
||
│ │ ├── lib.rs
|
||
│ │ ├── validation/ # Règles de validation (réutilisées back + front via WASM)
|
||
│ │ ├── format/ # Formatage dates, montants, etc.
|
||
│ │ ├── constants/ # Codes erreur, limites, paramètres métier
|
||
│ │ └── rules/ # Règles métier pures (sans I/O)
|
||
│ └── pkg/ # Sortie wasm-pack (si WASM) pour import front
|
||
│
|
||
├── docv-back/ # Backend Rust
|
||
│ ├── Cargo.toml
|
||
│ ├── .env.example
|
||
│ ├── migrations/ # Migrations SQL versionnées
|
||
│ │ └── *.sql
|
||
│ ├── seeds/ # Données par défaut (rôles, permissions, document_types, site_texts, etc.)
|
||
│ │ └── *.sql
|
||
│ ├── src/
|
||
│ │ ├── main.rs # Point d’entrée
|
||
│ │ ├── config/ # Configuration (env, db, app)
|
||
│ │ ├── db/ # Connexion pool, migrations
|
||
│ │ ├── error/ # Types d’erreur, mapping HTTP
|
||
│ │ ├── handlers/ # Handlers HTTP par ressource
|
||
│ │ │ ├── auth.rs
|
||
│ │ │ ├── folders.rs
|
||
│ │ │ ├── documents.rs
|
||
│ │ │ ├── offices.rs
|
||
│ │ │ ├── users.rs
|
||
│ │ │ ├── roles.rs
|
||
│ │ │ ├── site_texts.rs
|
||
│ │ │ ├── system_configuration.rs
|
||
│ │ │ └── ...
|
||
│ │ ├── services/ # Logique métier
|
||
│ │ │ ├── folder_service.rs
|
||
│ │ │ ├── document_service.rs
|
||
│ │ │ ├── auth_service.rs
|
||
│ │ │ ├── anchoring/ # Client vers API ancrage (serveur services, projet api-anchorage)
|
||
│ │ │ └── ia/ # Client vers API IA (sous-module ai, TypeScript, socle Ollama/AnythingLLM)
|
||
│ │ ├── models/ # Entités / DTOs (sérialisation)
|
||
│ │ ├── repositories/ # Accès BDD (requêtes)
|
||
│ │ ├── middleware/ # Auth, logging, rate limit, CORS
|
||
│ │ └── routes.rs # Agrégation des routes
|
||
│ └── logs/ # Logs applicatifs (hors dépôt ou .gitignore)
|
||
│
|
||
├── docv-front/ # Frontend (Next.js ou équivalent)
|
||
│ ├── package.json
|
||
│ ├── tsconfig.json
|
||
│ ├── next.config.* (ou équivalent)
|
||
│ ├── .env.example
|
||
│ ├── public/
|
||
│ │ └── ...
|
||
│ ├── src/
|
||
│ │ ├── app/ # App router (si Next.js App Router) ou pages/
|
||
│ │ │ └── ...
|
||
│ │ ├── pages/ # Pages (si Next.js Pages Router)
|
||
│ │ │ ├── folders/
|
||
│ │ │ ├── documents/
|
||
│ │ │ ├── offices/
|
||
│ │ │ ├── users/
|
||
│ │ │ ├── roles/
|
||
│ │ │ ├── admin/
|
||
│ │ │ └── ...
|
||
│ │ ├── components/ # Composants réutilisables
|
||
│ │ │ ├── layout/
|
||
│ │ │ ├── ui/ # Design system (boutons, inputs, etc.)
|
||
│ │ │ └── ...
|
||
│ │ ├── design-system/ # Tokens, thème par défaut (structure pour enso)
|
||
│ │ │ ├── tokens/ # Couleurs, typo, espacements
|
||
│ │ │ ├── theme.ts
|
||
│ │ │ └── index.ts
|
||
│ │ ├── api/ # Client API (appels backend docv)
|
||
│ │ │ ├── client.ts
|
||
│ │ │ ├── folders.ts
|
||
│ │ │ ├── documents.ts
|
||
│ │ │ └── ...
|
||
│ │ ├── i18n/ # Structure textes + textes par défaut (fr, en)
|
||
│ │ │ ├── keys.ts
|
||
│ │ │ ├── fr.json
|
||
│ │ │ └── en.json
|
||
│ │ ├── stores/ # État global (context, store)
|
||
│ │ ├── hooks/
|
||
│ │ ├── utils/ # Helpers partagés
|
||
│ │ └── types/ # Types TS (alignés contrats back)
|
||
│ └── dist/ ou .next/
|
||
│
|
||
└── docv-core/ # Optionnel : package partagé TS (types, contrats, constantes)
|
||
├── package.json # @enso/docv-core
|
||
├── tsconfig.json
|
||
├── src/
|
||
│ ├── types/ # Entités métier agnostiques
|
||
│ ├── contracts/ # DTOs, réponses API
|
||
│ ├── constants/
|
||
│ └── index.ts
|
||
└── dist/
|
||
```
|
||
|
||
- **docv-back** : service HTTP Rust (Axum/Actix), connexion PostgreSQL, migrations + seeds pour structure et données par défaut. Dépend de `docv-shared` (natif). Handlers et services pour auth, dossiers, documents, offices, users, rôles, site_texts, system_configuration ; sous-dossiers `anchoring` et `ia` pour les **clients** HTTP vers l’API d’ancrage (serveur services, projet api-anchorage) et vers l’**API IA** (sous-module `ai`, TypeScript, qui s’appuie sur le socle Ollama/AnythingLLM). Ces API externes sont consommées par le back uniquement (voir sections 2bis et 2ter).
|
||
- **docv-front** : application front complète ; design-system avec tokens et thème par défaut ; i18n avec structure et textes par défaut ; pages et composants pour toutes les fonctionnalités docv. Si WASM utilisé : importe le build `docv-shared` (pkg wasm-pack) pour validation, formatage, constantes partagés.
|
||
- **docv-core** : optionnel ; package partagé TS exposant types, contrats et constantes pour **docv-front** et **enso-front**. Peut coexister avec docv-shared (WASM) : docv-core pour types/contrats API, docv-shared pour logique partagée en Rust/WASM.
|
||
|
||
Architecture logicielle détaillée (couches, modules, API, paramétrage, sécurité) : `docs/ARCHITECTURE_DOCV_DETAILLEE.md`.
|
||
|
||
---
|
||
|
||
### 3.2 enso (avocats)
|
||
|
||
**Documentation dédiée enso :** point d’entrée `docs/enso/README.md` (périmètre, spécifiques E1–E31, liens vers specs, implémentation, référentiel).
|
||
|
||
enso a sa propre BDD, ses textes, son design, ses paramétrages (rôles, documents, dossiers, membres) et ses API tiers ; il hérite de la structure et des défauts de docv. Les API externes (ancrage, IA) sont **consommées par le backend uniquement** ; le front n’appelle que enso-back (voir section 2bis). Backend et frontend utilisent les mêmes langages et frameworks que docv (Rust côté back, même stack front que docv-front).
|
||
|
||
```text
|
||
enso/
|
||
├── package.json # Scripts qui délèguent à enso-front et enso-back
|
||
│
|
||
├── enso-front/ # Même stack que docv-front (ex. Next.js, TypeScript)
|
||
│ ├── package.json # dependency: docv-front ou @enso/docv-core (types/contrats)
|
||
│ ├── tsconfig.json
|
||
│ ├── next.config.* (ou équivalent)
|
||
│ ├── .env.example
|
||
│ ├── public/
|
||
│ ├── src/
|
||
│ │ ├── app/ ou pages/
|
||
│ │ │ └── ... # Pages spécifiques avocat (dossiers, mandats, etc.)
|
||
│ │ ├── components/ # Composants spécifiques enso (surcharges ou nouveaux)
|
||
│ │ ├── theme/ # Surcharges du design system docv (couleurs, marque enso)
|
||
│ │ │ └── overrides.ts
|
||
│ │ ├── api/ # Client API enso uniquement (pas d’appel direct aux API externes)
|
||
│ │ ├── i18n/ # Textes enso (structure héritée, clés spécifiques ou surcharges)
|
||
│ │ │ ├── fr.json
|
||
│ │ │ └── en.json
|
||
│ │ ├── stores/
|
||
│ │ ├── hooks/
|
||
│ │ └── types/
|
||
│ └── dist/ ou .next/
|
||
│
|
||
└── enso-back/ # Même stack que docv-back (Rust)
|
||
├── Cargo.toml
|
||
├── .env.example
|
||
├── migrations/ # Migrations SQL (structure dérivée docv)
|
||
│ └── *.sql
|
||
├── seeds/ # Données spécifiques avocat
|
||
│ └── *.sql
|
||
├── src/
|
||
│ ├── main.rs
|
||
│ ├── config/
|
||
│ ├── db/
|
||
│ ├── error/
|
||
│ ├── handlers/ # Handlers HTTP par ressource
|
||
│ │ ├── auth.rs
|
||
│ │ ├── folders.rs
|
||
│ │ ├── documents.rs
|
||
│ │ └── ...
|
||
│ ├── services/
|
||
│ │ ├── common/ # Auth, logging, erreurs (mêmes patterns que docv)
|
||
│ │ ├── lawyer/ # Dossiers avocat, mandats, etc.
|
||
│ │ └── docv/ # Optionnel : client vers backend docv si délégation ; sinon client direct API ancrage (services, api-anchorage) et API IA
|
||
│ ├── models/
|
||
│ ├── repositories/
|
||
│ ├── middleware/
|
||
│ └── routes.rs
|
||
└── logs/
|
||
```
|
||
|
||
- **enso-front** : même langage et framework que docv-front ; hérite du design system docv (structure + défauts), surcharge le thème (couleurs, marque) ; textes et paramétrages spécifiques avocat ; pas d’IdNot, Mailchimp, OVH, Stripe.
|
||
- **enso-back** : même langage et framework que docv-back (Rust) ; BDD enso (PostgreSQL), schéma aligné sur la structure docv ; services `lawyer/` pour la logique avocat ; **consomme** les API externes (ancrage : serveur services, api-anchorage ; IA) côté back uniquement. Le front n’appelle que enso-back.
|
||
|
||
---
|
||
|
||
### 3.3 Périmètre notaire (hors dépôt actuel)
|
||
|
||
Un produit dédié au secteur notarial n’est pas arborescé ici pour l’instant. Orientation : [`docs/HORS_PERIMETRE_NOTAIRE.md`](HORS_PERIMETRE_NOTAIRE.md).
|
||
|
||
---
|
||
|
||
### 3.4 Racine du monorepo (rappel)
|
||
|
||
```text
|
||
enso/ # Dépôt (workspace root)
|
||
├── package.json # workspaces: docv, docv/docv-front, ...
|
||
├── .gitmodules # Déclaration du sous-module ai (après git submodule add)
|
||
├── .cursor/
|
||
│ └── rules/ # Règles Cursor (qualité, lint, clôture)
|
||
├── docs/
|
||
│ ├── features/
|
||
│ ├── fixKnowledge/
|
||
│ ├── ARCHITECTURE_DOCV_ENSO.md
|
||
│ └── PLAN_REALISATION_DOCV_ENSO.md
|
||
├── deploy/ # Scripts et configs déploiement (docv, enso)
|
||
├── .secrets/ # Secrets par env (hors dépôt ou ignorés)
|
||
├── ai/ # Sous-module Git → https://git.4nkweb.com/4nk/ai.git (API IA TypeScript, socle Ollama/AnythingLLM)
|
||
├── docv/
|
||
│ ├── docv-shared/ # Crate Rust partagée (natif + WASM pour fronts)
|
||
│ ├── docv-back/ # Rust
|
||
│ ├── docv-front/ # Next.js ou équivalent
|
||
│ └── docv-core/ # Optionnel (TS partagé)
|
||
├── enso/
|
||
│ ├── enso-front/
|
||
│ └── enso-back/
|
||
```
|
||
|
||
Les workspaces npm à la racine incluent les frontends déclarés dans le `package.json` racine (ex. `docv/docv-front`, `docv/docv-core`, `enso/enso-front` selon évolution du dépôt). Les backends Rust (**docv-back**, **enso-back**) sont gérés par Cargo ; la racine peut appeler `cargo build` dans chaque répertoire back ou via un workspace Cargo commun. Le répertoire **`ai/`** est un **sous-module Git** (https://git.4nkweb.com/4nk/ai.git) : API IA en TypeScript, développée pour interagir avec le socle IA (Ollama, AnythingLLM, modèles préinstallés) ; les backends consomment cette API (voir section 2ter).
|
||
|
||
---
|
||
|
||
## 4. Proposition d’arborescence pour enso (vue globale)
|
||
|
||
Monorepo avec **workspaces npm** à la racine. Deux produits suivis dans ce dépôt : **docv** (commun) et **enso** (avocats). Chacun peut avoir un front et un back, dépendants de docv pour le partagé.
|
||
|
||
```text
|
||
enso/ # Dépôt (workspace root)
|
||
├── package.json # workspaces, scripts globaux (lint, typecheck, build)
|
||
├── docs/ # Documentation technique
|
||
│ ├── features/
|
||
│ ├── fixKnowledge/
|
||
│ └── ARCHITECTURE_DOCV_ENSO.md
|
||
├── deploy/ # Déploiement (scripts, configs, hooks)
|
||
├── .secrets/ # Secrets par environnement (hors dépôt ou ignorés)
|
||
│
|
||
├── docv/ # Commun agnostique
|
||
│ ├── package.json # @enso/docv ou docv-core
|
||
│ ├── src/
|
||
│ │ ├── types/ # Entités métier agnostiques
|
||
│ │ │ ├── document.ts
|
||
│ │ │ ├── folder.ts
|
||
│ │ │ ├── office.ts
|
||
│ │ │ ├── user.ts
|
||
│ │ │ └── index.ts
|
||
│ │ ├── contracts/ # DTOs, contrats API partagés
|
||
│ │ ├── i18n/ # Clés et traductions de base (fr, en)
|
||
│ │ ├── utils/ # Helpers partagés (validation, format, etc.)
|
||
│ │ └── constants/
|
||
│ ├── tsconfig.json
|
||
│ └── dist/
|
||
│
|
||
├── enso/ # Déclinaison avocats
|
||
│ ├── package.json # scripts qui délèguent aux sous-packages
|
||
│ ├── enso-front/ # Même stack que docv-front (ex. Next.js)
|
||
│ │ ├── package.json # dependency: "@enso/docv" ou "docv-core"
|
||
│ │ ├── src/
|
||
│ │ │ ├── pages/
|
||
│ │ │ ├── components/ # Spécifique avocat
|
||
│ │ │ ├── api/
|
||
│ │ │ └── ...
|
||
│ │ └── public/
|
||
│ └── enso-back/ # Même stack que docv-back (Rust)
|
||
│ ├── Cargo.toml
|
||
│ ├── migrations/
|
||
│ ├── src/
|
||
│ │ ├── handlers/
|
||
│ │ ├── services/ # common/, lawyer/, docv/
|
||
│ │ └── ...
|
||
│ └── logs/
|
||
```
|
||
|
||
---
|
||
|
||
## 5. Découpage fonctionnel
|
||
|
||
### 5.1 docv (commun)
|
||
|
||
- **Responsabilité** : tout ce qui est indépendant du métier notaire vs avocat.
|
||
- **Contenu proposé** :
|
||
- **types** : Document, Folder, Office, User, Contact, Address, File, etc. (noms et champs agnostiques).
|
||
- **contracts** : DTOs et interfaces d’API réutilisables (création document, pagination, réponses standard).
|
||
- **i18n** : clés et fichiers de traduction communs (erreurs, libellés génériques, formats).
|
||
- **utils** : validation, formatage dates/montants, helpers de transformation.
|
||
- **constants** : codes erreur, limites, paramètres par défaut.
|
||
- **Pas dans docv** : logique métier spécifique notaire (ancrage, actes, IdNot, etc.) ou avocat (mandats, dossiers avocat), ni couche d’accès données (Prisma, repositories).
|
||
|
||
### 5.2 enso (avocats)
|
||
|
||
- **enso-front** : même langage et framework que docv-front ; application dédiée aux avocats ; importe docv pour types, i18n, design system ; pages et composants spécifiques avocat.
|
||
- **enso-back** : même langage et framework que docv-back (Rust) ; BDD enso (PostgreSQL), schéma aligné sur docv ; services `common/` (auth, logging, erreurs) et `lawyer/` (dossiers, mandats) ; consomme les API externes (ancrage : serveur services, api-anchorage ; IA) côté back uniquement.
|
||
|
||
### 5.3 Périmètre notaire (hors dépôt actuel)
|
||
|
||
Voir [`docs/HORS_PERIMETRE_NOTAIRE.md`](HORS_PERIMETRE_NOTAIRE.md).
|
||
|
||
---
|
||
|
||
## 6. Workspaces npm (racine)
|
||
|
||
Exemple de `package.json` à la racine de enso :
|
||
|
||
```json
|
||
{
|
||
"name": "enso-monorepo",
|
||
"private": true,
|
||
"workspaces": [
|
||
"docv/docv-front",
|
||
"docv/docv-core",
|
||
"enso/enso-front"
|
||
],
|
||
"scripts": {
|
||
"build": "npm run build --workspaces --if-present",
|
||
"build:back": "cargo build --manifest-path docv/docv-back/Cargo.toml && cargo build --manifest-path enso/enso-back/Cargo.toml",
|
||
"lint": "npm run lint --workspaces --if-present",
|
||
"typecheck": "npm run typecheck --workspaces --if-present"
|
||
}
|
||
}
|
||
```
|
||
|
||
Les packages **docv-front**, **docv-core** (si présent) et **enso-front** sont référencés par leur chemin. Les backends Rust sont buildés via Cargo (voir script `build:back` ou workspace Cargo à la racine).
|
||
|
||
---
|
||
|
||
## 7. Dépendances entre packages
|
||
|
||
- **docv** : aucune dépendance vers **enso**.
|
||
- **enso-front**, **enso-back** : dépendent de **docv** uniquement pour le partagé.
|
||
|
||
---
|
||
|
||
## 8. Nommage des packages
|
||
|
||
- **docv** : `@enso/docv` ou `docv-core` (à aligner avec la convention du dépôt).
|
||
- **enso** : `@enso/enso-front`, `@enso/enso-back` (ou `enso-front`, `enso-back`).
|
||
|
||
Les noms ci-dessus sont des propositions ; à valider selon les usages (npm privé, `file:../docv`, etc.).
|
||
|
||
---
|
||
|
||
## 9. Déploiement et environnements
|
||
|
||
- **deploy/** à la racine : scripts et configs communs (build, déploiement, hooks).
|
||
- Le sous-projet **enso** peut avoir ses propres cibles (test, pprod, prod) et variables d’environnement ; les scripts dans `deploy/` peuvent appeler les builds des workspaces concernés (par exemple build docv puis enso-front et enso-back pour la cible « enso »).
|
||
|
||
---
|
||
|
||
## 10. Documentation
|
||
|
||
- **docs/features/** : évolutions (objectif, impacts, déploiement, analyse).
|
||
- **docs/fixKnowledge/** : correctifs (problème, cause, corrections, déploiement, analyse).
|
||
- **docs/SCREENS_AND_FUNCTIONS_MAP.md** : cartographie des écrans et des fonctions attendues (wording générique).
|
||
- **docs/features/specs/README.md** : référentiel des spécifications par fonctionnalité (une spec par zone, détail objectif, écrans, actions, règles métier, API, déploiement, analyse).
|
||
- Ce fichier reste la référence pour le découpage **docv / enso** et l’architecture du monorepo.
|
||
|
||
---
|
||
|
||
## 11. Résumé
|
||
|
||
| Sous-projet | Rôle | Contenu principal |
|
||
|-------------|------|--------------------|
|
||
| **docv** | Commun agnostique | docv-shared (Rust, natif + WASM si partage back/front), docv-back (Rust), docv-front (ex. Next.js), docv-core (TS partagé) ; structure et défauts pour tous |
|
||
| **enso** | Avocats | enso-front (même stack que docv-front) + enso-back (Rust, même stack que docv-back), consomment docv |
|
||
|
||
Un périmètre notaire distinct est documenté hors arborescence applicative actuelle : [`docs/HORS_PERIMETRE_NOTAIRE.md`](HORS_PERIMETRE_NOTAIRE.md).
|
||
|
||
Cette proposition concerne l’organisation du dépôt **enso** et l’intégration de **docv** et **enso**.
|