dlm-version-master

DLM Version Master 7 Portable

Objectif

Versionner, vérifier, commiter et pousser les modifications d'un dépôt .NET en utilisant une infrastructure appartenant au dépôt sans supposer de nom de produit ou de structure de répertoires. Ce skill personnel fournit le workflow générique ; chaque dépôt déclare ses projets, son point d'entrée de release, sa carte des modules, ses chemins de sortie et sa politique de commit.

Barrière de gouvernance des résultats

Lire et appliquer la Gouvernance des résultats DLM partagée avant toute mutation de l'état de version, build Release, vérification d'artefact, mise en scène (staging), commit ou push.

• Établir une seule ligne de base de release/version gelée avec la portée autorisée, les modules/sorties requis, la décision de version interne, les preuves correspondant aux revendications et la ligne d'arrêt. L'appel direct de dlm-version-master autorise l'évaluation de version interne, la build/vérification requise, le commit Git à portée exacte et le push vers la branche distante ; il n'autorise pas la copie d'artefact, la publication, le taggage, le déploiement ou le déploiement sur le terrain.
• Un hachage source soutient la revendication de changement de module / décision de version ; un hachage de sortie soutient l'identité octet lorsque le profil le consomme. Aucun ne gèle une ligne de base ni ne prouve l'état d'exécution, de coordination, de déploiement ou de terrain.
• Exécuter uniquement les vérifications requises par le profil ou présentant un risque matériel. Des métadonnées vertes ne peuvent pas remplacer des preuves de comportement, et des échecs administratifs non liés ne peuvent pas devenir silencieusement des critères de release.
• Effectuer une seule vérification combinée d'identité/portée/pré-stage avant mutation, puis avancer sur le chemin de release le plus court. N'ajoutez pas de reçus, de résumés en double ou de vérifications complètes répétées sans un véritable consommateur ou une nouvelle incertitude matérielle.

Autorité et composition

• Chaque appel direct de dlm-version-master est porteur de l'autorisation permanente de l'utilisateur pour :
  1. décider de manière autonome via des règles internes s'il faut incrémenter les versions (none vs. patch / minor / major) sauf si l'utilisateur spécifie explicitement une politique de bump dans le prompt ;
  2. exécuter la build Release requise et la vérification des métadonnées binaires chaque fois que les versions des modules ou les entrées source pertinentes pour la build changent ;
  3. mettre en scène (staging) les chemins autorisés exacts, exécuter les revues pré-commit requises (ponytail-review), commiter dans Git avec un message de commit structuré détaillé couvrant 修改范围 (Portée), 对应版本 (Version), 怎么改的 (Comment), et 为什么改的 (Pourquoi), et pousser vers la branche du dépôt distant (git push).
• Ignorer le commit ou le push lors d'un appel direct uniquement lorsque l'utilisateur demande explicitement de ne pas commiter/pousser dans le tour en cours, ou lorsqu'un contrôle de sécurité/vérification concret bloque l'opération (build/test/review requis échoués, modifications non liées mélangées dans un fichier cible, distant manquant/ambigu, ou branche distante divergente).
• La création de dépôt distant, le force-push, le taggage, le déploiement, la publication et la copie d'artefact restent des autorités séparées.
• En mode de composition dlm-close-release, effectuer la découverte, la décision de version interne, la build, le changelog et la vérification des métadonnées, puis retourner les chemins modifiés exacts sans mise en scène, commit ou push, sauf si l'orchestrateur propriétaire délègue expressément la phase Git partagée.
• Ne pas copier ce skill personnel dans le dépôt ni le référencer depuis un manifeste de contexte de projet.
• Garder l'ingénierie, les preuves de release, la coordination DLM, Git, le déploiement et l'acceptation sur le terrain comme des états séparés.

Contexte de départ

1. Résoudre une racine Git et lire son AGENTS.md.
2. Si le dépôt utilise DLM, charger doc_llm/dlm.json et la tâche de release active.
3. Lire references/versioned-build-contract.md et references/git-sync.md.
4. Inspecter les fichiers .sln, .slnx, .csproj exécutable/bibliothèque/plugin, Directory.Build.*, les scripts de version du dépôt, les définitions CI/release et l'état de version avant toute édition.
5. Préférer l'infrastructure de version appartenant au dépôt. Créer build/versioning/ uniquement lorsque l'utilisateur demande d'établir un versionnage et qu'aucun mécanisme compatible n'existe.

Résoudre le profil du dépôt

Utiliser cet ordre :

1. profil de release/version déclaré dans doc_llm/dlm.json ou la documentation du dépôt ;
2. script de version/build existant et état de version ;
3. projet/solution spécifié par l'utilisateur ;
4. projet de démarrage exécutable non ambigu ou solution principale ;
5. si toujours ambigu, signaler les candidats et demander avant toute mutation de version.

Ne pas intégrer les chemins d'un produit connu dans le skill personnel. Le comportement spécifique au projet appartient au contrat du dépôt ou à ses scripts.

Décisions de version par hachage source (règle interne autonome)

La décision d'incrémenter une version et le niveau d'incrément sont pris automatiquement par des règles internes (sauf si l'utilisateur remplace explicitement le niveau dans le prompt). Hacher les entrées source appartenant au projet, pas les binaires de sortie.

Inclure selon le cas :

• .cs, .fs, .vb, .xaml, .axaml ;
• .csproj, .fsproj, .vbproj, .props, .targets ;
• ressources, manifestes, références de packages/projets et entrées de génération de code appartenant au projet.

Exclure :

• bin/, obj/, out/, publish/, artifacts/, la mise en scène (staging) et la sortie d'exécution copiée ;
• les props de version générées, les changelogs et les notes de release ;
• l'état de version lui-même lors du calcul du hachage source d'un module ;
• les sorties .pdb, .deps.json, DLL/EXE/package générées.

Table de décision interne :

• Pas d'incrément (none) : Un hachage d'entrée source de module inchangé n'incrémente jamais. Si seuls des fichiers non-modules (tels que la documentation, les enregistrements DLM ou les scripts du dépôt en dehors des entrées hachées des modules) ont changé, ou si aucune entrée source de module n'a changé depuis le hachage enregistré, ne pas incrémenter les versions et ne pas créer de mutation de version vide ; procéder directement à la phase de commit Git et de push distant pour les modifications autorisées réelles dans la portée.
• Incrément automatique lorsque le hachage d'entrée source du module a changé : Inspecter l'impact sémantique du diff du module et les règles du dépôt pour sélectionner le niveau automatiquement sans s'arrêter pour demander :
  • major / A : API publique cassante, format persistant, découverte de plugin, exécution, autorisation ou contrat de déploiement ;
  • minor / B : fonctionnalité rétrocompatible, nouveau module/plugin/outil ou ajout de capacité ;
  • patch / C : correction de bogue rétrocompatible, correction de mise en page/accessibilité/localisation, refactoring, réglage des performances, journalisation ou maintenance interne ;
  • auto : valeur par défaut déclarée par le dépôt lorsqu'elle est configurée, sinon évaluer via les règles major / minor / patch ci-dessus (par défaut patch).

Métadonnées binaires

Pour les projets de style SDK, s'assurer que les valeurs de version publiques transitent vers les sorties générées :

<Version>1.2.3</Version>
<AssemblyVersion>1.2.3.0</AssemblyVersion>
<FileVersion>1.2.3.0</FileVersion>
<InformationalVersion>1.2.3</InformationalVersion>
<IncludeSourceRevisionInInformationalVersion>false</IncludeSourceRevisionInInformationalVersion>

Ne pas placer de branche, SHA de commit, URL distante, auteur/e-mail, message de commit, chemin machine ou chemin de dépôt dans les champs de version binaire publique. La provenance Git appartient aux logs Git/CI/release.

Build et vérification

Lorsque les règles internes incrémentent un ou plusieurs modules (ou lorsque les entrées de module pertinentes pour la build ont changé), utiliser le script du dépôt s'il est présent ; sinon, build la portée sélectionnée en série :

dotnet build <project-or-solution> -c Release -m:1

Ne pas forcer la suppression d'une sortie verrouillée. Signaler le processus de verrouillage et s'arrêter sauf si l'utilisateur autorise un arrêt sécurisé du processus.

Après la build, valider uniquement les revendications requises par la ligne de base de release gelée et le profil du dépôt :

1. exécuter les tests affectés et les vérifications de release du dépôt ;
2. vérifier au moins une sortie pour chaque module public modifié ;
3. lire la version fichier/produit/assembly/informative via un outillage approprié ;
4. vérifier le chemin de sortie attendu et, si requis, les métadonnées SHA-256/package ;
5. s'assurer que les modules inchangés n'ont pas été incrémentés ;
6. générer le changelog / résumé de release concis du dépôt lorsque le profil de release ou un véritable consommateur de release/décision l'exige.

Si les métadonnées, tests, hachages ou l'identité de sortie requis ne peuvent pas être vérifiés, la revendication de release correspondante est incomplète et bloque la phase de commit/push Git. Signaler séparément les échecs préexistants non liés ou administratifs ; ils n'invalident pas une sortie conforme à moins qu'un impact matériel ne soit démontré.

Phase obligatoire de commit Git et push distant

Suivre la Synchronisation Git sur chaque appel direct de dlm-version-master (sauf suppression explicite par l'utilisateur ou exécution en tant qu'enfant composé sans délégation Git) :

1. Exécuter la décision de version interne -> build vérifiée (lorsqu'un incrément a eu lieu ou que les entrées pertinentes pour la build ont changé) -> revue pré-commit (ponytail-review et hooks du dépôt) -> git commit à portée exacte -> git push vers la branche distante.
2. Chaque commit créé par dlm-version-master doit utiliser un message de commit structuré multi-lignes détaillé, basé sur le git diff --cached réel et les transitions de version (jamais un résumé d'une ligne ou un "bump version" / "mise à jour fichiers" vague). Il doit explicitement inclure les quatre sections requises :
   • 修改范围 (Portée) : modules/projets/sous-systèmes modifiés et fichiers autorisés clés ou limites ;
   • 对应版本 (Version) : niveau d'incrément (none / patch / minor / major) et transition de version ancienne -> nouvelle pour chaque module affecté (ou version actuelle avec none (sourceHash unchanged) lorsqu'aucun module n'a été incrémenté) ;
   • 怎么改的 (Comment) : implémentation technique concrète dérivée du diff mis en scène (points d'entrée, flux de données/contrôle, ajustements d'algorithme/UI/config/build) ;
   • 为什么改的 (Pourquoi) : cause racine, exigence/tâche motrice, déclencheur de défaut ou raison architecturale/de compatibilité pour le changement de code et la décision de version.
3. Lorsque les règles internes décident de ne pas incrémenter les versions (hachages source des modules inchangés), ignorer la mutation de version et ne pas créer de commit de version vide ; toujours mettre en scène, reviewer, commiter (avec le même message de commit structuré en quatre parties) et pousser les modifications autorisées du dépôt prévues dans la portée, ou pousser les commits vérifiés non poussés existants sur la branche courante.

Sortie

Rapporter la source du profil du dépôt, la ligne de base de release gelée / ligne d'arrêt, la décision de version interne (none / patch / minor / major) et sa justification, la portée de la build et les commandes (lorsqu'exécutées), les transitions de version/hachage des modules, les modules inchangés, les tests correspondant aux revendications, les métadonnées/hachages de sortie vérifiés, le consommateur/chemin du changelog, la liste des fichiers modifiés autorisée, le message de commit structuré complet (修改范围 / 对应版本 / 怎么改的 / 为什么改的), le hachage du commit, le résultat vérifié du push de la branche distante, et les écarts bloquants versus consultatifs. Garder les niveaux de preuve plus élevés distincts du succès de la build et de la synchronisation Git.