Saphan Studio zarządza flotami agentów kodujących AI na Twojej infrastrukturze i łączy ich pracę z dowodami oraz zapisanymi decyzjami — pod zwierzchnictwem człowieka.
Dla osób prowadzących engineering, które zatwierdzają wynik pracy agentów; zespołów platformowych uruchamiających Claude Code, Codex, Qwen Code lub modele lokalne na własnych maszynach; oraz osób odpowiedzialnych za bezpieczeństwo i audyt, które muszą odtworzyć przebieg zmiany.
Zacznij sam — Solo preview, bezpłatnie →Wprowadź zespół — design partner →Zobacz jedną zmianę od początku do końca →
Zbudowane na Saphan Protocol →
Twoja flota pracuje w języku zespołu. Rejestr audytowy odpowiada po angielsku. EN ไทย العربية
Solo · prywatny preview
Saphan Studio dla jednego developera, na jednej stacji roboczej, bezpłatnie. Zarejestruj się do prywatnego preview.
Podstawowe kontrole są zaimplementowane i codziennie używane do budowy Saphan. Solo wchodzi do prywatnego preview: rejestracja jest otwarta, a o dostępie poinformujemy, gdy będzie gotowy. Prace z roadmapy są oznaczone wszędzie, gdzie występują.
Oceniasz dla zespołu? Solo to jedna stacja robocza. Ścieżka zespołowa zaczyna się od partnerstwa pilotażowego — na czym to polega →
Co Saphan Studio daje organizacji
Nadzór → Uprawnienie człowieka — wraz z każdą ograniczoną delegacją — jest podpisane i zapisane. Milczenie nigdy nie oznacza zgody, a odmowy pozostają danymi.
Bezpieczeństwo → Agenci są traktowani jako niezaufani, nawet gdy nie są złośliwi: uruchomienia w sandboxie, a ruch wychodzący według nazwanej polityki dla każdego uruchomienia, które ją zadeklaruje.
Koszty → Każde wykonanie jest wyceniane przed uruchomieniem, a koszt trafia obok decyzji, która je zatwierdziła.
Enterprise → Control plane, rekord i tożsamość pozostają w Twojej infrastrukturze, z eksportem audytowym od pierwszego dnia.
Kontrole → Co już działa, kontrola po kontroli — jeden wiersz na każdą: co robi, co odrzuca, co zostaje w rekordzie.
Zgodność → Dowody potrzebne w istniejącym systemie zarządzania bezpieczeństwem informacji (ISMS), powiązane z wymaganiami ISO 27001, ISO/IEC 42001, SOC 2, NIST AI RMF i EU AI Act.
Funkcje produktu
Wspierane runtime’y → Claude Code, OpenAI Codex, Qwen Code, Factory Droid i Saphan Agent-Loop — pod jednym control plane.
Bench → Jakie obciążenie naprawdę obsłuży Twój sprzęt — zmierzone na Twojej maszynie, a nie wywnioskowane z karty modelu.
Serwer MCP → Zadawaj pytania rejestrowi w narzędziu, którego już używasz: sprawdzaj stan floty, bramki oczekujące na decyzję i koszty w dowolnym przekroju. Interfejs działa tylko do odczytu, za standardowym OAuth, a każdy dostęp jest rejestrowany.
Discovery → Kontrolowana analiza systemu legacy, którego nikt nie rozumie już w całości. Zwraca zatwierdzony obraz systemu, w którym każdy wniosek wskazuje źródło — poznawanie, nie zmienianie. Metoda została sprawdzona w realnych projektach i jest przenoszona na Saphan Protocol.
Dokumentacja i raporty → Dokumentacja procesu i raporty delivery generowane z samego rejestru — każda liczba prowadzi do podpisanego wiersza lub zacommitowanego dokumentu.
Co zyskujesz — według Twojej roli
Saphan nie zastępuje Twoich agentów, modeli ani Gita. Stawia ich pracę za bramką, o której decyduje człowiek, i trzyma dowody obok decyzji.
Problem. Pull requesty od agentów przychodzą szybciej, niż ktokolwiek zdąży czytać transkrypty, a review zamienia się w teatr.
W Saphan. Agenci wracają z twierdzeniami i dołączonym dowodem — diff, wyniki testów, sprawdzenie migracji. Bramka odmawia zatwierdzenia, któremu brakuje dowodu wymaganego w zleceniu.
Co widzisz. Jeden ekran na decyzję: co jest twierdzone, co udowodnione, czego jeszcze brakuje — i jedna komenda, by zdecydować.
Problem. Każdy runtime przynosi własne nawyki sandboxa i nikt nie potrafi później powiedzieć, co było osiągalne z którego miejsca.
W Saphan. Maszyny dołączają przez jawny akt właściciela. Każde uruchomienie jest izolowane przez system operacyjny albo odrzucone. Claude Code, Codex, Qwen Code i modele lokalne pracują pod tymi samymi zleceniami, bramkami i rejestrem.
Co widzisz. Dla każdego uruchomienia: który sandbox je trzymał, które katalogi pozostały zapisywalne, ile kosztowało, który plik binarny działał.
Problem. „Senior to obejrzał” nie jest dowodem, a transkrypt czatu nie jest decyzją.
W Saphan. Każda decyzja to podpisany wiersz: kto zdecydował, co, kiedy, na podstawie jakich dowodów i z jakiego upoważnienia. Osoba trzecia weryfikuje go samym kluczem publicznym root.
Co widzisz. Dziennik bramek i zapis uruchomień, eksportowane jako Markdown, CSV, PDF lub HTML — dla osoby, której nie było w pokoju.
Nadzorowane runtime’y · działają dzisiaj
Saphan obejmuje governance i security pracy wokół runtime’u: dopuszczenie, izolowaną tożsamość, dispatch, confinement, koszt, dowody, review i akt człowieka. Zmiana modelu albo CLI nie tworzy drugiego systemu operacyjnego.
Oznaczenia wskazują platformy, na których dany runtime jest ćwiczony pod izolacją Saphan. Kanoniczna tabela — wraz z tym, czego nie dowodzi — jest w dokumentacji ↗
Claude Code, OpenAI Codex, Qwen Code i Factory Droid działają jako nazwane, izolowane per seat backendy pod tymi samymi strumieniami, bramkami i ledgerem.
Wbudowana pętla narzędziowa prowadzi modele lokalne za endpointami zgodnymi z OpenAI, w tym Ollama i vLLM, bez uzależniania krytycznej ścieżki od CLI vendora.
Kompilatory, test runnery, lintery i formatery są pełnoprawnymi aktorami w rekordzie, bez kosztu modelu — jako nadzorowana praca, nie niewidoczna ucieczka do shella.
Agenci i toolchainy mogą działać w obrazach OCI przypiętych digestem, z read-only rootem, użytkownikiem non-root, ograniczonymi mountami i limitami runtime’u. Dokładny obraz jest mierzony na dokładnej maszynie przed dispatchem; brak wymaganego confinement odmawia przed spawnem.
Akceptacja człowieka dociera do Git forge w implementacji
Saphan wiąże decyzję człowieka o merge z dokładnym headem pull requestu, przenosi to uprawnienie do forge i dowiaduje się o merge przez obserwację repozytorium — nigdy przez zaufanie udanej odpowiedzi API.
Bramka zapisuje aktora, decyzję i SHA heada PR. Nowy push unieważnia tę zgodę, zamiast po cichu rozciągać ją na inny kod.
Wymagany status saphan/gate i ochrona gałęzi zatrzymują niezatwierdzony merge w samym forge. Saphan nie polega na tym, że UI zachowa się poprawnie.
Forge tworzy merge commit z trailerami atrybucyjnymi Saphan. Rekord przechodzi do stanu merged dopiero po pobraniu i zweryfikowaniu tego commita.
Kontrakt forge i jego kontrole negatywne są ćwiczone na repozytoriach GitHub i Gitea 1.26.4. Kolejne adaptery forge powstają w kolejności potrzeb design partnerów.
Zacznij sam. Zachowaj ten sam control plane, gdy flota rośnie.
Solo
Lokalny silnik, konsola webowa, CLI i praca w edytorze bez centralnego serwera. Otwarte wejście do zdyscyplinowanej pracy agentów, nie wygasający trial.
Team
Tożsamość zarządzana przez Saphan jako SaaS i bezdana sygnalizacja mobilna; flota, kod i rekord operacyjny pozostają na Twojej infrastrukturze.
saphan-oauth utrzymywany przez Saphan i pełny cykl życia tożsamościEnterprise
Samodzielnie hostowana kontrola organizacyjna, tożsamość maszyn, polityka, izolacja i eksport dowodów dla regulowanego delivery.
saphan-oauth albo dowolny dopuszczony IdP klientaSaphan Studio to środowisko, w którym prowadzisz floty agentów AI: zlecenia trafiają do wykonawców, wracają raporty z dowodami, a decyzje na bramkach podejmujesz w edytorze. Czytasz rezultaty, nie transkrypty.
Praca przechodzi dalej dopiero po dołączeniu dowodów i zapisaniu decyzji uprawnionego aktora. Zatwierdzenie człowieka jest domyślne; ograniczona automatyzacja wymaga jawnej delegacji podpisanej przez człowieka.
Wszystko trafia do zwykłych plików w Twoim repozytorium Git. Powstaje trwała pamięć operacyjna pracy, gotowa do wykorzystania przez narzędzia audytowe, które organizacja już posiada.
To nie lista funkcji. To fundament, który organizacja dostaje dziś — jeden wiersz na jedną kontrolę: co robi i co zostawia w rekordzie dla osoby, której przy tym nie było.
| Kontrola | Co działa | Co zostaje w rekordzie |
|---|---|---|
| Podpisany rekord zarządczy | Aktorzy, delegacje, maszyny, seaty i uprawnienia w jednym dzienniku append-only podpisanym Ed25519. Każdy rejestr czytelny dla człowieka jest jego projekcją — odtwarzalną, nigdy źródłem. | Cała historia zarządcza, weryfikowalna przez stronę trzecią mającą tylko główny klucz publiczny — bez zaufania do maszyny, która ją wytworzyła. |
| Brak niejawnej akceptacji | Żaden timeout nie oznacza zgody i nie istnieje domyślne auto-accept. Bramka wymaga decyzji człowieka albo jawnej, ograniczonej delegacji z polityki podpisanej przez człowieka; nie ma wartości domyślnej i odrzuca decyzje poza kolejnością. Silnik nie nadaje sobie uprawnień ani nie wykonuje merge. | Jeden wiersz na decyzję: aktor, decyzja z zamkniętego słownika, czas i łańcuch uprawnień. „Merged" nigdy nie jest deklarowane — jest tylko obserwowane z prawdziwego merge commita. |
| Decyzje odporne na manipulację | Każda akceptacja to kluczowana, zweryfikowana krotka, sprawdzana ponownie przy merge. Zmień później dowolne pole i weryfikacja pada. | Krotka i wynik jej sprawdzenia przy merge. |
| Sugestia ≠ decyzja | Konsultacja AI albo człowieka jest zapisywana jako opinia; decyzja jest odrębnym aktem uprawnionego aktora. Automatyczne uprawnienie musi wynikać z ograniczonej delegacji podpisanej przez człowieka; odejście od sugestii również jest zapisywane. | Osobne wiersze rekomendacji i decyzji na każdej bramce — nie tylko co postanowiono, ale co i kto rekomendował. |
| Tożsamość maszyny z certyfikatu | Bez endpointu rejestracji, bez join tokena. Maszynę przyjmuje jawny akt właściciela z powiązaniem certyfikatu; płaszczyzna sterowania łączy się tylko na zewnątrz, a runnery nie trzymają do niej żadnych poświadczeń. | Akt przyjęcia w podpisanym dzienniku; łańcuch certyfikatów. |
| Delegowane, ograniczone uprawnienia | Delegacje podpisane kluczem głównym, z zakresem, strumieniami pracy i oknem ważności. Wygaśnięcie to sufit, nigdy wyzwalacz; wycofanie aktora działa natychmiast, niezależnie od niewygasłych delegacji. | Delegacja z podpisem nad każdym polem — kto komu co nadał i do kiedy. |
| Ratyfikowane prawo stałe | Dokumenty rządzące tym, jak wykonuje się pracę, są podpisane kluczem głównym w numerowany seryjnie manifest. Każdy dokument weryfikuje się z powrotem do korzenia; agent pracuje pod prawem, którego otrzymanie da się wykazać. | Manifest oraz zapis każdego uruchomienia, jakie prawo zostało wstrzyknięte — z jego hashem. |
| Izolacja uruchomień na poziomie OS — lokalnie | Polityka zapisu deny-by-default z sandboksa samego systemu operacyjnego — Seatbelt na macOS, Bubblewrap na Linuksie — składana dla każdego uruchomienia, zanim agent wystartuje. Brak sandboksa odrzuca uruchomienie, zamiast je osłabiać. | Rekord uruchomienia nazywa narzędzie, które je izolowało, i katalogi, które pozostały zapisywalne — twierdzenie, które Twój zespół może odtworzyć. |
| Izolacja uruchomień na poziomie OS — zdalnie | Izolacja wymuszana przez jądro (Landlock) dla uruchomień wysyłanych przez SSH. Zdolność maszyny do izolacji jest mierzona, zanim trafi tam praca; maszyna niezmierzona albo zmierzona jako niezdolna odrzuca uruchomienie. | Zmierzona zdolność na podpisanym wierszu maszyny; rekord uruchomienia nazywający, co wymusiło. |
| Ruch wychodzący to lista | Uruchomienie, które deklaruje politykę egress, dociera do sieci wyłącznie przez drzwi, którymi ta polityka rządzi: cel jest dopuszczony tylko wtedy, gdy polityka dopuszcza i hosta, i port, a domyślnie nie dopuszcza nic. Host, którego nie da się odciąć, odrzuca uruchomienie, zamiast startować otwarty. W tym wydaniu opt-in per dispatch — nie ma jeszcze domyślnego ustawienia dla całej floty i mówimy to wprost. | Digest skompilowanej polityki na wierszu uruchomienia — która lista rządziła tym uruchomieniem. Osądy per połączenie nie są jeszcze zapisywane; to zadeklarowany limit tego wydania, nie projektu. |
| Żadnych bocznych kanałów między agentami | Agenci koordynują się wyłącznie przez zapisywane powierzchnie — ordery, pliki kanałów w worktree strumienia wciągane do rekordu, bramki, skrzynkę insert-only na dyrektywy właściciela. W produkcie nie istnieje komunikacja agent–agent. | „Kto komu co powiedział i kiedy" to zapytanie, nie przesłuchanie — historia koordynacji strumienia odtwarzalna z rekordu. |
| Odmowy jako dane | Każda odmowa — silnika, autoryzacji, schematu, polityki — to zapisany, bezkosztowy wiersz z nazwaną klasą. Przyczyny odmów są logowane, nigdy zwracane po kablu. | Księga odmów: kontrole, które zadziałały, a nie tylko istnieją. |
| Monitorowanie — cel dla Prometheusa | Demon serwujący wystawia GET /metrics w standardowym formacie tekstowym Prometheusa: uruchomienia po statusie i backendzie, odmowy po klasie, decyzje bramek po bramce i decyzji, wersja schematu magazynu. Wartości etykiet to wyłącznie nazwy klas — nigdy nazwy strumieni, ścieżki ani nazwy aktorów. |
Odmowy jako metryka pierwszej klasy — w tej architekturze odmowa to sygnał bezpieczeństwa, nie szum. Zbierane przez Prometheusa, którego już masz; nic do instalowania. |
| Wartości sekretów pozostają poza rekordem | Typy konfiguracji i dispatchu przenoszą nazwy oraz referencje, nie wartości sekretów. Pliki kluczy są sprawdzane przed użyciem, a zdalne wykonanie wyłącza przekazywanie środowiska. Proces posiadający poświadczenie może użyć wartości do uwierzytelnienia bez kopiowania jej do rekordu pracy. | Konfiguracja po nazwie. Żadnej wartości sekretu w rekordzie operacyjnym, dowodach, logu, kosztach ani eksporcie. |
| OAuth 2.1 na powierzchni zarządczej | Dostęp tylko z bearerem. Team uwierzytelnia przez utrzymywany przez Saphan SaaS saphan-oauth. Enterprise uruchamia saphan-oauth lokalnie albo dopuszcza dowolny IdP klienta przez zatwierdzaną przez człowieka listę issuerów. Klasy zakresów, wycinki na poziomie wierszy per tenant, domyślnie fail-closed. |
Log dostępu klasy audytowej na każdym transporcie — uczciwe kody statusu, nigdy wartości ani query stringi. |
| Kontrola kosztów | Wycena i twardy limit na uruchomienie ustalone przed wysłaniem; pojemność sprawdzona przed startem; klasy rozliczeniowe na seatach. Koszty rzeczywiste i odchylenie lądują obok dowodów, nie na osobnej fakturze. | Księga kosztów, per strumień i per bramka — „ile kosztowała ta zmiana" ma tę samą jednolinijkową odpowiedź co „kto ją zatwierdził". |
| Przypięty łańcuch dostaw | Binaria agentów dostarczane z digestem liczonym na maszynie odbierającej, a tożsamość rozwiązywana ponownie tam, gdzie się wykonują. | Na uruchomienie: digest binarium, wersja, hash konfiguracji, wstrzyknięte prawo stałe i jego hash. |
| Twój magazyn rekordu | Magazyn rekordu PostgreSQL na infrastrukturze, którą kontrolujesz, konfigurowany po nazwie, poświadczenia tylko przez nazwę zmiennej. Kod, dowody uruchomień i rekord operacyjny nie przechodzą przez infrastrukturę Saphan. Team przekazuje tożsamość do OAuth Saphan; Enterprise pozostawia ją lokalnie. Oba warianty mogą używać sygnalizacji mobilnej niosącej tylko nieprzejrzysty identyfikator bramki i licznik badge’a. | Twoja baza plus zwykłe pliki w Twoim gicie. Czytelne bez naszych narzędzi. |
| Zgodność mierzona, nie deklarowana | Scenariusze end-to-end uruchamiane na prawdziwym binarium: dyscyplina bramek, blokowanie dispatchu, odporność na injection, źle zaadresowane instrukcje, przepływ OAuth, kontrola bearera, parytet projekcji. | Wyniki testów zgodności, odtwarzalne na Twojej instalacji. |
Fail-closed to styl domu: nierozpoznana wartość konfiguracji, brak sandboksa, niejednoznaczny adres bind — każde odrzucane z nazwaną klasą, zamiast cofać się do słabszej postawy. Tam, gdzie kontrola jeszcze nie wymusza, dokumentacja mówi to wprost, a roadmapa ją nazywa.
Jak te wiersze mapują się na ISO 27001, ISO/IEC 42001, SOC 2, NIST AI RMF i EU AI Act →
Dwie drogi startu
Solo · prywatny preview
Team · design partner
Dokumentacja · tylko stan zaimplementowany
Saphan Docs powstaje na podstawie istniejącego kodu i zweryfikowanego zachowania produktu. Obejmuje wdrożenie, konfigurację, bezpieczeństwo, governance, audyt i operacje. Bez roadmapy. Bez obietnic.
Otwórz Saphan Docs ↗Nadzór jest gwarancją. Tak wygląda codzienna praca.
Praca zaczyna się od zlecenia: kompletnego briefu określającego zakres, ograniczenia i wymagane dowody. Silnik przekazuje go agentowi bez utraty kontekstu w historii czatu.
Agent zwraca raport, w którym każdemu twierdzeniu towarzyszy dowód. Czytasz wynik i analizujesz zmiany w kodzie, zamiast przeglądać pełny transkrypt rozmowy. To różnica liczona w godzinach.
Widok floty jest dostępny w VS Code: pokazuje aktywne zadania, elementy czekające na decyzję i komendę potrzebną do jej zapisania. Możesz zatwierdzić przejście przez bramkę bez opuszczania przeglądanego pliku.
Każdy projekt otrzymuje własny „most”: zlecenia, decyzje i wnioski zapisane jako zwykłe pliki w repozytorium Git. Studio dostarcza szablon, a baza kodu otrzymuje swoją strukturę pierwszego dnia. Zasady mają stałe miejsce, zanim ruszy pierwszy agent.
Jeden strumień, jeden identyfikator, te same liczby na każdym etapie. Materiał poniżej jest przykładem ilustracyjnym, nie zapisem produkcyjnym; nic tu nie jest zrzutem z systemu klienta.
Praca zaczyna się od samodzielnego briefu: co wchodzi w zakres, co nie i co liczy się jako dowód. Jeśli agent musi zgadywać, wadliwy był brief.
# ORDER — payments-refactor · wave 1 Stream: payments-refactor · Base: main @ 4f21c09 · Protocol: saphan-protocol v1.0 ## Scope (IN) PaymentProvider interface per ADR-0007 · three adapters · retries with idempotency keys — migration 0042, up AND down ## Proof standard build green · full suite as passed-of-total, skipped named · migration 0042 proven up + down on a schema copy · adapter parity: fixture diff empty · goldens untouched ## Stops STOP-2: full return before merge. Merge is human-only, from the gate.
Czytasz wyniki, nie transkrypty. Każda liczba niesie swoją definicję; sama liczba nie jest dowodem.
# RETURN — payments-refactor · STOP-2 Executor: agent-7 · Commits: 6 (head a3f9e12) · Base: main @ 4f21c09 1. PaymentProvider extracted; 3 providers behind one interface. → diff: 14 files (+612 −208) · goldens untouched 2. Retries are idempotent under duplicate delivery. → TestRetryIdempotency: 200 duplicate deliveries, 1 charge 3. Migration 0042 applied on a copy of the production schema. → up 1.2s · down: not run — see Open questions tests: 124 of 124 passed, 0 skipped · build: green
Zlecenie wymagało dowodu migracji w obie strony. Zwrot dowodzi jednej. Bramki nie da się przegadać.
$ saphan gate payments-refactor --gate stop-2 --actor marcin [refused] proof-standard-unmet — migration 0042: down path not proven owed: migration 0042 down · nothing advanced · the gate holds · nothing was merged
Agent dostarcza brakujący dowód na tym samym head. Decyzja jest osobnym aktem nazwanego człowieka. Ograniczona delegacja mogłaby tu rozstrzygnąć klasę niskiego ryzyka wyłącznie na mocy polityki podpisanej przez człowieka; ten strumień jej nie ma, więc bramka czekała na osobę.
# RETURN — payments-refactor · STOP-2 (amended, head a3f9e12) 3. Migration 0042 proven both ways on a copy of the production schema. → up 1.2s / down 0.9s · row counts identical pre and post $ saphan gate payments-refactor --gate stop-2 --actor marcin [recorded] stop-2 approved · actor: marcin · 2026-07-14 09:12 +07 evidence: build green · 124/124 tests, 0 skipped · diff 14 files (+612 −208) · migration 0042 up+down · bundle sha256:9f2c… authority: human owner · delegation: none in scope
Odmowa i zgoda to dwa wiersze. Podpis chroni integralność wiersza — te pola nie zostały później zmienione. Nie poświadcza, że testy były dobre ani że kod jest poprawny; do tego służą dowody, i to je człowiek przeczytał przed decyzją.
$ saphan gates payments-refactor refused stop-2 · actor: marcin · 09:04 +07 · proof-standard-unmet (migration 0042 down) approved stop-2 · actor: marcin · 09:12 +07 · evidence sha256:9f2c… · head a3f9e12 · authority: root merged observed on main @ 7b0e4d1 · 10:03 +07 · a human act in your Git, observed by the engine
Merge pozostaje aktem człowieka w Twoim narzędziu Git. Rejestr przechodzi do stanu merged dopiero po zaobserwowaniu commita merge na gałęzi bazowej — nigdy dlatego, że wywołanie API zwróciło sukces.
Pełne pliki stojące za tym przykładem — brief, zwrot, cytowany ADR, finding, sandbox i widok edytora:
# ORDER — payments-refactor · wave 1 From: master · To: one executor · Stream: payments-refactor Worktree: worktrees/payments-refactor · Base: main @ 4f21c09 Protocol: saphan-protocol v1.0 · pinned in PROTOCOL_BASELINE.md ## Context — read first The payments module calls three providers (stripe, adyen, in-house ledger) directly from checkout code. Retries are ad hoc; a network blip on 06-24 double-charged three orders (postmortem PM-12). ADR-0007 (attached below) ratified one provider interface at STOP-1. This stream implements it. Nothing here asks you to design — the design decisions are made and recorded; your job is the build. ## Scope IN: a. PaymentProvider interface exactly per ADR-0007 §Decision — the Charge/Refund signatures are frozen there; do not redesign them. b. Three adapters: stripe, adyen, ledger. Existing behavior is preserved; parity proven call-for-call against recorded fixtures in tests/fixtures/providers/. c. Retries with idempotency keys (key = order_id + attempt window), stored in pending_payments — migration 0042, up AND down. d. Wire pin W-2: the public /payments API is FROZEN. Golden tests in tests/golden/payments_test.go must pass untouched — if a golden blocks you, STOP and report; never edit a golden. OUT (recorded — do not touch): checkout UI · refund flows (wave 2) · provider timeout policy (carry-forward on ADR-0007). ## Proof standard build green · full suite, counts as passed-of-total with skipped named · migration 0042 proven up+down on a schema copy, row counts pre/post · adapter parity: fixture diff empty · goldens untouched (git diff --stat on tests/golden = empty) · diff summary per file ## Stops STOP-1 already passed (ADR-0007). STOP-2: full return per template before merge. Merge is human-only, from the gate. ## If blocked Write the blocker under "Open questions" in the return, flag the stream, stop. Guessing past ambiguity is a protocol violation, not initiative.
Brief jest kompletny aż do zamrożonych sygnatur: zawiera kontekst, kontrakty, wiążące decyzje interfejsowe i instrukcję na wypadek blokady. Jeżeli agent musi zgadywać, problem leży w zleceniu — dlatego nie pozostawiamy miejsca na domysły.
# RETURN — payments-refactor · STOP-2 Executor: agent-7 · Commits: 6 (head a3f9e12) · Base: main @ 4f21c09 ## Claims, with evidence 1. PaymentProvider extracted; 3 providers behind one interface. → diff: 14 files (+612 −208) · golden tests untouched, green 2. Retries are idempotent under duplicate delivery. → TestRetryIdempotency: 200 duplicate deliveries, 1 charge 3. Migration proven both ways on a copy of the production schema. → up 1.2s / down 0.9s · row counts identical pre and post ## Open questions for the gate Provider timeout is 30s, inherited. Keep or tighten? Out of scope — flagged, untouched. ## Not done Refund flows: out of scope per order (recorded — wave 2).
Każde twierdzenie wraca razem z dowodem. Raport można przeczytać w kilka minut zamiast analizować dwugodzinny transkrypt.
# ADR-0007 — one PaymentProvider interface; providers are adapters Status: accepted · Date: 2026-06-30 · Actor: marcin · Gate: STOP-1 ## Context Three providers are called directly from checkout code. Each has its own retry style and error mapping; the test surface triples; adding or swapping a provider means surgery on callers. Incident 06-24: a timeout retry double-charged three orders (postmortem PM-12). ## Decision One interface, signatures frozen: Charge(ctx, Order, IdempotencyKey) → (Receipt, error) Refund(ctx, ReceiptRef, Amount) → (Refund, error) Providers become adapters behind it. Error taxonomy unified as retryable / terminal / unknown — the mapping is owned by each adapter and may not leak provider-specific errors upward. ## Consequences + one contract to test; parity provable against recorded fixtures + retries live in one place, above the adapters — idempotency enforced at a single seam, not three − adapters gain a lint rule: no provider error types cross the seam − migration 0042 required for idempotency-key storage ## Considered and passed Per-provider services — triples the test surface, scatters retry logic. Feature flags per provider — hides the seam from the record. ## Carry-forward Timeout inherited at 30s. Decide at wave 2 — trigger: refund flows.
Dokument zawiera kontekst incydentu, który wymusił decyzję, zamrożone sygnatury, konsekwencje — także negatywne — oraz odrzucone warianty z uzasadnieniem. Zlecenie odwołuje się do ADR-u, więc decyzja faktycznie steruje pracą, a nie pełni roli dekoracji.
# Finding 4.2 — a number without a definition is not evidence Seen: a return claimed "tests: 124 passed" while 9 were skipped. The count was true and the claim was false. Rule: every number in a return carries its definition — passed of total, skipped named and justified. Applied: same cycle. All return templates updated; the gate now asks for the definition when a bare number appears.
Niepowodzenie staje się nową regułą w tym samym cyklu, w którym je wykryto. Protokół jest zbiorem sprawdzonych precedensów, nie jednorazowym manifestem.
# The sandbox — how the pieces talk you — the operator │ briefs out · gates · reads returns ▼ editor / CLI (VS Code panel · saphan) │ ▼ saphan engine — self-hosted │ dispatch · fleet projection · refusals ▼ worktrees — one isolated sandbox per stream ├─ agent-3 payments-refactor running, wave 1 ├─ agent-7 atrisk-push stop-2 — awaiting you └─ agent-12 notification-svc merged, observed │ ▼ the bridge — plain files in your git orders · returns · ADRs · findings · gate log │ ▼ main — merge is human-only The protocol is the language every arrow speaks. The record is what every arrow leaves behind.
Agenci działają w izolacji, każdy w osobnym worktree. Silnik komunikuje się w obu kierunkach za pomocą protokołu, a każdy etap pozostawia ślad w pliku. Nic istotnego nie dzieje się poza rejestrem.
Z poziomu edytora wybierasz strumień prac, sprawdzasz dowody i podejmujesz decyzję na bramce — bez opuszczania aktualnego pliku.
Każde zlecenie, zwrot, werdykt review, decyzja bramki, wiersz kosztu i obserwacja merge są już w rejestrze. Dokumentacja procesu i raporty delivery to projekcje tego rejestru — generowane, nie pisane. Każda liczba prowadzi do podpisanego wiersza lub zacommitowanego dokumentu, a czytelnik weryfikuje skrót, zanim czyta.
Co pociąg dostarcza i czego odmawia — cytowane ze zlecenia; generator nie parafrazuje mandatu. Decyzje, na których się oparł. Jedna sekcja na wagon: przesłanka, dowód, czego nie wolno, i liczby, które zwróciła noga. Jak to sprawdzono — klasa review, rundy, co zmieniło każde odrzucenie, cytowane z werdyktu. Jak wylądowało — oś czasu podpisanych wierszy bramek aż do commita merge. Co zostawiło po sobie, księga kosztów z klasą rozliczeniową i załączniki: każdy dokument źródłowy ze swoim skrótem. Profil ujawniania decyduje, co kopia publiczna pomija — nazwy hostów i seatów zastąpione klasą, koszt pominięty — i nazywa to, co pominęła.
Delivery, bramki, koszt, pociągi, przepływ, pojemność, testy, defekty, prawa, audyt compliance i metryki — za wybrany okres: scalone wagony i czyją ręką, odsetek przejść za pierwszym razem i rundy na wagon, wycena wobec wykonania wobec limitu z klasą rozliczeniową przy każdej liczbie, burndown i przepływ kumulatywny per pociąg, czas cyklu i gdzie poszły godziny — noga, czekanie na review, czekanie na właściciela, merge. Każda plansza nazywa tabelę, z której czyta, i liczby, których jeszcze mieć nie może; liczba bez źródła nie jest drukowana.
Jak to wygląda — podgląd z konsoli:
Generator drukuje odczyty z rejestru i odmawia wymyślania: wagon scalony nie jest wagonem wydanym, i rozdział mówi to we własnym nagłówku.
Ekrany dokumentacji i raportów wchodzą z buildem enterprise; konsola nie jest jeszcze publiczna. Ta strona powie „dostarczone”, gdy zostaną dostarczone — nie wydanie wcześniej.
Człowiek nie jest klikaczem ani zwykłym uczestnikiem procesu. Jest jego właścicielem: wyznacza kierunek, określa zakres władzy przekazanej flocie i pozostaje odpowiedzialny za rezultat. Tak właśnie nazywa go sama flota — human owner.
Wymagania zmieniają się w trakcie projektu. Zmiana wykryta na bramce oznacza korektę jednego strumienia, a nie wyrzucenie tygodnia pracy całej floty. To najtańszy moment na zmianę kierunku, zanim błąd rozprzestrzeni się na kolejne zadania.
„Wyjaśnij mi to, zanim zatwierdzę.” Operator nadąża za systemem, zamiast podpisywać decyzję w ciemno. Raport z wykonania ma skrócić ten proces do kilku minut, a nie całego popołudnia. Zatwierdzasz świadomie albo nie zatwierdzasz wcale.
Na pytanie „dlaczego tak, a nie inaczej?” odpowiadają dokumenty: ADR-y oraz warianty rozważone i odrzucone. Nie trzeba polegać na czyjejś pamięci decyzji sprzed tygodni. Uzasadnienie trafia do rejestru, zanim ktokolwiek o nie zapyta.
Ograniczona delegacja — nigdy ukryty autopilot
Właściciel może podpisać nazwaną politykę, która deleguje jawnie określone klasy decyzji niskiego ryzyka nazwanemu aktorowi automatycznemu. Delegacja ma własny zakres, uprawnienie i pochodzenie. Poza tym zakresem bramka nadal czeka na człowieka; samo podanie modelu jako aktora nie nadaje mu uprawnień.
Uprawnienie człowieka jest korzeniem. Automatyzacja może korzystać wyłącznie z ograniczonego uprawnienia jawnie podpisanego przez człowieka, a rekord zachowuje ten łańcuch dla każdej decyzji.
Organizacja zatrudniająca pięćdziesięciu inżynierów nie powinna płacić za najbardziej zaawansowany model, gdy zadanie lepiej wykona skrypt. Reguła routingu jest prosta: wybierz najtańszego wykonawcę, który nadal spełnia wymagany standard dowodowy.
Budowanie aplikacji iOS, uruchomienie testów czy pakowanie rezultatów to zadania dla narzędzi, nie rozmowy z modelem. W protokole są wykonawcami tak samo jak agenci: otrzymują zlecenie, zwracają dowody i pozostawiają ten sam ślad w rejestrze. Nie zużywasz tokenów na pracę, którą toolchain wykona lepiej.
Modele uruchamiane we własnej infrastrukturze, dostępne przez ten sam interfejs wykonawcy, obsługują powtarzalne prace: migracje według wzorca, streszczenia i generowanie szkieletu kodu. Twój sprzęt, Twoje dane i koszt energii zamiast opłat za tokeny.
Claude Code, OpenAI Codex, Qwen Code, Factory Droid albo model uruchamiany przez Saphan Agent-Loop jest rezerwowany przez politykę do zadań, które naprawdę go wymagają: projektowania, trudnego debugowania i przeglądu. Polityka jest wersjonowanym plikiem tworzonym przez zespół, nie domyślnym ustawieniem wybranym bez decyzji.
Rejestr wskazuje wykonawcę każdego strumienia prac. Przypisanie kosztu jest częścią kontraktu, nie późniejszym szacunkiem. Koszt znajduje się obok dowodów dla konkretnego strumienia i bramki, dlatego pytanie „ile kosztowała ta zmiana?” ma równie prostą odpowiedź jak „kto ją zatwierdził?”
Koszty powstają dziś w dwóch miejscach: inżynierowie korzystają z agentów w CLI w ramach licencji abonamentowych, a zautomatyzowane procesy zużywają tokeny rozliczane przez API. Bez wspólnego mechanizmu trudno je przypisać. Saphan obejmuje oba modele tym samym kontraktem: jedno zlecenie na wejściu, te same dowody na wyjściu i jeden rejestr — niezależnie od tego, czy wykonawcą jest interaktywna sesja CLI, czy automatyczne wywołanie API. Koszt przestaje być rozdzielony między dwie nieporównywalne faktury.
Warstwa routingu działa dziś w naszym środowisku: jedna polityka obejmuje wykonawców od lokalnego serwera modeli po zewnętrzne API najbardziej zaawansowanych modeli, a agenci sterowani z CLI już pracują pod kontrolą Saphan. Automatyczny wariant API korzysta z tego samego kontraktu. Moduł kosztowy finalizujemy z partnerami pilotażowymi; mechanizm przypisywania kosztu jest już częścią kontraktu.
Routing określa, gdzie powinna trafić dana klasa zadań. Bench mierzy, jakie obciążenie rzeczywiście obsłuży Twoja maszyna — dzięki czemu decyzja opiera się na danych, a nie założeniach. Różnica między nimi bywa duża i nie da się jej wiarygodnie przewidzieć bez pomiaru.
$ saphan-verdict [verdict] class-120b — 120.99 GiB addressable · hot + large fit co-resident → note: glm-4.5-air rejected — dominated by gpt-oss-120b on this class [critical] addressable memory is 63.3 of 125.5 GiB installed — raise the ceiling
Bezpłatny test niczego nie instaluje i nie wysyła danych na zewnątrz. Raportuje pamięć dostępną dla GPU, nie tylko zainstalowany RAM. Na maszynie referencyjnej różnica obejmowała niemal połowę pamięci, dlatego ocena dopasowania zawsze opiera się na niższej wartości.
W pomiarze czterech modeli na jednym węźle z 128 GB pamięci model GLM-4.5-Air — flagowy kandydat, którego łatwo byłoby wybrać bez testu — okazał się 2,1 raza wolniejszy zarówno przy przetwarzaniu promptu, jak i generowaniu tokenów od gpt-oss-120b i wymagał o 10 GiB więcej pamięci. Karta modelu nie pokaże tej różnicy, bo nie opisuje Twojej konkretnej maszyny.
Wszystko, co już masz, zachowuje swoją rolę. Saphan przejmuje jedno zadanie: moment, w którym wynik pracy agenta staje się zmianą oprogramowania, za którą ktoś musi odpowiedzieć.
Frontierowe API i modele lokalne za endpointami zgodnymi z OpenAI, jak Ollama czy vLLM, to tory, na które Saphan kieruje pracę według wersjonowanej polityki. Obsługa wielu modeli to kwestia routingu; to nie to samo, co zarządzanie gotowym agentem kodującym.
Claude Code, OpenAI Codex, Qwen Code, Factory Droid i własny Agent-Loop Saphan działają jako wysyłane, izolowane per seat backendy — bez adaptera frameworka, bez SDK do osadzenia. Kontrakt jest mały: odebrać samodzielne zlecenie, pracować w izolowanym worktree, zwrócić twierdzenia z dowodem.
LangGraph, CrewAI, Microsoft Agent Framework i A2A to osobna warstwa integracji, nie runtime’y agentów kodujących. Kontrakt adaptera jest określony; poszczególne adaptery powstają z design partnerami w kolejności realnych potrzeb i żaden nie jest przedstawiany jako dostarczony.
Saphan nigdy nie pisze do Twojego repozytorium. Obserwuje commity, gałęzie i merge przez granicę tylko do odczytu; merge pozostaje aktem człowieka w Twoim narzędziu. Bramka dociera do samego forge — wymagany status i dokładny head pull requesta — jak to działa →
Admisja maszyn, uruchomienia w sandboxie, zlecenia na zewnątrz i zwroty z dowodami do wewnątrz, bramki człowieka z ograniczoną delegacją oraz podpisany rejestr — ponad frameworkami, prostopadle do pakietów AI governance, które obserwują modele i dane z góry. Zmień stos agentów; płaszczyzna upoważnień zostaje.
Metoda nie jest zamknięta w narzędziu. Saphan Protocol to wersjonowany, czytelny dla człowieka zestaw zasad egzekwowanych przez silnik: zlecenia, bramki decyzyjne, wymagania dowodowe i rejestry decyzji. Protokół jest stale doskonalony na podstawie pracy naszych własnych flot.
Maszyny go wykonują, a audytorzy i inżynierowie mogą go po prostu przeczytać. Wersja 1.0 zostanie opublikowana wraz z publicznym wydaniem.
Saphan po tajsku znaczy „most” — สะพาน. Buduję produkt w Hua Hin w Tajlandii, a znak na tej stronie przedstawia most Ramy VIII w Bangkoku: pojedynczy pylon na jednym brzegu utrzymuje pomost za pomocą wyraźnie widocznych lin. W tej konstrukcji nic nie jest ukryte — można prześledzić każdą siłę i zobaczyć, co przenosi obciążenie. To trafna metafora produktu: praca przechodzi na drugą stronę, nic nie znika po cichu i zawsze wiadomo, co utrzymało decyzję.
Jest też głębszy powód. Przez lata pracy z infrastrukturą widziałem systemy, które zawodziły w tym samym miejscu — nie w samym kodzie, lecz podczas przekazania pracy z jednej strony na drugą. Później nikt nie potrafił powiedzieć, kto ją dopuścił ani dlaczego. Agenci nie stworzyli tego problemu; zwielokrotnili go ponad możliwości ludzkiej pamięci. Narzędzie nosi więc nazwę brakującego elementu: nie muru ani bramki istniejącej dla samej kontroli, lecz mostu, który pamięta każde przejście.
Protokół i silnik działają produkcyjnie w naszych projektach. Saphan jest rozwijany przy użyciu własnego protokołu i własnej floty.
Publiczne wydanie będzie udostępniane etapami; protokół v1.0, silnik i pakiet audytowy zostaną opublikowane razem.
Wybieramy 2–3 partnerów pilotażowych — zespoły liczące 50–500 inżynierów, z realnymi obowiązkami regulacyjnymi i audytowymi.
Mechanizm stojący za rejestrem jest objęty zgłoszeniem patentowym w USA.
Polska — IP Partner, Warszawa. IP Partner reprezentuje Saphan w Polsce: pierwsza rozmowa po polsku, wdrożenie na Waszej infrastrukturze i lokalny zespół dla organizacji, które wprowadzają agentów AI do inżynierii objętej regulacjami. Kontakt: Łukasz Bederski, MBA, Founder — strona partnera · ippartner.pl · LinkedIn.
Chcesz reprezentować Saphan na swoim rynku? [email protected]
Tempo pracy agentów przekracza możliwości przeglądu. Pull requesty się piętrzą, a przegląd kodu staje się formalnością. Jednocześnie klienci enterprise i audytorzy pytają, kto nadzoruje zmiany wprowadzane przez agentów. Odpowiedź „spojrzał na to senior” nie rozwiązuje żadnego z tych problemów.
Zespół pilotażowy pracuje tą metodą na co dzień: zlecenia trafiają do agentów, wracają raporty z dowodami, a decyzje na bramkach są podejmowane w edytorze. Repozytorium otrzymuje własną strukturę procesu pierwszego dnia, zanim ruszy pierwszy agent.
Dodatkowa korzyść audytowa: skoro każda zmiana zawiera już dowody i zapisaną decyzję, odpowiedź na kwestionariusz bezpieczeństwa staje się gotowym dokumentem, a nie improwizowanym akapitem.
Zespół sprzedaży otrzymuje komunikat, który może przedstawić klientom i poprzeć dowodami: „nasze floty AI podlegają audytowalnej warstwie autoryzacji”. To zaufanie, które można udokumentować.
Jeden zespół i jedno repozytorium. Wdrożenie jest prowadzone osobiście przez założyciela, a pierwsze bramki działają na rzeczywistej pracy już w pierwszym tygodniu. Saphan działa w całości we własnej infrastrukturze, więc kod nie trafia do nowego zewnętrznego systemu. Zaangażowanie zespołu: około godziny tygodniowo. Brak opłat licencyjnych przez cały pilotaż. Możesz zakończyć współpracę w dowolnym momencie i zachować wszystkie dane oraz pliki.
Rejestr składa się ze zwykłych plików w Twoim repozytorium Git i pozostaje czytelny bez naszych narzędzi. Saphan Protocol v1.0 zostanie opublikowany otwarcie, dlatego zespół zachowuje wypracowane zasady nawet bez dostawcy. System uruchomiony u Ciebie nadal działa. Brak uzależnienia od dostawcy wynika z architektury, a nie z deklaracji.
Twoje przypadki brzegowe stają się uogólnionymi regułami protokołu — bez ujawniania wewnętrznych szczegółów. Napotkane tarcia wyznaczają plan rozwoju, a wariant Team — bramki na poziomie organizacji, wspólny widok floty i widoki audytowe — powstaje z uwzględnieniem realiów Twojej organizacji. Pierwsi partnerzy otrzymują preferencyjne warunki na piśmie przed publikacją cennika.
Współpraca pilotażowa
Skontaktuj się z nami — [email protected]