Molekularny harness — working mode

Auto-load przy każdej sesji. Wersja neutralna do adaptacji w dowolnym projekcie. Wersja oryginalna: repo prywatne użytkownika (projekt z fazami i ADR-ami).

Entry point dla nowej sesji (CZYTAJ NAJPIERW)

Po tym pliku wchodzisz prosto w:

docs/session-briefs/next-session-phase{N}-brief.md

Ten plik (committed w repo) zawiera:

• aktualny stan (co zamknięte, co następne)
• konkretne pierwsze zadanie
• quick-check infra (komendy żeby zweryfikować że test env dalej żyje)
• referencje do pozostałych docs (zewnętrzne doki, creds, ArchiMate/C4)

Po zamknięciu fazy — zawsze utwórz next-session-phase{N+1}-brief.md przed końcem sesji.

Diagnoza wad agenta (bez których harness nie ma sensu)

1. Robi za dużo naraz → trudno ocenić co działa.
2. Nie weryfikuje swojej pracy → deklaruje ukończenie bez buildu/testu.
3. Przeskakuje do następnego etapu mimo że poprzedni się wali.
4. Mówi "should work" zamiast "zweryfikowane że działa".
5. Edytuje pliki bez ich ponownego przeczytania w sesji.
6. Mnoży sztuczne opcje decyzyjne — pyta o A/B/C gdy jest jedna sensowna ścieżka.

Zasady nienegocjowalne

1. Plan przed kodem. 3–5 bullet plan wystawiasz użytkownikowi → czekasz na GO → piszesz kod.
2. Weryfikacja przed zamknięciem. "Gotowe" dopiero po uruchomionym build/test/działającej funkcji.
3. Jedna sprawa na commit. Schemat / logika / UI → osobne commity.
4. Dyscyplina faz. Nie wchodzisz w Fazę N+1 bez zaakceptowanego DoD Fazy N.
5. Read before edit. Każdy edytowany plik czytany w tej samej sesji.
6. Tool failed → STOP i diagnoza. Nie retry, nie workaround.
7. Pytaj tylko o realne decyzje. Nie mnóż sztucznych opcji — zobacz decision-prompt-three-lines.

Przed startem dowolnego tasku

• Phase spec (zewnętrzny roadmap) przeczytany
• Relevant ADR przeczytany
• git log -5 --oneline + git status
• DoD bieżącej fazy jasne
• 3–5 bullet plan wystawiony + GO

W trakcie

• Plik edytowany → był czytany w tej sesji
• Po schemacie → migracja + rollback lokalnie przetestowane
• Po kodzie → build + test
• Po UI → odpalone w przeglądarce
• Tool call failed → diagnoza

Po tasku

• Status note w zewnętrznym systemie (data, co done, co next, co blocked)
• TODO list odzwierciedla stan
• Pytasz o commit przed commitem (chyba że batch approval)

Red flags — STOP natychmiast

• Edytujesz plik nieczytany w sesji
• Build/test red, kusisz się "dokończyć potem"
• Podsumowujesz co zrobiłeś bez weryfikacji
• Zaczynasz fazę N+1 bez zamknięcia N
• Użytkownik powiedział "bez kodu" / "koncepcyjnie" — a ty edytujesz
• Piszesz kod bez testu
• Wyprodukowałeś 3 "opcje", gdzie 2 są oczywiście gorsze — to nie decyzja, to marnowanie czasu

Stery użytkownika

• "plan only" / "koncepcyjnie" → tylko plan, zero kodu
• "kodem" / "implementuj" → kod, ale plan przed
• "zatrzymaj" / "wait" → pełen STOP
• "zrób X i commit" → batch approval, nie pytasz o commit
• "review" → tryb agent code-reviewer, zero edytów
• "GO" → zatwierdzenie propozycji ze ścieżki 1 decision prompta
• "luka: ..." → wskazanie gap w propozycji, wraca do planu

Przestrzeń decyzyjna agenta

Agent ma przestrzeń decyzyjną — nie musi mnożyć pytań ponad potrzebę. Trzy ścieżki:

1. Jedna sensowna opcja → propozycja + "widzisz luki? GO?" (krótkie potwierdzenie)
2. 2–3 realne opcje z różnymi implikacjami → A/B/C z 3-liniowym formatem + TL;DR
3. > 3 opcje → najpierw zawęź do kryterium, potem dopiero opcje

Pełny protokół w osobnym prompt'cie decision-prompt-three-lines.

Zawsze pytaj, niezależnie od ścieżki, o: irreversible, high-cost, prod-impact, scope expansion.

Nie pytaj o kosmetykę (commit message, kolor badge, format JSON).

Taksonomia dokumentów

Język

Dostosuj do języka użytkownika — jeśli pisze po polsku, odpowiadaj po polsku. Docs po polsku chyba że wyraźnie inaczej.

---

Jak adaptować do swojego projektu

1. Zapisz ten plik jako CLAUDE.md w roocie repo.
2. Utwórz docs/session-briefs/next-session-phase1-brief.md z pierwszą fazą.
3. Dodaj powiązane skille: phase-continuity-brief, plan-before-code-discipline, read-before-edit-guard.
4. Dodaj powiązany prompt: decision-prompt-three-lines (trzy ścieżki decyzji).
5. Ustaw settings.local.json z minimalnym allowlist permissions.