# Playbook: Der Driver

Das Playbook für Menschen, die wollen, dass die Suite von selbst weitermacht. `/continuous-refactoring` ist der **Driver**: Er arbeitet eine **Runde** nach der anderen ab, mit einem **Rhythmus** dazwischen, bis zu einem Ende. Gefragt wirst du nur, wo die Entscheidung bei dir liegt.

Eine Runde ist ein Run, das Review seines Merge Requests und eventuell Nacharbeit:

```
Projekt prüfen → ein Run in einem Subagenten → seinen Merge Request prüfen → erledigt, oder Nacharbeit → den Rhythmus abwarten → nächste Runde
```

## Der Aufruf

Er startet, ohne zu fragen, und sagt in einem Satz zurück, was er verstanden hat. Alles hat einen Standard; sag es in eigenen Worten anders.

| Einstellung | Standard | Du kannst sagen |
|---|---|---|
| Merge | `nur Review`: er kommentiert, und du mergst | `mergen` |
| Ende | fünf Runden | eine Anzahl Runden, gemergter Merge Requests, eine Uhrzeit, „bis nichts mehr bearbeitbar ist“ |
| Rhythmus | 30 Minuten zwischen den Runden | eine andere Dauer, „keine Pause“ |
| Aufruf | keiner: Jeder Run trifft seine eigene Track-Wahl, Investigation eingeschlossen | ein Track („Guardrails“), eine Einschränkung („nur die Rector-Tools“) |
| Log | keins | eine Datei, die dein Repository ignoriert, eine Zeile pro Runde. Das Log ist für dich; der Driver liest seinen Zustand aus dem Tracker |

Für einen einzelnen Run, ein genanntes Ticket oder [ein eigenes Pack](https://continuous-refactoring.de/de/docs/own-tool.md) rufst du [`/continuous-refactoring-run`](https://continuous-refactoring.de/de/docs/run.md) auf. Bekommt der Driver eines davon, gibt er es weiter.

## Was eine Runde tut

- **Jeder Run beginnt frisch.** Ein Run in einem Subagenten hat einen eigenen Kontext, also liest der hundertste Run den Tracker so klar wie der erste. Er ist immer autonom, und die Regeln deiner `AGENTS.md` gehen mit.
- **Er nennt ein Ticket, um mit ihm weiterzumachen:** um einen Merge Request zu überarbeiten, an dem er oder du Änderungen angefordert hast, für den nächsten Teil eines Tickets, das in mehreren Merge Requests bearbeitet wird, für eine Frage, die du beantwortet hast, oder wenn du darum bittest. Er nennt nie ein Ticket, das wartet oder blockiert ist: Es zu nennen, hieße, es unabhängig von seinem Zustand zu bearbeiten.
- **Er prüft jeden Merge Request in einem eigenen Subagenten**, mit dem Review-Skill deines Projekts, wo es einen gibt, sonst so, wie es ein engagierter menschlicher Reviewer täte: im Umfang seines Tickets, Verhalten erhalten, Checks grün, die Beschreibung sagt, warum die Änderung sicher ist.
- **Nacharbeit bleibt in der Runde.** Eine Bitte um Änderungen wird am Merge Request gepostet, und ein Run beantwortet sie sofort, ohne Rhythmus dazwischen. Nach zwei Nacharbeiten ohne mergebares Ergebnis geht der Merge Request an dich. Eine Runde enthält bis zu drei Runs und zählt als eine.
- **Mit `mergen`** wartet er auf grüne CI und nutzt die Merge-Methode deines Repositorys. Vor dem Löschen des Branchs prüft er, ob ein Merge Request darauf gestapelt ist, und dass der Merge den Inhalt des Branchs wirklich übernommen hat. Wenn nicht, hält er an: Die Korrektur ist ein gewöhnlicher Merge Request, nie ein Umschreiben der Historie.

## Der Rhythmus

Er wird vom Ende der vorigen Runde an gezählt. Der Driver wartet in seiner Sitzung, wo deine Umgebung einen Timer hat. Sonst endet er und sagt, wann die nächste Runde fällig ist, und der nächste Aufruf arbeitet die nächste Runde ab. Ein kurzer Rhythmus ist alles, was eine Sitzung hält; einen längeren, etwa einmal am Tag, richtest du mit deinem eigenen Scheduler ein. Siehe [bekannte Einschränkungen](https://github.com/Art4/continuous-refactoring/blob/0.11.0/docs/playbooks/known-limitations.md).

## Wo du ins Spiel kommst

Der Driver beantwortet nie selbst eine offene Frage, und er macht mit dem nächsten Ticket weiter, während eines auf dich wartet.

| Was auf dich wartet | Wo es steht | Was du tust |
|---|---|---|
| Eine Frage, die beim Planen aufkam | ein `Open question`-Kommentar am Ticket, vom Run gepostet | auf dem Ticket antworten; der Driver nennt es, sobald du geantwortet hast |
| Eine Frage, die der Driver zu einem Merge Request hat | ein Kommentar am Merge Request | dort antworten und erneut aufrufen |
| Ein Merge Request, der zweimal überarbeitet wurde, ohne zu bestehen | ein Kommentar am Merge Request | wie oben |
| Ein mergebarer Merge Request, bei `nur Review` | ein Kommentar am Merge Request | mergen, oder dort Änderungen anfordern: Die nächste Runde überarbeitet ihn |
| Eine Änderung, die ein Run in deiner `AGENTS.md` will | die Nachricht des Drivers, mit dem Wortlaut | selbst vornehmen, oder nicht |

Er sagt dir von jedem davon Bescheid, sobald es passiert, über die Benachrichtigung, die deine Umgebung hat, und schreibt nach jeder Runde eine Statuszeile. Kommentare an wartenden Tickets lässt er in Ruhe: Jeder Kommentar dort würde als deine Antwort zählen.

## Wann er endet

- **Fertig:** Ein Run findet nichts Bearbeitbares, und nichts wartet.
- **Pausiert:** Ein Run findet nichts Bearbeitbares, aber Tickets warten, sind im Review oder blockiert; oder, bei `nur Review`, sind mehr als drei Merge Requests offen. Er listet auf, was jedes braucht. Ruf erneut auf, sobald du dich darum gekümmert hast.
- **Etwas ist kaputtgegangen:** Ein Run ist fehlgeschlagen, das Arbeitsverzeichnis ist nach einem Run nicht sauber, ein Merge ist nicht gelandet, oder zwei Runs in Folge endeten ohne Merge Request und ohne neues wartendes Ticket.
- **Dein Ende:** standardmäßig die fünfte Runde.

## Wer ihn startet

Du oder ein Zeitplan, mit seinem Namen. Ein Agent, der Refactoring erledigt haben will, ruft `/continuous-refactoring-run` auf; ein Driver, der in einem Subagenten gestartet wird, bricht ab und sagt das.

## Der erste Aufruf

Auf einem Projekt ohne Abschnitt `## Refactoring operations` stellt dir das Onboarding Fragen, und ein Run in einem Subagenten kann niemanden fragen. Also führt der erste Aufruf das Onboarding direkt in deiner Sitzung aus und hält dann an: Committe, was es geschrieben hat, und ruf erneut auf.