# CyberBrain26 v5 — cesta k prvnímu prodejnému produktu **Stav:** návrh k ověření, nenahrazuje schválenou roadmapu v4.1 **Datum:** 1. října 2026 **Hlavní cíl:** dostat do rukou prvních zákazníků úzký, užitečný a pravdivě popsaný produkt co nejdříve. **Pracovní časový cíl:** nabídnout první placený pilot za 8–10 týdnů od zahájení V5; otevřenou placenou betu cílit přibližně na 10–14 týdnů. Jde o odhad pro jednoho vývojáře na plný úvazek, ne závazný termín; závisí na zákaznickém ověření, stavu současných změn a složitosti první integrace. --- > **`status: superseded`** > **superseded_by:** `.kilo/plans/CyberBrain26cil-031026-v2.md` (schválený směr, 3. 10. 2026) > **superseded:** 4. 10. 2026 > > **Tento dokument NENÍ autoritativní plán.** Na otázku „co stavíme a v jakém > pořadí" odpovídá `.kilo/plans/CyberBrain26cil-031026-v2.md`. > > Ceny a obchodní závěry V5 jsou **nepotvrzené odhady**. Neprezentuj je jako > schválený ceník ani jako validovanou poptávku. > V5 mění pořadí práce. Dlouhodobá vize CyberBrain26 zůstává zachovaná, ale vývoj se teď řídí jedním konkrétním produktem, zákaznickou odezvou a bezpečnostními důkazy. --- ## 1. Produktové rozhodnutí ### Pracovní název produktu **CyberBrain Agent Guard** — lokální kontrolní vrstva pro spouštění akcí AI agentů nad vývojářským pracovním adresářem. ### Zákazník a problém První cílová skupina jsou **bezpečnostně uvědomělí vývojáři a technická vedení malých softwarových týmů**. První produkt bude instalovaný na jednotlivých pracovních stanicích; týmová správa zatím není součástí nabídky. Tito zákazníci chtějí používat coding agenty nad vlastním repozitářem, ale potřebují: **Doporučená obchodní hypotéza po desk research:** kupujícím je CTO, engineering lead nebo bezpečnostní/platformní vedoucí softwarového týmu s přibližně 10–100 vývojáři; vývojář je uživatel. Segment, rozpočet i hodnotová nabídka jsou stále neověřené. Podrobná konkurence, cenové testy a monetizační varianta jsou v [tržní analýze a monetizační strategii](docs/product/MARKET_AND_MONETIZATION_ANALYSIS_V5.md). - omezit, které příkazy, soubory a prostředky agent smí používat; - před citlivou akcí vidět, co se skutečně spustí, a rozhodnutí schválit nebo odmítnout; - spouštět kód v odděleném pracovním prostoru bez nechráněného fallbacku; - po běhu zjistit, kdo co povolil, co se provedlo a jaký byl výsledek; - vědět, zda data odcházejí do vzdáleného modelu. Jde o **ověřovací hypotézu**, nikoli potvrzený tržní fakt. První týden je určený k jejímu ověření. Pokud rozhovory ukážou jiný naléhavý problém, upraví se produktový záběr dřív než architektura. ### Slib produktu > „Agent může pracovat ve vymezeném pracovním prostoru. Uživatel vidí a schvaluje akce, které mohou něco změnit, a po běhu má místní záznam o tom, co se stalo.“ Slib se vztahuje pouze na přesně uvedené podporované systémy a konfigurace. Bubblewrap je současný backend pro omezený místní prototyp; sám o sobě není bezpečnostní certifikací ani zárukou ochrany proti všem škodlivým programům. ### První produktová forma - Jednouživatelský nástroj pro Linux, ovládaný přes CLI. - První instalaci omezit na jednu ověřenou distribuci a její podporovanou verzi, vybranou podle zákaznických rozhovorů. Předběžně vybráno **Ubuntu 24.04 LTS** ([D1](docs/product/DECISIONS_LOG_V5.md#d1--podporovaný-os-ubuntu-2404-lts), rozhodnutí vlastníka před discovery, podmíněné potvrzením rozhovory). - Jeden běžný úkol: povolit vybranému coding agentovi vykonat konkrétní akci nad kopií projektu nebo samostatným Git worktree pro danou úlohu. - Lokální politika, lokální schvalovací obrazovka v CLI a lokální auditní historie. - Model lze provozovat lokálně nebo přes explicitně zvoleného cloudového providera. Žádné tiché přepnutí mezi lokálním a cloudovým modelem; před cloudovým přenosem musí být zřejmé, jaká data opouštějí zařízení. - Začít řízenými, placenými piloty a instalací s podporou. Opakovatelný veřejný prodej přijde až po ověření instalace, podpory a ochoty platit. ### Co není první produkt - obecný „AI operating system“ pro jednotlivce i firmy; - plnohodnotná náhrada IDE nebo další coding agent; - cloudová víceuživatelská služba; - bezpečnostní produkt pro spouštění libovolného nepřátelského kódu; - certifikované nebo compliance-ready řešení; - sada všech režimů PERSONAL / SECURITY / RESEARCH / ENTERPRISE / COMPLIANCE; - nová implementace všech agentních frameworků, sandboxů a modelových providerů. --- ## 2. Co ukazuje současný stav projektu Repozitář má základy, na kterých lze postavit úzký produkt: - `AuthorizedExecutionService` vede akci přes identitu, policy, oprávnění, případné schválení a audit. - `BubblewrapExecutionProvider` spouští Python a shell v Linuxových namespaces, bez sítě a bez nechráněného fallbacku. - Ptahův `CoderAgent` už je napojený na autorizovaný exekuční tok. - Existují modelové adaptéry a rozhraní providerů. - V pracovním stromu jsou nové základy SQLite pro tasky, audit, schválení a projektovou paměť; jejich stav, integraci a testovací pokrytí je potřeba nejprve ověřit. - `EXECUTION_SECURITY_REVIEW.md` popisuje konkrétní rizika sandboxu, mimo jiné limity počtu procesů, agregátní paměti, diskového prostoru a důvěry v zapisovatelný pracovní adresář. Projekt zatím není hotový coding agent pro běžnou přirozenojazyčnou práci nad repozitářem. Současné CLI umí plánovat a vykonávat kroky, ale první verze musí dodat konzistentní uživatelský tok od zadání nebo předání akce až po její schválení, běh a kontrolu výsledku. Pracovní strom obsahuje významné staged, unstaged a nové soubory. V5 proto nezačíná další velkou přestavbou. Nejdřív se zachová a zmapuje současná práce, roztřídí se podle produktu a ověří se, co je skutečně integrováno. Podrobné mapování stávajících komponent proti MVP je v [MVP gap analysis](docs/product/MVP_GAP_ANALYSIS_V5.md). Cílový uživatel, jednovětý slib a rozhovorový plán jsou v [product briefu](docs/product/PRODUCT_BRIEF_V5.md) a [customer discovery plánu](docs/product/CUSTOMER_DISCOVERY_V5.md). --- ## 3. Plán po etapách Časy jsou orientační pro jednoho vývojáře na plný úvazek. Pokud je vývoj částečný, harmonogram se prodlouží. Každá etapa končí měřitelným rozhodnutím pokračovat / upravit / zastavit. ### Etapa 0 — Ověřit, za co zákazník zaplatí **Odhad:** 5 pracovních dnů **Výstup:** stručná produktová definice a seznam design partnerů. 1. Uskutečnit 10–12 rozhovorů s vývojáři a technickými vedoucími malých týmů; nejméně polovina respondentů musí mít přímý vliv na nákup nebo umět zapojit rozpočtového vlastníka. - Desk research z podobných rozhovorů a projektů je v [ANALOGOUS_INTERVIEW_RESEARCH_V5.md](docs/product/ANALOGOUS_INTERVIEW_RESEARCH_V5.md); pomáhá formulovat hypotézy, ale nepočítá se jako rozhovor ani důkaz ochoty platit. - Vzorek cílit na 4 lidi v ČR a 4–8 mimo ČR při stejném profilu respondenta. Produkt směřovat globálně; geografii odpovědí vyhodnocovat odděleně a nevyvozovat závěr o trhu z malého vzorku. 2. Zjistit, jaké coding agenty používají, jaké akce jim dovolují a co je přimělo hledat bezpečnější postup. 3. Ukázat konkrétní prototypový tok: akce → vysvětlení rizika → schválení → omezený běh → auditní záznam. 4. Ověřit instalační prostředí, potřebu lokálního modelu, síťová omezení a podmínky práce s neveřejným kódem. 5. Zjistit kupujícího, rozpočet, současné výdaje a nákupní proces. Vhodným respondentům předložit konkrétní placenou pilotní nabídku a zaznamenat cenu, rozsah, kupujícího a další krok. Testovací cenové hypotézy jsou v tržní analýze; nejsou veřejným ceníkem. **Pokračovat, pokud:** alespoň 5 respondentů nezávisle popíše tentýž nedávný problém, alespoň 3 nabídnou konkrétní pilotní task a technický kontakt a alespoň 2 přijmou placenou nabídku nebo zahájí skutečné interní schválení nákupu. Jinak změnit cílovou skupinu či slib produktu; nepřidávat funkce naslepo. ### Etapa 1 — Uzavřít výchozí stav a vydatelnou základnu **Odhad:** 3–5 pracovních dnů, část lze dělat souběžně s rozhovory. **Výstup:** reprodukovatelný vývojový základ a ověřený seznam existujících komponent. 1. Udělat inventuru staged, unstaged a untracked změn; změny nemažte ani nepřepisujte bez rozhodnutí vlastníka. 2. Rozdělit existující práci na: ponechat, opravit, odložit a archivovat. 3. Zvlášť ověřit nové SQLite implementace, persistentní queue, approval manager, audit log a privacy gateway. Nezdvojovat to, co už funguje. 4. Stanovit jednu podporovanou linuxovou distribuci/verzi a nutné Bubblewrap předpoklady podle rozhovorů. **Rozhodnuto 2. 10. 2026, čeká na implementaci:** podporovanou platformou je **Ubuntu 24.04 LTS** — viz [D1](docs/product/DECISIONS_LOG_V5.md#d1--podporovaný-os-ubuntu-2404-lts). Jde o rozhodnutí vlastníka učiněné **před** zákaznickými rozhovory, takže ho je nutné znovu potvrdit proti výsledkům discovery; uvolňuje práci na balení a CI, ale nepotvrzuje, že je to správná platforma pro první kupce. 5. Udělat čistý instalační postup, příkaz pro ověření kvality a CI pro podporovaný systém. Zdokumentovat i chování, když Bubblewrap není dostupný. 6. Aktualizovat `PROJECT_STATUS.md` pouze po ověření aktuálního pracovního stromu. **Splněno 2. 10. 2026:** pracovní strom byl ověřen a `PROJECT_STATUS.md` byl s ním srovnán. **Hotovo, pokud:** čistý checkout lze nainstalovat a ověřit podle dokumentace; vývojář umí rozeznat prototypové, ověřené a nepodporované části produktu. ### Etapa 2 — Dokončit jeden uživatelský scénář **Odhad:** 2–3 týdny **Výstup:** soukromý MVP pro první design partnery. #### P0 — Nutné pro pilot - Jeden jasný příkaz nebo flow k vytvoření a spuštění řízeného tasku. - Jeden první vstupní bod pro coding agenta. V Etapě 0 vybrat, zda bude nejrychlejší adaptér pro existujícího agenta, nebo první verze použije vlastní jednoduché CLI pro explicitní příkazy. Nepodporovat více integrací najednou. - Zobrazit konkrétní akci ke schválení: agent, příkaz/nástroj, pracovní adresář, dotčené oprávnění a informace o síťovém či modelovém přenosu. - Ověřit identitu a policy před každým podporovaným voláním nástroje; žádný agent nesmí volat backend sandboxu napřímo. - Zamítnout nebo vyžádat schválení podle policy. Zamítnutí, timeout, chybějící schvalovací infrastruktura i nedostupný sandbox musí skončit zavřením akce. **Rozhodnuto a implementováno 2. 10. 2026:** `cyberbrain run` je fail-closed přes `AuthorizedExecutionService` a `PtahBridge` nad reálnou `SQLiteDatabase`; žádný `--insecure-legacy` bypass — viz [D2](docs/product/DECISIONS_LOG_V5.md#d2--cyberbrain-run-bude-fail-closed). Důsledek: `cyberbrain run` přestal fungovat pro citlivé akce bez schválení, protože `ApprovalManager` je bez DB `None`. Doplněk: [D3](docs/product/DECISIONS_LOG_V5.md#d3--cyberbrain-runplan-nevolaj%C3%AD-model--odstran%C4%9Bny---model---lang) odebral `ModelGateway` a `--model`/`--lang` z CLI. - Spouštět pilotní úlohu v pracovním prostoru vyhrazeném pro danou úlohu. Pro změny projektu preferovat oddělený Git worktree a zobrazit `git diff` před převzetím změn do hlavního adresáře. - Zobrazit výstup, exit status, timeout a stav tasku; přerušení nesmí falešně hlásit úspěch. - Zapsat identitu, rozhodnutí policy, schválení, volání nástroje a výsledek do lokálního persistentního auditu. - Umožnit uživateli vypsat historii a zjistit, proč byla akce povolena, zamítnuta nebo vyžádala schválení. - ~~Ukazovat konkrétní model/provider.~~ **Vyřešeno D3:** `cyberbrain run`/`plan` jsou model-free — `--model`/`--lang` byly odstraněny, `ModelGateway` není volán z CLI. Latenty: knihovní `ModelGatewayConfig` (`default_provider="litellm"`, fallback na `ollama`/`llama.cpp`) zůstává jako riziko pro ne-CLI kanály (viz `docs/SECURITY_ONE_PAGER.md` §7). #### P1 — Až po funkčním P0 - Jednoduché nastavení policy v souboru s validací a bezpečným výchozím profilem. - Export auditní historie ve strukturovaném formátu. - Záloha/obnova lokální databáze a nastavitelná retence. - Přehledné chyby při instalaci a diagnostický příkaz bez zveřejnění secrets. - Týmovou správu, sdílené politiky a agregovaný přehled začít jen tehdy, když je požadují platící pilotní zákazníci. #### Nepatří do MVP Redis, distribuovaná fronta, víceuzlové nasazení, webový administrátorský portál, SSO, více uživatelů, obecný marketplace agentů, browser/GUI/MCP execution a desítky model providerů. **MVP demo:** uživatel vybere repozitář, zadá nebo předá úlohu prvnímu podporovanému agentovi, uvidí žádost o konkrétní oprávnění, povolí nebo odmítne ji, sleduje běh v izolovaném pracovním prostoru, zkontroluje diff a otevře auditní záznam. Při každém selhání se systém zastaví s jasnou příčinou. ### Etapa 3 — Zpevnit hranice a pravdivost produktu **Odhad:** 1–2 týdny, částečně souběžně s Etapou 2 **Výstup:** omezený, ale zdokumentovaný bezpečnostní baseline. 1. Stanovit explicitní threat model: kdo je útočník, jaké vstupy jsou nedůvěryhodné, co je mimo rozsah. 2. Pro pilot nepovolovat spuštění nepřátelského kódu vůči hostitelskému systému; používat taskové kopie/worktree, ne pracovní adresář jako neomezené důvěryhodné úložiště. 3. Rozhodnout, jak budou řešeny limity paměti, počtu procesů, CPU, disku a inodeů. Pokud je nelze v MVP spolehlivě zajistit, jasně omezit typ povoleného použití. 4. Ověřit cleanup potomků při timeoutu a zrušení, namespaces a chování na každé podporované host konfiguraci. 5. Spustit CI s Bubblewrap dostupným i chybějícím. Chybějící sandbox musí zůstat fail-closed. 6. Omezit oprávnění procesu, chránit lokální databázi a secrets, nastavit retention a dokumentovat zálohy. Nevydávat logy za kryptograficky neměnný audit, pokud nejsou chráněny proti přepsání vlastníkem hostu. 7. Připravit stručný bezpečnostní list: podporované konfigurace, známá omezení, data ukládaná lokálně, data předávaná modelovému providerovi a správce těchto dat. **Stop/go:** pokud MVP potřebuje garantovat ochranu před škodlivým kódem, víceuživatelskou izolaci nebo compliance, které současný sandbox nesplňuje, zastavit sliby o takovém použití a buď zúžit pilot, nebo přijmout izolovanější backend či odbornou bezpečnostní revizi. ### Etapa 4 — Placené piloty a produktové balení **Odhad:** 2–4 týdny po MVP; začít přípravou ještě během vývoje. **Výstup:** první placený pilot a rozhodnutí o veřejné betě. - Připravit balíček pro instalaci na podporovaném Linuxu, verzi, changelog, diagnostiku a postup obnovy. - Dodat quick start, vzor policy, ukázkový task, známá omezení a FAQ pro řešení běžných problémů. - Před pilotem uzavřít základní podmínky: licence, rozsah podpory, nakládání s daty, odpovědnost za lokální model/provider klíče a omezení bezpečnostních tvrzení. Konkrétní právní text nechat zkontrolovat podle zamýšleného prodeje. - Pilotovat u 2–3 design partnerů na jejich vlastním projektu; zaznamenat čas instalace, úspěšnost úlohy, četnost schválení, chybové stavy a skutečně ušetřený čas. - Nabídnout placený pilot nebo instalaci s podporou ručně. Měřit čas dodání a podpory, konverzi do roční smlouvy a opakovatelnost integrace; nečekat na platební automatizaci, samostatný portál nebo plně samoobslužný cloud. - Po každém pilotu uzavřít konkrétní feedback a rozhodnout, zda je další krok oprava produktu, úprava segmentu, nebo zastavení. **Kritéria pro otevřenou placenou betu:** - alespoň 2 zákazníci dokončili pilot a alespoň 1 zaplatil nebo písemně potvrdil nákup za konkrétních podmínek; - nový vývojář dokáže produkt nainstalovat podle návodu bez přímého zásahu autora; - žádný známý bypass policy v podporované cestě; chyby sandboxu se zavírají fail-closed; - uživatel rozumí, co se spouští, co odchází ke cloudovému providerovi a jak se změny přebírají do repozitáře; - bezpečnostní list, licence a hranice podpory jsou připravené. ### Etapa 5 — Rozšířit jen podle placené poptávky Další investice vybírat podle ztracených obchodů a opakujících se potřeb pilotních zákazníků: - macOS/Windows, pokud je požadují potvrzení zákazníci a existuje odpovídající bezpečný backend; - integrace dalšího coding agenta, až první adaptér bude stabilní a partner ji skutečně potřebuje; - týmové sdílení politik a centrální audit, až zákazník potřebuje více uživatelů a je připraven platit za správu; - Podman/container/microVM backend, pokud bezpečnostní nebo provozní model překračuje limity lokálního Bubblewrap; - dlouhodobé workflow, scheduler a distribuovaná orchestrace až na základě konkrétního placeného případu; - governance/compliance funkce po vymezení konkrétní jurisdikce, klasifikace systému a zákaznických požadavků. --- ## 4. Architektonická pravidla V5 1. **Rozhraní zachovat, implementace omezit.** Provider kontrakty pomáhají vyměnit backend, ale nebudeme stavět implementaci každé varianty před poptávkou. 2. **SQLite nejprve.** Pro jednouživatelský lokální produkt nejdřív ověřit existující SQLite persistence. Distribuovanou databázi přidat až pro prokázaný víceuživatelský scénář. 3. **Jeden orchestration path.** Ponechat existující Ptah/Python základ, dokud zákaznické testy neukážou, že orchestrace brání produktu. 4. **Policy před každou akcí.** Model, plánovač ani agentní prompt nejsou bezpečnostní autoritou. Každé podporované volání nástroje musí projít deterministickou autorizací. 5. **Schvalovat přesný rozsah.** Schválení musí být svázané s konkrétní akcí, argumenty, pracovním adresářem a taskem; změna těchto údajů vyžaduje nové posouzení. 6. **Žádné tiché přechody.** Nedostupný model ani sandbox nesmějí vyvolat méně bezpečný režim, nový provider nebo spuštění na hostu bez vědomí uživatele. 7. **Měřit důkazy, ne počet rovin.** Každý release má instalační, funkční a bezpečnostní kritéria; počet modulů ani agentů není metrika produktového pokroku. --- ## 5. Konkurenční pozice Následující mapování slouží pro rozhodnutí, co nestavět znovu. Funkce se mění; před veřejným vydáním je znovu ověřit. | Oblast | Existující alternativy | Důsledek pro V5 | |---|---|---| | Agentní orchestrace, nástroje, guardrails, tracing a lidské schválení | [OpenAI Agents SDK](https://openai.github.io/openai-agents-python/), [Microsoft Agent Framework](https://learn.microsoft.com/en-us/agent-framework), [LangGraph](https://langchain-ai.github.io/langgraph/) | Nestavět obecný framework znovu. Přidaná hodnota V5 musí být kontrola konkrétní exekuce na uživatelově systému. | | Vestavěná lokální oprávnění a sandbox coding agentů | [Cursor](https://prod.cursor.com/docs/agent/security/run-modes), [Claude Code](https://code.claude.com/docs/en/security), [VS Code](https://code.visualstudio.com/docs/agents/concepts/trust-and-safety), [Codex CLI](https://learn.chatgpt.com/docs/codex/cli) | Přímá konkurence. Schvalování, omezení práce se soubory, izolace příkazů a kontrola diffu už jsou v některých produktech zabudované. V5 nesmí prodávat samotný součet těchto funkcí; musí ověřit potřebu nezávislé, lokální kontroly a auditu přes používané agenty. | | Coding agenti a práce s workspace | [OpenHands SDK/Agent Server](https://github.com/OpenHands/docs/blob/main/sdk/arch/agent-server.mdx) | Neprodávat „dalšího agenta“. Ověřit jednu užitečnou integraci a zaměřit ji na oprávnění, schválení, izolaci a místní audit. | | Izolovaná prostředí pro agentní kód | [Daytona](https://www.daytona.io/docs/en/isolation), [E2B](https://e2b.dev/) | Nepokoušet se v první verzi konkurovat jejich cloudové microVM infrastruktuře. Začít místním jedno-uživatelským use-case; silnější izolaci koupit, integrovat nebo vyvinout až s obchodním důvodem. | | Guardrails pro interakci LLM | [NVIDIA NeMo Guardrails](https://docs.nvidia.com/nemo/guardrails/latest/index.html) | Odlišit obsahové/dialogové guardrails od deterministického povolení procesu, workspace a nástroje. Nezaměňovat filtrování textu za sandbox. | **Hypotéza odlišení k ověření:** jednotná lokální autorizace akcí a audit napříč existujícími coding agenty na podporovaném Linuxu. Cursor, Claude Code, VS Code a Codex už pokrývají části tohoto toku nativně; samotné schvalovací okno, sandbox nebo auditní záznam proto nejsou unikátní. V5 musí doložit, že zákazník potřebuje další vrstvu mimo své stávající prostředí a že ji nainstaluje bez narušení workflow. --- ## 6. Metriky produktu a obchodu Sledovat nejméně tyto metriky od prvního pilotu: - **Čas do prvního úspěchu:** od čisté instalace k bezpečně dokončené úloze. - **Úspěšnost instalace bez pomoci:** podíl testerů, kteří postup dokončí podle návodu. - **Dokončení úloh:** podíl podporovaných úloh dokončených bez ruční opravy produktu. - **Srozumitelnost schválení:** uživatel umí vysvětlit, jakou akci povolil a s jakými dopady. - **Bezpečnostní regresní nálezy:** počet obejití policy, nespolehlivého fallbacku nebo nedostatečně auditovaných akcí; cíl je nula známých případů v podporované cestě. - **Použitelnost:** kolik času produkt ušetřil či kolik rizikové práce uživatel odmítl agentovi svěřit. - **Konverze:** rozhovory → design partneři → placené piloty → opakované použití. - **Náklady na podporu:** čas potřebný k instalaci a řešení jednoho zákazníka. Na začátku neoptimalizovat počet stažení, počet agentních rolí ani počet podporovaných providerů. --- ## 7. Rozhodovací brány | Brána | Rozhodnutí | |---|---| | Po Etapě 0 | Potvrdil trh problém a existují design partneři? Pokud ne, změnit segment nebo produktový slib. | | Po Etapě 1 | Je z čisté základny opakovatelný build a je jasné, které části pracovního stromu patří do produktu? Pokud ne, neotevírat další větev roadmapy. | | Po Etapě 2 | Dokáže nový uživatel dokončit bezpečný scénář bez zásahu autora? Pokud ne, zúžit integraci a odstranit tření. | | Po Etapě 3 | Je bezpečnostní tvrzení přesně omezené na ověřené prostředí a zátěž? Pokud ne, bezpečnostní použití nepovolovat. | | Po Etapě 4 | Zaplatil zákazník a používá produkt opakovaně? Pokud ne, nezahajovat enterprise platformu; opravit nabídku nebo změnit segment. | --- ## 8. První akční sprint Na začátku V5 udělat v tomto pořadí: 1. Zachovat současný pracovní strom a sepsat jeho inventuru; nic bez rozmyslu nezahazovat ani nepřepisovat. 2. Připravit jednostránkový popis cílového uživatele, problému, produktového slibu a omezení. 3. Dokončit desk research [podobných rozhovorů a produktů](docs/product/ANALOGOUS_INTERVIEW_RESEARCH_V5.md); poté získat 8–12 vlastních zákaznických rozhovorů a oslovit první kandidáty na pilot. Veřejné studie ani cizí case studies nepočítat do discovery gate. 4. Ověřit aktuální status nových SQLite a privacy změn oproti `PROJECT_STATUS.md`. 5. Zvolit jediný podporovaný OS, jediný první agentní vstup a jediný demo scénář podle rozhovorů. 6. Teprve potom sestavit 2–3týdenní implementační backlog pro MVP. ### Okamžitě nevykonávat - neimplementovat všechny etapy najednou; - nepřidávat další agentní role bez konkrétního use-case; - nepřepisovat architekturu kvůli hypotetickému budoucímu škálování; - neprodávat „secure AI operating system“, „neprůstřelný sandbox“ ani compliance shodu; - nevytvářet vlastní microVM infrastrukturu před potvrzením placené potřeby; - nezveřejňovat veřejný produkt, dokud nejsou vyřešeny licence, podporované systémy a přenos dat k modelům. --- ## 9. Zdroje konkurenčního srovnání - OpenAI Agents SDK: https://openai.github.io/openai-agents-python/ - Microsoft Agent Framework: https://learn.microsoft.com/en-us/agent-framework - LangGraph persistence: https://langchain-ai.github.io/langgraphjs/how-tos/cross-thread-persistence-functional/ - CrewAI produkční architektura: https://github.com/crewAIInc/crewAI/blob/main/docs/v1.15.0/en/concepts/production-architecture.mdx - OpenHands Agent Server: https://github.com/OpenHands/docs/blob/main/sdk/arch/agent-server.mdx - Daytona izolace: https://www.daytona.io/docs/en/isolation - E2B: https://e2b.dev/ - NVIDIA NeMo Guardrails: https://docs.nvidia.com/nemo/guardrails/latest/index.html - Cursor Agent Security / Run Modes: https://prod.cursor.com/docs/agent/security/run-modes - Claude Code Security: https://code.claude.com/docs/en/security - VS Code agent trust and safety: https://code.visualstudio.com/docs/agents/concepts/trust-and-safety - Codex CLI: https://learn.chatgpt.com/docs/codex/cli - Tržní analýza a cenové hypotézy V5: [MARKET_AND_MONETIZATION_ANALYSIS_V5.md](docs/product/MARKET_AND_MONETIZATION_ANALYSIS_V5.md) - Záznam produktových rozhodnutí (D1 podporovaný OS, D2 fail-closed `cyberbrain run`, D3 model-free CLI): [DECISIONS_LOG_V5.md](docs/product/DECISIONS_LOG_V5.md) - Bezpečnostní list kódu: [SECURITY_ONE_PAGER.md](docs/SECURITY_ONE_PAGER.md) - Desk research rozhovorů a case studies: [ANALOGOUS_INTERVIEW_RESEARCH_V5.md](docs/product/ANALOGOUS_INTERVIEW_RESEARCH_V5.md)