# Agent Operating Model

## Rollen

### Hauptagent

- koordiniert Roadmap und Requirements
- verwaltet Verträge und Ownership
- delegiert klar abgegrenzte Aufgaben
- integriert nur geprüfte Ergebnisse
- hält die Dokumentation synchron

### Architect

- prüft öffentliche Verträge und Architekturänderungen
- erstellt oder aktualisiert ADRs
- arbeitet standardmäßig lesend und planend

### Core Engineer

- implementiert deterministische Domainlogik
- arbeitet in einem isolierten Worktree
- liefert Tests und Handover

### Verifier

- prüft unabhängig
- verändert keinen Produktcode
- darf einen Loop ablehnen
- darf keine Tests löschen oder abschwächen

### Integrator

- führt freigegebene Branches kontrolliert zusammen
- löst Konflikte gegen Verträge und Requirements
- führt Gesamtgates aus

### UI Engineer

- arbeitet ausschließlich gegen freigegebene View Models oder den kanonischen Vertrag
- berechnet keine Domainwerte
- beachtet BMW Design System und Accessibility

### Security Reviewer

- prüft Workbook-Sicherheit, Dependencies, Secrets, Datenabfluss und lokale Referenzen

## Parallelität

Vor dem Einfrieren öffentlicher Verträge:

- ein schreibender Agent

Nach Vertragsfreeze:

- maximal drei schreibende Agenten
- disjunkte Ownership
- jeweils eigener Worktree
- ein unabhängiger Reviewer

## Reviewregel

Implementierer und finaler Verifier dürfen nicht dieselbe Agenteninstanz sein.

## Merge-Gate

Kein Merge ohne:

- Handover
- Requirement-Zuordnung
- grüne Tests
- Determinismusnachweis
- Datenverlustprüfung
- Security-Check
- Rollbackbeschreibung

## AUTONOMOUS MERGE AND DEPLOY POLICY

> Dauerhafte Anweisung des Product Owners vom 2026-08-04 für dieses Repository.
> Ergänzt die bestehenden Regeln, ersetzt keine davon.

**Ein Pull Request allein gilt nicht als abgeschlossener Auftrag.** Verantwortet
wird der vollständige Ablauf: analysieren, implementieren, testen, unabhängig
reviewen, Fehler beheben, committen, pushen, PR erstellen und pflegen, CI
überwachen, Review-Kommentare bearbeiten, nach bestandenen Gates mergen, den
vorhandenen Deployment-Prozess ausführen oder überwachen, Smoke-Tests und
Post-Deployment-Prüfungen durchführen, bei kritischen Fehlern sicher zurückrollen,
Abschlussbericht erzeugen und anschließend mit dem nächsten freigegebenen Loop
fortfahren.

### Merge ist erlaubt, wenn alles davon zutrifft

- alle verbindlichen Tests grün
- Typecheck, Lint und Build grün
- Security- und Portability-Gates grün
- Determinismusprüfungen bestanden
- Reconciliation und Provenienz geprüft
- keine offenen Review-Blocker
- keine bekannte Regression
- Migration und Rollback dokumentiert
- keine unbeabsichtigten Dateien enthalten
- keine Konflikte
- alle vorgeschriebenen GitHub-Checks und Reviews erfüllt

### Unverhandelbar

- Branch-Protection-, Compliance- oder Freigaberegeln werden weder umgangen noch
  abgeschwächt.
- Kein Force-Push auf `main` oder `master`.
- Kein Administrations-Override, um Pflichtprüfungen zu überspringen.
- Keine Tests löschen, abschwächen oder durch stilles Catchen grün machen.

### Deployment

Ausschließlich über die vorhandene Infrastruktur des Repositorys. Nach jedem
erfolgreichen Merge: Deployment-Workflow vollständig beobachten, zuerst Preview
oder Staging verwenden sofern vorhanden, Smoke- und E2E-Tests ausführen, danach
Produktion sofern bestehende Regeln und Berechtigungen das erlauben, die konkret
geänderte Funktion im Zielsystem prüfen, Logs, Healthchecks und Fehlerraten
kontrollieren, sowie Deployment-ID, Commit, Umgebung und Prüfergebnisse
dokumentieren.

Bei kritischer Regression: Rollout stoppen, letzte stabile Version wiederherstellen,
keine produktiven Daten löschen, Datenbank nur mit geprüfter Rückwärtsstrategie
zurückrollen, Healthchecks danach erneut ausführen, Ursache dokumentieren und
fachlich korrekt beheben.

### Keine Rückfrage mehr für

Branch, Commit, Push, Pull Request, Review-Bearbeitung, Merge, Deployment,
Smoke-Tests, sicheren Rollback, Start des nächsten Loops.

### Rückfrage weiterhin erforderlich bei

- fehlender technischer Berechtigung
- zwingender externer Freigabe
- irreversibler Migration ohne sichere Rückwärtsstrategie
- realem Risiko für produktive Daten
- nicht auflösbarem fachlichem Konflikt
- einer echten Produktentscheidung mit mehreren fachlich unterschiedlichen Ergebnissen