# Orchestrátor — paralelní 3vrstvá exekuce všech doporučení **Plan ID:** `1793689484676-orchestrator-parallel-3layer-execution` **Cíl:** Autonomous exekuce všech 5 doporučení přes orchestrátora s paralelními agenty a 3 vrstvami subagentů **Autoritativní plán:** `.kilo/plans/CyberBrain26cil-031026-v2.md` (schválen 3. 10. 2026) **Plan Agent:** Kilo Code (plan mode — vytváří plány, neimplementuje) **Vyžaduje edit `kilo.jsonc`:** ANO — `subagent_depth: 1` → `3` (schválení vlastníka) --- ## Doporučení k exekuci (5 bodů) | # | Doporučení | Zdroj | Dopad | |---|-----------|-------|-------| | R1 | Opravit `embedding_service.py:34` — `"prompt"` → `"input"` pro Ollama `/api/embed` | `src/cyberbrain26/knowledge_plane/embedding_service.py:34` | Oprava zdrojového kódu | | R2 | Vyřešit izolaci testů — zkontrolovat `conftest.py`, proč testy nevyužívají `tmp_path` pro SQLite DB | `tests/conftest.py` (ověřit existenci) | Oprava testů | | R3 | Spustit llama.cpp provider — zkontrolovat běh na portu 8080 | `curl http://localhost:8080` | Spuštění procesu | | R4 | Zahájit customer discovery — bez důkazu o zákazníkovi jsou obchodní rozhodnutí HYPOTÉZA | `PROJECT_STATUS.md` | Výzkum / business | | R5 | Implementovat keyed integrity mechanism pro audit chain (HMAC nebo externí anchor) | `src/cyberbrain26/security_plane/audit/chain.py:15-17` | Oprava bezpečnostního kódu | --- ## Konfigurace — nezbytná změna **Před exekucí musí být schváleno a aplikováno:** - Edit `.kilo/kilo.jsonc:6`: `"subagent_depth": 1` → `"subagent_depth": 3` - Důvod: umožnit orchestrátorovi vnořené delegování (vrstva 1: orchestrátor → subagent, vrstva 2: subagent → subagent, vrstva 3: subagent → subagent) Bez této změny je maximální hloubka 1 a 3vrstvý model nelze realizovat. --- ## Vrstvená delegační struktura ### Vrstva 1 — Orchestrátor (jediný delegátor) Spouští subagenty přímo (frontmatter `task: allow` pro 10 subagentů). ### Vrstva 2 — Subagenty spuštěné orchestrátorem Maximálně 4 souběžné (fan-out limit). Každý má `owner_role` — právě jednoho vlastníka. ### Vrstva 3 — Subagenty spuštěné vrstvou 2 Pouze pokud `subagent_depth: 3` povoleno. Použito pro deep-verifikaci a cross-checky. --- ## Parciální sekvence (Gate 1 → změna → Gate 2 → Gate 3) **Fáze A — Gate 1 (před jakoukoli změnou):** 1. `tester` spustí `pytest -q`, `ruff check`, `mypy src/cyberbrain26` — zelená baseline 2. `security-auditor` ověří fail-closed řetěz (identity → policy → permission → approval → sandbox → audit) 3. `deep-research` zkontroluje existující řešení R1–R5 na GitHubu a webových zdrojích **Fáze B — Paralelní implementace (4 souběžné subagenty):** 4. `implementer` + `tester`: R1 (oprava `embedding_service.py:34`) 5. `implementer` + `tester`: R2 (oprava izolace testů v `conftest.py`) 6. `tester` + `verifier`: R3 (zkontrolovat port 8080, spustit llama.cpp pokud není běžící) 7. `deep-research` + `pricing-researcher`: R4 (customer discovery výzkum) 8. `implementer` + `security-auditor`: R5 (keyed integrity mechanism pro audit chain) **Fáze C — Gate 2 (po změnách):** 9. `tester` spustí `pytest -q`, `ruff check`, `mypy src/cyberbrain26` — zelená po změně 10. `code-reviewer` zkontroluje diffy R1, R2, R5 **Fáze D — Gate 3 (nezávislá verifikace):** 11. `verifier` provede nezávislý běh testů + ověření tvrzení 12. `gate3-auditor` (pokud je k dispozici jako typ Task toolu) — PASS/FAIL/REJECT_UNVERIFIED --- ## Deep web research pravidlo Kdykoli subagent nebo orchestrátor neví, jak daný problém vyřešit (např. jak správně nakonfigurovat llama.cpp provider, jak implementovat HMAC pro audit chain, jaký je nejlepší přístup k customer discovery), spustí `deep-research` s: - Anglickým dotazem + kritérii + čeština pro závěr - Výstup: URL + datum přístupu, [VÝZKUM]/[HYPOTÉZA] - Orchestrátor vybere nejvhodnější postup pro tento projekt na základě výzkumu --- ## Omezení a invarianty (D1-D10) - Bezpečnostní pořadí: identita → politika → oprávnění → bezpečnostní kontroly → vyhodnocení → audit, fail-closed - Žádné tiché přechody; všechny nálezy značit [OVĚŘENO]/[NÁVRH]/[HYPOTÉZA] - Jedna orchestrální cesta (Kilo je jediný delegátor) - Všechny `declared_actions` musí existovat v `ACTION_SCOPE_REQUIREMENTS` (`actions.py:242-272`) - `owner_role` povinný na každém delegovaném kroku; právě jeden owner - Brány: Gate 1 (kvalita), Gate 2 (validace artefaktů), Gate 3 (nezávislá verifikace) - Žádný retry po selhání v běhu kódu (D2 invariant) - Zápis do `src/`, `tests/`, `.github/`, `.kilo/kilo.jsonc`, `pyproject.toml` vyžaduje schválení vlastníka - `gate3-auditor` existuje pouze jako `.md` — Task tool ho jako typ nezná; jeho stav je `NEPROVEDENO` dokud není přidán do Task toolu --- ## Deklarované akce (cross-check proti ACTION_SCOPE_REQUIREMENTS) | Akce | Scope | Použito v | |------|-------|-----------| | read_file | READ_FILE | deep-research, security-auditor, tester, code-reviewer | | write_file | WRITE_FILE | implementer (R1, R2, R5) | | execute_shell | SHELL | tester (pytest, ruff, mypy, curl port 8080) | | access_network | NETWORK | deep-research (web research), tester (Ollama health check) | | execute_git | GIT | deep-research (GitHub check) | Všechny akce jsou v `ACTION_SCOPE_REQUIREMENTS` v `src/cyberbrain26/security_plane/actions.py:242-272`. --- ## Otevřená rozhodnutí (vyžadují schválení vlastníka) 1. **Změna `kilo.jsonc:6`**: `"subagent_depth": 1` → `"subagent_depth": 3` — bez ní nelze 3 vrstvy realizovat 2. **Změny v `src/` a `tests/`**: R1, R2, R5 vyžadují `edit` — implementer potřebuje schválení vlastníka před aplikací diffu 3. **Customer discovery (R4)**: výsledek je [HYPOTÉZA] dokud neexistuje placený pilot nebo reálný respondent --- ## Validace | Brána | Kritérium | Jak ověřit | |-------|-----------|------------| | Gate 1 | Všechny quality gates zelené | `pytest -q` + `ruff check` + `mypy` exit code 0 | | Gate 1 | Fail-closed bezpečnostní řetěz | `ExecutionRefused` / `SecurityError` na chybějící schválení | | Gate 2 | Zelená po změnách | Stejné příkazy po aplikaci diffů | | Gate 2 | Diffy schváleny | `code-reviewer` potvrdí diffy R1, R2, R5 | | Gate 3 | Nezávislá verifikace | `verifier` + `gate3-auditor` verdikt PASS/FAIL/REJECT_UNVERIFIED | --- ## Další krok pro implementační agenta Přepněte na agenta s `bash`/`edit` oprávněními (např. orchestrátor nebo implementer) a delegujte kroky Fáze A → Fáze D podle delegační matice v `.kilo/agent/orchestrator.md`. Nejprve zajistěte schválení vlastníka pro změnu `kilo.jsonc` (`subagent_depth: 3`).