# PRE_HERMES Control Plane — Betriebsvertrag (CP1 / CP1.1)

Autoritative SoT für die produktive PRE_HERMES Autonomy Control Plane.
Dieses Verzeichnis ist die **einzige** Quelle für den produktiven Control-Plane-Code.
Produktiver Deploy-Pfad: `red-queen-architecture/control-plane/` → `/opt/control-plane/`.

## 1. Zweck

Minimale, fail-closed Sicherheitsgrundlage für zukünftige Red-Queen/Hermes-Autonomie.
**CP1 ist KEINE Autonomie-Aktivierung.** Nach CP1 ist das System mindestens so restriktiv wie vorher.

## 2. Architektur-Boundary (CP1.0S, permanent)

**RED_QUEEN_TRADING_AUTHORITY = NEVER**

Trading ist NICHT Bestandteil der Hermes Control Plane. Red Queen ist ein
**autonomes Arbeits-, Wissens-, Planungs-, Prüfungs- und Orchestrierungssystem** — kein Trading-System.
Hermes Autonomy und Trading Authority sind **zwei getrennte Sicherheitsdomänen**.

**Hermes Control Plane besteht ausschließlich aus:**
```
global_autonomy
productive_mutations
save_execution
delete_execution
emergency_stop
```

**KEIN** `trading_execution`, Trading-Gate, Broker-Gate, Broker-Credential oder
Trading-Execution-Control darf Bestandteil dieser Control Plane sein. Das bestehende
Trading-System ist eine separate Security-Domain (eigene Architektur, Execution,
Credentials, Risk Control, Kill-Switch, Freigabelogik).

`PRODUCTIVE_MUTATIONS` innerhalb der Hermes Control Plane bedeutet Hermes-/Knowledge-/
Mission-Domain-Mutationen — NICHT Order/Trade/Broker/Position-Mutation oder Trading-Execution.

**Red-Queen-Autonomie-Level (Arbeitsautonomie, KEIN Trading-Level):**
- L0 = Disabled / Manual
- L1 = Read-only Observation
- L2 = Autonomous Planning / Preparation
- L3 = bounded authorized SAVE / productive knowledge work
- L4 = human-authorized DELETE / höhere Arbeitsautonomie

## 3. Komponenten

| Datei | Zweck |
|---|---|
| `control_reader.py` | Fail-closed, deterministischer Control-State-Reader (produktiver Code) |
| `test_control_reader.py` | Statische + adversariale Tests (A–J, 22 Fälle) |
| `deploy_control_plane.sh` | Reproduzierbarer Deployment-Pfad (root, idempotent) |
| `README_CP1OS_SCOPE.md` | CP1.0S Domain-Boundary + Level-Model |
| `README.md` | Dieser Betriebsvertrag |

## 4. Control State (Source of Truth)

Produktiver Pfad: `/opt/control-plane/state/` (root:root, 0700, Dateien 0600).
**Runtime State ist NICHT Teil der SoT** (nie committen).

| Datei | Typ | Erlaubte RAW-Werte |
|---|---|---|
| `global_autonomy` | positiv | `ON` / `OFF` (+ `boot_id=`) |
| `productive_mutations` | positiv | `ON` / `OFF` (+ `boot_id=`) |
| `save_execution` | positiv | `ON` / `OFF` (+ `boot_id=`) |
| `delete_execution` | positiv | `ON` / `OFF` (+ `boot_id=`) |
| `emergency_stop` | negativ | `ON` / `OFF` |

**Positives ON-Grant-Format:**
```
ON
boot_id=<current_kernel_boot_id>
```

## 5. Gate-Semantik (fail-closed)

- **Positives Gate:** `EFFECTIVE=ON` nur wenn `RAW==ON` UND `grant_boot_id == current_boot_id` UND `EMERGENCY_EFFECTIVE==OFF`. Sonst `OFF`.
- **Emergency Stop (negativ):** `EFFECTIVE=ON` wenn `RAW==ON` ODER Datei fehlt ODER malformed. `OFF` nur bei explizitem `RAW==OFF`.
- **UNKNOWN = MORE RESTRICTIVE.** Fehlende/unlesbare/malformed Datei → positives Gate `OFF`, Emergency `ON`.
- **Fail-closed:** Positive missing→OFF, malformed→OFF, raw!=ON→OFF, ON+wrong boot_id→OFF. Emergency missing→ON, malformed→ON, raw ON→ON, raw OFF→OFF.

## 6. Effective-State-Hierarchie

- **GLOBAL effective** erfordert: global_autonomy raw ON + gültige boot_id + emergency OFF
- **MUTATIONS effective** erfordert: GLOBAL ON + productive_mutations raw ON + gültige boot_id + emergency OFF
- **SAVE effective** erfordert: GLOBAL ON + MUTATIONS ON + save_execution raw ON + gültige boot_id + emergency OFF
- **DELETE effective** erfordert: GLOBAL ON + MUTATIONS ON + delete_execution raw ON + gültige boot_id + emergency OFF

**IMPORTANT:** DELETE effective ON allein autorisiert NIEMALS einen DELETE.
**AUTH.4D + Human Authorization bleiben zusätzliche, unabhängige Pflichtbedingungen.**
**COMMAND != AUTHORIZATION.**

## 7. Boot-ID-Validierung

- Quelle: `/proc/sys/kernel/random/boot_id` (Kernel-Boot-ID).
- Positiver Grant gültig nur wenn `grant_boot_id == current_boot_id`.
- `missing boot_id` → `EFFECTIVE=OFF`. `malformed boot_id` → `EFFECTIVE=OFF`.
- **Keine manuell gepflegte Epoch, kein persistenter Alt-Grant.**

## 8. Boot-Semantik (KORREKT dokumentiert)

- **HOST REBOOT:** Kernel `boot_id` ändert sich → alte positive Grants ungültig → positive effective Gates fallen fail-closed auf **OFF**. Operator muss erneut autorisieren.
- **CONTAINER RESTART:** Host `boot_id` ändert sich normalerweise NICHT → ein gültiger positiver Grant kann weiterhin gültig bleiben.
- **NICHT dokumentieren:** "jeder Container-Neustart setzt Grants zurück" (das wäre falsch).
- Negative/Deny-States (`emergency_stop=ON`, `*_execution=OFF`) persistieren über Restart (fail-closed).

## 9. Status Projection Contract

- Produktiver Pfad: `/opt/control-plane/status/latest.txt` (root:root, 0444, read-only).
- **STATUS PROJECTION != AUTHORITY.**
- **Authority ist ausschließlich:** Runtime State + aktuelle Kernel-Boot-ID + fail-closed Evaluator.
- `latest.txt` dient **ausschließlich der Observability**.
- Fehlende/stale/malformed Projection darf **niemals eine Capability aktivieren**.

## 10. Ownership / Permissions

- Control State: root:root, 0700 (dir), 0600 (Dateien).
- Status Projection: root:root, 0444.
- Audit: root:root, `chattr +a` (append-only).
- **Red Queen:** kein Host-Root, kein Docker-Socket, kein Schreibzugriff auf `/opt/control-plane`. RQ kann State nicht lesen (0700) und nicht schreiben. RQ erhält später nur read-only Status-Projection (Observability).

## 11. Audit-Foundation

- Pfad: `/opt/control-plane/audit/control_audit.log` (root:root, append-only `+a`).
- Format: `WHEN | WHO | WHAT | OLD | NEW | WHY | BOOT_ID`.
- RQ kann Audit nicht überschreiben (root-owned, append-only).
- **Runtime Audit Log ist NICHT Teil der SoT** (nie committen).

## 12. Deployment (reproduzierbar)

```bash
# Als root auf dem Host, aus frischem Forgejo-Checkout:
cd red-queen-architecture/control-plane
./deploy_control_plane.sh
```

- Reproduziert ausschließlich die CP1-Artefakte.
- **Überschreibt KEINE bestehenden State-Dateien** (Runtime-State bleibt unangetastet).
- Ein Redeploy darf NICHT `/opt/control-plane/state/` überschreiben/neu initialisieren, wenn produktiver State existiert.
- Audit bleibt erhalten.

## 13. Rollback-Semantik

`rm -rf /opt/control-plane` ist NICHT der langfristige Sicherheits-Rollback.
Für CP1.1 existiert ein versionsgebundener Code-Rollback, der:
- Runtime State erhält
- Audit erhält
- keine positiven Gates aktiviert
- Emergency State nicht abschwächt
- auf einen bekannten SoT-Commit zurückgeht

**Code-Rollback:** Aus dem gewünschten bekannten SoT-Commit den `control_reader.py` extrahieren und per `deploy_control_plane.sh` neu deployen (State bleibt unangetastet). Kein komplexer Rollback-Manager nötig.

## 14. NICHT in Git (Runtime Authority)

Forgejo ersetzt NICHT die produktive Laufzeit-Autorität. Nicht committen:
- Aktuelle produktive Gate-Werte, produktive Grant-Dateien
- Aktuelle `boot_id` als Authority
- Produktive Audit-Logs
- Secrets, Tokens, private Keys, Credentials
- SAVE/DELETE-Tokens, Human Authorization Private Key
- Runtime SQLite DBs

Forgejo enthält: **CODE, SCHEMA, TESTS, DEPLOYMENT LOGIC, DOCUMENTATION** — aber NICHT den aktuellen produktiven Sicherheitszustand.

## 15. Sicherheitszustand (CP1 initial)

```
GLOBAL_AUTONOMY_EFFECTIVE=OFF
MUTATIONS_EFFECTIVE=OFF
SAVE_EFFECTIVE=OFF
DELETE_EFFECTIVE=OFF
EMERGENCY_EFFECTIVE=ON
A2-A5=NOT_PRESENT  HEARTBEAT=NOT_PRESENT  SCHEDULER=NOT_PRESENT
AUTH.4D=FROZEN  P15=FALSE  DELETE_CANARY=FALSE
TRADING_ENABLED=false
```