Initial public upload from Projekte/ProjectIntakeTower

.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/ProjectIntakeTower", "--enable-web-dashboard", "false", "--open-web-dashboard", "false", "--enable-gui-log-window", "false"]
+cwd = "/home/smlflg/Projekte/ProjectIntakeTower"
+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/ProjectIntakeTower"
+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/ProjectIntakeTower"
+enabled = true
+startup_timeout_sec = 120
+tool_timeout_sec = 180

.hermes/plans/2026-05-04_194718-project-intake-audit-briefings.md

@@ -0,0 +1,141 @@
+# Plan — ProjectIntakeTower Audit Briefings Setup
+
+## Goal
+
+Create the requested ProjectIntakeTower intake structure and the first read-only audit briefing for `smlfg/KommandoZentrale`, without touching the source repo and without making any consolidation decision.
+
+Requested target root:
+
+`/home/smlflg/Projekte/ProjectIntakeTower`
+
+## Current Context / Assumptions
+
+- The user supplied a shell-style setup snippet that would create:
+  - `briefings/`
+  - `audits/kommandozentrale/`
+  - `audits/zentrale/`
+  - `audits/megaharness/`
+  - `briefings/01_audit_kommandozentrale.md`
+- This plan mode turn must not execute that setup yet.
+- Only this markdown plan is written during plan mode.
+- The actual audit described by the briefing is read-only against the source repo.
+- The only future audit output writes allowed by the briefing are under:
+  - `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/`
+- Luis owns final consolidation decisions. Any decision-shaped conclusion must be marked `NEEDS_HUMAN`.
+
+## Proposed Approach
+
+1. After plan approval, create the ProjectIntakeTower directory structure exactly as requested.
+2. Write the KommandoZentrale audit briefing file exactly at the requested path.
+3. Treat the briefing as an execution contract for a later bounded read-only audit lane/agent.
+4. Keep source repo inspection read-only and record source `git status --short` before and after the audit.
+5. Produce exactly the four requested audit artifacts for KommandoZentrale.
+
+## Step-by-Step Plan
+
+### 1. Create target directories
+
+Create these directories if missing:
+
+- `/home/smlflg/Projekte/ProjectIntakeTower/briefings/`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/zentrale/`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/megaharness/`
+
+Verification:
+
+- Check that each directory exists.
+
+### 2. Write the KommandoZentrale audit briefing
+
+Create or replace:
+
+`/home/smlflg/Projekte/ProjectIntakeTower/briefings/01_audit_kommandozentrale.md`
+
+Content should preserve the user's supplied audit contract, including:
+
+- Mission: audit public/local repo `smlfg/KommandoZentrale`.
+- Read-only source repo rules.
+- No branches, commits, pushes, PRs, refactors, or source modifications.
+- Only allowed audit writes under:
+  - `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/`
+- Context files to read if available:
+  - `/home/smlflg/Projekte/megaHarness/BRIEFING_LUIS.md`
+  - `/home/smlflg/Projekte/megaHarness/Höhlengleichnis.md`
+- Allowed investigation commands/tools.
+- Required source `git status --short` before and after.
+- Required output files and exact structure for `AGENT_FINDINGS.md`.
+
+Verification:
+
+- Read back the file path and confirm the expected title exists:
+  - `# READY — READ_ONLY_AUDIT — KommandoZentrale`
+
+### 3. Later audit execution contract
+
+When the audit is executed, the auditor should produce exactly these files:
+
+1. `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/AGENT_FINDINGS.md`
+2. `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/ARCHITECTURE_MAP.md`
+3. `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/RISK_REGISTER.md`
+4. `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/NEXT_ISSUES.md`
+
+The auditor must not write elsewhere.
+
+### 4. Recommended audit execution shape
+
+Use a bounded read-only audit worker/lane rather than a broad autonomous implementation agent.
+
+Minimum contract:
+
+- Objective: compact factual repo intake for Samuel and Luis.
+- Source repo: `smlfg/KommandoZentrale`, local path if available.
+- Mode: `READ_ONLY_AUDIT`.
+- Allowed source actions: inspect files, docs, configs, tests, git status/log.
+- Forbidden source actions: modify, branch, commit, push, PR, refactor.
+- Output directory: `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/`.
+- Stop condition: any consolidation verdict, archive decision, or architecture-anchor decision becomes `NEEDS_HUMAN`.
+
+## Files Likely To Change After Approval
+
+Only these setup files/directories should be created or changed:
+
+- `/home/smlflg/Projekte/ProjectIntakeTower/briefings/`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/zentrale/`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/megaharness/`
+- `/home/smlflg/Projekte/ProjectIntakeTower/briefings/01_audit_kommandozentrale.md`
+
+During the later audit, only these files should be written:
+
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/AGENT_FINDINGS.md`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/ARCHITECTURE_MAP.md`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/RISK_REGISTER.md`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/NEXT_ISSUES.md`
+
+## Tests / Validation
+
+After setup:
+
+1. Verify all target directories exist.
+2. Verify `01_audit_kommandozentrale.md` exists.
+3. Verify the briefing file contains:
+   - `READY — READ_ONLY_AUDIT — KommandoZentrale`
+   - `READ ONLY for the source repo`
+   - all four required output paths.
+
+After later audit:
+
+1. Verify source repo `git status --short` was recorded before and after.
+2. Verify all four audit output files exist.
+3. Verify no source repo files changed.
+4. Verify decision-shaped items are in `NEEDS_HUMAN`, not recommendations.
+5. Verify artifact content is compact and factual, without raw log dumps.
+
+## Risks, Tradeoffs, Open Questions
+
+- Risk: The local source repo path for `KommandoZentrale` may not exist. Mitigation: auditor should use local path if available or remote/public repo if accessible, and record which was used.
+- Risk: Context files in `/home/smlflg/Projekte/megaHarness/` may be missing. Mitigation: briefing explicitly says continue and do not block.
+- Risk: Audit drifts into consolidation recommendation. Mitigation: stop that reasoning and mark as `NEEDS_HUMAN`.
+- Risk: An audit agent might write outside the allowed output directory. Mitigation: use a strict lane/worker contract and verify output paths after completion.
+- Open question: Whether Samuel wants the setup file written exactly as supplied or wants additional briefing files for `zentrale` and `megaharness` next. This first plan only covers the supplied KommandoZentrale briefing.

00_OPERATOR_CHECKLIST.md

@@ -0,0 +1,63 @@
+# ProjectIntakeTower Operator Checklist
+
+Status: prepared for read-only audit night
+Target root: `/home/smlflg/Projekte/ProjectIntakeTower`
+Primary rule: generate audit facts, not architecture verdicts.
+
+## 1. Preflight
+
+- [ ] Confirm `briefings/` contains all four READY prompts.
+- [ ] Confirm `audits/` contains exactly these repo folders:
+  - `kommandozentrale/`
+  - `zentrale/`
+  - `megaharness/`
+- [ ] Do not use or modify `/home/smlflg/Projekte/project-intake-tower/artifacts/`.
+- [ ] Treat all dirty repo state as pre-existing unless an audit proves otherwise.
+- [ ] Do not create branches, commits, pushes, PRs, labels, or GitHub issues.
+
+## 2. Start Order
+
+- [ ] Start Session 1 with `briefings/01_audit_kommandozentrale.md`.
+- [ ] Start Session 2 with `briefings/02_audit_zentrale.md`.
+- [ ] Start Session 3 with `briefings/03_audit_megaharness.md`.
+- [ ] Wait until the three repo audits are done or clearly partial.
+- [ ] Start Session 4 with `briefings/04_aggregator.md`.
+
+## 3. Required Audit Outputs
+
+Each repo folder must contain exactly these four human-readable Markdown files:
+
+- [ ] `AGENT_FINDINGS.md`
+- [ ] `ARCHITECTURE_MAP.md`
+- [ ] `RISK_REGISTER.md`
+- [ ] `NEXT_ISSUES.md`
+
+The aggregator must write:
+
+- [ ] `audits/TOWER_HEALTH_OVERVIEW.md`
+
+## 4. Stop Conditions
+
+Stop the active session and write `NEEDS_HUMAN` when any of these happen:
+
+- [ ] The session needs to edit source code to continue.
+- [ ] The session wants to pick an architecture anchor.
+- [ ] The session wants to archive, fuse, or deprecate a repo.
+- [ ] The session finds secrets or credentials.
+- [ ] The session needs missing context outside the allowed scope.
+- [ ] The session starts planning PRs, branches, labels, or implementation work.
+
+## 5. Morning Verification
+
+- [ ] `audits/kommandozentrale/` has the four required files.
+- [ ] `audits/zentrale/` has the four required files.
+- [ ] `audits/megaharness/` has the four required files.
+- [ ] `audits/TOWER_HEALTH_OVERVIEW.md` exists.
+- [ ] The overview has no anchor verdict and no archive/fusion decision.
+- [ ] `git status --short` in `KomandoZentral` is unchanged from preflight.
+- [ ] `git status --short` in `Zentrale` has no new changes caused by this audit.
+- [ ] `git status --short` in `megaHarness` has no new changes caused by this audit.
+
+## 6. Success Definition
+
+The night is successful if Samuel can read the overview first, then scan each repo audit in under 5 minutes, and Luis receives factual inputs without losing ownership of the consolidation decision.

NIGHT_RUN_CHECKLIST.md

@@ -0,0 +1,69 @@
+# ProjectIntakeTower Night Run Checklist
+
+Date: 2026-05-04
+Goal: convert expiring Codex quota into useful, local, read-only audit artifacts without creating code drift, branches, PRs, or conflicts with Luis' consolidation assignment.
+
+## Hard Rules
+
+- Do not edit existing repo worktrees under `/home/smlflg/Projekte/KomandoZentral`, `/home/smlflg/Projekte/Zentrale`, or `/home/smlflg/Projekte/megaHarness`.
+- Prefer fresh source clones under `/tmp/project-intake-tower-src-2026-05-04/` when starting manual sessions.
+- If an existing local worktree is inspected, record its `git status --short` and treat dirty state as pre-existing context.
+- Write durable outputs only under `/home/smlflg/Projekte/ProjectIntakeTower/`.
+- Do not create branches, commits, pushes, issues, labels, or pull requests.
+- Do not make an anchor-repo recommendation, archive/keep verdict, or target architecture decision. That stays with Luis.
+- If an agent hits uncertainty that would require an architecture or product decision, mark `NEEDS_HUMAN` and continue documenting facts.
+
+## Source Snapshot
+
+| Repo | Local Path | Branch / Commit Signal |
+|---|---|---|
+| `smlfg/KommandoZentrale` | `/home/smlflg/Projekte/KomandoZentral` | `master`, `af2aa3f7479443803991239610add5343ccf43b3` |
+| `smlfg/Zentrale` | `/home/smlflg/Projekte/Zentrale` | `master`, `3153996 Prepare control tower prototype public handoff` |
+| `smlfg/MegaHarness` | `/home/smlflg/Projekte/megaHarness` | `master`, `452f9d5ebfb4e6b5f569b1804fdcfe880e08629e` |
+
+## Session Order
+
+- [x] Prepare Audit 1 with `briefings/01_audit_kommandozentrale.md`.
+- [x] Prepare Audit 2 with `briefings/02_audit_zentrale.md`.
+- [x] Prepare Audit 3 with `briefings/03_audit_megaharness.md`.
+- [x] Write the four required Markdown files for all three audit folders.
+- [x] Write `audits/TOWER_HEALTH_OVERVIEW.md`.
+
+## Required Output Per Repo
+
+Each repo output folder must contain:
+
+- [x] `AGENT_FINDINGS.md`
+- [x] `ARCHITECTURE_MAP.md`
+- [x] `RISK_REGISTER.md`
+- [x] `NEXT_ISSUES.md`
+
+Repo output folders:
+
+- [x] `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/`
+- [x] `/home/smlflg/Projekte/ProjectIntakeTower/audits/zentrale/`
+- [x] `/home/smlflg/Projekte/ProjectIntakeTower/audits/megaharness/`
+
+## Aggregator Output
+
+- [x] `/home/smlflg/Projekte/ProjectIntakeTower/audits/TOWER_HEALTH_OVERVIEW.md`
+
+The overview contains:
+
+- [x] Source snapshot table.
+- [x] Cross-repo capability comparison.
+- [x] Overlap and duplication map.
+- [x] Shared risk themes.
+- [x] Test and verifier gaps.
+- [x] `NEEDS_HUMAN` index.
+- [x] Morning review checklist.
+- [x] Explicit note: no architecture verdict.
+
+## Morning Verification
+
+- [x] `find /home/smlflg/Projekte/ProjectIntakeTower/audits -maxdepth 2 -type f | sort` shows the expected files.
+- [x] `git -C /home/smlflg/Projekte/KomandoZentral status --short` has no new audit-caused changes.
+- [x] `git -C /home/smlflg/Projekte/Zentrale status --short` still shows pre-existing dirty state, but no ProjectIntakeTower audit files.
+- [x] `git -C /home/smlflg/Projekte/megaHarness status --short` still shows pre-existing dirty state, but no ProjectIntakeTower audit files.
+- [x] No GitHub PRs, branches, or pushes were created by this run.
+- [x] Every file is concise enough to skim quickly.

README.md

@@ -0,0 +1,63 @@
+# ProjectIntakeTower
+
+Local read-only audit tower for the 2026-05-04 Codex quota night run.
+
+## Purpose
+
+This folder contains briefings and durable Markdown artifacts for three isolated repo audits plus one cross-repo synthesis. The goal is useful morning review material for Samuel and Luis without code drift, GitHub noise, or premature consolidation decisions.
+
+## Directory Layout
+
+```text
+ProjectIntakeTower/
+├── README.md
+├── 00_OPERATOR_CHECKLIST.md
+├── NIGHT_RUN_CHECKLIST.md
+├── briefings/
+│   ├── 01_audit_kommandozentrale.md
+│   ├── 02_audit_zentrale.md
+│   ├── 03_audit_megaharness.md
+│   └── 04_aggregator.md
+└── audits/
+    ├── kommandozentrale/
+    ├── zentrale/
+    ├── megaharness/
+    └── TOWER_HEALTH_OVERVIEW.md
+```
+
+## Source Handling
+
+Briefings are written for disposable source clones under:
+
+```text
+/tmp/project-intake-tower-src-2026-05-04/
+```
+
+The final audit artifacts are the source of truth for what was actually inspected. If an audit used an existing local worktree, it records that explicitly and treats dirty state as pre-existing context.
+
+Durable output belongs only under this `ProjectIntakeTower/` directory.
+
+## Rules
+
+- Existing local worktrees stay untouched.
+- No branches, commits, pushes, PRs, labels, or GitHub issues.
+- Audit agents write only Markdown artifacts.
+- Luis owns the consolidation verdict.
+- Use `NEEDS_HUMAN` when a question requires a product or architecture decision.
+
+## Quick Verification
+
+```bash
+find /home/smlflg/Projekte/ProjectIntakeTower/audits -maxdepth 2 -type f | sort
+```
+
+Expected per repo:
+
+- `AGENT_FINDINGS.md`
+- `ARCHITECTURE_MAP.md`
+- `RISK_REGISTER.md`
+- `NEXT_ISSUES.md`
+
+Expected cross-repo output:
+
+- `audits/TOWER_HEALTH_OVERVIEW.md`

REPO_OBSERVATION.md

@@ -0,0 +1,75 @@
+# Repo Observation
+
+## Sicher beobachtet
+
+- `ProjectIntakeTower` ist in `/home/smlflg/Projekte/ProjectIntakeTower` kein Git-Repository. `git status --short` und `git log --oneline -5` liefern `fatal: not a git repository`.
+- Top-Level-Dateien und Ordner:
+  - `README.md`
+  - `00_OPERATOR_CHECKLIST.md`
+  - `NIGHT_RUN_CHECKLIST.md`
+  - `briefings/`
+  - `audits/`
+  - `night_logs/`
+  - `.hermes/`
+- Es wurden keine Projekt-Manifeste gefunden: kein `package.json`, kein `pyproject.toml`, kein `Cargo.toml`, kein `go.mod`.
+- Es wurden keine App- oder Source-Verzeichnisse im Tower selbst gefunden: kein `src/`, kein `app/`, kein `tests/`.
+- Laut `README.md` ist der Zweck ein lokaler read-only Audit-Tower fuer drei isolierte Repo-Audits plus eine Cross-Repo-Synthese.
+- Laut `README.md` gehoeren dauerhafte Outputs nur in diesen `ProjectIntakeTower/` Ordner.
+- Laut `README.md`, `00_OPERATOR_CHECKLIST.md` und `NIGHT_RUN_CHECKLIST.md` gelten harte Grenzen: keine Branches, Commits, Pushes, PRs, Labels, Issues, Source-Edits oder Architektur-Verdikte.
+- Vorhandene Briefings:
+  - `briefings/01_audit_kommandozentrale.md`
+  - `briefings/02_audit_zentrale.md`
+  - `briefings/03_audit_megaharness.md`
+  - `briefings/04_aggregator.md`
+- Vorhandene Audit-Artefakte pro auditiertem Projekt:
+  - `audits/kommandozentrale/AGENT_FINDINGS.md`
+  - `audits/kommandozentrale/ARCHITECTURE_MAP.md`
+  - `audits/kommandozentrale/RISK_REGISTER.md`
+  - `audits/kommandozentrale/NEXT_ISSUES.md`
+  - `audits/zentrale/AGENT_FINDINGS.md`
+  - `audits/zentrale/ARCHITECTURE_MAP.md`
+  - `audits/zentrale/RISK_REGISTER.md`
+  - `audits/zentrale/NEXT_ISSUES.md`
+  - `audits/megaharness/AGENT_FINDINGS.md`
+  - `audits/megaharness/ARCHITECTURE_MAP.md`
+  - `audits/megaharness/RISK_REGISTER.md`
+  - `audits/megaharness/NEXT_ISSUES.md`
+- Vorhandene Cross-Repo-Synthese: `audits/TOWER_HEALTH_OVERVIEW.md`.
+- `NIGHT_RUN_CHECKLIST.md` markiert die drei Repo-Audits und den Aggregator als abgeschlossen.
+- `audits/TOWER_HEALTH_OVERVIEW.md` enthaelt eine Source-Snapshot-Tabelle fuer:
+  - `smlfg/KommandoZentrale`
+  - `smlfg/Zentrale`
+  - `smlfg/MegaHarness`
+- `audits/TOWER_HEALTH_OVERVIEW.md` sagt ausdruecklich, dass keine Anchor-, Archiv-, Merge- oder Implementierungs-Empfehlung getroffen wird.
+- Die Suche nach Hinweisen wie `NEEDS_HUMAN`, `decision`, `gate`, `risk` zeigt viele Treffer in Checklisten, Briefings und Audit-Artefakten.
+- In den gesuchten Treffern wurden keine `TODO`- oder `FIXME`-Hinweise sichtbar.
+- `night_logs/LANDING_NOTE_2026-05-04_19-55.md` dokumentiert, dass nach dem Night Run keine neuen Agenten, Architekturentscheidungen, PRs, Pushes oder Branches gestartet werden sollen.
+
+## Vermutlich
+
+- `ProjectIntakeTower` ist vermutlich ein Markdown-only Intake- und Audit-Container, kein ausfuehrbares Produkt. Begruendung: Es gibt keine Manifeste, keine Source-Struktur, keine Tests und die vorhandenen Dokumente beschreiben einen read-only Audit-Tower.
+- Die belastbarsten Daten liegen vermutlich unter `audits/`, nicht unter `briefings/`. Begruendung: Die Briefings sind Arbeitsauftraege; die Audit-Dateien sind laut `README.md` und Checklisten die dauerhaften Outputs.
+- `.hermes/plans/2026-05-04_194718-project-intake-audit-briefings.md` ist vermutlich ein frueheres Setup-Planartefakt, nicht der aktuelle Wahrheitsstand. Begruendung: Die erledigten Audit-Outputs liegen danach unter `audits/`.
+- Fuer Statuskarten je Projekt sind vermutlich vor allem `AGENT_FINDINGS.md`, `ARCHITECTURE_MAP.md`, `RISK_REGISTER.md` und `NEXT_ISSUES.md` nutzbar. Begruendung: Diese Dateien enthalten beobachtete Dateien, Entry Points, Risiken, offene Fragen und naechste Issue-Kandidaten.
+
+## Unklar
+
+- Es ist unklar, wann und durch wen der Tower selbst zuletzt geaendert wurde, weil kein Git-Verlauf vorhanden ist.
+- Es ist unklar, ob die vorhandenen Audit-Artefakte bereits final menschlich reviewt wurden oder nur Night-Run-Ergebnisse sind.
+- Es ist unklar, ob lokale Dirty States in `/home/smlflg/Projekte/Zentrale` und `/home/smlflg/Projekte/megaHarness` spaeter beruecksichtigt werden sollen. Die vorhandenen Audits verwenden laut Artefakten Public Clones als Quelle.
+- Es ist unklar, ob einzelne auditierte Projekte Produkt, Experiment, aktiv, tot oder Konsolidierungskandidat sind. Die vorhandenen Dokumente vermeiden diese Entscheidung ausdruecklich.
+- Es ist unklar, ob die auditieren Quell-Repos aktuell lauffaehig sind. Die Audit-Artefakte dokumentieren, dass Tests nicht ausgefuehrt wurden.
+- Es ist unklar, ob `NEXT_ISSUES.md` als echte Backlog-Quelle verwendet werden soll. Die vorhandenen Dokumente behandeln sie als Kandidaten, nicht als automatisch auszufuehrende Arbeit.
+
+## Risiken bei Weiterarbeit
+
+- Blindes Bauen wuerde den Tower leicht mit einem App- oder Produkt-Repo verwechseln, obwohl hier keine Codebasis beobachtet wurde.
+- Eine neue App, UI oder Architektur koennte die dokumentierte Rolle als read-only Audit-Container verwischen.
+- Automatisches Umsetzen von `NEXT_ISSUES.md` koennte menschliche Gates und Konsolidierungsentscheidungen ueberspringen.
+- Eine Statusansicht koennte Public-Clone-Fakten mit lokalen Dirty States vermischen, besonders bei `Zentrale` und `MegaHarness`.
+- Eine lauffaehige Annahme ueber auditierte Projekte waere riskant, weil die vorhandenen Audits Tests und Runtime-Verifikation nicht ausgefuehrt haben.
+- Eine Entscheidung ueber Anchor, Archivierung, Fusion oder Produktstatus wuerde den dokumentierten Grenzen des Towers widersprechen.
+
+## Kleinste reversible nächste Aktion
+
+Nur Status feststellen: `audits/TOWER_HEALTH_OVERVIEW.md` lesen und danach pro Projekt genau `AGENT_FINDINGS.md` verdichten, ohne zu bauen, zu migrieren, Issues anzulegen oder Architekturentscheidungen zu treffen.

audits/TOWER_HEALTH_OVERVIEW.md

@@ -0,0 +1,121 @@
+# Tower Health Overview
+
+## 1. Executive summary
+
+- All three requested public repos were auditable from fresh temporary clones.
+- KommandoZentrale is a compact deterministic routing engine with CLI, FastAPI UI, YAML decisions, and local feedback state.
+- Zentrale is the broadest implemented orchestration prototype with CLI, TUI, Web/API, registries, context packs, run tracking, and OpenCode delegation.
+- MegaHarness is doctrine/handoff material in public HEAD, not an executable implementation repo.
+- The strongest overlap is routing/policy: KommandoZentrale implements it, Zentrale partially implements/bridges it, MegaHarness plans it.
+- The clearest distinct Zentrale asset is generated phase/harness context packs.
+- The clearest distinct KommandoZentrale asset is explainable confidence-gated routing output.
+- The clearest distinct MegaHarness asset is the L0-L4 doctrine plus build-vs-integrate and Höhlengleichnis method.
+- Main shared risk: docs, runtime state, and policy ownership can drift if treated as already consolidated.
+- No anchor, archive, merge, or implementation recommendation is made here.
+
+## 2. Input coverage
+
+| Repo | AGENT_FINDINGS | ARCHITECTURE_MAP | RISK_REGISTER | NEXT_ISSUES | Notes |
+|------|----------------|------------------|---------------|-------------|-------|
+| KommandoZentrale | present | present | present | present | Public clone `af2aa3f`; temp clone clean. |
+| Zentrale | present | present | present | present | Public clone `3153996`; local repo is dirty and was not used as truth. |
+| MegaHarness | present | present | present | present | Public clone `452f9d5`; local `BRIEFING_LUIS.md` is dirty and was not used as truth. |
+
+## 3. Cross-repo comparison
+
+| Dimension | KommandoZentrale | Zentrale | MegaHarness | Notes |
+|----------|------------------|----------|-------------|-------|
+| apparent purpose | Deterministic harness routing and YAML decision output | Local adaptive agent orchestration/control-tower skeleton | Meta-harness doctrine and Luis handoff | Purposes overlap but maturity differs. |
+| maturity | Small executable prototype with tests/docs | Broad executable prototype with many surfaces and tests/docs | Markdown-only doctrine in public HEAD | Do not compare linearly as equal implementation repos. |
+| entrypoints | `kz`, `kz-web`, FastAPI `/api/route` | `zentrale`, dashboard, serve, web APIs, context-pack/run commands | Docs only | MegaHarness has human-reading entrypoints only. |
+| UI/backend presence | Embedded FastAPI web UI | FastAPI/WebSocket, static SPA, Textual TUI | UI described but not implemented | UI behavior verification differs. |
+| harness integration | Recommendation only | Static route, KZ bridge, OpenCode delegation path | Adapter protocol described | Zentrale has live execution machinery. |
+| state model | `DECISIONS/`, `DATA/outcomes.yaml`, latest cache | `projects/`, context packs, `runs/`, logs, learning/effectiveness | Planned MD-DB and eval JSONL | State contracts need alignment. |
+| verification story | pytest tree; README commands; no CI observed | broad pytest tree; validators/doctor docs; no CI observed | no tests/verifier observed | Controlled verifier pass remains needed. |
+| docs quality | strong schema/architecture docs with some naming drift | broad README/docs/registries with surface drift | strong doctrine docs but no README/schema examples | Different doc gaps. |
+| consolidation relevance | routing policy and confidence evidence | concrete workflow/context/run implementation | conceptual topology and decision method | Relevance is factual, not a verdict. |
+| main unknown | cache/store/naming contract | cwd/phase/web-surface contract | local/public briefing and MD-DB concrete schema | Human questions are concentrated here. |
+
+## 4. Observed overlaps
+
+| Overlap | Repos involved | Evidence | Why it matters |
+|---------|----------------|----------|----------------|
+| Routing policy | KommandoZentrale, Zentrale, MegaHarness | KZ `classify/rules/confidence`; Zentrale `routing.py`; MegaHarness Task-Router doctrine. | Multiple routing authorities can diverge. |
+| Harness vocabulary | All three | KZ harness registry; Zentrale harness/profile registry; MegaHarness adapter layer. | Names and capabilities need mapping. |
+| Markdown/context artifacts | Zentrale, MegaHarness, KommandoZentrale | Zentrale context-pack templates; MegaHarness MD-DB doctrine; KZ YAML decisions/docs. | Artifact shapes may become contracts. |
+| Local UI/control tower surface | KommandoZentrale, Zentrale, MegaHarness | KZ web UI; Zentrale TUI/Web/SPAs; MegaHarness L4 UI plan. | UI promises should be tied to implemented behavior. |
+| Feedback/eval loop | All three | KZ outcome updates; Zentrale effectiveness learning; MegaHarness eval JSONL doctrine. | Feedback should not affect routing unless semantics are aligned. |
+| Samuel-specific operating layer | All three | KZ operator-state flags; Zentrale phase/harness profiles; MegaHarness Sidecar/USP docs. | Personalization is a cross-cutting asset. |
+
+## 5. Distinct assets
+
+| Repo | Distinct asset | Evidence | Possible relevance |
+|------|----------------|----------|--------------------|
+| KommandoZentrale | Confidence-gated YAML routing decision | `DECISION_OUTPUT_SCHEMA.md`, `src/kz/service.py`, `src/kz/confidence.py`. | Reusable routing-decision contract. |
+| KommandoZentrale | Static harness registry with evidence caps | `src/kz/registry.py`. | Factual input for policy comparison. |
+| Zentrale | Phase/harness-specific context-pack generator | `src/zentrale/context_pack.py`, `templates/context-pack/`. | Concrete implementation of adaptive Markdown context. |
+| Zentrale | Run records and learning/effectiveness loop | `src/zentrale/run_tracking.py`, `src/zentrale/registry_learning.py`. | Execution history and feedback surface. |
+| Zentrale | Multi-surface operator UI | `dashboard/`, `web/`, `src/zentrale/web/`. | Existing control-tower UX experiments. |
+| MegaHarness | L0-L4 doctrine | `ARCHITECTURE.md`. | Shared conceptual map for Luis' review. |
+| MegaHarness | Build-vs-integrate heuristic | `Artefakt_USP.md`. | Prevents commodity-code expansion. |
+| MegaHarness | Höhlengleichnis categories | `Höhlengleichnis.md`. | Candidate classification method, not final verdict. |
+
+## 6. Consolidation risks
+
+| Risk | Affected repos | Evidence | Why Luis/Samuel should care |
+|------|----------------|----------|-----------------------------|
+| Policy ownership ambiguity | All three | KZ routing engine; Zentrale static/KZ routing; MegaHarness Task-Router doctrine. | Same task can receive different recommendations. |
+| Runtime maturity mismatch | All three | KZ/Zentrale have code; MegaHarness public clone is docs-only. | Comparing repos as equal codebases would mislead. |
+| State contract drift | KommandoZentrale, Zentrale, MegaHarness | KZ decisions/cache; Zentrale projects/runs/context packs; MegaHarness planned MD-DB. | Data location and schema choices affect future handoff. |
+| UI promise drift | KommandoZentrale, Zentrale, MegaHarness | KZ embedded UI; Zentrale TUI/Web with stub routes; MegaHarness UI doctrine. | UI surfaces may suggest more functionality than exists. |
+| Local/public divergence | Zentrale, MegaHarness | startcheck local dirty state; public temp clones clean. | Tomorrow's reader must know which snapshot is authoritative. |
+| Verification gap | All three | no CI observed; tests not run in audit; MegaHarness has no tests. | Human decisions should not assume green verification. |
+| Scope expansion pressure | Zentrale, MegaHarness | broad Zentrale surfaces; MegaHarness multi-layer/product doctrine. | The audit should support decisions, not create new workstreams. |
+
+## 7. Open questions for Luis
+
+1. Which routing facts from KommandoZentrale are unique policy value versus duplicate implementation?
+2. Which Zentrale surfaces are evidence of product direction versus experiments?
+3. Does Zentrale's context-pack generator satisfy part of the MegaHarness MD-context concept?
+4. Which state contracts must be preserved: YAML decisions, context packs, run logs, eval JSONL, or a subset?
+5. Which integration surface is safest to treat as a boundary: CLI, Python module, HTTP API, or file contract?
+6. How should routing feedback be compared across KZ outcomes, Zentrale effectiveness, and MegaHarness eval doctrine?
+7. Which repo contains implementation evidence and which contains decision doctrine?
+8. Which current risks block a consolidation memo from being precise?
+9. What additional evidence, if any, is needed from sibling repos before a verdict?
+10. Which terminology should be normalized before any topology decision?
+
+## 8. Open questions for Samuel
+
+1. Should Luis read public clones only, or also dirty local Zentrale/megaHarness state?
+2. Which `BRIEFING_LUIS.md` version is intended for tomorrow?
+3. What must be emotionally/conceptually preserved from the MegaHarness doctrine?
+4. Which local UI surface actually feels useful: KZ web, Zentrale TUI, Zentrale browser UI, or none yet?
+5. Is the latest-decision cache acceptable as normal KZ behavior?
+6. Should harnesses run from the project root or generated context-pack directory?
+7. Which spelling should be canonical for KommandoZentrale/KomandoZentral?
+8. Which artifacts are active work product versus prior art?
+9. What should be sent to Luis as the exact input package?
+10. Which decision should not be rushed tomorrow morning?
+
+## 9. Candidate next actions
+
+| Action | Owner candidate | Input needed | Output | Human gate |
+|--------|-----------------|--------------|--------|------------|
+| read/review | Samuel | `audits/TOWER_HEALTH_OVERVIEW.md` and three `AGENT_FINDINGS.md` files | Shared factual baseline | no |
+| read/review | Luis | all 13 audit files plus public repo links | Independent consolidation understanding | no |
+| decide | Samuel | local/public dirty-state summary | Which snapshot Luis should inspect | yes |
+| decide | Samuel | KZ naming evidence | Canonical spelling for handoff | yes |
+| compare | Luis | KZ/Zentrale/MegaHarness architecture maps | Routing/context/state comparison notes | yes |
+| extract evidence | Samuel or assistant | sibling repo references from MegaHarness docs | Evidence matrix for Sidecar/eval/UI claims | yes |
+| tag | Samuel | repo list and current intent | Human-readable active/prior-art/context tags | yes |
+| write decision memo | Luis | audit files plus Samuel clarifications | `KONSOLIDIERUNG_LUIS.md` or equivalent memo | yes |
+
+## 10. Morning checklist
+
+- Read first: `audits/TOWER_HEALTH_OVERVIEW.md`.
+- Then read: each repo's `AGENT_FINDINGS.md`.
+- Then skim: `ARCHITECTURE_MAP.md` for the repo Luis wants to inspect first.
+- Do not immediately decide which repo is anchor or archive target.
+- Send Luis: this `audits/` folder, public repo URLs, and Samuel's answer about public-vs-local dirty state.
+- Keep `NEXT_ISSUES.md` files as candidate backlog only; do not create GitHub issues from them before human review.

audits/kommandozentrale/AGENT_FINDINGS.md

@@ -0,0 +1,79 @@
+# Agent Findings — KommandoZentrale
+
+## 1. Scope
+- Repo/source: fresh public clone `https://github.com/smlfg/KommandoZentrale.git` at `af2aa3f` in `/tmp/tower-audit-KommandoZentrale`.
+- Inspection mode: read-only file/config inspection; no target repo edits; no branches, commits, pushes, PRs, or issues.
+- Output folder: `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/`.
+- Timestamp: 2026-05-04T18:04:02Z.
+- Auditor: Codex read-only audit operator.
+- Important constraints: no architecture anchor verdict; no consolidation recommendation; tests not executed because audit goal is artifact generation and setup may write caches.
+
+## 2. Repo identity
+- What this repo appears to be: deterministic harness-routing engine for AI work.
+- Primary purpose: classify a task, combine operator state and task modifiers, recommend a harness, and emit explainable YAML decisions.
+- Main language/framework: Python package using PyYAML, FastAPI, uvicorn, pytest, and ruff.
+- Apparent maturity: small public handoff prototype with CLI, local web UI, persistence, docs, and focused tests.
+- Main entry points: `kz = "kz.cli:main"`, `kz-web = "kz.web:run"`, `python -m kz`, FastAPI app in `src/kz/web.py`.
+- Important docs/configs: `README.md`, `pyproject.toml`, `SOFTWARE_ARCHITEKTUR.md`, `DECISION_OUTPUT_SCHEMA.md`, `TASK_TAXONOMY_V1.md`, `WEB_UI_PLAN.md`.
+- Evidence: `README.md` describes CLI/Web/API usage; `pyproject.toml` defines package, dependencies, scripts, pytest paths; `src/kz/service.py` contains the shared routing pipeline.
+
+## 3. Top observations
+
+| ID | Observation | Evidence | Why it matters |
+|----|-------------|----------|----------------|
+| KZ-O1 | CLI and Web share one routing service. | `src/kz/cli.py` calls `route_request`; `src/kz/web.py` POST `/api/route` calls the same service. | Reduces ambiguity about the core behavior surface. |
+| KZ-O2 | Routing is deterministic and rule-based, not LLM-driven. | `SOFTWARE_ARCHITEKTUR.md` says heuristic rules instead of ML/LLM; `src/kz/classify.py`, `src/kz/rules.py`, `src/kz/confidence.py`. | Important for consolidation because this is a policy engine, not an execution harness. |
+| KZ-O3 | Output contract is YAML decision data. | `DECISION_OUTPUT_SCHEMA.md`; `src/kz/persist.py` serializes `RoutingDecision` to YAML. | Provides an integration surface for other tools. |
+| KZ-O4 | Persistence is local and CWD-sensitive. | `save_decision()` writes to `os.getcwd()/DECISIONS`; `list_decision_files()` reads `Path(os.getcwd()) / "DECISIONS"`. | Can surprise callers if embedded from another repo. |
+| KZ-O5 | A home-cache side effect exists even for unsaved routes. | `route_request()` calls `write_latest_decision()`; `latest_decision_path()` defaults to `~/.cache/kz/latest-decision.json`. | Read-only callers need to know that route calls can still write cache state. |
+| KZ-O6 | The web app exposes decision review and outcome patching. | Endpoints `/api/decisions`, `/api/decisions/{filename}`, `/api/decisions/{filename}/outcome` in `src/kz/web.py`. | Outcome feedback is more than static routing docs. |
+| KZ-O7 | Harness registry includes confidence caps and evidence status. | `src/kz/registry.py` defines profiles for AgentArena, Claude Code, Hermes, OpenCode, Codex CLI, Aider, Gemini MCP. | Useful factual asset for Luis without deciding repo ownership. |
+| KZ-O8 | Public repo naming still carries a local spelling mismatch. | `pyproject.toml` homepage points to `https://github.com/smlflg/KomandoZentral`; public audit source is `smlfg/KommandoZentrale`. | Naming can confuse handoff readers and automation. |
+
+## 4. Strengths
+
+| Strength | Evidence | Relevance for consolidation |
+|----------|----------|-----------------------------|
+| Compact core pipeline | `src/kz/service.py` coordinates classification, operator state, rules, confidence, persistence. | Easy to reason about as a single routing component. |
+| Explicit task taxonomy and schema docs | `TASK_TAXONOMY_V1.md`, `DECISION_OUTPUT_SCHEMA.md`. | Gives Luis concrete contracts to compare against other routing layers. |
+| CLI/API parity at the routing core | `src/kz/cli.py`, `src/kz/web.py`, `src/kz/service.py`. | Reduces duplicate behavior inside this repo. |
+| Focused test tree exists | `tests/test_cli.py`, `tests/test_routing.py`, `tests/test_api.py`, `tests/test_confidence.py`, `tests/test_web_e2e.py`. | Verification path is visible even though tests were not run in this audit. |
+| Explainability is a stated design goal | `SOFTWARE_ARCHITEKTUR.md` says explainable by design and confidence-gated. | Matches the control-tower need for readable routing decisions. |
+
+## 5. Weaknesses / gaps
+
+| Gap | Evidence | Risk |
+|-----|----------|------|
+| Cache writes are implicit | `route_request()` catches `OSError` around `write_latest_decision()`. | Read-only invocations may still mutate user cache. |
+| CWD-dependent decision store | `persist.py` builds paths from `os.getcwd()`. | Embedding from Zentrale or another orchestrator can write decisions into unexpected folders. |
+| Public/local repo name mismatch | `pyproject.toml` homepage uses `KomandoZentral`; requested public repo is `KommandoZentrale`. | Handoff confusion and broken links. |
+| No CI config found in inspected tree | `find` showed no `.github/workflows` at depth inspected. | Verification may depend on local discipline. |
+| Web UI is embedded in one Python file | `src/kz/web.py` contains API plus large inline HTML/CSS/JS. | Browser behavior is harder to validate and evolve cleanly. |
+
+## 6. Test / CI / verification situation
+- Existing tests: pytest tests exist for CLI, routing, confidence, API, web string/e2e behavior, and review layer.
+- CI config: no CI workflow file observed in the inspected public tree.
+- How to run: `uv run pytest -q`, `uv run ruff check .`, and `uv build` are documented in `README.md`.
+- Whether tests were run: not run in this execution.
+- If not run: why not: package-manager/test execution can write caches and the user requested a controlled read-only audit; file/config inspection was sufficient for the handoff artifact.
+- Risk: tests may be stale or environment-sensitive until Samuel/Luis run a controlled verifier pass.
+
+## 7. Dependency / setup situation
+- Package managers: `uv` is documented; editable `pip install -e .` is an alternative.
+- Lockfiles: `uv.lock` exists.
+- Runtime assumptions: Python `>=3.12`; PyYAML, FastAPI, uvicorn; dev dependencies include httpx, pytest, ruff.
+- Missing setup docs: no CI setup path observed; no explicit cache/location contract for `KZ_CACHE_DIR`.
+- Fragile assumptions: current working directory determines `DECISIONS/`; default cache path is under the user's home directory.
+
+## 8. Pre-existing local state
+- Public temp clone state: `git status --short` was empty.
+- Local repo caveat: `/home/smlflg/Projekte/KomandoZentral` exists and appeared clean during startcheck, but the audit used the public clone as source of truth.
+- Dirty state interpretation: no local dirty state was interpreted as audit output.
+
+## 9. NEEDS_HUMAN
+
+| Question | Why human judgment is needed | Suggested reader |
+|----------|------------------------------|------------------|
+| Should the public handoff standardize on `KommandoZentrale` or legacy `KomandoZentral` spelling? | Both spellings appear in paths/metadata and changing naming affects links. | Samuel |
+| Is implicit `~/.cache/kz/latest-decision.json` writing acceptable for read-only route calls? | This is product/ops intent, not just code mechanics. | Samuel/Luis |
+| Should outcome feedback be part of the current consolidation surface? | Web/API support outcome updates, while docs position the tool mainly as routing decision output. | Luis |

audits/kommandozentrale/ARCHITECTURE_MAP.md

@@ -0,0 +1,91 @@
+# Architecture Map — KommandoZentrale
+
+## 1. High-level map
+
+KommandoZentrale is a compact deterministic routing service. The visible layers are:
+- Input adapters: CLI in `src/kz/cli.py`, local FastAPI app in `src/kz/web.py`, and module shims under `kz/`.
+- Core pipeline: `src/kz/service.py` coordinates classifier, operator-state resolver, routing rules, confidence logic, harness registry, and persistence.
+- Domain model: enums/dataclasses in `src/kz/models.py`.
+- Local state: YAML decisions under `DECISIONS/`, outcome updates, and latest-decision cache.
+
+## 2. File / directory map
+
+| Path | Role | Notes |
+|------|------|-------|
+| `README.md` | Operator-facing setup and usage | Documents CLI, Web UI, API, tests, and runtime output dirs. |
+| `pyproject.toml` | Python package config | Defines `kz` and `kz-web` scripts, dependencies, pytest/ruff config. |
+| `src/kz/cli.py` | CLI adapter | Builds `RouteRequest`, prints YAML, handles `outcome`. |
+| `src/kz/service.py` | Core routing pipeline | Shared by CLI and API. |
+| `src/kz/classify.py` | Task classifier and modifier parser | Regex keyword classifier. |
+| `src/kz/rules.py` | Harness routing rules | Applies task class, modifiers, operator state. |
+| `src/kz/confidence.py` | Confidence gate | Converts routing confidence to direct/experiment/no recommendation levels. |
+| `src/kz/registry.py` | Harness registry | Static profiles and confidence caps. |
+| `src/kz/persist.py` | YAML persistence | Writes/reads `DECISIONS/` relative to CWD. |
+| `src/kz/latest_decision.py` | Latest decision cache | Defaults to `~/.cache/kz/latest-decision.json`. |
+| `src/kz/web.py` | FastAPI API plus embedded web UI | Exposes routing, decision listing/detail/raw, outcome patch. |
+| `tests/` | Verification suite | Focused pytest files for core and web/API surfaces. |
+
+## 3. Entry points
+
+| Entry point | Type | Evidence | Notes |
+|-------------|------|----------|-------|
+| `kz` | CLI script | `pyproject.toml` maps to `kz.cli:main`. | Main routing command. |
+| `python -m kz` | Python module | `README.md`; `kz/__main__.py`; `src/kz/__main__.py`. | Local/module execution path. |
+| `kz outcome` | CLI subcommand | `src/kz/cli.py` handles `raw_args[0] == "outcome"`. | Updates stored decision outcome. |
+| `kz-web` | CLI script | `pyproject.toml` maps to `kz.web:run`. | Starts uvicorn on localhost. |
+| `GET /health` | API | `src/kz/web.py`. | Health probe. |
+| `POST /api/route` | API | `src/kz/web.py`. | Calls the same `route_request()` pipeline as CLI. |
+| `GET /api/decisions` | API | `src/kz/web.py`. | Lists local YAML decisions. |
+| `PATCH /api/decisions/{filename}/outcome` | API | `src/kz/web.py`. | Writes feedback into decision files. |
+
+## 4. Data/control flow
+
+- User/input flow: user supplies a task plus optional operator-state/modifier flags through CLI or `/api/route`.
+- Agent/control flow: no live agent execution; the system recommends a harness and fallback with confidence.
+- Persistence/state flow: optional `--save` writes YAML to `DECISIONS/`; outcome updates mutate existing YAML; latest decision cache writes under `KZ_CACHE_DIR` or `~/.cache/kz`.
+- External API/tool flow: local FastAPI server only; no observed GitHub/MCP/remote service calls in runtime routing.
+
+## 5. Interfaces and integration surfaces
+
+| Interface | Direction | Evidence | Consolidation relevance |
+|-----------|-----------|----------|-------------------------|
+| CLI `kz` | inbound | `pyproject.toml`, `src/kz/cli.py` | Simple integration point for Zentrale or operator scripts. |
+| YAML decision schema | outbound/inbound | `DECISION_OUTPUT_SCHEMA.md`, `src/kz/persist.py` | Candidate contract for routing decisions. |
+| FastAPI route API | inbound/outbound | `src/kz/web.py` | Local UI/API surface for routing and review. |
+| `DECISIONS/` | local state | `README.md`, `persist.py` | Durable record but CWD-sensitive. |
+| `DATA/outcomes.yaml` | local state | `README.md`, `persist.py` outcome helpers | Feedback learning surface. |
+| Latest cache | local state | `latest_decision.py` | Hidden side effect unless configured. |
+| Harness registry | internal config | `src/kz/registry.py` | Contains reusable harness profile/evidence facts. |
+
+## 6. State and persistence
+
+- Files: YAML decisions in `DECISIONS/`; `DATA/outcomes.yaml`; latest-decision JSON cache.
+- Databases: none observed.
+- Logs: no formal log directory observed.
+- Caches: `~/.cache/kz/latest-decision.json` by default.
+- Runtime state: current working directory affects decision paths.
+- Unknowns: whether the cache write is intended for all integrations or only interactive CLI use.
+
+## 7. Configuration model
+
+- Where config lives: CLI flags, static registry in Python, pytest/ruff config in `pyproject.toml`.
+- How profiles/env vars are handled: `KZ_CACHE_DIR` can override latest-decision cache location.
+- Secrets risk: no secret files observed; low direct secret risk.
+- Missing config docs: cache override and CWD persistence behavior are not prominent in README.
+
+## 8. Architecture risks
+
+| Risk | Evidence | Effect |
+|------|----------|--------|
+| Hidden write on read-like route calls | `route_request()` writes latest-decision cache even when `save` is false. | Harder to embed in strict read-only automation. |
+| CWD-sensitive state | `persist.py` uses `os.getcwd()`. | Parent orchestrator may write/read decisions in the wrong project. |
+| Naming ambiguity | `pyproject.toml` homepage points to legacy spelling. | Public handoff and automation may drift. |
+| Embedded Web UI complexity | `src/kz/web.py` includes API and large inline UI. | Browser behavior can drift without dedicated frontend tests. |
+| Static harness policy | `src/kz/registry.py`, `src/kz/rules.py`. | Needs explicit ownership if multiple repos also route harnesses. |
+
+## 9. Open architecture questions
+
+- Should KommandoZentrale be consumed as CLI, Python library, HTTP API, or only as reference policy?
+- Should latest-decision cache writes be opt-in for integrations?
+- Should `DECISIONS/` be rooted in this repo, caller workspace, or a configured path?
+- Which parts of the harness registry are factual evidence versus Samuel-specific preference?

audits/kommandozentrale/NEXT_ISSUES.md

@@ -0,0 +1,80 @@
+# Next Issue Candidates — KommandoZentrale
+
+Diese Datei enthält nur Issue-Kandidaten.
+Keine Issues erstellen.
+Keine Labels erstellen.
+Keine PRs öffnen.
+
+## Issue candidates
+
+### ISSUE-1: Clarify Public Repo Naming
+
+- Type: docs/metadata
+- Why this matters: Public handoff uses `KommandoZentrale`, while local metadata still points to `KomandoZentral`.
+- Evidence: `pyproject.toml` homepage; requested public repo URL.
+- Suggested scope: Add/update a short naming note and metadata once Samuel confirms canonical spelling.
+- Non-goals: No repo rename, no redirect setup, no archive decision.
+- Acceptance criteria: README/metadata no longer leave readers unsure which repo is meant.
+- Risk reduced: unclear ownership; stale docs.
+- Candidate Höhlengleichnis category: F — Vor-Entscheidung nötig.
+- Human gate needed: yes.
+
+### ISSUE-2: Document Latest-Decision Cache Contract
+
+- Type: docs/product-contract
+- Why this matters: Route calls can write cache even without `--save`.
+- Evidence: `src/kz/service.py`; `src/kz/latest_decision.py`.
+- Suggested scope: Document `KZ_CACHE_DIR`, default path, and integration expectations.
+- Non-goals: No behavior change before human review.
+- Acceptance criteria: A reader can predict whether a route call writes state.
+- Risk reduced: hidden state; no verification path.
+- Candidate Höhlengleichnis category: E — Komplementär.
+- Human gate needed: yes.
+
+### ISSUE-3: Make Decision Store Root Explicit For Integrations
+
+- Type: data-contract
+- Why this matters: `DECISIONS/` is relative to current working directory.
+- Evidence: `src/kz/persist.py`.
+- Suggested scope: Define intended base-dir behavior in docs and tests.
+- Non-goals: No migration of existing decision files.
+- Acceptance criteria: CLI and library/API callers have documented storage semantics.
+- Risk reduced: hidden state; dependency fragility.
+- Candidate Höhlengleichnis category: F — Vor-Entscheidung nötig.
+- Human gate needed: yes.
+
+### ISSUE-4: Add Classifier Precedence Smoke Cases
+
+- Type: test
+- Why this matters: Keyword ordering affects task class and harness recommendation.
+- Evidence: `src/kz/classify.py` checks THINK before BUILD/ANALYZE and defaults to BUILD.
+- Suggested scope: Add focused tests for mixed planning/build/research phrases.
+- Non-goals: No routing redesign.
+- Acceptance criteria: Mixed-task behavior is explicit in tests.
+- Risk reduced: architecture ambiguity; duplicated concept.
+- Candidate Höhlengleichnis category: E — Komplementär.
+- Human gate needed: no.
+
+### ISSUE-5: Document Outcome Feedback Scope
+
+- Type: docs/product-contract
+- Why this matters: Outcome PATCH/update exists, but consolidation readers need to know whether it is core.
+- Evidence: `src/kz/web.py`, `src/kz/cli.py`, `src/kz/persist.py`.
+- Suggested scope: Add current-scope note for outcome recording and confidence feedback.
+- Non-goals: No UI redesign.
+- Acceptance criteria: README or architecture doc states whether outcome feedback is MVP/core/experimental.
+- Risk reduced: stale docs; duplicated concept.
+- Candidate Höhlengleichnis category: F — Vor-Entscheidung nötig.
+- Human gate needed: yes.
+
+### ISSUE-6: Add Minimal API Parity Smoke
+
+- Type: test
+- Why this matters: CLI and Web use the same service, but parity should remain visible.
+- Evidence: `src/kz/cli.py`; `src/kz/web.py`; existing `tests/`.
+- Suggested scope: One test comparing CLI-style request and `/api/route` payload for the same task.
+- Non-goals: No browser automation.
+- Acceptance criteria: API and CLI route core output remain aligned.
+- Risk reduced: UI/backend mismatch.
+- Candidate Höhlengleichnis category: E — Komplementär.
+- Human gate needed: no.

audits/kommandozentrale/RISK_REGISTER.md

@@ -0,0 +1,29 @@
+# Risk Register — KommandoZentrale
+
+## Risk summary
+
+KommandoZentrale has a clear, compact routing role and useful tests/docs. The main risks are not architectural verdicts; they are integration risks: hidden local state, naming ambiguity, duplicated routing policy, and unclear verification baseline.
+
+## Risk table
+
+| ID | Risk | Evidence | Severity | Likelihood | Impact | Possible mitigation | NEEDS_HUMAN |
+|----|------|----------|----------|------------|--------|---------------------|-------------|
+| KZ-R1 | Public/local naming drift | Public clone is `smlfg/KommandoZentrale`; `pyproject.toml` homepage references `smlflg/KomandoZentral`. | medium | high | Broken links and confused handoff. | Add a naming note or metadata cleanup after review. | yes |
+| KZ-R2 | Hidden cache writes | `route_request()` calls `write_latest_decision()`; default path is `~/.cache/kz/latest-decision.json`. | medium | medium | Read-only operators may mutate home state. | Document `KZ_CACHE_DIR` and/or make cache explicit. | yes |
+| KZ-R3 | CWD-dependent decision persistence | `persist.py` writes to `os.getcwd()/DECISIONS`. | medium | high | Parent tools can scatter decision files. | Require explicit base dir for integrations. | yes |
+| KZ-R4 | Routing policy duplication with other repos | KZ has `classify/rules/confidence`; Zentrale also has `routing.py`; MegaHarness plans a Task-Router. | high | high | Divergent harness choices for the same task. | Treat KZ policy as evidence until Luis decides ownership. | yes |
+| KZ-R5 | No CI observed | No `.github/workflows` found in inspected tree; README documents manual commands. | medium | medium | Public handoff may lack automated regression signal. | Add CI only after consolidation direction is chosen. | no |
+| KZ-R6 | Web UI behavior harder to verify | `src/kz/web.py` contains API and embedded UI. | medium | medium | API may pass while browser workflow drifts. | Add focused browser/API smoke later. | no |
+| KZ-R7 | Outcome scope ambiguity | API supports outcome patching; docs emphasize routing decision output. | low | medium | Readers may disagree whether feedback is in current scope. | Document current behavior and non-goals. | yes |
+
+## Top 3 risks for Samuel tomorrow
+
+- Hidden write behavior could surprise read-only or sandboxed workflows.
+- Name mismatch can make the repo look missing or duplicated.
+- Outcome feedback scope needs a quick human stance before public handoff language changes.
+
+## Top 3 risks for Luis' consolidation work
+
+- Routing policy exists here and in Zentrale while MegaHarness also plans one.
+- KZ produces recommendations, not live harness execution.
+- Persistence contracts are local-file based and need a clear integration boundary.

audits/megaharness/AGENT_FINDINGS.md

@@ -0,0 +1,81 @@
+# Agent Findings — MegaHarness
+
+## 1. Scope
+- Repo/source: fresh public clone `https://github.com/smlfg/MegaHarness.git` at `452f9d5` in `/tmp/tower-audit-MegaHarness`.
+- Inspection mode: read-only file inspection; no target repo edits; no branches, commits, pushes, PRs, or issues.
+- Output folder: `/home/smlflg/Projekte/ProjectIntakeTower/audits/megaharness/`.
+- Timestamp: 2026-05-04T18:04:02Z.
+- Auditor: Codex read-only audit operator.
+- Important constraints: no architecture anchor verdict; no consolidation recommendation; doctrine is described, not accepted or rejected by this audit.
+
+## 2. Repo identity
+- What this repo appears to be: doctrine and Luis handoff package for a personal meta-harness/control-tower concept.
+- Primary purpose: describe MegaHarness as a layer over existing coding harnesses, with Markdown artifacts as source of truth and adapters to external execution engines.
+- Main language/framework: Markdown documentation only in the public clone; no package/framework metadata observed.
+- Apparent maturity: conceptual architecture lock and handoff material; not an executable implementation repo in public HEAD.
+- Main entry points: no CLI/API/runtime entry point observed.
+- Important docs/configs: `ARCHITECTURE.md`, `Artefakt_USP.md`, `Höhlengleichnis.md`, `BRIEFING_LUIS.md`, `idea`.
+- Evidence: public clone contains only those five files plus `.git`; no `pyproject.toml`, `package.json`, `src/`, `tests/`, `README.md`, or CI config observed.
+
+## 3. Top observations
+
+| ID | Observation | Evidence | Why it matters |
+|----|-------------|----------|----------------|
+| MH-O1 | The repo is doctrine-first, not implementation-first. | `find` shows five top-level docs and no source/test tree. | Maturity must be compared differently from code repos. |
+| MH-O2 | The architecture uses an explicit L0-L4 layered model. | `ARCHITECTURE.md` sections for provider, adapter, MD-DB, kernel, UI layers. | Gives Luis a vocabulary for comparison without deciding anchor. |
+| MH-O3 | Markdown database is central to the concept. | `ARCHITECTURE.md` L2; `idea` point 3; `Artefakt_USP.md` says MD-DB schema/content is 100% own. | Important distinct asset, but schema/examples are absent in public clone. |
+| MH-O4 | The repo favors adapters over forks. | `Artefakt_USP.md` build-vs-integrate heuristic and anti-patterns. | Useful consolidation principle, not a decision by this audit. |
+| MH-O5 | The adapter protocol is described but not implemented. | `ARCHITECTURE.md` lists `spawn`, `status`, `interrupt`, `collect`, `capabilities`. | Integration surface exists as text only. |
+| MH-O6 | Sidecar and eval are referenced as existing elsewhere. | `ARCHITECTURE.md` cites `Sidecar-ng` and `HarnessEcosystem/sidebyside`. | Claims depend on sibling repos not contained here. |
+| MH-O7 | Luis briefing explicitly asks for decisions this audit must not make. | `BRIEFING_LUIS.md` asks for anchor recommendation, verdicts, sequence, risks, topology. | Protects audit boundary. |
+| MH-O8 | Höhlengleichnis provides categories for issue candidates, but final categorization is human/decision work. | `Höhlengleichnis.md` category table A-F. | Audit can use candidate categories only. |
+| MH-O9 | Public clone lacks a self-contained README or verifier. | No `README.md`, no test/check script, no link checker. | Tomorrow's reader must know this is a handoff bundle, not runnable software. |
+
+## 4. Strengths
+
+| Strength | Evidence | Relevance for consolidation |
+|----------|----------|-----------------------------|
+| Clear layered vocabulary | `ARCHITECTURE.md` L0-L4 model. | Helps compare UI, orchestration, adapters, state, and providers. |
+| Explicit build-vs-integrate doctrine | `Artefakt_USP.md`. | Reduces risk of building commodity infrastructure. |
+| Project distillation method | `Höhlengleichnis.md`. | Provides a non-code method for judging duplicate/shadow projects. |
+| Boundary-aware Luis handoff | `BRIEFING_LUIS.md`. | Makes decision ownership visible. |
+| Personalization is treated as asset | `Artefakt_USP.md` and `BRIEFING_LUIS.md` preserve Samuel-specific MD/Sidecar/policy layers. | Important non-code requirement for consolidation. |
+
+## 5. Weaknesses / gaps
+
+| Gap | Evidence | Risk |
+|-----|----------|------|
+| No executable implementation in public clone | no `src/`, package metadata, tests, or CLI/API entrypoint. | Cannot verify runtime claims from this repo. |
+| No concrete MD-DB schema files | `ARCHITECTURE.md` describes `md-db/`, but no such directory exists. | Central concept remains abstract. |
+| No README entry point | no `README.md` observed. | Reader onboarding depends on knowing which doc to read first. |
+| Sibling repo claims are not reproducible here | references to Sidecar-ng, sidebyside, frontier UI, PromptGarage. | Luis must inspect other repos or treat claims as context. |
+| Local/public briefing divergence exists | startcheck showed `/home/smlflg/Projekte/megaHarness/BRIEFING_LUIS.md` modified locally. | Samuel may have newer private handoff text not in public clone. |
+
+## 6. Test / CI / verification situation
+- Existing tests: none observed.
+- CI config: none observed.
+- How to run: no executable run command observed.
+- Whether tests were run: not applicable; no test runner/package metadata exists in public clone.
+- If not run: why not: repository is Markdown-only in public HEAD.
+- Risk: documentation consistency, references, and schema claims need a docs verifier or human review.
+
+## 7. Dependency / setup situation
+- Package managers: none observed.
+- Lockfiles: none observed.
+- Runtime assumptions: none executable in this repo; architecture references external harnesses and sibling projects.
+- Missing setup docs: no README, no local verifier, no MD-DB example, no adapter fixture.
+- Fragile assumptions: reader must know the intended reading order and which sibling project claims are current.
+
+## 8. Pre-existing local state
+- Public temp clone state: `git status --short` was empty.
+- Local repo caveat: `/home/smlflg/Projekte/megaHarness` has modified `BRIEFING_LUIS.md` and was not used as source of truth.
+- Dirty state interpretation: local dirty briefing text was treated as pre-existing context only.
+
+## 9. NEEDS_HUMAN
+
+| Question | Why human judgment is needed | Suggested reader |
+|----------|------------------------------|------------------|
+| Should the modified local `BRIEFING_LUIS.md` supersede public HEAD for Luis? | Local and public handoff text may differ. | Samuel |
+| What is the intended first-read file for public reviewers? | Public clone lacks `README.md`. | Samuel |
+| Which sibling repo claims should Luis verify directly? | Sidecar/eval/UI references are external to this repo. | Luis |
+| Is MD-DB meant as "database" despite any "no own DB" wording elsewhere? | This is a product-language clarification, not code. | Samuel/Luis |

audits/megaharness/ARCHITECTURE_MAP.md

@@ -0,0 +1,82 @@
+# Architecture Map — MegaHarness
+
+## 1. High-level map
+
+The public MegaHarness repo contains a documented architecture, not an implementation. The described layers are:
+- L0 Provider layer: external model providers, explicitly not MegaHarness-owned.
+- L1 Harness adapter layer: Claude Code, OpenClaude, Codex, OpenHands, Hermes, etc.
+- L2 Markdown database: project briefs, instructions, skills, sidecar rules, tracks, eval logs.
+- L3 Kernel: router, orchestrator, sidecar engine, eval engine, MD resolver, harness swap.
+- L4 UI layer: dashboard, track viewer, MD-DB browser, eval viewer, spawn composer.
+
+## 2. File / directory map
+
+| Path | Role | Notes |
+|------|------|-------|
+| `ARCHITECTURE.md` | Main architecture plan | L0-L4 model, component descriptions, MVP plan, risks, glossary. |
+| `Artefakt_USP.md` | Build-vs-integrate doctrine | Separates Samuel-specific assets from commodity infrastructure. |
+| `Höhlengleichnis.md` | Project distillation method | Defines A-F categories and seed/match/verdict/action flow. |
+| `BRIEFING_LUIS.md` | Luis handoff | Frames the consolidation deliverable and boundaries. |
+| `idea` | Raw/compact vision | Lists harness-agnostic, MD-DB, eval, UI, Samuel-optimized principles. |
+
+## 3. Entry points
+
+| Entry point | Type | Evidence | Notes |
+|-------------|------|----------|-------|
+| `ARCHITECTURE.md` | Document entry | Top-level file; detailed architecture sections. | Best architecture overview. |
+| `BRIEFING_LUIS.md` | Human handoff | Defines Luis deliverable and project context. | Decision request, not audit output. |
+| `Höhlengleichnis.md` | Method document | Category table and process sections. | Useful for candidate issue categories only. |
+| Runtime CLI/API | Not observed | No package/source tree in public clone. | NEEDS_HUMAN if a runtime exists elsewhere. |
+
+## 4. Data/control flow
+
+- User/input flow: doctrine describes user intent entering UI/CLI/Cron/Eval trigger, then becoming track metadata.
+- Agent/control flow: Task-Router chooses harness/model; Parallel-Orchestrator spawns through L1 adapters; Sidecar observes; Harness-Swap can move work between harnesses.
+- Persistence/state flow: MD-DB is described as source of truth with `projects/`, `instructions/`, `skills/`, `sidecar/`, `tracks/`, `evals/`.
+- External API/tool flow: external harnesses/providers are adapter targets; Sidecar-ng and sidebyside are referenced as sibling integrations.
+- Unclear: none of this flow is executable from public repo files alone.
+
+## 5. Interfaces and integration surfaces
+
+| Interface | Direction | Evidence | Consolidation relevance |
+|-----------|-----------|----------|-------------------------|
+| Harness adapter protocol | outbound/inbound | `ARCHITECTURE.md` method table: `spawn`, `status`, `interrupt`, `collect`, `capabilities`. | Candidate contract, not implementation. |
+| Track-MD | internal/outbound | `ARCHITECTURE.md` describes `tracks/*.md` and `done_when`. | Central planned task contract. |
+| MD-Resolver | internal | `ARCHITECTURE.md` L2/L3 sections. | Distinct concept compared with Zentrale context packs. |
+| Eval JSONL | inbound/outbound | `ARCHITECTURE.md` describes `evals/*.jsonl`. | Potential shared feedback format. |
+| Sidecar rules | inbound | `ARCHITECTURE.md` and `Artefakt_USP.md` reference Sidecar-ng/rules. | Samuel-specific layer. |
+| Luis briefing | human-facing | `BRIEFING_LUIS.md`. | Defines what Luis, not this audit, should decide. |
+
+## 6. State and persistence
+
+- Files: planned Markdown DB files and JSONL evals are documented but absent.
+- Databases: no runtime database observed; Markdown DB is a planned file-based source of truth.
+- Logs: planned transcripts/metrics/evals described; no log implementation observed.
+- Caches: none observed.
+- Runtime state: planned tracks/active/queued/done/failed and heartbeat files in architecture text only.
+- Unknowns: final MD-DB location and concrete schema are not present in public clone.
+
+## 7. Configuration model
+
+- Where config lives: planned frontmatter in Markdown files and router policy docs.
+- How profiles/env vars are handled: described conceptually through harness/model/project/session-phase selectors.
+- Secrets risk: no secrets observed in public clone; future adapter layer will need secret/env handling.
+- Missing config docs: no schema examples, no adapter config example, no `.env`/secrets policy, no validator.
+
+## 8. Architecture risks
+
+| Risk | Evidence | Effect |
+|------|----------|--------|
+| Doctrine not executable | no source/package/test files. | Cannot validate behavior from this repo. |
+| MD-DB is underspecified as files | no `md-db/` examples despite central role. | Implementers may invent incompatible schemas. |
+| External references are not bundled | references to Sidecar-ng, sidebyside, PromptGarage, UI patterns. | Luis needs cross-repo evidence. |
+| Five-day MVP plan may be historical | `ARCHITECTURE.md` dates 2026-04-23 to 2026-04-28. | Plan status needs human update. |
+| Human decision pressure embedded in docs | `BRIEFING_LUIS.md` asks for anchor/fusion/topology. | Audit must not accidentally answer Luis' assignment. |
+
+## 9. Open architecture questions
+
+- Which parts of the documented L0-L4 model are still current?
+- Should Zentrale context packs count as an implementation of part of the MD-DB idea?
+- What is the minimal MD-DB schema example Luis should evaluate?
+- Which external/sibling assets are factual dependencies versus inspiration?
+- Is MegaHarness a standalone repo target or a doctrine layer over another implementation?

audits/megaharness/NEXT_ISSUES.md

@@ -0,0 +1,92 @@
+# Next Issue Candidates — MegaHarness
+
+Diese Datei enthält nur Issue-Kandidaten.
+Keine Issues erstellen.
+Keine Labels erstellen.
+Keine PRs öffnen.
+
+## Issue candidates
+
+### ISSUE-1: Add A Public README Reading Order
+
+- Type: docs/handoff
+- Why this matters: Public clone has no obvious first-read file.
+- Evidence: no `README.md`; top-level docs are `ARCHITECTURE.md`, `Artefakt_USP.md`, `Höhlengleichnis.md`, `BRIEFING_LUIS.md`, `idea`.
+- Suggested scope: Add a short README listing purpose, status, reading order, and non-executable nature.
+- Non-goals: No architecture verdict, no consolidation sequence.
+- Acceptance criteria: A new reader knows where to start and what not to expect.
+- Risk reduced: stale docs; no verification path.
+- Candidate Höhlengleichnis category: E — Komplementär.
+- Human gate needed: yes.
+
+### ISSUE-2: Create Minimal MD-DB Example
+
+- Type: docs/schema
+- Why this matters: MD-DB is central but absent as files.
+- Evidence: `ARCHITECTURE.md` L2 describes planned folders; no `md-db/` exists.
+- Suggested scope: Add one tiny example project/track/instruction/eval fixture as documentation.
+- Non-goals: No parser, no runtime implementation.
+- Acceptance criteria: The doctrine includes concrete file names and frontmatter examples.
+- Risk reduced: architecture ambiguity.
+- Candidate Höhlengleichnis category: F — Vor-Entscheidung nötig.
+- Human gate needed: yes.
+
+### ISSUE-3: Mark Public Repo Status As Doctrine-Only
+
+- Type: docs/status
+- Why this matters: The docs describe runtime layers that do not exist in this repo.
+- Evidence: no source tree or tests; `ARCHITECTURE.md` describes adapters/router/UI/evals.
+- Suggested scope: Add status note to top of architecture or README.
+- Non-goals: No implementation work.
+- Acceptance criteria: Reader cannot confuse planned components with built components.
+- Risk reduced: unclear ownership; stale docs.
+- Candidate Höhlengleichnis category: E — Komplementär.
+- Human gate needed: no.
+
+### ISSUE-4: Add Sibling Evidence Matrix
+
+- Type: handoff/evidence
+- Why this matters: Many claims depend on other local repos.
+- Evidence: references to `Sidecar-ng`, `HarnessEcosystem/sidebyside`, `frontier-llm-harness`, `PromptGarage`.
+- Suggested scope: Table of claim, sibling path, evidence file, status.
+- Non-goals: No integration or copy/paste of sibling code.
+- Acceptance criteria: Luis can verify claims without repo spelunking.
+- Risk reduced: hidden state; architecture ambiguity.
+- Candidate Höhlengleichnis category: F — Vor-Entscheidung nötig.
+- Human gate needed: yes.
+
+### ISSUE-5: Reconcile Local And Public Luis Briefing
+
+- Type: handoff
+- Why this matters: Local `BRIEFING_LUIS.md` is modified compared with public clone.
+- Evidence: startcheck local dirty state.
+- Suggested scope: Samuel chooses which version Luis should read.
+- Non-goals: No commit/push/merge.
+- Acceptance criteria: Handoff source is explicitly named in tomorrow's package.
+- Risk reduced: stale docs; unclear ownership.
+- Candidate Höhlengleichnis category: F — Vor-Entscheidung nötig.
+- Human gate needed: yes.
+
+### ISSUE-6: Clarify MD-DB Versus Database Wording
+
+- Type: docs/product-contract
+- Why this matters: "Database" can mean runtime DB or versioned Markdown source of truth.
+- Evidence: `ARCHITECTURE.md` says Markdown DB; `Artefakt_USP.md` treats MD-DB schema/content as core USP.
+- Suggested scope: Add wording that MD-DB means Git-versioned Markdown files, not SQL service, unless later changed.
+- Non-goals: No storage decision beyond documenting current doctrine.
+- Acceptance criteria: Reader understands the current storage concept.
+- Risk reduced: architecture ambiguity.
+- Candidate Höhlengleichnis category: E — Komplementär.
+- Human gate needed: yes.
+
+### ISSUE-7: Add Docs Verification Checklist
+
+- Type: verifier
+- Why this matters: Markdown-only repo still needs drift checks.
+- Evidence: no CI, link checker, or required-file checklist.
+- Suggested scope: Add a checklist for required docs, links, referenced sibling paths, and status dates.
+- Non-goals: No automated CI unless later approved.
+- Acceptance criteria: Samuel/Luis can manually verify doc completeness in minutes.
+- Risk reduced: no verification path.
+- Candidate Höhlengleichnis category: E — Komplementär.
+- Human gate needed: no.

audits/megaharness/RISK_REGISTER.md

@@ -0,0 +1,29 @@
+# Risk Register — MegaHarness
+
+## Risk summary
+
+MegaHarness is a coherent doctrine/handoff repo in the public clone, but it is not executable. The main risks are verification gaps, missing concrete schemas, local/public handoff divergence, and the temptation to treat doctrine as implemented behavior.
+
+## Risk table
+
+| ID | Risk | Evidence | Severity | Likelihood | Impact | Possible mitigation | NEEDS_HUMAN |
+|----|------|----------|----------|------------|--------|---------------------|-------------|
+| MH-R1 | Doctrine mistaken for implementation | Public clone has only five docs and no source/tests. | high | high | Luis/Samuel may overestimate runtime maturity. | Label repo as doctrine-only in handoff. | no |
+| MH-R2 | Missing MD-DB concrete schema | `ARCHITECTURE.md` centers MD-DB; no `md-db/` examples exist. | high | high | Future implementers may invent incompatible contracts. | Add minimal example after decision. | yes |
+| MH-R3 | Public/local briefing divergence | local `BRIEFING_LUIS.md` is modified; public clone is clean. | medium | high | Luis may read outdated or incomplete handoff. | Samuel selects public or local briefing source. | yes |
+| MH-R4 | External evidence not reproducible here | Sidecar-ng, sidebyside, PromptGarage, UI patterns are referenced but absent. | medium | high | Claims need cross-repo validation. | Add evidence matrix or links after review. | yes |
+| MH-R5 | No verification path | no README, tests, CI, link checker, or docs validator. | medium | high | Documentation drift can accumulate silently. | Add docs-only checklist/verifier later. | no |
+| MH-R6 | Historic MVP timeline | `ARCHITECTURE.md` references 2026-04-23 to 2026-04-28. | low | medium | Readers may confuse past plan with current status. | Add status note. | yes |
+| MH-R7 | Scope expansion pressure | `idea` and `ARCHITECTURE.md` mention many layers: UI, adapters, router, evals, sidecar, swap. | high | medium | Consolidation could expand instead of condense. | Keep Luis decision bounded to requested repos. | yes |
+
+## Top 3 risks for Samuel tomorrow
+
+- Public repo does not include executable proof of the doctrine.
+- Local `BRIEFING_LUIS.md` may contain newer context not in public HEAD.
+- Missing README/reading order can slow Luis down.
+
+## Top 3 risks for Luis' consolidation work
+
+- MegaHarness has strong concepts but no directly comparable runtime maturity.
+- Core MD-DB concept lacks concrete files/schema in the public clone.
+- Sibling-project claims need evidence from outside this repo.

audits/zentrale/AGENT_FINDINGS.md

@@ -0,0 +1,81 @@
+# Agent Findings — Zentrale
+
+## 1. Scope
+- Repo/source: fresh public clone `https://github.com/smlfg/Zentrale.git` at `3153996` in `/tmp/tower-audit-Zentrale`.
+- Inspection mode: read-only file/config inspection; no target repo edits; no branches, commits, pushes, PRs, or issues.
+- Output folder: `/home/smlflg/Projekte/ProjectIntakeTower/audits/zentrale/`.
+- Timestamp: 2026-05-04T18:04:02Z.
+- Auditor: Codex read-only audit operator.
+- Important constraints: no architecture anchor verdict; no consolidation recommendation; tests not executed because package/test commands may write caches or runtime files.
+
+## 2. Repo identity
+- What this repo appears to be: local adaptive agent orchestration/control-tower skeleton.
+- Primary purpose: create project scaffolds, route tasks to harness/phase pairs, generate context packs, track runs, expose CLI/TUI/Web views, and delegate primarily through OpenCode.
+- Main language/framework: Python `>=3.11`, FastAPI, Textual, static browser UI, JSON registries, pytest.
+- Apparent maturity: broad public handoff prototype with many implemented surfaces and explicit tests, but still contains stubs and contract ambiguities.
+- Main entry points: `zentrale = "zentrale.cli:main"`, `python -m zentrale`, `zentrale serve`, Textual dashboard commands, FastAPI app in `src/zentrale/web/app.py`.
+- Important docs/configs: `README.md`, `pyproject.toml`, `docs/architecture.md`, `docs/decisions.md`, `registry/*.json`, `templates/context-pack/*`, `integrations/*.md`.
+- Evidence: `README.md` documents the end-to-end run loop and dashboard; `src/zentrale/cli.py` implements the command surface; `registry/harnesses.json` and `registry/profiles.json` define harnesses/profiles.
+
+## 3. Top observations
+
+| ID | Observation | Evidence | Why it matters |
+|----|-------------|----------|----------------|
+| Z-O1 | The CLI surface is broad and operationally oriented. | `src/zentrale/cli.py` defines `init-project`, `context-pack`, `route`, `run`, `doctor`, `dashboard`, `serve`, and more. | Zentrale is more than a routing policy document; it contains workflow machinery. |
+| Z-O2 | The repo models projects, phases, harnesses, context packs, runs, and learning feedback. | `src/zentrale/project_scaffold.py`, `context_pack.py`, `run_tracking.py`, `registry_learning.py`, `registry/*.json`. | These are distinct assets for consolidation review. |
+| Z-O3 | Harness routing can be local/static or delegated to KommandoZentral. | `src/zentrale/routing.py`; `src/zentrale/cli.py` supports `route --live` and `run --use-kz`. | Shows direct overlap and integration with KommandoZentrale. |
+| Z-O4 | Context packs are generated as phase/harness-specific Markdown bundles. | `src/zentrale/context_pack.py`; `templates/context-pack/*.md`; README `context-pack` docs. | This is an important concrete implementation of the MD-context idea. |
+| Z-O5 | The `run` command writes real local state. | `src/zentrale/cli.py` creates context packs, run records, logs, learning proposals, and appends `DONE_CRITERIA.md`. | Execution semantics are not read-only and need clear ownership. |
+| Z-O6 | Web API contains implemented reads and route suggestion, but write routes are still stubs. | `src/zentrale/web/routes/projects.py`, `runs.py`, `routing.py`, `dashboard.py`. | UI/backend maturity is mixed. |
+| Z-O7 | Phase definitions drift across surfaces. | `registry/phases.json` includes `review`; `/api/phases` and `_PHASE_ORDER` omit `review`. | Consolidation readers should not assume one canonical phase source yet. |
+| Z-O8 | Cost estimation depends on log fields that may not exist in generated logs. | `src/zentrale/web/routes/dashboard.py` reads `stdout`/`stderr`; `run_tracking.py` writes logs through `build_run_log()`. | Dashboard cost numbers can be incomplete. |
+| Z-O9 | Public clone has extensive tests. | `tests/test_cli.py`, `test_e2e.py`, `test_web_api.py`, `test_context_pack.py`, `test_run_tracking.py`, `test_opencode_delegate.py`. | Verification intent is strong, even though tests were not executed in this audit. |
+
+## 4. Strengths
+
+| Strength | Evidence | Relevance for consolidation |
+|----------|----------|-----------------------------|
+| Concrete context-pack implementation | `context_pack.py`, `templates/context-pack/`. | Implements a key idea that MegaHarness describes doctrinally. |
+| Multiple operator surfaces | CLI, Textual dashboard, FastAPI, static UI in README and source. | Shows several candidate control-tower interaction models. |
+| JSON registries for harness/phase/profile contracts | `registry/harnesses.json`, `registry/phases.json`, `registry/profiles.json`. | Machine-readable basis for comparison. |
+| Direct KZ integration path | `routing.py` maps KommandoZentral output into Zentrale phases/harness IDs. | Relevant overlap without requiring a consolidation verdict. |
+| Run tracking and learning feedback exist | `run_tracking.py`, `registry_learning.py`, README run loop. | Provides evidence of an execution/history layer. |
+
+## 5. Weaknesses / gaps
+
+| Gap | Evidence | Risk |
+|-----|----------|------|
+| Local state writes are central to normal commands | `context_pack.py`, `run_tracking.py`, `cli.py run`. | Running commands in the wrong workspace can mutate project artifacts. |
+| Phase contract is inconsistent | `registry/phases.json` vs `/api/phases` and project phase ordering. | UI/API may hide or mishandle valid registry phases. |
+| Web write endpoints are stubs | `projects.py` and `runs.py` return 501 for create/update/retry/start. | UI may imply workflows not backed by API. |
+| Harness execution cwd is context-pack path | `src/zentrale/cli.py` passes `cwd=pack_path` to `run_harness_prompt`. | Harness may operate from context bundle rather than target project. |
+| Dirty local repo exists outside public clone | startcheck showed many modified local files and untracked `artifacts/`. | Samuel/Luis must not conflate local development state with public handoff. |
+
+## 6. Test / CI / verification situation
+- Existing tests: pytest files cover CLI, routing, context packs, run tracking, dashboard helpers, web API, doctor, registry contracts, E2E mocks, and OpenCode delegation.
+- CI config: no CI workflow file observed in the inspected public tree.
+- How to run: README documents `python scripts/validate_skeleton.py`, `python -m zentrale validate`, `python -m zentrale doctor`, `python -m zentrale route`, `python -m zentrale serve --help`, and `uv run pytest -q`.
+- Whether tests were run: not run in this execution.
+- If not run: why not: verification commands may write caches/runtime files; the requested output is an audit artifact, not a test run.
+- Risk: test status remains unproven for the exact public clone until a controlled verifier pass is run.
+
+## 7. Dependency / setup situation
+- Package managers: Python package via setuptools; README uses both `python -m zentrale` and `uv run`.
+- Lockfiles: `uv.lock` exists.
+- Runtime assumptions: Python `>=3.11`; Textual, FastAPI, uvicorn, httpx; optional pytest.
+- Missing setup docs: CI and isolated writable runtime/cache setup are not clearly specified.
+- Fragile assumptions: local integration roots for KomandoZentral/OpenCode/MultiHarnessStudio; runtime writes under `projects/` and `runs/`; external harness binaries may be absent.
+
+## 8. Pre-existing local state
+- Public temp clone state: `git status --short` was empty.
+- Local repo caveat: `/home/smlflg/Projekte/Zentrale` is dirty with modified docs, dashboard, run tracking, validation, web routes, tests, and untracked `artifacts/`.
+- Dirty state interpretation: local dirty state was documented as pre-existing and not treated as public audit output.
+
+## 9. NEEDS_HUMAN
+
+| Question | Why human judgment is needed | Suggested reader |
+|----------|------------------------------|------------------|
+| Should harness execution run from project root or context-pack directory? | Current implementation chooses context-pack cwd, but product intent is ambiguous. | Samuel/Luis |
+| Which phase list is canonical: registry or UI/API constants? | `review` exists in registry but not all surfaces. | Luis |
+| Are web create/retry/start actions in scope for the handoff, or intentionally stubbed? | API returns 501 for key write actions. | Samuel |
+| Should dirty local Zentrale changes be considered tomorrow? | Public clone and local working copy differ materially. | Samuel |

audits/zentrale/ARCHITECTURE_MAP.md

@@ -0,0 +1,98 @@
+# Architecture Map — Zentrale
+
+## 1. High-level map
+
+Zentrale is a local orchestration skeleton with several layers:
+- Operator entrypoints: CLI, Textual TUI screens, FastAPI server, static browser UI.
+- Planning/config layer: JSON registries for harnesses, phases, and profiles; Markdown templates for context packs.
+- Workflow layer: project scaffolding, routing, context-pack creation, run records, logs, learning proposals, and cost/effectiveness views.
+- Integration layer: static routing, optional KommandoZentral routing, OpenCode delegation, integration-root checks.
+
+## 2. File / directory map
+
+| Path | Role | Notes |
+|------|------|-------|
+| `README.md` | Main operator documentation | Describes goal, CLI, dashboard, web start, run loop, validation. |
+| `pyproject.toml` | Package config | Defines `zentrale` script and dependencies. |
+| `src/zentrale/cli.py` | Main command dispatcher | Implements most user-visible workflows. |
+| `src/zentrale/routing.py` | Static and KZ-backed routing | Maps task text to harness/phase. |
+| `src/zentrale/context_pack.py` | Context-pack generator | Writes Markdown bundles by project/phase/harness. |
+| `src/zentrale/project_scaffold.py` | Project scaffolding | Creates project folders and metadata. |
+| `src/zentrale/run_tracking.py` | Run persistence | Writes `RUN.json`, `log.json`, status, done criteria. |
+| `src/zentrale/opencode_delegate.py` | OpenCode command/prompt adapter | Deepest concrete harness delegation path. |
+| `src/zentrale/harness_runner.py` | Harness dispatch wrapper | Routes prompt execution to selected harness. |
+| `src/zentrale/dashboard/` | Textual TUI screens | Runs, tasks, logs, quickrun, phases, costs. |
+| `src/zentrale/web/` | FastAPI/WebSocket backend | Serves SPA and API routes. |
+| `web/` and `src/zentrale/web/static/` | Static UI assets | Browser UI files appear in both source/static locations. |
+| `registry/` | Machine-readable contracts | Harnesses, phases, profiles, md-register README. |
+| `templates/` | Markdown templates | Project files and context-pack files. |
+| `tests/` | Verification suite | Broad mocked tests for CLI, E2E, web, dashboard, contracts. |
+
+## 3. Entry points
+
+| Entry point | Type | Evidence | Notes |
+|-------------|------|----------|-------|
+| `zentrale` | CLI script | `pyproject.toml` maps to `zentrale.cli:main`. | Main command surface. |
+| `python -m zentrale` | Python module | `README.md`; module shims. | Alternate execution path. |
+| `zentrale validate` | CLI verifier | `src/zentrale/cli.py`; `src/zentrale/validate.py`. | Skeleton validation. |
+| `zentrale doctor` | CLI diagnostics | `src/zentrale/cli.py`; `src/zentrale/doctor.py`. | Checks dirs, templates, integration roots. |
+| `zentrale route` | CLI routing | `src/zentrale/cli.py`; `routing.py`. | Static or KZ-backed route suggestion. |
+| `zentrale context-pack` | CLI writer | `cli.py`; `context_pack.py`. | Writes phase/harness Markdown bundle. |
+| `zentrale run` | CLI execution loop | `cli.py`; README. | Route, context-pack, run record, harness execution, logs, learning. |
+| `zentrale dashboard` | TUI | `src/zentrale/dashboard/unified.py`. | Textual unified dashboard. |
+| `zentrale serve` | Web server | `src/zentrale/web/app.py`. | FastAPI/WebSocket/SPA. |
+| `/api/projects`, `/api/runs`, `/api/routes`, `/api/costs`, `/api/phases` | Web API | `src/zentrale/web/routes/*.py`. | Mixed read/stub surface. |
+
+## 4. Data/control flow
+
+- User/input flow: user provides a project prompt, task, harness, phase, or verification criteria through CLI/TUI/Web.
+- Agent/control flow: static routing or KomandoZentral output selects harness/phase; `run` builds a delegation prompt and dispatches through `run_harness_prompt`.
+- Persistence/state flow: project scaffolds under `projects/`; context packs under project folders; run records/logs under `runs/`; learning proposals and effectiveness data through registry-learning helpers.
+- External API/tool flow: OpenCode command execution is modeled; KomandoZentral can be invoked through a local subprocess; web server exposes local HTTP/WebSocket APIs.
+
+## 5. Interfaces and integration surfaces
+
+| Interface | Direction | Evidence | Consolidation relevance |
+|-----------|-----------|----------|-------------------------|
+| CLI `zentrale` | inbound | `pyproject.toml`, `cli.py` | Primary operator/control interface. |
+| JSON registries | internal/outbound | `registry/harnesses.json`, `phases.json`, `profiles.json` | Candidate shared contract. |
+| Markdown context packs | outbound to harnesses | `context_pack.py`, `templates/context-pack/` | Concrete implementation of phase/harness-specific context. |
+| Run records/logs | local persistence | `run_tracking.py` | Execution history and dashboard input. |
+| KomandoZentral bridge | inbound/outbound subprocess | `routing.py`, `--use-kz`, `--live` | Direct overlap/integration with KZ. |
+| OpenCode adapter | outbound subprocess | `opencode_delegate.py`, `harness_runner.py` | Most developed harness execution path. |
+| FastAPI/WebSocket | inbound/outbound | `web/app.py`, `web/routes/`, `ws_manager.py` | Local UI/backend surface. |
+| Static UI/TUI | operator UI | `web/`, `dashboard/` | Multiple UI patterns exist. |
+
+## 6. State and persistence
+
+- Files: project scaffold Markdown/JSON, context-pack Markdown, `RUN.json`, `log.json`, `DONE_CRITERIA.md`, learning proposal files.
+- Databases: no database observed in public clone.
+- Logs: run logs under `runs/<run_id>/log.json`.
+- Caches: package/test tooling may create caches; runtime state lives in repo-local project/run dirs.
+- Runtime state: active run polling reads `runs/`; web init state reads projects and active runs.
+- Unknowns: whether harness cwd should be project root, context-pack dir, or configurable.
+
+## 7. Configuration model
+
+- Where config lives: JSON registries, Markdown templates, Python constants in `config.py`, CLI flags.
+- How profiles/env vars are handled: profiles are registry-driven; external roots are checked by doctor/integration scripts.
+- Secrets risk: no explicit secret store observed; external harness commands may inherit user environment.
+- Missing config docs: exact writable-state locations and external binary/root requirements could be clearer.
+
+## 8. Architecture risks
+
+| Risk | Evidence | Effect |
+|------|----------|--------|
+| Registry/constants drift | `registry/phases.json` includes `review`; `/api/phases` omits it. | Different surfaces disagree on valid phase lifecycle. |
+| Write routes stubbed | Web project/run create/update/retry endpoints return 501. | Browser UI may not be feature-complete. |
+| Harness cwd ambiguity | `cli.py` passes `cwd=pack_path` for harness execution. | Agent may not see intended project files. |
+| Broad surface area | CLI, TUI, SPA, WebSocket, OpenCode, KZ, registries, learning. | More verification required before treating as stable. |
+| Local/public drift | local Zentrale is dirty; public clone is clean. | Tomorrow's reader may see different behavior locally. |
+
+## 9. Open architecture questions
+
+- Which surfaces are authoritative: CLI, TUI, Web API, or static SPA?
+- Should registries be the only source for phases/harnesses/profiles?
+- Should Zentrale call KommandoZentrale as a subprocess, library, API, or not at all?
+- What is the intended working directory for delegated harness execution?
+- Which local state directories are part of product behavior versus development artifacts?

audits/zentrale/NEXT_ISSUES.md

@@ -0,0 +1,104 @@
+# Next Issue Candidates — Zentrale
+
+Diese Datei enthält nur Issue-Kandidaten.
+Keine Issues erstellen.
+Keine Labels erstellen.
+Keine PRs öffnen.
+
+## Issue candidates
+
+### ISSUE-1: Decide Harness Execution Working Directory
+
+- Type: product-contract/test
+- Why this matters: Current `run` execution uses the context-pack directory as cwd.
+- Evidence: `src/zentrale/cli.py` passes `cwd=pack_path` to `run_harness_prompt`.
+- Suggested scope: Decide and document whether harnesses run in project root, context-pack dir, or configurable cwd.
+- Non-goals: No harness adapter rewrite.
+- Acceptance criteria: One test locks the selected cwd contract.
+- Risk reduced: broken setup; harness-specific assumptions.
+- Candidate Höhlengleichnis category: F — Vor-Entscheidung nötig.
+- Human gate needed: yes.
+
+### ISSUE-2: Make Phase Definitions Registry-Backed Everywhere
+
+- Type: data-contract/test
+- Why this matters: `review` exists in the registry but is absent in API/constants.
+- Evidence: `registry/phases.json`; `src/zentrale/web/routes/dashboard.py`; `src/zentrale/web/routes/projects.py`.
+- Suggested scope: Read phase lists from registry or explicitly document derived subsets.
+- Non-goals: No lifecycle redesign.
+- Acceptance criteria: `/api/phases`, project phase ordering, and tests agree with the chosen source.
+- Risk reduced: UI/backend mismatch; stale docs.
+- Candidate Höhlengleichnis category: E — Komplementär.
+- Human gate needed: yes.
+
+### ISSUE-3: Mark Web Write Routes As Stubbed Or Complete Them Later
+
+- Type: docs/product-contract
+- Why this matters: POST/PUT routes exist but raise 501.
+- Evidence: `src/zentrale/web/routes/projects.py`, `src/zentrale/web/routes/runs.py`.
+- Suggested scope: Add handoff note listing implemented vs stubbed web API actions.
+- Non-goals: No implementation in audit phase.
+- Acceptance criteria: README/API notes prevent readers from assuming create/retry/start works through web.
+- Risk reduced: UI/backend mismatch.
+- Candidate Höhlengleichnis category: F — Vor-Entscheidung nötig.
+- Human gate needed: yes.
+
+### ISSUE-4: Add Context-Pack Contract Fixture
+
+- Type: test/schema
+- Why this matters: Context packs are a key asset and should have a stable shape.
+- Evidence: `src/zentrale/context_pack.py`; `templates/context-pack/*.md`; `tests/test_context_pack.py`.
+- Suggested scope: One fixture documents expected files and placeholder replacement for a representative harness/phase.
+- Non-goals: No new MD-DB design.
+- Acceptance criteria: Test and docs show exact generated context-pack layout.
+- Risk reduced: architecture ambiguity; duplicated concept.
+- Candidate Höhlengleichnis category: E — Komplementär.
+- Human gate needed: no.
+
+### ISSUE-5: Clarify Static Routing Versus KommandoZentral Routing
+
+- Type: docs/integration
+- Why this matters: Zentrale can route locally or through KommandoZentral.
+- Evidence: `src/zentrale/routing.py`; CLI flags `--live` and `--use-kz`.
+- Suggested scope: Document when each route source is used and how output is mapped.
+- Non-goals: No policy ownership decision.
+- Acceptance criteria: A reader can predict route source for `route`, `route --live`, `run`, and `run --use-kz`.
+- Risk reduced: duplicated concept; unclear ownership.
+- Candidate Höhlengleichnis category: F — Vor-Entscheidung nötig.
+- Human gate needed: yes.
+
+### ISSUE-6: Define Run Log Schema For Cost Views
+
+- Type: data-contract/test
+- Why this matters: Cost routes estimate from prompt/stdout/stderr/model fields.
+- Evidence: `src/zentrale/web/routes/dashboard.py`; `src/zentrale/run_tracking.py`; `src/zentrale/opencode_delegate.py`.
+- Suggested scope: Add a minimal log schema fixture used by cost CLI/API tests.
+- Non-goals: No pricing model redesign.
+- Acceptance criteria: Generated logs contain or explicitly omit fields consumed by cost views.
+- Risk reduced: hidden state; no verification path.
+- Candidate Höhlengleichnis category: E — Komplementär.
+- Human gate needed: no.
+
+### ISSUE-7: Separate Read-Only Diagnostics From Writing Commands
+
+- Type: docs/ops
+- Why this matters: Some commands inspect, while others create project/run artifacts.
+- Evidence: `validate` and `doctor` are mostly read paths; `context-pack`, `run`, `retry` write files.
+- Suggested scope: Add a command safety table to README.
+- Non-goals: No CLI redesign.
+- Acceptance criteria: Operators know which commands mutate `projects/`, `runs/`, or project files.
+- Risk reduced: code drift; hidden state.
+- Candidate Höhlengleichnis category: E — Komplementär.
+- Human gate needed: no.
+
+### ISSUE-8: Reconcile Public Clone And Local Dirty Snapshot
+
+- Type: handoff
+- Why this matters: Samuel's local repo contains modified files not in public clone.
+- Evidence: startcheck `git status --short` for `/home/smlflg/Projekte/Zentrale`.
+- Suggested scope: Decide whether Luis reviews public HEAD or local dirty snapshot.
+- Non-goals: No commit, no push, no branch.
+- Acceptance criteria: Tomorrow's review input is explicitly named.
+- Risk reduced: unclear ownership; stale docs.
+- Candidate Höhlengleichnis category: F — Vor-Entscheidung nötig.
+- Human gate needed: yes.

audits/zentrale/RISK_REGISTER.md

@@ -0,0 +1,30 @@
+# Risk Register — Zentrale
+
+## Risk summary
+
+Zentrale is the broadest implemented control-tower prototype in the audited set, with real local state and harness delegation paths. Its main risks are surface-area complexity, contract drift, runtime write behavior, and unclear boundaries with KommandoZentrale and MegaHarness doctrine.
+
+## Risk table
+
+| ID | Risk | Evidence | Severity | Likelihood | Impact | Possible mitigation | NEEDS_HUMAN |
+|----|------|----------|----------|------------|--------|---------------------|-------------|
+| Z-R1 | Phase contract drift | `registry/phases.json` includes `review`; `/api/phases` and `_PHASE_ORDER` omit it. | high | high | UI/API/tests may disagree with registry-backed workflows. | Make one phase source canonical after review. | yes |
+| Z-R2 | Harness execution root ambiguity | `src/zentrale/cli.py` uses `cwd=pack_path` for `run_harness_prompt`. | high | medium | Agents may operate on context docs instead of project source. | Decide intended cwd and document/test it. | yes |
+| Z-R3 | Write-heavy commands | `context_pack.py`, `run_tracking.py`, `registry_learning.py`, `append_done_criteria()`. | medium | high | Accidental artifact churn during audits or dry runs. | Separate read-only diagnostics from execution commands. | no |
+| Z-R4 | Web write routes are stubs | `projects.py` and `runs.py` POST/PUT routes raise 501. | medium | high | Browser UI may imply unimplemented workflows. | Label stubs or hide write controls until implemented. | yes |
+| Z-R5 | Routing duplication | `routing.py` static rules and KZ bridge coexist with KZ's own policy. | high | high | Divergent recommendations and unclear ownership. | Treat as consolidation input, not verdict. | yes |
+| Z-R6 | Cost/log data mismatch | Cost routes read `stdout`/`stderr`; generated log shape needs explicit contract. | medium | medium | Cost dashboard can undercount or mislead. | Add log schema test and dashboard fixture. | no |
+| Z-R7 | External tool fragility | OpenCode, KomandoZentral, MultiHarness roots are assumed by docs/doctor. | medium | medium | Setup works only on Samuel's machine unless documented. | Produce environment checklist. | no |
+| Z-R8 | Local dirty state divergence | startcheck showed modified local files and untracked `artifacts/`. | high | high | Luis may inspect local behavior that differs from public handoff. | Explicitly choose public clone or local dirty snapshot for review. | yes |
+
+## Top 3 risks for Samuel tomorrow
+
+- Local Zentrale is dirty and may not match the public handoff.
+- Harness execution cwd could send agents into the context-pack folder rather than the project.
+- Web/API/TUI surfaces are broad; not every displayed workflow is necessarily implemented.
+
+## Top 3 risks for Luis' consolidation work
+
+- Zentrale overlaps with KommandoZentrale on routing and with MegaHarness on context/MD orchestration concepts.
+- Registry and UI/API phase definitions are not fully aligned.
+- The repo contains live execution machinery, so code-level maturity is not comparable to doctrine-only MegaHarness.

briefings/01_audit_kommandozentrale.md

@@ -0,0 +1,219 @@
+# READY — READ_ONLY_AUDIT — KommandoZentrale
+
+## Mission
+
+Audit the public/local repo `smlfg/KommandoZentrale`.
+
+Your job is not to improve code.  
+Your job is to produce compact audit artifacts for Samuel and Luis so they can understand this repo’s current shape, risks, reusable parts, and consolidation relevance.
+
+## Absolute Rules
+
+- READ ONLY for the source repo.
+- Do not create branches.
+- Do not commit.
+- Do not push.
+- Do not open PRs.
+- Do not refactor.
+- Do not modify repo files.
+- The only allowed writes are under:
+
+`/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/`
+
+If you detect that the task requires a consolidation verdict, architecture anchor decision, or repo-archive decision: STOP that line of reasoning and mark it as `NEEDS_HUMAN`.
+
+Luis owns the final consolidation decision. Do not preempt Luis.
+
+## Context Files To Read If Available
+
+Read these first if they exist:
+
+- `/home/smlflg/Projekte/megaHarness/BRIEFING_LUIS.md`
+- `/home/smlflg/Projekte/megaHarness/Höhlengleichnis.md`
+
+If unavailable, continue. Do not block.
+
+## Allowed Investigation
+
+You may use:
+
+- `find`
+- `rg`
+- `tree`
+- `git status`
+- `git log --oneline --decorate -n 30`
+- reading source files
+- reading docs
+- reading configs
+- reading tests
+- reading package/build files
+
+Before and after the audit, run `git status --short` for the audited repo and record the result.
+
+## Required Output Files
+
+Write exactly these files:
+
+1. `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/AGENT_FINDINGS.md`
+2. `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/ARCHITECTURE_MAP.md`
+3. `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/RISK_REGISTER.md`
+4. `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/NEXT_ISSUES.md`
+
+## AGENT_FINDINGS.md Structure
+
+Use this structure:
+
+```md
+# KommandoZentrale — Agent Findings
+
+## Audit Scope
+- Repo:
+- Local path or remote:
+- Time:
+- Mode: READ_ONLY_AUDIT
+- Source git status before:
+- Source git status after:
+
+## Executive Summary
+5-10 bullets. Facts only.
+
+## What This Repo Appears To Be
+Short factual description. No verdict.
+
+## Strongest Assets
+Table:
+| Asset | Evidence Path | Why It Matters | Confidence |
+
+## Main Weaknesses / Gaps
+Table:
+| Gap | Evidence Path | Impact | Confidence |
+
+## Reusable Components For Future Tower Work
+Table:
+| Component | Path | Reuse Type | Notes |
+
+## Consolidation-Relevant Observations
+Facts only. No recommendation.
+
+## NEEDS_HUMAN
+List anything uncertain, ambiguous, or decision-shaped.
+```
+
+## ARCHITECTURE_MAP.md Structure
+
+Use this structure:
+
+```md
+# KommandoZentrale — Architecture Map
+
+## Repo Shape
+Compact directory map. Avoid raw full tree dumps.
+
+## Entrypoints
+Table:
+| Entrypoint | Path | Purpose | Evidence |
+
+## Main Layers / Modules
+Table:
+| Layer / Module | Path | Responsibility | Notes |
+
+## Data / Config Flow
+Facts about configuration, persistence, external services, env vars, and runtime assumptions.
+
+## Dependencies
+Table:
+| Dependency | Evidence Path | Usage | Risk / Note |
+
+## Tests / CI / Quality Gates
+Table:
+| Check | Path / Command | Exists? | Notes |
+
+## Interfaces Relevant To Consolidation
+Facts only. No architecture verdict.
+
+## Unknowns
+List unclear parts.
+```
+
+## RISK_REGISTER.md Structure
+
+Use this structure:
+
+```md
+# KommandoZentrale — Risk Register
+
+## Risk Table
+| Risk | Evidence Path | Impact | Likelihood | Suggested Verifier | Owner / Needs Human |
+
+## Test Coverage Gaps
+Table:
+| Gap | Evidence Path | Why It Matters | Suggested Test / Check |
+
+## Operational / Maintenance Risks
+Facts only.
+
+## Security / Secret Handling Observations
+Mention only evidence-backed observations. Do not print secrets.
+
+## NEEDS_HUMAN
+Decision-shaped or ambiguous risks.
+```
+
+## NEXT_ISSUES.md Structure
+
+Use this structure:
+
+```md
+# KommandoZentrale — Candidate Next Issues
+
+These are candidate issue drafts only. Do not create GitHub issues.
+
+## Candidate Issues
+
+### 1. <Title>
+- Type:
+- Evidence:
+- Why it matters:
+- Suggested acceptance check:
+- Decision owner / NEEDS_HUMAN:
+
+### 2. <Title>
+- Type:
+- Evidence:
+- Why it matters:
+- Suggested acceptance check:
+- Decision owner / NEEDS_HUMAN:
+
+## Non-Issues / Do Not File Yet
+Items that look tempting but require Luis/Samuel decision first.
+
+## Questions For Samuel / Luis
+Short list.
+```
+
+## Stop Conditions
+
+Stop and mark `NEEDS_HUMAN` if:
+
+- the repo identity is ambiguous;
+- the repo is not publicly reachable and no local path is available;
+- the local repo has unexpected uncommitted changes that affect interpretation;
+- the audit would require source repo writes;
+- the audit would require credentials;
+- the finding becomes a consolidation verdict, archive decision, or architecture-anchor decision.
+
+## Final Response Format
+
+When finished, respond only with:
+
+```text
+READ_ONLY_AUDIT complete: KommandoZentrale
+Artifacts:
+- <path>
+- <path>
+- <path>
+- <path>
+Source git status before: <short summary>
+Source git status after: <short summary>
+NEEDS_HUMAN: <count + one-line summary>
+```

briefings/02_audit_zentrale.md

@@ -0,0 +1,136 @@
+# READY Briefing 02 - Audit Zentrale
+
+## Job Contract
+
+Mode: `READ_ONLY_AUDIT`
+Repo: `smlfg/Zentrale`
+Source clone: `/tmp/project-intake-tower-src-2026-05-04/zentrale`
+Output directory: `/home/smlflg/Projekte/ProjectIntakeTower/audits/zentrale`
+Branch: `master`
+Commit: `315399689d17af2119c71ef83fd0bd3192dbb11f`
+
+Your task is to convert uncertainty into local Markdown artifacts. Spend tokens on reading, mapping, checking, comparing, and documenting. Do not modify code.
+
+## Non-Negotiable Constraints
+
+- Read only from the source clone and reference docs.
+- Write only inside the output directory listed above.
+- Do not edit the source clone, existing local worktrees, or any GitHub state.
+- Do not create a branch, commit, push, issue, label, or pull request.
+- Do not install dependencies unless a no-network, already-present environment makes a documented verifier possible.
+- Do not make an anchor-repo recommendation.
+- Do not decide what should be archived, kept, merged, or used as target architecture.
+- If a question requires Samuel or Luis, mark `NEEDS_HUMAN` and explain the missing decision.
+
+## Reference Docs
+
+Read these only to understand boundaries and vocabulary:
+
+- `/home/smlflg/Projekte/megaHarness/Höhlengleichnis.md`
+- `/home/smlflg/Projekte/megaHarness/BRIEFING_LUIS.md`
+- `/home/smlflg/Projekte/HarnessEcosystem/docs/gpt5-4-shift-report.md`
+
+Luis owns the consolidation verdict. You provide factual audit material.
+
+## Required Output Files
+
+Create exactly these files:
+
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/zentrale/AGENT_FINDINGS.md`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/zentrale/ARCHITECTURE_MAP.md`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/zentrale/RISK_REGISTER.md`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/zentrale/NEXT_ISSUES.md`
+
+## Audit Procedure
+
+1. Record source snapshot: repo URL, branch, commit SHA, top-level files, and any obvious entrypoints.
+2. Read `README.md`, `DEVELOP.md`, `AGENTS.md`, `pyproject.toml`, `docs/`, `registry/`, `src/zentrale/`, `zentrale/`, `web/`, scripts, and tests.
+3. Identify CLI, TUI, FastAPI/web, dashboard, registry, context-pack, run-tracking, harness-runner, and integration surfaces.
+4. Map how projects, profiles, phases, harnesses, context packs, and run artifacts move through the system.
+5. Compare docs against code only as factual drift, not as a verdict.
+6. Inspect tests for coverage shape and missing high-risk behavior.
+7. Prioritize top findings by operational relevance to Agent Control Tower consolidation.
+
+## File Schemas
+
+### AGENT_FINDINGS.md
+
+Use:
+
+```markdown
+# Zentrale - Agent Findings
+
+## Source Snapshot
+| Field | Value |
+|---|---|
+| Repo | smlfg/Zentrale |
+| Source clone | /tmp/project-intake-tower-src-2026-05-04/zentrale |
+| Branch | master |
+| Commit | 315399689d17af2119c71ef83fd0bd3192dbb11f |
+
+## Executive Summary
+5-8 bullets max.
+
+## Top Findings
+| Priority | Finding | Evidence | Why It Matters |
+|---:|---|---|---|
+
+## Confirmed Facts
+- ...
+
+## NEEDS_HUMAN
+- ...
+```
+
+### ARCHITECTURE_MAP.md
+
+Use tables for:
+
+- Entrypoints.
+- Core modules.
+- Registry/data contracts.
+- Web/API/TUI surfaces.
+- Data flow.
+- External tool interfaces.
+- Tests and verifiers.
+- Documentation/code drift.
+
+### RISK_REGISTER.md
+
+Use:
+
+```markdown
+# Risk Register
+
+| Priority | Risk | Impact | Likelihood | Evidence | Mitigation Candidate | Needs Human? |
+|---:|---|---|---|---|---|---|
+```
+
+### NEXT_ISSUES.md
+
+Write 5-10 issue candidates:
+
+```markdown
+## Issue Candidate N - Title
+
+- Type: audit/doc/test/verifier/small-fix
+- Suggested A-F category: A/B/C/D/E/F/provisional
+- Evidence:
+- Why now:
+- Acceptance criteria:
+- Human decision needed:
+```
+
+The A-F category is only a provisional suggestion from the Höhlengleichnis vocabulary. Do not present it as final.
+
+## Stop Conditions
+
+Stop only the unsafe part, not the whole audit, if:
+
+- Scope expands into consolidation decision.
+- You need to mutate source code.
+- You need network or secrets.
+- You cannot separate facts from recommendations.
+- You are about to decide Luis' architecture question.
+
+Document any such case under `NEEDS_HUMAN`.

briefings/03_audit_megaharness.md

@@ -0,0 +1,141 @@
+# READY Briefing 03 - Audit MegaHarness
+
+## Job Contract
+
+Mode: `READ_ONLY_AUDIT`
+Repo: `smlfg/MegaHarness`
+Source clone: `/tmp/project-intake-tower-src-2026-05-04/megaharness`
+Output directory: `/home/smlflg/Projekte/ProjectIntakeTower/audits/megaharness`
+Branch: `master`
+Commit: `452f9d5ebfb4e6b5f569b1804fdcfe880e08629e`
+
+Your task is to convert uncertainty into local Markdown artifacts. Spend tokens on reading, mapping, checking, comparing, and documenting. Do not modify code.
+
+## Non-Negotiable Constraints
+
+- Read only from the source clone and reference docs.
+- Write only inside the output directory listed above.
+- Do not edit the source clone, existing local worktrees, or any GitHub state.
+- Do not create a branch, commit, push, issue, label, or pull request.
+- Do not install dependencies.
+- Do not make an anchor-repo recommendation.
+- Do not decide what should be archived, kept, merged, or used as target architecture.
+- If a question requires Samuel or Luis, mark `NEEDS_HUMAN` and explain the missing decision.
+
+## Reference Docs
+
+For this audit, the source clone itself contains the key doctrine docs:
+
+- `/tmp/project-intake-tower-src-2026-05-04/megaharness/ARCHITECTURE.md`
+- `/tmp/project-intake-tower-src-2026-05-04/megaharness/Artefakt_USP.md`
+- `/tmp/project-intake-tower-src-2026-05-04/megaharness/Höhlengleichnis.md`
+- `/tmp/project-intake-tower-src-2026-05-04/megaharness/BRIEFING_LUIS.md`
+- `/tmp/project-intake-tower-src-2026-05-04/megaharness/idea`
+
+Also read:
+
+- `/home/smlflg/Projekte/HarnessEcosystem/docs/gpt5-4-shift-report.md`
+
+Luis owns the consolidation verdict. You provide factual audit material about the doctrine repository and its implementation gap.
+
+## Required Output Files
+
+Create exactly these files:
+
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/megaharness/AGENT_FINDINGS.md`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/megaharness/ARCHITECTURE_MAP.md`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/megaharness/RISK_REGISTER.md`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/megaharness/NEXT_ISSUES.md`
+
+## Audit Procedure
+
+1. Record source snapshot: repo URL, branch, commit SHA, top-level files, and artifact-only nature of the repo.
+2. Read every source document in the clone.
+3. Extract the intended layers, routing doctrine, build-vs-integrate heuristics, Höhlengleichnis A-F categories, and Luis handoff boundaries.
+4. Map what is doctrine, what is plan, what is accepted constraint, and what is missing implementation.
+5. Compare docs against each other only as factual tension, not as a verdict.
+6. Identify testability and verifier gaps for a doctrine-first repo.
+7. Prioritize top findings by usefulness to Samuel and Luis tomorrow morning.
+
+## File Schemas
+
+### AGENT_FINDINGS.md
+
+Use:
+
+```markdown
+# MegaHarness - Agent Findings
+
+## Source Snapshot
+| Field | Value |
+|---|---|
+| Repo | smlfg/MegaHarness |
+| Source clone | /tmp/project-intake-tower-src-2026-05-04/megaharness |
+| Branch | master |
+| Commit | 452f9d5ebfb4e6b5f569b1804fdcfe880e08629e |
+
+## Executive Summary
+5-8 bullets max.
+
+## Top Findings
+| Priority | Finding | Evidence | Why It Matters |
+|---:|---|---|---|
+
+## Confirmed Facts
+- ...
+
+## NEEDS_HUMAN
+- ...
+```
+
+### ARCHITECTURE_MAP.md
+
+Use tables for:
+
+- Doctrine documents.
+- Intended layers.
+- Proposed data stores or MD-DB concepts.
+- Harness surfaces.
+- Decision vocabulary.
+- Gaps between doctrine and executable code.
+- References useful to Luis.
+
+### RISK_REGISTER.md
+
+Use:
+
+```markdown
+# Risk Register
+
+| Priority | Risk | Impact | Likelihood | Evidence | Mitigation Candidate | Needs Human? |
+|---:|---|---|---|---|---|---|
+```
+
+### NEXT_ISSUES.md
+
+Write 5-10 issue candidates:
+
+```markdown
+## Issue Candidate N - Title
+
+- Type: audit/doc/test/verifier/small-fix
+- Suggested A-F category: A/B/C/D/E/F/provisional
+- Evidence:
+- Why now:
+- Acceptance criteria:
+- Human decision needed:
+```
+
+The A-F category is only a provisional suggestion from the Höhlengleichnis vocabulary. Do not present it as final.
+
+## Stop Conditions
+
+Stop only the unsafe part, not the whole audit, if:
+
+- Scope expands into consolidation decision.
+- You need to mutate source code.
+- You need network or secrets.
+- You cannot separate facts from recommendations.
+- You are about to decide Luis' architecture question.
+
+Document any such case under `NEEDS_HUMAN`.

briefings/04_aggregator.md

@@ -0,0 +1,104 @@
+# READY Briefing 04 - Cross-Repo Aggregator
+
+## Job Contract
+
+Mode: `READ_ONLY_SYNTHESIS`
+Input directory: `/home/smlflg/Projekte/ProjectIntakeTower/audits`
+Output file: `/home/smlflg/Projekte/ProjectIntakeTower/audits/TOWER_HEALTH_OVERVIEW.md`
+
+Your task is to synthesize the three completed read-only audits into one five-minute cross-repo overview for Samuel and Luis. Do not read source repos unless an audit artifact is missing a critical source snapshot field. Prefer the audit artifacts as the source of truth for this synthesis.
+
+## Non-Negotiable Constraints
+
+- Write only the output file listed above.
+- Do not edit the three repo audit folders except for reading their Markdown files.
+- Do not edit source clones or existing local worktrees.
+- Do not create a branch, commit, push, issue, label, or pull request.
+- Do not make an anchor-repo recommendation.
+- Do not decide what should be archived, kept, merged, or used as target architecture.
+- Do not write a consolidation sequence as a verdict.
+- If the input artifacts are incomplete, mark the gap and continue with partial synthesis.
+
+## Required Inputs
+
+Read these files if present:
+
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/AGENT_FINDINGS.md`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/ARCHITECTURE_MAP.md`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/RISK_REGISTER.md`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/kommandozentrale/NEXT_ISSUES.md`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/zentrale/AGENT_FINDINGS.md`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/zentrale/ARCHITECTURE_MAP.md`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/zentrale/RISK_REGISTER.md`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/zentrale/NEXT_ISSUES.md`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/megaharness/AGENT_FINDINGS.md`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/megaharness/ARCHITECTURE_MAP.md`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/megaharness/RISK_REGISTER.md`
+- `/home/smlflg/Projekte/ProjectIntakeTower/audits/megaharness/NEXT_ISSUES.md`
+
+## Output Schema
+
+Create:
+
+`/home/smlflg/Projekte/ProjectIntakeTower/audits/TOWER_HEALTH_OVERVIEW.md`
+
+Use exactly this structure:
+
+```markdown
+# Tower Health Overview
+
+## No Architecture Verdict
+Short statement that this file is facts and synthesis only. Luis owns the consolidation decision.
+
+## Source Snapshot
+| Repo | Source | Branch | Commit | Audit Complete? | Missing Inputs |
+|---|---|---|---|---|---|
+
+## Five-Minute Executive Summary
+5-8 bullets max.
+
+## Capability Comparison
+| Capability | KommandoZentrale | Zentrale | MegaHarness | Notes |
+|---|---|---|---|---|
+
+## Overlap And Duplication Map
+| Theme | Repos Involved | Evidence | Why It Matters |
+|---|---|---|---|
+
+## Shared Risk Themes
+| Priority | Risk Theme | Repos | Evidence | Human Decision Needed? |
+|---:|---|---|---|---|
+
+## Test And Verifier Gaps
+| Repo | Existing Signal | Gap | Suggested Next Check |
+|---|---|---|---|
+
+## NEEDS_HUMAN Index
+| Repo | Item | Why Human |
+|---|---|---|
+
+## Tomorrow Morning Review Checklist
+- [ ] ...
+
+## Next Issue Queue Without Verdict
+| Priority | Repo | Issue Candidate | Type | Why Now |
+|---:|---|---|---|---|
+```
+
+## Synthesis Rules
+
+- Merge duplicate risks into themes, but keep repo-specific evidence.
+- Prefer tables over prose.
+- Keep each section short enough to scan.
+- Name missing inputs explicitly.
+- If a statement is an inference, label it as inference.
+- Avoid words like "anchor", "archive", "consolidate into", "should be foundation", or equivalent verdict language except in the explicit "No Architecture Verdict" disclaimer.
+
+## Stop Conditions
+
+Mark `NEEDS_HUMAN` if:
+
+- The audits conflict on facts.
+- A repo audit is missing.
+- The only useful summary would require choosing an architecture direction.
+- The synthesis would create a verdict that belongs to Luis.

index.html

@@ -0,0 +1,334 @@
+<!doctype html>
+<html lang="de">
+  <head>
+    <meta charset="utf-8" />
+    <meta name="viewport" content="width=device-width, initial-scale=1" />
+    <title>Owner Packet Viewer</title>
+    <style>
+      :root {
+        color-scheme: dark;
+        font-family:
+          Inter, ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
+        background: #111417;
+        color: #eef2ef;
+      }
+
+      * {
+        box-sizing: border-box;
+      }
+
+      body {
+        min-height: 100vh;
+        margin: 0;
+        background: #111417;
+      }
+
+      button,
+      textarea {
+        font: inherit;
+      }
+
+      .shell {
+        min-height: 100vh;
+        display: grid;
+        grid-template-rows: auto minmax(0, 1fr);
+        gap: 16px;
+        padding: 18px;
+      }
+
+      header,
+      main {
+        width: min(980px, 100%);
+        margin: 0 auto;
+      }
+
+      header {
+        display: grid;
+        grid-template-columns: minmax(0, 1fr) auto;
+        gap: 16px;
+        align-items: end;
+        border-bottom: 1px solid #2c3533;
+        padding-bottom: 14px;
+      }
+
+      .eyebrow,
+      .label {
+        color: #93a09b;
+        font-size: 0.73rem;
+        font-weight: 800;
+        letter-spacing: 0;
+        text-transform: uppercase;
+      }
+
+      h1 {
+        margin: 4px 0 0;
+        font-size: clamp(1.5rem, 3vw, 2.35rem);
+        line-height: 1.08;
+      }
+
+      .status {
+        min-width: 150px;
+        border: 1px solid #40514d;
+        border-radius: 8px;
+        padding: 10px 12px;
+        color: #a7f0dd;
+        text-align: center;
+        font-weight: 800;
+      }
+
+      main {
+        display: grid;
+        grid-template-columns: minmax(0, 1fr) minmax(260px, 320px);
+        gap: 16px;
+        align-items: start;
+      }
+
+      .packet,
+      .side {
+        border: 1px solid #293331;
+        border-radius: 8px;
+        background: #171d20;
+        box-shadow: 0 20px 50px rgba(0, 0, 0, 0.24);
+      }
+
+      .packet {
+        padding: 22px;
+      }
+
+      .question {
+        margin: 8px 0 14px;
+        font-size: 1.42rem;
+        line-height: 1.22;
+      }
+
+      .context {
+        margin: 0;
+        color: #c7d0cb;
+        line-height: 1.55;
+      }
+
+      .field {
+        display: grid;
+        gap: 7px;
+        margin-top: 18px;
+      }
+
+      .value {
+        border-left: 3px solid #6de0c9;
+        padding: 11px 13px;
+        background: #20322f;
+        color: #f6fbf9;
+        line-height: 1.45;
+      }
+
+      .risk {
+        border-left-color: #ffc56f;
+        background: #33291b;
+      }
+
+      .actions {
+        display: grid;
+        grid-template-columns: repeat(3, minmax(0, 1fr));
+        gap: 10px;
+        margin-top: 22px;
+      }
+
+      .action {
+        min-height: 44px;
+        border: 0;
+        border-radius: 8px;
+        color: #06110e;
+        font-weight: 850;
+        cursor: pointer;
+      }
+
+      .action:disabled {
+        cursor: default;
+        opacity: 0.45;
+      }
+
+      .action.selected {
+        box-shadow: 0 0 0 3px rgba(238, 242, 239, 0.32);
+      }
+
+      [data-action="Approve"] {
+        background: #6de0c9;
+      }
+
+      [data-action="Reject"] {
+        background: #ff8d8d;
+      }
+
+      [data-action="Ask"] {
+        background: #ffc56f;
+      }
+
+      .side {
+        display: grid;
+        gap: 16px;
+        padding: 18px;
+      }
+
+      textarea {
+        min-height: 180px;
+        resize: vertical;
+        border: 1px solid #40514d;
+        border-radius: 8px;
+        padding: 12px;
+        outline: none;
+        background: #0d1113;
+        color: #eef2ef;
+      }
+
+      textarea:focus {
+        border-color: #6de0c9;
+        box-shadow: 0 0 0 3px rgba(109, 224, 201, 0.13);
+      }
+
+      .decision {
+        min-height: 48px;
+        border: 1px solid #40514d;
+        border-radius: 8px;
+        padding: 12px;
+        color: #c7d0cb;
+      }
+
+      .error {
+        color: #ffabab;
+      }
+
+      @media (max-width: 760px) {
+        header,
+        main {
+          grid-template-columns: 1fr;
+        }
+
+        .status {
+          text-align: left;
+        }
+
+        .actions {
+          grid-template-columns: 1fr;
+        }
+      }
+    </style>
+  </head>
+  <body>
+    <div class="shell">
+      <header>
+        <div>
+          <div class="eyebrow">Owner Packet</div>
+          <h1 id="project">Loading packet</h1>
+        </div>
+        <div class="status" id="status">loading</div>
+      </header>
+
+      <main>
+        <section class="packet" aria-label="Owner decision packet">
+          <div class="label">Question</div>
+          <h2 class="question" id="question">Loading owner_packet.json...</h2>
+          <p class="context" id="context"></p>
+
+          <div class="field">
+            <div class="label">Recommended action</div>
+            <div class="value" id="recommendedAction"></div>
+          </div>
+
+          <div class="field">
+            <div class="label">Risk</div>
+            <div class="value risk" id="risk"></div>
+          </div>
+
+          <div class="actions" id="actions" aria-label="Decision actions"></div>
+        </section>
+
+        <aside class="side" aria-label="Local owner note">
+          <div>
+            <div class="label">Local decision</div>
+            <div class="decision" id="decision">No decision selected.</div>
+          </div>
+
+          <label class="label" for="note">Local note</label>
+          <textarea id="note" placeholder="Private local note. Not written back to owner_packet.json."></textarea>
+        </aside>
+      </main>
+    </div>
+
+    <script>
+      const noteKey = "project-intake-tower.owner-note";
+      const selectedKey = "project-intake-tower.owner-decision";
+
+      const elements = {
+        project: document.getElementById("project"),
+        status: document.getElementById("status"),
+        question: document.getElementById("question"),
+        context: document.getElementById("context"),
+        recommendedAction: document.getElementById("recommendedAction"),
+        risk: document.getElementById("risk"),
+        actions: document.getElementById("actions"),
+        decision: document.getElementById("decision"),
+        note: document.getElementById("note")
+      };
+
+      elements.note.value = localStorage.getItem(noteKey) || "";
+      elements.note.addEventListener("input", () => {
+        localStorage.setItem(noteKey, elements.note.value);
+      });
+
+      fetch("owner_packet.json", { cache: "no-store" })
+        .then((response) => {
+          if (!response.ok) {
+            throw new Error("owner_packet.json could not be loaded");
+          }
+          return response.json();
+        })
+        .then(renderPacket)
+        .catch((error) => {
+          elements.status.textContent = "error";
+          elements.question.textContent = "Packet could not be loaded.";
+          elements.context.textContent = error.message;
+          elements.context.classList.add("error");
+        });
+
+      function renderPacket(packet) {
+        elements.project.textContent = packet.project || "Unnamed project";
+        elements.status.textContent = packet.status || "unknown";
+        elements.question.textContent = packet.question || "No question provided.";
+        elements.context.textContent = packet.context || "No context provided.";
+        elements.recommendedAction.textContent = packet.recommended_action || "No recommendation provided.";
+        elements.risk.textContent = packet.risk || "No risk provided.";
+        renderActions(Array.isArray(packet.options) ? packet.options : ["Approve", "Reject", "Ask"]);
+      }
+
+      function renderActions(options) {
+        elements.actions.innerHTML = "";
+        const savedDecision = localStorage.getItem(selectedKey);
+
+        for (const option of options) {
+          const button = document.createElement("button");
+          button.type = "button";
+          button.className = "action";
+          button.dataset.action = option;
+          button.textContent = option;
+          button.addEventListener("click", () => selectDecision(option));
+          elements.actions.appendChild(button);
+        }
+
+        if (savedDecision) {
+          selectDecision(savedDecision);
+        }
+      }
+
+      function selectDecision(decision) {
+        localStorage.setItem(selectedKey, decision);
+        elements.decision.textContent = decision;
+
+        for (const button of elements.actions.querySelectorAll("button")) {
+          const selected = button.dataset.action === decision;
+          button.classList.toggle("selected", selected);
+          button.disabled = true;
+        }
+      }
+    </script>
+  </body>
+</html>

night_logs/LANDING_NOTE_2026-05-04_19-55.md

@@ -0,0 +1,26 @@
+# Landing Note
+
+Ich habe heute einen massiven agentischen Stress-Test gefahren.
+
+## Gefühl
+- Es war extrem spannend.
+- Es hat Spaß gemacht.
+- Es war kognitiv überwältigend.
+- Ich bin jetzt nicht mehr in Review-Form.
+
+## Wichtig
+- Heute Nacht keine neuen Agenten mehr starten.
+- Keine Architekturentscheidung treffen.
+- Keine PRs / Pushes / Branches.
+- Morgen nur Artefakte sichten.
+
+## Morgen prüfen
+- Was wurde wirklich geschrieben?
+- Welche Dateien sind nützlich?
+- Welche Outputs sind Müll?
+- Welche Erkenntnisse über Agent-Orchestrierung sind real?
+- Wo hat Hermes sinnvoll interveniert?
+- Welche Grenzen braucht mein zukünftiges Agent-Engineering-System?
+
+## Urteil
+Noch kein Urteil. Erst schlafen, dann verifizieren.

owner_packet.json

@@ -0,0 +1,13 @@
+{
+  "project": "ProjectIntakeTower",
+  "status": "needs_human_decision",
+  "question": "Soll Luis zuerst nur die Public-Clone-Audits lesen, oder auch lokale Dirty States einbeziehen?",
+  "context": "Die vorhandenen Audit-Artefakte nutzen Public Clones als Quelle. Lokale Dirty States bei Zentrale und MegaHarness sind dokumentiert, wurden aber nicht als Wahrheit verwendet.",
+  "recommended_action": "Zuerst Public-Clone-Audits lesen und lokale Dirty States nur als separate offene Frage behandeln.",
+  "options": [
+    "Approve",
+    "Reject",
+    "Ask"
+  ],
+  "risk": "Public-Clone-Fakten und lokale Dirty States koennen vermischt werden, wenn diese Quelle nicht zuerst entschieden wird."
+}