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
docv — Documentation projet (socle commun)
Point d’entrée de la documentation pour le projet docv (socle commun agnostique métier). docv porte les zones 1 à 15 (authentification, offices, dossiers, documents, partage, abonnement, admin, contenus, technique et design) ; il n’a pas de zone 17 ni de spécifiques métier dédiés. enso hérite de docv.
Architecture globale : ARCHITECTURE_DOCV_ENSO.md (section 3.1 docv).
Plan de réalisation : PLAN_REALISATION_DOCV_ENSO.md (Phase 1 — docv).
1. Périmètre docv
| Élément | Contenu |
|---|---|
| Zones | 1 à 15 uniquement (pas de zone 17). |
| Fonctionnalités | Auth et compte, dossiers, documents et types, types de dossiers, offices et membres, rôles et permissions, parties et partage, notes et rappels, abonnement et facturation, espaces client/invité, admin office, admin plateforme, contenus et paramètres, technique et design. |
| API externes | Consommées par docv-back uniquement : API ancrage (serveur services, api-anchorage), API IA (sous-module ai). Pas d’IdNot, API notaire, Mailchimp, OVH, Stripe. |
| Spécifiques | Aucun ; docv reste agnostique. Les spécifiques enso sont listés sous E1–E31. |
2. Documentation de référence pour docv
| Document | Usage |
|---|---|
| AUTH_SESSION.md | Durées OAuth (Bearer + cookie docv_oauth_session), office_members (filtre API des sociétés visibles), espaces cabinet vs clients et variables DOCV_* de test. |
| IMPLEMENTATION.md | Détail d’implémentation : ordre des zones, stack, schéma BDD, surface API, checklist Phase 1. |
| SCREENS_AND_FUNCTIONS_MAP.md | Cartographie écrans et actions (sections 1–15, 18.1–18.52). |
| REFERENTIEL_ECRANS_ACTIONS.md | Liste exhaustive écrans et actions zones 1–15 (identifiants stables). |
| specs/README.md | Spécifications fonctionnelles par zone (SPEC_01 à SPEC_15). |
| implementation/README.md | Implémentation technique par zone (IMPL_01 à IMPL_15). |
| PARAMETRAGE_ECRANS_ACTIONS.md | Modèle de paramétrage (écrans, actions, options). |
| ARCHITECTURE_DOCV_DETAILLEE.md | Architecture détaillée du socle docv (couches, BDD, API). |
3. Ordre de réalisation docv (Phase 1)
D’après le plan de réalisation (Phase 1) :
| Étape | Contenu | Livrable |
|---|---|---|
| 1.1 Backend docv (Rust) | Stack HTTP, PostgreSQL, migrations, schéma BDD agnostique, API REST (auth, CRUD dossiers/documents/membres/rôles, paramétrage, textes) ; consommation API ancrage et API IA côté back. | Service docv-back opérationnel. |
| 1.2 Frontend docv | Stack front moderne (ex. Next.js), écrans zones 1–15, design system (tokens, thème, composants de base), appels API docv-back uniquement. | Front docv utilisable sur BDD et back docv. |
| 1.3 Données et paramétrage par défaut | Seeds/migrations (rôles, permissions, types documents/dossiers, textes, system_configuration). | Instance docv déployée avec structures et données par défaut réutilisables par enso. |
Phase 0 (cadrage, règles Cursor, structure monorepo, sous-module ai) est un préalable à la Phase 1.
3bis. Comptes utilisateurs (réels uniquement)
Les comptes de connexion (docv / OAuth vers enso) doivent être réels : créés par les flux prévus du produit (inscription, invitation, admin plateforme / admin office selon les specs zones 1, 5, 12, 13, etc.), pas par seed applicatif, ni par utilisateurs mock, ni par script CLI d’insertion dédié au dépôt. Les migrations SQL décrivent le schéma (ex. table users) ; la donnée compte relève des processus métier et d’exploitation.
4. Structure cible docv (rappel)
- docv-back : Rust ; BDD PostgreSQL dédiée ; handlers/services zones 1–15 ; consommation API ancrage et API IA ; pas d’IdNot ni API notaire/Mailchimp/OVH/Stripe.
- docv-front : même stack que pour enso-front (ex. Next.js, TypeScript) ; design system (structure + défauts) ; écrans et actions zones 1–15 ; client API vers docv-back uniquement.
- docv-shared (optionnel) : crate Rust partagée (natif + WASM) pour validation, formatage, constantes, règles métier pures ; consommée par docv-back et docv-front (WASM).
5. Ordre de lecture recommandé pour implémenter docv
- ARCHITECTURE_DOCV_ENSO.md (sections 2bis, 2ter, 3.1) — API externes, socle IA, structure docv.
- ARCHITECTURE_DOCV_DETAILLEE.md — couches, BDD, contrats API docv.
- IMPLEMENTATION.md — ordre d’implémentation par zone, stack, schéma BDD, surface API, checklist Phase 1.
- PLAN_REALISATION_DOCV_ENSO.md (Phase 0 et Phase 1) — ordre des étapes 1.1, 1.2, 1.3.
- specs/README.md et SPEC_01 à SPEC_15 — périmètre fonctionnel des zones 1–15.
- implementation/README.md et IMPL_01 à IMPL_15 — implémentation technique (routes, front, back, BDD).
- REFERENTIEL_ECRANS_ACTIONS.md — identifiants stables pour paramétrage (zones 1–15).