# CyberBrain26 — MASTER ROADMAP v4.1 **Status:** MASTER BASELINE / canonical foundation **Version:** 4.1 **Project:** CyberBrain26 **Purpose:** definitive technical, architectural, security, privacy, governance and product baseline --- ## 0. STATUS A TREATMENT STARÉHO PROJEKTU CyberBrain26 v4.1 je nový kanonický základ projektu. Tato verze rozšiřuje v4.0 o ověřené architektonické extension points a bezpečnostní/governance mechanismy. V4.0 zůstává zachována jako předchozí baseline. Tato verze supersedes předchozí roadmapy včetně v3.x, ale zachovává všechny relevantní požadavky a nápady. Staré BETA/NEXT/LAB prostředí se nemažou naslepo. Nejprve se provedou audit, inventura a klasifikace: - KEEP — zachovat - REFACTOR — přepracovat - REWRITE — napsat znovu - ARCHIVE — archivovat - DROP — vyřadit po ověření **Zásadní pravidlo:** před Phase 4 — Modular Architecture — se nesmí bezhlavě pokračovat ve staré implementaci. Nejprve musí vzniknout čistý, ověřený baseline odpovídající této roadmapě. --- # 1. VIZE CyberBrain26 je vendor-neutral, local-first, security-first AI operating environment pro jednotlivce i firmy. Má spojovat: - multi-agent AI - lokální i cloudové modely - AI orchestration - cybersecurity - OSINT - Deep Research - coding a Vibe Coding - computer use - automatizaci - znalostní databázi a Notebook workspace - multimodalitu - osobní workflow - enterprise integrace - privacy - AI security - AI governance a compliance Systém má škálovat od osobního Linux desktopu až po self-hosted/private-cloud/enterprise nasazení bez nutnosti přepsat základní architekturu. --- # 2. ZÁKLADNÍ PRINCIPY ## 2.1 Local-first Lokální výpočet a lokální data jsou preferovaná varianta. ## 2.2 Zero-cost base Základní funkcionalita musí být použitelná bez placených API. Externí free/freemium API jsou rozšíření, nikoli jediný základ systému. Nelze garantovat, že konkrétní poskytovatel zůstane navždy zdarma. ## 2.3 Security-first Bezpečnost není doplněk. Je součástí architektury každého agenta, nástroje, datového toku a automatizace. ## 2.4 Zero-trust Žádný agent, model, tool, MCP server, dokument ani externí runtime není automaticky důvěryhodný. ## 2.5 Vendor neutrality CyberBrain26 nesmí být uzamčený na jeden model, providera, framework nebo agent runtime. ## 2.6 Privacy-preserving Systém má minimalizovat sběr, přenos a uchovávání dat. ## 2.7 Auditability Citlivé akce musí být dohledatelné, vyhodnotitelné a zpětně auditovatelné. ## 2.8 Human oversight Autonomie nesmí obejít bezpečnostní a schvalovací mechanismy. ## 2.9 Agentic AI + Edge/Local-First Hybrid CyberBrain26 je navržen jako agentic platforma, která preferuje lokální/edge výpočet, ale umí bezpečně využít externí cloud pouze tehdy, když to dovolí policy, privacy a resource routing. ## 2.10 Controlled Autonomy + Deterministic Oversight Autonomie je povolena pouze uvnitř deterministicky vymahatelných hranic Identity → Policy → Permissions → Security → Evaluation → Audit → Governance. LLM nesmí být jediným bezpečnostním rozhodovacím bodem. ## 2.11 Ethical AI by Design Governance vrstva musí umožnit mapování AI systémů na relevantní právní a dobrovolné rámce, zejména EU AI Act, NIST AI RMF a ISO/IEC 42001. Výchozí návrh preferuje human oversight u rizikových akcí. ## 2.12 Flexible Cost Model Zero-cost base zůstává výchozí. Architektura ale musí umožnit volitelné pay-per-use cloudové služby přes oddělený provider/credential layer. Případné kredity musí být scoped, odvolatelné, auditovatelné a pokud možno pseudonymizované. ## 2.13 Extension-Point First Budoucí technologie se nesmí stát tvrdou závislostí jádra. Protokoly, identity, sandboxy, retrieval strategie, provenance mechanismy a externí runtimes se integrují přes stabilní interface → adapter → provider vrstvy. --- # 3. PRODUKTOVÉ REŽIMY CyberBrain26 bude mít minimálně tyto režimy: - PERSONAL - DEVELOPER - RESEARCH - SECURITY - LAB - ENTERPRISE - SOVEREIGN / EDGE - COMPLIANCE SOVEREIGN / EDGE zakazuje neautorizovaný outbound cloud traffic a preferuje lokální modely, data a execution backends. COMPLIANCE aktivuje regulatorní mapping, evidence, auditní výstupy a příslušné transparency controls. Každý režim může mít jiné limity, modely, nástroje, síťové politiky, retention a approval rules. --- # 4. HLAVNÍ ARCHITEKTURA CyberBrain26 se skládá z hlavních rovin: 1. Control Plane 2. Execution Plane 3. Data Plane 4. Security Plane 5. Governance & Compliance Plane 6. Experience Layer 7. Experience Layer 8. Personal AI Layer 9. Integration / Protocol Layer 10. Extension / Adapter Layer FastAPI je framework Control Plane/API vrstvy. **FastAPI není celá architektura.** --- # 5. CONTROL PLANE ## Účel Řídí systém, API, workflow, eventy, registries, policy koordinaci a administraci. ## Komponenty - FastAPI - API Gateway - Event Bus - Task Queue - Workflow Engine - Agent Registry - Model Registry - Tool Registry - Provider Registry - Policy coordination - configuration management - administration - health/status endpoints - scheduler ## API Primárně REST + SSE. WebSocket pouze tam, kde má skutečný přínos. ## Event-driven backbone Control Plane musí podporovat event-driven komunikaci. Konkrétní backend (např. NATS nebo Redis Streams) je vyměnitelný přes Event Bus interface. Standardizované telemetry hooks používají OpenTelemetry tam, kde je to bezpečné a privacy policy dovolí. ## State persistence Workflow/agent tasks musí mít checkpointing a recovery mechanismus. Konkrétní implementace (např. LangGraph persistence) nesmí být jediným veřejným datovým kontraktem. --- # 6. EXECUTION PLANE Execution Plane provádí skutečné akce. Podporované execution capabilities: - Python - Shell / Terminal - Browser - Git - Docker / Podman - MCP - Open Interpreter - OpenClaw - PyAutoGUI - xdotool - browser automation - file operations - controlled computer use Každý execution mechanismus musí být podřízen: **Identity → Policy → Permission → Sandbox → Audit** ## Execution Provider abstraction Execution Plane používá abstraktní `ExecutionProvider` / sandbox contract. Backend může být lokální proces, Podman, Docker, Firecracker microVM, Kata/gVisor nebo jiný ověřený backend. Podman Quadlet je lifecycle/deployment mechanismus, nikoli alternativa k microVM. Firecracker je microVM isolation backend. NanoClaw je volitelný agent/container runtime pattern a nesmí být zaměňován s microVM hypervisorem. Neověřený kód má podle rizika dostat disposable filesystem, omezené credentials, omezený network egress a časový/resource limit. --- # 7. EXTERNÍ AGENT RUNTIMES ## 7.1 OpenClaw OpenClaw je externí agent runtime / companion agent. Použití: - dlouho běžící osobní agent - messaging - zařízení a nodes - background automation - osobní workflow - delegované úkoly OpenClaw nesmí být tvrdou závislostí CyberBrain26. Všechny citlivé akce musí respektovat CyberBrain26 policy model, pokud jsou prováděny v jeho řízeném workflow. ## 7.2 Open Interpreter Open Interpreter je externí computer-execution / coding runtime. Použití: - terminal - Python - soubory - browser - GUI automation - coding - testing - MCP - controlled computer use Musí být umístěn za: - Policy Engine - Permission Gateway - Sandbox - Audit - Resource limits --- # 8. DATA PLANE Data Plane spravuje data, paměť a znalosti. ## Základ - filesystem - SQLite - ChromaDB - embeddings - conversation history - project memory - Notebook workspace - Knowledge Base - research data - LM Cache - metadata - evidence store ## Organizace Data musí být organizována podle: - user - project - workspace - task - source - trust level - sensitivity - retention policy --- # 9. NOTEBOOK / KNOWLEDGE WORKSPACE Notebook-like pracovní prostor inspirovaný moderními knowledge tools. Podpora zdrojů: - PDF - dokumenty - text - web pages - images - audio - video - code - URLs - conversations - notes - generated reports Funkce: - source ingestion - indexing - semantic search - summaries - citations - source comparison - Q&A - project folders - provenance - trust labels - knowledge graph podle potřeby AI-generated informace se nesmí automaticky považovat za fakt. --- # 10. SECURITY PLANE Security Plane je kritická vrstva systému. Obsahuje: - Identity - Agent Identity - RBAC - ABAC - Policy Engine - Permission Gateway - Approval Manager - AI Firewall - Secrets Manager - Credential Broker - Sandbox - Network Control - Audit - Security Monitoring - security alerts - resource controls --- # 11. AGENT IDENTITY Každý agent musí mít vlastní identitu. Identita umožňuje: - jednoznačně určit agenta - určit jeho roli - určit povolené nástroje - určit scope přístupu - auditovat jeho akce - řídit downstream credentials - odlišit agenty od uživatele Agent nesmí automaticky zdědit všechna oprávnění uživatele. --- # 12. RBAC + ABAC ## RBAC Role-based access control. ## ABAC Attribute-based access control. Politiky mohou záviset například na: - user - agent - task - environment - resource - data sensitivity - time - network - risk score - mode --- # 13. POLICY ENGINE Základní princip: **DEFAULT DENY** Nic citlivého není povoleno jen proto, že to agent chce. ## Režimy ### SAFE - žádná riziková automatická exekuce - citlivé operace vyžadují approval - omezené nástroje ### FULL - vyšší automatizace - read-only operace mohou být automatické - rizikové write/execute akce vyžadují kontrolu podle policy - sandbox + audit zůstává aktivní ### RESEARCH - experimentální modely - detailní logging - sandbox - omezená síť ### RED TEAM LAB - izolované testovací prostředí - testovací data - syntetické credentials - žádné produkční credentials - omezený network - izolovaný filesystem --- # 14. PERMISSION MODEL Standardní capability categories: - READ_FILE - WRITE_FILE - DELETE_FILE - NETWORK - BROWSER - SHELL - PYTHON - GIT - DOCKER - SECRETS Agent musí získat konkrétní permission podle policy. Žádný agent nedostává unrestricted access automaticky. --- # 15. APPROVAL MANAGER Citlivé akce mohou vyžadovat explicitní lidské schválení. Příklady: - delete - destructive shell - credential access - external data upload - production changes - sending external messages - publishing content - financial/administrative actions - high-risk security actions Approval musí být auditovatelný. --- # 16. CREDENTIAL BROKER Credential Broker vydává krátkodobé a omezené credentials. Principy: - short-lived - least privilege - scoped - revocable - auditable - task-specific - agent-specific Agent nemá dostávat dlouhodobý master credential, pokud to není nezbytné. --- # 17. SECRETS MANAGEMENT Požadavky: - encryption at rest - encryption in transit - rotation - expiration - revocation - access policy - secret scope - audit - masking - prevention of accidental model exposure Secrets se nesmí bez důvodu dostávat do promptů, logs, memory nebo externích providerů. --- # 18. AI FIREWALL AI Firewall kontroluje AI-specific threats. Musí umět detekovat a/nebo blokovat podle policy: - prompt injection - indirect prompt injection - tool poisoning - MCP poisoning - malicious documents - malicious URLs - data exfiltration - credential access - excessive agency - agent hijacking - suspicious agent-to-agent communication - memory poisoning - unsafe tool calls - suspicious outputs AI Firewall může kontrolovat: **INPUT → MODEL → OUTPUT → TOOL CALL → TOOL RESULT → MEMORY WRITE → EXTERNAL EGRESS** --- # 19. PRIVACY ARCHITECTURE Cíl: privacy-preserving, nikoli „magická anonymita“. Principy: - local-first - telemetry OFF by default where possible - data minimization - metadata minimization - EXIF stripping - document metadata stripping - pseudonymous IDs - encryption - configurable retention - data residency - network egress control - provider privacy controls - local-only mode --- # 20. PRIVACY GATEWAY Před odesláním dat externím providerům může Privacy Gateway provést: 1. classification 2. PII detection 3. sensitive-data detection 4. redaction 5. pseudonymization 6. policy check 7. provider selection 8. user approval podle risku Příklad: **Local data → Privacy Gateway → policy → sanitized payload → external provider** --- # 21. ANTI-FORENSICS HRANICE CyberBrain26 nesmí obsahovat funkce určené k: - falsifikaci auditních záznamů - manipulaci důkazů - skrytí legitimních logů - úmyslnému zamlžování identity při škodlivém jednání - ničení forenzních stop za účelem zakrytí útoku Místo toho Security Lab používá legitimní ephemeral isolation: - disposable VMs - containers - microVMs - snapshots - isolated networks - synthetic credentials - synthetic data - controlled reset - controlled destroy - oddělený evidence store Cílem je bezpečný experiment, ne falsifikace reality. --- # 22. TENANT ISOLATION Enterprise varianta musí podporovat izolaci tenantů. Oddělovat se musí minimálně: - users - agents - credentials - data - memory - files - logs - models/configuration - policies - audit scope --- # 23. MODEL LAYER Model Layer musí být vendor-neutral. Technologie: - LiteLLM - Ollama - llama.cpp - local models - external APIs - model router - model registry - provider registry Model není bezpečnostní hranice. --- # 24. MODEL INTELLIGENCE / MODELS HARVESTER Původní API Harvester je přejmenován na **Models Harvester / Model Intelligence**. ## Kategorie - FREE - NEW - FREE FOR TEST - FREE FOR STUDY ## Infobox modelu - provider - model ID - version - family - type - context - capabilities - vision - tool/function calling - structured output - reasoning - coding - multimodal - local availability - API availability - license - commercial use - free status - registration required - card required - rate limits - token limits - discovered - last checked - status - source - trust - environment - test status - safety profile - resource requirements ## Trust - OFFICIAL - VERIFIED - COMMUNITY - UNOFFICIAL - UNKNOWN ## Status - ACTIVE - HIDDEN - FAILED - DEPRECATED - UNKNOWN Nefunkční modely se primárně skrývají, nikoli bez evidence mažou. --- # 25. MODEL VALIDATION PIPELINE **DISCOVERY → NORMALIZATION → DEDUPLICATION → METADATA VALIDATION → CONNECTIVITY TEST → FUNCTIONAL TEST → CLASSIFICATION → REGISTRY UPDATE** Harvester má primárně sbírat a validovat metadata. Nemá automaticky stahovat obrovské modely bez důvodu. Doporučený interval základního harvestu: přibližně 24 hodin, s možností ručního spuštění. --- # 26. PROVIDER REGISTRY Provider Registry obsahuje: - provider - status - free tier - registration - card requirement - API - available models - rate limits - token limits - conditions - expiration - last checked - source - trust Volitelné Free Score může hodnotit: - free - no-card - no-expiration - API availability - limit size - stability - official source - local availability Penalizace: - card required - trial only - low limits - academic-only - unofficial source - unstable service --- # 27. AGENT LAYER Základní role: - Planner - Supervisor - Router - Evaluator - Coder Agent - Cybersecurity Agent - OSINT Agent - Research Agent - Browser Agent - Computer Use Agent - Content Agent - Knowledge Agent - Compliance Agent - Security Testing Agent Agenti musí být modulární a replaceable. --- # 28. ORCHESTRATION LangGraph je orchestration layer, nikoli celý CyberBrain26. Orchestration musí být oddělena od: - model gateway - execution - policy - identity - memory - governance ## Agent Orchestration Fabric Nad LangGraph vzniká vendor-neutral orchestration abstraction pro: - Agent Pool - Team Builder - task decomposition - agent selection - delegation - checkpointing - evaluation - human approval LangGraph je jeden možný backend orchestrace, nikoli veřejný kontrakt celého systému. ## A2A extension point CyberBrain26 musí mít připravený `AgentTransport` / `AgentProtocolProvider`, do kterého lze později přidat A2A. A2A 1.0.0 je standardizovaný externí agent-to-agent protokol s Agent Cards a discovery mechanismem; jeho bezpečnost musí jít přes A2A Gateway + Identity + Policy. A2A není povinný interní transport každého agenta. Tím se zabrání framework lock-inu. --- # 29. MCP SECURITY MCP servery jsou potenciálně nedůvěryhodné komponenty. MCP musí podléhat: - registry - trust classification - permission model - tool schema validation - policy checks - network restrictions - audit - output validation - version tracking Neznámý MCP server nesmí automaticky získat plný přístup. ## MCP Security Gateway MCP komunikace musí procházet gateway vrstvou s: - per-request agent identity - server/tool trust classification - schema validation - tool description/input inspection - policy enforcement - credential scoping - network restrictions - output validation - audit/evidence - version compatibility CyberBrain26 cílí na MCP 2026-07-28 jako aktuální ověřenou baseline, ale MCP SDK/protocol details musí být zapouzdřeny v adapteru, aby budoucí specifikační změny nevyžadovaly přepis core. ## MCP protocol compatibility MCP adapter musí oddělit interní Tool Contract od MCP wire protocolu. To umožní podporovat více MCP verzí během přechodných období bez rozbití interních tool interfaces. --- # 30. MEMORY ARCHITECTURE Paměť musí rozlišovat minimálně: - trusted - verified - untrusted - suspicious - generated - inferred - user-confirmed AI-generated/inferred obsah nesmí být automaticky uložen jako fakt. Memory writes musí být podle rizika kontrolované. ## Tiered Memory Paměť se dále dělí na: - Working Memory - Episodic Memory (JSONL/SQLite) - Semantic Memory (vector store + volitelný Knowledge Graph) ## Memory Verification Gate Zápisy do důvěryhodné/sémantické paměti musí nést provenance metadata, minimálně source, timestamp, agent identity, confidence/trust state a případně human confirmation. Rizikové zápisy procházejí Verification Gate. Memory architecture nesmí předpokládat jeden retrieval mechanismus. --- # 31. RETRIEVAL ARCHITECTURE Retrieval je provider-based a nesmí být zamčený na jednu technologii. Podporované strategie mohou zahrnovat: - vector retrieval - keyword / BM25 - metadata / SQL retrieval - graph retrieval - GraphRAG - hybrid retrieval - agentic retrieval GraphRAG je další retrieval strategy, nikoli náhrada klasického RAG. Router může kombinovat více strategií podle typu úkolu. Pozdější přidání Knowledge Graph/GraphRAG proto nesmí vyžadovat změnu Memory API. ## Contradiction Detection Knowledge layer má mít extension point pro detekci konfliktů mezi tvrzeními a jejich provenance. --- # 30A. RETRIEVAL ARCHITECTURE Retrieval je provider-based a nesmí být zamčený na jednu technologii. Podporované strategie mohou zahrnovat: - vector retrieval - keyword / BM25 - metadata / SQL retrieval - graph retrieval - GraphRAG - hybrid retrieval - agentic retrieval GraphRAG je další retrieval strategy, nikoli náhrada klasického RAG. Router může kombinovat více strategií podle typu úkolu. Pozdější přidání Knowledge Graph/GraphRAG proto nesmí vyžadovat změnu Memory API. ## Contradiction Detection Knowledge layer má mít extension point pro detekci konfliktů mezi tvrzeními a jejich provenance. # 31. PROMPTMASTER PromptMaster je vrstva mezi uživatelem a AI workflow. Funkce: - intent understanding - cleanup - structuring - optimization - context enrichment - English translation where useful - policy check - model routing - task decomposition - prompt testing Režimy: - AUTO - SUGGEST - RAW - EXPERT PromptMaster nesmí měnit význam uživatelského požadavku bez transparentnosti. --- # 32. DEEP RESEARCH ENGINE Workflow: **QUESTION → PLAN → SOURCE DISCOVERY → SOURCE VALIDATION → EXTRACTION → CROSS-CHECK → SYNTHESIS → CITATIONS → UNCERTAINTY → REPORT** Musí podporovat: - web - local files - Notebook sources - structured research - source trust - contradictions - provenance - citations - reusable research artifacts --- # 33. OSINT ENGINE OSINT komponenta pro legitimní research: - search - public records - domains - DNS - certificates - metadata - social/public sources - entity resolution - timeline building - correlation - evidence handling Výsledky musí mít provenance a confidence. --- # 34. DARK WEB OSINT / DEEPSEARCH Podpora pouze pro legitimní bezpečnostní výzkum, threat intelligence a authorized investigations. Musí mít: - isolated environment - strict network policy - source provenance - evidence preservation - malware/content isolation - credential protection - no automatic trust --- # 35. SECURITY LAB Security Lab má být plnohodnotné izolované testovací prostředí. ## Technologie - Kali Linux - Docker / Podman - disposable VMs - microVMs - snapshots - isolated networks - test targets - vulnerable applications - controlled credentials - synthetic data ## Testovací oblasti - web security - API security - network security - mobile security - Linux security - container security - cloud/security concepts - AI security - agent security - MCP security - prompt injection - jailbreak testing - indirect injection - excessive agency - rogue agents - memory poisoning - data exfiltration - credential exposure - privilege escalation - malware analysis sandbox --- # 36. EPHEMERAL SECURITY LAB Lab instance má být možné vytvořit jako disposable environment. Lifecycle: **CREATE → SNAPSHOT → TEST → OBSERVE → EVALUATE → EXPORT EVIDENCE → RESET/DESTROY** Produkční credentials a produkční filesystem nejsou součástí labu. --- # 37. FORENSICS / EVIDENCE LAYER Evidence Layer slouží pro legitimní audit a autorizované testování. Ukládá podle policy: - event logs - tool calls - screenshots - command results - test artifacts - hashes - timestamps - environment information - findings - evidence relationships Evidence musí být oddělena od experimentálního prostředí, pokud je to potřeba. --- # 38. ATTACK SIMULATION ENGINE Defenzivní simulation engine: **SCENARIO → ATTACK GENERATION → TARGET → DEFENSE → OBSERVATION → EVALUATION → SCORE → REPORT** Testuje například: - prompt injection - indirect injection - tool poisoning - MCP poisoning - rogue agents - excessive agency - memory poisoning - credential exposure - data exfiltration - privilege escalation Výstup: - security score - findings - severity - reproduction metadata - mitigation - regression test --- # 39. AI GOVERNANCE & COMPLIANCE CyberBrain26 má obsahovat Governance & Compliance Plane. ## Registry - AI System Registry - Model Registry - Provider Registry - Tool Registry - Agent Registry ## Governance - AI Risk Classification - Model/System Cards - Human Oversight - Transparency - Incident Management - Evidence Store - Compliance Reports - Regulatory Monitoring --- # 40. COMPLIANCE ENGINE Počítá se minimálně s mapováním na: - EU AI Act - NIST AI RMF - NIST Generative AI Profile - ISO/IEC 42001 Architektura musí být připravena na budoucí frameworky a zákaznické compliance požadavky. Compliance engine nemá být jen checklist. Musí pracovat s: - AI inventory - risk classification - controls - evidence - owners - review dates - incidents - residual risk - reports --- # 41. AI RISK CLASSIFICATION Každý AI systém / agent / workflow má mít risk classification. Hodnocené faktory mohou zahrnovat: - autonomy - data sensitivity - external communication - tool permissions - credential access - decision impact - environment - model risk - user population - regulatory context Vyšší risk znamená přísnější policy, approval, monitoring a evidence. --- # 42. AI CONTENT PROVENANCE & TRANSPARENCY CyberBrain26 nebude mít univerzální povinný watermark. Místo toho bude existovat provider-based transparency layer, která podle typu obsahu, užití a policy může použít: - machine-readable marking - provenance metadata - C2PA nebo jiný podporovaný provenance mechanismus - visible AI labeling - watermarking, pokud je vhodný - human-review state Regulatory policy musí být oddělena od konkrétní implementace označování. Article 50 EU AI Act je implementován jako policy/compliance mapping, nikoli jako hard-coded watermarking. # 42. MODEL / SYSTEM CARDS Pro důležité modely a AI systémy mají být dostupné strukturované karty. Obsah: - purpose - owner - version - capabilities - limitations - data classes - permissions - known risks - safety profile - test status - compliance status - dependencies - deployment environments - last review --- # 43. HUMAN OVERSIGHT Systém musí umožnit: - approval - rejection - pause - cancel - escalation - manual takeover - review Autonomie není absolutní cíl. Cílem je **controlled autonomy**. --- # 44. AUDIT & OBSERVABILITY Audit musí sledovat minimálně: - user - agent - task - model - tool - action - policy decision - approval - result - error - resource usage - latency - network action - memory write - security alert Event Bus standardizuje mimo jiné: - MODEL_DISCOVERED - MODEL_VALIDATED - MODEL_FAILED - TASK_CREATED - TASK_STARTED - TASK_FINISHED - AGENT_STARTED - AGENT_FINISHED - TOOL_CALLED - APPROVAL_REQUIRED - SECURITY_ALERT - RESOURCE_LIMIT - MEMORY_UPDATED --- # 45. EVALUATION ENGINE Každý důležitý agent/workflow má být vyhodnocován. Metriky: - correctness - reliability - security - tool usage - hallucination - efficiency - latency - resource consumption - policy compliance - regression Evaluation může být: - unit - integration - scenario - adversarial - benchmark - regression - human review --- # 46. RESOURCE MANAGER Resource Manager sleduje: - CPU - RAM - GPU - VRAM - disk - active models - active agents - active tasks Při nedostatku zdrojů může: - přepnout na menší model - použít free external API podle policy - throttlovat tasky - odložit background práci - zastavit experimentální workload Příklad profilů: - LOW: ~2 CPU / 4 GB RAM - NORMAL: ~4 CPU / 8 GB RAM - LAB: ~6–8 CPU / 12–16+ GB RAM Hodnoty jsou orientační a musí se přizpůsobit host systému. --- ## Model/HW optimization extension points Resource Manager musí mít připravené profily pro: - MoE models - quantization (včetně 4-bit) - speculative decoding - CPU/GPU/NPU capability detection - latency/TPS benchmarking - local-vs-cloud routing podle policy a citlivosti dat Cloud fallback je povolen pouze pro data, která projdou Privacy/Egress policy. # 47. TASK QUEUE Task Queue řeší: - background tasks - scheduled jobs - model harvesting - validation - research jobs - agent tasks - periodic maintenance --- # 48. LM CACHE LM Cache snižuje: - náklady - latency - opakované inference - zbytečné API calls Cache musí respektovat: - sensitivity - tenant isolation - retention - privacy - model/version compatibility --- # 49. COMPUTER USE LAYER Podpora: - screenshots - screen analysis - browser control - PyAutoGUI - xdotool - GUI automation - controlled desktop interaction - video/screen analysis Computer Use musí být bezpečnostně oddělené od běžného textového agenta. Citlivé GUI operace mohou vyžadovat approval. --- # 50. MULTIMODALITA Podpora: - text - image - audio - video - screen - documents - code U multimodálního vstupu musí být řešena: - provenance - privacy - metadata - malicious content - prompt injection in media - OCR trust --- # 51. VIBE CODING ENGINE CyberBrain26 má podporovat kontrolovaný agentic development. Workflow: **IDEA → SPECIFICATION → ARCHITECTURE → TASK BREAKDOWN → PLANNER → CODER → EXECUTOR → TESTER → SECURITY REVIEW → CRITIC/EVALUATOR → HUMAN REVIEW → GIT** ## Safety Gate Před merge/release: - tests - security scan - secrets scan - static analysis - dependency review - architecture review - policy check - human approval - Git commit Cílem není „AI napíše kód a bez kontroly ho spustí“. --- # 52. GIT / RELEASE MODEL Prostředí: - LAB - TEST - NEXT - VALIDATION - BETA - RELEASE Doporučený tok: **LAB → TEST → NEXT → VALIDATION → BETA → RELEASE** Každý přechod má quality gate. --- # 53. PERSONAL AI LAYER Osobní vrstva může poskytovat: - personalization - preferences - context - predictions - proactive assistance - personal workflow - task planning - reminders - project continuity Predikce nesmí znamenat nekontrolovanou automatizaci. --- # 54. PERSONAL WORKFLOW ENGINE Umožní definovat workflow typu: **trigger → context → agent → tools → approval → action → result → memory** Podpora: - scheduled tasks - recurring workflows - event-triggered workflows - conditional workflows - human-in-the-loop --- # 55. PRODUCTIVITY INTEGRATIONS Plánované integrace: - Calendar - Google Keep / podobné notes - Gmail - GitHub - další OAuth služby Integrace musí používat: - OAuth - scoped permissions - credential broker - token rotation - audit --- # 56. GITHUB AGENT GitHub Agent může pomáhat s: - issue analysis - code review - branch planning - PR preparation - tests - documentation - security review Production changes musí podléhat policy a approval. --- # 57. SOCIAL MEDIA MANAGER Funkce: - content planning - drafting - scheduling - analytics - platform adaptation - approval workflow Publikování je external side effect a může vyžadovat explicitní approval. --- # 58. WEB & DOMAIN MANAGER Podpora: - domain research - DNS inspection - certificate monitoring - website monitoring - deployment assistance - content workflows - security checks Destruktivní změny DNS/deploymentu musí být chráněné policy. --- # 59. CONTENT CREATION ENGINE Podpora: - text - images - audio - video - presentations - documents - social content - technical reports Výstupy musí mít možnost provenance a human review. --- # 60. CZECH VOICE LAYER Plánovaná podpora: - Czech speech-to-text - Czech text-to-speech - voice commands - hands-free workflow Voice commands jsou jen další input channel a musí respektovat stejný policy model. --- # 61. MULTIPLATFORM Cílové platformy: - Linux - Windows - macOS - Web - Android - případně iOS Shared core + platform-specific adapters. Core logika nesmí být pevně svázána s jediným desktop OS. --- # 62. ENTERPRISE DEPLOYMENT Podporované varianty: - LOCAL - SELF-HOSTED - PRIVATE CLOUD - HYBRID - ENTERPRISE Enterprise architektura musí umožnit: - SSO podle potřeby - RBAC/ABAC - tenant isolation - audit - compliance - private networking - data residency - policy administration - controlled model/provider selection --- # 63. SECURITY THREAT MODEL CyberBrain26 musí počítat minimálně s: - prompt injection - indirect prompt injection - tool poisoning - malicious MCP servers - excessive agency - credential theft - data exfiltration - insecure tool calls - agent hijacking - agent-to-agent attacks - memory poisoning - supply-chain attacks - rogue agents - malicious files - malicious URLs - compromised dependencies - compromised model/provider - insider misuse --- # 64. SUPPLY-CHAIN SECURITY Kontrolovat: - Python packages - npm packages - Docker images - MCP servers - model files - skills/plugins - external runtimes - Git dependencies Požadováno podle rizika: - version pinning - hashes - provenance - vulnerability scanning - trust classification - SBOM - update review --- # 65. ZERO-TRUST DATA FLOW Každý externí nebo interní vstup má být klasifikován. Příklad toku: **INPUT → CLASSIFICATION → PRIVACY → SECURITY → POLICY → MODEL → OUTPUT VALIDATION → TOOL POLICY → EXECUTION → AUDIT → MEMORY** --- # 66. GOVERNANCE DASHBOARD Dashboard má zobrazovat minimálně: - AI systems - models - providers - agents - tools - permissions - risks - incidents - compliance status - approvals - evidence - failed tests - security score - resource use --- # 67. QUALITY GATES Každý významný release musí projít podle rozsahu: 1. Functional Gate 2. Security Gate 3. Privacy Gate 4. Architecture Gate 5. Performance Gate 6. Evaluation Gate 7. Governance Gate 8. Human Gate --- # 68. NEW TECHNOLOGY EVALUATION Každý nový framework, model, tool nebo runtime se posuzuje podle: 1. Je skutečně potřeba? 2. Kam architektonicky patří? 3. Je local/free/optional? 4. Jaká má oprávnění? 5. Jaká jsou bezpečnostní rizika? 6. Jaké má resource requirements? 7. Jak snadno jej lze nahradit? 8. Vytváří lock-in? 9. Do kterého environmentu patří? 10. Jaká je jeho přidaná hodnota? 11. Jaká je jeho licence? 12. Jaká je jeho provenance/trust? 13. Lze jej integrovat přes interface/adapter bez core lock-inu? 14. Jaký je migrační plán při změně nebo zániku technologie? --- # 69. DEPENDENCY PRINCIPLES Komponenty musí mít jasně definované závislosti. Například: - Experience Layer závisí na Control/API vrstvě. - Agent Layer závisí na orchestration, model gateway a policy. - Execution Layer závisí na identity + permissions + sandbox. - Memory závisí na Data Plane a privacy/trust policy. - Governance závisí na registries, audit a evidence. - Compliance nesmí být jediným mechanismem security. - External protocols (MCP, A2A) musí být za protocol adapters. - Identity providers (Local/OIDC/DID/VC) musí být za identity interfaces. - Execution backends (process/container/microVM) musí být za execution interfaces. - Retrieval strategies (vector/keyword/graph/GraphRAG/hybrid) musí být za retrieval interfaces. - Provenance mechanisms (metadata/C2PA/watermarking/labels) musí být za transparency interfaces. - Nová technologie nesmí vynutit změnu doménových modelů v core. Security nesmí být až nadstavba po dokončení agentů. --- # 70. OBSERVABILITY Systém musí mít jednotnou observability vrstvu pro: - OpenTelemetry traces/spans tam, kde to dovoluje privacy policy - logs - metrics - traces - security events - model usage - agent runs - tool calls - latency - resource consumption - failures Privacy policy musí určovat, co se skutečně ukládá. --- # 71. INCIDENT MANAGEMENT Incident workflow: **DETECT → CLASSIFY → CONTAIN → INVESTIGATE → REMEDIATE → VERIFY → DOCUMENT → LEARN** Incidenty musí být propojené s: - evidence - audit - affected agent/model/tool - policy - remediation - regression tests --- # 72. SECURITY REGRESSION Každý významný security finding má být podle možností převeden na opakovatelný test. Cíl: **finding → regression test → CI/security gate → prevention of recurrence** --- # 73. ARCHITECTURAL DIFFERENTIATION CyberBrain26 se má odlišovat kombinací: - local-first - zero-cost base - vendor-neutral - security-first - privacy-preserving - multi-agent - computer use - OSINT - Deep Research - Vibe Coding - AI security lab - AI governance - compliance - enterprise deployment Nejde pouze o další chatbot. --- # 74. MASTER SECURITY PRINCIPLE Nejdůležitější architektonické pravidlo: **AUTONOMY ONLY ABOVE:** **IDENTITY → POLICY → PERMISSIONS → SECURITY → EVALUATION → AUDIT → GOVERNANCE** Čím vyšší autonomie, tím silnější musí být kontrolní vrstvy. --- # 75. IMPLEMENTAČNÍ ROADMAPA ## Phase 0 — Forensic / Architecture Audit Cíl: - inventura starého projektu - ověření všech adresářů - Git historie - soubory - velikosti - metadata - backupy - handoff - dependencies - funkčnost - rozdíly mezi BETA/NEXT/LAB Výstup: **KEEP / REFACTOR / REWRITE / ARCHIVE / DROP** --- ## Phase 1 — Clean Foundation - čistý repository baseline - Python environment - config - logging - basic FastAPI - health checks - testing - Git - CI základ - security baseline --- ## Phase 2 — Core Control Plane - API Gateway - Event Bus - Task Queue - registries - workflow foundation - configuration --- ## Phase 3 — Security Foundation - Identity - Agent Identity - RBAC - ABAC - Policy Engine - Permission Gateway - Approval Manager - Audit --- ## Phase 4 — Modular Architecture Rozdělení systému na jasné moduly/planes bez tvrdého coupling. ### Povinné extension contracts této fáze - AgentTransport / AgentProtocolProvider → připraveno pro A2A - ToolProtocolProvider → MCP adapter - IdentityProvider → Local/OIDC, DID/VC později - CredentialProvider → scoped/JIT credentials - ExecutionProvider → local/container/microVM backends - RetrievalProvider → vector/keyword/graph/GraphRAG/hybrid - ProvenanceProvider → metadata/C2PA/watermark/labels - EventBusProvider → NATS/Redis Streams/other - TelemetryProvider → OpenTelemetry/other V této fázi se nemusí implementovat všechny budoucí backendy. Musí ale existovat stabilní rozhraní, test doubles a contract tests. Požadavek: - explicitní interfaces - dependency rules - testability - replaceability - plugin boundaries - stable contracts - protocol adapters - provider interfaces - extension points pro A2A, DID/VC, microVM, GraphRAG, provenance a další budoucí technologie - žádný core module nesmí importovat konkrétní external provider implementation přímo --- ## Phase 5 — Model Layer - LiteLLM - Ollama - llama.cpp - Model Registry - Provider Registry - Model Intelligence - routing - fallback --- ## Phase 6 — Agent Layer - Planner - Router - Supervisor - Evaluator - specialized agents - LangGraph orchestration --- ## Phase 7 — Execution Layer - Python - Shell - browser - Git - Docker/Podman - MCP - Open Interpreter - OpenClaw integration --- ## Phase 8 — Data & Memory - SQLite - ChromaDB - memory trust - project memory - Notebook - Knowledge Base - provenance --- ## Phase 9 — AI Firewall & Privacy Gateway - injection detection - tool validation - MCP controls - PII detection - redaction - pseudonymization - egress control - secret protection --- ## Phase 10 — Security Lab - Kali - disposable VMs - containers - microVMs - vulnerable targets - AI security testing - attack simulation - evidence layer --- ## Phase 11 — Deep Research / OSINT - research engine - OSINT - source validation - citations - evidence - dark-web research isolation --- ## Phase 12 — Vibe Coding / Developer Platform - planner - coder - tester - security review - critic - Git workflow - regression --- ## Phase 13 — Computer Use / Multimodal - screen - browser - PyAutoGUI - xdotool - image/audio/video - multimodal security --- ## Phase 14 — Personal AI - personalization - workflow engine - prediction - Czech voice - proactive assistance --- ## Phase 15 — Productivity Integrations - Calendar - email - notes - GitHub - OAuth - scoped credentials --- ## Phase 16 — Content / Social / Web - Content Creation Engine - Social Media Manager - Web & Domain Manager --- ## Phase 17 — Governance & Compliance - AI inventory - risk classification - system/model cards - compliance engine - evidence - human oversight - transparency - incident management - regulatory monitoring --- ## Phase 18 — Enterprise - multi-tenancy - enterprise RBAC/ABAC - SSO - private networking - data residency - enterprise audit - deployment profiles --- ## Phase 19 — Cross-platform - Linux - Windows - macOS - Web - Android - iOS where justified --- ## Phase 20 — Production / Global Product - release hardening - documentation - supportability - upgrade strategy - migration tools - security response - compliance evidence - packaging - enterprise deployment - internationalization --- # 76. PHASE EXIT CRITERIA Každá fáze musí mít měřitelné výstupy. Minimální princip: - Functional criteria - Security criteria - Privacy criteria - Performance criteria - Test coverage - Documentation - Dependency status - Migration status - Known risks - Rollback plan Fáze není hotová jen proto, že „kód funguje“. --- # 77. DEFINITION OF DONE Komponenta je Done, pokud podle rozsahu splňuje: - funkční požadavky - testy - security review - privacy review - policy integration - observability - dokumentaci - dependency review - resource review - regression coverage - Git/release criteria U citlivých komponent také: - audit - approval flow - evidence - governance mapping --- # 78. CLEAN BASELINE POSTUP Po uložení této roadmapy: 1. Freeze starý projekt. 2. Udělat forensic/architecture audit. 3. Získat kompletní inventuru BETA/NEXT/LAB. 4. Porovnat starou implementaci s v4.0. 5. Označit KEEP/REFACTOR/REWRITE/ARCHIVE/DROP. 6. Vytvořit čistý nový baseline. 7. Přenést pouze ověřené části. 8. Validovat Phase 1–3. 9. Teprve potom zahájit Phase 4 — Modular Architecture. --- # 79. KONEČNÁ DEFINICE CYBERBRAIN26 v4.0 CyberBrain26 v4.0 je modulární, vendor-neutral, local-first a security-first AI platforma pro osobní i enterprise použití. Integruje: - multi-agent AI - lokální/cloud modely - model routing - AI orchestration - cybersecurity - OSINT - Deep Research - coding - Vibe Coding - computer use - knowledge management - Notebook workspace - multimodalitu - automatizaci - enterprise integrace - privacy - AI security - AI governance - compliance Citlivé akce jsou řízené pomocí: **IDENTITY → POLICY → PERMISSIONS → SECURITY → EVALUATION → AUDIT → GOVERNANCE** Systém má být schopný fungovat od lokálního osobního prostředí až po enterprise deployment bez přepsání základních architektonických principů. --- # 80. MASTER PRINCIPLE > **CyberBrain26 není jeden AI agent.** > > Je to bezpečnostně řízené AI prostředí, ve kterém mohou různé modely, agenti, nástroje a externí runtimes spolupracovat, ale žádná jednotlivá komponenta nesmí automaticky získat důvěru, neomezená oprávnění nebo kontrolu nad celým systémem. --- **Canonical baseline:** `CyberBrain26 MASTER ROADMAP v4.0` **Suggested filename:** `Cyberbrain26_master_roadmapv4-0.md` **Role:** základ pro audit, clean baseline, Phase 4 a další implementaci CyberBrain26. --- # 76. OVĚŘENÍ NOVĚ PŘIDANÝCH ARCHITEKTONICKÝCH SMĚRŮ Tato sekce zachycuje rozhodnutí provedená po externím ověření návrhů před jejich zanesením do baseline. Neznamená automatickou implementaci všech technologií. Znamená, že core architektura musí mít připravené extension points. ## MCP 2026-07-28 **Rozhodnutí:** ADOPT AS COMPATIBILITY BASELINE / ADAPTER. Ověřeno: MCP 2026-07-28 je aktuální vydaná specifikace; změny zahrnují stateless protocol core a významné authorization/protocol změny. Interní CyberBrain26 Tool Contract proto nesmí být totožný s MCP wire contractem. ## A2A 1.0.0 **Rozhodnutí:** ARCHITECTURE READY / IMPLEMENT LATER. A2A je externí agent-to-agent protocol. CyberBrain26 připraví AgentTransport a A2A Gateway, ale A2A nebude povinným interním transportem. ## EU AI Act Article 50 **Rozhodnutí:** COMPLIANCE POLICY LAYER. Article 50 se neimplementuje jako univerzální pravidlo „všechny výstupy mají watermark“. Pro interakci člověk–AI, syntetický obsah, emotion/biometric use a některé veřejně informační texty existují odlišné transparentnostní požadavky a podmínky. CyberBrain26 proto potřebuje klasifikaci výstupu a policy-driven transparency controls. ## DID / VC **Rozhodnutí:** OPTIONAL IDENTITY/CREDENTIAL ADAPTERS. DID/VC jsou standardizované technologie, ale nejsou nutné jako základní identity mechanismus CyberBrain26. Core musí podporovat provider abstraction, aby je bylo možné přidat bez přepisu Identity Layer. ## NanoClaw **Rozhodnutí:** OPTIONAL RUNTIME / ISOLATION ADAPTER. NanoClaw je agent/container runtime pattern, nikoli microVM hypervisor. Nemá být zaměněn s Firecracker. ## Firecracker / Podman Quadlet **Rozhodnutí:** SEPARATE LAYERS. Firecracker patří do execution isolation backendů jako microVM. Podman Quadlet patří do container lifecycle/deployment vrstvy. Obě technologie se integrují přes Execution/Deployment abstractions. ## Watermarking **Rozhodnutí:** OPTIONAL PROVENANCE MECHANISM. Watermarking není univerzální povinný mechanismus. CyberBrain26 zavádí AI Content Provenance & Transparency Layer, která může podle policy použít machine-readable marking, provenance metadata, C2PA, visible labeling nebo watermarking. ## GraphRAG **Rozhodnutí:** ADDITIONAL RETRIEVAL STRATEGY. GraphRAG nenahrazuje vector/keyword/hybrid retrieval. Je jednou z možných strategií v provider-based Retrieval Engine. ## Hlavní závěr **Nyní implementujeme hlavně rozhraní a bezpečnostní hranice, nikoli všechny budoucí technologie.** Cílem je, aby pozdější přidání A2A, DID/VC, Firecracker, NanoClaw, GraphRAG, C2PA nebo jiného provideru znamenalo přidání adapteru/provideru a testů, nikoli redesign Control Plane, Identity, Data Plane, Security Plane nebo Governance Plane. --- # 77. ARCHITECTURAL COMPATIBILITY RULE Budoucí změna technologie musí být pokud možno řešitelná tímto postupem: **INTERFACE → ADAPTER → PROVIDER → POLICY → TESTS** Pokud přidání nové technologie vyžaduje změnu více core planes, musí projít Architecture Gate a být považováno za potenciální redesign, nikoli běžný plugin.