Doposud Orca plánoval mise jako lineární řetězec — každá fáze čekala na předchozí, i když jich bylo deset a navzájem se nepřekrývaly. Výsledek: i s nastavenými třemi session běžel vlastně jen jeden agent a zbytek fronty čekal na uvolnění.
To se teď mění. Plánovač umí sestavit závislostní graf (DAG), kde nezávislé fáze startují současně — a skutečně tak využijí paralelní kapacitu.
Jak to funguje
Každá fáze v plánu nově dostane id (krátký slug jako api, ui, tests) a případně dependsOn — seznam id fází, které musí skončit, než tahle fáze začne. Pokud fáze žádné závislosti nemá, startuje okamžitě.
Příklad plánového výstupu:
[
{ "id": "schema", "title": "Nové DB schéma", "dependsOn": [] },
{ "id": "api", "title": "API endpoint", "dependsOn": ["schema"] },
{ "id": "ui", "title": "Dashboard komponenta", "dependsOn": ["schema"] },
{ "id": "tests", "title": "Integrační testy", "dependsOn": ["api", "ui"] }
]Vidíte api i ui závisí jen na schema — spustí se současně. tests počká na oba. Místo čtyř sériových kroků jsou to tři časové sloty.
Dvoufázové napojení závislostí
Persistace grafu probíhá ve dvou průchodech:
- Vytvoření úkolů — všechny fáze se nejdřív zapíší do databáze, aby
dependsOnmohlo odkazovat na sourozence definované před i po něm v poli - Napojení závislostí —
dependsOnse namapuje na skutečné DB id, případné halucinované slugy se tiše přenesou na předchozí fázi (fallback), nikdy se nevytvoří cyklus
Zpětná kompatibilita se zachovává: pokud žádná fáze nemá id, Orca automaticky padne zpátky na lineární řetězec — starší plány a manuální režim fungují beze změny.
Auto-PR: když jedou dva, potřebují izolaci
Paralelní agenti nemohou pracovat ve sdíleném checkoutu — jeden commit by přepsal druhého. Proto když nastavíte více než jednu session, Orca automaticky zapne PR-native mýd: každá fáze dostane vlastní worktree, provede změny, a Orca je složí do jednoho PR.
Pokud PR režim výslovně vypnete (i když máte víc session), Orca vaši volbu respektuje — ale paralelní fáze se pak sériově. Je to bezpečnější než mlčky clobberovat.
Resume notes místo popisu úkolu
Druhá věc, která se v tomto commitu výrazně zlepšila: zpětná vazba od review a důvody relaunchů už se nelepí do popisu úkolu jako textové bloky.
Dřív vypadala situace takto: agent dostal task s popisem, který po pátém rejectu obsahoval pět nad sebou naskládaných bloků [Review rejected — ...]. Nový agent nevěděl, který feedback je aktuální a který už vyřešil.
Teď má každý úkol sloupec resume_note — jedno místo pro aktuální vstup. Review reject tam napíše nový důvod, předchozí se přepíše. Při čistém zavření se poznámka vymaže. Agent ji dostává jako samostatný blok ve svém promptu, oddělený od statického zadání.
Prompt fáze respektuje paralelismus
Prompt pro agenta ve fázi nově říká:
Other phases may already be done, or may be running RIGHT NOW alongside you in the SAME working tree. Do NOT redo or re-verify other phases’ work — and edit ONLY the files your own deliverable needs.
To je zásadní změna proti dřívějšímu „earlier phases were already completed”. Agent už nemá iluzi, že je v sérii — ví, že vedle něj běží další a má respektovat hranice své fáze.
Replan zachovává šířku grafu
Když Orca během mise přeplánuje (např. po review rejectu nebo nových požadavcích), bere si aktuální max_sessions a nastavení izolace z mise. Nový plán dostane stejný paralelní kontext — nespadne zpátky na lineární řetězec jen proto, že se plánovalo znovu.
Tyhle změny dohromady znamenají, že Orca přestává být „jeden agent a fronta” a začíná fungovat jako skutečný orchestrátor, kde se využívá paralelní kapacita tam, kde dává smysl — a kde ne, tam se bezpečně vrátí na sérii.