# TELEGRAM_MISSION_CONTROL — Kommunikations-Contract

> **Geltungsbereich:** Red Queen Autonomous Engineering System v1
> **Status:** Verbindlicher Kommunikations-Contract (Telegram)
> **Sprache:** Deutsch (verbindlich)

---

## 1. Grundsatz

Telegram dient als **kontrollierte, nicht-spamende** Kommunikationsbrücke zu Christian.
**Keine Mikro-Updates, kein Spam.** Meldungen werden nur bei **signifikanten** Ereignissen
versendet und folgen festen Standardformaten.

## 2. Standard-Meldungen

### 2.1 MISSION ACCEPTED
- **WHEN:** Eine Mission wurde von Red Queen angenommen und in PLANNING/CREATED gesetzt.
- **Inhalt:** Missionsname/-ID, Kurz-Klassifikation (SMALL/MEDIUM/…), erwartete Richtung.

### 2.2 CHECKPOINT
- **WHEN:** Nur bei **sinnvoller Phase** (z. B. Plan steht, kritischer Meilenstein, wichtige
  Etappe fertig, in REVIEW gegangen). **NICHT** bei jedem WP.
- **Inhalt:** Task/Phase, Status (z. B. Plan validiert, N kritische WP PASS, Testsumme).

### 2.3 BLOCKER
- **WHEN:** Ein WP/Mission ist `BLOCKED` oder `FAILED` (nach SAFETY-Kette).
- **Inhalt:** WAS blockt, TASK_ID, Fehler-Signatur, getroffene Maßnahmen, STOP-Status.

### 2.4 DECISION REQUIRED
- **WHEN:** Eine Entscheidung von Christian/Red Queen-Higher ist nötig (z. B. Human Decision,
  Konflikt, Scope-Frage).
- **Inhalt:** Klare Frage, Kontext, Optionen, Konsequenzen bei jeder Option.

### 2.5 APPROVAL REQUIRED
- **WHEN:** Ein Genehmigungs-Gate (SI-2/SI-3, Integration auf main, externer Zugriff) ist nötig.
- **Inhalt:** Was genehmigt werden soll, Scope, Risiko, wer antworten muss (Christian).

### 2.6 CRITICAL
- **WHEN:** Circuit Breaker geöffnet / kritischer Trigger (SAFETY_CONTRACT §5) / Prod-/Secret-/
  SSH-/Persistenz-Vorfall.
- **Inhalt:** CRITICAL-Status, Trigger, STOP + NO MUTATION bestätigt, Alarmhinweis.

### 2.7 MISSION COMPLETE
- **WHEN:** Mission vollständig (alle WP DONE, REVIEW abgeschlossen).
- **Inhalt:** MISSION-ID, Ergebnis-Zusammenfassung, Artefakte/Verweise, ggf. offene Punkte.

---

## 3. Anti-Spam- und Kopplungsregeln

| Regel | Umsetzung |
|-------|-----------|
| **Keine Micro-Updates** | Kein Meldung je kleinstem Schritt/Sekundär-Detail |
| **Kein Spam** | Keine Wiederholungen; Checkpoints nur bei sinnvoller Phase |
| **CHECKPOINT nur bei sinnvoller Phase** | Phase mit Mehrwert; nicht pro Zwischenschritt |
| **Batching** | Wenn mehrere Meldungen im selben Zeitfenster → zusammenfassen |
| **Dedupe** | identische/konsistente Status nicht erneut senden |
| **Priorität** | CRITICAL / DECISION / APPROVAL → sofort; CHECKPOINT → geordnet |

---

## 4. Autonomes Weiterarbeiten

Red Queen/Sub-Agenten arbeiten **autonom weiter**, wenn **alle** der folgenden Bedingungen
erfüllt sind:
1. **Mission eindeutig** (klarer Auftrag, keine offenen Scope-Fragen).
2. **Fortschritt** messbar (Progress im Ledger).
3. **Safety eingehalten** (keine überschrittenen Limits, kein offener Circuit Breaker).
4. **Keine Human Decision erforderlich** (kein DECISION/APPROVAL-Trigger).

Sobald eine dieser Bedingungen fehlt → **STOPP und Meldung** (DECISION/APPROVAL/BLOCKER/CRITICAL),
nicht blind weiterarbeiten.

## 5. Meldungs-Format

Jede Meldung nutzt einen festen Präfix, um maschinelle Auswertbarkeit zu gewährleisten:
```
[MISSION ACCEPTED] / [CHECKPOINT] / [BLOCKER] / [DECISION REQUIRED] /
[APPROVAL REQUIRED] / [CRITICAL] / [MISSION COMPLETE]
```
Danach folgen Pflichtfeld-Elemente (Task-ID, Status, Grund/Info) gemäß §2.

## 6. WHO / STOP
- **WHO:** Red Queen versendet Standardmeldungen; Sub-Agenten kommunizieren nicht selbständig
  nach außen, sondern über Red Queen.
- **WHERE:** Telegram-Status-Kanal.
- **STOP:** Bei CRITICAL → alle weiteren autonomen Aktionen stoppen; nur Meldung + warten.