Nicolas Cantu bc3c75e15f Add enso docs mirror under services/docv/enso-docs; docv integration docs

- 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

2026-04-03 17:26:35 +02:00

27 KiB

Raw Blame History

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 (entête) ; déclinaison enso : docs/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) :

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).

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).

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.

3.4 Racine du monorepo (rappel)

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é.

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.

6. Workspaces npm (racine)

Exemple de package.json à la racine de enso :

{
  "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.

Cette proposition concerne l’organisation du dépôt enso et l’intégration de docv et enso.

27 KiB Raw Blame History Unescape Escape