| name | migrating-erp-downgrade |
| description | A utiliser lors de la migration du specifique d'un client d'une version ERP Divalto a une autre (rebase sur un nouveau Service Pack / version X.N), ou pour arbitrer ce qu'un downgrade conserve, rebase ou abandonne | Guide la migration de pack : ordre de compilation (bases standard d'abord, surcharges overWrite ensuite -- recompiler un standard apres sa surcharge efface les procedures fusionnees), contournement deux passes quand des dependances inter-projets ne sont pas declarees dans les .dhps, arbitrage des sources downgrade (un SP ne livre qu'un sous-ensemble des sources : croiser diff textuel, existence de l'objet compile et couplage au dictionnaire downgrade -- jamais 'supprimable' sur la seule absence de source standard), verification post-migration de l'integrite des surcharges. Complete les references downgrade de managing-diva-dictionaries et la compilation de managing-diva-projects / compiling-diva-projects. |
migrating-erp-downgrade -- Migration / rebase de pack et arbitrage downgrade
Contenu
- Quand l'utiliser
- Carte du processus de migration
- Ordre de compilation (les deux pieges)
- Verifier l'integrite des surcharges (script)
- Arbitrer les sources d'un downgrade
- References
Quand l'utiliser
- Migrer le specifique d'un client d'une version ERP Divalto a une autre (rebase
d'un projet downgrade sur un nouveau Service Pack ou une version X.N).
- Arbitrer un downgrade : decider, source par source, quoi conserver + rebaser, quoi
abandonner, au passage d'un SP.
- Diagnostiquer un comportement « redevenu standard » apres un rebase (surcharge
silencieusement effacee).
Ne pas utiliser pour :
- Compiler un projet (boucle de developpement) ->
compiling-diva-projects.
- Creer / structurer un
.dhpt / .dhps -> managing-diva-projects.
- Modifier / surcharger un dictionnaire ou diffuser ses 3 couches ->
managing-diva-dictionaries.
- Preparer une livraison / quitus -> skill de livraison dedie.
Carte du processus de migration
Nouveau pack standard (SP cible)
│
▼
1. Arbitrer les sources downgrade ── croiser 3 signaux (diff / objet / couplage)
│ → reference/downgrade-source-arbitration.md
▼
2. Rebaser le specifique a conserver ── (dico : managing-diva-dictionaries)
│
▼
3. Compiler DANS LE BON ORDRE ── bases standard d'abord, surcharges overWrite ensuite
│ → reference/migration-build-order.md
▼
4. Verifier l'integrite des surcharges ── check_overwrite_order.py (date + symbole)
│
▼
Pack migre, surcharges intactes
Ordre de compilation -- les deux pieges
Detail complet : reference/migration-build-order.md.
- Piege overWrite (R-035) --
OverWrite <base>.dhop fusionne ses procedures
dans <base>.dhop. Recompiler le standard <base> apres sa surcharge regenere
l'objet propre et efface la surcharge (0 erreur de compil ; bug silencieux au
runtime). Regle d'or : bases standard d'abord, surcharges ENSUITE.
- Dependances
.dhps non declarees (R-010) -- en buildall, un mauvais ordre
provoque « Erreur dictionnaire ... recompiler les dictionnaires » sur des .dhoq
standard. Contournement : 2e passe en mode build. Correctif durable :
declarer les dependances dans les .dhps (cf. managing-diva-projects).
Verifier l'integrite des surcharges -- check_overwrite_order.py
Apres un rebase, controler que chaque surcharge overWrite a bien survecu (deux
signaux : date de l'objet de base vs overlay, presence du symbole de surcharge
dans l'objet de base).
# Paire explicite (fiable) -- on fournit les procedures de surcharge a controler
py .claude/skills/migrating-erp-downgrade/scripts/check_overwrite_order.py \
--base "objets/<base>.dhop" --overlay "objets/<overlay>.dhop" \
--symbols "<ProcSurcharge1>,<ProcSurcharge2>"
# Scan d'un repertoire (heuristique de nommage u<->t, symboles candidats auto)
py .claude/skills/migrating-erp-downgrade/scripts/check_overwrite_order.py \
--objets "objets/"
Sortie JSON : par paire, date_inversion (base plus recent que l'overlay = suspect),
et par symbole in_base / in_overlay / lost (present overlay, absent base = surcharge
effacee). anomaly=true et exit 1 si un signal est leve. Voir
reference/migration-build-order.md section
« Verifier l'integrite ».
Portee : le moteur (recherche de symbole dans le .dhop, comparaison de dates) est
fiable. La detection suppose de pointer le script sur les objets reels du projet (bases
et overlays). Le mode --objets couple par nommage (heuristique) ; le mode explicite
est sans ambiguite.
Arbitrer les sources d'un downgrade
Detail complet : reference/downgrade-source-arbitration.md.
Un Service Pack ne livre qu'un sous-ensemble des sources standard ; le reste n'existe
qu'en objet compile. Ne jamais conclure « supprimable » sur la seule absence de
source standard. Croiser 3 signaux :
- diff textuel (si la source standard est livree) ;
- existence de l'objet standard (indexer aussi
objets/) -> source absente + objet
present = standard recompile en contexte downgrade, pas un custom ;
- couplage au dictionnaire / RecordSQL downgrade (raisonner par dependance).
L'arbitrage des RecordSQL se joue sur le record relationnel [CHAMPL] du dictionnaire --
voir le diff 3 couches / 3 voies de
managing-diva-dictionaries.
References
