Decision prompt — trzy ścieżki

Problem

Gdy agent musi podjąć decyzję, są dwa anty-wzorce:

1. Mnożenie sztucznych opcji — A/B/C gdy B i C są oczywiście gorsze, żeby "było demokratycznie". Użytkownik traci czas.
2. Esej decyzyjny — 5 akapitów kontekstu, a na końcu "co wybierasz?". Użytkownik nie wie co klika.

Obie sytuacje wynikają z jednego błędu: agent nie zdiagnozował najpierw, ile realnych opcji istnieje.

Diagnoza najpierw — ile jest realnych opcji?

• 1 opcja → propozycja + pytanie o luki (ścieżka 1)
• 2–3 realne opcje → klasyczny A/B/C z 3-liniowym formatem (ścieżka 2)
• > 3 opcje → zawęź najpierw (ścieżka 3)

---

Ścieżka 1 — jedna sensowna opcja (proposal + luki?)

Jeśli widzisz jedną ścieżkę, która wynika z kontekstu (inne są oczywiście gorsze, nieadekwatne, lub nie istnieją), nie mnożysz sztucznych opcji. Zamiast A/B/C:

**Propozycja**: zrobię X (1 linia — co fizycznie).
Wpływ: Y (1 linia — prod/test/DB/cost).
Ryzyko: Z (1 linia — co może pójść nie tak, ile trwa).

Widzisz luki? Jeśli nie — GO.

Domyślnie czekasz na NO-GO. Brak odpowiedzi ≠ GO. Użytkownik odpowiada: GO / luka: ... / inaczej: ....

Kiedy ścieżka 1 jest właściwa

• Pipeline ma jeden idiomatyczny krok (następna migracja w serii, kolejny commit w logicznej sekwencji)
• Użytkownik poprosił o konkret (np. "dodaj endpoint /api/health") — nie wymyślaj wariantów
• Inne opcje wymagałyby zmiany architektury / scope — to osobna decyzja, nie alternatywa
• Niska irreversibility + niski koszt (zmiana odwracalna git revert)

Przykład (dobra ścieżka 1)

Propozycja: dodam `config.ts` z `ROUTING_V2_ENABLED` — `z.string().default('false')
.transform(v => v==='true'||v==='1')` (edge-case safe boolean parsing).
Wpływ: test env + prod env przyjmie nową env var; domyślnie off.
Ryzyko: żadne (default off, zero touch v1 routing).

Widzisz luki? Jeśli nie — GO.

Dlaczego dobry: jedna sensowna ścieżka (parsing boolean z zodem to idiomatyczny sposób), mały blast radius, pełna odwracalność. Pytanie o A/B/C byłoby marnowaniem czasu.

---

Ścieżka 2 — 2–3 realne opcje (klasyczny format)

Gdy są realne opcje z różnymi implikacjami, każda musi mieć dokładnie 3 linie:

1. Co fizycznie zrobię (1 linia — akcja, nie cel)
2. Na co wpływa (1 linia — prod? test? UI? baza? koszt? irreversible?)
3. Trade-off / ryzyko (1 linia — co zyskujemy / co tracimy / jak długo trwa)

Format

**A** `label` — co zrobię (zmiana Railway env var, backend redeploy).
Wpływ: tylko test env, bez ruszenia prod.
Trade-off: ~3 min, odwracalne.

**B** `label` — co zrobię (merge feature/X do main, prod auto-deploy).
Wpływ: **PROD live**, migracja 031_edges uruchomi się na prod Supabase.
Trade-off: rollback przez `git revert` + redeploy, additive migracja więc safe.

**C** `pauza` — nic nie robię.
Wpływ: zero.
Trade-off: wracasz kiedy chcesz.

Po liście opcji — 1 linia TL;DR rekomendacji (jeśli masz zdanie):

Rekomenduję A — B jest reversible ale chce mieć test verify pierwsze.

Kiedy ścieżka 2 jest właściwa

• Różna odwracalność (jedna irreversible, inna nie)
• Różny blast radius (test vs prod)
• Różny koszt (wolne + tanie vs szybkie + drogie)
• Różne trade-offy poznawcze (agent nie może zdecydować bez wiedzy użytkownika)

---

Ścieżka 3 — > 3 opcje, żadna nie dominuje

Decyzja zbyt gruba. Najpierw zawęź do 2–3 wariantów.

Pierwszy krok: decision prompt o kryterium wyboru, nie o konkretną opcję:

**Decision narrowing**:
Mamy 5 bibliotek do rozważenia (A, B, C, D, E).
Pytanie wstępne: jakie kryterium najważniejsze — (1) bundle size, (2) API ergonomics,
(3) maintenance activity, (4) TypeScript support?

Po wskazaniu kryterium wybiorę 2 najlepsze do pełnego decision prompta.

---

Zawsze pytaj (niezależnie od ścieżki)

• Irreversible: DROP TABLE, rm -rf, force push na main, delete branch zdalnie
• High-cost: operacja > $X, API call w pętli, long-running compute
• Prod-impact: deploy, migracja produkcyjna, zmiana w main
• Scope expansion: użytkownik poprosił o X, widzisz że należy też Y — pytaj zanim rozszerzysz

Nie pytaj o kosmetykę

Nazwa commit message, kolor badge, formatowanie JSON → decydujesz sam zgodnie z konwencjami repo.

Anty-wzorce

• Sztuczne A/B/C — gdy B i C są oczywiście gorsze, nie mnóż. Ścieżka 1.
• "Co ty na to?" bez propozycji — użytkownik nie zna pełnego kontekstu narzędzi, ty znasz
• Decyzja na końcu po 5 akapitach — propozycja / opcje od razu, nie po długim wstępie
• Pytanie o oczywiste — "czy mam dodać if (!user) throw?" Nie pytaj o idiomatyczne fragmenty

Efekt

• Użytkownik w 10 sekund wie co klika (gdy są opcje)
• Agent nie blokuje się na godzinach deliberacji
• Pytania są celowe, nie rytualne
• Przestrzeń decyzyjna zachowana dla realnych wyborów