---
name: molecular-harness-working-mode
title: Molekularny harness — working mode
description: "Główny manifest working mode dla Claude Code w rozbudowanych projektach. Neutralna wersja osobistego harness'u z projektu GroqeSTT — auto-loaded w CLAUDE.md na starcie każdej sesji. Zawiera diagnozę typowych wad agenta, zasady nienegocjowalne, check-listy przed/w trakcie/po tasku, red flags, stery użytkownika oraz taksonomię dokumentów."
category: system
tags:
  - harness
  - working-mode
  - claude-code
  - dyscyplina
  - projekty
model: Claude Sonnet 4.6 / Opus 4.7
source: https://madejski.ai/pl/promptoteka/molecular-harness-working-mode
locale: pl
license: MIT
---

# 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

| Typ | Lokalizacja (przykład) |
|---|---|
| Koncepcja | zewnętrzny doc |
| ADR | zewnętrzny doc / `docs/adr/` |
| Phase spec | zewnętrzny roadmap |
| Status note | zewnętrzny doc (sub-page pod phase) |
| Working mode | Ten plik |
| Architektura | ArchiMate / C4 / `docs/architecture/` |
| Code | Repo (commits + PR) |

## 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.