operator v1.0.0A

Immutable. This exact content is served forever at /api/v1/blob/920d76f46a60a60f.

---
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
visibility: public
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.