Arc OS

System Orkiestracji dla Zespołów AI

Twoja firma nie potrzebuje kolejnych chatbotów. Potrzebuje departamentu, który nigdy nie śpi.

Czym Jest Arc OS

Arc OS to platforma zarządzania zasobami AI, która wdraża autonomiczne zespoły agentów w wizualnym biurze w czasie rzeczywistym. Każdy agent ma zdefiniowaną rolę, przełożonego i egzekwowalne standardy jakości. CEO wyznacza kierunek. Agenci zajmują się resztą.

Jedno zdanie: Arc OS zamienia modele AI w odpowiedzialni pracowników, którzy nawzajem recenzują swoją pracę zanim złożą raport tobie.

v2: Architektura Native-First

Arc OS to przepisany od zera system oparty natywnie na Claude Code:

67% mniej kodu. Zero niestandardowego backendu. Te same możliwości.

Podstawowe Funkcje

1. Łańcuch Dostaw AI

Agenci działają jako skoordynowany łańcuch dostaw — nie izolowane chatboty:

CEO wyznacza cel
    → Rick dekompozytuje, deleguje, przypisuje ograniczenia
        → Morty wykonuje (kod, analiza, infrastruktura)
            → Summer recenzuje (bezpieczeństwo, jakość, audyt OWASP)
                → Jerry dokumentuje (decyzje, uzasadnienia, ślad audytowy)
    → Rick syntetyzuje wszystkie wyniki
    → CEO widzi tylko końcowy, zwalidowany output

2. Agent Teams (Native)

Zbudowane na Claude Code Agent Teams:

• TeamCreate — wdróż skoordynowany zespół
• TaskCreate/TaskUpdate — ustrukturyzowane zarządzanie zadaniami
• SendMessage — komunikacja między agentami
• Nie wymaga niestandardowej warstwy komunikacji

3. Wizualne Biuro

Pikselowe biuro Phaser.js w czasie rzeczywistym, w którym agenci istnieją jako trwałe encje:

• Agenci siedzą przy biurkach, podchodzą do siebie przy delegowaniu
• Dymki dialogowe pokazują bieżącą aktywność
• Kolory statusów odzwierciedlają obciążenie pracą
• Tablica zadań widoczna na ścianie
• Biuro JEST stanem systemu — jedno spojrzenie pokazuje wszystko

4. Mobilne Centrum Dowodzenia (Telegram)

Oficjalna integracja z Telegram Channel:

• Komendy w języku naturalnym: /status, /tasks, delegowanie
• Przesłane pliki automatycznie klasyfikowane i kierowane do agentów
• Aktualizacje postępu przez edycje wiadomości
• Reakcje dla szybkiego feedbacku

5. Prywatność i Szyfrowanie Zero-Knowledge

Twoje dane są szyfrowane w spoczynku — klucze API, wiadomości czatu i wrażliwa konfiguracja są chronione szyfrowaniem AES-256-GCM. Klucze odzyskiwania (format w stylu 1Password) zapewniają, że nigdy nie stracisz dostępu. Nagłówki bezpieczeństwa (CSP, X-Frame-Options) i sanityzacja PII w logach dodają dogłębną obronę.

6. Skille Na Żądanie

Przenośna ekspertyza ładowana dynamicznie:

• handoff-protocol, code-review, system-audit, git-manager, project-onboarding
• Skille dopasowują się do triggerów komend
• Ładowane na żądanie, nie trwale w kontekście
• Do 70% redukcja bezczynnego zużycia tokenów

6. Nieskończona Pamięć (NotebookLM Bridge)

Realne wyszukiwanie semantyczne zasilane przez Google NotebookLM — nie dopasowywanie słów kluczowych:

• NotebookLM Bridge — serwis Python FastAPI (:19213) opakowuje notebooklm-py
• Auto-sync — zamknięcie/otwarcie issue i aktualizacje wiki automatycznie synchronizują się z Google
• Czat Cloud PM — narzędzie ask_notebooklm semantycznie odpytuje wiedzę projektu
• Fallback — lokalne wyszukiwanie słów kluczowych gdy bridge jest niedostępny
• Notebooki per projekt — każdy projekt otrzymuje własny notebook Google NotebookLM
• Bridge JEST trwałą pamięcią — Google obsługuje RAG za darmo, 100% dokładności

7. Lifecycle Hooks

Hooki Claude Code automatycznie synchronizują stan agentów bez ręcznej interwencji:

• SubagentStop → agent oznaczony jako bezczynny w office-state.json → SSE → aktualizacja UI Phaser
• Stop → generowane podsumowanie sesji, wszystkie agenty resetowane do bezczynności
• Hooki SĄ klejem — żadnego pollingu, żadnego crona, tylko synchronizacja stanu sterowana zdarzeniami

8. Blueprinty Departamentów

5 wstępnie skonfigurowanych zestawów:

• Web: Rick prowadzi, Morty koduje, Summer recenzuje
• GameDev: Summer prowadzi design, Rick obsługuje silnik
• Debug: Rick kategoryzuje, Morty debuguje, Summer waliduje
• Legal: Beth prowadzi analizę, Summer recenzuje
• Service: Rick prowadzi ops, Morty wykonuje

Dla Kogo to Jest

• Solo developerzy, którzy potrzebują niezawodnego outputu AI bez pilnowania każdej odpowiedzi
• Techniczni założyciele, którzy chcą warstwy operacyjnej AI, która się skaluje
• Agencje, które potrzebują izolowanych, brandowanych przestrzeni roboczych AI per klient
• Każdy zmęczony kopiowaniem promptów między zakładkami i ręcznym przeglądaniem kodu AI

9. Sfederowana Architektura Botów (Phase 20)

Zarządzanie wieloma projektami przez federację Master + Child botów:

• Master Bot — lekki orkiestrator Telegram (nie AI): /status, /health, /deploy, /new_project, /remove_project, /watchdog
• Child Boty — proxy Telegram ↔ Claude CLI per projekt z izolowanym kontekstem
• Onboarding — interaktywny wywiad → automatyczne provisionowanie z dopasowaniem skilów
• Samoleczenie — watchdog automatycznie restartuje crashed childre z exponential backoff
• Zaszyfrowany skarbiec — magazyn AES-256-GCM dla tokenów botów (nie w .env)
• Ustrukturyzowane logowanie — format JSONL, dzienna rotacja, przyjazny dla grep/jq

10. CRM Dashboard i Obserwowalność (Phase 22)

Zarządzanie projektami w czasie rzeczywistym przez serwer HTTP Bun:

• REST API — 18 endpointów CRM: projekty, logi, pliki, skille, metryki, specyfikacje, role, wiadomości, learnings, heartbeat
• Strumienie SSE — live tailowanie logów JSONL + output consulta
• Terminal WebSocket — tmux capture-pane z kolorami ANSI + tryb interaktywny
• Wykresy Sparkline — canvas bar charts dla timeseries sukces/błąd
• Flow Auth — email/hasło lub OAuth (Google, GitHub) → token JWT (TTL 24h)

11. Dual-Agent Flow (Phase 24.5)

Współpraca dwóch ról per projekt:

• Consultant (Sonnet, tylko odczyt) — analiza, specyfikacje, propozycje architektury przez /c
• Developer (Opus, pełny dostęp) — implementacja, deployment przez /d
• Kolejka Spec — automatycznie wyodrębniana z wzorca ### SPEC:, CEO zatwierdza/odrzuca
• Motyw Slate & Silver — ciemny glassmorphism w całym UI

12. Lokalny Gateway Bridge (Phase 25)

Podłącz lokalne IDE do inteligencji Arc OS:

• Bridge CLI (citadel-bridge) — connect, pull, push, status, disconnect
• Sync Skilów — pobierz bundle skilów + evals z CRM do lokalnego projektu
• Sync Learnings — dwukierunkowy: pobieraj korekty, pushuj lokalne odkrycia
• Wstrzykiwanie CLAUDE.md — automatyczny kontekst Arc OS przez markery <!-- CITADEL:START/END -->
• Heartbeat — raportuj aktywność lokalnej sesji do CRM dashboard

13. Knowledge Dashboard (Phase 32)

Pełnofunkcjonalne zarządzanie wiedzą projektu:

• Reports Feed — widok osi czasu, grupowany datami, kolorowe tagi źródeł
• CRUD Skilów — edytor split-pane dla definicji skilów
• Edytor Wiki — edycja inline, zapis, tworzenie stron markdown
• NotebookLM — markowe landing z kartami przypadków użycia

14. Multi-Tenant tworzenie Projektów (Phase 33)

Self-service tworzenie przestrzeni roboczej dla powracających użytkowników:

• Ustawienia Konta — klucze API per użytkownik przechowywane bezpiecznie (0o600)
• Modal Tworzenia Projektu — 3 pola (nazwa, nisza, preset), bez pełnego kreatora
• Katalogi z namespace użytkownika — /opt/repos/{chatId}_{projectName}/
• 10 wielokrotnie używanych helperów — allocatePort, createProjectDirectories, generateClaudeMd itd.

15. Autonomiczny Menedżer Projektów (Phase 34)

8 narzędzi MCP dla hands-free zarządzania projektami:

• CRUD Issues — create_issue, list_issues, update_issue (P0-P3, etykiety)
• Sync Wiki — update_wiki tworzy/aktualizuje strony markdown
• Silnik Roadmapy — sync_roadmap z zamianą statusu w miejscu
• Wstrzykiwanie Init — otwarte issues + następny cel roadmapy automatycznie wstrzykiwane do CLAUDE.md

16. Live Terminal Sync (Phase 35)

Streamuj output lokalnego Claude Code do web dashboard w czasie rzeczywistym:

• Backend — POST /terminal/log odbiera linie JSONL, dołącza do plików logów
• ARC CLI — Bun.spawn z potokiem stdout, buforowany POST co 2s, usuwanie ANSI
• Frontend — przełącznik zakładek Bot/Live z zielonym pulsującym punktem dla live streamów

17. Cloud Project Manager (Phase 36)

Analiza projektu oparta na AI przez web dashboard:

• Czat SSE — POST /api/crm/projects/:name/chat proxy do Anthropic API
• Pętla narzędzi po stronie serwera — ask_notebooklm semantycznie odpytuje wiki, issues, roadmapę
• NotebookLM Bridge — Python FastAPI z wyszukiwaniem semantycznym Google + auto-sync

18. Sage Worker + Skill Evolution (Phase 40.11)

Kolekcjonowanie skilów oparte na danych z opcjonalnym benchmarkowaniem A/B:

• Sage (model Haiku) — analizuje drafty skilów vs rejestr, wykrywa nakładanie się i luki
• Żądania aktualizacji (PR) — ludzie recenzują, zatwierdzają/odrzucają, auto-log ewolucji
• Benchmarki A/B — przeprowadzaj head-to-head ewaluacje na rzeczywistych promptach przed promowaniem skilla
• Odkrywanie Marketplace (Phase 40.12) — skanuje claudemarketplaces.com, analizuje kompatybilność przez LLM, instalacja jednym kliknięciem (globalnie lub per projekt)

19. Knowledge Graph + Obsidian Link (Phase 40.17)

• /api/crm/projects/:name/knowledge-graph — węzły + krawędzie z linków wiki
• Graf force-directed na canvas w frontendzie (bez bibliotek zewnętrznych)
• Przycisk Otwórz w Obsidian na każdej karcie Neural Memory — skocz bezpośrednio do vault

20. Odświeżenie UI — Adaptacja Projektu Vercel (Phase 41)

Etapowa migracja referencyjnego projektu Next.js wygenerowanego przez Vercel do istniejącego stosu React+Lingui+Vite. 8 pod-faz, zero zmiany frameworka:

• Tokeny projektu — przestrzeń kolorów OKLCH (głęboki teal primary, ciepły amber akcent, ciepły ivory surface), Inter + JetBrains Mono
• Piguły Worker Selector — poziome pigułki z awatarami tone-ring (kolorowane deterministycznym hashem id workera)
• Dymki wiadomości czatu — użytkownik odwrócony (ciemny bg pierwszego planu), prefiks awatara workera, asymetryczne zaokrąglone narożniki, pasek akcji per wiadomość (Zapisz do notatki, Kopiuj, 👍, 👎)
• Composer — wbudowany przełącznik modelu (Sonnet ↔ Opus), chip Tools z odznaką liczby aktywnych, chip szybkiego wstawiania /btw, dół akcji poniżej (/btw, Pause, Stop, Approve Last)
• Sidebar — odznaka liczby issues na nawigacji, feed Live Activity (top 3 zdarzenia issue, poll 30s), animowany ping-pulse na zsynchronizowanej Neural Memory
• TopBar — przycisk Search z podpowiedzią kbd ⌘/Ctrl K uwzględniającą platformę (globalny listener go focusuje)
• Context Rail (nowy) — 320px prawy panel, widoczny ≥1280px: Current Goal parsowany z ROADMAP.md + metryki 2×2 (Otwarte issues, Zamknięte/tydzień, Zablokowane, Skille) + lista Active Skills + Przypięte z wątku + stopka git-branch
• Pinned Notes (funkcja backendowa) — migracja 009 + POST/GET/DELETE /api/crm/projects/:name/pins. "Zapisz do notatki" w czacie teraz przypina wiadomość do Context Rail zamiast pisać do wiki.

21. Hartowanie Bezpieczeństwa (Phase 42)

Wywołane audytem agenta Sentinel 2026-04-23. 13 łatek bezpieczeństwa w 4 niezależnych przejściach audytu. Werdykt: 🟢 ZIELONY, gotowy na wielu użytkowników.

• Strażnik multi-tenancy — canAccessProject(registry, chatId, project) na każdej chronionej trasie (SSE, terminal WebSocket, blokada CLI/MCP). Interaktywny terminal WS wymaga CEO lub role=admin.
• Perymetr — Bun binduje wyłącznie 127.0.0.1:19210; /api/internal/* odrzuca nagłówki proxy (X-Forwarded-For/X-Real-IP/Forwarded) jako kanarek misconfiguracji nginx.
• Allowlist SSRF — handleScoutAnalyze ogranicza wychodzący fetch do https + hosta claudemarketplaces.com, redirect:"manual" blokuje bypass łańcucha przekierowań.
• Ścieżki tokenów — extractChatId czyta zarówno nagłówek Bearer jak i query ?token= (dopasowanie browser EventSource z crmAuthMiddleware).
• Hartowanie — timingSafeEqual na sygnaturze JWT, audyt safePath we wszystkich handlerach (naprawiono traversal handleSaveSkill), lista deny nginx rozszerzona o config/+data/+knowledge-base/.
• Pokrycie regresji — scripts/vps-sync.sh uruchamia 7+ testów smoke po deploy (bind loopback, path traversal, blokada SSRF, kanarek proxy, SSE ?token=, walidacja fail-closed, wejście chat/save).

Pełna dokumentacja: docs/SECURITY.md, raport audytu: docs/security/audit-2026-04-23.md.

22. Zero-Knowledge E2EE (Phase 45)

Szyfrowanie po stronie klienta dla wrażliwych danych przestrzeni roboczej. Nawet operatorzy Arc OS nie mogą odczytać zaszyfrowanej zawartości.

• Derywacja klucza głównego — WebCrypto PBKDF2 (100k iteracji) → klucz AES-256-GCM cachowany w sessionStorage
• Klucze odzyskiwania — format w stylu 1Password XXXX-XXXX-XXXX-XXXX-XXXX, zaszyfrowana kopia zapasowa klucza głównego
• Szyfrowanie w spoczynku — skarbiec AES-256-GCM dla kluczy API, zaszyfrowane kolumny SQLite dla wiadomości czatu
• Dogłębna obrona CSP — default-src 'self', X-Frame-Options: DENY, X-Content-Type-Options: nosniff
• Sanityzator PII — redaguje emaile, klucze API, JWT, numery kart z logów JSONL przed zapisem na dysk

23. Timeline i Redesign Issues (Phase 47)

Obserwowalność inspirowana DAW i zgrupowane fazami śledzenie issues.

• Timeline — pasy workerów, chipy zdarzeń, kontrolki mute/solo, przewijana głowica odtwarzania. Odtwarza sesję workera jak konsolę mikserską audio.
• IssuesRedesign (Phase 47.8) — tabela zgrupowana fazami + panel szczegółów slide-in, animacja pulsowania P0, paski postępu, responsywny na mobile.

24. Dekompozycja Architektury (Phase 48)

Refaktoryzacja monolitów w moduły domenowe bez zmiany zachowania.

• Router CRM — crm-routes.ts (10 779 LOC) → shared/routes/router.ts (373 LOC) delegujący do 19 modułów domenowych
• UI Workspace — Workspace.jsx (~2 000 LOC) → 168-liniowy orkiestrator + 9 komponentów w pages/workspace/
• Serwer API — master-bot/api-server.ts (196 linii) deleguje do master-bot/routes/{auth,internal,cli,websocket}.ts
• Phase 48.5 — event-driven CRM inbox przez fs.watch (latencja 100× niższa niż polling 500ms)
• Phase 48.6 — leniwy lifecycle workera: idle-kill + budzenie na żądanie, ~298 MB RAM zwolnione (39%), pojemność 2 → 6-10 równoczesnych użytkowników

25. Egzekwowanie Dokumentacji (Phase 49.1)

Hook git pre-push (.githooks/pre-push → scripts/check-docs-coverage.ts) blokuje pushe, które zmieniają kod bez aktualizacji zmapowanych dokumentów.

26. Trial Credits + Stripe Billing (Phases 50-51)

Self-serve monetyzacja na bazie zerowego kosztu podstawowego.

• Trial credits (Phase 50) — jednorazowe per email, blokuje tworzenie projektów + dostęp do Anthropic API dla płatnych planów
• subscriptions + stripe_events (migracja 020) — ID klienta Stripe, poziom planu, log idempotentności
• PLAN_LIMITS — jedyne źródło prawdy dla mapowania plan → projekty/workerzy/funkcje
• checkPlanLimit(userId, action) — middleware OR-semantic zwraca {allowed, reason, current, limit, plan}
• Poziomy cenowe — Free (1 projekt / 5 workerów), Min ($4.99 — 5 LUB 25), Max ($11.99 — 20 LUB 150)
• 402 Payment Required — ustrukturyzowany błąd przy handleOnboardingSetup + handleCreateWorker po przekroczeniu limitu

27. F&F Beta Launch (Phase 52.1)

Zamknięta beta przed publicznym startem — rejestracja tylko na zaproszenie, dedykowana pętla feedbacku.

• Kody zaproszeń — format arc-XXXX-XXXX (hex crypto.randomBytes), tabela invites (migracja 021)
• Bramka rejestracji — /api/auth/register wymaga invite_code, zwraca 403 invite_required w przeciwnym razie
• Endpointy admin — POST/GET/DELETE /api/crm/admin/invites + ARC CLI arc invites generate/list/revoke
• Poziom planu beta — nieograniczony (Infinity projektów/workerów, wszystkie funkcje Max) bez przyznawania roli admin
• Kanał feedbacku — Telegram @arcos_beta_feedback, cotygodniowy digest, 50% zniżki dożywotniej + Founders Wall

28. Egzekwowanie Dyscypliny Issues (#115 / #116 / #117, maj 2026)

"Każde zadanie = zarejestrowane issue + audytowalny ślad aktywności" to kamień węgielny obietnicy Arc OS. Workerzy znali regułę z CLAUDE.md, ale nic w runtime jej nie egzekwowało — projekty regularnie gromadziły dni ukończonych sesji CLI bez żadnych otwartych issues. To trio trzech issues zamyka pętlę od końca do końca.

#115 — bindowanie runtime (CLI + Web + Telegram, wszystkie trzy powierzchnie):

• Picker startowy sesji przy arc <project> — interaktywna lista otwartych issues (sortowanie P0→P3 + recent-first, filtr rozmyty gdy >10), niedawno zamknięte (z potwierdzeniem ponownego otwarcia), [n] utwórz nowe, [q] pomiń z podwójnym potwierdzeniem. Wybrany id persystuje do ~/.arc/sessions/<project>-<worker>.json i jest wstrzykiwany jako zmienna env ARC_ACTIVE_ISSUE_ID do podprocesu Claude + jako blok Active issue: #N — Title w CLAUDE.md, żeby workerzy sami logowali w trakcie sesji.
• Modal Web Workspace odzwierciedla przepływ CLI; klikalny pill aktywnego issue w pasku workera pozwala użytkownikowi wybrać ponownie w dowolnym momencie. Persystuje przez POST /api/crm/projects/:name/active-issue (zapisuje zdarzenie activity_log session_active_issue).
• Telegram — zestaw /issue w każdym child bocie — list, switch <id>, create <title>, close <id>, current.
• Hook końca sesji automatycznie loguje wpis session_end z czasem trwania + liczbą commitów + dirty files. Tagi rozszerzają strumień aktywności per issue: session_start / session_end / switched_in / switched_away / auto_summary / reopened.
• Nocny cron audytu flaguje projekty z ≥5 zdarzeniami aktywności ale zerowymi aktualizacjami issue w 24h i pinguje właściciela przez master bot Telegram.

#116 — egzekwowanie w git: .githooks/commit-msg blokuje każdy commit bez #<id> (lub closes #<n> / fixes #<n> / refs #<n> / resolves #<n> / (#<n>)) gdzieś w wiadomości. Trailers Co-Authored-By + Signed-off-by są najpierw usuwane, więc refs tylko w trailerach nie spełniają reguły. Prefiksy maintenance (chore/docs/style/test/build/ci/refactor/perf), Merge / Revert / fixup! / [ci skip] przechodzą czysto. Komunikat o błędzie pokazuje aktywny id sesji użytkownika do kopiowania. Awaryjne obejście: git commit --no-verify.

#117 — retroaktywne uzupełnienie: arc retro <project> rekonstruuje issues z ~/.arc/sessions/<project>-*.json + JSONL transkryptów + git log --since=started_at --until=ended_at. Deduplikuje przez podobieństwo tytułów Jaccard (≥0.55) skrzyżowane z oknem nakładania ±48h. Wpisy aktywności trafiają na oryginalne sygnatury czasowe przez nowe opcjonalne pole ts przy POST /api/mcp/issues/:project/:id/log (wartości przyszłe są przycinane do teraz). Stara praca z commitami automatycznie zamykana; niedawno nieukończona zostaje otwarta. Tryb dry-run domyślnie, --apply tworzy.

Aktualny Status

Phase 52.1 — F&F Beta Launch w toku. Publiczny start uzależniony od kryteriów sukcesu (≥70% signup → first_message, ≥40% retencja Day-1, ≥25% retencja Day-7, 0 bugów P0 przez ostatnie 3 dni).

• 6 agentów, 5 blueprintów, 15+ skilów, ARC CLI (3 platformy + 9 cloud subcommands), React CRM Dashboard z Context Rail + Timeline + IssuesRedesign, frontend Phaser (legacy), federacja Telegram (Master + Children)
• 70+ endpointów CRM API w 19 modułach domenowych (auth, projekty, workerzy, skille, sage, pliki, wiki, czat, analityka, billing, zaproszenia itd.), Bun HTTP bindowany do 127.0.0.1
• Dual-agent flow, Dynamic Workers z fsWatch hot-reload + lazy lifecycle, Bridge CLI, ARC CLI, Knowledge Dashboard, Cloud PM Chat, NotebookLM Bridge, Sage Worker + benchmarki A/B + Marketplace Discovery, Knowledge Graph
• i18n EN/UK (438 ciągów), web auth (email + OAuth + reset hasła + weryfikacja email przez Resend), projekty multi-tenant z owner_id SSOT, lifecycle hooks, watchdog z exponential backoff, skarbiec AES-256-GCM, auto-ingest watcher
• Bezpieczeństwo i prywatność: JWT (timingSafeEqual), bramki multi-tenancy na każdej trasie, allowlist SSRF, bind loopback, zero-knowledge E2EE (PBKDF2 + AES-256-GCM, klucze odzyskiwania), nagłówki CSP/X-Frame, sanityzator PII, testy smoke na każdym deploy
• Monetyzacja: Trial credits + Stripe billing Stage 1 (DB + middleware + status), rejestracja za zaproszeniem, poziom planu beta
• DX: Hook pre-push pokrycia doc, dekompozycja architektury Phase 48 (refaktoryzacja monolitu 10 779 → 373 LOC)

Arc OS. Zbudowany natywnie na Claude Code. Agenci wykonują pracę. Google pamięta wszystko.