„Koszary" to baza szkoleniowa i katalog kompetencji, nie jednostka bojowa: kto z agentów analitycznych K0NSULT co potrafi, jak łączy się ich w roje dla skuteczności i jakie ćwiczenia (drille) sprawdzają, czy dowód faktycznie wytrzymuje weryfikację. Doktryna claim ≤ proof obowiązuje identycznie jak wszędzie indziej w tym portalu.
„Koszary agentów" to szkolna metafora dla czegoś prostszego: rejestru narzędzi analitycznych K0NSULT (agentów uruchamianych w sesjach Claude Code) razem z opisem, w jaki sposób łączy się je w większe zespoły (roje/workflow) oraz jak sprawdza się, że efekt ich pracy jest wart zaufania (ćwiczenia/drille). Nie ma tu jednostek bojowych, broni ani zdolności ofensywnej — jest procedura pracy analitycznej z wbudowaną weryfikacją. Każdy element poniżej jest oznaczony jako LIVE (realne narzędzie z kodem, dostępne operatorowi w sesji) albo model (opisany i przećwiczony na scenariuszu syntetycznym) — bez mieszania tych dwóch kategorii.
Siedem agentów pojedynczych używanych dziś w pracy nad portalem ipIII i repozytorium K0NSULT. Każdy ma wąską specjalizację — łączenie ich w roje (niżej) jest tym, co daje skuteczność, nie pojedynczy agent działający solo na złożonym zadaniu.
| Agent | Rola | Umiejętność główna | Kiedy uruchomić |
|---|---|---|---|
| ip3-page-builder | budowniczy stron | tworzy pojedynczą stronę HTML wg wzorca portalu (style/header/footer, subnav, badge statusu), pilnuje zero-overclaim i braku inline JS | nowa strona /ai-truth/ipIII/*, wymagany lint po zapisie |
| ip3-corpo-doc | dokumentalista | pisze treści korporacyjne/marketingowe (wartość, oferta, business case) w spójnym tonie i rejestrze języka | materiały B2B, karty produktowe, komunikacja do partnerów |
| ip3-connector-builder | integrator | buduje konektory/parsery (np. wyniki skanerów, webhook ingestion) razem z testami jednostkowymi i integracyjnymi | nowe źródło danych evidence, integracja narzędzia zewnętrznego |
| general-purpose | analityk uniwersalny | wieloetapowe wyszukiwanie, research w kodzie, zadania bez wąskiej specjalizacji, gdy ścieżka nie jest jeszcze jasna | zadania rozproszone po repo, niepewny zakres na starcie |
| Explore | zwiadowca (read-only) | szybkie mapowanie stanu repo/API bez żadnej modyfikacji — rekonesans przed decyzją | przed planem, przed audytem istniejącego kodu |
| Plan | planista | rozkłada złożone zadanie na kroki, szacuje ryzyko, przygotowuje bramkę ACK przed egzekucją | zadania >10 min, nieodwracalne lub wieloetapowe |
| code-reviewer | recenzent | wykrywa błędy i luki w diffie, sprawdza zgodność ze standardem repo, weryfikuje pokrycie testami | przed commitem/merge, po wygenerowaniu kodu przez innego agenta |
Pojedynczy agent na złożonym zadaniu ma wąskie pole widzenia. Skuteczność rośnie, gdy agentów łączy się w jeden z dwóch wzorców pracy — i domyka wynikiem weryfikowanym przez trzeci mechanizm.
Każdy krok zależy od wyniku poprzedniego: Explore → Plan → ip3-connector-builder →
code-reviewer. Dobry, gdy zadania są od siebie zależne i kolejność ma znaczenie (np. najpierw
rekonesans, potem projekt, potem implementacja, na końcu recenzja przed commitem).
N niezależnych agentów tego samego typu pracuje na rozłącznych plikach/zadaniach jednocześnie (np. N stron portalu budowanych naraz przez N instancji ip3-page-builder) — zero kolizji, bo każdy dostaje osobny plik. Dobry, gdy zadania są od siebie niezależne.
Po pipeline'ie lub roju wynik nie jest przyjmowany automatycznie: panel niezależnych ocen próbuje obalić twierdzenie (nie potwierdzić na skróty). Przechodzi dopiero, gdy większość nie zdoła go obalić (threshold). To brama jakości, nie formalność.
Ćwiczenie w tym kontekście nie oznacza symulowania ataku na cudzy system — oznacza procedurę weryfikacyjną uruchamianą na własnej pracy, zanim trafi ona dalej (do repo, do raportu, do operatora). Opisujemy tu wyłącznie co jest testowane i jaki dowód liczy się jako sukces — nigdy sposobu wykonania ataku.
Co testowane: czy rola obronna (code-reviewer, completeness-critic) wykrywa lukę wprowadzoną celowo do scenariusza syntetycznego przez rolę „adwersarza" (bez realnego payloadu — zmiana logiczna w danych testowych). Dowód sukcesu: finding zapisany z lokalizacją i uzasadnieniem, zanim trafi do produkcji.
Co testowane: czy każde twierdzenie (claim) w raporcie/stronie ma faktyczny dowód (kod, test, link, hash), a nie tylko deklarację. Dowód sukcesu: lista pominięć/gapów oznaczonych jawnie jako ROADMAP, zero „domykania na słowo".
Co testowane: czy wniosek przetrwa próbę obalenia przez kilka niezależnych ocen (judge-panel). Dowód sukcesu: ≥3 z 4 niezależnych ocen nie znajduje kontrargumentu podważającego finding.
| Agent | Umiejętność kluczowa | Najsilniejszy w |
|---|---|---|
| ip3-page-builder | budowa strony wg wzorca, zero kolizji plików | rój równoległy — N stron portalu budowanych jednocześnie |
| ip3-corpo-doc | spójny ton i rejestr językowy | pipeline: brief → szkic → recenzja tonu |
| ip3-connector-builder | parser/integracja z testami | pipeline: specyfikacja → kod → testy → włączenie do orkiestratora |
| general-purpose | szerokie zadania wieloetapowe | pipeline sekwencyjny z punktami kontrolnymi (checkpointy) |
| Explore | rekonesans repo/API bez modyfikacji | pierwszy krok każdego pipeline'u, przed Plan |
| Plan | rozkład zadania, ocena ryzyka, bramka ACK | brama otwierająca każdy większy rój lub pipeline |
| code-reviewer | wykrywanie błędów/luk w diffie | ostatni krok pipeline'u — brama przed commitem |
Judge-panel i completeness-critic (opisane szerzej na zbrojowni skilli) działają jako meta-warstwa nad każdym rojem/pipeline'em powyżej — nie zastępują żadnego z siedmiu agentów, tylko weryfikują ich wspólny wynik.
„Trening" agenta w tym modelu nie oznacza uczenia nowych zdolności ofensywnych — oznacza ewaluację procedury: czy agent aktywuje się na właściwy wyzwalacz, czy jego wynik jest powtarzalny między uruchomieniami, i czy przechodzi bramkę weryfikującą (judge-panel/completeness-critic) zanim trafi dalej. Gotowość mierzymy dowodem, nie deklaracją: liczbą przechodzących testów jednostkowych/integracyjnych, liczbą stron/konektorów przepuszczonych przez lint bez findingu, liczbą drilli zakończonych zapisanym dowodem sukcesu. Nowy agent trafia do „koszar" (czyli do realnego użycia w pracy nad repo) dopiero po przejściu tej samej ścieżki co skille: projekt → ewaluacja trafności wyzwalacza → wdrożenie.
W tym modelu „znać siebie" oznacza rzetelny rejestr własnych agentów, ich rzeczywistych umiejętności i granic (ta strona + znane ograniczenia). „Znać przeciwnika" oznacza rozumienie typowych kategorii wzorców zagrożeń z literatury (taktyki, nie instrukcje wykonania) — wyłącznie w celu rozpoznania i budowy obrony, nigdy replikacji. Żadna część tej strony nie zawiera i nie będzie zawierać instrukcji wykonania ataku, exploitów ani payloadów.
Na potrzeby ćwiczenia klasyfikujemy zagrożenia wyłącznie jako kierunki techniczne modelowe (np. „wektor sieciowy zewnętrzny", „wektor łańcucha dostaw", „wektor tożsamości/dostępu", „wektor aplikacyjny") — kategorie znane z ram takich jak MITRE ATT&CK, opisane na poziomie taktyki, nie konkretnego aktora. Ta strona świadomie nie przypisuje żadnego scenariusza konkretnemu państwu, grupie ani podmiotowi — atrybucja wymaga formalnego dochodzenia właściwych służb, nie modelu ćwiczebnego w tym repozytorium. Wszelkie „kierunki geograficzne" wspominane w materiałach szkoleniowych K0NSULT są uproszczeniem edukacyjnym, nie deklaracją polityczną ani wywiadowczą.
Powiązane: model sztabu i stanów gotowości → /sztab-obrony · arsenał skilli analitycznych → /zbrojownia-skilli · rejestr znanych ograniczeń → /known-limitations · zasady zaangażowania → /engagement.