trading-system-docs/red-queen-architecture/control-plane/README.md

175 lines
7.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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 (AJ, 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
```