Compound Engineering: pętla, wtyczka i dowody

Compound Engineering to metoda firmy Every, a zarazem wtyczka na licencji MIT, dzięki której każda zmiana zostawia agenta lepiej przygotowanego na następną: brainstorm, plan, praca, uproszczenie, review i na końcu compound, czyli zapis wniosku w docs/solutions/, skąd kolejne plany go pobierają. Wersja 3.29.0 to 36 skilli dla Claude Code, Codex, Cursora i innych hostów agentów.

Ten sam błąd wraca trzeci raz w tym kwartale. Ktoś naprawił go w marcu, naprawa była poprawna, a rozumowanie za nią leży w wątku na Slacku, którego nikt nie znajdzie, i w transkrypcie agenta, którego już nie ma. Problemem nie jest sama naprawa, tylko to, że ani twój zespół, ani twój agent jej nie pamięta.

Ta strona jest dla programistów i tech leadów, którzy chcą tej pamięci bez płacenia za nią kontekstem przy każdym zadaniu. Opisuje wtyczkę w obecnym kształcie, jedną funkcję przeprowadzoną przez całą pętlę, sposób sprawdzenia wyniku bez czytania każdej linii i miejsce metody na drabinie autonomii. Jak w ogóle instaluje się i aktualizuje wtyczki, opisuje strona o wtyczkach i marketplace’ach; porównanie z sąsiednimi frameworkami znajdziesz w zestawieniu frameworków pracy z agentami.

Co zyskujesz z Compound Engineering

Sprawdzone polecenia instalacji i aktualizacji dla Claude Code, Codex i Cursora oraz jedną pułapkę kolejności, przez którą aktualizacja zostawia starą wersję
Jedną funkcję przeprowadzoną przez sześciokrokową pętlę: co każdy skill zapisuje na dysku i gdzie decyduje człowiek
Sposób akceptowania wyniku pętli na podstawie planu, raportu z review i CI zamiast diffa
Mapowanie etapów Every na drabinę L0–L5 i miejsce, w którym naprawdę stoi /lfg
Cechę konstrukcyjną, od której zależy, czy gromadzone wnioski pomagają agentowi, czy mu szkodzą
Pięć promptów do skopiowania, które wykonują kluczowe kontrole metody z wtyczką lub bez niej

Jak działa pętla compound?

README opisuje sześć kroków. Pięć z nich daje zrecenzowaną zmianę; szósty daje system, dzięki któremu następna zmiana jest tańsza.

Krok	Skill	Co zapisuje	Etap cyklu życia
Brainstorm	`ce-brainstorm`	Plan z samymi wymaganiami, powstały w interaktywnym Q&A	Plan
Plan	`ce-plan`	Ten sam plik planu, rozbudowany do planu gotowego do implementacji, w `docs/plans/`	Projekt
Praca	`ce-work`	Kod i commity; po drodze uruchamia testy i kontrole hosta	Budowa
Uproszczenie	`ce-simplify-code`	Porządki w świeżym diffie pod kątem czytelności i ponownego użycia	Testy
Review	`ce-code-review`	Review wielu person względem planu, tylko raport; poprawki nanosi się jawnie	Testy
Compound	`ce-compound`	Jeden wniosek w `docs/solutions/`, do tego słownictwo w `CONCEPTS.md`; wskazanie w pliku instrukcji tylko za twoją zgodą	Utrzymanie

Metodą jest strzałka powrotna: ce-brainstorm i ce-plan czytają docs/solutions/ jako podstawę, więc ograniczenie poznane w marcu pojawia się we wrześniowym planie. Every podaje podział czasu: 80% planowanie i review, 20% wykonanie.

Krok compound ma też próg. ce-compound zapisuje wniosek tylko wtedy, gdy zawiera rozumowanie, którego nie niosą już finalny kod, testy, typy, komentarze ani istniejąca dokumentacja, i gdy jego utrata realnie groziłaby powtórką. Jego własny test jest kontrfaktyczny: gdyby dokument zniknął, czy następny inżynier i tak powtórzyłby błąd? Jeśli nie, przebieg niczego nie zapisuje i podaje powód. Rutynowa poprawka nie daje wniosku — i to znaczy, że skill działa.

Zainstaluj Compound Engineering w Claude Code, Codex lub Cursorze

Wszystkie trzy hosty czytają to samo repozytorium. Marketplace nazywa się compound-engineering-plugin, a wtyczka compound-engineering.

W sesji:

/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineering

Z powłoki lub skryptu:

claude plugin marketplace add EveryInc/compound-engineering-plugin
claude plugin install compound-engineering@compound-engineering-plugin

Przy aktualizacji najpierw odśwież marketplace. Samo /plugin update czyta zbuforowany snapshot i zostawia starą wersję:

/plugin marketplace update compound-engineering-plugin
/plugin update compound-engineering

Claude Code wyświetla skille wtyczek z prefiksem wtyczki, więc /ce-plan z README widzisz jako /compound-engineering:ce-plan.

W terminalu:

codex plugin marketplace add EveryInc/compound-engineering-plugin
codex plugin add compound-engineering@compound-engineering-plugin

Możesz też zainstalować wtyczkę z /plugins w TUI. Po każdej z tych dróg zrestartuj Codex. Codex wywołuje skille przez $: $ce-plan, $lfg. Dla profilu innego niż domyślny poprzedź oba polecenia tym samym CODEX_HOME; krok marketplace tylko udostępnia wtyczkę, a krok add ją aktywuje.

Polecenia codex plugin update nie ma. Odśwież snapshot i uruchom add jeszcze raz:

codex plugin marketplace upgrade compound-engineering-plugin
codex plugin add compound-engineering@compound-engineering-plugin

W czacie Cursor Agent, według README wtyczki:

/add-plugin compound-engineering

Albo wyszukaj „compound engineering” w marketplace wtyczek Cursora. Samego marketplace Cursora nie sprawdziliśmy ponownie na potrzeby tej strony (cursor.com był nieosiągalny 2026-09-26). Aktualizacja: zainstaluj lub odśwież wtyczkę w ten sam sposób.

Następnie uruchom ce-setup raz w każdym repozytorium (/compound-engineering:ce-setup w Claude Code, $ce-setup w Codex). Skill raportuje, które opcjonalne narzędzia są dostępne, proponuje utworzenie .compound-engineering/config.yaml, sprawdza, czy lokalny plik nadpisań jest w .gitignore, i proponuje dopisanie do pliku instrukcji agenta wskazania na magazyn wiedzy. Jeśli twój katalog docs/ to już śledzona treść, ustaw w tej konfiguracji docs_root, żeby przenieść wszystkie foldery artefaktów pod jeden katalog względny wobec repozytorium.

Ile to kosztuje w kontekście. claude plugin details compound-engineering pokazało dla 3.29.0 w Claude Code 2.1.283 około 2989 tokenów stale obecnych: to lista 36 skilli, którą niesie każda sesja. Główne skille ce-* kosztują około 2,5 tys. tokenów przy każdym wywołaniu, a ce-debug około 5,6 tys. Uruchom claude plugin details przed i po instalacji każdej kolejnej wtyczki dyscyplinującej; dwie nakładające się pętle kosztują podwójnie i walczą o to, która się odpali.

Skalowanie poza jedno repozytorium. Tech leadzi, którzy chcą tych samych reguł w każdym repozytorium, mogą zadeklarować Compound Packs (eksperymentalne): foldery reguł nakazowych, lokalne albo przypięte do refa w gicie, które planowanie wciąga, a review egzekwuje z odwołaniem do pliku reguły. Traktuj pack jak współdzielony kod: właściciel, review, przypięta wersja.

Nazwy z dwukropkiem. Wczesne wydania miały polecenia w stylu /ce:plan. Dziś to ce-plan, ce-work, ce-compound i tak dalej.
Osobne agenty i polecenia. Przewodnik Every, czytany 2026-08-24, opisywał osobne foldery agentów i poleceń. Repozytorium przeszło od tego czasu na układ oparty wyłącznie na skillach; persony recenzentów żyją wewnątrz ce-code-review i nie są instalowalnymi agentami. Stroisz je przez skill, nie edytując plików agentów.
Zła nazwa marketplace. To compound-engineering-plugin, nie every ani compound-engineering. Starsze poradniki dodają EveryInc/every-marketplace; dodaj zamiast niego EveryInc/compound-engineering-plugin.
Aktualizacja bez odświeżenia. Opisana w każdej zakładce powyżej. To najczęstsze zgłoszenie typu „zaktualizowałem i nic się nie zmieniło”.
Kolizje z docs/. Na stronie z dokumentacją albo w każdym repo, którego docs/ jest publikowane, domyślne foldery artefaktów trafią do publikowanej treści, dopóki nie ustawisz docs_root.

Przeprowadź jedną funkcję przez pętlę

Pętla jest identyczna we wszystkich trzech hostach; różni się tylko prefiks (/compound-engineering: w Claude Code, $ w Codex, w Cursorze forma z menu poleceń). Przykład używa żądania startowego z samego README.

Przeprowadź brainstorm wymagań. Uruchom ce-brainstorm make background job retries safer. Odpowiedz na pytania. Powinien powstać plik planu z samymi wymaganiami w docs/plans/.
Zaplanuj, a potem sam przejrzyj plan. Uruchom ce-plan. Rozbuduje ten sam plik do planu implementacji, opartego na pasujących wnioskach z docs/solutions/. To najważniejsza bramka człowieka: czytasz plan, a nie kod, którego jeszcze nie ma. Użyj promptu do review planu poniżej.
Pracuj. Uruchom ce-work. Implementuje plan, uruchamia testy i sprawdzanie typów projektu i commituje. Uruchamiaj go na gałęzi albo w git worktree, nigdy na main.
Uprość i zrecenzuj. Uruchom ce-simplify-code, a potem ce-code-review. Review to sam raport: uwagi są uszeregowane według poziomu pewności i nic nie zostanie naniesione, dopóki o to nie poprosisz.
Zapisz wniosek (compound). Gdy zmiana jest zweryfikowana, uruchom ce-compound. Albo zapisze jeden wniosek w docs/solutions/, albo zgłosi, że nic nie przekroczyło progu.
Utrzymuj magazyn. Raz na kwartał, albo gdy plany zaczynają cytować nieaktualne rady, uruchom ce-compound-refresh. Każdy wniosek dostaje jeden werdykt: Keep, Update, Consolidate, Replace albo Delete. Zwykły przebieg ocenia tylko poprawność i nigdy nie usuwa poprawnego dokumentu; przebieg usuwający dokumenty, które kod już wyjaśnia, działa tylko na twoją prośbę i po potwierdzeniu.

Review the implementation plan the last ce-plan run wrote under docs/plans/.
Do not write code and do not edit the plan.

1. List every acceptance criterion in the plan. For each one, name the test,
   command or observable result that would prove it. Mark any criterion that
   has no machine-checkable proof as UNTESTABLE.
2. List every file and module the plan will touch. Flag anything in auth,
   payments, schema migrations, secrets or public APIs as HIGH RISK.
3. Quote each docs/solutions/ learning the plan cites, and check that the
   code it refers to still exists. Report any citation to code that is gone.
4. Name the one assumption that, if wrong, would waste the most work.

End with APPROVE, REVISE (with the smallest change that fixes the plan) or
SPLIT (with the proposed pieces).

Jak zweryfikować wynik pętli bez czytania każdej linii?

Pętla daje cztery dowody i razem zastępują one czytanie diffa w większości zmian.

Plan jako specyfikacja. Kryteria akceptacji zatwierdzone w kroku 2 są miarą dla reszty przebiegu. ce-code-review recenzuje względem tego planu, a nie względem gustu.
Raport z review. Uwagi mają dyskretny poziom pewności, a nie wynik liczbowy. Zgodność kilku person podnosi pewność tylko wtedy, gdy działały w osobnych kontekstach (zob. zasady niżej).
Testy i CI. ce-work uruchamia kontrole hosta po drodze, ce-test-browser sprawdza interfejs, a /lfg obserwuje CI aż do rozstrzygnięcia, z ograniczoną pętlą napraw.
Pozostałości na piśmie. W /lfg każda uwaga, której przebieg nie naprawił, trafia do opisu pull requesta albo raportu końcowego, więc to, czego nie zrobiono, jest jawne.

Merge nadal zatwierdza człowiek i nadal czyta kod w klasach zmian, w których błędna linia dużo kosztuje: uwierzytelnianie, pieniądze, schemat i migracje danych. Tę listę definiuje strona dowody zamiast diffów, a kolejność triażu podaje code review PR-a agenta.

Gdzie etapy Every lądują na drabinie autonomii?

Przewodnik Every opisuje drabinę etapów od 0 do 5, pokazującą, jak zmienia się sposób pracy jednego programisty. Ten serwis używa jednej drabiny dojrzałości, L0–L5 dla każdej pętli, więc poniżej mapowanie. To pomoc w czytaniu materiałów Every, nie równoważność; jedna mapa traktuje etapy Every jako osobny model. Etapy Every służą do czytania materiałów Every; drabina służy do określania, gdzie jest pętla.

Etap Every (przewodnik, lektura 2026-08-24)	Co robi programista	Poziom drabiny	Co rozstrzyga
0	Pisze każdą linię	L0, ręcznie	Kod agenta nie trafia na dysk
1	Pyta model czatowy i wkleja to, co przydatne	L1, wspomaganie	Człowiek prowadzi i czyta linia po linii
2	Używa agenta z dostępem do plików i zatwierdza każdą akcję	L2, para	Człowiek steruje na żywo
3	Uzgadnia szczegółowy plan, odchodzi, dostaje pull request	L3, menedżer review	Agent działa bez nadzoru; człowiek czyta każdy diff
4	Opisuje rezultat; agent bada, planuje, buduje, sam się recenzuje i otwiera pull request	L3 lub L4	L4 tylko wtedy, gdy merge opiera się na zatwierdzonym planie, testach i dowodach z review, a nie na czytaniu diffa
5	Kieruje kilkoma agentami równolegle, skądkolwiek	Brak własnego poziomu	Równoległość zwiększa przepustowość; każda pętla nadal jest na L3 lub L4. L5 wymaga merge’y, których nikt nie czytał, a tego nie opisuje żaden etap

Gdzie jest /lfg. /lfg automatyzuje etap 4 Every: po ce-brainstorm planuje, pracuje, upraszcza, recenzuje i nanosi kwalifikujące się poprawki, zapisuje trwały wniosek, jeśli taki powstał, uruchamia testy w przeglądarce, commituje, pushuje, otwiera pull request i obserwuje CI. Nie robi merge’a, chyba że pozwolisz na to w danym przebiegu, a bez zdalnego repozytorium git kończy na lokalnych commitach. Na drabinie to maszyneria pętli L4, a nie dowód, że nią jest. Jeśli potem czytasz cały diff na 40 plików przed merge’em, pętla jest na L3 z dodatkową automatyzacją. Domyślnie nigdy nie osiąga L5, bo merge zostaje przy człowieku.

Czy gromadzenie wniosków pogarsza agenty?

Może. Najbardziej bezpośrednie badanie repozytoryjnych plików kontekstu, Gloaguen i in. z ETH Zurich (Evaluating AGENTS.md, arXiv, 2026), wskazuje, że takie pliki na ogół nie poprawiają skuteczności zadań, a podnoszą koszt inferencji. Strona o przycinaniu CLAUDE.md i AGENTS.md podaje liczby z badania i opisuje zwrot dostawców w połowie 2026 roku w stronę usuwania kontekstu zamiast dopisywania. Metoda, która mówi „zapisuj każdą lekcję”, musi na to odpowiedzieć.

Odpowiedź wtyczki to jedna cecha: pobierane, a nie ładowane zawsze.

docs/solutions/ to magazyn pobierany. Wnioski leżą na dysku, a ce-plan sięga tylko po te pasujące do pracy. Czterysta wniosków nie dokłada nic do kontekstu ładowanego zawsze; zadanie płaci tylko za tych kilka, które pobierze.
CLAUDE.md i AGENTS.md są ładowane zawsze. Za każdą linię płacisz w każdym zadaniu. ce-compound edytuje plik instrukcji tylko po to, by dodać wskazanie na magazyn, tylko w trybie interaktywnym i tylko za twoją zgodą. Nigdy go nie tworzy.

Dwa mechanizmy nie pozwalają, by magazyn stał się tym samym problemem w innym folderze: próg przy zapisie i ce-compound-refresh później.

We just solved a non-trivial problem in this session. Decide whether it
deserves a learning document, then write it only if it does.

The bar: write it only if the reasoning is not recoverable from the final
code, tests, types, comments or existing docs, and losing it would plausibly
cause the mistake to happen again. If it fails the bar, say why and stop.

If it passes, classify it as a defect or as guidance and use that structure:
  Defect:   Symptoms / What Didn't Work / Solution / Why This Works / Prevention
  Guidance: Context / Guidance / Why This Matters / When To Apply / Examples

- "What Didn't Work" must name each approach we tried and why it failed.
- Every claim about code behaviour quotes the line that proves it, with a
  file path. Mark anything you cannot prove UNVERIFIED.
- Add YAML frontmatter: title, problem_type, component, root_cause, and
  3-6 tags that reuse vocabulary already in docs/solutions/.

Before writing, search docs/solutions/ for a document on the same problem.
Compare problem, root cause, solution, files touched and prevention rule.
If four or more match, update that document instead and tell me which.
Save to docs/solutions/<category>/<kebab-case-title>.md.

Audit whether this repository's accumulated knowledge is reachable by an
agent that has never seen it. Do not change anything.

1. Find every place that stores durable engineering knowledge: docs/solutions/,
   ADRs, runbooks, plan files, long sections of CLAUDE.md or AGENTS.md. Give
   file counts and the date range of last modification.
2. For each place, quote the line in the file the agent loads at session
   start that points to it, or write NOT REFERENCED.
3. Take the five most recent bug fixes from git log. For each, search the
   knowledge for a document that would have prevented or shortened it.
   Report hit or miss, and whether a hit was findable by the words someone
   would actually search for.
4. Report reachable-and-findable documents divided by total documents.

Finish with the single highest-leverage change: one line in one file, or
one index. One change, not a plan.

Które zasady ze słownika wtyczki warto skopiować?

CONCEPTS.md w repozytorium to słownik, który opiekunowie prowadzą dla własnych agentów. Cztery z jego zasad dobrze się uogólniają poza tę wtyczkę.

Dwóch recenzentów w jednym kontekście to nie dwóch świadków. Niezależność to cecha kontekstu wykonania, w którym działał recenzent, a nie perspektywy, którą przyjął. Jeśli każesz jednemu agentowi zrecenzować kod „jako ekspert od bezpieczeństwa, potem od wydajności, potem jako architekt”, trzy zestawy uwag dzielą jedno odczytanie diffa i jeden zestaw pomyłek. Tylko osobno uruchomione konteksty uprawniają do podniesienia pewności, a gdy uruchomienie się nie uda, przebieg raportuje, jakie pokrycie stracił.

Tożsamość modelu to paragon, nie zamówienie. Gdy review trafia do innego dostawcy modeli po drugą opinię, wtyczka zapisuje raport serwującego backendu o tym, który model faktycznie działał, obok modelu, o który prosiła. Wyniki bez takiego paragonu są oznaczane jako zamówione, ale niezweryfikowane. Potok wielomodelowy, który ufa parametrowi żądania, nie wykryje cichego przełączenia na inny model.

Hosty obcinają treść skilli od końca, po cichu. Każdy znany limit hosta zachowuje początek treści skilla i odrzuca resztę, a żaden nie zgłasza błędu. Kolejność jest więc nośna: wtyczka umieszcza na górze cel, warunek ukończenia i reguły zatrzymania, a mechanikę każdej fazy ładuje z pliku referencyjnego w chwili działania. Rób tak samo we własnych skillach i długich plikach instrukcji.

Instrukcje w chwili działania wygrywają z wnioskiem. Agent ładuje instrukcje skilla albo główny plik instrukcji wtedy, gdy działa, więc wniosek, który im przeczy, nie jest tylko nieaktualny — w praktyce zostaje zignorowany. Rozwiązuj sprzeczność tam, gdzie agent czyta, i traktuj konflikt w tym miejscu jako pilniejszy niż nieaktualna ścieżka.

Audit the review process below for independence, not accuracy.

[paste your review prompt, command or pipeline description]

Answer without guessing:
1. How many separate model invocations does it make? Count contexts, not
   personas, roles or bullet points.
2. Where does it treat agreement between findings as evidence? Quote the
   line, then say whether the agreement is across independent contexts or
   one context agreeing with itself.
3. What does it use to rank or escalate findings, other than the model's
   own confidence in its own output?
4. If a delegated call silently fell back to a different model, what in the
   process would notice?

Output a table of what the process claims against what it can support, and
the cheapest change that would buy real independence.

Co się psuje w Compound Engineering i jak z tego wyjść?

Aktualizacja nic nie zmieniła. Uruchomiłeś /plugin update bez odświeżenia marketplace. Wyjście: uruchom polecenie odświeżenia dla swojego hosta z zakładek instalacji, zaktualizuj ponownie i sprawdź wynik przez claude plugin details compound-engineering w Claude Code albo codex plugin list -m compound-engineering-plugin w Codex.

Wnioski powstają, ale nikt ich nie czyta. Magazyn istnieje, ale plik instrukcji nigdy na niego nie wskazuje, więc plany się na nim nie opierają. Wyjście: uruchom powyższy prompt o osiągalności, a potem przyjmij propozycję ce-setup, by dopisać wskazanie na magazyn wiedzy.

Magazyn sam sobie przeczy. Dwa dokumenty o tym samym podsystemie mówią co innego, a agent pierwszy znajduje ten nieaktualny. Wyjście: uruchom ce-compound-refresh dla tego obszaru i zaplanuj go cyklicznie, zamiast czekać na następną sprzeczność.

Wniosek przeczy plikowi instrukcji. W chwili działania wygrywa plik instrukcji, niezależnie od tego, kto ma rację. Wyjście: ustal, której wersji trzyma się obecny kod, i popraw przegrany plik. Skill odświeżania zgłasza błędny plik instrukcji, ale go za ciebie nie edytuje.

Review planu znika pod presją terminu. Podział 80/20 po cichu się odwraca i wracasz do recenzowania dużych diffów z planów, których nikt nie czytał — to ta sama kolejka review, którą opisują fabryki oprogramowania. Wyjście: uczyń prompt do review planu obowiązkowym krokiem przed ce-work, a plany z werdyktem SPLIT dziel.

/lfg działa z szerokimi uprawnieniami na twoim laptopie. /lfg jest zbudowany tak, by nie czekać, i zatrzymuje się tylko przed nieodwracalnymi akcjami, na które nie pozwoliłeś. Wyjście: uruchamiaj go w worktree albo w jednorazowym sandboksie z ograniczoną siecią i tokenem git ograniczonym do jednego repozytorium. Nigdy nie łącz go z --dangerously-skip-permissions poza takim sandboksem; zobacz sandboksy dla agentów.

Efekt procentu składanego jest deklarowany, nie mierzony. Żaden opublikowany pomiar nie pokazuje zwrotu z tej pętli. Wyjście: zmierz go we własnym repozytorium. Policz, ile razy na kwartał ktoś ponownie tłumaczy tę samą konwencję albo od nowa diagnozuje tę samą awarię, i sprawdź, czy liczba spada, odkąd magazyn istnieje. Jeśli nie spada, pętla działa, ale nic się nie kumuluje.

To złe narzędzie. Przy prototypach do wyrzucenia, repozytoriach bez runnera testów albo zespołach, w których nikt nie przejrzy tego, co pisze ce-compound, ceremonia nie daje żadnego sygnału. Użyj lżejszego pakietu dyscypliny albo żadnego; alternatywy są w zestawieniu frameworków.

Review every document under docs/solutions/. Give each exactly one verdict:
KEEP, UPDATE, CONSOLIDATE, REPLACE or DELETE, judged against the code as it
is now.

- DELETE if the code it describes no longer exists or the problem is now
  impossible by construction.
- REPLACE if the conclusion is now wrong. Say what the current answer is.
- CONSOLIDATE if another document covers the same root cause. Name the pair
  and which one survives.
- UPDATE if the substance holds but a path, command, version or API changed.
- KEEP only if you verified at least one specific claim against current
  code. Quote the line you checked.

Then check each document against CLAUDE.md, AGENTS.md and any skill files it
names. Report every contradiction with file and line; a contradiction there
outranks staleness. Do not edit the instruction files.

Output a table sorted by verdict, DELETE and REPLACE first. Apply nothing.

Dokąd dalej z Compound Engineering

Frameworki pracy z agentami: porównanie Compound Engineering obok Superpowers, Spec Kit, OpenSpec, BMAD i GSD: ceremonia, artefakty i koszt kontekstu

Superpowers Druga zdyscyplinowana wtyczka od projektu do PR-a: worktree, wykonywalne plany i wymuszone TDD

Jedna mapa: drabina, cykl życia i stacje Jedno słownictwo dojrzałości serwisu, L0–L5 dla pętli, i jak starsze schematy z tego serwisu się na nie mapują

Czytanie dowodów zamiast kodu Co czytać zamiast diffa i w których klasach zmian człowiek nadal czyta kod

Przycinanie CLAUDE.md i AGENTS.md Protokół ablacji i dowody na temat plików kontekstu ładowanych zawsze

Wzorce pamięci Jak agenty zapisują i przywołują wiedzę między sesjami i co każde narzędzie utrwala samo