DLM Close Release 7 Portable

Was macht DLM Close Release 7 Portable?

Zweck

Schließen Sie einen verifizierten Engineering-Umfang ab, ohne Aufgabenabschluss, Wissenssedimentierung, Release-Erstellung, Versionierung, Git-Commit oder Deployment zu vermischen. Dieses persönliche Skill orchestriert den Lebenszyklus; Repository-Verträge und untergeordnete Skills behalten ihre technischen Regeln.

Outcome-Governance-Gate

Lesen und wenden Sie die gemeinsame DLM Outcome Governance an, bevor Sie einen Closure-Schreibvorgang, Release-/Versionsänderung, formales Audit, Staging oder Commit durchführen.

• Halten Sie Engineering-Zielzustand, Evidenzzustand, DLM-Koordinationszustand, Release-Zustand, Git-Zustand, Deployment-Zustand und Feldakzeptanz getrennt. Das Fortschreiten eines impliziert nicht das andere.
• Lösen Sie eine Akzeptanzbasis für den autorisierten Modus auf. Bevor Closure-Schreibvorgänge oder Release-/Git-Mutationen durchgeführt werden, friert der Basis-Eigentümer dessen Ziel, Nicht-Ziele, Autorisierte Umfang, erforderliche Evidenzen, Kriterien und Stopplinie einmal ein. Hashes, BOM/EOL, Checkout-Darstellung und Quittungen frieren es nicht ein oder invalidieren es nicht.
• Closure-/Sedimentierungs-/Release-Aufzeichnungen sind nur dann Zielarbeit, wenn sie vom anwendbaren Vertrag/Entscheid angefordert oder konsumiert werden. Reine administrative Änderungen eröffnen keinen unabhängigen Build/Test/Audit erneut.
• Verwenden Sie höchstens ein formales vollständiges Audit für einen stabilen Zielzustand, und nur, wenn der Benutzer, ein akzeptierter Vertrag oder ein materielles Risiko dies rechtfertigt. Nach der Reparatur validieren Sie fehlgeschlagene Bedingungen und direkte Regressionen erneut.

Wählen Sie den engsten autorisierten Modus

Modus	Zugelassene Aktionen	Typische Absicht
close-only	Closure Review, Sediment, DLM-Validierung	"Aufgabe schließen" "Abschluss sedimentieren"
release-verify	close-only plus Repository-Release-/Versionserstellung und Artefakt-Metadaten-Überprüfung	"Release vorbereiten" "Release-Version überprüfen"
release-commit	release-verify plus exakte-Pfad-Staging und Commit	"Version aktualisieren und Git-Commit durchführen"

Standardmäßig close-only. Ein Commit-Request autorisiert kein Push, Tag, Deployment, Veröffentlichung oder Artefakt-Kopieren. Jedes ist separat autorisiert. Wenn der Wortlaut nicht ausreicht, um eine Git-/Versionsmutation zu unterscheiden, stoppen Sie einmal und fragen Sie.

Repository- und Vertragssperre

1. Lösen Sie eine Git-Root auf und lesen Sie dessen AGENTS.md und DLM-Vertrag.
2. Führen Sie das minimale dlm-load aus, das für die Aufgabe und das Release-Profil erforderlich ist.
3. Kopieren Sie dieses persönliche Skill nicht in das Repository und fügen Sie es keinem Kontextmanifest hinzu.
4. Verwenden Sie das vom Repository deklarierte Release-Profil:
   • none: nur Closure, es sei denn, der Benutzer stellt eine Prozedur bereit.
   • dotnet: Verwenden Sie dlm-version-master im Kompositionsmodus.
   • custom: Verwenden Sie den repository-eigenen Versions-/Build-/Verifizierungsvertrag.
5. Verwenden Sie bei Multi-Repository- oder Submodul-Arbeiten eine separate Erlaubnisliste, ein Validierungsergebnis und einen separaten Commit pro Git-Root. Beanspruchen Sie keine Cross-Repository-Atomizität.

Phase 0 – Umfangs-Snapshot

Führen Sie vor jedem Schreibvorgang diesen kombinierten Writer-/Umfangs-Sicherheits-Snapshot einmal aus:

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

Erstellen Sie exakte Mengen für aufgabenbezogene Kandidaten, bereits vorhandene nicht zusammenhängende Änderungen und vorab gestagte Dateien. Wenn die Eigentümerschaft nicht aus Benutzerabsicht, eingefrorenem autorisiertem Umfang, Aufgabendokumenten und Diff ermittelt werden kann, stoppen Sie vor der Mutation. Wiederholen Sie den Snapshot nicht nur, um Autorisierungsnachweise zu erzeugen. Verwenden Sie niemals git add . oder git add -A.

Phase 1 – Closure Review

Führen Sie einen gezielten Closure Review gegen die eingefrorenen Kriterien und abgeglichenen Evidenzen durch. Verwenden Sie dlm-reflect; ein formales unabhängiges Review ist optional, es sei denn, der Benutzer fordert es an, ein akzeptierter Vertrag verlangt es oder ein materielles Risiko rechtfertigt es. Fahren Sie fort, wenn der deklarierte Fertigstellungsgrad nachgewiesen ist, oder leiten Sie eine materielle verbleibende Lücke als aktuelle Arbeits-/Blockierungsaufgabe. Der Build-Erfolg allein ist kein Verhalten, UI, Hardware, Migration, Sicherheit oder Feldevidenz; ebenso widerlegt ein veralteter administrativer Index allein nicht nachgewiesenes Verhalten.

Phase 2 – Sedimentierung

Wenn der Benutzer Sedimentierung angefordert hat, der akzeptierte Repository-/Aufgabenvertrag sie verlangt oder ein echter Lade-/Release-/Entscheidungs-Konsument Synchronisation benötigt, führen Sie dlm-sediment einmal im Kompositionsmodus aus. Schreiben Sie nur bestätigtes Aufgaben-/Domänenwissen und Status. BRIEF/L0-Genehmigungs-Gates bleiben aktiv. Untergeordnete Skills müssen exakte geänderte Pfade zurückgeben und dürfen nicht staggen oder committen. Wenn kein solcher Auslöser existiert, notieren Sie sediment: nicht erforderlich und bewahren Sie die verifizierte Engineering-Schlussfolgerung auf.

Synchronisieren Sie einmal für echte Aufgaben-/Wissenskonsumenten und verwenden Sie vorhandene Evidenzen wieder. Erstellen Sie keine synonymen Quittungen oder führen Sie keine nicht zusammenhängenden Engineering-Validierungen erneut durch, weil sich nur Koordinationsaufzeichnungen geändert haben.

Für close-only: Führen Sie DLM-Gesundheitschecks nur durch, wenn der autorisierte Closure den DLM-Zustand umfasst oder ein aktueller Vertrag/Konsumentenanspruch davon abhängt, und stoppen Sie dann nach dem Closure-Bericht. Ein übersprungener nicht anwendbarer Check ist kein Fehler.

Phase 3 – Release-Überprüfung

Nur für Release-Modi:

1. Lösen Sie das Repository-Release-Profil und den exakten Ausgabeumfang auf.
2. Bestimmen Sie die Versionsabsicht. Major/Minor erfordern explizite Absicht. Patch/Auto ist nur erlaubt, wenn eine Release-Absicht besteht und der Repository-Vertrag diesen Standard erklärt.
3. Führen Sie den Repository-Versions-/Build-Prozess seriell aus, es sei denn, sein Vertrag spezifiziert etwas anderes.
4. Führen Sie Tests durch und überprüfen Sie die öffentlichen Binär-/Paketmetadaten und Hashes, die durch die eingefrorenen Release-Kriterien/das Profil erforderlich sind; fügen Sie keine Reviewer-Präferenzchecks als neue Release-Bedingungen hinzu.
5. Fügen Sie der Kandidaten-Erlaubnisliste nur beabsichtigte Versionszustände, Changelog, Release-Infrastruktur und aufgabenbezogene Quelldateien hinzu.

Ein Build-, Test-, Hash- oder Metadatenfehler blockiert Commit-/Release-Ansprüche, wenn dieser Check durch die eingefrorene Release-Basis, das Repository-Profil oder ein nachgewiesenes materielles Ausgaberisiko erforderlich ist. Nicht zusammenhängende bereits vorhandene oder administrative Fehler werden separat gemeldet und erweitern nicht stillschweigend die Release-Kriterien.

Phase 4 – Exaktes gestagtes Set-Gate

Nur für release-commit:

• Normalisieren Sie die Erlaubnisliste auf Repository-relative exakte Pfade.
• Vergleichen Sie aktuell gestagte Dateien mit dem Vorab-Staging-Snapshot.
• Entstagen Sie keine Benutzerarbeit. Wenn vorab gestagte Dateien außerhalb der Erlaubnisliste liegen, stoppen Sie und melden Sie.
• Wenn eine erlaubnislistierte Datei nicht zusammenhängende bereits vorhandene Änderungen mischt, die nicht sicher getrennt werden können, stoppen Sie und fragen Sie.
• Schließen Sie Geheimnisse, maschinenlokale Konfiguration, bin/, obj/, out/, Logs, Captures, Publish-/Staging-Ausgabe und temporäre Artefakte aus, es sei denn, sie werden explizit angefordert und sind angemessen.
• Führen Sie Whitespace-/Encoding-Checks durch, die vom Repository gefordert werden.

Phase 5 – Staging und Commit

git add -- <exakte-pfade>
git diff --cached --name-status
git diff --cached --stat
git diff --cached --check
git status --short

Erfordern Sie exakte Gleichheit zwischen gestagten Pfaden und der genehmigten Erlaubnisliste. Führen Sie vor dem Commit die Pre-Commit-Reviews durch, die von der globalen AGENTS.md (das ponytail-review-Gate und sein Schutzmarker) und vom Repository für diesen exakten gestagten Diff verlangt werden; lösen Sie jeden Befund entsprechend den Regeln auf oder behalten Sie ihn explizit bei. Wenn ein erforderliches Review-Skill oder Hook nicht verfügbar ist, stoppen Sie vor dem Commit und melden Sie diese Lücke, anstatt sie zu umgehen. Committen Sie einmal pro Git-Root gemäß den Repository-Konventionen. Ändern Sie nicht, es sei denn, es wird angefordert. Überprüfen Sie nach dem Commit git show --stat --oneline HEAD und den verbleibenden Arbeitsverzeichnis.

Fehlerregeln

• Ein nicht-null untergeordneter Befehl blockiert spätere Phasen nur, wenn er ein aktuelles eingefrorenes Kriterium, einen anwendbaren Vertrag, eine Integritätsprüfung berührter Artefakte oder eine materielle Sicherheits-/Release-Grenze verletzt. Nicht zusammenhängende bereits vorhandene und administrative Fehler werden gemeldet, werden aber nicht zu neuen Gates.
• Eine blockierte Aufgabe ist nicht abgeschlossen; persistieren Sie ihren Grund, Eigentümer, Versuche und Release-Bedingung.
• Abgebrochene Arbeiten können Abbruchzustand persistieren, ohne eine erfolgreiche Release vorzutäuschen.
• Ausgabesperren werden gemeldet, nicht erzwungen gelöscht.
• Nicht zusammenhängende Arbeiten bleiben unberührt.
• Basis-Invalidierung ist für neuen SSOT-Konflikt, falsche Prämisse, Sicherheit oder Datenverlustrisiko reserviert. EOL/BOM, Clean/Smudge, Zeitstempel, Anzeigereihenfolge oder reine Quittungsänderungen invalidieren oder eröffnen keine vollständige Validierung erneut.

Abschlussbericht

Melden Sie Modus, Repository-/Projektidentität, Akzeptanzbasis-Zustand/Eigentümer/Stopplinie, Closure-Review-Typ/Urteil, Sediment-Konsumenten/Pfade, DLM-Checks, Release-Profil und Versionsänderungen, abgeglichene verifizierte Artefakte, gestagte Erlaubnisliste, Commit-Hash falls vorhanden, Blockierende versus Hinweis-Lücken und absichtlich unberührte nicht zusammenhängende Dateien. Geben Sie explizit an, welche von Commit/Push/Tag/Deployment/Artefakt-Kopieren nicht durchgeführt wurden. Stoppen Sie an der autorisierten Modus-Grenze; aktivieren Sie nicht automatisch die nächste Unteraufgabe, das nächste Arbeitselement, den nächsten aufgeschobenen Befund, Push, Tag oder Deployment.