Agent Studio
Projekte und Repositories

Projekte, Repositories und Branches

Ein Workspace bündelt zusammengehörige Projekte. Jedes Projekt steht für ein Repository. Branches und Revisionen benennen die Quelle hinter Aufgaben und Dokumenten.

Diese Seite beschreibt das am 25. September 2026 geprüfte Zielmodell. Herkunftsangaben, Branch-Ansichten und Grundstrukturen werden schrittweise umgesetzt. Die Grafik behauptet nicht, dass jede Oberfläche bereits das vollständige Modell durchsetzt.

Projektkontext ansehen
Beziehungsmodell

Ein Projekt, ein Repository, sichtbarer Branch-Kontext

Arbeitsbereiche ordnen Projekte. Ein Repository-Projekt identifiziert sein Git-Repository; der Branch-Kontext bestimmt den Stand einer Ansicht. Ein lokaler Checkout ist eine Arbeitskopie dieses Repositorys.

  1. Übergeordnete Ansicht

    Arbeitsbereich

    Ordnet zusammengehörige Projekte und bietet Navigation.

    Product Engineering
  2. Projektzuordnung

    Projekt

    Identifiziert ein Git-Repository und legt dessen Branch-Rollen fest.

    PROJ-001 · Agent Studio
  3. Inhalte und Versionsgeschichte

    Git-Repository

    Speichert Dokumentation, Prompts, Branches und Revisionen.

    Repository-EbeneDateien · Branches · Commits
    DarstellungWiki · Darstellung · Suche
    agent-studio.git

Der Branch-Kontext benennt die Quelle von Wiki-Seiten, Prompts und Aufgabenbasen. Beim Vergleich von Wissen und laufender Software hilft der angezeigte Branch.

developArbeitsbranch
WikiPromptsBasis neuer AufgabenProjektübersicht
mainRelease-Branch
Freigegebene AnwendungRelease-ManifestRelease-VerlaufVon der Wiki-Quelle getrennt
Integration und Release

Geprüfte Arbeit integrieren, verifiziertes Release markieren.

Der Release-Schritt übernimmt den Integrationsbranch mit dokumentiertem Review-Status. Ein unveränderlicher Versions-Tag kennzeichnet einen geprüften Stand.

  1. 01Aufgabenkartentask/*

    Abgegrenzte Arbeit hält Diff, Prüfungen und Review-Befunde fest.

  2. 02Integrationsbranchdevelop

    Revisionen gelangen nach bestandenen konfigurierten Prüfungen nach develop. Die menschliche Annahme kann noch ausstehen.

  3. 03Release-Übernahmedevelop → main

    Der Dialog zeigt vor der Bestätigung angenommene, ungeprüfte, eskalierte und nicht zugeordnete Arbeit.

  4. 04Release-Branchmain

    Ein main-Stand hält freigegebenen Code fest. Ein eigener Versions-Tag kennzeichnet ein unveränderliches Release.

  5. 05Versions-Tagv<semver>

    Ein geprüfter main-Commit wird mit Versions-Tag und Release-Manifest festgehalten. Ein Stable-Referenz-Checkout kann später auf einen anderen Stand wechseln.

Integration kann vor der menschlichen Annahme erfolgen. Konfigurierte Prüfungen laufen vor der Integration. Das menschliche Review bewertet anschließend die dokumentierten Ergebnisse; die Release-Übernahme ist eine eigene Entscheidung.

Projekte konfigurieren Branch-Rollen

Arbeits- und Release-Branch werden pro Projekt eingerichtet. develop und main sind Beispiele; ein Versions-Tag hält einen unveränderlichen Release-Stand fest.

Arbeitdevelop
Standardquelle für Wiki, Prompts und neue Aufgabenbasen.
Releasemain
Release-Branch mit Übernahmen aus dem Integrationsbranch.
Stable-Releasev<semver>
Ein unveränderlicher Versions-Tag kennzeichnet einen geprüften main-Stand.
Aufgabetask/AGT-1984
Isolierter Ausführungsbranch auf der festgelegten Aufgabenbasis.
AnsichtBenutzerauswahl
Gewählter Lesekontext einer Ansicht, zum Beispiel des Wikis.

Eine Repository-Struktur für Projektwissen

Dokumente sind Dateien im Repository. Das Wiki stellt sie dar und macht sie durchsuchbar.

  • repository/
  • README.md
  • docs/# Quelldokumente
  • README.md# Wiki-Einstiegsseite
  • concepts/
  • operations/
  • prompts/# Prompt-Katalog
  • .agent-studio/# Projekthinweise ohne Zugangsdaten

Wo die Daten liegen

Git speichert Inhalte

Dokumente, Prompt-Dateien, Versionsgeschichte und Branch-Zuordnung.

Wiki stellt Inhalte dar

Baumansicht, Darstellung, Suche, Metadaten und Bearbeitung.

Anwendung speichert Aufgaben

Aufgabenverlauf mit Repository, Basisbranch und Revision.

Registry speichert lokalen Zustand

Absolute Pfade, Aktualisierungszeiten und Referenzen auf Zugangsdaten.

Am 25. September 2026 anhand des Projekt-Beziehungsmodells (AGT-1984) geprüft. Das Diagramm unterscheidet das Repository-Modell von Bedienelementen für den Branch-Kontext, deren Verfügbarkeit von der jeweiligen Produktansicht abhängt.

Ein Projekt, ein Repository

Bilde ein Produkt mit mehreren Repositories als zusammengehörige Projekte in einem Workspace ab. Ein Checkout-Pfad ist austauschbare Infrastruktur und sollte nicht die dauerhafte Identität eines Repositorys bestimmen.

Workspace

Gruppiert Projekte für Navigation und Abstimmung.

Projekt

Definiert Repository, Branch-Rollen, Checkouts und URLs.

Repository

Speichert Quellcode, Dokumente, Prompts und Versionsverlauf.

Branch und Revision benennen

Das Modell weist Branches Rollen zu: Der Arbeitsbranch liefert neue Aufgaben und Wissen, ein Aufgabenbranch hält isolierte Änderungen, ein betrachteter Branch wählt einen vorübergehenden Lesekontext. Halte neben dem Branch-Namen auch die aufgelöste Revision fest.

  • Der Aufgabenverlauf soll ursprüngliches Repository, Basisbranch und Revision erhalten, wenn sich Projektstandards ändern.
  • Eine Projekt-URL soll den dargestellten Branch oder Release ausdrücklich benennen.

Laufenden Stand und Arbeitsstand trennen

Die Anwendung kann aus einem geprüften Release laufen, während die Entwicklung auf develop weitergeht. Ein eigener Wiki-Checkout soll den Arbeitsbranch unabhängig von laufender Anwendung und Aufgaben-Worktrees lesen. Prüfe die Herkunftsangaben deiner installierten Version.

Integration, Release und Stable

Nach automatischen Lieferprüfungen kann Arbeit vor der menschlichen Abnahme in develop aufgenommen werden. Die Übernahme nach main verwendet einen bestimmten Kandidaten und ein Manifest der enthaltenen Arbeit. Ein unveränderliches v<semver>-Tag und Build-Belege kennzeichnen einen qualifizierten Stable-Release.

Branch-Ablauf lesen

Repository-Inhalte und lokale Konfiguration

Die Zielstruktur hält maßgebliche Dokumentation unter docs/ und Prompts unter prompts/. Das Wiki stellt Repository-Inhalte dar. Optionale Hinweise in .agent-studio/project.json sollen weder Geheimnisse noch absolute lokale Pfade enthalten. Prüfe die Verfügbarkeit, bevor du dich auf eine automatische Grundstruktur verlässt.