1. Harness-agnostisch — kann Claude Code, OpenClaude, Codex, Cursor, OpenHands etc. als Execution-Layer orchestrieren
    2. Modell-agnostisch — Opus, GPT‑5.4, Sonnet, Gemini, Minimax austauschbar pro Track
    3. .md-Datenbank als Source-of-Truth — alle Instructions, CLAUDE.md, Skills, Sidecar-Regeln, Projekt-Briefs als versioniertes Markdown, adaptiv (kontextabhängig geladen)
    4. Parallel-native — mehrere Tracks gleichzeitig, nicht sequenziell
    5. Eval-integriert — jeder Track misst sich selbst (Token/Turn, Completion, Quality-Labels), Ergebnisse fließen zurück in die .md-DB
    6. Integriert eigene + fremde Projekte — also Adapter-Layer für externe Repos, nicht nur für Samuels Code
    7. Samuel-optimiert — ADHS-kompatibel, Sidecar-logik-native, kurze Feedback-Loops
    8. UI — sichtbar, nicht nur CLI. Dashboard für Tracks, Status, Metriken

    Das ist keine Kleinigkeit — das ist im Grunde ein Produkt, nicht ein Config-Job. Was du beschreibst überlappt stark mit Devin + LangSmith + ein Eval-Framework + ein
    Markdown-CMS — alles in einem.

    Was das für den 5-Tage-Plan heißt

    Dein „fertig" ist nicht in 5 Tagen erreichbar aus dem Stand. Aber ein lauffähiger Kern, auf dem du weiterbaust, ist drin:

    - Tag 1: OpenHands als Execution-Engine läuft (dein „Motor"). Gleichzeitig: .md-DB-Struktur definiert (einfach: ~/.harness/md-db/ mit projects/, instructions/, evals/,
    tracks/).
    - Tag 2: Adapter-Layer: dünne Python-Shell die aus .md-Einträgen Track-Configs generiert und an OpenHands/Claude Code/Codex weiterreicht. Das ist dein
    „harness-agnostisch".
    - Tag 3: Parallel-Queue (Temporal/Dagger oder simpler: tmux + Prefect). 3 Tracks gleichzeitig.
    - Tag 4: Eval-Hooks — pro Track werden Metriken nach Abschluss in die .md-DB zurückgeschrieben.
    - Tag 5: UI — einfachster Weg: statische HTML-SPA die die .md-DB rendert (dein frontier-llm-harness und sidebyside sind genau das Muster). Oder: Streamlit/Gradio.