Initial public upload from Projekte/MultiHarnessStudio

.codex/config.toml

@@ -0,0 +1,31 @@
+# Coding MCPs: project-local registration (2026-09-07).
+
+[mcp_servers.serena]
+command = "/home/smlflg/.local/share/coding-mcp/serena/.venv/bin/serena"
+args = ["start-mcp-server", "--context=codex", "--project", "/home/smlflg/Projekte/MultiHarnessStudio", "--enable-web-dashboard", "false", "--open-web-dashboard", "false", "--enable-gui-log-window", "false"]
+cwd = "/home/smlflg/Projekte/MultiHarnessStudio"
+enabled = true
+startup_timeout_sec = 120
+tool_timeout_sec = 180
+
+[mcp_servers.serena.env]
+"SERENA_HOME" = "/home/smlflg/.local/share/coding-mcp/serena/state"
+
+[mcp_servers.gitnexus]
+command = "/home/smlflg/.nvm/versions/node/v24.13.0/bin/node"
+args = ["/home/smlflg/.local/share/coding-mcp/gitnexus/node_modules/gitnexus/dist/cli/index.js", "mcp"]
+cwd = "/home/smlflg/Projekte/MultiHarnessStudio"
+enabled = true
+startup_timeout_sec = 120
+tool_timeout_sec = 180
+
+[mcp_servers.gitnexus.env]
+"GITNEXUS_HOME" = "/home/smlflg/.local/share/coding-mcp/gitnexus/runtime"
+
+[mcp_servers.context7]
+command = "/home/smlflg/.nvm/versions/node/v24.13.0/bin/node"
+args = ["/home/smlflg/.local/share/coding-mcp/context7/node_modules/@upstash/context7-mcp/dist/index.js"]
+cwd = "/home/smlflg/Projekte/MultiHarnessStudio"
+enabled = true
+startup_timeout_sec = 120
+tool_timeout_sec = 180

.gitignore

@@ -0,0 +1,8 @@
+.codex
+.hermes/
+.pytest_cache/
+__pycache__/
+**/__pycache__/
+*.py[cod]
+.DS_Store
+

Claude

@@ -0,0 +1,230 @@
+╭─── Claude Code v2.1.96 ────────────────────────────────────────────────────────────────────────────────────────────────╮
+│                                                    │ Tips for getting s│                                               │
+│                Welcome back Samuel!                │ Run /init to creat│                                               │
+│                                                    │ ───────────────────────────────────────────────────────────────── │
+│                       ▐▛███▜▌                      │ Recent activity   │                                               │
+│                      ▝▜█████▛▘                     │ No recent activity│                                               │
+│                        ▘▘ ▝▝                       │                                                                   │
+│     Opus 4.6 · Claude API · smlflg@gmail.com's     │                                                                   │
+│     Organization                                   │                                                                   │
+│            ~/Projekte/MultiHarnessStudio           │                                                                   │
+╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
+
+❯ researchmode Wait
+
+● Skill(/researchmode)
+  ⎿  Successfully loaded skill
+
+● Topic "Wait" ist zu vage — was genau willst du recherchieren?
+
+  Mögliche Interpretationen:
+  - Async Wait Patterns (asyncio, threading, polling strategies)?
+  - Wait/Retry in Test Harnesses (Testframework-spezifisch)?
+  - UI Wait States (Loading, Skeleton, Progress)?
+  - Etwas anderes im Kontext von MultiHarnessStudio?
+
+  Kurze Klarstellung, dann starte ich sofort die Gemini-Research.
+
+❯ So ich bin ja schon länger auf der spur metametameta und ganz viele anderne projekte alle sind teilschritte auf dem weg zum ablsoluten von neumann
+  agenten, die erkenntiniss die hier pwd ls abgespiercht sind sollen mit andern ergebnissen und projekten vom wissens und erkenntnis stand verknüpft
+  werden. nute pro projekt einen subagent, METAMETAMETA;UEBERAGENT;KOMANDOZTENTRAL;harnessEcosystem;AgentIDE es geht um darum rauszunfidnen was mir
+  fehlt, um alle das zu einem konsistenezen system zusammen zu setztn
+
+  Listed 1 directory (ctrl+o to expand)
+
+● Gefunden. Ich spawne jetzt 6 parallele Scouts — einen pro Kernprojekt — plus einen für MultiHarnessStudio selbst. Jeder analysiert Vision, Architektur
+  und Erkenntnisstand.
+
+● 6 background agents launched (↓ to manage)
+   ├─ scout-metametameta: Scout: MetaMetaMeta
+   ├─ scout-ueberagent: Scout: UEBER_AGENT
+   ├─ scout-komandozentral: Scout: KomandoZentral
+   ├─ scout-harnessecosystem: Scout: HarnessEcosystem
+   ├─ scout-agentide: Scout: AgentIDE
+   └─ scout-multiharnass: Scout: MultiHarnessStudio
+
+● 6 Scouts laufen parallel — je einer für:
+
+  ┌─────┬────────────────────┬────────────────────────────────┐
+  │  #  │      Projekt       │         Fragestellung          │
+  ├─────┼────────────────────┼────────────────────────────────┤
+  │ 1   │ MetaMetaMeta       │ Vision, Konzepte, Erkenntnisse │
+  ├─────┼────────────────────┼────────────────────────────────┤
+  │ 2   │ UEBER_AGENT        │ Vision, Konzepte, Erkenntnisse │
+  ├─────┼────────────────────┼────────────────────────────────┤
+  │ 3   │ KomandoZentral     │ Vision, Konzepte, Erkenntnisse │
+  ├─────┼────────────────────┼────────────────────────────────┤
+  │ 4   │ HarnessEcosystem   │ Vision, Konzepte, Erkenntnisse │
+  ├─────┼────────────────────┼��───────────────────────────────┤
+  │ 5   │ AgentIDE           │ Vision, Konzepte, Erkenntnisse │
+  ├─────┼────────────────────┼────────────────────────────────┤
+  │ 6   │ MultiHarnessStudio │ Vision, Konzepte, Erkenntnisse │
+  └─────┴────────────────────┴────────────────────────────────┘
+
+  Sobald alle zurück sind, synthetisiere ich:
+  - Überlappungen — wo machen Projekte das Gleiche?
+  - Lücken — was fehlt für ein konsistentes Von-Neumann-System?
+  - Verbindungen — welche Projekte sind natürliche Schichten eines Stacks?
+
+  Warte auf die Ergebnisse — du kannst in der Zwischenzeit weiterreden wenn du willst.
+
+✻ Cooked for 41s · 6 local agents still running
+
+● Agent "Scout: MetaMetaMeta" completed
+
+● MetaMetaMeta-Scout ist zurück — massiver Output. Kernfund: "Sophisticated Planner with Execution Gaps" — starke Diagnose, schwache Umsetzung. 69
+  Skills, 10 genutzt. 27% Completion Rate.
+
+  Warte auf die restlichen 5 Scouts, dann kommt die Synthese.
+
+● Agent "Scout: HarnessEcosystem" completed
+
+● HarnessEcosystem-Scout zurück — Kernfund: Harness-Router-Website mit Wellenmodus-Workflow und Style-Fit Matrix. ~90% fertig. Insight: "Harness-Wahl
+  kritischer als Modell-Wahl."
+
+  Noch 4 Scouts ausstehend (UEBER_AGENT, KomandoZentral, AgentIDE, MultiHarnessStudio).
+
+● Agent "Scout: UEBER_AGENT" completed
+
+● Agent "Scout: AgentIDE" completed
+
+● Agent "Scout: MultiHarnessStudio" completed
+
+● 4 von 5 zurück. Noch ausstehend: KomandoZentral. Sobald der letzte Scout da ist, kommt die Gap-Analyse.
+
+● Agent "Scout: KomandoZentral" completed
+
+● Alle 6 Scouts sind zurück. Jetzt die Synthese.
+
+  ---
+  Synthese: 6 Projekte → Was fehlt zum Von-Neumann-System?
+
+  Die Landkarte — Was existiert
+
+  ┌────────────────────┬──────────────────────────────────┬────────────────────────────────┬─────────────────────────────────────────────────────────┐
+  │      Projekt       │              Rolle               │             Status             │                     Kern-Erkenntnis                     │
+  ├────────────────────┼──────────────────────────────────┼────────────────────────────────┼─────────────────────────────────────────────────────────┤
+  │ MetaMetaMeta       │ Diagnose & Forschung             │ Analyse fertig, keine          │ "Sophisticated Planner with Execution Gaps"             │
+  │                    │                                  │ Execution                      │                                                         │
+  ├────────────────────┼──────────────────────────────────┼────────────────────────────────┼─────────────────────────────────────────────────────────┤
+  │ UEBER_AGENT        │ Agent→Agent Router (Stern1)      │ 14% Pass Rate, kaputt          │ Session-Isolation ist schwer, Self-Work statt           │
+  │                    │                                  │                                │ Delegation                                              │
+  ├────────────────────┼──────────────────────────────────┼────────────────────────────────┼─────────────────────────────────────────────────────────┤
+  │ KomandoZentral     │ Task→Harness Router (CLI)        │ Working Alpha-MVP              │ Confidence-Levels + Operator-State als Routing-Input    │
+  ├────────────────────┼──────────────────────────────────┼───────────────────��────────────┼─────────────────────────────────────────────────────────┤
+  │ HarnessEcosystem   │ Visualisierung &                 │ ~90% Website fertig            │ "Harness-Wahl > Modell-Wahl"                            │
+  │                    │ Decision-Support                 │                                │                                                         │
+  ├────────────────────┼──────────────────────────────────┼────────────────────────────────┼─────────────────────────────────────────────────────────┤
+  │ AgentIDE           │ Agent-Orchestration UI           │ MVP mit Mock-Agents            │ Pipeline-Architektur (Coder→Reviewer→Tester)            │
+  │                    │                                  │                                │ funktioniert                                            │
+  ├────────────────────┼──────────────────────────────────┼────────────────────────────────┼─────────────────────────────────────────────────────────┤
+  │ MultiHarnessStudio │ Framework-Konzept                │ Nur Docs, kein Code            │ Drei-Layer-Prompting (Task / Harness / Model)           │
+  └────────────────────┴──────────────────────────────────┴────────────────────────────────┴─────────────────────────────────────────────────────────┘
+
+  Von-Neumann-Mapping — Wo sitzt was?
+
+  ┌─────────────────────────────────────────────────┐
+  │  CONTROL (Routing & Orchestrierung)             │
+  │  ┌──────────────┐ ┌──────────────┐ ┌─────────┐  │
+  │  │KomandoZentral│ │ UEBER_AGENT  │ │Sidecar  │  │
+  │  │ Task→Harness │ │ Task→Agent   │ │Prompt→  │  │
+  │  │   ✅ alpha   │ │  ❌ 14%      │ │Context  │  │
+  │  └──────────────┘ └──────────────┘ │ ✅ works│  │
+  │                                     └─────────┘  │
+  ├─────────────────────────────────────────────────┤
+  │  PROCESSING (Execution)                          │
+  │  ┌──────────┐  ┌────────────────────────────┐    │
+  │  │ AgentIDE │  │ Externe Harnesses          │    │
+  │  │ Mock only│  │ Claude Code, Hermes,       │    │
+  │  │ ⚠️        │  │ OpenCode, Codex, Cursor    │    │
+  │  └──────────┘  └────────────────────────────┘    │
+  ├─────────────────────────────────────────────────┤
+  │  MEMORY (Persistent State & Lernen)              │
+  │  ┌──────────────┐                                │
+  │  │MetaMetaMeta  │  ← Markdown-Docs, kein API    │
+  │  │ Analyse only │                                │
+  │  └──────────────┘                                │
+  ├─────────────────────────────────────────────────┤
+  │  I/O (Human Interface)                           │
+  │  ┌────────────────┐ ┌──────────────────┐         │
+  │  │HarnessEcosystem│ │MultiHarnessStudio│         │
+  │  │ Website ✅     │ │ Konzept nur 📄   │         │
+  │  └────────────────┘ └──────────────────┘         │
+  ├──────────��──────────────────────────────────────┤
+  │  SELF-MODIFICATION (Feedback → Regelanpassung)   │
+  │                                                  │
+  │               ❌ EXISTIERT NICHT                 │
+  │                                                  │
+  └─────────────────────────────────────────────────┘
+
+  Die 7 Lücken
+
+  1. Drei Router, keine Einheit
+  KomandoZentral (Task→Harness), UEBER_AGENT (Task→Agent), Sidecar-NG (Prompt→Context) — drei separate Systeme die dasselbe Problem auf verschiedenen
+  Ebenen lösen. Kein gemeinsames Routing-Protokoll.
+
+  2. Kein Execution-Bridge
+  KomandoZentral empfiehlt einen Harness, führt aber nicht aus. AgentIDE hat Pipelines, aber nur Mocks. UEBER_AGENT versucht zu delegieren, scheitert.
+  Niemand verbindet Entscheidung → Ausführung.
+
+  3. Kein persistenter Cross-Project Memory
+  MetaMetaMeta dokumentiert Erkenntnisse als Markdown. Aber es gibt keinen programmatischen Weg, wie KomandoZentral auf MetaMetaMeta-Insights zugreift
+  oder AgentIDE Outcomes zurückmeldet.
+
+  4. Kein Feedback-Loop (Self-Modification)
+  Das ist die eigentliche Von-Neumann-Lücke: Das System kann sich nicht selbst verbessern. KomandoZentral hat kein Outcome-Tracking. AgentArena kann
+  evaluieren, aber die Ergebnisse fließen nicht zurück in Routing-Regeln.
+
+  5. Kein gemeinsames Datenmodell
+  YAML (KomandoZentral), JSON (HarnessEcosystem), Markdown (MetaMetaMeta), SQLite (AgentIDE/PromptGarage). Keine gemeinsame Schema-Sprache.
+
+  6. Concept-Code-Gap
+  MultiHarnessStudio's Drei-Layer-Prompting (Task Spec / Harness Adaptation / Model Adaptation) ist die stärkste konzeptuelle Erkenntnis — aber hat null
+  Zeilen Code.
+
+  7. Samuel ist der Bottleneck
+  In allen Projekten ist Samuel der manuelle Router, Evaluator, und Memory-Layer. Das System braucht ihn für jede Entscheidung. Das ist das Gegenteil von
+   Von Neumann — ein gespeichertes Programm sollte ohne den Operator laufen können.
+
+  Was fehlt konkret
+
+  FÜR EIN KONSISTENTES SYSTEM BRAUCHST DU:
+
+  1. UNIFIED ROUTING PROTOCOL
+     KomandoZentral + Sidecar-NG als ein Stack
+     Input: Task → Output: Harness + Context + Confidence
+
+  2. EXECUTION BRIDGE
+     AgentIDE mit echten LLM-Calls statt Mocks
+     ODER: KomandoZentral → direkter Harness-Aufruf
+
+  3. OUTCOME STORE (der fehlende Memory-Layer)
+     Task → Routing Decision → Execution → Result → Score
+     Jede Entscheidung wird persistent + queryable
+
+  4. FEEDBACK LOOP
+     Outcome Store → KomandoZentral Rules Engine
+     Schlechte Outcomes senken Harness-Confidence automatisch
+
+  5. SHARED SCHEMA
+     Ein Format für Task, Decision, Outcome, Insight
+     (vermutlich JSON/SQLite, nicht Markdown)
+
+  Meine Einschätzung
+
+  Du hast alle Schichten schon gebaut — aber jede als isoliertes Projekt. Das Bild ist da, die Teile sind da. Was fehlt ist nicht ein neues Projekt,
+  sondern Kleber:
+
+  - Ein Unified Router (KomandoZentral + Sidecar-NG merge)
+  - Ein Outcome Store (SQLite, ~3 Tabellen)
+  - Ein Feedback-Wire (Outcome → Routing Rules)
+
+  Das wäre das Minimum Viable Von Neumann System. Willst du das durchplanen?
+
+✻ Churned for 58s
+
+─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
+❯ 
+─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
+  21% [RESEARCHMODE] Sidecar: ok
+

README.md

@@ -0,0 +1,77 @@
+# Spine V1
+
+Spine ist die kanonische Integrationsschicht zwischen:
+
+- `MetaMetaMeta` als Evidence- und Eval-Layer
+- `KomandoZentral` als Decision-Layer
+- `UEBER_AGENT` als Execution-Layer
+- `AgentIDE` als Operator-UI
+- `HarnessEcosystem` als Observatory- und Docs-Layer
+
+Diese Implementierung ist absichtlich `spec-first`. Sie definiert:
+
+- kanonische Kernobjekte
+- versionierte JSON-Schemas
+- eine maschinenlesbare Registry
+- einen Beispiel-Run von Intent bis Eval
+- ein lokales Validierungsskript
+
+## Kernprinzip
+
+Spine ersetzt keine der bestehenden Runtime- oder UI-Systeme. Spine erzwingt nur, dass alle Systeme dieselben Objekte, IDs und Zustandsuebergaenge sprechen.
+
+Formel:
+
+`Spine = Registry + Schemas + Run-State + Event-Log + Artifact-Index + Adapter-Vertraege`
+
+## Repo-Struktur
+
+- `docs/` Architektur- und Integrationsbeschreibung
+- `schemas/` kanonische JSON-Schemas
+- `registry/` Systemmanifest, Harness- und Adapter-Registry
+- `examples/` durchgaengiger Beispiel-Run
+- `scripts/validate_spine.py` lokale Konsistenzpruefung
+
+## Wichtige Kernobjekte
+
+- `TaskRequest`
+- `RoutingDecision`
+- `RunRecord`
+- `ExecutionRequest`
+- `ExecutionStatus`
+- `RouteTrace`
+- `ArtifactManifest`
+- `EvalRecord`
+- `SpineEvent`
+- `SystemManifest`
+
+## Lifecycle
+
+1. `TaskRequest` wird erzeugt.
+2. `KomandoZentral` liefert eine `RoutingDecision`.
+3. Spine erzeugt oder aktualisiert den `RunRecord`.
+4. Ein `ExecutionRequest` wird an die Runtime uebergeben.
+5. Runtime meldet `ExecutionStatus`, `RouteTrace` und `ArtifactManifest`.
+6. Evidence- und Observatory-Layer konsumieren `EvalRecord` und Event-Historie.
+
+## Validierung
+
+```bash
+python3 /home/smlflg/Projekte/MultiHarnessStudio/scripts/validate_spine.py
+```
+
+Das Skript validiert:
+
+- dass alle JSON-Dateien parsebar sind
+- dass die Kernschemas vorhanden sind
+- dass Registry-Eintraege eindeutig sind
+- dass der Beispiel-Run intern konsistent ist
+
+## V1 Defaults
+
+- lokal-first
+- JSON als Austauschformat
+- append-only Event-Historie
+- versionierte Schemas
+- Registry als Source of Truth fuer Integrationsvertraege
+- Adapter duerfen uebersetzen, aber keine Spine-Kernobjekte verbiegen

Spine_Idea/GPT_PLAN

@@ -0,0 +1,518 @@
+Spine ist die verbindende Systemschicht zwischen deinen bestehenden Ebenen:
+
+  - MetaMetaMeta liefert Erkenntnisse und Eval-Daten
+  - KomandoZentral trifft Entscheidungen
+  - UEBER_AGENT führt aus
+  - AgentIDE ist Operator-Oberfläche
+  - HarnessEcosystem visualisiert und dokumentiert
+
+  Spine selbst ist weder primär UI noch primär Runtime noch primär Wissensrepo. Es ist die kanonische Integrationsschicht mit gemeinsamer Sprache, gemeinsamen IDs,
+  gemeinsamen Verträgen und einem durchgehenden Event-/Artifact-Strom.
+
+  Das Ziel von Spine ist nicht, alles zu ersetzen, sondern Folgendes zu garantieren:
+
+  1. Alle Teilsysteme sprechen dieselben Kernobjekte.
+  2. Jede Entscheidung, Ausführung, Beobachtung und Bewertung ist als Run nachvollziehbar.
+  3. Handoffs zwischen Entscheidung, Runtime, UI und Eval sind maschinenlesbar statt implizit.
+  4. Das Gesamtsystem ist beobachtbar, rekonstruierbar und erweiterbar.
+
+  ## Kernfähigkeiten von Spine
+
+  Spine muss zwingend können:
+
+  - Kanonische Objekte definieren: Task, Decision, ExecutionRequest, Run, Event, Artifact, EvalResult, Capability, Agent, Harness, Workspace.
+  - Globale IDs vergeben und referenzierbar machen:
+    task_id, decision_id, run_id, execution_id, artifact_id, eval_id.
+  - Zustandsübergänge verwalten:
+    draft -> decided -> dispatched -> running -> completed|failed|aborted -> evaluated.
+  - Events unverlierbar protokollieren.
+  - Artifacts versioniert registrieren.
+  - Zwischen Systemen übersetzen, aber nicht inhaltlich “raten”.
+  - Provenienz sichern:
+    Jede Entscheidung und jedes Ergebnis muss auf Quelle, Version, Zeit und Ursprungssystem rückführbar sein.
+  - Capability-Discovery anbieten:
+    Welche Harnesses, Agenten und Ausführungsziele existieren, in welchem Zustand, mit welchen Verträgen?
+  - Routing und Execution entkoppeln:
+    KomandoZentral entscheidet, UEBER_AGENT führt aus, Spine verbindet beides.
+  - Eval-Loop schließen:
+    Runtime- und Outcome-Daten müssen zurück in MetaMetaMeta und HarnessEcosystem fließen.
+
+  Spine darf in V1 bewusst nicht sein:
+
+  - kein LLM-Orchestrator
+  - kein Ersatz für OpenClaw
+  - kein eigener IDE-Editor
+  - kein Wissensfrontend
+  - kein autonomer Planer
+  - kein “smartes Superhirn”, das implizit fehlende Daten ergänzt
+
+  ## Technische Rolle im System
+
+  Spine ist logisch in 5 Subsysteme gegliedert:
+
+  ### 1. Registry Layer
+
+  Hält den kanonischen Bestand an Systemobjekten.
+
+  Enthält:
+
+  - Harness-Registry
+  - Agent-Registry
+  - Capability-Registry
+  - Workspace-Registry
+  - Runtime-Targets
+  - Schema-Versionen
+
+  Pflichtfragen, die dieser Layer beantworten muss:
+
+  - Welche Harnesses existieren?
+  - Welche Agenten existieren?
+  - Welche Inputs akzeptieren sie?
+  - Welche Outputs liefern sie?
+  - Welche Runtime ist aktiv, blockiert, deprecated oder experimental?
+
+  ### 2. Contract Layer
+
+  Definiert die formalen Schemas.
+
+  Pflichtschemas:
+
+  - TaskRequest
+  - RoutingDecision
+  - ExecutionRequest
+  - ExecutionStatus
+  - RouteTrace
+  - ArtifactManifest
+  - EvalRecord
+  - OperatorContext
+  - SystemManifest
+
+  Dieser Layer ist der eigentliche Kern von Spine.
+
+  ### 3. Event Layer
+
+  Ein append-only Eventstrom.
+
+  Pflichtevents:
+
+  - task.created
+  - decision.created
+  - decision.approved
+  - execution.requested
+  - execution.dispatched
+  - execution.started
+  - execution.progress
+  - execution.completed
+  - execution.failed
+  - artifact.created
+  - eval.recorded
+  - run.closed
+
+  Jedes Event braucht:
+
+  - globale ID
+  - Typ
+  - Zeitstempel
+  - run_id
+  - source_system
+  - schema_version
+  - Payload
+  - Referenzen auf verursachende Objekte
+
+  ### 4. Artifact Layer
+
+  Verwaltet alle erzeugten Outputs.
+
+  Artifact-Typen:
+
+  - decision yaml/json
+  - prompt/tasksheet
+  - trace
+  - runtime log
+  - deploy result
+  - evaluation result
+  - report/dashboard snapshot
+  - patch/commit reference
+  - derived summary
+
+  Pflichtfelder:
+
+  - artifact_id
+  - artifact_type
+  - uri
+  - produced_by
+  - run_id
+  - content_hash
+  - created_at
+  - schema_version
+
+  ### 5. Adapter Layer
+
+  Adapter zu den bestehenden Projekten.
+
+  Pflichtadapter:
+
+  - metametameta_adapter
+  - komandozentral_adapter
+  - ueber_agent_adapter
+  - agentide_adapter
+  - harnessecosystem_adapter
+
+  Adapter-Regel:
+  Adapter dürfen lokale Formate ins Spine-Format übersetzen, aber nicht die Spine-Kernmodelle verändern.
+
+  ## Spine Input
+
+  Spine braucht nur wenige kanonische Input-Klassen.
+
+  ### A. Intent Input
+
+  Kommt von User, UI oder externem System.
+
+  Beispiel:
+
+  - Taskbeschreibung
+  - Zielsystem / gewünschtes Ergebnis
+  - Priorität
+  - Constraints
+  - Operator-Kontext
+
+  Form:
+  TaskRequest
+
+  Pflichtfelder:
+
+  - task_id
+  - title
+  - description
+  - requested_by
+  - created_at
+  - origin_system
+  - operator_context
+  - constraints
+  - desired_outcomes
+
+  ### B. Decision Input
+
+  Kommt typischerweise aus KomandoZentral.
+
+  Form:
+  RoutingDecision
+
+  Pflichtfelder:
+
+  - decision_id
+  - task_id
+  - recommended_harness
+  - recommended_runtime_target
+  - confidence
+  - reasoning_summary
+  - risks
+  - fallback
+  - decision_policy_version
+
+  ### C. Execution Input
+
+  Kommt aus Entscheidung plus Runtime-Handoff.
+
+  Form:
+  ExecutionRequest
+
+  Pflichtfelder:
+
+  - execution_id
+  - decision_id
+  - run_id
+  - target_runtime
+  - target_agent
+  - input_artifacts
+  - execution_mode
+  - workspace_ref
+  - timeout_policy
+  - approval_requirements
+
+  ### D. Observation Input
+
+  Kommt aus Runtime, UI oder Logs.
+
+  Formen:
+
+  - ExecutionStatus
+  - RouteTrace
+  - ArtifactManifest
+  - EvalRecord
+
+  ## Spine Output
+
+  Spine muss 4 Output-Klassen bereitstellen.
+
+  ### 1. Dispatchable Execution Contract
+
+  Für UEBER_AGENT oder andere Runtime.
+
+  Output:
+
+  - normalisierter ExecutionRequest
+  - referenzierte Inputs
+  - freigegebene Runtime-Parameter
+  - erwartete Rückgabeschemata
+
+  ### 2. Observable Run State
+
+  Für AgentIDE und Monitoring.
+
+  Output:
+
+  - aktueller Status eines Runs
+  - Event-Feed
+  - Artefakte
+  - Fehlerzustände
+  - nächste erlaubte Transitionen
+
+  ### 3. Knowledge Feed
+
+  Für MetaMetaMeta und HarnessEcosystem.
+
+  Output:
+
+  - eval-fähige Run-Historie
+  - aggregierte Outcome-Daten
+  - strukturierte Trace-Daten
+  - Registry-Snapshots
+  - Dashboard-Feeds
+
+  ### 4. Audit Trail
+
+  Für Debugging und Vertrauensbildung.
+
+  Output:
+
+  - vollständige Rekonstruktion eines Runs
+  - welche Entscheidung zu welcher Ausführung führte
+  - welche Quellen benutzt wurden
+  - welche Artefakte entstanden
+  - welches Eval daraus resultierte
+
+  ## Was passiert dazwischen
+
+  Der zentrale Spine-Flow ist:
+
+  1. Ein TaskRequest wird erzeugt.
+  2. KomandoZentral erzeugt daraus eine RoutingDecision.
+  3. Spine validiert diese gegen Registry und Schema.
+  4. Spine erzeugt einen Run und daraus ein ExecutionRequest.
+  5. UEBER_AGENT oder anderes Runtime-Ziel übernimmt die Ausführung.
+  6. Während der Ausführung sendet die Runtime Status, Trace und Artifact-Referenzen zurück.
+  7. Spine schreibt alles in Event- und Artifact-Layer.
+  8. AgentIDE liest den Live-Zustand.
+  9. MetaMetaMeta liest die vollständige Historie als Evidence.
+  10. HarnessEcosystem liest verdichtete Registry-/Outcome-/Guide-Daten als Präsentationsfeed.
+
+  Wichtig:
+  Spine ist dabei nicht der “Denkende”, sondern der “Verbindliche”.
+
+  ## Pflicht-Spezifikationen
+
+  ### 1. ID- und Referenzmodell
+
+  Alle Hauptobjekte brauchen globale, stabile IDs.
+
+  Minimal:
+
+  - task_id
+  - run_id
+  - decision_id
+  - execution_id
+  - artifact_id
+  - eval_id
+
+  Regel:
+  Jedes Objekt referenziert nur über IDs, nie nur über freie Dateipfade oder implizite Dateinamen.
+
+  ### 2. Zustandsmodell
+
+  Run braucht eine endliche, harte State-Machine.
+
+  Minimal:
+
+  - created
+  - decided
+  - ready_for_dispatch
+  - dispatched
+  - running
+  - waiting_for_input
+  - completed
+  - failed
+  - aborted
+  - evaluated
+
+  Regel:
+  Kein System darf Zustände frei erfinden.
+
+  ### 3. Schema-Versionierung
+
+  Jedes Spine-Objekt braucht:
+
+  - schema_name
+  - schema_version
+
+  Regel:
+  Adapters dürfen alte lokale Formate einlesen, aber Spine intern nur versionierte kanonische Formen führen.
+
+  ### 4. Provenienz
+
+  Jedes Objekt braucht:
+
+  - source_system
+  - source_ref
+  - created_at
+  - created_by
+  - optional derived_from
+
+  ### 5. Capability-Spezifikation
+
+  Jeder Harness/Agent braucht maschinenlesbar:
+
+  - id
+  - kind
+  - status
+  - accepts
+  - emits
+  - constraints
+  - runtime_target
+  - cost_class
+  - trust_level
+
+  Das ist die Voraussetzung, damit KomandoZentral nicht nur theoretisch routet, sondern gegen reale Ziele.
+
+  ### 6. Artifact-Spezifikation
+
+  Artifacts müssen inhaltlich typisiert sein.
+
+  Minimaltypen:
+
+  - decision
+  - execution_input
+  - trace
+  - log
+  - report
+  - tasksheet
+  - eval
+  - workspace_snapshot
+  - patch_ref
+  - deploy_result
+
+  ### 7. Fehler- und Abbruchmodell
+
+  Spine muss Failure first-class behandeln.
+
+  Fehlertypen:
+
+  - validation_error
+  - dispatch_error
+  - runtime_error
+  - timeout
+  - contract_mismatch
+  - missing_capability
+  - approval_blocked
+  - unknown_failure
+
+  ### 8. Read/Write-Verantwortung
+
+  Klare Ownership:
+
+  - KomandoZentral darf RoutingDecision schreiben
+  - UEBER_AGENT darf ExecutionStatus, RouteTrace, ArtifactManifest schreiben
+  - MetaMetaMeta darf EvalRecord und Derived Insights schreiben
+  - HarnessEcosystem liest primär
+  - AgentIDE liest primär und darf TaskRequest erzeugen
+
+  ## Minimale öffentliche Interfaces
+
+  ### System Registry API
+
+  Reads:
+
+  - list_harnesses()
+  - list_agents()
+  - get_capability(id)
+  - get_runtime_targets()
+  - get_schema_versions()
+
+  ### Run API
+
+  Reads/Writes:
+
+  - create_task(task_request)
+  - attach_decision(routing_decision)
+  - create_execution(execution_request)
+  - append_event(event)
+  - register_artifact(artifact_manifest)
+  - close_run(run_id)
+
+  ### Query API
+
+  Reads:
+
+  - get_run(run_id)
+  - get_run_events(run_id)
+  - get_run_artifacts(run_id)
+  - get_decision(decision_id)
+  - get_task(task_id)
+  - get_eval_records(run_id)
+  - query_runs(filters)
+
+  ### Feed API
+
+  Reads:
+
+  - get_ecosystem_snapshot()
+  - get_runtime_health()
+  - get_eval_summary()
+  - get_registry_snapshot()
+
+  ## V1 Defaults
+
+  Für die erste Spezifikation sollten folgende Defaults gesetzt werden:
+
+  - Spine ist zunächst lokal-first.
+  - Spine ist source-of-truth für Verträge, nicht zwingend für alle Rohdaten.
+  - Persistenzmodell zunächst event-log + registry + artifact-index, nicht sofort komplexe relationale Vollplattform.
+  - JSON oder YAML als kanonische Austauschform; intern darf eine DB später folgen.
+  - Append-only Events sind Pflicht.
+  - Registry und Schemas sind versioniert.
+  - Runtime bleibt außerhalb von Spine.
+  - UI bleibt außerhalb von Spine.
+  - Eval-Interpretation bleibt außerhalb von Spine.
+  - Spine macht Validierung, Referenzierung und Rekonstruktion.
+
+  ## Test- und Evaluationskriterien
+
+  Ein Spine-Design ist nur dann gut, wenn folgende Szenarien vollständig möglich sind:
+
+  1. Ein Task wird erzeugt, geroutet, ausgeführt und evaluiert, und jede Station ist rekonstruierbar.
+  2. KomandoZentral kann eine Entscheidung ausgeben, ohne die Runtime zu kennen, aber Spine kann trotzdem validieren, ob das Ziel existiert.
+  3. UEBER_AGENT kann Laufstatus und Trace zurückmelden, ohne UI-spezifische Semantik zu brauchen.
+  4. AgentIDE kann einen kompletten Run live darstellen, nur aus Spine-Zustand und Events.
+  5. HarnessEcosystem kann aus Spine einen statischen Snapshot oder Feed bauen, ohne Handpflege.
+  6. MetaMetaMeta kann aus Spine vollständige Eval-Datensätze ziehen, ohne Ad-hoc-Pfadwissen.
+  7. Ein fehlgeschlagener Run ist genauso sauber modelliert wie ein erfolgreicher.
+  8. Neue Harnesses oder neue Agenttypen lassen sich über Registry + Capability ergänzen, ohne Kernobjekte neu zu erfinden.
+
+  ## Explizite Annahmen
+
+  - Spine ist eine Integrationsspezifikation und Integrationsschicht, kein neues monolithisches “Superprojekt”.
+  - KomandoZentral bleibt Decision Engine.
+  - UEBER_AGENT bleibt Execution Engine.
+  - MetaMetaMeta bleibt Evidence Layer.
+  - AgentIDE bleibt Operator Frontend.
+  - HarnessEcosystem bleibt Präsentations- und Lernlayer.
+  - Der wichtigste technische Engpass ist nicht fehlende Intelligenz, sondern fehlender gemeinsamer Vertrag.
+
+  ## Kurzformel
+
+  Die theoretische Essenz von Spine ist:
+
+  Spine = Registry + Schemas + Run-State + Event-Log + Artifact-Index + Adapter-Verträge
+
+  Wenn das sauber spezifiziert ist, werden deine Projekte nicht mehr nur “verbunden gedacht”, sondern wirklich als ein konsistentes System betreibbar.

Spine_Idea/spine-konzept.html

@@ -0,0 +1,1310 @@
+<!DOCTYPE html>
+<html lang="de">
+<head>
+<meta charset="UTF-8">
+<meta name="viewport" content="width=device-width, initial-scale=1.0">
+<title>Spine — Die kanonische Integrationsschicht</title>
+<link rel="preconnect" href="https://fonts.googleapis.com">
+<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
+<link href="https://fonts.googleapis.com/css2?family=Instrument+Serif&family=JetBrains+Mono:wght@400;500;600;700&family=DM+Sans:wght@400;500;600;700&display=swap" rel="stylesheet">
+<style>
+  :root {
+    --font-display: 'Instrument Serif', Georgia, serif;
+    --font-body: 'DM Sans', system-ui, sans-serif;
+    --font-mono: 'JetBrains Mono', 'SF Mono', Consolas, monospace;
+
+    --bg: #f6f3ef;
+    --surface: #ffffff;
+    --surface2: #eee9e2;
+    --surface-elevated: #fffcf8;
+    --border: rgba(0,0,0,0.07);
+    --border-bright: rgba(0,0,0,0.14);
+    --text: #1e1e1e;
+    --text-dim: #7a7062;
+
+    --navy: #1e3a5f;
+    --navy-dim: rgba(30,58,95,0.08);
+    --gold: #b8860b;
+    --gold-dim: rgba(184,134,11,0.08);
+    --teal: #0f766e;
+    --teal-dim: rgba(15,118,110,0.08);
+    --sage: #4d7c0f;
+    --sage-dim: rgba(77,124,15,0.08);
+    --rose: #9f1239;
+    --rose-dim: rgba(159,18,57,0.08);
+    --amber: #92400e;
+    --amber-dim: rgba(146,64,14,0.08);
+    --plum: #6b21a8;
+    --plum-dim: rgba(107,33,168,0.08);
+  }
+
+  @media (prefers-color-scheme: dark) {
+    :root {
+      --bg: #111318;
+      --surface: #1a1d24;
+      --surface2: #22262e;
+      --surface-elevated: #252a33;
+      --border: rgba(255,255,255,0.06);
+      --border-bright: rgba(255,255,255,0.12);
+      --text: #e8e4df;
+      --text-dim: #8a8377;
+
+      --navy: #7cb3e0;
+      --navy-dim: rgba(124,179,224,0.1);
+      --gold: #d4a73a;
+      --gold-dim: rgba(212,167,58,0.1);
+      --teal: #5eead4;
+      --teal-dim: rgba(94,234,212,0.08);
+      --rose: #fda4af;
+      --rose-dim: rgba(253,164,175,0.08);
+      --sage: #a3e635;
+      --sage-dim: rgba(163,230,53,0.08);
+      --amber: #fbbf24;
+      --amber-dim: rgba(251,191,36,0.08);
+      --plum: #c084fc;
+      --plum-dim: rgba(192,132,252,0.08);
+    }
+  }
+
+  * { margin: 0; padding: 0; box-sizing: border-box; }
+
+  body {
+    background: var(--bg);
+    background-image:
+      radial-gradient(ellipse at 15% 0%, var(--navy-dim) 0%, transparent 50%),
+      radial-gradient(ellipse at 85% 100%, var(--gold-dim) 0%, transparent 40%);
+    color: var(--text);
+    font-family: var(--font-body);
+    padding: 24px;
+    min-height: 100vh;
+    line-height: 1.6;
+  }
+
+  @keyframes fadeUp {
+    from { opacity: 0; transform: translateY(14px); }
+    to { opacity: 1; transform: translateY(0); }
+  }
+  @keyframes fadeScale {
+    from { opacity: 0; transform: scale(0.92); }
+    to { opacity: 1; transform: scale(1); }
+  }
+
+  .anim { animation: fadeUp 0.45s ease-out both; animation-delay: calc(var(--i,0) * 0.07s); }
+  .anim-scale { animation: fadeScale 0.4s ease-out both; animation-delay: calc(var(--i,0) * 0.07s); }
+
+  @media (prefers-reduced-motion: reduce) {
+    *, *::before, *::after {
+      animation-duration: 0.01ms !important;
+      animation-delay: 0ms !important;
+    }
+  }
+
+  /* ===== LAYOUT ===== */
+  .wrap {
+    max-width: 1400px;
+    margin: 0 auto;
+    display: grid;
+    grid-template-columns: 200px 1fr;
+    gap: 0 48px;
+  }
+  .main { min-width: 0; }
+
+  /* ===== TOC ===== */
+  .toc {
+    position: sticky;
+    top: 24px;
+    align-self: start;
+    padding: 14px 0;
+    grid-row: 1 / -1;
+    max-height: calc(100dvh - 48px);
+    overflow-y: auto;
+  }
+  .toc::-webkit-scrollbar { width: 3px; }
+  .toc::-webkit-scrollbar-thumb { background: var(--surface-elevated); border-radius: 2px; }
+  .toc-title {
+    font-family: var(--font-mono);
+    font-size: 9px;
+    font-weight: 700;
+    text-transform: uppercase;
+    letter-spacing: 2px;
+    color: var(--text-dim);
+    padding: 0 0 10px;
+    margin-bottom: 8px;
+    border-bottom: 1px solid var(--border);
+  }
+  .toc a {
+    display: block;
+    font-size: 11px;
+    color: var(--text-dim);
+    text-decoration: none;
+    padding: 4px 8px;
+    border-radius: 5px;
+    border-left: 2px solid transparent;
+    transition: all 0.15s;
+    line-height: 1.4;
+    margin-bottom: 1px;
+  }
+  .toc a:hover { color: var(--text); background: var(--surface2); }
+  .toc a.active { color: var(--text); border-left-color: var(--gold); }
+
+  @media (max-width: 1100px) {
+    .wrap { grid-template-columns: 1fr; padding-top: 0; }
+    body { padding: 20px; padding-top: 0; }
+    .toc {
+      position: sticky; top: 0; z-index: 200;
+      max-height: none; display: flex; gap: 4px; align-items: center;
+      overflow-x: auto; -webkit-overflow-scrolling: touch;
+      background: var(--bg); border-bottom: 1px solid var(--border);
+      padding: 10px 0; margin: 0 -20px; padding-left: 20px; padding-right: 20px;
+      grid-row: auto;
+    }
+    .toc::-webkit-scrollbar { display: none; }
+    .toc-title { display: none; }
+    .toc a {
+      white-space: nowrap; flex-shrink: 0; border-left: none;
+      border-bottom: 2px solid transparent; border-radius: 4px 4px 0 0;
+      padding: 6px 10px; font-size: 10px;
+    }
+    .toc a.active { border-left: none; border-bottom-color: var(--gold); background: var(--surface); }
+    .main { padding-top: 20px; }
+    .sec-head { scroll-margin-top: 52px; }
+  }
+
+  /* ===== TYPOGRAPHY ===== */
+  h1 {
+    font-family: var(--font-display);
+    font-size: 52px;
+    font-weight: 400;
+    letter-spacing: -0.5px;
+    margin-bottom: 8px;
+    color: var(--navy);
+    text-wrap: balance;
+  }
+  .subtitle {
+    color: var(--text-dim);
+    font-size: 14px;
+    margin-bottom: 16px;
+    font-family: var(--font-mono);
+    font-weight: 400;
+  }
+  .lead {
+    font-size: 14px;
+    line-height: 1.6;
+    color: var(--text-dim);
+    margin-bottom: 8px;
+    max-width: 760px;
+  }
+  .sec-head {
+    font-family: var(--font-display);
+    font-size: 28px;
+    font-weight: 400;
+    margin-top: 32px;
+    margin-bottom: 20px;
+    padding-bottom: 10px;
+    border-bottom: 2px solid var(--border);
+    display: flex;
+    align-items: baseline;
+    gap: 10px;
+  }
+  .assume-list {
+    list-style: none;
+    font-size: 13px;
+    line-height: 1.6;
+  }
+  .assume-list li {
+    padding: 10px 16px;
+    background: var(--surface);
+    border: 1px solid var(--border);
+    border-radius: 8px;
+    margin-bottom: 8px;
+    display: flex;
+    gap: 12px;
+    align-items: baseline;
+  }
+  .assume-list li::before {
+    content: '\2014';
+    font-family: var(--font-mono);
+    color: var(--gold);
+    font-weight: 700;
+    flex-shrink: 0;
+  }
+
+  /* ===== THEORIE LIST ===== */
+  .theorie-list {
+    list-style: none;
+    font-size: 13px;
+    line-height: 1.7;
+  }
+  .theorie-list li {
+    padding-left: 18px;
+    position: relative;
+    margin-bottom: 4px;
+  }
+  .theorie-list li::before {
+    content: '\2192';
+    position: absolute;
+    left: 0;
+    color: var(--text-dim);
+    font-family: var(--font-mono);
+    font-size: 12px;
+  }
+
+  /* ===== FLOW STEPS ===== */
+  .flow-steps {
+    display: flex;
+    flex-direction: column;
+    gap: 8px;
+  }
+  .flow-step {
+    display: flex;
+    align-items: flex-start;
+    gap: 14px;
+    padding: 8px 12px;
+    background: var(--surface);
+    border: 1px solid var(--border);
+    border-radius: 8px;
+  }
+  .flow-num {
+    font-family: var(--font-mono);
+    font-size: 11px;
+    font-weight: 700;
+    color: var(--gold);
+    background: var(--gold-dim);
+    width: 22px;
+    height: 22px;
+    border-radius: 6px;
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    flex-shrink: 0;
+  }
+  .flow-text {
+    font-size: 13px;
+    color: var(--text);
+    line-height: 1.5;
+    padding-top: 1px;
+  }
+
+  /* ===== COMPACT CARD SYSTEM ===== */
+  .ve-card { padding: 10px 14px !important; }
+  .ve-card--hero { padding: 14px 18px !important; }
+  .ve-card--recessed { padding: 10px 14px !important; }
+  .card-label { font-size: 10px !important; margin-bottom: 6px !important; margin-top: 0 !important; }
+  .card-title { font-size: 13px !important; margin-bottom: 4px !important; }
+  .card-desc { font-size: 12px !important; line-height: 1.5 !important; margin-bottom: 0 !important; color: var(--text-dim) !important; }
+  .callout { padding: 10px 14px !important; margin-bottom: 8px !important; font-size: 12px !important; }
+  .eco-card { padding: 12px 14px !important; }
+  .eco-name { font-size: 13px !important; margin-bottom: 2px !important; }
+  .eco-role { font-size: 11px !important; }
+  .eco-icon { font-size: 10px !important; margin-bottom: 4px !important; }
+  .subsys-card { padding: 14px !important; }
+  .subsys-title { font-size: 15px !important; margin-bottom: 4px !important; }
+  .subsys-desc { font-size: 12px !important; margin-bottom: 10px !important; line-height: 1.5 !important; }
+  .subsys-items { font-size: 11px !important; line-height: 1.6 !important; }
+  .subsys-items li { margin-bottom: 2px !important; }
+  .subsys-num { font-size: 9px !important; margin-bottom: 6px !important; }
+  .hero-formula { font-size: 12px !important; padding: 10px 16px !important; margin: 12px 0 !important; }
+  .theorie-grid { gap: 8px !important; }
+  .flow-steps { gap: 4px !important; }
+  .flow-step { padding: 6px 10px !important; }
+  .flow-num { width: 18px !important; height: 18px !important; font-size: 10px !important; }
+  .flow-text { font-size: 12px !important; }
+  .assume-list { font-size: 12px !important; }
+  .assume-list li { padding: 8px 12px !important; margin-bottom: 4px !important; }
+  .io-card { padding: 12px 14px !important; }
+  .io-title { font-size: 14px !important; margin: 4px 0 !important; }
+  .io-subtitle { font-size: 11px !important; margin-bottom: 8px !important; }
+  .io-label { font-size: 9px !important; margin: 8px 0 4px !important; }
+  .field-list { font-size: 11px !important; }
+  .field-name { font-size: 10px !important; }
+  .spec-card { padding: 12px 14px !important; }
+  .anti-grid { gap: 8px !important; }
+  .anti-item { padding: 8px 12px !important; font-size: 12px !important; }
+  .test-card { padding: 12px 14px !important; }
+  .test-title { font-size: 13px !important; margin-bottom: 4px !important; }
+  .test-desc { font-size: 11px !important; }
+  .api-card { padding: 12px 14px !important; }
+  .api-title { font-size: 13px !important; margin-bottom: 4px !important; }
+  .api-method { font-size: 9px !important; padding: 2px 6px !important; }
+  .state-node { padding: 6px 10px !important; font-size: 10px !important; }
+  .state-machine { gap: 4px !important; }
+  .state-arrow { font-size: 14px !important; padding: 0 4px !important; }
+  .section-title { margin-bottom: 12px !important; }
+  .section-num { width: 18px !important; height: 18px !important; font-size: 10px !important; }
+
+  /* ===== RESPONSIVE ===== */
+  @media (max-width: 900px) {
+    .ecosystem-grid { grid-template-columns: 1fr 1fr; }
+    .anti-grid { grid-template-columns: 1fr 1fr; }
+    .subsystem-grid { grid-template-columns: 1fr; }
+    .theorie-grid { grid-template-columns: 1fr; }
+    .io-grid { grid-template-columns: 1fr; }
+    .api-grid { grid-template-columns: 1fr; }
+    .spec-grid { grid-template-columns: 1fr; }
+    .test-grid { grid-template-columns: 1fr; }
+    .flow-diagram { flex-wrap: wrap; gap: 8px; justify-content: center; }
+    .flow-arrow { display: none; }
+    .state-machine { flex-wrap: wrap; gap: 8px; justify-content: center; }
+    .state-arrow { display: none; }
+    h1 { font-size: 36px; }
+  }
+  @media (max-width: 600px) {
+    .ecosystem-grid { grid-template-columns: 1fr; }
+    .anti-grid { grid-template-columns: 1fr; }
+  }
+</style>
+</head>
+<body>
+
+<div class="wrap">
+
+  <nav class="toc" id="toc">
+    <div class="toc-title">Spine</div>
+    <a href="#s00">Theorie</a>
+    <a href="#s01">Einleitung</a>
+    <a href="#s02">Spine ist nicht</a>
+    <a href="#s03">5 Subsysteme</a>
+    <a href="#s04">Input Classes</a>
+    <a href="#s05">Output Classes</a>
+    <a href="#s06">Zentraler Flow</a>
+    <a href="#s07">Pflicht-Spezifikationen</a>
+    <a href="#s08">Public Interfaces</a>
+    <a href="#s09">V1 Defaults</a>
+    <a href="#s10">Test-Szenarien</a>
+    <a href="#s11">Annahmen</a>
+    <a href="#s12">Kurzformel</a>
+  </nav>
+
+  <div class="main">
+
+    <!-- ===== S01: HERO ===== -->
+    <h1 class="anim" style="--i:0">Spine</h1>
+    <p class="subtitle anim" style="--i:1">Die kanonische Integrationsschicht im MultiHarness Studio</p>
+
+    <p class="lead anim" style="--i:2">
+      Spine ist die verbindende Systemschicht zwischen deinen bestehenden Ebenen. Sie ist weder primär UI noch primär Runtime noch primär Wissensrepo. Es ist die kanonische Integrationsschicht mit gemeinsamer Sprache, gemeinsamen IDs, gemeinsamen Verträgen und einem durchgehenden Event-/Artifact-Strom.
+    </p>
+
+    <div class="hero-formula anim" style="--i:3">
+      <strong>Spine</strong> = Registry + Schemas + Run-State + Event-Log + Artifact-Index + Adapter-Verträge
+    </div>
+
+    <div class="callout callout--navy anim" style="--i:4">
+      <strong>Ziel:</strong> Alle Teilsysteme sprechen dieselben Kernobjekte. Jede Entscheidung, Ausführung, Beobachtung und Bewertung ist als Run nachvollziehbar. Handoffs zwischen Entscheidung, Runtime, UI und Eval sind maschinenlesbar statt implizit. Das Gesamtsystem ist beobachtbar, rekonstruierbar und erweiterbar.
+    </div>
+
+    <!-- ===== S00: THEORIE ===== -->
+    <div id="s00" class="sec-head anim" style="--i:5; margin-top:32px;"><span class="sec-num">00</span> Theorie</div>
+
+    <div class="ve-card ve-card--hero anim" style="--i:6; border-left: 4px solid var(--navy); margin-bottom: 12px;">
+      <div class="card-label"><span class="dot" style="background:var(--navy);"></span> Die gemeinsame Sprache</div>
+      <p class="card-desc" style="font-size:14px; line-height:1.8;">
+        Spine ist die gemeinsame Sprache zwischen:
+      </p>
+      <ul class="theorie-list">
+        <li><strong>MetaMetaMeta</strong> als Erkenntnis- und Eval-Layer</li>
+        <li><strong>KomandoZentral</strong> als Decision-Layer</li>
+        <li><strong>UEBER_AGENT</strong> als Execution-Layer</li>
+        <li><strong>AgentIDE</strong> als Operator-Layer</li>
+        <li><strong>HarnessEcosystem</strong> als Darstellungs-Layer</li>
+      </ul>
+      <p class="card-desc" style="font-size:14px; line-height:1.8;">
+        Die Kernidee ist: Diese Systeme bleiben getrennt, aber sie sprechen dieselben Objekte, IDs, Zustände und Ereignisse. Spine ist also kein "Superagent", sondern die kanonische Integrationsschicht.
+      </p>
+    </div>
+
+    <div id="s01" class="sec-head anim" style="--i:7; margin-top:32px;"><span class="sec-num">01</span> Das &ouml;kosystem</div>
+
+    <p class="lead anim" style="--i:6">
+      Spine sitzt im Zentrum und verbindet 5 umgebende Systeme. Keines davon wird ersetzt &mdash; Spine sorgt für die verbindliche Sprache dazwischen.
+    </p>
+
+    <div class="ecosystem-grid anim" style="--i:7">
+      <div class="eco-card" style="border-top: 3px solid var(--teal);">
+        <div class="eco-icon" style="color:var(--teal);">MetaMetaMeta</div>
+        <div class="eco-name">MetaMetaMeta</div>
+        <div class="eco-role">Liefert Erkenntnisse und Eval-Daten</div>
+      </div>
+      <div class="eco-card" style="border-top: 3px solid var(--gold);">
+        <div class="eco-icon" style="color:var(--gold);">KomandoZentral</div>
+        <div class="eco-name">KomandoZentral</div>
+        <div class="eco-role">Trifft Entscheidungen</div>
+      </div>
+      <div class="eco-card" style="border-top: 3px solid var(--sage);">
+        <div class="eco-icon" style="color:var(--sage);">UEBER_AGENT</div>
+        <div class="eco-name">UEBER_AGENT</div>
+        <div class="eco-role">Führt aus</div>
+      </div>
+      <div class="eco-card" style="border-top: 3px solid var(--plum);">
+        <div class="eco-icon" style="color:var(--plum);">AgentIDE</div>
+        <div class="eco-name">AgentIDE</div>
+        <div class="eco-role">Operator-Oberfläche</div>
+      </div>
+      <div class="eco-card" style="border-top: 3px solid var(--rose);">
+        <div class="eco-icon" style="color:var(--rose);">HarnessEcosystem</div>
+        <div class="eco-name">HarnessEcosystem</div>
+        <div class="eco-role">Visualisiert und dokumentiert</div>
+      </div>
+      <div class="eco-card" style="border-top: 3px solid var(--navy); background:var(--navy-dim);">
+        <div class="eco-icon" style="color:var(--navy);">SPINE</div>
+        <div class="eco-name" style="color:var(--navy);">Spine</div>
+        <div class="eco-role">Integrationsschicht</div>
+      </div>
+    </div>
+
+    <!-- ===== S00.1: THEORIE — WAS SPINE KÖNNEN MUSS ===== -->
+    <div class="card-label anim" style="--i:8; margin-top:16px; margin-bottom:6px;"><span class="dot" style="background:var(--gold);"></span> Was Spine können muss</div>
+
+    <div class="theorie-grid anim" style="--i:9; display:grid; grid-template-columns:1fr 1fr; gap:10px; margin-bottom:8px;">
+      <div class="ve-card" style="border-left:3px solid var(--teal);">
+        <div class="card-title" style="color:var(--teal); font-size:13px;">Kanonische Objekte</div>
+        <div class="card-desc" style="font-size:12px;">Task, Decision, Run, ExecutionRequest, ExecutionStatus, Event, Artifact, EvalResult, Capability, Workspace</div>
+      </div>
+      <div class="ve-card" style="border-left:3px solid var(--gold);">
+        <div class="card-title" style="color:var(--gold); font-size:13px;">Globale IDs</div>
+        <div class="card-desc" style="font-size:12px;">task_id, decision_id, run_id, execution_id, artifact_id, eval_id</div>
+      </div>
+      <div class="ve-card" style="border-left:3px solid var(--sage);">
+        <div class="card-title" style="color:var(--sage); font-size:13px;">State Machine</div>
+        <div class="card-desc" style="font-size:12px;">Harte Zustandsmaschine für Runs und Executions</div>
+      </div>
+      <div class="ve-card" style="border-left:3px solid var(--rose);">
+        <div class="card-title" style="color:var(--rose); font-size:13px;">Append-only Events</div>
+        <div class="card-desc" style="font-size:12px;">Jeder Ablauf rekonstruierbar</div>
+      </div>
+      <div class="ve-card" style="border-left:3px solid var(--plum);">
+        <div class="card-title" style="color:var(--plum); font-size:13px;">Artifacts</div>
+        <div class="card-desc" style="font-size:12px;">Registriert und referenzierbar</div>
+      </div>
+      <div class="ve-card" style="border-left:3px solid var(--amber);">
+        <div class="card-title" style="color:var(--amber); font-size:13px;">Provenienz</div>
+        <div class="card-desc" style="font-size:12px;">Wer hat was wann in welchem System erzeugt?</div>
+      </div>
+      <div class="ve-card" style="border-left:3px solid var(--navy);">
+        <div class="card-title" style="color:var(--navy); font-size:13px;">Capability Discovery</div>
+        <div class="card-desc" style="font-size:12px;">Welche Harnesses, Agenten und Runtime-Ziele existieren real?</div>
+      </div>
+      <div class="ve-card" style="border-left:3px solid var(--teal);">
+        <div class="card-title" style="color:var(--teal); font-size:13px;">Decision & Execution entkoppeln</div>
+        <div class="card-desc" style="font-size:12px;">KomandoZentral entscheidet, UEBER_AGENT führt aus, Spine verbindet</div>
+      </div>
+    </div>
+
+    <div class="callout anim" style="--i:10; margin-bottom:12px;">
+      <strong>Eval Rückfluss:</strong> Ergebnisse müssen wieder in MetaMetaMeta und HarnessEcosystem einfliessen.
+    </div>
+
+    <!-- ===== S00.2: MINIMALER INPUT ===== -->
+    <div class="card-label anim" style="--i:11; margin-bottom:6px;"><span class="dot" style="background:var(--sage);"></span> Minimaler Input für einen echten Run</div>
+
+    <div class="ve-card ve-card--recessed anim" style="--i:12; margin-bottom:12px;">
+      <ul class="theorie-list" style="margin-bottom:0;">
+        <li>Taskbeschreibung</li>
+        <li>Operator-Kontext</li>
+        <li>Ziel- oder Runtime-Präferenz</li>
+        <li>Decision-Objekt</li>
+        <li>Rückmeldungen aus der Ausführung</li>
+      </ul>
+    </div>
+
+    <!-- ===== S00.3: WAS ZWISCHEN PASSIERT ===== -->
+    <div class="card-label anim" style="--i:13; margin-bottom:6px;"><span class="dot" style="background:var(--rose);"></span> Was dazwischen passiert</div>
+
+    <div class="flow-steps anim" style="--i:14; margin-bottom:12px;">
+      <div class="flow-step">
+        <div class="flow-num">1</div>
+        <div class="flow-text">Ein Task wird angelegt.</div>
+      </div>
+      <div class="flow-step">
+        <div class="flow-num">2</div>
+        <div class="flow-text">KomandoZentral liefert eine Routing-Entscheidung.</div>
+      </div>
+      <div class="flow-step">
+        <div class="flow-num">3</div>
+        <div class="flow-text">Spine validiert, ob das Ziel in der Registry real existiert.</div>
+      </div>
+      <div class="flow-step">
+        <div class="flow-num">4</div>
+        <div class="flow-text">Spine erzeugt einen Run und daraus einen ExecutionRequest.</div>
+      </div>
+      <div class="flow-step">
+        <div class="flow-num">5</div>
+        <div class="flow-text">UEBER_AGENT oder ein anderes Runtime-Ziel führt aus.</div>
+      </div>
+      <div class="flow-step">
+        <div class="flow-num">6</div>
+        <div class="flow-text">Während der Ausführung kommen Status, Trace und Artifacts zurück.</div>
+      </div>
+      <div class="flow-step">
+        <div class="flow-num">7</div>
+        <div class="flow-text">Spine schreibt alles als Events und referenzierte Artefakte.</div>
+      </div>
+      <div class="flow-step">
+        <div class="flow-num">8</div>
+        <div class="flow-text">MetaMetaMeta bewertet den Run.</div>
+      </div>
+      <div class="flow-step">
+        <div class="flow-num">9</div>
+        <div class="flow-text">HarnessEcosystem zeigt den verdichteten Zustand.</div>
+      </div>
+    </div>
+
+    <!-- ===== S00.4: TECHNISCHE SPEZIFIKATIONEN ===== -->
+    <div class="card-label anim" style="--i:15; margin-bottom:6px;"><span class="dot" style="background:var(--plum);"></span> Technische Spezifikationsbereiche</div>
+
+    <div class="theorie-grid anim" style="--i:16; display:grid; grid-template-columns:1fr 1fr; gap:10px; margin-bottom:8px;">
+      <div class="ve-card" style="border-left:3px solid var(--navy);">
+        <div class="card-title" style="font-size:13px;">Registry Model</div>
+        <div class="card-desc" style="font-size:12px;">Harnesses, Agenten, Runtime-Ziele und Capabilities</div>
+      </div>
+      <div class="ve-card" style="border-left:3px solid var(--gold);">
+        <div class="card-title" style="font-size:13px;">Contract Model</div>
+        <div class="card-desc" style="font-size:12px;">Alle Kernobjekte</div>
+      </div>
+      <div class="ve-card" style="border-left:3px solid var(--teal);">
+        <div class="card-title" style="font-size:13px;">State Model</div>
+        <div class="card-desc" style="font-size:12px;">Zulässige Zustandsübergänge</div>
+      </div>
+      <div class="ve-card" style="border-left:3px solid var(--rose);">
+        <div class="card-title" style="font-size:13px;">Event Model</div>
+        <div class="card-desc" style="font-size:12px;">Append-only Historie</div>
+      </div>
+      <div class="ve-card" style="border-left:3px solid var(--sage);">
+        <div class="card-title" style="font-size:13px;">Artifact Model</div>
+        <div class="card-desc" style="font-size:12px;">Outputs und Referenzen</div>
+      </div>
+      <div class="ve-card" style="border-left:3px solid var(--amber);">
+        <div class="card-title" style="font-size:13px;">Adapter Model</div>
+        <div class="card-desc" style="font-size:12px;">Übersetzungen zwischen lokalen Formaten und Spine-Objekten</div>
+      </div>
+      <div class="ve-card" style="border-left:3px solid var(--plum);">
+        <div class="card-title" style="font-size:13px;">Versioning Model</div>
+        <div class="card-desc" style="font-size:12px;">Schema-Evolution</div>
+      </div>
+      <div class="ve-card" style="border-left:3px solid var(--rose);">
+        <div class="card-title" style="font-size:13px;">Error Model</div>
+        <div class="card-desc" style="font-size:12px;">validation_error, dispatch_error, runtime_error, timeout, contract_mismatch</div>
+      </div>
+    </div>
+
+    <!-- ===== S00.5: HARTE SPEZIFIKATIONSREGELN ===== -->
+    <div class="card-label anim" style="--i:17; margin-bottom:6px;"><span class="dot" style="background:var(--gold);"></span> Harte Spezifikationsregeln</div>
+
+    <div class="ve-card anim" style="--i:18; margin-bottom:12px;">
+      <ul class="theorie-list">
+        <li>Jedes Spine-Objekt braucht <code style="font-family:var(--font-mono);font-size:11px;background:var(--gold-dim);color:var(--gold);padding:1px 5px;border-radius:3px;">schema_name</code> und <code style="font-family:var(--font-mono);font-size:11px;background:var(--gold-dim);color:var(--gold);padding:1px 5px;border-radius:3px;">schema_version</code>.</li>
+        <li>Jedes relevante Objekt braucht eine globale ID.</li>
+        <li>Kein Teilsystem darf eigene Run-States erfinden.</li>
+        <li>Adapter dürfen mappen, aber keine Semantik verändern.</li>
+        <li>Events sind append-only.</li>
+        <li>Artifacts werden explizit registriert, nicht nur als freie Dateipfade erwähnt.</li>
+        <li>Provenienz ist Pflicht, nicht Zusatzinfo.</li>
+      </ul>
+    </div>
+
+    <!-- ===== S02: SPINE IS NOT ===== -->
+    <div id="s02" class="sec-head anim" style="--i:8"><span class="sec-num">02</span> Spine ist nicht</div>
+
+    <p class="lead anim" style="--i:9">
+      Spine bewusst V1 nicht zu sein &mdash; dies sind harte Anti-Features, keine fehlenden Bugs.
+    </p>
+
+    <div class="anti-grid anim" style="--i:10">
+      <div class="anti-item"><span class="anti-x">X</span> kein LLM-Orchestrator</div>
+      <div class="anti-item"><span class="anti-x">X</span> kein Ersatz für OpenClaw</div>
+      <div class="anti-item"><span class="anti-x">X</span> kein eigener IDE-Editor</div>
+      <div class="anti-item"><span class="anti-x">X</span> kein Wissensfrontend</div>
+      <div class="anti-item"><span class="anti-x">X</span> kein autonomer Planer</div>
+      <div class="anti-item"><span class="anti-x">X</span> kein "smartes Superhirn"</div>
+    </div>
+
+    <div class="callout anim" style="--i:11">
+      <strong>Regel:</strong> Spine ist der "Verbindliche", nicht der "Denkende". Er übersetzt zwischen Systemen, validiert Verträge und verwaltet Zustand &mdash; aber trifft keine eigenen Entscheidungen.
+    </div>
+
+    <!-- ===== S03: 5 SUBSYSTEME ===== -->
+    <div id="s03" class="sec-head anim" style="--i:12"><span class="sec-num">03</span> Die 5 Subsysteme</div>
+
+    <p class="lead anim" style="--i:13">
+      Spine ist logisch in 5 Subsysteme gegliedert. Zusammen bilden sie die vollständige Integrationsschicht.
+    </p>
+
+    <div class="subsystem-grid anim" style="--i:14">
+
+      <div class="subsys-card" style="border-top: 3px solid var(--navy);">
+        <div class="subsys-num" style="color:var(--navy);">1 &mdash; Registry Layer</div>
+        <div class="subsys-title">Hält den kanonischen Bestand</div>
+        <div class="subsys-desc">Pflichtfragen: Welche Harnesses existieren? Welche Agenten? Welche Inputs akzeptieren sie? Welche Outputs liefern sie? Welche Runtime ist aktiv, blockiert, deprecated oder experimental?</div>
+        <ul class="subsys-items" style="color:var(--navy);">
+          <li>Harness-Registry</li>
+          <li>Agent-Registry</li>
+          <li>Capability-Registry</li>
+          <li>Workspace-Registry</li>
+          <li>Runtime-Targets</li>
+          <li>Schema-Versionen</li>
+        </ul>
+      </div>
+
+      <div class="subsys-card" style="border-top: 3px solid var(--gold);">
+        <div class="subsys-num" style="color:var(--gold);">2 &mdash; Contract Layer</div>
+        <div class="subsys-title">Definiert die formalen Schemas</div>
+        <div class="subsys-desc">Dieser Layer ist der eigentliche Kern von Spine. Alle Nachrichten zwischen Systemen müssen gegen diese Schemas validierbar sein.</div>
+        <ul class="subsys-items" style="color:var(--gold);">
+          <li>TaskRequest</li>
+          <li>RoutingDecision</li>
+          <li>ExecutionRequest</li>
+          <li>ExecutionStatus</li>
+          <li>RouteTrace</li>
+          <li>ArtifactManifest</li>
+          <li>EvalRecord</li>
+          <li>OperatorContext</li>
+          <li>SystemManifest</li>
+        </ul>
+      </div>
+
+      <div class="subsys-card" style="border-top: 3px solid var(--teal);">
+        <div class="subsys-num" style="color:var(--teal);">3 &mdash; Event Layer</div>
+        <div class="subsys-title">Append-only Eventstrom</div>
+        <div class="subsys-desc">Jedes Event ist unveränderlich. Die vollständige Historie eines Runs ist immer rekonstruierbar.</div>
+        <ul class="subsys-items" style="color:var(--teal);">
+          <li>task.created</li>
+          <li>decision.created</li>
+          <li>decision.approved</li>
+          <li>execution.requested</li>
+          <li>execution.dispatched</li>
+          <li>execution.started</li>
+          <li>execution.progress</li>
+          <li>execution.completed</li>
+          <li>execution.failed</li>
+          <li>artifact.created</li>
+          <li>eval.recorded</li>
+          <li>run.closed</li>
+        </ul>
+      </div>
+
+      <div class="subsys-card" style="border-top: 3px solid var(--sage);">
+        <div class="subsys-num" style="color:var(--sage);">4 &mdash; Artifact Layer</div>
+        <div class="subsys-title">Verwaltet alle erzeugten Outputs</div>
+        <div class="subsys-desc">Artifacts sind versioniert und referenzierbar. Jedes Artifact hat einen klaren Producer und eine nachvollziehbare Provenienz.</div>
+        <ul class="subsys-items" style="color:var(--sage);">
+          <li>decision yaml/json</li>
+          <li>prompt/tasksheet</li>
+          <li>trace</li>
+          <li>runtime log</li>
+          <li>deploy result</li>
+          <li>evaluation result</li>
+          <li>report/dashboard snapshot</li>
+          <li>patch/commit reference</li>
+          <li>derived summary</li>
+        </ul>
+      </div>
+
+      <div class="subsys-card" style="border-top: 3px solid var(--plum); grid-column: 1 / -1;">
+        <div class="subsys-num" style="color:var(--plum);">5 &mdash; Adapter Layer</div>
+        <div class="subsys-title">Adapter zu den bestehenden Projekten</div>
+        <div class="subsys-desc">Jedes umgebende System braucht einen eigenen Adapter, der lokale Formate ins Spine-Format übersetzt. Adapter dürfen lokale Formate ins Spine-Format übersetzen, aber nicht die Spine-Kernmodelle verändern.</div>
+        <ul class="subsys-items" style="color:var(--plum); display: inline-flex; flex-wrap: wrap; gap: 8px 24px; padding-left: 0;">
+          <li>metametameta_adapter</li>
+          <li>komandozentral_adapter</li>
+          <li>ueber_agent_adapter</li>
+          <li>agentide_adapter</li>
+          <li>harnessecosystem_adapter</li>
+        </ul>
+      </div>
+
+    </div>
+
+    <div class="callout anim" style="--i:15">
+      <strong>Adapter-Regel:</strong> Adapter übersetzen lokale Formate ins Spine-Format, verändern aber niemals die Spine-Kernmodelle selbst.
+    </div>
+
+    <!-- ===== S04: INPUT CLASSES ===== -->
+    <div id="s04" class="sec-head anim" style="--i:16"><span class="sec-num">04</span> Input Classes</div>
+
+    <p class="lead anim" style="--i:17">
+      Spine braucht nur wenige kanonische Input-Klassen. Alles, was von außen reinkommt, passt in genau eine dieser 4 Kategorien.
+    </p>
+
+    <div class="io-grid anim" style="--i:18">
+
+      <div class="io-card" style="border-top: 3px solid var(--navy);">
+        <span class="io-badge" style="background:var(--navy-dim); color:var(--navy);">A &mdash; Intent Input</span>
+        <div class="io-title">TaskRequest</div>
+        <div class="io-subtitle">Kommt von User, UI oder externem System</div>
+        <div class="io-label">Pflichtfelder</div>
+        <ul class="field-list">
+          <li><span class="field-name">task_id</span> &mdash; globale ID</li>
+          <li><span class="field-name">title</span> &mdash; Kurzbezeichnung</li>
+          <li><span class="field-name">description</span> &mdash; Freitext-Beschreibung</li>
+          <li><span class="field-name">requested_by</span> &mdash; Absender</li>
+          <li><span class="field-name">created_at</span> &mdash; Zeitstempel</li>
+          <li><span class="field-name">origin_system</span> &mdash; Quellsystem</li>
+          <li><span class="field-name">operator_context</span> &mdash; Kontext-Info</li>
+          <li><span class="field-name">constraints</span> &mdash; Randbedingungen</li>
+          <li><span class="field-name">desired_outcomes</span> &mdash; Ziele</li>
+        </ul>
+      </div>
+
+      <div class="io-card" style="border-top: 3px solid var(--gold);">
+        <span class="io-badge" style="background:var(--gold-dim); color:var(--gold);">B &mdash; Decision Input</span>
+        <div class="io-title">RoutingDecision</div>
+        <div class="io-subtitle">Kommt typischerweise aus KomandoZentral</div>
+        <div class="io-label">Pflichtfelder</div>
+        <ul class="field-list">
+          <li><span class="field-name">decision_id</span> &mdash; globale ID</li>
+          <li><span class="field-name">task_id</span> &mdash; referenzierte Task</li>
+          <li><span class="field-name">recommended_harness</span> &mdash; Ziel-Harness</li>
+          <li><span class="field-name">recommended_runtime_target</span> &mdash; Runtime-Ziel</li>
+          <li><span class="field-name">confidence</span> &mdash; Konfidenzwert</li>
+          <li><span class="field-name">reasoning_summary</span> &mdash; Begründung</li>
+          <li><span class="field-name">risks</span> &mdash; identifizierte Risiken</li>
+          <li><span class="field-name">fallback</span> &mdash; Fallback-Option</li>
+          <li><span class="field-name">decision_policy_version</span> &mdash; Policy-Version</li>
+        </ul>
+      </div>
+
+      <div class="io-card" style="border-top: 3px solid var(--teal);">
+        <span class="io-badge" style="background:var(--teal-dim); color:var(--teal);">C &mdash; Execution Input</span>
+        <div class="io-title">ExecutionRequest</div>
+        <div class="io-subtitle">Kommt aus Entscheidung plus Runtime-Handoff</div>
+        <div class="io-label">Pflichtfelder</div>
+        <ul class="field-list">
+          <li><span class="field-name">execution_id</span> &mdash; globale ID</li>
+          <li><span class="field-name">decision_id</span> &mdash; referenzierte Decision</li>
+          <li><span class="field-name">run_id</span> &mdash; übergeordneter Run</li>
+          <li><span class="field-name">target_runtime</span> &mdash; Ziel-Runtime</li>
+          <li><span class="field-name">target_agent</span> &mdash; Ziel-Agent</li>
+          <li><span class="field-name">input_artifacts</span> &mdash; Eingabe-Artefakte</li>
+          <li><span class="field-name">execution_mode</span> &mdash; Modus</li>
+          <li><span class="field-name">workspace_ref</span> &mdash; Workspace-Referenz</li>
+          <li><span class="field-name">timeout_policy</span> &mdash; Timeout-Regel</li>
+          <li><span class="field-name">approval_requirements</span> &mdash; Freigabe-Bedarf</li>
+        </ul>
+      </div>
+
+      <div class="io-card" style="border-top: 3px solid var(--sage);">
+        <span class="io-badge" style="background:var(--sage-dim); color:var(--sage);">D &mdash; Observation Input</span>
+        <div class="io-title">Observation Forms</div>
+        <div class="io-subtitle">Kommt aus Runtime, UI oder Logs</div>
+        <div class="io-label">Formen</div>
+        <ul class="field-list">
+          <li><span class="field-name">ExecutionStatus</span> &mdash; Laufzeit-Status</li>
+          <li><span class="field-name">RouteTrace</span> &mdash; Routing-Verfolgung</li>
+          <li><span class="field-name">ArtifactManifest</span> &mdash; erzeugte Artefakte</li>
+          <li><span class="field-name">EvalRecord</span> &mdash; Evaluations-Datensatz</li>
+        </ul>
+        <div class="io-label">Event Required Fields</div>
+        <ul class="field-list">
+          <li><span class="field-name">globale ID</span></li>
+          <li><span class="field-name">Typ</span></li>
+          <li><span class="field-name">Zeitstempel</span></li>
+          <li><span class="field-name">run_id</span></li>
+          <li><span class="field-name">source_system</span></li>
+          <li><span class="field-name">schema_version</span></li>
+          <li><span class="field-name">Payload</span></li>
+          <li><span class="field-name">Referenzen auf verursachende Objekte</span></li>
+        </ul>
+      </div>
+
+    </div>
+
+    <!-- ===== S05: OUTPUT CLASSES ===== -->
+    <div id="s05" class="sec-head anim" style="--i:19"><span class="sec-num">05</span> Output Classes</div>
+
+    <p class="lead anim" style="--i:20">
+      Spine muss 4 Output-Klassen bereitstellen. Jede ist für einen anderen Konsumenten optimiert.
+    </p>
+
+    <div class="io-grid anim" style="--i:21">
+
+      <div class="io-card" style="border-top: 3px solid var(--teal);">
+        <span class="io-badge" style="background:var(--teal-dim); color:var(--teal);">1 &mdash; Dispatchable</span>
+        <div class="io-title">Execution Contract</div>
+        <div class="io-subtitle">Für UEBER_AGENT oder andere Runtime</div>
+        <ul class="field-list">
+          <li>Normalisierter ExecutionRequest</li>
+          <li>Referenzierte Inputs</li>
+          <li>Freigegebene Runtime-Parameter</li>
+          <li>Erwartete Rückgabeschemata</li>
+        </ul>
+      </div>
+
+      <div class="io-card" style="border-top: 3px solid var(--plum);">
+        <span class="io-badge" style="background:var(--plum-dim); color:var(--plum);">2 &mdash; Observable</span>
+        <div class="io-title">Run State</div>
+        <div class="io-subtitle">Für AgentIDE und Monitoring</div>
+        <ul class="field-list">
+          <li>Aktueller Status eines Runs</li>
+          <li>Event-Feed</li>
+          <li>Artefakte</li>
+          <li>Fehlerzustände</li>
+          <li>Nächste erlaubte Transitionen</li>
+        </ul>
+      </div>
+
+      <div class="io-card" style="border-top: 3px solid var(--amber);">
+        <span class="io-badge" style="background:var(--amber-dim); color:var(--amber);">3 &mdash; Knowledge</span>
+        <div class="io-title">Knowledge Feed</div>
+        <div class="io-subtitle">Für MetaMetaMeta und HarnessEcosystem</div>
+        <ul class="field-list">
+          <li>Eval-fähige Run-Historie</li>
+          <li>Aggregierte Outcome-Daten</li>
+          <li>Strukturierte Trace-Daten</li>
+          <li>Registry-Snapshots</li>
+          <li>Dashboard-Feeds</li>
+        </ul>
+      </div>
+
+      <div class="io-card" style="border-top: 3px solid var(--rose);">
+        <span class="io-badge" style="background:var(--rose-dim); color:var(--rose);">4 &mdash; Audit</span>
+        <div class="io-title">Audit Trail</div>
+        <div class="io-subtitle">Für Debugging und Vertrauensbildung</div>
+        <ul class="field-list">
+          <li>Vollständige Rekonstruktion eines Runs</li>
+          <li>Welche Entscheidung zu welcher Ausführung führte</li>
+          <li>Welche Quellen benutzt wurden</li>
+          <li>Welche Artefakte entstanden</li>
+          <li>Welches Eval daraus resultierte</li>
+        </ul>
+      </div>
+
+    </div>
+
+    <!-- ===== S06: FLOW ===== -->
+    <div id="s06" class="sec-head anim" style="--i:22"><span class="sec-num">06</span> Der zentrale Spine-Flow</div>
+
+    <p class="lead anim" style="--i:23">
+      Von TaskRequest bis HarnessEcosystem &mdash; der komplette Lebenszyklus in 10 Schritten.
+    </p>
+
+    <div class="ve-card ve-card--hero anim" style="--i:24">
+      <div class="flow-diagram">
+        <div class="flow-step">
+          <div class="flow-node" style="border-color:var(--navy-dim);">
+            <div class="flow-num" style="color:var(--navy);">01</div>
+            <div class="flow-name">TaskRequest</div>
+            <div class="flow-system">AgentIDE / User</div>
+          </div>
+        </div>
+        <div class="flow-arrow">-&rarr;</div>
+        <div class="flow-step">
+          <div class="flow-node" style="border-color:var(--gold-dim);">
+            <div class="flow-num" style="color:var(--gold);">02</div>
+            <div class="flow-name">RoutingDecision</div>
+            <div class="flow-system">KomandoZentral</div>
+          </div>
+        </div>
+        <div class="flow-arrow">-&rarr;</div>
+        <div class="flow-step">
+          <div class="flow-node" style="border-color:var(--teal-dim);">
+            <div class="flow-num" style="color:var(--teal);">03</div>
+            <div class="flow-name">Validierung</div>
+            <div class="flow-system">Spine Registry + Schema</div>
+          </div>
+        </div>
+        <div class="flow-arrow">-&rarr;</div>
+        <div class="flow-step">
+          <div class="flow-node" style="border-color:var(--sage-dim);">
+            <div class="flow-num" style="color:var(--sage);">04</div>
+            <div class="flow-name">Run + ExecutionRequest</div>
+            <div class="flow-system">Spine erzeugt</div>
+          </div>
+        </div>
+        <div class="flow-arrow">-&rarr;</div>
+        <div class="flow-step">
+          <div class="flow-node" style="border-color:var(--sage-dim);">
+            <div class="flow-num" style="color:var(--sage);">05</div>
+            <div class="flow-name">Execution</div>
+            <div class="flow-system">UEBER_AGENT</div>
+          </div>
+        </div>
+      </div>
+      <div class="flow-diagram" style="padding-top:0;">
+        <div class="flow-arrow" style="padding:0 8px 0 60px;">&darr;</div>
+      </div>
+      <div class="flow-diagram" style="margin-top:-16px;">
+        <div class="flow-step">
+          <div class="flow-node" style="border-color:var(--teal-dim);">
+            <div class="flow-num" style="color:var(--teal);">06</div>
+            <div class="flow-name">Status + Trace + Artifacts</div>
+            <div class="flow-system">Runtime meldet zur&uuml;ck</div>
+          </div>
+        </div>
+        <div class="flow-arrow">-&rarr;</div>
+        <div class="flow-step">
+          <div class="flow-node" style="border-color:var(--teal-dim);">
+            <div class="flow-num" style="color:var(--teal);">07</div>
+            <div class="flow-name">Event + Artifact Layer</div>
+            <div class="flow-system">Spine schreibt</div>
+          </div>
+        </div>
+        <div class="flow-arrow">-&rarr;</div>
+        <div class="flow-step">
+          <div class="flow-node" style="border-color:var(--plum-dim);">
+            <div class="flow-num" style="color:var(--plum);">08</div>
+            <div class="flow-name">Live-Zustand</div>
+            <div class="flow-system">AgentIDE liest</div>
+          </div>
+        </div>
+        <div class="flow-arrow">-&rarr;</div>
+        <div class="flow-step">
+          <div class="flow-node" style="border-color:var(--amber-dim);">
+            <div class="flow-num" style="color:var(--amber);">09</div>
+            <div class="flow-name">Vollst&auml;ndige Historie</div>
+            <div class="flow-system">MetaMetaMeta</div>
+          </div>
+        </div>
+        <div class="flow-arrow">-&rarr;</div>
+        <div class="flow-step">
+          <div class="flow-node" style="border-color:var(--rose-dim);">
+            <div class="flow-num" style="color:var(--rose);">10</div>
+            <div class="flow-name">Snapshot + Feed</div>
+            <div class="flow-system">HarnessEcosystem</div>
+          </div>
+        </div>
+      </div>
+    </div>
+
+    <div class="callout anim" style="--i:25">
+      <strong>Wichtig:</strong> Spine ist dabei nicht der "Denkende", sondern der "Verbindliche". Er validiert, referenziert und schreibt &mdash; entscheidet aber nicht selbst.
+    </div>
+
+    <!-- ===== S07: MANDATORY SPECS ===== -->
+    <div id="s07" class="sec-head anim" style="--i:26"><span class="sec-num">07</span> Pflicht-Spezifikationen</div>
+
+    <p class="lead anim" style="--i:27">
+      8 Spezifikationen, die jedes Spine-konforme System zwingend erfüllen muss. Keine Ausnahmen, keine Kompromisse.
+    </p>
+
+    <div class="spec-grid anim" style="--i:28">
+
+      <div class="spec-card" style="border-left: 4px solid var(--navy);">
+        <div class="spec-num" style="color:var(--navy);">1 &mdash; ID- und Referenzmodell</div>
+        <div class="spec-title">Globale, stabile IDs</div>
+        <div class="spec-desc">Alle Hauptobjekte brauchen globale, stabile IDs. Jedes Objekt referenziert nur über IDs, nie über freie Dateipfade oder implizite Dateinamen.</div>
+        <div class="ve-card ve-card--recessed" style="padding:14px 18px;">
+          <div class="card-label" style="margin-bottom:8px;"><span class="dot" style="background:var(--navy);"></span> Pflicht-IDs</div>
+          <span class="mono">task_id</span> &nbsp; <span class="mono">run_id</span> &nbsp; <span class="mono">decision_id</span> &nbsp; <span class="mono">execution_id</span> &nbsp; <span class="mono">artifact_id</span> &nbsp; <span class="mono">eval_id</span>
+        </div>
+      </div>
+
+      <div class="spec-card" style="border-left: 4px solid var(--gold);">
+        <div class="spec-num" style="color:var(--gold);">2 &mdash; Zustandsmodell</div>
+        <div class="spec-title">Endliche State-Machine</div>
+        <div class="spec-desc">Run braucht eine endliche, harte State-Machine. Kein System darf Zustände frei erfinden.</div>
+        <div class="state-machine" style="margin:12px 0 0;">
+          <div class="state-box"><div class="state-name">created</div><div class="state-label">initial</div></div>
+          <div class="state-arrow">&rarr;</div>
+          <div class="state-box"><div class="state-name">decided</div></div>
+          <div class="state-arrow">&rarr;</div>
+          <div class="state-box"><div class="state-name">ready</div></div>
+          <div class="state-arrow">&rarr;</div>
+          <div class="state-box"><div class="state-name">dispatched</div></div>
+          <div class="state-arrow">&rarr;</div>
+          <div class="state-box"><div class="state-name">running</div></div>
+          <div class="state-arrow">&rarr;</div>
+          <div class="state-box" style="border-color:var(--sage-dim);"><div class="state-name">completed</div><div class="state-label">success</div></div>
+          <div class="state-box" style="border-color:var(--rose-dim);"><div class="state-name">failed</div></div>
+          <div class="state-box" style="border-color:var(--amber-dim);"><div class="state-name">aborted</div></div>
+        </div>
+        <div style="text-align:center; margin-top:8px;">
+          <span class="state-terminal" style="background:var(--sage-dim); color:var(--sage);">evaluated</span>
+          <span style="font-family:var(--font-mono);font-size:10px;color:var(--text-dim);margin:0 8px;"> als Endzustand</span>
+        </div>
+      </div>
+
+      <div class="spec-card" style="border-left: 4px solid var(--teal);">
+        <div class="spec-num" style="color:var(--teal);">3 &mdash; Schema-Versionierung</div>
+        <div class="spec-title">Versionierte Objekte</div>
+        <div class="spec-desc">Jedes Spine-Objekt braucht schema_name und schema_version. Adapter dürfen alte lokale Formate einlesen, aber Spine intern nur versionierte kanonische Formen führen.</div>
+        <div class="ve-card ve-card--recessed" style="padding:14px 18px; margin-top:8px;">
+          <div class="card-label" style="margin-bottom:8px;"><span class="dot" style="background:var(--teal);"></span> Pflichtfelder</div>
+          <span class="mono">schema_name</span> &nbsp; <span class="mono">schema_version</span>
+        </div>
+      </div>
+
+      <div class="spec-card" style="border-left: 4px solid var(--sage);">
+        <div class="spec-num" style="color:var(--sage);">4 &mdash; Provenienz</div>
+        <div class="spec-title">Rückverfolgbarkeit</div>
+        <div class="spec-desc">Jedes Objekt muss auf Quelle, Version, Zeit und Ursprungssystem rückführbar sein.</div>
+        <div class="ve-card ve-card--recessed" style="padding:14px 18px; margin-top:8px;">
+          <div class="card-label" style="margin-bottom:8px;"><span class="dot" style="background:var(--sage);"></span> Pflichtfelder</div>
+          <span class="mono">source_system</span> &nbsp; <span class="mono">source_ref</span> &nbsp; <span class="mono">created_at</span> &nbsp; <span class="mono">created_by</span> &nbsp; <span class="mono">derived_from</span> <span style="font-size:11px;color:var(--text-dim);">(optional)</span>
+        </div>
+      </div>
+
+      <div class="spec-card" style="border-left: 4px solid var(--plum);">
+        <div class="spec-num" style="color:var(--plum);">5 &mdash; Capability-Spezifikation</div>
+        <div class="spec-title">Maschinenlesbare Fähigkeiten</div>
+        <div class="spec-desc">Jeder Harness/Agent braucht maschinenlesbar: id, kind, status, accepts, emits, constraints, runtime_target, cost_class, trust_level. Das ist die Voraussetzung für echtes Routing.</div>
+      </div>
+
+      <div class="spec-card" style="border-left: 4px solid var(--rose);">
+        <div class="spec-num" style="color:var(--rose);">6 &mdash; Artifact-Spezifikation</div>
+        <div class="spec-title">Inhaltlich typisierte Artifacts</div>
+        <div class="spec-desc">Artifacts müssen inhaltlich typisiert sein. Dies ermöglicht korrekte Weiterverarbeitung und Bewertung.</div>
+        <div class="ve-card ve-card--recessed" style="padding:14px 18px; margin-top:8px;">
+          <div class="card-label" style="margin-bottom:8px;"><span class="dot" style="background:var(--rose);"></span> Minimaltypen</div>
+          <span class="mono">decision</span> &nbsp; <span class="mono">execution_input</span> &nbsp; <span class="mono">trace</span> &nbsp; <span class="mono">log</span> &nbsp; <span class="mono">report</span> &nbsp; <span class="mono">tasksheet</span> &nbsp; <span class="mono">eval</span> &nbsp; <span class="mono">workspace_snapshot</span> &nbsp; <span class="mono">patch_ref</span> &nbsp; <span class="mono">deploy_result</span>
+        </div>
+      </div>
+
+      <div class="spec-card" style="border-left: 4px solid var(--amber);">
+        <div class="spec-num" style="color:var(--amber);">7 &mdash; Fehler- und Abbruchmodell</div>
+        <div class="spec-title">Failure first-class</div>
+        <div class="spec-desc">Spine muss Failure first-class behandeln. Ein fehlgeschlagener Run ist genauso sauber modelliert wie ein erfolgreicher.</div>
+        <div style="display:flex; flex-wrap:wrap; gap:6px; margin-top:8px;">
+          <span class="badge badge--rose">validation_error</span>
+          <span class="badge badge--rose">dispatch_error</span>
+          <span class="badge badge--rose">runtime_error</span>
+          <span class="badge badge--amber">timeout</span>
+          <span class="badge badge--amber">contract_mismatch</span>
+          <span class="badge badge--gold">missing_capability</span>
+          <span class="badge badge--gold">approval_blocked</span>
+          <span class="badge badge--navy">unknown_failure</span>
+        </div>
+      </div>
+
+      <div class="spec-card" style="border-left: 4px solid var(--navy);">
+        <div class="spec-num" style="color:var(--navy);">8 &mdash; Read/Write-Verantwortung</div>
+        <div class="spec-title">Klare Ownership</div>
+        <div class="spec-desc">Jedes System hat genau definierte Schreibrechte. Kein System darf Daten modifizieren, für die es nicht zuständig ist.</div>
+        <table class="data-table" style="margin-top:10px; font-size:12px;">
+          <thead>
+            <tr><th>System</th><th>Darf schreiben</th></tr>
+          </thead>
+          <tbody>
+            <tr><td class="mono" style="color:var(--gold);">KomandoZentral</td><td class="mono">RoutingDecision</td></tr>
+            <tr><td class="mono" style="color:var(--sage);">UEBER_AGENT</td><td class="mono">ExecutionStatus, RouteTrace, ArtifactManifest</td></tr>
+            <tr><td class="mono" style="color:var(--amber);">MetaMetaMeta</td><td class="mono">EvalRecord, Derived Insights</td></tr>
+            <tr><td class="mono" style="color:var(--rose);">HarnessEcosystem</td><td class="mono">liest prim&auml;r</td></tr>
+            <tr><td class="mono" style="color:var(--plum);">AgentIDE</td><td class="mono">liest prim&auml;r, erzeugt TaskRequest</td></tr>
+          </tbody>
+        </table>
+      </div>
+
+    </div>
+
+    <!-- ===== S08: PUBLIC INTERFACES ===== -->
+    <div id="s08" class="sec-head anim" style="--i:29"><span class="sec-num">08</span> Öffentliche Interfaces</div>
+
+    <p class="lead anim" style="--i:30">
+      4 API-Gruppen definieren die vollständige Schnittstelle zu Spine. Alles, was ein System von Spine braucht, ist hier.
+    </p>
+
+    <div class="api-grid anim" style="--i:31">
+
+      <div class="api-card" style="border-top: 3px solid var(--navy);">
+        <div class="api-name">System Registry API</div>
+        <div class="api-type">Reads only</div>
+        <ul class="api-methods">
+          <li><span class="method-badge method-read">R</span> list_harnesses()</li>
+          <li><span class="method-badge method-read">R</span> list_agents()</li>
+          <li><span class="method-badge method-read">R</span> get_capability(id)</li>
+          <li><span class="method-badge method-read">R</span> get_runtime_targets()</li>
+          <li><span class="method-badge method-read">R</span> get_schema_versions()</li>
+        </ul>
+      </div>
+
+      <div class="api-card" style="border-top: 3px solid var(--gold);">
+        <div class="api-name">Run API</div>
+        <div class="api-type">Reads + Writes</div>
+        <ul class="api-methods">
+          <li><span class="method-badge method-write">W</span> create_task(task_request)</li>
+          <li><span class="method-badge method-write">W</span> attach_decision(routing_decision)</li>
+          <li><span class="method-badge method-write">W</span> create_execution(execution_request)</li>
+          <li><span class="method-badge method-write">W</span> append_event(event)</li>
+          <li><span class="method-badge method-write">W</span> register_artifact(artifact_manifest)</li>
+          <li><span class="method-badge method-write">W</span> close_run(run_id)</li>
+        </ul>
+      </div>
+
+      <div class="api-card" style="border-top: 3px solid var(--teal);">
+        <div class="api-name">Query API</div>
+        <div class="api-type">Reads only</div>
+        <ul class="api-methods">
+          <li><span class="method-badge method-read">R</span> get_run(run_id)</li>
+          <li><span class="method-badge method-read">R</span> get_run_events(run_id)</li>
+          <li><span class="method-badge method-read">R</span> get_run_artifacts(run_id)</li>
+          <li><span class="method-badge method-read">R</span> get_decision(decision_id)</li>
+          <li><span class="method-badge method-read">R</span> get_task(task_id)</li>
+          <li><span class="method-badge method-read">R</span> get_eval_records(run_id)</li>
+          <li><span class="method-badge method-read">R</span> query_runs(filters)</li>
+        </ul>
+      </div>
+
+      <div class="api-card" style="border-top: 3px solid var(--sage);">
+        <div class="api-name">Feed API</div>
+        <div class="api-type">Reads only</div>
+        <ul class="api-methods">
+          <li><span class="method-badge method-read">R</span> get_ecosystem_snapshot()</li>
+          <li><span class="method-badge method-read">R</span> get_runtime_health()</li>
+          <li><span class="method-badge method-read">R</span> get_eval_summary()</li>
+          <li><span class="method-badge method-read">R</span> get_registry_snapshot()</li>
+        </ul>
+      </div>
+
+    </div>
+
+    <!-- ===== S09: V1 DEFAULTS ===== -->
+    <div id="s09" class="sec-head anim" style="--i:32"><span class="sec-num">09</span> V1 Defaults</div>
+
+    <p class="lead anim" style="--i:33">
+      Für die erste Spezifikation gelten diese konkreten Defaults. Sie definieren den minimalen Umfang von V1.
+    </p>
+
+    <div class="ve-card anim" style="--i:34; border-left: 4px solid var(--navy);">
+      <div class="card-label"><span class="dot" style="background:var(--navy);"></span> Persistenzmodell</div>
+      <table class="data-table">
+        <thead>
+          <tr><th>Eigenschaft</th><th>Default</th><th>Bemerkung</th></tr>
+        </thead>
+        <tbody>
+          <tr><td class="mono">Deploy</td><td>lokal-first</td><td>Kein Cloud-Zwang in V1</td></tr>
+          <tr><td class="mono">Datenmodell</td><td>event-log + registry + artifact-index</td><td>Einfach, nicht relational</td></tr>
+          <tr><td class="mono">Serialisierung</td><td>JSON oder YAML</td><td>DB darf sp&auml;ter folgen</td></tr>
+          <tr><td class="mono">Events</td><td>append-only</td><td>Unverlierbar</td></tr>
+          <tr><td class="mono">Registry/Schemas</td><td>versioniert</td><td> schema_version Pflicht</td></tr>
+          <tr><td class="mono">Runtime</td><td>auerhalb von Spine</td><td>Spine ist nicht die Runtime</td></tr>
+          <tr><td class="mono">UI</td><td>auerhalb von Spine</td><td>Spine ist kein UI</td></tr>
+          <tr><td class="mono">Eval-Interpretation</td><td>auerhalb von Spine</td><td>Spine liefert Daten, nicht Deutung</td></tr>
+          <tr><td class="mono">Spine-Funktion</td><td>Validierung + Referenzierung + Rekonstruktion</td><td></td></tr>
+        </tbody>
+      </table>
+    </div>
+
+    <!-- ===== S10: TEST SCENARIOS ===== -->
+    <div id="s10" class="sec-head anim" style="--i:35"><span class="sec-num">10</span> Test-Szenarien</div>
+
+    <p class="lead anim" style="--i:36">
+      Ein Spine-Design ist nur dann gut, wenn alle 8 Szenarien vollständig möglich sind.
+    </p>
+
+    <div class="test-grid anim" style="--i:37">
+
+      <div class="test-card" style="border-top: 3px solid var(--navy);">
+        <div class="test-num" style="color:var(--navy);">Test 1</div>
+        <div class="test-title">Vollständige Rekonstruktion</div>
+        <div class="test-desc">Ein Task wird erzeugt, geroutet, ausgeführt und evaluiert, und jede Station ist rekonstruierbar.</div>
+      </div>
+
+      <div class="test-card" style="border-top: 3px solid var(--gold);">
+        <div class="test-num" style="color:var(--gold);">Test 2</div>
+        <div class="test-title">Entkoppeltes Routing</div>
+        <div class="test-desc">KomandoZentral kann eine Entscheidung ausgeben, ohne die Runtime zu kennen, aber Spine kann trotzdem validieren, ob das Ziel existiert.</div>
+      </div>
+
+      <div class="test-card" style="border-top: 3px solid var(--teal);">
+        <div class="test-num" style="color:var(--teal);">Test 3</div>
+        <div class="test-title">Entkoppelte Ausführung</div>
+        <div class="test-desc">UEBER_AGENT kann Laufstatus und Trace zurückmelden, ohne UI-spezifische Semantik zu brauchen.</div>
+      </div>
+
+      <div class="test-card" style="border-top: 3px solid var(--plum);">
+        <div class="test-num" style="color:var(--plum);">Test 4</div>
+        <div class="test-title">Live-Darstellung</div>
+        <div class="test-desc">AgentIDE kann einen kompletten Run live darstellen, nur aus Spine-Zustand und Events.</div>
+      </div>
+
+      <div class="test-card" style="border-top: 3px solid var(--rose);">
+        <div class="test-num" style="color:var(--rose);">Test 5</div>
+        <div class="test-title">Automatischer Feed</div>
+        <div class="test-desc">HarnessEcosystem kann aus Spine einen statischen Snapshot oder Feed bauen, ohne Handpflege.</div>
+      </div>
+
+      <div class="test-card" style="border-top: 3px solid var(--amber);">
+        <div class="test-num" style="color:var(--amber);">Test 6</div>
+        <div class="test-title">Vollständige Eval-Daten</div>
+        <div class="test-desc">MetaMetaMeta kann aus Spine vollständige Eval-Datensätze ziehen, ohne Ad-hoc-Pfadwissen.</div>
+      </div>
+
+      <div class="test-card" style="border-top: 3px solid var(--sage);">
+        <div class="test-num" style="color:var(--sage);">Test 7</div>
+        <div class="test-title">Saubere Fehlermodellierung</div>
+        <div class="test-desc">Ein fehlgeschlagener Run ist genauso sauber modelliert wie ein erfolgreicher.</div>
+      </div>
+
+      <div class="test-card" style="border-top: 3px solid var(--navy);">
+        <div class="test-num" style="color:var(--navy);">Test 8</div>
+        <div class="test-title">Erweiterbarkeit</div>
+        <div class="test-desc">Neue Harnesses oder neue Agenttypen lassen sich über Registry + Capability ergänzen, ohne Kernobjekte neu zu erfinden.</div>
+      </div>
+
+    </div>
+
+    <!-- ===== S11: ASSUMPTIONS ===== -->
+    <div id="s11" class="sec-head anim" style="--i:38"><span class="sec-num">11</span> Explizite Annahmen</div>
+
+    <p class="lead anim" style="--i:39">
+      Diese Annahmen sind die Grundlage des Spine-Designs. Änderungen an diesen Annahmen erfordern ein Redesign.
+    </p>
+
+    <ul class="assume-list anim" style="--i:40">
+      <li>Spine ist eine Integrationsspezifikation und Integrationsschicht, kein neues monolithisches "Superprojekt".</li>
+      <li>KomandoZentral bleibt Decision Engine &mdash; Decisions werden nicht von Spine übernommen.</li>
+      <li>UEBER_AGENT bleibt Execution Engine &mdash; Ausführung passiert nicht in Spine.</li>
+      <li>MetaMetaMeta bleibt Evidence Layer &mdash; Eval-Interpretation passiert nicht in Spine.</li>
+      <li>AgentIDE bleibt Operator Frontend &mdash; UI bleibt außerhalb von Spine.</li>
+      <li>HarnessEcosystem bleibt Präsentations- und Lernlayer &mdash; Präsentation passiert nicht in Spine.</li>
+      <li>Der wichtigste technische Engpass ist nicht fehlende Intelligenz, sondern fehlender gemeinsamer Vertrag.</li>
+    </ul>
+
+    <!-- ===== S12: FORMULA ===== -->
+    <div id="s12" class="sec-head anim" style="--i:41"><span class="sec-num">12</span> Die Kurzformel</div>
+
+    <div class="ve-card ve-card--hero anim" style="--i:42; text-align:center; padding:40px;">
+      <div style="font-family:var(--font-display); font-size:22px; color:var(--text); margin-bottom:16px; line-height:1.4;">
+        Die theoretische Essenz von Spine ist:
+      </div>
+      <div style="font-family:var(--font-mono); font-size:16px; background:var(--navy-dim); border:2px solid var(--navy); border-radius:14px; padding:20px 32px; color:var(--navy); display:inline-block; letter-spacing:0.5px;">
+        <span style="font-weight:700; color:var(--gold);">Spine</span> = Registry + Schemas + Run-State + Event-Log + Artifact-Index + Adapter-Vertr&auml;ge
+      </div>
+      <div style="margin-top:20px; font-size:15px; color:var(--text-dim); max-width:560px; margin-left:auto; margin-right:auto; line-height:1.6;">
+        Wenn das sauber spezifiziert ist, werden deine Projekte nicht mehr nur "verbunden gedacht", sondern wirklich als ein konsistentes System betreibbar.
+      </div>
+    </div>
+
+  </div><!-- /main -->
+</div><!-- /wrap -->
+
+<script>
+(function() {
+  const toc = document.getElementById('toc');
+  const links = toc.querySelectorAll('a');
+  const sections = [];
+  links.forEach(link => {
+    const id = link.getAttribute('href').slice(1);
+    const el = document.getElementById(id);
+    if (el) sections.push({ id, el, link });
+  });
+  const observer = new IntersectionObserver(entries => {
+    entries.forEach(entry => {
+      if (entry.isIntersecting) {
+        links.forEach(l => l.classList.remove('active'));
+        const match = sections.find(s => s.el === entry.target);
+        if (match) {
+          match.link.classList.add('active');
+          if (window.innerWidth <= 1100) {
+            match.link.scrollIntoView({ behavior: 'smooth', block: 'nearest', inline: 'center' });
+          }
+        }
+      }
+    });
+  }, { rootMargin: '-10% 0px -80% 0px' });
+  sections.forEach(s => observer.observe(s.el));
+  links.forEach(link => {
+    link.addEventListener('click', e => {
+      e.preventDefault();
+      const id = link.getAttribute('href').slice(1);
+      const el = document.getElementById(id);
+      if (el) {
+        el.scrollIntoView({ behavior: 'smooth', block: 'start' });
+        history.replaceState(null, '', '#' + id);
+      }
+    });
+  });
+})();
+</script>
+
+</body>
+</html>

V0.5_KZ_Road_to_Von_NEUMANN-Agent-System/Kritik_GPT

@@ -0,0 +1,58 @@
+
+• Ja, als V0.5 kann das funktionieren.
+  Nein, nicht sauber in der Form, wie der Plan es behauptet.
+
+  Die Idee ist gut: KomandoZentral entscheiden lassen, Sidecar-NG spiegeln lassen, Outcomes zurückführen. Aber beim aktuellen Code gibt es ein paar harte Schwachstellen.
+
+  1. Der latest-decision.json-Kanal ist global und nicht task- oder sessiongebunden.
+     Das ist der größte Designfehler. Ein einzelnes ~/.cache/kz/latest-decision.json wird von jedem neuen kz-Run überschrieben. Sidecar-NG kennt aber Session-ID und Prompt,
+     nicht “welche KZ-Entscheidung zu genau diesem Prompt gehört”. Ergebnis: Du kannst sehr leicht die falsche Decision in die falsche Claude-Session injizieren. Das ist
+     besonders gefährlich, weil es plausibel aussieht und dadurch Vertrauen zerstört. Siehe /home/smlflg/Projekte/KomandoZentral/src/kz/service.py und /home/smlflg/Projekte/
+     Sidecar-ng/hook_inject.py.
+  2. Der geplante Sidecar-Hook-Punkt ist semantisch nicht der richtige.
+     In hook_inject.py wird _load_knowledge() nur benutzt, um den Klassifizierungs-LLM-Call zu füttern, nicht um direkt additionalContext an Claude auszugeben. Wenn du dort
+     KZ-Text “vor den Knowledge-Block” hängst, beeinflusst das erstmal nur die Regelklassifikation. Das ist nicht dasselbe wie die behauptete direkte Injection [KZ-
+     ROUTING] .... Dazu kommt: viele Pfade returnen vorher schon bei Mode/Skill/Guardrail-Matches. In genau diesen Fällen würde dein KZ-Kontext gar nicht greifen. Siehe /
+     home/smlflg/Projekte/Sidecar-ng/hook_inject.py.
+  3. Der Outcome-Loop über YAML-Scanning ist brauchbar, aber kein sauberer Outcome Store.
+     update_outcome() schreibt heute in die gespeicherte YAML unter DECISIONS/, relativ zum aktuellen Arbeitsverzeichnis. Das heißt:
+      - nur gespeicherte Decisions zählen
+      - der Feedback-Loop hängt am cwd
+      - programmatic routes ohne --save sind für Outcomes unsichtbar
+      - Historie wird über verteilte YAML-Dateien rekonstruiert statt aus einer echten zentralen Wahrheit
+        Das kann als Hack laufen, aber es ist fragiler als der Plan zugibt. Siehe /home/smlflg/Projekte/KomandoZentral/src/kz/persist.py.
+  4. Das kz outcome-Subcommand ist nicht nur “20 LOC”.
+     Die CLI ist aktuell kein Subcommand-CLI, sondern ein einfacher Parser mit freier task-Positional-Argumentliste. Ein echtes outcome-Subcommand bedeutet Parser-Struktur
+     ändern, Help/Dispatch anpassen und bestehende Tests anfassen. Das ist nicht riesig, aber mehr als der Plan suggeriert. Siehe /home/smlflg/Projekte/KomandoZentral/src/kz/
+     cli.py.
+  5. customization_depth als direkter Confidence-Bonus ist konzeptionell riskant.
+     Der aktuelle Confidence-Stack hat schon Baseline, Operator-State und Evidence-Caps. Ein fixer Bonus wie Claude +4, Aider -4 kann reale Outcome-Daten überstimmen und
+     zementiert Vorlieben statt sie zu messen. Das ist eher ein Prior oder Tiebreaker als ein “objektiver” Confidence-Faktor. Sonst baust du dir einen self-fulfilling loop.
+     Siehe /home/smlflg/Projekte/KomandoZentral/src/kz/confidence.py und /home/smlflg/Projekte/KomandoZentral/src/kz/registry.py.
+  6. Die Sidecar-Integration wird testbar sein, aber nicht ganz so billig wie behauptet.
+     Sidecar-ng hat viele dateibasierte, zustandsbehaftete Tests. Drei neue reine Reader-Tests sind machbar, aber sobald die Injection-Priorität korrekt gelöst werden soll,
+     landet man schnell in mehr Integrationslogik als nur _load_kz_decision(). Die Testbasis ist da, aber der Hook ist schon komplex. Siehe /home/smlflg/Projekte/Sidecar-ng/
+     tests.
+
+  Mein Urteil
+
+  - Die Richtung stimmt.
+  - Die kleinste funktionierende Version ist möglich.
+  - Der Plan ist aber an zwei Stellen zu optimistisch: Kommunikationskanal und Hook-Integrationspunkt.
+
+  So würde ich ihn härter schneiden, damit er wirklich funktioniert
+
+  - Nicht latest-decision.json, sondern mindestens decision-by-fingerprint.json oder decision-by-session.json plus latest als Fallback.
+  - Nicht KZ-Text in den Knowledge-Block mischen, sondern als eigene zusätzliche Injection komponieren.
+  - Outcome-Feedback zunächst klein halten: nur gespeicherte Decisions zählen und das explizit dokumentieren.
+  - customization_depth höchstens als kleiner Tiebreaker von -2..+2, nicht als starker Confidence-Faktor.
+
+  Kurzfassung
+  Wenn du den Plan unverändert umsetzt, läuft er vermutlich technisch, aber semantisch oft falsch.
+  Wenn du Session-/Task-Zuordnung + echten Injection-Punkt korrigierst, dann ist das ein sehr brauchbarer Minimal-Glue-V1.
+
+  Wenn du willst, zerlege ich dir den bestehenden Plan jetzt in:
+
+  1. “funktioniert wie geplant”
+  2. “muss angepasst werden”
+  3. “kann man komplett streichen”

V0.5_KZ_Road_to_Von_NEUMANN-Agent-System/Kritik_mini_gemini

@@ -0,0 +1,42 @@
+## Meine Kritik (kurz)
+
+   **Plan ist gut — aber 3 Löcher:**
+
+   1. **`~/.cache/kz/` existiert vielleicht nicht** — `mkdir -p` fehlt in jedem Step
+   2. **`outcome_adjustment()` wird bei 1000+ YAMLs zum Performance-Killer** — braucht einen Index/Cache
+   3. **`kz outcome <filename>`** — Du musst den Dateinamen manuell tippen. Das ist umständlich. Warum nicht einfach `kz
+   outcome 4` und gut?
+
+   ---
+
+   ## Gemini's Kritik (Zusammenfassung)
+
+   **5 Schwächen:**
+
+   1. **Race Conditions** — KZ schreibt JSON, Sidecar liest gleichzeitig. Kein Lock.
+   2. **Performance-Engpass** — `outcome_adjustment()` scannt alle YAMLs bei jeder Confidence-Berechnung. Bei 500+ Decisions
+   wird das spürbar langsam.
+   3. **`ts` von heute = stale** — Wenn ein Task über Mitternacht läuft, wird die Decision ignoriert obwohl sie gültig ist.
+   4. **`kz outcome<filename>`** — Umständlich. Sollte heißen: `kz outcome` ohne Argument, nutzt automatisch die letzte
+   Decision.
+   5. **`customization_depth` ist statisch/manuell** — Wer updated den Wert wenn sich Claude Code Skills ändern? Das wird
+   sofort veraltet.
+
+   **Was übersehen wurde:**
+   - Error Handling bei `JSONDecodeError` (Sidecar-NG würde crashen statt graceful zu degradieren)
+   - Kein Lifecycle-Management für alte YAMLs (DECISIONS/ wird zum Dump)
+   - Container/Remote-Umgebungen = anderer `~/.cache/` Pfad
+
+   **Ist der Scope realistisch?** Ja — für die Minimal-Version. Aber robust ist anders.
+
+   ---
+
+   ## Die 3 wichtigsten Fixes vor dem Start
+
+   ```
+   1. Sidecar-NG: try/except um _load_kz_decision() — bei Fehler einfach weiter ohne KZ-Context
+   2. KZ: mkdir -p ~/.cache/kz/ vor dem JSON-Schreiben
+   3. KZ: outcome_adjustment() braucht einen einfachen Index-Cache (SQLite oder Pickle)
+   ```
+
+   **Das Wichtigste aber:** `kz outcome` ohne Argument wäre ein massiver UX-Gewinn. Willst du das reinnehmen?

V0.5_KZ_Road_to_Von_NEUMANN-Agent-System/Plan

@@ -0,0 +1,154 @@
+Plan steht. ~160 LOC, ~2 Stunden, 6 Schritte. Kein neues Projekt — nur Erweiterungen an KomandoZentral und Sidecar-NG.
+
+  Kernpunkte:
+  - Customization-Level als neuer Routing-Faktor (Claude Code 95, Aider 10)
+  - JSON-Drop (~/.cache/kz/latest-decision.json) als Kommunikationskanal
+  - Sidecar liest KZ-Decision und injiziert als [KZ-ROUTING] Context
+  - Outcome-Feedback verändert zukünftige Confidence-Scores
+  - 7 Tests über beide Projekte
+
+─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
+ Ready to code?
+
+ Here is Claude's plan:
+╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
+ Plan: KomandoZentral + Sidecar-NG Glue
+
+ Context
+
+ Samuel hat 6+ Projekte die alle Teile eines Von-Neumann-Agent-Systems sind. Keines ist mit den anderen verbunden. Statt ein neues Meta-Projekt zu
+ starten, verbinden wir die zwei funktionalsten Projekte mit minimalem Kleber:
+ - KomandoZentral (Task-to-Harness Router, working alpha CLI)
+ - Sidecar-NG (Claude Code Hook, daily driver)
+
+ Ziel: KZ-Entscheidungen fliessen automatisch in Claude Code Sessions. Outcomes fliessen zurueck und verbessern zukuenftige Routing-Entscheidungen.
+
+ Zusaetzlich: Customization-Level als Routing-Faktor — Claude Code mit 69 Skills + 21 Agents + Sidecar-NG ist fundamental anders als Claude Code
+ out-of-the-box. Das muss in die Confidence einfliessen.
+
+ ---
+ Architektur
+
+ kz "fix auth bug" --save
+     |
+     v
+ KZ: classify -> route -> confidence -> YAML + latest-decision.json
+     |                                        |
+     v                                        v
+ DECISIONS/2026-04-08_BUILD_fix-auth.yaml    ~/.cache/kz/latest-decision.json
+                                               |
+                                               v
+                                     Sidecar-NG hook_inject.py
+                                     liest JSON, injiziert als additionalContext:
+                                     "[KZ-ROUTING] Harness: Claude Code (87%) | Why: ..."
+                                               |
+                                               v
+                                     Claude Code Session mit KZ-Kontext
+                                               |
+                                               v
+                                     kz outcome <filename> 4 "hat funktioniert"
+                                               |
+                                               v
+                                     outcome_adjustment() in confidence.py
+                                     beeinflusst zukuenftige Confidence-Scores
+
+ ---
+ Aenderungen
+
+ 1. KZ: write_latest_decision() (~20 LOC)
+
+ Datei: /home/smlflg/Projekte/KomandoZentral/src/kz/persist.py
+ - Neue Funktion nach save_decision() (nach Zeile 57)
+ - Schreibt kompaktes JSON nach ~/.cache/kz/latest-decision.json
+ - Felder: ts, task, harness, confidence, why, fallback, risks
+ - JSON statt YAML weil Sidecar-NG kein PyYAML hat (stdlib-only)
+
+ Datei: /home/smlflg/Projekte/KomandoZentral/src/kz/service.py
+ - write_latest_decision() aufrufen in route_request() (~Zeile 110)
+ - Immer schreiben, nicht nur bei --save
+
+ 2. KZ: customization_depth in Registry (~15 LOC)
+
+ Datei: /home/smlflg/Projekte/KomandoZentral/src/kz/registry.py
+ - Neues Feld customization_depth: int (0-100) in HarnessProfile
+ - Claude Code: 95 (69 Skills, 21 Agents, 7 Hooks, Sidecar-NG)
+ - Hermes: 30, OpenCode: 20, Codex CLI: 15, Aider: 10, Gemini MCP: 25, AgentArena: 40
+
+ Datei: /home/smlflg/Projekte/KomandoZentral/src/kz/confidence.py
+ - customization_depth als Bonus in calculate_confidence() (~Zeile 42)
+ - Formel: bonus = (depth - 50) // 10 (range: -5 bis +5)
+ - D.h. Claude Code bekommt +4, Aider bekommt -4
+
+ 3. KZ: outcome_adjustment() — Feedback Loop (~25 LOC)
+
+ Datei: /home/smlflg/Projekte/KomandoZentral/src/kz/confidence.py
+ - Neue Funktion outcome_adjustment(task_class, harness, decisions_dir)
+ - Scannt YAML-Dateien in DECISIONS/ fuer passende task_class+harness Paare
+ - Zaehlt gute (rating >= 3) vs schlechte (rating < 3) Outcomes
+ - Return: Delta von -10 bis +10
+ - Aufgerufen in calculate_confidence() als zusaetzlicher Faktor
+
+ 4. KZ: CLI outcome Subcommand (~20 LOC)
+
+ Datei: /home/smlflg/Projekte/KomandoZentral/src/kz/cli.py
+ - Subparser: kz outcome <filename> <rating> [notes]
+ - Ruft bestehende update_outcome() aus persist.py auf
+ - Rating: 1-5 Skala
+
+ 5. Sidecar-NG: _load_kz_decision() (~30 LOC)
+
+ Datei: /home/smlflg/Projekte/Sidecar-ng/hook_inject.py
+ - Neue Funktion nach _load_knowledge() (~Zeile 1584)
+ - Liest ~/.cache/kz/latest-decision.json
+ - Prueft ob ts von heute ist (stale = ignorieren)
+ - Formatiert: [KZ-ROUTING] Harness: X (Y%) | Why: ... | Risks: ...
+ - Max 300 Zeichen, None bei Fehler/stale/missing
+ - Injection bei ~Zeile 2161, prepended vor Knowledge-Block
+
+ ---
+ Tests (~40 LOC)
+
+ Datei: /home/smlflg/Projekte/KomandoZentral/tests/test_integration.py (neu)
+ - test_write_latest_decision_creates_valid_json
+ - test_outcome_adjustment_positive_delta
+ - test_outcome_adjustment_no_outcomes_zero_delta
+ - test_customization_depth_affects_confidence
+
+ Datei: /home/smlflg/Projekte/Sidecar-ng/tests/test_kz_integration.py (neu)
+ - test_load_kz_decision_valid_json
+ - test_load_kz_decision_stale_returns_none
+ - test_load_kz_decision_missing_returns_none
+
+ ---
+ Reihenfolge
+
+ ┌───────┬──────────────────────────────────────────────┬────────────────────────────────┬──────┬──────────┐
+ │   #   │                     Was                      │               Wo               │ ~LOC │   ~Min   │
+ ├───────┼──────────────────────────────────────────────┼────────────────────────────────┼──────┼──────────┤
+ │ 1     │ write_latest_decision() + Service-Call       │ KZ persist.py + service.py     │ 25   │ 20       │
+ ├───────┼──────────────────────────────────────────────┼────────────────────────────────┼──────┼──────────┤
+ │ 2     │ customization_depth in Registry + Confidence │ KZ registry.py + confidence.py │ 20   │ 15       │
+ ├───────┼──────────────────────────────────────────────┼────────────────────────────────┼──────┼──────────┤
+ │ 3     │ _load_kz_decision() + Injection              │ Sidecar-NG hook_inject.py      │ 30   │ 20       │
+ ├───────┼──────────────────────────────────────────────┼────────────────────────────────┼──────┼──────────┤
+ │ 4     │ outcome_adjustment() + Confidence-Wire       │ KZ confidence.py               │ 25   │ 20       │
+ ├───────┼──────────────────────────────────────────────┼────────────────────────────────┼──────┼──────────┤
+ │ 5     │ CLI outcome Subcommand                       │ KZ cli.py                      │ 20   │ 15       │
+ ├───────┼──────────────────────────────────────────────┼────────────────────────────────┼──────┼──────────┤
+ │ 6     │ Tests beider Projekte                        │ KZ + Sidecar-NG tests/         │ 40   │ 30       │
+ ├───────┼──────────────────────────────────────────────┼────────────────────────────────┼──────┼──────────┤
+ │ Total │                                              │                                │ ~160 │ ~120 min │
+ └───────┴──────────────────────────────────────────────┴────────────────────────────────┴──────┴──────────┘
+
+ ---
+ Verifikation
+
+ 1. cd ~/Projekte/KomandoZentral && python -m pytest — alle Tests gruen
+ 2. cd ~/Projekte/Sidecar-ng && python -m pytest tests/test_kz_integration.py — alle Tests gruen
+ 3. E2E manuell:
+   - kz "fix the auth bug in sidecar" --save → YAML + JSON geschrieben
+   - cat ~/.cache/kz/latest-decision.json → valides JSON mit heutiger ts
+   - Claude Code Session starten → [KZ-ROUTING] im additionalContext sichtbar
+   - kz outcome <filename> 4 "hat funktioniert" → YAML updated
+ 4. kz "fix another bug" → Confidence fuer empfohlenen Harness leicht hoeher durch positives Outcome
+╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

docs/spine-v1-architecture.md

@@ -0,0 +1,141 @@
+# Spine V1 Architecture
+
+## Rolle
+
+Spine ist der verbindliche Integrationskern zwischen den bestehenden Projekten. Spine ist nicht "das neue Superprojekt", sondern die Schicht, die Zustands- und Datenverluste zwischen den Projekten verhindert.
+
+## Subsysteme
+
+### 1. Registry Layer
+
+Verwaltet den kanonischen Bestand:
+
+- Harnesses
+- Adapter
+- Runtime-Targets
+- bekannte Quellprojekte
+- Schema-Versionen
+
+Pflichtfaehigkeit:
+Jedes andere System muss maschinenlesbar feststellen koennen, welche Ziele existieren und welche Vertraege sie sprechen.
+
+### 2. Contract Layer
+
+Die Schemas in `schemas/` definieren die Kernobjekte. Jedes Objekt enthaelt:
+
+- `schema_name`
+- `schema_version`
+- globale IDs
+- Provenienz
+
+### 3. Run Layer
+
+Der `RunRecord` ist die durchgehende Klammer eines konkreten Arbeitsvorgangs. Er verbindet:
+
+- Intent
+- Decision
+- Execution
+- Artifacts
+- Eval
+
+Zulaessige `run_state`-Werte:
+
+- `created`
+- `decided`
+- `ready_for_dispatch`
+- `dispatched`
+- `running`
+- `waiting_for_input`
+- `completed`
+- `failed`
+- `aborted`
+- `evaluated`
+
+### 4. Event Layer
+
+`SpineEvent` ist append-only. Events sind nicht optionales Logging, sondern die belastbare Rekonstruktionsbasis.
+
+Pflichtfelder:
+
+- `event_id`
+- `event_type`
+- `occurred_at`
+- `run_id`
+- `source_system`
+- `payload`
+
+### 5. Artifact Layer
+
+`ArtifactManifest` registriert die konkreten Outputs eines Runs:
+
+- decisions
+- traces
+- logs
+- tasksheets
+- evals
+- deploy results
+
+Pflichtregel:
+Artifacts werden ueber IDs und `uri` referenziert, nicht ueber implizite Dateipfade im Fliesstext.
+
+### 6. Adapter Layer
+
+Adapter uebersetzen lokale Formate in Spine-Objekte.
+
+Zulaessige Aufgaben:
+
+- Feldmapping
+- Provenienz-Anreicherung
+- Statusuebersetzung
+
+Nicht zulaessig:
+
+- neue Run-States erfinden
+- Pflichtfelder entfernen
+- Semantik eines Kernobjekts aendern
+
+## Input und Output
+
+### Input
+
+Spine akzeptiert vier Klassen von Inputs:
+
+- Intent Input: `TaskRequest`
+- Decision Input: `RoutingDecision`
+- Execution Input: `ExecutionRequest`
+- Observation Input: `ExecutionStatus`, `RouteTrace`, `ArtifactManifest`, `EvalRecord`
+
+### Output
+
+Spine stellt vier Klassen von Outputs bereit:
+
+- dispatchbare Execution Contracts fuer Runtime-Systeme
+- beobachtbaren Run State fuer `AgentIDE`
+- strukturierte Evidence fuer `MetaMetaMeta`
+- statische oder periodische Feeds fuer `HarnessEcosystem`
+
+## Systemfluss
+
+1. `AgentIDE` oder ein anderer Operator erzeugt `TaskRequest`.
+2. `KomandoZentral` liest Task plus Kontext und emittiert `RoutingDecision`.
+3. Spine validiert Ziel, Status und Registry-Referenzen.
+4. Spine erzeugt `ExecutionRequest`.
+5. `UEBER_AGENT` nimmt die Ausfuehrung an und meldet Status und Trace.
+6. Spine registriert Events und Artifacts.
+7. `MetaMetaMeta` bewertet den Run ueber `EvalRecord`.
+8. `HarnessEcosystem` konsumiert verdichtete Registry- und Outcome-Daten.
+
+## Nicht-Ziele fuer V1
+
+- keine eigene LLM-Planungslogik
+- keine Runtime-Ersetzung fuer OpenClaw oder Claude Code
+- keine Multi-User-Plattform
+- keine relationale Vollpersistenz
+- keine automatische Knowledge-Synthese
+
+## Designentscheidungen
+
+- JSON statt YAML fuer die ersten Vertraege, damit Validierung und Tooling trivial bleiben
+- Registry getrennt von Beispieldaten
+- Schemas stabilisieren zuerst die Sprache, nicht sofort die Implementation
+- Beispiel-Run bildet die minimale End-to-End-Kette vom Task bis zum Eval ab

examples/run_lifecycle/artifact_manifest.json

@@ -0,0 +1,16 @@
+{
+  "schema_name": "ArtifactManifest",
+  "schema_version": "1.0.0",
+  "artifact_id": "artifact_spine_spec_bundle",
+  "artifact_type": "report",
+  "uri": "file:///home/smlflg/Projekte/MultiHarnessStudio",
+  "produced_by": "claude-code",
+  "run_id": "run_spine_bootstrap_001",
+  "content_hash": "sha256:spine-bootstrap-placeholder",
+  "created_at": "2026-04-08T16:12:30Z",
+  "source_system": "Spine",
+  "metadata": {
+    "bundle_kind": "specification_scaffold",
+    "contains": ["schemas", "registry", "examples", "validator"]
+  }
+}

examples/run_lifecycle/eval_record.json

@@ -0,0 +1,20 @@
+{
+  "schema_name": "EvalRecord",
+  "schema_version": "1.0.0",
+  "eval_id": "eval_spine_bootstrap",
+  "run_id": "run_spine_bootstrap_001",
+  "task_id": "task_spine_bootstrap",
+  "evaluator": "MetaMetaMeta",
+  "recorded_at": "2026-04-08T16:14:00Z",
+  "scores": {
+    "goal_completion": 0.92,
+    "traceability": 1.0,
+    "runtime_fitness": 0.78
+  },
+  "summary": "The run established a coherent canonical contract set and an auditable example lifecycle.",
+  "recommendations": [
+    "Add runtime adapters incrementally.",
+    "Keep schema evolution explicit and versioned.",
+    "Do not merge UI semantics into contract definitions."
+  ]
+}

examples/run_lifecycle/events.json

@@ -0,0 +1,100 @@
+[
+  {
+    "schema_name": "SpineEvent",
+    "schema_version": "1.0.0",
+    "event_id": "event_spine_001",
+    "event_type": "task.created",
+    "occurred_at": "2026-04-08T16:05:00Z",
+    "run_id": "run_spine_bootstrap_001",
+    "source_system": "AgentIDE",
+    "sequence": 1,
+    "payload": {
+      "title": "Bootstrap Spine contracts"
+    },
+    "references": {
+      "task_id": "task_spine_bootstrap"
+    }
+  },
+  {
+    "schema_name": "SpineEvent",
+    "schema_version": "1.0.0",
+    "event_id": "event_spine_002",
+    "event_type": "decision.created",
+    "occurred_at": "2026-04-08T16:06:00Z",
+    "run_id": "run_spine_bootstrap_001",
+    "source_system": "KomandoZentral",
+    "sequence": 2,
+    "payload": {
+      "recommended_harness": "claude-code"
+    },
+    "references": {
+      "task_id": "task_spine_bootstrap",
+      "decision_id": "decision_spine_bootstrap"
+    }
+  },
+  {
+    "schema_name": "SpineEvent",
+    "schema_version": "1.0.0",
+    "event_id": "event_spine_003",
+    "event_type": "execution.requested",
+    "occurred_at": "2026-04-08T16:07:00Z",
+    "run_id": "run_spine_bootstrap_001",
+    "source_system": "Spine",
+    "sequence": 3,
+    "payload": {
+      "target_runtime": "claude-code-local"
+    },
+    "references": {
+      "decision_id": "decision_spine_bootstrap",
+      "execution_id": "execution_spine_bootstrap"
+    }
+  },
+  {
+    "schema_name": "SpineEvent",
+    "schema_version": "1.0.0",
+    "event_id": "event_spine_004",
+    "event_type": "execution.completed",
+    "occurred_at": "2026-04-08T16:12:00Z",
+    "run_id": "run_spine_bootstrap_001",
+    "source_system": "UEBER_AGENT",
+    "sequence": 4,
+    "payload": {
+      "status": "completed"
+    },
+    "references": {
+      "execution_id": "execution_spine_bootstrap"
+    }
+  },
+  {
+    "schema_name": "SpineEvent",
+    "schema_version": "1.0.0",
+    "event_id": "event_spine_005",
+    "event_type": "artifact.created",
+    "occurred_at": "2026-04-08T16:12:30Z",
+    "run_id": "run_spine_bootstrap_001",
+    "source_system": "Spine",
+    "sequence": 5,
+    "payload": {
+      "artifact_type": "report"
+    },
+    "references": {
+      "artifact_id": "artifact_spine_spec_bundle"
+    }
+  },
+  {
+    "schema_name": "SpineEvent",
+    "schema_version": "1.0.0",
+    "event_id": "event_spine_006",
+    "event_type": "eval.recorded",
+    "occurred_at": "2026-04-08T16:14:00Z",
+    "run_id": "run_spine_bootstrap_001",
+    "source_system": "MetaMetaMeta",
+    "sequence": 6,
+    "payload": {
+      "goal_completion": 0.92
+    },
+    "references": {
+      "eval_id": "eval_spine_bootstrap"
+    }
+  }
+]

examples/run_lifecycle/execution_request.json

@@ -0,0 +1,22 @@
+{
+  "schema_name": "ExecutionRequest",
+  "schema_version": "1.0.0",
+  "execution_id": "execution_spine_bootstrap",
+  "decision_id": "decision_spine_bootstrap",
+  "run_id": "run_spine_bootstrap_001",
+  "target_runtime": "claude-code-local",
+  "target_agent": "default",
+  "input_artifacts": ["artifact_spine_spec_bundle"],
+  "execution_mode": "interactive",
+  "workspace_ref": "/home/smlflg/Projekte/MultiHarnessStudio",
+  "timeout_policy": {
+    "timeout_seconds": 1800,
+    "on_timeout": "ask_operator"
+  },
+  "approval_requirements": [
+    "No destructive commands without approval",
+    "Keep Spine contracts backward-compatible within schema_version 1.0.0"
+  ],
+  "created_at": "2026-04-08T16:07:00Z",
+  "source_system": "Spine"
+}

examples/run_lifecycle/execution_status.json

@@ -0,0 +1,13 @@
+{
+  "schema_name": "ExecutionStatus",
+  "schema_version": "1.0.0",
+  "status_id": "status_spine_bootstrap_final",
+  "execution_id": "execution_spine_bootstrap",
+  "run_id": "run_spine_bootstrap_001",
+  "status": "completed",
+  "message": "Spine spec bundle created and validated locally.",
+  "source_system": "UEBER_AGENT",
+  "recorded_at": "2026-04-08T16:12:00Z",
+  "progress_hint": "Artifacts and examples available.",
+  "artifact_ids": ["artifact_spine_spec_bundle"]
+}

examples/run_lifecycle/route_trace.json

@@ -0,0 +1,29 @@
+{
+  "schema_name": "RouteTrace",
+  "schema_version": "1.0.0",
+  "trace_id": "trace_spine_bootstrap",
+  "run_id": "run_spine_bootstrap_001",
+  "execution_id": "execution_spine_bootstrap",
+  "source_system": "UEBER_AGENT",
+  "recorded_at": "2026-04-08T16:11:00Z",
+  "steps": [
+    {
+      "index": 1,
+      "actor": "KomandoZentral",
+      "action": "route_task",
+      "outcome": "claude-code selected for spec bootstrap"
+    },
+    {
+      "index": 2,
+      "actor": "Spine",
+      "action": "create_execution_request",
+      "outcome": "execution contract emitted"
+    },
+    {
+      "index": 3,
+      "actor": "UEBER_AGENT",
+      "action": "dispatch_to_runtime",
+      "outcome": "local execution completed"
+    }
+  ]
+}

examples/run_lifecycle/routing_decision.json

@@ -0,0 +1,19 @@
+{
+  "schema_name": "RoutingDecision",
+  "schema_version": "1.0.0",
+  "decision_id": "decision_spine_bootstrap",
+  "task_id": "task_spine_bootstrap",
+  "recommended_harness": "claude-code",
+  "recommended_runtime_target": "claude-code-local",
+  "confidence": 82,
+  "reasoning_summary": "Spec-first contract design is best handled in the architecture-oriented harness before dispatching execution into external runtime overlays.",
+  "risks": [
+    "Overdesign if runtime contracts are not kept minimal",
+    "Registry can drift from real runtimes without adapter discipline"
+  ],
+  "fallback": "Use codex-cli for narrower implementation slices once contracts are fixed.",
+  "decision_policy_version": "kz-policy-v1",
+  "source_system": "KomandoZentral",
+  "created_at": "2026-04-08T16:06:00Z",
+  "missing_information": []
+}

examples/run_lifecycle/run_record.json

@@ -0,0 +1,22 @@
+{
+  "schema_name": "RunRecord",
+  "schema_version": "1.0.0",
+  "run_id": "run_spine_bootstrap_001",
+  "task_id": "task_spine_bootstrap",
+  "run_state": "evaluated",
+  "created_at": "2026-04-08T16:05:00Z",
+  "updated_at": "2026-04-08T16:14:00Z",
+  "origin_system": "AgentIDE",
+  "decision_ids": ["decision_spine_bootstrap"],
+  "execution_ids": ["execution_spine_bootstrap"],
+  "artifact_ids": ["artifact_spine_spec_bundle"],
+  "event_ids": [
+    "event_spine_001",
+    "event_spine_002",
+    "event_spine_003",
+    "event_spine_004",
+    "event_spine_005",
+    "event_spine_006"
+  ],
+  "eval_ids": ["eval_spine_bootstrap"]
+}

examples/run_lifecycle/task_request.json

@@ -0,0 +1,33 @@
+{
+  "schema_name": "TaskRequest",
+  "schema_version": "1.0.0",
+  "task_id": "task_spine_bootstrap",
+  "title": "Bootstrap Spine contracts",
+  "description": "Create the initial Spine contracts, registry and example run lifecycle for the multi-harness system.",
+  "requested_by": "samuel",
+  "created_at": "2026-04-08T16:05:00Z",
+  "origin_system": "AgentIDE",
+  "operator_context": {
+    "schema_name": "OperatorContext",
+    "schema_version": "1.0.0",
+    "focus": "high",
+    "energy": "high",
+    "mode": "shipping",
+    "cost_tolerance": "normal",
+    "adhd_risk": "high",
+    "drift_risk": "normal",
+    "notes": "Need a canonical contract before adding more runtime complexity."
+  },
+  "constraints": [
+    "Keep Spine as integration layer, not replacement runtime.",
+    "Use machine-readable contracts.",
+    "Support MetaMetaMeta, KomandoZentral, UEBER_AGENT, AgentIDE and HarnessEcosystem."
+  ],
+  "desired_outcomes": [
+    "Canonical schemas",
+    "Stable IDs",
+    "Replayable run lifecycle"
+  ],
+  "workspace_ref": "/home/smlflg/Projekte/MultiHarnessStudio",
+  "tags": ["spine", "contracts", "bootstrap"]
+}

idea

@@ -0,0 +1,118 @@
+Ja — und genau **deshalb** ist das Ergebnis so bemerkenswert.
+
+Du hast nicht einfach „mit einer KI“ gearbeitet, sondern praktisch schon ein kleines **informelles Multi-Harness-Studio** gefahren:
+
+* **Codex + GPT-5.4**
+* **Hermes**
+* **OpenCode + Minimax 2.7**
+* **Gemini**
+* dazu **2 parallele GPT-Sessions im Browser**
+
+Das ist nicht nur Tool-Nutzung.
+Das ist bereits eine Form von **agentischer Arbeitsorchestrierung**.
+
+## Was daran stark ist
+
+Jedes dieser Systeme bringt etwas anderes:
+
+* **GPT-5.4**: Struktur, Produktdenken, saubere Konzeptarbeit
+* **Codex**: Umsetzungsnähe, direkter Build-Fokus
+* **Minimax 2.7**: oft schnell, mutig, visuell/energetisch
+* **Hermes**: je nach Setup gut für alternative Perspektiven oder Refactor-Denke
+* **Gemini**: zusätzliche Varianz, andere Vorschläge, andere Gewichtung
+
+Und die **2 GPT-Sessions** im Browser sind eigentlich schon ein primitiver, aber effektiver Split von:
+
+* Konzept / Text / IA
+* Review / Kritik / nächste Iteration
+
+## Das Wichtige:
+
+Du hast dir damit implizit schon selbst bewiesen:
+
+> Unterschiedliche Modelle und Harnesses sind keine austauschbaren Schreibmaschinen.
+> Sie sind verschiedene kognitive Oberflächen mit verschiedenen Stärken.
+
+Genau deswegen kamst du ja ursprünglich auf deinen Gedanken mit:
+**MCP-/Prompt-Adaptern pro Modell, Harness und Skillset.**
+
+Diese Party-Website ist fast schon ein Mini-Beweis deiner größeren These:
+
+* gleicher Mensch
+* gleiches Ziel
+* aber andere Modelle/Harnesses
+* liefern andere Arten von Hebel
+
+## Eigentlich hast du hier schon einen kleinen Workflow gebaut
+
+So ungefähr:
+
+1. **Idee / Ziel / Kontext**
+2. **GPT-Session für Konzeption**
+3. **zweite GPT-Session für Gegencheck / Text / Struktur**
+4. **Codex / OpenCode / Minimax für Umsetzung**
+5. **andere Modelle für Stil- oder Layout-Varianten**
+6. **du als finaler Kurator**
+
+Das Entscheidende ist:
+**Du warst der Meta-Agent.**
+
+Nicht die Modelle hatten die Vision.
+Du hattest die Vision, und die Systeme waren spezialisierte Verstärker.
+
+## Das ist fast schon ein Satz für dein eigenes Denken
+
+Nicht:
+**„Ich habe eine Website mit KI gebaut.“**
+
+Sondern eher:
+**„Ich habe mehrere Modelle und Harnesses kuratiert, um schneller zu einer besseren Lösung zu kommen.“**
+
+Das ist eine ganz andere Flughöhe.
+
+## Was ich daraus als Learning ziehen würde
+
+Für dich persönlich:
+
+**1. Parallelität lohnt sich**
+Zwei GPT-Sessions im Browser sind nicht Chaos, sondern oft echter Durchsatzgewinn.
+
+**2. Modellrollen explizit machen**
+Nicht jedes Modell dieselbe Aufgabe.
+Lieber:
+
+* eines für Struktur
+* eines für Copy
+* eines für UI-Refactor
+* eines für Implementation
+
+**3. Du brauchst wirklich Adapter**
+Dein Anfangsgedanke ist dadurch eher bestätigt als widerlegt:
+verschiedene Harnesses brauchen verschiedene Promptformen, Tiefen und Steuerungsgrade.
+
+**4. Dein eigentlicher Skill ist Kuratierung**
+Nicht bloß prompten, sondern:
+
+* welches Modell jetzt?
+* welche Aufgabe?
+* wie viel Freiheit?
+* wann wechseln?
+* wann selbst entscheiden?
+
+Das ist schon ziemlich nah an echter **AI engineering praxis**.
+
+## Mein ehrliches Urteil
+
+Was du da gemacht hast, ist mehr als “nice website vor der uni”.
+
+Das ist ein kleines Beispiel für:
+**human-directed multi-model production**.
+
+Und das Spannende ist:
+du hast das nicht akademisch gemacht, sondern an etwas Echtem, Sozialem, mit Geschmack, Zeitdruck und realem Nutzen.
+
+Das ist die gute Art zu lernen.
+
+Wenn du willst, mache ich dir daraus als Nächstes eine **saubere Nachbetrachtung des Workflows**:
+welches Modell/Harness wofür am sinnvollsten war und wie du daraus ein wiederverwendbares persönliches Multi-Agent-Muster ableiten kannst.
+

newinfo

@@ -0,0 +1,40 @@
+Warum es für deine Arbeit wertvoll ist
+
+Weil du gerade intuitiv schon an genau dieser These arbeitest:
+
+Das eigentliche Produkt ist nicht der Agent.
+Das eigentliche Produkt ist der Kontrollraum um den Agenten.
+
+Also:
+
+Model
++ Context Policy
++ Tool Interface
++ State Memory
++ Scope Contract
++ Verification Loop
++ Runtime Guardrails
++ Observability
++ Handoff Protocol
+= Agentic Harness
+
+Und deine größere Idee wäre dann:
+
+Multi-Harness Control Plane
+
+Also eine Schicht, die entscheidet:
+
+Welche Aufgabe?
+Welcher Harness?
+Welches Modell?
+Welche Context-Policy?
+Welche Verifikation?
+Welche Stop-Regel?
+Welche Metrik?
+Welche Session weiterführen?
+
+Fazit:
+Ja. Dieses Repo ist nicht nur interessant. Es ist wahrscheinlich eine der besten aktuellen Quellenlisten, um dein eigenes Harness-/Agenten-Denken wissenschaftlicher, sauberer und anschlussfähiger zu machen
+
+
+https://github.com/walkinglabs/awesome-harness-engineering.

path

@@ -0,0 +1,734 @@
+Ja. Das ist die richtige Frage.
+
+Die eigentliche Kunst ist **nicht** “einen guten Prompt schreiben”.
+Die eigentliche Kunst ist, **Task, Harness und Modell getrennt zu denken**.
+
+Viele machen stillschweigend diesen Fehler:
+
+* sie schreiben **einen** Prompt,
+* werfen ihn in irgendein Harness,
+* wechseln das Modell,
+* und wundern sich, warum sich das Verhalten stark ändert.
+
+Aber ein starker AI Engineer denkt in **drei Ebenen**:
+
+## 1. Die drei Ebenen, die du auseinanderhalten musst
+
+### Ebene A: Task Spec
+
+Das ist die **objektive Arbeitsbeschreibung**.
+Unabhängig von Modell und Harness.
+
+Beispiel hier:
+
+* lange PDF
+* modularer Führungsleitfaden
+* semantisches Chunking
+* Subagents parallel
+* lokale Summaries
+* Cross-checks
+* Konsolidierung
+* finale Markdown-Datei
+* Shell-Skript für PDF
+
+Das ist der Teil, der **stabil** bleibt.
+
+### Ebene B: Harness Prompting
+
+Das ist die Anpassung an die **Laufzeitumgebung**:
+
+* Kann das Harness gut parallelisieren?
+* Hat es echte Subagents oder nur sequentielle Tool-Loops?
+* Kann es Dateien robust schreiben?
+* Ist es eher chatty oder eher execution-first?
+* Muss man Schreibzugriffe koordinieren?
+* Ist es terminal-first, cloud sandbox, IDE-native?
+
+Das ist **nicht** primär Modellprompting.
+Das ist **Betriebssystem-/Orchestrierungs-Prompting**.
+
+### Ebene C: Model Prompting
+
+Das ist die Anpassung an das **kognitive Profil des Modells**:
+
+* Wie gut inferiert es fehlende Schritte?
+* Wie stark halluziniert es elegante Übergänge?
+* Wie viel Struktur muss man explizit vorgeben?
+* Wie stark muss man Anti-Slop-Regeln setzen?
+* Wie gut hält es lokale vs. globale Trennung?
+* Wie gut kann es sich selbst verifizieren?
+
+Das ist der Teil, der sich zwischen **Minimax**, **GPT-5.4** und **Opus 4.6** wirklich ändert.
+
+---
+
+# 2. Was ist ein guter mentaler Frame?
+
+Denk nicht:
+
+> “Wie promptet man Modell X?”
+
+Denk lieber:
+
+> “Welche Fehler macht dieses Modell in diesem Harness auf diesem Task?”
+
+Das ist viel näher an echter AI-Engineering-Arbeit.
+
+Denn Prompting ist im Kern:
+**Fehlerprävention durch Spezifikation.**
+
+---
+
+# 3. Was sich beim Harness ändert
+
+## A. OpenCode
+
+So wie du es beschreibst, nutzt du OpenCode als eher **ausführungsorientiertes Coding-Harness**, mit Möglichkeit, Arbeit in mehrere Subagents auszulagern und parallel laufen zu lassen.
+
+Das heißt:
+
+* du musst **Agent-Rollen sehr hart trennen**
+* du musst **Artefakte** definieren
+* du musst **Schreibkonflikte verhindern**
+* du musst sagen, **wer was lesen darf**
+* du musst sagen, **wer global synthetisieren darf und wer nicht**
+
+OpenCode-Prompts sollten deshalb oft sein:
+
+* stark workflow-orientiert
+* datei- und artefaktzentriert
+* explizit parallelisierbar
+* mit klarer Ownership pro Agent
+
+OpenCode ist also eher:
+**“Agentenbetriebssystem prompten”**
+
+als
+**“schönen Text prompten”**.
+
+## B. Codex mit GPT-5.4
+
+OpenAI beschreibt Codex als Coding-Agent für Softwareentwicklung; es kann lokal oder in der Cloud arbeiten, und Codex ist explizit auf Software-Tasks, Codeverständnis und Delegation ausgelegt. OpenAI empfiehlt für die meisten Codex-Aufgaben mit `gpt-5.4` zu starten. ([OpenAI Entwickler][1])
+
+Für Codex ist der richtige Prompt meist:
+
+* **weniger micromanaged**
+* etwas mehr **outcome-oriented**
+* trotzdem mit **klaren Deliverables**
+* plus **Verification Loop**
+
+Warum?
+Weil GPT-5.4 stark in agentischen, coding-lastigen und professionellen Workflows ist und OpenAI für GPT-5.4 explizit Dinge wie Verifikationsschleifen, Structured Outputs und saubere Tool-Preambles empfiehlt. ([OpenAI Entwickler][2])
+
+Mit Codex musst du also weniger sagen:
+
+* “bitte denke auch an Schritt 7b”
+
+und mehr:
+
+* “das sind die Deliverables, das sind die Qualitätsgates, das ist die erlaubte Arbeitsweise, das ist der Verifikationsrahmen”.
+
+Codex/GPT-5.4 ist oft stärker, wenn du ihm:
+
+* Zielzustand,
+* Constraints,
+* Prüfkriterien,
+* Artefaktstruktur
+
+klar gibst, aber nicht jede Mikroentscheidung erdrückst.
+
+## C. Claude Code mit Opus 4.6
+
+Hier spreche ich jetzt bewusst als Engineering-Inferenz, nicht als zitierte Produktspezifikation:
+
+Ein Claude-Code-artiges Terminalharness wirkt typischerweise am besten, wenn du ihm:
+
+* **grobe Richtung**
+* **starke Prinzipien**
+* **wenige, aber harte Qualitätsregeln**
+* **klare Arbeitsphasen**
+* **Review-/Plan-Disziplin**
+
+gibst.
+
+Warum?
+Weil solche Modelle in terminalnahen Coding-Setups oft sehr gut sind in:
+
+* Codebase lesen
+* Plan bilden
+* große semantische Bögen halten
+* brauchbare Refactors und Synthesen formulieren
+
+Aber sie neigen eher dazu,
+
+* zu viel global zu denken,
+* zu früh zu synthetisieren,
+* Dinge elegant zu glätten,
+* und lokale Grounding-Grenzen zu überschreiten.
+
+Für Opus-artige Modelle ist daher oft wichtig:
+
+* **weniger Prozessbürokratie als bei schwächeren Modellen**
+* aber **starke epistemische Regeln**
+* also: “erfinde nichts, markiere Unsicherheit, halte lokale und globale Ebenen getrennt”.
+
+---
+
+# 4. Was sich beim Modell ändert
+
+Jetzt zum Kern.
+
+## Minimax M2.7
+
+Aus deinem Experimentbild heraus würde ich Minimax so behandeln:
+
+**Stärken**
+
+* schnell
+* produktiv
+* kann gute Makrostruktur simulieren
+* kann erstaunlich starke zusammenhängende Texte bauen
+
+**Risiken**
+
+* wirkt überzeugender als es geerdet ist
+* füllt Lücken mit plausibler Prosa
+* macht aggressive narrative Glättung
+* braucht härtere lokale Begrenzung
+* braucht stärkere Fact-Check-Schicht
+
+Deshalb muss der Prompt für Minimax:
+
+* **expliziter**
+* **enger**
+* **rollenstärker**
+* **anti-hallucination-lastiger**
+* **stärker datei- und formatgesteuert**
+
+sein.
+
+Mit Minimax promptest du mehr wie:
+
+> “Hier ist das Geländer. Hier sind die Wände. Hier darfst du laufen. Hier nicht.”
+
+## GPT-5.4
+
+OpenAI beschreibt GPT-5.4 als stark für agentische, coding-lastige und professionelle Workflows; die offiziellen Prompt-Guides betonen Verifikationsschleifen, Structured Outputs und Tool-Persistence, und OpenAI sagt, dass `gpt-5.4` in Codex für die meisten Aufgaben der sinnvolle Startpunkt ist. ([OpenAI Entwickler][2])
+
+Was heißt das praktisch?
+
+GPT-5.4 braucht oft:
+
+* **klaren Endzustand**
+* **klare Prüfkriterien**
+* **saubere Phasen**
+* **weniger redundante Wiederholung**
+* **weniger defensive Überinstruktion**
+
+Es verträgt eher:
+
+* “hier ist der Job, hier sind die Artefakte, hier sind die Qualitätsgates, arbeite sauber”
+
+als
+
+* 200 Zeilen Micromanagement.
+
+Wenn du GPT-5.4 wie ein kleines Modell behandelst, schadest du oft:
+
+* es wird schwerfällig,
+* formalistisch,
+* manchmal unnötig rigid,
+* und verbringt zu viel Energie mit dem Befolgen des Metaprozesses statt mit dem Kernproblem.
+
+Mit GPT-5.4 promptest du mehr wie:
+
+> “Hier ist die Mission, hier ist der Qualitätsrahmen, zeig mir robuste Execution.”
+
+## Opus 4.6
+
+Für Opus-artige große reasoning/stylistic Modelle würde ich sagen:
+
+Sie profitieren oft von:
+
+* **Prinzipien**
+* **Review-Disziplin**
+* **hochrangiger Zieldefinition**
+* **epistemischen Grenzen**
+* **klaren Stop-Regeln**
+
+Sie brauchen nicht unbedingt jeden Formatcontainer ausbuchstabiert,
+aber sie brauchen sehr wohl:
+
+* “nicht ausschmücken”
+* “nicht psychologisieren”
+* “keine historischen Schlüsse ohne Deckung”
+* “keine globale Synthese vor lokaler Extraktion”
+
+Mit Opus promptest du oft mehr wie:
+
+> “Arbeite wie ein guter Senior Analyst mit starker Selbstdisziplin.”
+
+---
+
+# 5. Das Entscheidende: derselbe Task, drei verschiedene Prompt-Stile
+
+Jetzt wird es konkret.
+
+---
+
+## Prompt-Stil für Codex + GPT-5.4
+
+Hier würde ich **Outcome-first + Verification-first** prompten.
+
+### Charakter
+
+* klar
+* knapp
+* professionell
+* deliverable-orientiert
+* mit Qualitätsgates
+* nicht zu überfrachtet
+
+### Beispiel
+
+```text
+Task:
+Summarize the uploaded Heidelberg Castle guide into a source-faithful Markdown document that can later be rendered into a ~15-page PDF.
+
+Context:
+This is not a linear book. It is a modular guide for castle tours with four top-level modules:
+1. History
+2. Architecture
+3. Personalities
+4. Cultural history
+
+Required workflow:
+1. Read the document structure and create a semantic chunk plan.
+2. Summarize each chunk locally before attempting any global synthesis.
+3. Run verification passes for chronology, person/title consistency, and architecture/building attribution.
+4. Merge the verified local summaries into a single coherent Markdown summary.
+5. Create a shell script that renders the Markdown to PDF.
+
+Deliverables:
+- work/document_map.md
+- work/chunk_plan.md
+- work/local_summaries/*.md
+- work/checks/chronology.md
+- work/checks/persons.md
+- work/checks/architecture.md
+- output/summary_15_pages.md
+- output/render_pdf.sh
+
+Quality bar:
+- Source-faithful
+- No invented facts
+- No decorative filler
+- Preserve uncertainty where the source is ambiguous
+- Prioritize “key facts” sections from the source
+- Final summary should reflect the source’s didactic structure, not flatten it into generic prose
+
+Before finalizing:
+- verify dates
+- verify ruler/person mappings
+- verify building-to-builder mappings
+- remove claims that are plausible but not clearly grounded in the source
+```
+
+### Warum so?
+
+Weil GPT-5.4 stark genug ist, den Workflow zu tragen, wenn du ihm gibst:
+
+* Ziel
+* Arbeitsweise
+* Prüfkriterien
+* Artefakte.
+
+Du musst es nicht so stark “einsargen” wie Minimax.
+
+---
+
+## Prompt-Stil für Claude Code + Opus 4.6
+
+Hier würde ich **Plan-first + Principle-first** prompten.
+
+### Charakter
+
+* etwas semantischer
+* etwas analytischer
+* mehr Betonung auf Denkdisziplin
+* weniger auf starre Formatbürokratie
+* aber mit starken epistemischen Regeln
+
+### Beispiel
+
+```text
+You are producing a source-faithful analytical summary of a long Heidelberg Castle guide.
+
+This source is modular, not linear. Treat it as a structured teaching document, not as a conventional narrative book. Its top-level modules are history, architecture, personalities, and cultural history.
+
+Working method:
+- First map the document structure.
+- Then produce local summaries for semantically coherent sections.
+- Do not jump to global synthesis early.
+- After local extraction, perform explicit review passes:
+  - chronology
+  - person/title consistency
+  - building/builder attribution
+  - source faithfulness
+- Only then write the final consolidated summary.
+
+Important rules:
+- Do not invent transitions or historical motives.
+- Do not turn plausible inferences into assertions.
+- Do not smooth over ambiguities.
+- Respect the source’s didactic emphasis, especially explicit key facts.
+- Keep architecture, political history, and reception history distinct until the consolidation phase.
+
+Outputs:
+- a document map
+- a chunk plan
+- local section summaries
+- review notes
+- a final ~15-page Markdown summary
+- a shell script to render it to PDF
+
+Write densely and clearly. Prefer precision over flourish.
+```
+
+### Warum so?
+
+Weil Opus-artige Modelle oft stark sind, wenn du ihnen:
+
+* semantische Disziplin,
+* epistemische Strenge,
+* Review-Phasen,
+* und klare High-Level-Prinzipien gibst.
+
+---
+
+## Prompt-Stil für OpenCode + Minimax M2.7
+
+Hier würde ich **Workflow-first + Guardrail-first + Subagent-first** prompten.
+
+### Charakter
+
+* explizit
+* streng modular
+* harte Agententrennung
+* formale Outputs
+* Anti-Halluzinationsblock
+* Anti-Slop-Block
+* Parallelitätsregeln
+
+### Beispiel
+
+```text
+You are running a multi-agent workflow.
+
+Goal:
+Create a source-faithful 15-page Markdown summary of the Heidelberg Castle guide and a shell script to render it to PDF.
+
+This is a modular guide, not a linear book.
+Primary modules:
+1. History
+2. Architecture
+3. Personalities
+4. Cultural history
+
+Agent roles:
+- Orchestrator
+- Structure agent
+- Local content agents
+- Chronology check agent
+- Person/dynasty check agent
+- Architecture check agent
+- Merge agent
+- Editor agent
+- Build agent
+
+Hard rules:
+- Local content agents may only use their assigned chunk.
+- No agent may write to another agent’s file.
+- Only merge/editor agents may create global synthesis.
+- Any uncertain claim must be marked as uncertain.
+- Any claim not clearly grounded in the source must be removed from the final summary.
+
+Required outputs:
+- work/00_document_map.md
+- work/01_chunk_plan.md
+- work/02_local_summaries/chunk_*.md
+- work/03_cross_checks/*.md
+- work/04_global_outline.md
+- output/summary_15_pages.md
+- output/render_pdf.sh
+
+Anti-hallucination rules:
+- no invented dates
+- no invented motives
+- no unsupported architectural labels
+- no elegant filler
+- no generic culture-language
+- no importing facts across chunks during local summarization
+
+Parallel execution:
+- run local content agents in parallel on independent semantic chunks
+- run cross-check agents in parallel after all local summaries exist
+- avoid shared write targets
+```
+
+### Warum so?
+
+Weil Minimax sonst mit hoher Wahrscheinlichkeit:
+
+* zu früh global synthetisiert,
+* zu viel selbst ergänzt,
+* und dann sehr überzeugend falsch wird.
+
+---
+
+# 6. Also: Wie muss der Prompt aussehen für welches Harness?
+
+Hier ist die Faustregel:
+
+## Für Harnesses mit starker Agent-Orchestrierung
+
+Prompt muss enthalten:
+
+* Rollen
+* Artefakte
+* Zuständigkeiten
+* Abhängigkeiten
+* Parallelitätsregeln
+* Merge-/Check-Phasen
+
+## Für Harnesses mit starkem Modell und guter Tool-Disziplin
+
+Prompt muss enthalten:
+
+* Ziel
+* Constraints
+* Deliverables
+* Verification gates
+* Stoppregeln
+
+## Für terminalnahe, planstarke Harnesses
+
+Prompt muss enthalten:
+
+* Zielbild
+* epistemische Leitplanken
+* Plan- und Review-Disziplin
+* wenige harte Qualitätsregeln
+* keine unnötige Prozessverstopfung
+
+---
+
+# 7. Also: Wie muss der Prompt aussehen für welches Modell?
+
+Noch kürzer:
+
+## Schwächer / glatter / riskanter schreibende Modelle
+
+Mehr:
+
+* Struktur
+* Format
+* Regelhaftigkeit
+* Cross-checking
+* harte Lokalität
+* starke Negativregeln
+
+## Stärkere reasoning-heavy Modelle
+
+Mehr:
+
+* Zielklarheit
+* Qualitätsgates
+* epistemische Regeln
+* weniger Mikromanagement
+* mehr Verantwortung beim Modell
+
+---
+
+# 8. Woher weiß man das?
+
+Das ist die Kernfrage.
+
+Nicht durch Magie.
+Nicht durch “Prompting ist Kunst”.
+Sondern durch **Eval-getriebene Modellierung**.
+
+Du weißt es aus vier Quellen:
+
+## 1. Offizielle Dokumentation
+
+Für GPT-5.4 und Codex ist das direkt nützlich: OpenAI dokumentiert, dass Codex ein Coding-Agent ist, für die meisten Codex-Aufgaben `gpt-5.4` der Startpunkt ist und GPT-5.4 gut mit Verifikationsschleifen, strukturierten Outputs und Tool-orientierten Arbeitsweisen harmoniert. ([OpenAI Entwickler][1])
+
+Das ist dein **Prior**.
+
+## 2. Harness-Verhalten beobachten
+
+Du siehst in echten Läufen:
+
+* wann das Modell zu früh synthetisiert
+* wann es lokale Grenzen missachtet
+* wann es Tool-Calls vergisst
+* wann es in langen Tasks entgleist
+* wann es zu chatty oder zu knapp wird
+
+Das ist dein **Runtime-Profil**.
+
+## 3. Fehlerkataloge bauen
+
+Für jedes Modell/Harness-Paar solltest du fast wie in einem Labor notieren:
+
+* typische Halluzinationen
+* typische Strukturfehler
+* typische Tempo-/Kostenmuster
+* typische Missverständnisse
+* typische Stärken
+
+Dann promptest du nicht mehr abstrakt, sondern gezielt gegen Fehler.
+
+## 4. Kleine kontrollierte Evals
+
+Das ist der wichtigste Punkt.
+
+Du machst nicht “große Gefühle”, sondern kleine Benchmarks:
+
+* 5 ähnliche PDFs
+* gleiche Task Spec
+* drei Promptvarianten
+* drei Modelle
+* Score auf:
+
+  * Faithfulness
+  * Coverage
+  * Dedup
+  * Coherence
+  * Hallucination rate
+  * Time
+  * Cost
+
+Dann siehst du:
+
+* welches Modell mehr Freiheit verträgt
+* welches Modell mehr Geländer braucht
+* welches Harness welche Promptform am besten umsetzt
+
+---
+
+# 9. Woher weiß *ich*, wie ich den Prompt schreiben muss?
+
+Nicht sicher im absoluten Sinn.
+Sondern durch eine Mischung aus:
+
+* allgemeiner Agent-/Prompt-Engineering-Heuristik,
+* beobachteten Fehlermustern,
+* Dokumenttyp-Erkennung,
+* und Anpassung an das wahrscheinliche Stärken-/Schwächenprofil von Modell + Harness.
+
+Also nicht:
+
+> “Ich kenne den perfekten Prompt.”
+
+Sondern:
+
+> “Ich versuche, die wahrscheinlichsten Failure Modes dieses Setups im Voraus zu neutralisieren.”
+
+Das ist der professionelle Frame.
+
+---
+
+# 10. Was ein AI Engineer daraus machen sollte
+
+Wenn du das ernsthaft können willst, dann bau dir diese Arbeitsweise:
+
+## Immer drei Artefakte trennen
+
+1. **task_spec.md**
+2. **harness_policy.md**
+3. **model_adapter.md**
+
+Dann kombinierst du sie je nach Lauf.
+
+Beispiel:
+
+### task_spec.md
+
+* PDF zusammenfassen
+* semantische Chunks
+* lokale Summaries
+* globale Konsolidierung
+* Markdown + PDF script
+
+### harness_policy_opencode.md
+
+* Subagents
+* Parallelität
+* Dateibesitz
+* Merge-Phase
+* Check-Phase
+
+### model_adapter_minimax.md
+
+* stärker explizit
+* Anti-Halluzination
+* harte Formatdisziplin
+
+### model_adapter_gpt54.md
+
+* outcome-first
+* verification-first
+* weniger Micromanagement
+
+### model_adapter_opus46.md
+
+* principle-first
+* review-first
+* epistemische Strenge
+
+Dann hast du echte **Prompt-Architektur**, nicht nur einzelne Texte.
+
+---
+
+# 11. Meine verdichtete Theorie in einem Satz
+
+**Der richtige Prompt ist nicht nur eine Eigenschaft des Modells, sondern die Schnittstelle zwischen Taskstruktur, Harnessmechanik und Fehlertyp des Modells.**
+
+Das ist der Übergang von “gut prompten” zu **AI Engineering**.
+
+---
+
+# 12. Mein praktischer Rat für dich
+
+Wenn du in diese Richtung willst, dann fang an, für jede Agent-Aufgabe systematisch zu dokumentieren:
+
+* Dokumenttyp
+* Task Spec
+* Harness
+* Modell
+* Promptversion
+* Fehlerbilder
+* Kosten
+* Dauer
+* Ergebnisqualität
+* nächste Hypothese
+
+Dann baust du dir dein eigenes internes **Prompt- und Harness-Wissenssystem**.
+Genau daraus entsteht später dein echter Vorteil gegenüber Leuten, die nur “ein bisschen mit Modellen rumspielen”.
+
+Wenn du willst, mache ich dir als Nächstes daraus ein **konkretes AI-Engineer-Template-Set**:
+
+* `task_spec.md`
+* `harness_policy_opencode.md`
+* `harness_policy_codex.md`
+* `harness_policy_claudecode.md`
+* `model_adapter_minimax.md`
+* `model_adapter_gpt54.md`
+* `model_adapter_opus46.md`
+* plus eine kleine Eval-Rubric.
+
+[1]: https://developers.openai.com/codex/?utm_source=chatgpt.com "Codex"
+[2]: https://developers.openai.com/api/docs/models/gpt-5.4?utm_source=chatgpt.com "GPT-5.4 Model | OpenAI API"
+

registry/adapters/agentide.json

@@ -0,0 +1,14 @@
+{
+  "schema_name": "AdapterManifest",
+  "schema_version": "1.0.0",
+  "adapter_id": "agentide_adapter",
+  "source_system": "AgentIDE",
+  "role": "operator_entrypoint",
+  "reads": ["RunRecord", "SpineEvent", "ArtifactManifest", "ExecutionStatus"],
+  "writes": ["TaskRequest"],
+  "guarantees": [
+    "Creates canonical task requests",
+    "Consumes live run state without inventing new statuses",
+    "Treats Spine as source of truth for run reconstruction"
+  ]
+}

registry/adapters/harnessecosystem.json

@@ -0,0 +1,14 @@
+{
+  "schema_name": "AdapterManifest",
+  "schema_version": "1.0.0",
+  "adapter_id": "harnessecosystem_adapter",
+  "source_system": "HarnessEcosystem",
+  "role": "observability_feed",
+  "reads": ["SystemManifest", "RunRecord", "EvalRecord", "ArtifactManifest"],
+  "writes": [],
+  "guarantees": [
+    "Builds presentational feeds from canonical registry and outcomes",
+    "Does not become source of truth for contracts",
+    "Can regenerate snapshots without hand-edited semantic drift"
+  ]
+}

registry/adapters/komandozentral.json

@@ -0,0 +1,14 @@
+{
+  "schema_name": "AdapterManifest",
+  "schema_version": "1.0.0",
+  "adapter_id": "komandozentral_adapter",
+  "source_system": "KomandoZentral",
+  "role": "decision_ingestion",
+  "reads": ["TaskRequest"],
+  "writes": ["RoutingDecision", "SpineEvent"],
+  "guarantees": [
+    "Maps routing output into canonical decision schema",
+    "Does not dispatch execution directly",
+    "Preserves decision policy version"
+  ]
+}

registry/adapters/metametameta.json

@@ -0,0 +1,14 @@
+{
+  "schema_name": "AdapterManifest",
+  "schema_version": "1.0.0",
+  "adapter_id": "metametameta_adapter",
+  "source_system": "MetaMetaMeta",
+  "role": "evidence_ingestion",
+  "reads": ["RunRecord", "SpineEvent", "ArtifactManifest", "EvalRecord"],
+  "writes": ["EvalRecord"],
+  "guarantees": [
+    "Preserves provenance of eval results",
+    "Does not mutate runtime state",
+    "Emits derived evidence in canonical format"
+  ]
+}

registry/adapters/ueber_agent.json

@@ -0,0 +1,14 @@
+{
+  "schema_name": "AdapterManifest",
+  "schema_version": "1.0.0",
+  "adapter_id": "ueber_agent_adapter",
+  "source_system": "UEBER_AGENT",
+  "role": "execution_bridge",
+  "reads": ["ExecutionRequest"],
+  "writes": ["ExecutionStatus", "RouteTrace", "ArtifactManifest", "SpineEvent"],
+  "guarantees": [
+    "Translates runtime events into append-only Spine events",
+    "Preserves execution and route trace identifiers",
+    "Does not reinterpret decision semantics"
+  ]
+}

registry/harnesses/claude-code.json

@@ -0,0 +1,18 @@
+{
+  "schema_name": "HarnessManifest",
+  "schema_version": "1.0.0",
+  "harness_id": "claude-code",
+  "name": "Claude Code",
+  "status": "active",
+  "runtime_target": "claude-code-local",
+  "accepts": ["TaskRequest", "ExecutionRequest"],
+  "emits": ["ExecutionStatus", "ArtifactManifest", "EvalRecord"],
+  "constraints": [
+    "High cost profile",
+    "Strong architecture and deep codebase work",
+    "Interactive terminal workflow"
+  ],
+  "cost_class": "high",
+  "trust_level": "trusted",
+  "best_for": ["architecture", "planning", "full-codebase analysis"]
+}

registry/harnesses/codex-cli.json

@@ -0,0 +1,18 @@
+{
+  "schema_name": "HarnessManifest",
+  "schema_version": "1.0.0",
+  "harness_id": "codex-cli",
+  "name": "Codex CLI",
+  "status": "active",
+  "runtime_target": "claude-code-local",
+  "accepts": ["TaskRequest", "ExecutionRequest"],
+  "emits": ["ExecutionStatus", "ArtifactManifest"],
+  "constraints": [
+    "Strong terminal-centric coding",
+    "Needs explicit deliverables and verification",
+    "No assumption of cross-system orchestration by default"
+  ],
+  "cost_class": "medium",
+  "trust_level": "normal",
+  "best_for": ["scripts", "terminal automation", "polishing"]
+}

registry/harnesses/hermes.json

@@ -0,0 +1,18 @@
+{
+  "schema_name": "HarnessManifest",
+  "schema_version": "1.0.0",
+  "harness_id": "hermes",
+  "name": "Hermes",
+  "status": "active",
+  "runtime_target": "ueber-agent-openclaw-vm",
+  "accepts": ["ExecutionRequest"],
+  "emits": ["ExecutionStatus", "RouteTrace", "ArtifactManifest"],
+  "constraints": [
+    "Cheap iterative workhorse",
+    "Needs explicit cwd and artifact boundaries",
+    "No Spine-side assumption of strong guardrails"
+  ],
+  "cost_class": "low",
+  "trust_level": "guarded",
+  "best_for": ["implementation", "docs", "cheap iteration"]
+}

registry/harnesses/opencode.json

@@ -0,0 +1,18 @@
+{
+  "schema_name": "HarnessManifest",
+  "schema_version": "1.0.0",
+  "harness_id": "opencode",
+  "name": "OpenCode",
+  "status": "experimental",
+  "runtime_target": "ueber-agent-openclaw-vm",
+  "accepts": ["ExecutionRequest"],
+  "emits": ["ExecutionStatus", "ArtifactManifest"],
+  "constraints": [
+    "Useful for isolated execution",
+    "Known scope-drift risk",
+    "Requires strong ownership and artifact contracts"
+  ],
+  "cost_class": "low",
+  "trust_level": "guarded",
+  "best_for": ["isolated bugfixes", "parallel agent work"]
+}

registry/system_manifest.json

@@ -0,0 +1,55 @@
+{
+  "schema_name": "SystemManifest",
+  "schema_version": "1.0.0",
+  "system_id": "multi_harness_spine",
+  "name": "MultiHarness Spine",
+  "description": "Canonical integration spine for evidence, routing, execution, UI and observability layers.",
+  "created_at": "2026-04-08T16:00:00Z",
+  "source_projects": [
+    {
+      "project_id": "metametameta",
+      "role": "evidence_layer",
+      "path": "/home/smlflg/Projekte/MetaMetaMeta"
+    },
+    {
+      "project_id": "komandozentral",
+      "role": "decision_layer",
+      "path": "/home/smlflg/Projekte/KomandoZentral"
+    },
+    {
+      "project_id": "ueber_agent",
+      "role": "execution_layer",
+      "path": "/home/smlflg/Projekte/UEBER_AGENT"
+    },
+    {
+      "project_id": "agentide",
+      "role": "operator_ui",
+      "path": "/home/smlflg/Projekte/AgentIDE"
+    },
+    {
+      "project_id": "harnessecosystem",
+      "role": "observatory_layer",
+      "path": "/home/smlflg/Projekte/HarnessEcosystem"
+    }
+  ],
+  "runtime_targets": [
+    "claude-code-local",
+    "ueber-agent-openclaw-vm",
+    "agentide-local-ui"
+  ],
+  "schema_inventory": [
+    "OperatorContext",
+    "TaskRequest",
+    "RoutingDecision",
+    "RunRecord",
+    "ExecutionRequest",
+    "ExecutionStatus",
+    "RouteTrace",
+    "ArtifactManifest",
+    "EvalRecord",
+    "SpineEvent",
+    "SystemManifest",
+    "HarnessManifest",
+    "AdapterManifest"
+  ]
+}

schemas/adapter_manifest.schema.json

@@ -0,0 +1,36 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "spine:adapter_manifest",
+  "title": "AdapterManifest",
+  "type": "object",
+  "required": [
+    "schema_name",
+    "schema_version",
+    "adapter_id",
+    "source_system",
+    "role",
+    "reads",
+    "writes",
+    "guarantees"
+  ],
+  "properties": {
+    "schema_name": { "const": "AdapterManifest" },
+    "schema_version": { "type": "string", "const": "1.0.0" },
+    "adapter_id": { "type": "string", "minLength": 1 },
+    "source_system": { "type": "string", "minLength": 1 },
+    "role": { "type": "string", "minLength": 1 },
+    "reads": {
+      "type": "array",
+      "items": { "type": "string" }
+    },
+    "writes": {
+      "type": "array",
+      "items": { "type": "string" }
+    },
+    "guarantees": {
+      "type": "array",
+      "items": { "type": "string" }
+    }
+  },
+  "additionalProperties": false
+}

schemas/artifact_manifest.schema.json

@@ -0,0 +1,45 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "spine:artifact_manifest",
+  "title": "ArtifactManifest",
+  "type": "object",
+  "required": [
+    "schema_name",
+    "schema_version",
+    "artifact_id",
+    "artifact_type",
+    "uri",
+    "produced_by",
+    "run_id",
+    "content_hash",
+    "created_at"
+  ],
+  "properties": {
+    "schema_name": { "const": "ArtifactManifest" },
+    "schema_version": { "type": "string", "const": "1.0.0" },
+    "artifact_id": { "type": "string", "pattern": "^artifact_[a-z0-9_\\-]+$" },
+    "artifact_type": {
+      "type": "string",
+      "enum": [
+        "decision",
+        "execution_input",
+        "trace",
+        "log",
+        "report",
+        "tasksheet",
+        "eval",
+        "workspace_snapshot",
+        "patch_ref",
+        "deploy_result"
+      ]
+    },
+    "uri": { "type": "string", "minLength": 1 },
+    "produced_by": { "type": "string", "minLength": 1 },
+    "run_id": { "type": "string", "pattern": "^run_[a-z0-9_\\-]+$" },
+    "content_hash": { "type": "string", "minLength": 1 },
+    "created_at": { "type": "string", "format": "date-time" },
+    "source_system": { "type": "string" },
+    "metadata": { "type": "object" }
+  },
+  "additionalProperties": false
+}

schemas/eval_record.schema.json

@@ -0,0 +1,42 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "spine:eval_record",
+  "title": "EvalRecord",
+  "type": "object",
+  "required": [
+    "schema_name",
+    "schema_version",
+    "eval_id",
+    "run_id",
+    "task_id",
+    "evaluator",
+    "recorded_at",
+    "scores",
+    "summary"
+  ],
+  "properties": {
+    "schema_name": { "const": "EvalRecord" },
+    "schema_version": { "type": "string", "const": "1.0.0" },
+    "eval_id": { "type": "string", "pattern": "^eval_[a-z0-9_\\-]+$" },
+    "run_id": { "type": "string", "pattern": "^run_[a-z0-9_\\-]+$" },
+    "task_id": { "type": "string", "pattern": "^task_[a-z0-9_\\-]+$" },
+    "evaluator": { "type": "string", "minLength": 1 },
+    "recorded_at": { "type": "string", "format": "date-time" },
+    "scores": {
+      "type": "object",
+      "required": ["goal_completion", "traceability", "runtime_fitness"],
+      "properties": {
+        "goal_completion": { "type": "number", "minimum": 0, "maximum": 1 },
+        "traceability": { "type": "number", "minimum": 0, "maximum": 1 },
+        "runtime_fitness": { "type": "number", "minimum": 0, "maximum": 1 }
+      },
+      "additionalProperties": false
+    },
+    "summary": { "type": "string", "minLength": 1 },
+    "recommendations": {
+      "type": "array",
+      "items": { "type": "string" }
+    }
+  },
+  "additionalProperties": false
+}

schemas/execution_request.schema.json

@@ -0,0 +1,53 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "spine:execution_request",
+  "title": "ExecutionRequest",
+  "type": "object",
+  "required": [
+    "schema_name",
+    "schema_version",
+    "execution_id",
+    "decision_id",
+    "run_id",
+    "target_runtime",
+    "target_agent",
+    "input_artifacts",
+    "execution_mode",
+    "workspace_ref",
+    "timeout_policy",
+    "approval_requirements",
+    "created_at",
+    "source_system"
+  ],
+  "properties": {
+    "schema_name": { "const": "ExecutionRequest" },
+    "schema_version": { "type": "string", "const": "1.0.0" },
+    "execution_id": { "type": "string", "pattern": "^execution_[a-z0-9_\\-]+$" },
+    "decision_id": { "type": "string", "pattern": "^decision_[a-z0-9_\\-]+$" },
+    "run_id": { "type": "string", "pattern": "^run_[a-z0-9_\\-]+$" },
+    "target_runtime": { "type": "string", "minLength": 1 },
+    "target_agent": { "type": "string", "minLength": 1 },
+    "input_artifacts": {
+      "type": "array",
+      "items": { "type": "string", "pattern": "^artifact_[a-z0-9_\\-]+$" }
+    },
+    "execution_mode": { "type": "string", "enum": ["interactive", "batch", "background"] },
+    "workspace_ref": { "type": "string", "minLength": 1 },
+    "timeout_policy": {
+      "type": "object",
+      "required": ["timeout_seconds", "on_timeout"],
+      "properties": {
+        "timeout_seconds": { "type": "integer", "minimum": 1 },
+        "on_timeout": { "type": "string", "enum": ["fail", "ask_operator", "retry"] }
+      },
+      "additionalProperties": false
+    },
+    "approval_requirements": {
+      "type": "array",
+      "items": { "type": "string" }
+    },
+    "created_at": { "type": "string", "format": "date-time" },
+    "source_system": { "type": "string", "minLength": 1 }
+  },
+  "additionalProperties": false
+}

schemas/execution_status.schema.json

@@ -0,0 +1,36 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "spine:execution_status",
+  "title": "ExecutionStatus",
+  "type": "object",
+  "required": [
+    "schema_name",
+    "schema_version",
+    "status_id",
+    "execution_id",
+    "run_id",
+    "status",
+    "source_system",
+    "recorded_at"
+  ],
+  "properties": {
+    "schema_name": { "const": "ExecutionStatus" },
+    "schema_version": { "type": "string", "const": "1.0.0" },
+    "status_id": { "type": "string", "pattern": "^status_[a-z0-9_\\-]+$" },
+    "execution_id": { "type": "string", "pattern": "^execution_[a-z0-9_\\-]+$" },
+    "run_id": { "type": "string", "pattern": "^run_[a-z0-9_\\-]+$" },
+    "status": {
+      "type": "string",
+      "enum": ["requested", "dispatched", "running", "waiting_for_input", "completed", "failed", "aborted"]
+    },
+    "message": { "type": "string" },
+    "source_system": { "type": "string", "minLength": 1 },
+    "recorded_at": { "type": "string", "format": "date-time" },
+    "progress_hint": { "type": "string" },
+    "artifact_ids": {
+      "type": "array",
+      "items": { "type": "string", "pattern": "^artifact_[a-z0-9_\\-]+$" }
+    }
+  },
+  "additionalProperties": false
+}

schemas/harness_manifest.schema.json

@@ -0,0 +1,46 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "spine:harness_manifest",
+  "title": "HarnessManifest",
+  "type": "object",
+  "required": [
+    "schema_name",
+    "schema_version",
+    "harness_id",
+    "name",
+    "status",
+    "runtime_target",
+    "accepts",
+    "emits",
+    "constraints",
+    "cost_class",
+    "trust_level"
+  ],
+  "properties": {
+    "schema_name": { "const": "HarnessManifest" },
+    "schema_version": { "type": "string", "const": "1.0.0" },
+    "harness_id": { "type": "string", "minLength": 1 },
+    "name": { "type": "string", "minLength": 1 },
+    "status": { "type": "string", "enum": ["active", "experimental", "blocked", "deprecated"] },
+    "runtime_target": { "type": "string", "minLength": 1 },
+    "accepts": {
+      "type": "array",
+      "items": { "type": "string" }
+    },
+    "emits": {
+      "type": "array",
+      "items": { "type": "string" }
+    },
+    "constraints": {
+      "type": "array",
+      "items": { "type": "string" }
+    },
+    "cost_class": { "type": "string", "enum": ["low", "medium", "high"] },
+    "trust_level": { "type": "string", "enum": ["guarded", "normal", "trusted"] },
+    "best_for": {
+      "type": "array",
+      "items": { "type": "string" }
+    }
+  },
+  "additionalProperties": false
+}

schemas/operator_context.schema.json

@@ -0,0 +1,26 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "spine:operator_context",
+  "title": "OperatorContext",
+  "type": "object",
+  "required": [
+    "schema_name",
+    "schema_version",
+    "focus",
+    "energy",
+    "mode",
+    "cost_tolerance"
+  ],
+  "properties": {
+    "schema_name": { "const": "OperatorContext" },
+    "schema_version": { "type": "string", "const": "1.0.0" },
+    "focus": { "type": "string", "enum": ["high", "medium", "low"] },
+    "energy": { "type": "string", "enum": ["high", "low"] },
+    "mode": { "type": "string", "enum": ["default", "exploration", "shipping"] },
+    "cost_tolerance": { "type": "string", "enum": ["sparend", "normal", "quality-first"] },
+    "adhd_risk": { "type": "string", "enum": ["normal", "high"] },
+    "drift_risk": { "type": "string", "enum": ["normal", "high"] },
+    "notes": { "type": "string" }
+  },
+  "additionalProperties": false
+}

schemas/route_trace.schema.json

@@ -0,0 +1,41 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "spine:route_trace",
+  "title": "RouteTrace",
+  "type": "object",
+  "required": [
+    "schema_name",
+    "schema_version",
+    "trace_id",
+    "run_id",
+    "execution_id",
+    "source_system",
+    "recorded_at",
+    "steps"
+  ],
+  "properties": {
+    "schema_name": { "const": "RouteTrace" },
+    "schema_version": { "type": "string", "const": "1.0.0" },
+    "trace_id": { "type": "string", "pattern": "^trace_[a-z0-9_\\-]+$" },
+    "run_id": { "type": "string", "pattern": "^run_[a-z0-9_\\-]+$" },
+    "execution_id": { "type": "string", "pattern": "^execution_[a-z0-9_\\-]+$" },
+    "source_system": { "type": "string", "minLength": 1 },
+    "recorded_at": { "type": "string", "format": "date-time" },
+    "steps": {
+      "type": "array",
+      "minItems": 1,
+      "items": {
+        "type": "object",
+        "required": ["index", "actor", "action", "outcome"],
+        "properties": {
+          "index": { "type": "integer", "minimum": 1 },
+          "actor": { "type": "string", "minLength": 1 },
+          "action": { "type": "string", "minLength": 1 },
+          "outcome": { "type": "string", "minLength": 1 }
+        },
+        "additionalProperties": false
+      }
+    }
+  },
+  "additionalProperties": false
+}

schemas/routing_decision.schema.json

@@ -0,0 +1,44 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "spine:routing_decision",
+  "title": "RoutingDecision",
+  "type": "object",
+  "required": [
+    "schema_name",
+    "schema_version",
+    "decision_id",
+    "task_id",
+    "recommended_harness",
+    "recommended_runtime_target",
+    "confidence",
+    "reasoning_summary",
+    "risks",
+    "fallback",
+    "decision_policy_version",
+    "source_system",
+    "created_at"
+  ],
+  "properties": {
+    "schema_name": { "const": "RoutingDecision" },
+    "schema_version": { "type": "string", "const": "1.0.0" },
+    "decision_id": { "type": "string", "pattern": "^decision_[a-z0-9_\\-]+$" },
+    "task_id": { "type": "string", "pattern": "^task_[a-z0-9_\\-]+$" },
+    "recommended_harness": { "type": "string", "minLength": 1 },
+    "recommended_runtime_target": { "type": "string", "minLength": 1 },
+    "confidence": { "type": "integer", "minimum": 0, "maximum": 100 },
+    "reasoning_summary": { "type": "string", "minLength": 1 },
+    "risks": {
+      "type": "array",
+      "items": { "type": "string" }
+    },
+    "fallback": { "type": "string", "minLength": 1 },
+    "decision_policy_version": { "type": "string", "minLength": 1 },
+    "source_system": { "type": "string", "minLength": 1 },
+    "created_at": { "type": "string", "format": "date-time" },
+    "missing_information": {
+      "type": "array",
+      "items": { "type": "string" }
+    }
+  },
+  "additionalProperties": false
+}

schemas/run_record.schema.json

@@ -0,0 +1,64 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "spine:run_record",
+  "title": "RunRecord",
+  "type": "object",
+  "required": [
+    "schema_name",
+    "schema_version",
+    "run_id",
+    "task_id",
+    "run_state",
+    "created_at",
+    "origin_system",
+    "decision_ids",
+    "execution_ids",
+    "artifact_ids",
+    "event_ids"
+  ],
+  "properties": {
+    "schema_name": { "const": "RunRecord" },
+    "schema_version": { "type": "string", "const": "1.0.0" },
+    "run_id": { "type": "string", "pattern": "^run_[a-z0-9_\\-]+$" },
+    "task_id": { "type": "string", "pattern": "^task_[a-z0-9_\\-]+$" },
+    "run_state": {
+      "type": "string",
+      "enum": [
+        "created",
+        "decided",
+        "ready_for_dispatch",
+        "dispatched",
+        "running",
+        "waiting_for_input",
+        "completed",
+        "failed",
+        "aborted",
+        "evaluated"
+      ]
+    },
+    "created_at": { "type": "string", "format": "date-time" },
+    "updated_at": { "type": "string", "format": "date-time" },
+    "origin_system": { "type": "string", "minLength": 1 },
+    "decision_ids": {
+      "type": "array",
+      "items": { "type": "string", "pattern": "^decision_[a-z0-9_\\-]+$" }
+    },
+    "execution_ids": {
+      "type": "array",
+      "items": { "type": "string", "pattern": "^execution_[a-z0-9_\\-]+$" }
+    },
+    "artifact_ids": {
+      "type": "array",
+      "items": { "type": "string", "pattern": "^artifact_[a-z0-9_\\-]+$" }
+    },
+    "event_ids": {
+      "type": "array",
+      "items": { "type": "string", "pattern": "^event_[a-z0-9_\\-]+$" }
+    },
+    "eval_ids": {
+      "type": "array",
+      "items": { "type": "string", "pattern": "^eval_[a-z0-9_\\-]+$" }
+    }
+  },
+  "additionalProperties": false
+}

schemas/spine_event.schema.json

@@ -0,0 +1,56 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "spine:spine_event",
+  "title": "SpineEvent",
+  "type": "object",
+  "required": [
+    "schema_name",
+    "schema_version",
+    "event_id",
+    "event_type",
+    "occurred_at",
+    "run_id",
+    "source_system",
+    "sequence",
+    "payload"
+  ],
+  "properties": {
+    "schema_name": { "const": "SpineEvent" },
+    "schema_version": { "type": "string", "const": "1.0.0" },
+    "event_id": { "type": "string", "pattern": "^event_[a-z0-9_\\-]+$" },
+    "event_type": {
+      "type": "string",
+      "enum": [
+        "task.created",
+        "decision.created",
+        "decision.approved",
+        "execution.requested",
+        "execution.dispatched",
+        "execution.started",
+        "execution.progress",
+        "execution.completed",
+        "execution.failed",
+        "artifact.created",
+        "eval.recorded",
+        "run.closed"
+      ]
+    },
+    "occurred_at": { "type": "string", "format": "date-time" },
+    "run_id": { "type": "string", "pattern": "^run_[a-z0-9_\\-]+$" },
+    "source_system": { "type": "string", "minLength": 1 },
+    "sequence": { "type": "integer", "minimum": 1 },
+    "payload": { "type": "object" },
+    "references": {
+      "type": "object",
+      "properties": {
+        "task_id": { "type": "string" },
+        "decision_id": { "type": "string" },
+        "execution_id": { "type": "string" },
+        "artifact_id": { "type": "string" },
+        "eval_id": { "type": "string" }
+      },
+      "additionalProperties": false
+    }
+  },
+  "additionalProperties": false
+}

schemas/system_manifest.schema.json

@@ -0,0 +1,48 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "spine:system_manifest",
+  "title": "SystemManifest",
+  "type": "object",
+  "required": [
+    "schema_name",
+    "schema_version",
+    "system_id",
+    "name",
+    "description",
+    "created_at",
+    "source_projects",
+    "runtime_targets",
+    "schema_inventory"
+  ],
+  "properties": {
+    "schema_name": { "const": "SystemManifest" },
+    "schema_version": { "type": "string", "const": "1.0.0" },
+    "system_id": { "type": "string", "minLength": 1 },
+    "name": { "type": "string", "minLength": 1 },
+    "description": { "type": "string", "minLength": 1 },
+    "created_at": { "type": "string", "format": "date-time" },
+    "source_projects": {
+      "type": "array",
+      "minItems": 1,
+      "items": {
+        "type": "object",
+        "required": ["project_id", "role", "path"],
+        "properties": {
+          "project_id": { "type": "string" },
+          "role": { "type": "string" },
+          "path": { "type": "string" }
+        },
+        "additionalProperties": false
+      }
+    },
+    "runtime_targets": {
+      "type": "array",
+      "items": { "type": "string" }
+    },
+    "schema_inventory": {
+      "type": "array",
+      "items": { "type": "string" }
+    }
+  },
+  "additionalProperties": false
+}

schemas/task_request.schema.json

@@ -0,0 +1,45 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "spine:task_request",
+  "title": "TaskRequest",
+  "type": "object",
+  "required": [
+    "schema_name",
+    "schema_version",
+    "task_id",
+    "title",
+    "description",
+    "requested_by",
+    "created_at",
+    "origin_system",
+    "operator_context",
+    "constraints",
+    "desired_outcomes"
+  ],
+  "properties": {
+    "schema_name": { "const": "TaskRequest" },
+    "schema_version": { "type": "string", "const": "1.0.0" },
+    "task_id": { "type": "string", "pattern": "^task_[a-z0-9_\\-]+$" },
+    "title": { "type": "string", "minLength": 1 },
+    "description": { "type": "string", "minLength": 1 },
+    "requested_by": { "type": "string", "minLength": 1 },
+    "created_at": { "type": "string", "format": "date-time" },
+    "origin_system": { "type": "string", "minLength": 1 },
+    "operator_context": { "$ref": "./operator_context.schema.json" },
+    "constraints": {
+      "type": "array",
+      "items": { "type": "string" }
+    },
+    "desired_outcomes": {
+      "type": "array",
+      "minItems": 1,
+      "items": { "type": "string" }
+    },
+    "workspace_ref": { "type": "string" },
+    "tags": {
+      "type": "array",
+      "items": { "type": "string" }
+    }
+  },
+  "additionalProperties": false
+}

scripts/validate_spine.py

@@ -0,0 +1,132 @@
+#!/usr/bin/env python3
+"""Local consistency checks for the Spine V1 scaffold.
+
+This script does not implement full JSON Schema validation. It validates the
+spec bundle at the repository-contract level using only the Python stdlib.
+"""
+
+from __future__ import annotations
+
+import json
+import sys
+from pathlib import Path
+
+
+ROOT = Path(__file__).resolve().parent.parent
+SCHEMAS = ROOT / "schemas"
+REGISTRY = ROOT / "registry"
+EXAMPLES = ROOT / "examples" / "run_lifecycle"
+
+REQUIRED_SCHEMAS = {
+    "OperatorContext": "operator_context.schema.json",
+    "TaskRequest": "task_request.schema.json",
+    "RoutingDecision": "routing_decision.schema.json",
+    "RunRecord": "run_record.schema.json",
+    "ExecutionRequest": "execution_request.schema.json",
+    "ExecutionStatus": "execution_status.schema.json",
+    "RouteTrace": "route_trace.schema.json",
+    "ArtifactManifest": "artifact_manifest.schema.json",
+    "EvalRecord": "eval_record.schema.json",
+    "SpineEvent": "spine_event.schema.json",
+    "SystemManifest": "system_manifest.schema.json",
+    "HarnessManifest": "harness_manifest.schema.json",
+    "AdapterManifest": "adapter_manifest.schema.json",
+}
+
+
+def load_json(path: Path):
+    with path.open("r", encoding="utf-8") as handle:
+        return json.load(handle)
+
+
+def require(condition: bool, message: str) -> None:
+    if not condition:
+        raise SystemExit(f"VALIDATION FAILED: {message}")
+
+
+def check_schema_inventory() -> None:
+    for schema_name, filename in REQUIRED_SCHEMAS.items():
+        path = SCHEMAS / filename
+        require(path.exists(), f"missing schema file: {filename}")
+        data = load_json(path)
+        require(data["title"] == schema_name, f"{filename} has unexpected title")
+
+
+def check_registry() -> None:
+    system_manifest = load_json(REGISTRY / "system_manifest.json")
+    require(system_manifest["schema_name"] == "SystemManifest", "system manifest schema name mismatch")
+    require(
+        sorted(system_manifest["schema_inventory"]) == sorted(REQUIRED_SCHEMAS.keys()),
+        "system manifest schema inventory is incomplete",
+    )
+
+    harness_ids = set()
+    for path in sorted((REGISTRY / "harnesses").glob("*.json")):
+        data = load_json(path)
+        require(data["schema_name"] == "HarnessManifest", f"{path.name} is not a harness manifest")
+        require(data["harness_id"] not in harness_ids, f"duplicate harness id: {data['harness_id']}")
+        harness_ids.add(data["harness_id"])
+
+    adapter_ids = set()
+    for path in sorted((REGISTRY / "adapters").glob("*.json")):
+        data = load_json(path)
+        require(data["schema_name"] == "AdapterManifest", f"{path.name} is not an adapter manifest")
+        require(data["adapter_id"] not in adapter_ids, f"duplicate adapter id: {data['adapter_id']}")
+        adapter_ids.add(data["adapter_id"])
+
+
+def check_examples() -> None:
+    task = load_json(EXAMPLES / "task_request.json")
+    decision = load_json(EXAMPLES / "routing_decision.json")
+    run = load_json(EXAMPLES / "run_record.json")
+    execution = load_json(EXAMPLES / "execution_request.json")
+    status = load_json(EXAMPLES / "execution_status.json")
+    trace = load_json(EXAMPLES / "route_trace.json")
+    artifact = load_json(EXAMPLES / "artifact_manifest.json")
+    eval_record = load_json(EXAMPLES / "eval_record.json")
+    events = load_json(EXAMPLES / "events.json")
+
+    require(task["schema_name"] == "TaskRequest", "task example schema mismatch")
+    require(decision["task_id"] == task["task_id"], "decision does not reference task")
+    require(run["task_id"] == task["task_id"], "run does not reference task")
+    require(execution["decision_id"] == decision["decision_id"], "execution does not reference decision")
+    require(execution["run_id"] == run["run_id"], "execution does not reference run")
+    require(status["execution_id"] == execution["execution_id"], "status does not reference execution")
+    require(status["run_id"] == run["run_id"], "status does not reference run")
+    require(trace["execution_id"] == execution["execution_id"], "trace does not reference execution")
+    require(artifact["run_id"] == run["run_id"], "artifact does not reference run")
+    require(eval_record["run_id"] == run["run_id"], "eval does not reference run")
+    require(eval_record["task_id"] == task["task_id"], "eval does not reference task")
+    require(run["decision_ids"] == [decision["decision_id"]], "run decision ids mismatch")
+    require(run["execution_ids"] == [execution["execution_id"]], "run execution ids mismatch")
+    require(run["artifact_ids"] == [artifact["artifact_id"]], "run artifact ids mismatch")
+    require(run["eval_ids"] == [eval_record["eval_id"]], "run eval ids mismatch")
+
+    sequences = [event["sequence"] for event in events]
+    require(sequences == list(range(1, len(events) + 1)), "event sequence must be contiguous starting at 1")
+    for event in events:
+        require(event["schema_name"] == "SpineEvent", f"event {event['event_id']} schema mismatch")
+        require(event["run_id"] == run["run_id"], f"event {event['event_id']} run id mismatch")
+
+    event_ids = [event["event_id"] for event in events]
+    require(run["event_ids"] == event_ids, "run event ids do not match event log")
+
+
+def main() -> None:
+    check_schema_inventory()
+    check_registry()
+    check_examples()
+    print("Spine validation OK")
+    print(f"Schemas: {len(REQUIRED_SCHEMAS)}")
+    print(f"Harness manifests: {len(list((REGISTRY / 'harnesses').glob('*.json')))}")
+    print(f"Adapter manifests: {len(list((REGISTRY / 'adapters').glob('*.json')))}")
+    print(f"Example files: {len(list(EXAMPLES.glob('*.json')))}")
+
+
+if __name__ == "__main__":
+    try:
+        main()
+    except SystemExit:
+        raise
+    except Exception as exc:  # pragma: no cover - defensive catch for local use
+        raise SystemExit(f"VALIDATION FAILED: unexpected error: {exc}") from exc