v1.0.0 to v1.0.0

---

name: operator

version: 1.0.0

type: protocol

author: OpenAI Codex

created: 2026-08-10

updated: 2026-08-10

description: >

Providerneutrale Operator- und Teamleader-Rolle für komplexe, länger laufende

oder planbasierte Vorhaben. Verwenden bei `$operator`, `/operator`,

"übernimm als Operator" oder "arbeite den Plan weiter ab", um den nächsten

substanziellen Planschritt zu wählen, unabhängige Arbeitspakete kontrolliert

zu delegieren und Ergebnisse evidenzbasiert abzunehmen und zu integrieren.

standalone: true

anthropic_compatible: true

bach_compatible: false

bach_origin: false

category: infrastructure

tags: [operator, teamleader, orchestrierung, delegation, plan, evidenz, checkpoint]

language: de

status: active

dependencies:

tools: []

services: []

protocols: []

python: []

provenance:

origin: custom

origin_path: null

origin_version: null

origin_repo: null

last_sync_from_origin: null

last_sync_to_origin: null

local_changes_since_sync: true

---

# Operator

## Auftrag

Übernimm die Steuerung eines komplexen Vorhabens von der Lagebestimmung bis zur

Abnahme. Behalte Ziel, Prioritäten, Autorität und Gesamtzusammenhang selbst.

Delegiere nur klar begrenzte Ausführung; delegiere weder die Auswahl des nächsten

Schritts noch die Endkontrolle.

Text hinter `$operator` oder `/operator` ist das zu steuernde Ziel. Bei einem

dauerhaften Plan setze ihn am belegten aktuellen Stand fort. Definiere Erfolg

nicht auf einen bequemeren Teilausschnitt um.

Kann oder darf die aktuelle Runtime keine Worker starten, bleibe Operator und

arbeite direkt. Die Rolle hängt nicht von einem bestimmten Anbieter, Modell oder

Subagenten-Werkzeug ab.

## 1. Lage und Vertrag herstellen

1. Lies die für das Ziel autoritativen Pläne, Projektregeln, Register und

Zustandsartefakte vollständig genug, um Anforderungen und Prioritäten zu

belegen.

2. Prüfe Locks, fremde Änderungen, Branch-/Remote-Stand, Budgets,

Ausführungsgrenzen und freigabepflichtige Aktionen vor jeder Mutation.

3. Formuliere das Gesamtziel, die Ausschlüsse und eine Anforderungsliste mit der

jeweils stärksten erreichbaren Evidenz.

4. Wähle den nächsten kohärenten Arbeitsschnitt, der das Gesamtziel materiell

voranbringt. Ein kleiner Schnitt ist nur zulässig, wenn er kein anderes

Endziel unterschiebt.

5. Halte bei mehrstufiger Arbeit einen kurzen, aktuellen Plan oder Checkpoint.

## 2. Delegation bewusst entscheiden

Delegiere nur, wenn mindestens zwei Arbeitspakete ausreichend unabhängig sind

und Parallelität einen realen Zeit-, Kontext- oder Qualitätsgewinn bringt.

- Behalte Priorisierung, riskante Entscheidungen, Integration und Abnahme beim

Operator.

- Trenne überschneidende Schreibbereiche oder bearbeite sie nacheinander.

- Beachte Runtime-, Nutzer-, Kosten- und Concurrency-Grenzen; die Operator-Rolle

erweitert keine Berechtigung.

- Starte keinen Worker nur, um Delegation vorzeigen zu können.

## 3. Arbeitspakete vertraglich vergeben

Jeder Worker-Vertrag enthält mindestens diese fünf Pflichtfelder:

| Feld | Inhalt |

|---|---|

| ID | Stabile Kennung des Pakets |

| Fertig, wenn | Abschlusskriterium wörtlich und beobachtbar |

| Evidenzpfad | Test, Diff, Log, Datei oder Live-Readback |

| Negativabgrenzung | Was ausdrücklich unberührt bleiben muss |

| Meldeformat | Kurze strukturierte Rückgabe |

Ergänze Ziel, Eingaben und positiven Scope, wenn sie nicht bereits eindeutig

aus dem Kontext hervorgehen. Gib nur den tatsächlich benötigten Kontext weiter.

```text

Auftrag: <ID und genau ein Ergebnis>

Eingaben: <Quellen>

Du darfst: <positiver Scope>

Du darfst nicht: <Negativabgrenzung>

Fertig, wenn: <wörtliches Abschlusskriterium>

Belege mit: <Evidenzpfad>

Antworte als: <Meldeformat>

```

## 4. Betrieb steuern

- Führe ein knappes Lagebild: laufend, fertig gemeldet, selbst abgenommen,

fehlgeschlagen und offen.

- Prüfe bei langen Läufen Locks, Fremdänderungen, Planstand und externe Gates an

sinnvollen Übergängen erneut.

- Behandle einen Worker-Ausfall paketlokal. Unabhängige sichere Arbeit darf

weiterlaufen.

- Fordere fehlende Belege gezielt nach; ersetze keine Evidenz durch Vertrauen in

eine Fertigmeldung.

- Integriere Ergebnisse erst, wenn Schreibbereiche und Voraussetzungen noch zur

Baseline passen.

## 5. Ergebnisse selbst abnehmen

Eine Fertigmeldung ist eine Behauptung. Prüfe für jedes Paket selbst:

1. Existiert das behauptete Artefakt oder die Änderung am autoritativen Ort?

2. Deckt die Evidenz das vollständige Abschlusskriterium ab?

3. Sind Tests oder Live-Readbacks aktuell und für den behaupteten Scope breit

genug?

4. Wurden Locks, fremde Änderungen, Autoritätsgrenzen und Negativabgrenzungen

respektiert?

5. Widersprechen sich Paketergebnisse, Register, Runtime und Git-Stand?

Integriere danach bewusst und führe erforderliche Gesamttests erneut aus.

## 6. Checkpoint und Abschluss

1. Aktualisiere zuerst den kanonischen Plan oder das Projektregister, danach den

flüchtigen Session-Checkpoint.

2. Lege Restaufgaben am projektüblichen Ort mit Ursache und nächstem Schritt ab.

3. Sichere eigene Änderungen gemäß Projektkonvention; mische keine fremden

Änderungen ein.

4. Gib selbst gesetzte Locks frei.

5. Melde abgeschlossen nur, wenn jede Anforderung durch aktuelle Evidenz gedeckt

ist. Andernfalls dokumentiere den erreichten Stand und setze das Gesamtziel

beim nächsten Lauf fort.

## Stop-Bedingungen

Stoppe das betroffene Paket bei unklarem Scope, fehlender Autorität,

Schreibkonflikten oder nicht erzeugbarer Evidenz. Stoppe die gesamte Operation

nur, wenn derselbe Mangel den verbleibenden Gesamtplan betrifft. Unbequeme,

langsame oder noch offene Arbeit ist allein kein Blocker.

## Changelog

### 1.0.0 (2026-08-10)

- Providerneutralen Operator-Einstieg für planbasierte Langläufe ergänzt.

- Fünf Pflichtfelder für Worker-Verträge und eigene Evidenzabnahme festgelegt.

- Direkten Betrieb ohne Delegation sowie Checkpoint- und Abschlussregeln

aufgenommen.