10X WORKFLOW // MODUŁ 4 // 5 LEKCJI

MODUŁ 4 // LEGACY

Decyzje architektoniczne: dowody zamiast intuicji

Legacy w 10x Workflow otwiera blok 10xArchitect: pięć lekcji buduje 5-elementowy raport architektoniczny - od architektury kontekstu po okazje DDD. Raport ma być Twój - obronialny, nie przyjęty na wiarę. To obszar, którego niemal żaden kurs AI nie rusza.

Skrót modułu · pięć lekcji w 30 sekund

„Decyzje architektoniczne z dowodów, nie z intuicji."

- fundament 10x Workflow
LEKCJA 01 Diuna · Filtrfrak

Skalowanie kontekstu - ile kontekstu naraz uniesie agent?

„Filtrfrak nie oddaje pustyni ani kropli. Woda krąży w zamkniętym obiegu i wraca dokładnie tam, gdzie jest potrzebna - kto wylewa zapas na piach, nie zobaczy siczy."

- mistrz destylarni, nauka przy pierwszym filtrfraku
ZBIORNIK: CAŁY KONTEKST CONTEXT/ = SYSTEM-OF-RECORD ZAWÓR OKNO AGENTA: TYLKO TA DAWKA ANI KROPLI NA PIACH
RYS. 01 // ZAWÓR RACJONUJE: DAWKA KONTEKSTU POD ZADANIE

Fremen nie pyta, ile wody ma pustynia - pyta, ile wody potrzebuje najbliższy marsz. Filtrfrak działa, bo racjonuje: zamknięty obieg oddaje ciału dokładnie tyle, ile trzeba teraz. Kontekst agenta to ta sama ekonomia. Pytanie w legacy nie brzmi „co agent ma wiedzieć?", tylko „co agent ma wiedzieć TERAZ?" - okno kontekstu jest zasobem jak woda na pustyni, a wylany zapas nie wraca.

Wejście: repozytorium z kontekstem rozlanym po README, wiki i głowach ludzi. Wyjście: lean root AGENTS.md plus context/ jako system-of-record - fakty o architekturze mieszkają w plikach, które agent dociąga na żądanie, nie w jednym przeładowanym prompcie. Mechanizm: drabina dojrzałości - od zera do systemu, w którym każda dawka kontekstu ma swoje miejsce i swój moment podania.

GRUNT: PARNAS 1972 // MODUŁ UJAWNIA MINIMUM - Z KONTEKSTEM TAK SAMO

Pytanie
ile kontekstu naraz uniesie agent?
Gwarancja
kontekst racjonowany, nie wylewany
Artefakt
lean AGENTS.md + context/ jako system-of-record
Narzędzia
AGENTS.md lean root, context/ foundation, drabina dojrzałości
CEL:

kluczowy, zanim agent dotknie legacy - okno kontekstu to zasób racjonowany: dawka pod zadanie zamiast wylania wszystkiego naraz.

LEKCJA 02 Star Wars · Sondy zwiadowcze

Mapa projektu - jak wygląda teren, zanim wejdziesz?

„Flota nie ląduje na nieznanej planecie. Najpierw idą sondy - każda skanuje swój sektor i odsyła pomiar. Dowódca czyta mapę, nie patrzy przez iluminator."

- oficer zwiadu, odprawa przed desantem
BAZA SONDY: GIT LOG // GRAF ZALEŻNOŚCI // STRUKTURA MAPA: DEEP VS SHALLOW CORE VS PERIPHERAL // LOAD-BEARING
RYS. 02 // SONDY WRACAJĄ Z MAPĄ MODUŁÓW

Flota nie ląduje na nieznanej planecie na ślepo - najpierw lecą sondy zwiadowcze, każda skanuje swój sektor, a dowódca patrzy na złożoną z pomiarów mapę, nie przez iluminator. Mapa projektu to ten sam zwiad: wide scan, zanim postawisz stopę w kodzie. Struktura folderów kłamie - mapa ma powstać z dowodów: historii gita, wyszukiwań strukturalnych, grafów zależności.

Wejście: nieznane repozytorium. Wyjście: mapa projektu (pozycja ① raportu) - które moduły są deep, a które shallow, co jest core, co peripheral, co jest load-bearing. Mechanizm: równoległe sondy - /10x-research wysyła subagentów, git log i churn pokazują, gdzie projekt naprawdę żyje, a graf zależności - co się zawali, gdy pociągniesz nitkę.

GRUNT: OUSTERHOUT // DEEP VS SHALLOW - GŁĘBOKOŚĆ MODUŁU, NIE JEGO ROZMIAR

Pytanie
jak wygląda teren, zanim wejdziesz?
Gwarancja
mapa z dowodów, nie z folderów
Artefakt
mapa projektu - pozycja ① raportu
Narzędzia
/10x-research, git log/blame/churn, madge, dependency-cruiser
CEL:

kluczowy przy wejściu w cudzy albo stary kod - najpierw mapa z dowodów, dopiero potem pierwszy krok w teren.

LEKCJA 03 The Expanse · Detektyw na Ceres

Feature i hot spots - gdzie kod pęka najczęściej?

„Na Ceres nie patroluję ciemnych korytarzy. Chodzę tam, gdzie zbrodnia była już trzy razy - ona wraca w te same miejsca."

- detektyw stacji Ceres, notatki ze śledztwa
ŚLADY ZMIAN WRACAJĄ W TE SAME MIEJSCA HOT SPOT CHANGE COUPLING: CO ZMIENIA SIĘ RAZEM HOT SPOT = ZŁOŻONOŚĆ × CZĘSTOŚĆ ZMIAN
RYS. 03 // ZBRODNIA WRACA W TE SAME MIEJSCA

Detektyw na Ceres nie patroluje całej stacji - wraca tam, gdzie zbrodnia była już trzy razy. Kod pęka według tego samego wzorca: awarie nie rozkładają się równo po repozytorium, wracają w te same miejsca. Hot spot to skrzyżowanie dwóch dowodów: złożoności kodu i częstości zmian - tam, gdzie skomplikowane spotyka często dotykane, ryzyko rośnie najszybciej.

Wejście: mapa projektu i jeden feature. Wyjście: przegląd feature'a + hot spots (pozycje ② i ③ raportu) - przepływ danych end-to-end jednego modułu plus lista miejsc, które pękają najczęściej. Mechanizm: deterministyczne CLI domyka semantykę - ast-grep znajduje wzorce w składni, code-maat liczy change coupling, a observability dokłada dowody z produkcji; agent interpretuje, ale pomiar jest maszynowy.

GRUNT: TORNHILL // KOD JAK MIEJSCE ZBRODNI - ZŁOŻONOŚĆ × CZĘSTOŚĆ ZMIAN

Pytanie
gdzie kod pęka najczęściej?
Gwarancja
ryzyko wskazane z dowodów, nie z vibes
Artefakt
przegląd feature'a + hot spots - pozycje ② i ③ raportu
Narzędzia
ast-grep, code-maat (change coupling), Sentry/observability
CEL:

kluczowy przed każdą decyzją o refaktorze - ryzyko wskazują dowody: złożoność × częstość zmian, nie przeczucie.

LEKCJA 04 Warhammer 40k · Świątynia-maszyna

Refaktor odwracalny - jak przebudować bez zatrzymywania maszyny?

„Ducha maszyny nie gasimy nigdy. Wyjmij jeden moduł, wstaw nowy, odpraw rytuał powrotu. Jeśli maszyna zamilknie - cofnij krok, nie plan."

- magos odbudowy, litania wymiany podzespołu
DUCH MASZYNY: NIE GAŚNIE RYTUAŁ POWROTU = TEST STRANGLER FIG // MIKADO // ADR KROK CZERWONY → COFNIJ KROK, NIE PLAN
RYS. 04 // WYMIANA MODUŁU BEZ GASZENIA MASZYNY

Świątyni-maszyny nie gasi się nigdy - odbudowa idzie modułem po module: wyjmij jeden podzespół, wstaw nowy, odpraw rytuał powrotu i dopiero wtedy sięgnij po następny. Refaktor legacy to ta sama liturgia: odwracalna ścieżka zamiast big-bangu. Wielki przepisujący skok kończy się katastrofą, bo nie ma z niego drogi powrotu - sekwencja małych, osobno zielonych kroków ma ją zawsze.

Wejście: hot spot z dowodami i test chroniący zachowanie - napisany, zanim ruszy refactor. Wyjście: okazje refaktorowe (pozycja ④ raportu) plus ADR-y dokumentujące decyzje. Mechanizm: wzorce odwracalności - Strangler Fig (nowe oplata stare, zanim je zastąpi), Branch by Abstraction, metoda Mikado - a /10x-plan tnie ścieżkę na fazy, z których każda kończy się zielenią albo cofnięciem kroku, nie planu.

GRUNT: FOWLER + FEATHERS // TEST CHRONIĄCY ZACHOWANIE POWSTAJE PRZED REFAKTOREM

Pytanie
jak przebudować bez zatrzymywania maszyny?
Gwarancja
każdy krok odwracalny i osobno zielony
Artefakt
okazje refaktorowe - pozycja ④ raportu + ADR-y
Narzędzia
/10x-plan, ADR, metoda Mikado, Strangler Fig
CEL:

kluczowy, gdy system musi działać w trakcie przebudowy - każdy krok odwracalny i osobno zielony, big-bang zostaje w koszu.

LEKCJA 05 Fundacja · Model domeny

DDD z agentem - czy model mówi językiem domeny?

„Model przewiduje zachowanie całej domeny - pod jednym warunkiem: pojęcia muszą być ostre. Jedno rozmyte słowo w równaniu i plan rozjeżdża się o stulecia."

- wykład wstępny, katedra psychohistorii
POJĘCIA: ROZMYTE MODEL KONTEKST: MAGAZYN KONTEKST: PŁATNOŚCI JEDEN JĘZYK W KAŻDYM KONTEKŚCIE
RYS. 05 // CHAOS POJĘĆ → OSTRE GRANICE KONTEKSTÓW

Psychohistoria przewiduje zachowanie całej domeny jednym modelem - ale tylko dlatego, że jej pojęcia są ostre. Jedno rozmyte słowo w równaniu i predykcja rozjeżdża się o stulecia. Model domeny w kodzie podlega temu samemu prawu: bounded contexts działają, gdy granice są ostre, a język jednoznaczny - „zamówienie" w magazynie i „zamówienie" w płatnościach to dwa różne pojęcia i mają prawo mieć dwa różne modele.

Wejście: chaos pojęć zastanej domeny. Wyjście: okazje DDD (pozycja ⑤ raportu) - kandydaci na bounded contexts, glosariusz ubiquitous language, inwarianty, podział na entities i value objects. Mechanizm: AI jako coach DDD - agent prowadzi Event Storming, proponuje granice i nazwy, ale to człowiek broni każdej decyzji; model, którego zespół nie potrafi obronić, nie jest modelem, tylko notatką.

GRUNT: EVANS // UBIQUITOUS LANGUAGE - JEDEN JĘZYK OD ROZMOWY PO KOD

Pytanie
czy model mówi językiem domeny?
Gwarancja
granice i język, których zespół potrafi bronić
Artefakt
okazje DDD - pozycja ⑤ raportu + glosariusz
Narzędzia
Event Storming, glosariusz ubiquitous language, bounded contexts
CEL:

kluczowy, gdy model ma przeżyć dłużej niż sprint - granice i język, których zespół potrafi bronić, przetrwają rotację ludzi i agentów.

DALEJ Po 10xBuilderze · 10xArchitect otwarty

Dalej: 10xArchitect otwarty

BLOK 10XBUILDER // ZA TOBĄ

Legacy otwiera blok 10xArchitect, ale stoi na wszystkim, co zbudował 10xBuilder: rampa, łańcuch, rygor i tarcza. Cztery strony bloku niżej.

moduł 1
10xdevs-fundament.pages.dev - od pomysłu do rampy startowej
moduł 2 // csc
10xdevs-csc.pages.dev - pięć skoków jednej jednostki pracy
skalowanie
10xdevs-skalowanie.pages.dev - quality gates, goal, loops
moduł 3
10xdevs-jakosc.pages.dev - najpierw ryzyka, nie pliki
10XARCHITECT // CO DALEJ

10xArchitect zaczyna się tam, gdzie kończy się Twój własny kod: dowody zamiast intuicji, raport architektoniczny jako artefakt, którego bronisz. Następny moduł podnosi stawkę z kodu na ludzi.

zapowiedź
teamwork (M5, 10xChampion) - workflow w zespole, nie solo
zasada
raport ma być Twój - obronialny, nie przyjęty na wiarę

„Blok 10xBuilder za Tobą. 10xArchitect gra w cudzym kodzie - dowodami, nie intuicją."

- fundament 10x Workflow