atlasray66-collab/dlm-close-release

DLM Close Release 7 Portable

Objectif

Fermer un scope d'ingénierie vérifié sans confondre achèvement de tâche, capitalisation des connaissances, production de version, gestion de version, commit Git ou déploiement. Ce skill personnel orchestre le cycle de vie ; les contrats du dépôt et les skills enfants conservent leurs propres règles techniques.

Porte de gouvernance des résultats

Lire et appliquer la Gouvernance des résultats DLM partagée avant toute écriture de fermeture, mutation de version/version, audit formel, mise en staging ou commit.

• Maintenir séparés l'état cible d'ingénierie, l'état des preuves, l'état de coordination DLM, l'état de version, l'état Git, l'état de déploiement et l'acceptation terrain. Avancer l'un n'implique pas l'autre.
• Résoudre une Ligne de base d'acceptation pour le mode autorisé. Avant les écritures de fermeture ou les mutations de version/Git, le Propriétaire de la Ligne de base fige une fois sa cible, ses non-objectifs, le Périmètre autorisé, les preuves requises, les critères et la ligne d'arrêt. Les hachages, BOM/EOL, représentations de checkout et reçus ne la figent ni ne l'invalident.
• Les enregistrements de fermeture/capitalisation/version ne sont un travail cible que lorsqu'ils sont demandés ou consommés par le contrat/décision applicable. Les changements administratifs purs ne rouvrent pas une construction/test/audit non lié.
• Utiliser au maximum un audit formel complet pour un état cible stable, et seulement lorsque l'utilisateur, un contrat accepté ou un risque matériel le justifie. Après une réparation, revalider uniquement les conditions échouées et les régressions directes.

Sélectionner le mode autorisé le plus restreint

Mode	Actions autorisées	Intention typique
close-only	Revue de capitalisation, sédimentation, validation DLM	"关闭任务""完成沉淀"
release-verify	close-only plus construction de version/version du dépôt et vérification des métadonnées des artefacts	"准备发布""验证发布版本"
release-commit	release-verify plus mise en staging et commit par chemin exact	"更新版本并提交 Git"

Par défaut, utiliser close-only. Une demande de commit n'autorise pas push, tag, déploiement, publication ou copie d'artefacts. Chacun doit être autorisé séparément. Si le libellé est insuffisant pour distinguer une mutation Git/version, s'arrêter et demander.

Verrouillage du dépôt et du contrat

1. Résoudre une racine Git et lire son AGENTS.md et son contrat DLM.
2. Exécuter le dlm-load minimal nécessaire pour la tâche et le profil de version.
3. Ne pas copier ce skill personnel dans le dépôt ni l'ajouter à un manifeste de contexte.
4. Utiliser le profil de version déclaré par le dépôt :
   • none : fermeture uniquement, sauf si l'utilisateur fournit une procédure ;
   • dotnet : utiliser dlm-version-master en mode composition ;
   • custom : utiliser le contrat de version/construction/vérification appartenant au dépôt.
5. Pour les travaux multi-dépôts ou sous-modules, utiliser une liste d'autorisation, un résultat de validation et un commit séparés par racine Git. Ne pas revendiquer d'atomicité inter-dépôts.

Phase 0 — Instantané de périmètre

Avant toute écriture, réaliser cet instantané combiné de sécurité du périmètre et de l'auteur une fois :

git status --short
git diff --name-status
git diff --cached --name-status
git ls-files --others --exclude-standard

Construire des ensembles exacts pour les candidats appartenant à la tâche, les modifications préexistantes non liées et les fichiers déjà mis en staging. Si la propriété ne peut être établie à partir de l'intention de l'utilisateur, du Périmètre autorisé figé, des documents de la tâche et du diff, s'arrêter avant toute mutation. Ne pas répéter l'instantané simplement pour fabriquer une preuve d'autorisation. Ne jamais utiliser git add . ou git add -A.

Phase 1 — Revue de capitalisation

Effectuer une Revue de capitalisation ciblée sur les critères figés et les preuves correspondant aux revendications. Utiliser dlm-reflect ; une revue indépendante formelle est facultative sauf si l'utilisateur la demande, qu'un contrat accepté l'exige ou qu'un risque matériel le justifie. Continuer lorsque le niveau d'achèvement déclaré est prouvé, ou orienter un écart matériel restant comme travail/blocage du périmètre actuel. Le succès de la construction seul n'est pas une preuve de comportement, d'interface utilisateur, de matériel, de migration, de sécurité ou de terrain ; de même, un indice administratif obsolète ne suffit pas à infirmer un comportement prouvé.

Phase 2 — Sédimentation

Lorsque l'utilisateur a demandé une sédimentation, que le contrat accepté du dépôt/de la tâche l'exige, ou qu'un consommateur réel de chargement/version/décision a besoin d'une synchronisation, exécuter dlm-sediment une fois en mode composition. Écrire uniquement les connaissances et l'état de la tâche/tâche de domaine confirmés. Les portes d'approbation BRIEF/L0 restent actives. Les skills enfants doivent retourner les chemins exacts modifiés et ne doivent pas mettre en staging ni committer. Si aucun déclencheur de ce type n'existe, enregistrer sediment: non requis et préserver la conclusion d'ingénierie vérifiée.

Synchroniser une fois pour les consommateurs réels de tâche/connaissances et réutiliser les preuves existantes. Ne pas créer de reçus synonymes ni relancer une validation d'ingénierie non liée parce que seuls des enregistrements de coordination ont changé.

Pour close-only, exécuter les vérifications de santé DLM uniquement lorsque la fermeture autorisée inclut l'état DLM ou qu'un contrat/consommateur actuel en dépend, puis s'arrêter après le rapport de fermeture. Une vérification non applicable ignorée n'est pas un échec.

Phase 3 — Vérification de version

Uniquement pour les modes de version :

1. Résoudre le profil de version du dépôt et le périmètre exact de la sortie.
2. Déterminer l'intention de version. Les versions majeure/mineure nécessitent une intention explicite. Le correctif/automatique n'est autorisé que lorsque l'intention de version existe et que le contrat du dépôt déclare cette valeur par défaut.
3. Exécuter le processus de version/construction du dépôt en série, sauf si son contrat spécifie autre chose.
4. Exécuter les tests et vérifier les métadonnées des binaires/packages publics et les hachages requis par les critères/profil de version figés ; ne pas ajouter de vérifications de préférence du réviseur comme nouvelles conditions de version.
5. Ajouter uniquement l'état de version intentionnel, le changelog, l'infrastructure de version et les fichiers source appartenant à la tâche à la liste d'autorisation candidate.

Un échec de construction, test, hachage ou métadonnée bloque les revendications de commit/version lorsque cette vérification est requise par la Ligne de base de version figée, le profil du dépôt ou un risque matériel de sortie démontré. Les échecs non liés préexistants ou administratifs sont signalés séparément et n'élargissent pas silencieusement les critères de version.

Phase 4 — Porte exacte de l'ensemble mis en staging

Uniquement pour release-commit :

• Normaliser la liste d'autorisation en chemins exacts relatifs au dépôt.
• Comparer les fichiers actuellement mis en staging avec l'instantané pré-stage.
• Ne pas désactiver le travail de l'utilisateur. Si des fichiers pré-stage se trouvent en dehors de la liste d'autorisation, s'arrêter et signaler.
• Si un fichier autorisé mélange des modifications non liées préexistantes qui ne peuvent pas être séparées en toute sécurité, s'arrêter et demander.
• Exclure les secrets, la configuration locale de la machine, bin/, obj/, out/, les logs, les captures, la sortie de publication/staging et les artefacts temporaires, sauf demande explicite et appropriée.
• Exécuter les vérifications d'espacement/encodage requises par le dépôt.

Phase 5 — Mise en staging et commit

git add -- <chemins-exacts>
git diff --cached --name-status
git diff --cached --stat
git diff --cached --check
git status --short

Exiger une égalité exacte entre les chemins mis en staging et la liste d'autorisation approuvée. Avant le commit, exécuter les revues pré-commit requises par le AGENTS.md global (la porte ponytail-review et son marqueur de garde) et par le dépôt, sur ce diff exact mis en staging ; résoudre ou conserver explicitement chaque constat comme ces règles l'exigent. Si un skill de revue ou un hook requis est indisponible, s'arrêter avant de committer et signaler cette lacune plutôt que de la contourner. Committer une fois par racine Git en utilisant les conventions du dépôt. Ne pas amender sauf demande expresse. Après le commit, inspecter git show --stat --oneline HEAD et l'arbre de travail restant.

Règles d'échec

• Une commande enfant non nulle bloque les phases suivantes uniquement lorsqu'elle échoue à un critère figé actuel, un contrat applicable, une vérification d'intégrité d'artefact touché ou une frontière de sécurité/version matérielle. Les échecs non liés préexistants et administratifs sont signalés sans devenir de nouvelles portes.
• Une tâche bloquée n'est pas fermée ; persister sa raison, son propriétaire, ses tentatives et sa condition de version.
• Un travail annulé peut persister son état d'annulation sans prétendre à une version réussie.
• Les verrous de sortie sont signalés, pas supprimés de force.
• Le travail non lié reste intact.
• L'invalidation de la Ligne de base est réservée aux conflits de nouvelle SSOT, prémisse fausse, risque de sécurité ou de perte de données. Les changements de EOL/BOM, clean/smudge, timestamp, ordre d'affichage ou de reçu uniquement n'invalident ni ne rouvrent une validation complète.

Rapport final

Signaler le mode, l'identité du dépôt/projet, l'état/propriétaire/ligne d'arrêt de la Ligne de base d'acceptation, le type/verdict de la Revue de capitalisation, les consommateurs/chemins de sédimentation, les vérifications DLM, le profil de version et les changements de version, les artefacts vérifiés correspondant aux revendications, la liste d'autorisation mise en staging, le hachage du commit s'il y a lieu, les écarts bloquants vs. consultatifs, et les fichiers non liés délibérément laissés intacts. Indiquer explicitement lesquels de commit/push/tag/déploiement/copie d'artefacts n'ont pas été effectués. S'arrêter à la frontière du mode autorisé ; ne pas activer automatiquement la prochaine Sous-tâche, élément de travail, constat différé, push, tag ou déploiement.