---
description: "Projekte gruppieren zusammengehörige Aufgaben innerhalb eines Workspace. Hänge ein echtes Git-Repository an, um sichere, kontrollierte Code-Auslieferung…"
---

# Projekte & Git-Auslieferung

Projekte gruppieren zusammengehörige Aufgaben innerhalb eines Workspace. Hänge ein echtes Git-Repository an, um sichere, kontrollierte Code-Auslieferung zu ermöglichen.

![Projects Overview](/documentation/blume-assets/content/docs/img/screenshots/09-projects.png)

## Projekte

### Projekt erstellen

1. Seite **Projekte** → **Neues Projekt**
2. Name + Beschreibung
3. Speichern — das Projekt erscheint im Kartenraster

Jede Karte hat ein Menü mit **Bearbeiten** und **Löschen**.

![Project List](/documentation/blume-assets/content/docs/img/screenshots/09-projects.png)

### Projektdetails

Klicke auf ein Projekt, um die Detailseite zu öffnen:

![Project Detail](/documentation/blume-assets/content/docs/img/screenshots/10-project-detail-git-target.png)

Bereiche:
- **Kopfbereich** — Name, Beschreibung, Anzahl der Mitglieder
- **Git-Repository-Ziel** — Repository-Verbindung konfigurieren
- **Auslieferungen automatisch freigeben** — Opt-in pro Projekt
- **In den Standard-Branch mergen** — Opt-in pro Projekt
- **Ausstehende Auslieferungen** — Warten auf Prüfung
- **Auslieferungsverlauf** — Alle Auslieferungen (freigegeben/abgelehnt/fehlgeschlagen)

## Git-Repository-Ziel

Verbinde ein echtes Git-Repository, damit Agenten deine tatsächliche Codebasis auschecken.

### Konfiguration

| Feld | Beschreibung |
|-------|-------------|
| **Repository-URL** | HTTPS oder SSH (z. B. `https://github.com/org/repo.git`) |
| **Benutzername** | Optional — bei reiner Token-Authentifizierung leer lassen; erforderlich für Git-Server, die Benutzer + Passwort verlangen |
| **Zugangsdaten** | Token (wenn Benutzername leer) oder Passwort (wenn Benutzername gesetzt) |
| **Standard-Branch** | Ziel-Branch für Merges (z. B. `main`, `master`) |

### So funktioniert es

1. Aufgabe des Agenten läuft → der Daemon klont das Repository flach in das Arbeitsverzeichnis der Ausführung
2. Der Agent nimmt Änderungen vor → committet lokal
3. Nach Abschluss → der Daemon erfasst den Diff (`base_commit..HEAD`)
4. Der Diff wird als **ausstehende Auslieferung** hochgeladen → wartet auf menschliche Prüfung

**Sicherheit der Zugangsdaten**: Werden direkt nach dem Klonen aus dem Git-Remote entfernt; die lokale Commit-Identität ist der Benutzername des Git-Ziels oder allgemein „Agent Orchestrator“.

## Auslieferungs-Workflow

### Ausstehende Auslieferungen

Jede abgeschlossene Ausführung mit einem Git-Ziel erzeugt eine Auslieferung:

![Pending Delivery](/documentation/blume-assets/content/docs/img/screenshots/11-project-detail-review-dialog.png)

Der **Prüfdialog** zeigt:
- Vollständigen Unified Diff (alle Änderungen seit dem Basis-Commit)
- Hinzugefügte/geänderte/gelöschte Dateien
- Markierungen für Binärdateien

### Aktionen

| Aktion | Ergebnis |
|--------|--------|
| **Freigeben** | Pusht in einen neuen Branch `agenthub/task-<id>-run-<id>` (nie in den Standard-Branch) |
| **Ablehnen** | Nichts verlässt Agent Orchestrator |
| **Automatisch freigeben** | Wenn aktiviert, entfällt die Prüfung → gleicher Branch-Push |

### Auslieferungen automatisch freigeben

Opt-in pro Projekt (nur für Administratoren):

1. Projektdetails → Schalter **Auslieferungen automatisch freigeben**
2. Erst aktivierbar, wenn ein Git-Ziel konfiguriert ist
3. Jede automatisch freigegebene Auslieferung wird weiterhin im Audit-Log mit `autoApproved: true` protokolliert

### In den Standard-Branch mergen

Opt-in pro Projekt (nur für Administratoren):

1. Projektdetails → Schalter **Freigegebene Auslieferungen in den Standard-Branch mergen**
2. Wenn aktiviert, werden freigegebene Auslieferungen nach dem Push automatisch in den Standard-Branch gemergt
3. Merge-Konflikte → die Auslieferung wird mit `push_failed` und Fehlermeldung markiert; kein stilles Scheitern

### Auslieferungsverlauf

Vollständige Nachvollziehbarkeit jeder Auslieferung:

| Status | Bedeutung |
|--------|---------|
| `pending` | Wartet auf Prüfung |
| `pushed` | Freigegeben, in den Aufgaben-Branch gepusht |
| `rejected` | Von einem Menschen abgelehnt |
| `push_failed` | Git-Fehler (Konflikt, Berechtigungen usw.) |
| `merged` | Automatisch in den Standard-Branch gemergt |

Fehlgeschlagene Auslieferungen zeigen den Fehlergrund — nichts geht stillschweigend verloren.

## Aufgaben Projekten zuweisen

- **Aufgabe erstellen** — Projekt-Dropdown im Dialog „Neue Aufgabe“
- **Aufgabendetails** — Projekt-Chip → klicken zum Ändern
- **Aufgaben-Board** — Projektfilter-Dropdown

## Letzte Änderungen

- **Git-Repository-Ziel** — Echte Git-Repositories anhängen, Agenten checken die tatsächliche Codebasis aus
- **Auslieferungen automatisch freigeben** — Opt-in pro Projekt, um die menschliche Prüfung zu überspringen (wird weiterhin protokolliert)
- **In den Standard-Branch mergen** — Opt-in pro Projekt, um freigegebene Auslieferungen automatisch zu mergen
- **Auslieferungsverlauf** — Vollständige Nachvollziehbarkeit mit Fehlergründen