--module-check (objet metier .dhsp) | Check_Field procs (confirme FK), Find_ (revele table cible), FieldNames_Min (PK metier), constantes C_, Authorize_
--choix-json (gtfdmc.json) | Valeurs concretes des listes codifiees (partiel -- les 30+ restantes sont dans gtfdmc.dhfi ISAM) | --sql-columns | Liste complete des 200+ colonnes SQL, enrichies avec libelles DIVA au merge | --sql-indexes-json | Detection de l'usage reel des Ce1..CeA (co-colonnes : STAT_* -> stat, TIERSGRP -> groupement) |
Si une source manque : l'extraction reussit mais perd en precision (ex: sans --module-check, les FK sont detectees uniquement via f8 masque et les vraies tables cibles T014/T048/C3 sont remplacees par le nom du champ source). Toujours fournir les 7 sources pour une passe one-shot.
Naming convention DAV (a adapter par module) :
- Module Check :
gttmchk<ent>.dhsp (ex: gttmchkcli.dhsp, gttmchkfou.dhsp)
- Masque zoom principal :
gtez<NNN>_sql.dhsf (ex: gtez021_sql.dhsf pour CLI)
- Module zoom :
gttz<NNN>_sql.dhsp
Le JSON {CHEMIN_SCHEMA_SQL} est un export du schema SQL Server produit en amont
(ex: script de dump qui interroge information_schema.columns et sys.indexes).
Format attendu : {table, database, refreshed, column_count, columns[{name,type,length,nullable,ordinal}]}
pour columns, {table, indexes[{name,columns[],unique,primary}]} pour indexes.
Pour le module (parametres fournis par le collaborateur au CP1) :
py scripts/extract_module.py --module DAV --prefix GTF --label "Achat-Vente" \
--bases "GTFDOS,GTFPCF,GTFAT,..." --entities "CLI,FOU,ART,..." \
--output {REPERTOIRE_SORTIE}/doc-erp/DAV/module.partial.yaml
Reference locale pour les prefixes/bases des 15+ modules ERP standards :
reference/modules-erp-summary.md.
Relations (si Neo4j dispo) :
py scripts/extract_relations.py --entity CLI --source neo4j \
--output {REPERTOIRE_SORTIE}/doc-erp/DAV/relation/CLI.partial.yaml
Les fichiers .partial.yaml contiennent ce que les scripts ont pu extraire mecaniquement. Les sections business.* et meta.a_verifier sont enrichies a l'etape 3 (pas de checkpoint intermediaire, Claude enchaine).
Etape 3 -- Enrichissement narratif metier (autonome)
Claude produit le narratif en autonomie, sans question au collaborateur.
Le retour humain se fait uniquement post-livraison (CP-Final).
Sources de verite exclusivement (par ordre de priorite) :
- Sources X.13 vivantes (
{CHEMIN_ERP_STANDARD}) :
- Commentaires d'en-tete des masques
.dhsf (titre, description d'onglet)
- Commentaires et procedures des modules
.dhsp/.dhsq de l'entite
- Module Check (
.dhop/.dhsp mchk) pour les regles metier appliquees
- Menu et navigation ERP (zoom, titre, regroupement)
- Fragments locaux (
<skill>/reference/*.md) : transposition ciblee de
la documentation workspace (modules, prefixes, conventions).
Interdit comme source narrative :
archive/* (matiere digeree non canonique)raw/* (brouillons workspace)- Inventions / interpolations du LLM non tracables a une source
Regle de citation stricte :
Chaque affirmation narrative du livrable doit etre :
- soit tracee a une source X.13 avec reference
fichier:ligne
- soit marquee
[A VERIFIER] dans meta.a_verifier de l'entite concernee
Aucune invention tacite. Aucune formulation "probablement", "semble",
"possiblement" sans marquage [A VERIFIER] explicite.
Pour chaque entite, Claude :
- Ouvre les sources X.13 associees (dict, masques principaux, modules Check).
- Extrait le role metier, processus, regles observees, avec citations
fichier:ligne.
- Remplit
business.role, business.criticality, business.processes,
business.business_rules, business.examples.
- Liste exhaustivement dans
meta.a_verifier les elements non sourcables
(criticite metier appreciative, exemples typiques non documentes dans
le code, regles tacites, etc.).
- Passe a l'etape 4 sans pause.
Etape 4 -- Assemblage (autonome)
py scripts/merge_narrative.py \
--entity-partial {REPERTOIRE_SORTIE}/doc-erp/DAV/entity/CLI.partial.yaml \
--narrative {REPERTOIRE_SORTIE}/doc-erp/DAV/entity/CLI.narrative.yaml \
--output {REPERTOIRE_SORTIE}/doc-erp/DAV/entity/CLI.yaml
py scripts/assemble_model.py --module DAV \
--input {REPERTOIRE_SORTIE}/doc-erp/DAV/ \
--output {REPERTOIRE_SORTIE}/doc-erp/DAV/
Le script merge_narrative.py fusionne partial + narrative en un <entity>.yaml consolide. Le script assemble_model.py traite ensuite les relations heuristiques (resolution via confirmed_relations, reclassement DOS/ETB en type=partitioning, suppression des heuristiques non confirmees tracees dans meta._dropped_heuristic_relations).
Etape 4 bis -- Interpretation metier des CE (autonome, LLM-driven)
Apres assemblage et avant validation, Claude lit chaque <ENT>.yaml et redige
la description_metier de chaque CE actif (Ce1..CeA) a partir des signaux X.13
extraits par les scripts. Cette etape est LLM-driven : pas de script, Claude
edite directement le YAML in-place.
Pourquoi cette etape existe : l'heuristique role_infere (champ conserve
comme signal diagnostic) produit des descriptions generiques pour les entites
dont la structure differe de CLI (ex: ART, SOC, VRP). Le role metier specifique
de chaque CE se lit en croisant : le commentaire [CHAMP] du .dhsd, les
constantes C_*Ce<n>* du Module Check, la regle d'activation (Condition ou valeur
fixe), les co-colonnes des indexes, et le role metier global de l'entite.
Procedure a suivre par Claude pour chaque <ENT>.yaml :
Boucler sur technical.ce_analysis.fields[] et, pour chaque CE :
- Si
status == "reserve" : rien a faire (le script a deja ecrit
description_metier = "Reserve pour extension future...").
- Si
status == "actif" et description_metier existe deja et
description_metier_signature est inchange : conserver tel quel
(idempotence CA13).
- Si
status == "actif" et besoin de rediger :
- Lire les signaux disponibles pour le CE :
dhsd_comment + dhsd_source : commentaire du champ Ce dans le .dhsdmchk_constants[] : constantes C_Ce du Module Check (name, value,
comment, source)activation_rule : expression de Condition (ex: Ean <> ' ')fixed_value : valeur litterale assignee (ex: '3')values_observed_in_mchk, co_cols, indexes : indices supplementaires- Nom et role metier de l'entite (ex: ART = article, CLI = client)
- Rediger 1-3 phrases metier expliquant le role du CE : quel aspect
metier il exprime, dans quel contexte il est active, et si pertinent ce
que signifient ses valeurs.
- Citer au moins UNE source X.13 parmi les signaux : soit
dhsd_source,
soit un mchk_constants[].source. Format libre, plusieurs citations
separees par , . Stocker dans description_metier_source.
- Si aucun signal ne permet une description sourcee, laisser
description_metier: null et ajouter un item dans meta.a_verifier
du type "CE actif <ENT>.Ce<n> : role metier non sourcable depuis X.13".
Regle de citation stricte (CA4) : toute description_metier non vide DOIT
contenir une reference fichier:ligne dans description_metier_source. Pas
d'invention. Pas de formulation "probablement/semble/possiblement" sans
[A VERIFIER] explicite. Le script validate_model.py (etape 4 ter) refuse
sinon.
Calibration : le niveau de specificite metier attendu est celui du tableau
CE de CLI (reference validee). Un "drapeau derive (voir regle d'activation)"
generique n'est PAS acceptable pour une entite non-CLI.
Exemple bien formule (ART.CE9, actif si Ephemerefl = 2) :
"Drapeau article ephemere : actif quand l'article est marque comme a cycle
de vie limite (Ephemerefl = 2), co-indexe dans INDEX_A_MINI pour
accelerer les filtrages de catalogue." (src: gttmchkart.dhsp:XXX)
Contre-exemple a eviter (ART.CE9) :
"Probablement un drapeau lie a l'ephemerite, semble-t-il utilise dans des
traitements de catalogue."
Pourquoi c'est mauvais : "probablement" et "semble-t-il" sans
[A VERIFIER], aucune citation, repete l'heuristique sans ajouter de sens
metier. Correction : soit sourcer proprement, soit marquer [A VERIFIER]
et ne pas rediger.
Etape 4 ter -- Validation schemas (autonome)
py scripts/validate_model.py --model {REPERTOIRE_SORTIE}/doc-erp/DAV/ --schemas schemas/
Le script validate_model.py verifie la conformite aux schemas ET applique la
regle de citation stricte sur les CE : toute description_metier d'un CE actif
doit avoir une citation fichier:ligne dans description_metier_source, sinon
erreur.
Si validate_model.py renvoie des erreurs (non-warnings), Claude corrige
en re-editant les YAML et re-execute la validation, jusqu'a exit 0.
Les warnings (relations vers entites externes non documentees dans le
module courant) sont acceptes et reportes dans le livrable final.
Etape 5 -- Rendu (renderers fournis par le skill)
Le skill fournit plusieurs renderers autonomes consommant le meme modele YAML.
PDF n'est pas le format final unique : c'est un format parmi plusieurs. D'autres
renderers (Confluence, MkDocs, pandoc, site statique...) viendront s'ajouter sur le
meme principe. Regle d'autonomie : tout format de livrable necessaire doit etre
produit par un renderer du skill. Ne jamais court-circuiter avec un script externe
ad-hoc -- un renderer ad-hoc perd la typographie, les tableaux, les diagrammes
Mermaid et les refs inline, ce qui fait regresser silencieusement le livrable
(cf RETEX 2026-04-23 ou un md_to_pdf ad-hoc reportlab a produit un PDF 40x plus
petit que la reference Chrome headless, contenu textuel identique mais rendu
visuel appauvri).
Renderers disponibles aujourd'hui :
| Renderer | Script | Sortie | Prerequis |
|---|
| Markdown | render_markdown.py | .md | PyYAML | | PDF (Chrome headless) | render_pdf.py | .pdf | markdown + Chrome ou Edge |
Chaque renderer produit une sortie par audience (externe ou interne). En
audience interne, les chemins de sortie sont automatiquement suffixes .interne.
Au CP1, le collaborateur a precise les formats attendus (defaut : markdown +
pdf, audiences externe + interne). Claude execute ci-dessous les commandes
correspondantes.
5a -- Markdown (externe + interne)
py scripts/render_markdown.py \
--input {REPERTOIRE_SORTIE}/doc-erp/DAV/ \
--layer all \
--audience externe \
--output {REPERTOIRE_SORTIE}/doc-erp/DAV.md
py scripts/render_markdown.py \
--input {REPERTOIRE_SORTIE}/doc-erp/DAV/ \
--layer all \
--audience interne \
--output {REPERTOIRE_SORTIE}/doc-erp/DAV.md
Option --layer : business, schema, technical, ou all (sections empilees avec ancres).
Audiences :
externe (defaut) : livrable autonome destine au public large (clients,
Confluence publique). Aucune ref fichier:ligne visible.interne : meme contenu + refs inline + annexe "Sources consultees" pour audit
equipe Divalto. Fichier suffixe .interne.md.
5b -- PDF (externe + interne, via Chrome headless)
Toujours utiliser render_pdf.py du skill pour produire les PDFs. Ne jamais
utiliser un autre script de rendu PDF : le resultat qualitatif chute drastiquement.
py scripts/render_pdf.py \
--input {REPERTOIRE_SORTIE}/doc-erp/DAV.md \
--output {REPERTOIRE_SORTIE}/doc-erp/DAV-externe.pdf \
--title "Module DAV -- audience externe"
py scripts/render_pdf.py \
--input {REPERTOIRE_SORTIE}/doc-erp/DAV.interne.md \
--output {REPERTOIRE_SORTIE}/doc-erp/DAV-interne.pdf \
--title "Module DAV -- audience interne"
Chaine interne : Markdown -> HTML (lib markdown + extensions tables/fenced_code/toc)
-> PDF (Chrome/Edge headless avec CSS A4 dedie : typographie serif, code monospace,
tableaux stylees, blockquotes colores, numerotation de pages).
Prerequis : Chrome ou Edge installes (recherches dans PATH puis dans les emplacements
Windows classiques). Variable DOCERP_BROWSER pour forcer un autre browser.
5c -- Autres renderers (a venir)
Les futurs renderers (Confluence, MkDocs, pandoc, site statique) seront ajoutes
ici sous la meme regle d'autonomie : fournis par le skill, consomment le YAML
canonique, ne court-circuitent pas. A chaque nouveau renderer, mettre a jour
le tableau ci-dessus + la checklist de progression + la ligne correspondante
dans la section Scripts.
CHECKPOINT CP-Final -- Livrable presente au collaborateur
Presenter :
- Fichiers produits (YAML canoniques + .md + .pdf si demande)
- Taille du livrable, nb de pages, nb d'entites documentees
- Liste exhaustive des items [A VERIFIER] (c'est le principal point
d'interface post-livraison : le collaborateur confirme ou corrige)
- Statistiques : nb affirmations sourcees vs nb items [A VERIFIER]
Critere : rendu s'ouvre proprement, chaque couche a du contenu, toute
affirmation est tracee (source X.13 ou [A VERIFIER]).
Le collaborateur lit le livrable, annote les corrections ciblees, Claude
les re-injecte en re-generation partielle (pas de re-run complet si
evitable).
Scripts
Details d'usage dans chaque script (--help). Resume :
| Script | Role |
|---|
| extract_module.py | Extrait identite + bases + entites d'un module | | extract_entity.py | Extrait champs + indexes d'une entite | | extract_relations.py | Detecte FK et zooms d'une entite | | assemble_model.py | Fusionne les .partial.yaml en modele complet | | validate_model.py | Valide les YAML contre les schemas | | render_markdown.py | Produit un .md depuis le modele (3 couches possibles) | | render_pdf.py | Convertit un .md en PDF via Chrome/Edge headless |
Dependances
- Python 3.14+ (launcher
py)
- PyYAML :
py -m pip install pyyaml
- markdown (pour render_pdf) :
py -m pip install markdown
- Chrome ou Edge installes (render_pdf uniquement, recherche PATH + emplacements Windows classiques)
Convention de chemins
| Placeholder | Usage |
|---|
{CHEMIN_ERP_STANDARD} | Racine X.13 en lecture seule | {CHEMIN_FICHIERS} | Repertoire dicos .dhsd | {CHEMIN_SCHEMA_SQL} | Repertoire contenant l'export JSON du schema SQL | {REPERTOIRE_SORTIE} | Racine de sortie pour les YAML et le markdown |
Pas de chemin absolu en dur dans les scripts ni dans les instructions.
Aucune reference a archive/ ou raw/ : le skill doit rester portable et
autonome chez tout collaborateur (cf. .claude/skills/README.md sections
Autonomie documentaire et Autonomie vis-a-vis du repertoire prive
workspace).
Principes
- Penser avant de generer : collecter les parametres a CP1, clarifier toute ambiguite avant extraction.
- Minimum viable : produire ce qui est demande, pas plus. Un module a la fois.
- Modifications chirurgicales : sur un modele existant, re-extraire uniquement les entites touchees.
- Critere de succes : 0 erreur de validation, 3 couches couvertes, rendu Markdown qui s'ouvre proprement.
|
