Branches, Integration und Stable-Releases
Verfolge Git-Referenzen vom isolierten Aufgaben-Worktree über Lieferung, Integration und Übernahme bis zum versionierten Stable-Release.
Die Plattform verwaltet Worktrees, Commits, Lieferreferenzen, Integration, Übernahme und Bereinigung. Coding-Agenten bearbeiten Dateien; Git-Änderungen führt die Plattform aus.
1. Die Plattform führt Git-Änderungen aus
Ein Coding-Agent erstellt keine Branches und führt weder Stage, Commit, Push noch Merge aus. Die Plattform erfasst seine Dateiänderungen und verwaltet Aufgaben- und geschützte Branches.
task/<key>developmain2. Jede Coding-Ausführung ist isoliert
Verwaltete Coding-Ausführungen nutzen isolierte Git-Worktrees. Das gilt auch bei einem einzigen Ausführungsplatz sowie beim Fortsetzen und erneuten Ausführen. Eine Parallelität von eins verlagert die Arbeit nicht in den gemeinsamen Checkout.
- Der Branch task/<key> hält Aufgabenarbeit vom Integrationsbranch getrennt.
- Die Plattform sichert und veröffentlicht das Aufgabenergebnis vor der Integration.
- Die reguläre Bereinigung setzt voraus, dass der Aufgabenbranch im Integrationsziel enthalten ist.
3. Entfernte Lieferungen haben eine eindeutige Identität
Lieferreferenzen identifizieren Versuch, Fencing-Generation und Commit. Ein Fencing-Token ist eine aufsteigende Lease-Generation; ein veralteter Runner darf keinen neueren Versuch durch ein angenommenes Ergebnis überschreiben.
- Ergebnisreferenzen bewahren den gelieferten Commit; Salvage-Referenzen sichern wiederherstellbare Arbeit vor dem Abbau.
- Quarantäne-Referenzen halten Belege abgelehnter Lieferungen getrennt vom Integrationsbranch.
runner/<host>/<key>agent-studio/results/<attempt>/fence-<n>/<sha>agent-studio/salvage/...agent-studio/quarantine/...4. Nach automatischen Prüfungen, vor menschlichem Review integrieren
Nach erfolgreicher Lieferung und automatischen Prüfungen integriert die Plattform in das konfigurierte Ziel, üblicherweise develop. Sie prüft Lieferbelege, Fencing, Historie und Konflikte. Integriert bedeutet, dass die maßgeblichen gelieferten Commits von diesem Branch erreichbar sind.
Das menschliche Review folgt auf dem integrierten Stand. Integration bedeutet weder Abnahme noch Release oder Stable-Status. Diese Entscheidungen werden getrennt dokumentiert.
5. Den geprüften Release-Kandidaten übernehmen
Eine release/<utc>-Markierung hält den develop-Kandidaten fest. Die Freigabeprüfung berechnet den Umfang neu, prüft Manifest und erforderliche Checks und setzt main mit einem atomaren Push ohne Force auf genau diesen Kandidaten.
Der Kandidat kann integrierte Aufgaben enthalten, deren Abnahme noch aussteht. Prüfe offene Reviews und Eskalationen im Manifest vor der Übernahme.
6. Eine geprüfte Version festhalten
Eine Stable-Bereitstellung beginnt mit einem unveränderlichen v<semver>-Tag auf einem qualifizierten main-Commit. Das Build-Manifest hält Quell-SHA, Version, Prüfungen, Artefakte und Release-Belege fest. Eine Korrektur erhält eine neue Version und ein neues Tag.
7. Erreichbarkeit vor der Bereinigung prüfen
Der reguläre Abschluss entfernt Aufgaben-Worktree und Branch erst nach ihrer Aufnahme in das Integrationsziel. Eine Bereinigung veralteter Referenzen legt einen Löschplan zur Bestätigung vor. Aktive, ausgecheckte und geschützte Referenzen bleiben erhalten, ebenso Referenzen mit unklarer Zuordnung oder Wiederherstellbarkeit.
Git-Referenzen
Von der Aufgabenkarte zum Stable-Release
Die Plattform speichert Git-Referenzen für Lieferung, Integration und Release.- 01 · Auftrag Aufgabenkarte definiertes Ergebnis
- 02 · Isolieren Isolierter Worktree
task/<key>nach Integration entfernen - 03 · Liefern Runner-Referenzen
runner · results · salvage · quarantinenach Aufbewahrungsregel bereinigen - 04 · Integrieren
developIntegrationsprüfung - 05 · Freigeben
mainrelease/<utc>geschützte Markierung - 06 · Festhalten Stable-Release
v<semver> + manifest
| Klasse | Angelegt durch | Gelöscht, wenn |
|---|---|---|
task/<key> | Aufgabenvorbereitung | die Referenz im Integrationsbranch enthalten ist und kein aktiver Worktree sie benötigt. |
runner/<host>/<key> | Entfernter Runner | sie nach develop und main übernommen wurde und mindestens 7 Tage alt ist. |
agent-studio/results/<attempt>/fence-<n>/<sha> | Laufabschluss | der Nachweis-Commit auf main liegt; das Protokoll hält Referenz, SHA, Nachweisbranch und Aufgabenschlüssel fest. |
agent-studio/salvage/… | Sicherung vor dem Abbau | die Aufgabe abgeschlossen ist und der Commit auf main liegt oder die Referenz mindestens 14 Tage alt ist. |
agent-studio/quarantine/… | Integrationsprüfung | sie mindestens 30 Tage alt ist und keine offene Eskalation auf sie verweist. |
release/<utc> | Release-Übernahme | Nie durch die Branch-Bereinigung; Release-Referenzen sind geschützt. |
v<semver> | Release-Erstellung | Nie; Stable-Tags sind unveränderlich. |
8. Über das Aufgabenprotokoll prüfen
Dieser Ablauf koordiniert Lieferungen über die Aufgabe mit dokumentiertem Umfang, Commit, Prüfungen, Befunden und menschlicher Entscheidung. Integrations- und Freigabeprüfungen nutzen diese Aufzeichnungen ohne einen zusätzlichen Pull Request.