| 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. | |