atlasray66-collab/dlm-version-master

DLM Version Master 7 Portable

Zweck

Versionieren, verifizieren, committen und pushen Sie Änderungen an .NET-Repositorys unter Verwendung der Repository-eigenen Infrastruktur, ohne einen Produktnamen oder ein Verzeichnislayout anzunehmen. Dieser persönliche Skill stellt den generischen Workflow bereit; jedes Repository deklariert seine Projekte, den Freigabeeinstiegspunkt, die Modulzuordnung, die Ausgabepfade und die Commit-Richtlinie.

Ergebnis-Governance-Gate

Lesen und befolgen Sie die gemeinsame DLM Outcome Governance vor Versionierungs-Mutation, Release-Build, Artefakt-Verifikation, Staging, Commit oder Push.

• Etablieren Sie eine eingefrorene Freigabe-/Versionsbasislinie mit dem autorisierten Umfang, den erforderlichen Modulen/Ausgaben, der internen Versionsentscheidung, den anspruchsgemäßen Nachweisen und der Stopplinie. Der direkte Aufruf von dlm-version-master autorisiert die interne Versionsbewertung, den erforderlichen Build/Verifikation, den exakten Git-Commit und den Push zum Remote-Branch; es autorisiert weder das Kopieren, Veröffentlichen, Taggen, Bereitstellen noch das Feld-Rollout von Artefakten.
• Ein Quell-Hash unterstützt den Anspruch der Moduländerung/-Versionsentscheidung; ein Ausgabe-Hash unterstützt die Byte-Identität, wenn das Profil ihn verwendet. Keiner friert eine Basislinie ein oder beweist Laufzeit, Koordination, Bereitstellung oder Feldzustand.
• Führen Sie nur profilnotwendige oder materielle Risikoprüfungen durch. Grüne Metadaten können Verhaltensnachweise nicht ersetzen, und nicht zusammenhängende administrative Fehlschläge können nicht stillschweigend zu Release-Kriterien werden.
• Führen Sie eine kombinierte Identitäts-/Umfangs-/Vorab-Sicherheitsprüfung vor der Mutation durch und gehen Sie dann den kürzesten Freigabepfad. Fügen Sie keine Quittungen, doppelten Zusammenfassungen oder wiederholten vollständigen Verifikationen ohne einen echten Konsumenten oder eine neue materielle Unsicherheit hinzu.

Autorität und Zusammensetzung

• Jeder direkte Aufruf von dlm-version-master trägt die ständige Benutzerautorisierung, um:
  1. autonom über interne Regeln zu entscheiden, ob Versionen erhöht werden (none vs. patch / minor / major), es sei denn, der Benutzer gibt explizit eine Bump-Richtlinie in der Eingabeaufforderung an;
  2. den erforderlichen Release-Build und die binäre Metadatenüberprüfung auszuführen, wenn sich Modulversionen oder buildrelevante Quelleingaben ändern;
  3. exakt zugelassene Pfade zu staggen, erforderliche Pre-Commit-Reviews (ponytail-review) auszuführen, einen detaillierten strukturierten Commit-Betreff, der 修改范围 (Scope), 对应版本 (Version), 怎么改的 (How), and 为什么改的 (Why) abdeckt, in Git zu committen und in den Remote-Repository-Branch zu pushen (git push).
• Überspringen Sie Commit oder Push bei direktem Aufruf nur, wenn der Benutzer ausdrücklich anweist, im aktuellen Durchlauf nicht zu committen/zu pushen, oder wenn ein konkretes Sicherheits-/Verifikations-Gate dies blockiert (fehlgeschlagener erforderlicher Build/Test/Review, gemischte nicht zusammenhängende Änderungen in einer Zieldatei, fehlender/mehrdeutiger Remote, oder divergierter Remote-Branch).
• Remote-Repository-Erstellung, Force-Push, Tag, Bereitstellung, Veröffentlichung und Artefaktkopie bleiben separate Autoritäten.
• Im dlm-close-release-Kompositionsmodus führen Sie Ermittlungen, interne Versionsentscheidung, Build, Changelog und Metadatenüberprüfung durch, geben dann exakte geänderte Pfade zurück, ohne zu staggen, zu committen oder zu pushen, es sei denn, der besitzende Orchestrator delegiert ausdrücklich die gemeinsame Git-Phase.
• Kopieren Sie diesen persönlichen Skill nicht in das Repository und referenzieren Sie ihn nicht aus einem Projektkontext-Manifest.
• Halten Sie Engineering, Release-Nachweise, DLM-Koordination, Git, Bereitstellung und Feldakzeptanz als separate Zustände.

Startkontext

1. Ermitteln Sie eine Git-Wurzel und lesen Sie deren AGENTS.md.
2. Wenn das Repository DLM verwendet, laden Sie doc_llm/dlm.json und die aktive Release-Aufgabe.
3. Lesen Sie references/versioned-build-contract.md und references/git-sync.md.
4. Untersuchen Sie bestehende .sln, .slnx, ausführbare/Bibliotheks-/Plugin-.csproj, Directory.Build.*, Repository-Versionsskripte, CI/Release-Definitionen und Versionszustand vor der Bearbeitung.
5. Bevorzugen Sie die Repository-eigene Versionsinfrastruktur. Erstellen Sie build/versioning/ nur, wenn der Benutzer die Einrichtung der Versionierung verlangt und kein kompatibler Mechanismus existiert.

Repository-Profil ermitteln

Verwenden Sie diese Reihenfolge:

1. Release/Version-Profil, deklariert in doc_llm/dlm.json oder Repository-Dokumenten;
2. vorhandenes Versions-/Build-Skript und Versionszustand;
3. vom Benutzer angegebenes Projekt/Solution;
4. eindeutiges ausführbares Startprojekt oder primäre Solution;
5. falls immer noch mehrdeutig, melden Sie Kandidaten und fragen Sie vor Versionsmutation.

Betten Sie keine bekannten Produktpfade in den persönlichen Skill ein. Projektspezifisches Verhalten gehört in den Repository-Vertrag oder seine Skripte.

Quell-Hash-Versionsentscheidungen (autonome interne Regel)

Ob eine Version erhöht werden soll und welche Erhöhungsstufe anzuwenden ist, wird automatisch durch interne Regeln entschieden (es sei denn, der Benutzer überschreibt die Stufe explizit in der Eingabeaufforderung). Hashen Sie projekteigene Quelleingaben, nicht Ausgabebinärdateien.

Schließen Sie, soweit zutreffend, ein:

• .cs, .fs, .vb, .xaml, .axaml;
• .csproj, .fsproj, .vbproj, .props, .targets;
• projekteigene Ressourcen, Manifeste, Paket-/Projektverweise und Code-Generierungseingaben.

Schließen Sie aus:

• bin/, obj/, out/, publish/, artifacts/, Staging und kopierte Laufzeitausgaben;
• generierte Versionseigenschaften, Changelogs und Release-Notes;
• Versionszustand selbst bei der Berechnung eines Quell-Hashes eines Moduls;
• .pdb, .deps.json, generierte DLL/EXE/Paket-Ausgaben.

Interne Entscheidungstabelle:

• Keine Erhöhung (none): Ein unveränderter Modul-Quell-Eingabe-Hash führt nie zu einer Erhöhung. Wenn sich nur Nicht-Modul-Dateien (wie Dokumentation, DLM-Datensätze oder Repository-Skripte außerhalb der Modul-Hash-Eingaben) geändert haben oder wenn sich keine Modul-Quelleingaben seit dem aufgezeichneten Hash geändert haben, erhöhen Sie keine Versionen und erstellen Sie keine leere Versionsmutation; fahren Sie direkt mit der Git-Commit- und Remote-Push-Phase für die tatsächlichen zugelassenen Änderungen im Umfang fort.
• Automatische Erhöhung, wenn sich der Modul-Quell-Eingabe-Hash geändert hat: Untersuchen Sie die semantischen Auswirkungen des Modul-Diffs und der Repository-Regeln, um die Stufe automatisch auszuwählen, ohne nachfragen zu müssen:
  • major / A: Breaking public API, persistentes Format, Plugin-Erkennung, -Ausführung, -Autorisierung oder Bereitstellungsvertrag;
  • minor / B: Rückwärtskompatible Funktion, neues Modul/Plugin/Werkzeug oder Fähigkeitsergänzung;
  • patch / C: Rückwärtskompatibler Bug-Fix, Layout-/Barrierefreiheits-/Lokalisierungskorrektur, Refactoring, Leistungsoptimierung, Protokollierung oder interne Wartung;
  • auto: Vom Repository deklarierter Standard, falls konfiguriert, andernfalls Bewertung über die obigen major / minor / patch-Regeln (Standard ist patch).

Binäre Metadaten

Stellen Sie bei SDK-ähnlichen Projekten sicher, dass öffentliche Versionswerte in generierte Ausgaben fließen:

<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>

Platzieren Sie Branch, Commit-SHA, Remote-URL, Autor/E-Mail, Commit-Nachricht, Maschinenpfad oder Repository-Pfad nicht in öffentlichen binären Versionsfeldern. Git-Provenienz gehört in Git/CI/Release-Logs.

Build und Verifikation

Wenn interne Regeln ein oder mehrere Module erhöhen (oder wenn sich buildrelevante Modul-Eingaben geändert haben), verwenden Sie das Repository-Skript, falls vorhanden; andernfalls bauen Sie den ausgewählten Umfang seriell:

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

Erzwingen Sie kein Löschen von gesperrten Ausgaben. Melden Sie den sperrenden Prozess und stoppen Sie, es sei denn, der Benutzer autorisiert eine sichere Prozessbeendigung.

Validieren Sie nach dem Build nur die Ansprüche, die von der eingefrorenen Freigabe-Basislinie und dem Repository-Profil gefordert werden:

1. Führen Sie betroffene Tests und Repository-Release-Prüfungen durch;
2. Verifizieren Sie mindestens eine Ausgabe für jedes geänderte öffentliche Modul;
3. Lesen Sie Datei-/Produkt-/Assembly-/Informationsversion durch geeignete Werkzeuge;
4. Verifizieren Sie den erwarteten Ausgabepfad und, wo erforderlich, SHA-256/Paket-Metadaten;
5. Stellen Sie sicher, dass unveränderte Module nicht erhöht wurden;
6. Generieren Sie die prägnante Changelog-/Release-Zusammenfassung des Repositorys, wenn das Release-Profil oder ein echter Release-/Entscheidungskonsument dies erfordert.

Wenn erforderliche Metadaten, Tests, Hashing oder Ausgabeidentität nicht verifiziert werden können, ist der entsprechende Release-Anspruch unvollständig und blockiert die Git-Commit-/Push-Phase. Melden Sie nicht zusammenhängende, bereits bestehende oder administrative Fehlschläge separat; sie machen eine konforme Ausgabe nicht ungültig, es sei denn, es wird eine materielle Auswirkung nachgewiesen.

Obligatorische Git-Commit- und Remote-Push-Phase

Befolgen Sie die Git-Synchronisation bei jedem direkten Aufruf von dlm-version-master (es sei denn, sie wird vom Benutzer ausdrücklich unterdrückt oder läuft als zusammengesetztes Kind ohne Git-Delegierung):

1. Führen Sie die interne Versionsentscheidung -> verifizierten Build (wenn erhöht oder buildrelevante Eingaben geändert) -> Pre-Commit-Review (ponytail-review und Repository-Hooks) -> exakten git commit -> git push zum Remote-Branch aus.
2. Jeder von dlm-version-master erstellte Commit muss eine detaillierte, mehrzeilige Commit-Nachricht verwenden, die auf dem tatsächlichen git diff --cached und den Versionsübergängen basiert (niemals eine einzeilige Zusammenfassung oder vages „Version erhöhen“ / „Dateien aktualisieren“). Sie muss explizit alle vier erforderlichen Abschnitte enthalten:
   • 修改范围 (Scope): geänderte Module/Projekte/Subsysteme und wichtige zugelassene Dateien oder Grenzen;
   • 对应版本 (Version): Erhöhungsstufe (none / patch / minor / major) und jeder betroffene Modul-alt -> neu-Versionsübergang (oder aktuelle Version mit none (sourceHash unchanged), wenn kein Modul erhöht wurde);
   • 怎么改的 (How): konkrete technische Implementierung abgeleitet aus dem gestagten Diff (Einstiegspunkte, Daten-/Kontrollfluss, Algorithmus/UI/Konfiguration/Build-Anpassungen);
   • 为什么改的 (Why): Grundursache, Anforderungs-/Aufgabentreiber, Fehlerauslöser oder architektonischer/Kompatibilitätsgrund sowohl für die Codeänderung als auch für die Versionsentscheidung.
3. Wenn interne Regeln entscheiden, keine Versionen zu erhöhen (unveränderte Modul-Quell-Hashes), überspringen Sie die Versionsmutation und erstellen Sie keinen leeren Versions-Commit; stagen, reviewen, committen (mit der gleichen vierteiligen strukturierten Commit-Nachricht) und pushen Sie dennoch alle beabsichtigten zugelassenen Repository-Änderungen im Umfang, oder pushen Sie vorhandene ungepushte verifizierte Commits auf dem aktuellen Branch.

Ausgabe

Melden Sie Repository-Profilquelle, eingefrorene Freigabe-Basislinie/Stopplinie, interne Versionsentscheidung (none / patch / minor / major) und Begründung, Build-Umfang und -Befehle (wenn ausgeführt), Modul-Hash-/Versionsübergänge, unveränderte Module, anspruchsgemäße Tests, verifizierte Ausgabe-Metadaten/-Hashes, Changelog-Konsument/Pfad, Zugelassene-geänderte-Datei-Liste, vollständige strukturierte Commit-Nachricht (修改范围 / 对应版本 / 怎么改的 / 为什么改的), Commit-Hash, verifiziertes Remote-Branch-Push-Ergebnis und blockierende versus beratende Lücken. Halten Sie höhere Beweisniveaus getrennt von Build- und Git-Synchronisationserfolg.