Polityka planowania — zaakceptowane artefakty przed ryzykownym wykonaniem

Plan mode jest użytecznym interfejsem do analizy przed edycją, ale polityka planowania nie może zależeć od trybu jednego vendora ani hooka zgadującego stan sesji. Dla zmian wrażliwych wymagaj zaakceptowanych artefaktów intent, spec i plan, a chronione ścieżki, checki, permissions i nazwane approvals egzekwuj poza modelem. Artefakt jest kontraktem; Plan mode to jeden ze sposobów jego stworzenia.

Q17 · Enablement organizacji Dowód na maksymalny wynik: zaakceptowane intent.md, spec.md i plan.md, chronione dowodem hooka lub CI oraz nazwanym approverem przed wykonaniem zmiany wrażliwej.

Claude Code wspiera Plan Mode, Cursor Agent udostępnia planowanie w parametrach CLI, a Codex ma /plan w sesjach interaktywnych. Przed standaryzacją skrótów lub flag sprawdź bieżący local help i oficjalne docs.

Zdefiniuj, kiedy plan jest obowiązkowy

Użyj sygnałów ryzyka: migracje, auth, uprawnienia, płatności, infrastruktura, publiczne kontrakty, dane wrażliwe, operacje destrukcyjne i zachowanie trudne do cofnięcia. Sama liczba linii nie wystarcza.

1. Zaakceptuj intent. Nazwij wynik użytkownika lub operacyjny, non-goals, ograniczenia, ryzyko i dowód sukcesu.
2. Zaakceptuj specyfikację. Zdefiniuj zachowanie, interfejsy, zmiany danych, failure cases, rollout, rollback i observability.
3. Zrecenzuj plan. Wymagaj plików, kolejności kroków, checków, stop conditions i ludzkich decyzji. Rozwiąż niewiadome przed rozszerzeniem write authority.
4. Egzekwuj zewnętrznie. Chroń ścieżki przez branch policy, CI, sandbox, scoped credentials i production approvals. Hooki mogą kierować lub blokować lokalnie, ale są tylko warstwą.
5. Połącz dowody. PR zapisuje wersje zaakceptowanych artefaktów i wyjaśnia odchylenia.

Prompty do bramki planowania

Utwórz plan.md z zaakceptowanego intent i spec. Dodaj pliki, kolejność zmian, testy, migrację i rollback, observability, ryzyka, stop conditions oraz decyzje wymagające nazwanego człowieka. Nie edytuj kodu.

Podważ plan pod kątem pominiętych konsumentów, przejść danych, recovery, zmian permissions, kolejności deployment i luk w dowodach. Oznacz fakty wymagające weryfikacji repo lub produkcji.

Porównaj końcowy diff z zaakceptowanym planem. Wypisz odchylenia, ich dowody i osobę, która musi zaakceptować każdą materialną zmianę scope przed merge.

Dowody akceptacyjne

• Polityka definiuje triggery zmian wrażliwych i accountable approvera.
• Artefakty są wersjonowane i powiązane z dokładnym diffem.
• CI weryfikuje wymagane checki i chronione ścieżki niezależnie od zachowania agenta.
• Emergency exceptions są przypisane, ograniczone czasowo, audytowane i później reviewowane.
• Test fresh-session potwierdza, że każdy wspierany tool odkrywa politykę bez prywatnego kontekstu.

Wzorzec awarii: Plan Mode jako enforcement

Agent może wyjść z Plan Mode, lokalnego hooka może brakować, a markdown może zostać zignorowany. Nigdy nie twierdź, że samo UI planowania gwarantuje bezpieczne wykonanie. Konsekwentne permissions i promocję produkcyjną trzymaj za kontrolami, których agent nie przedefiniuje.

Dalej: kanoniczny plan

Użyj wspólnego etapu Plan dla kontraktu artefaktów i Gates i guardrails dla rozmieszczenia enforcement.

Plan Zamień intent w zaakceptowany wykonywalny plan.

Q10 · Gates i guardrails Rozdziel instrukcje, checki i władzę.