Polityka Plan mode — hook + managed policy wymusza plan przed destrukcyjnymi zmianami

Pytanie 17 (Wzmacnianie organizacji): Czy masz politykę „Plan mode wymagany” dla wrażliwych zmian (migracje DB, infra, security)?

Odpowiedź na max: Hard-enforced policy — hook + managed policy blokujące zmianę bez planu.

Dlaczego to ma znaczenie w 2026 (pamięć nie wymusza; tylko harness potrafi)

Plan mode to najtańsza bramka przed destrukcyjnymi zmianami, jaka istnieje w jakimkolwiek agentic coding tool. Naciskasz Shift+Tab dwa razy, a Claude Code rysuje pełny plan na piśmie zanim dotknie pliku, i czeka na twoje zatwierdzenie. Agent nie może uruchomić Bash, Edit, Write ani żadnego write-side MCP toola, dopóki nie powiesz „tak”. Dla destrukcyjnej zmiany — migracji schematu, terraform apply, przepisania tabeli permissions — ta dwuminutowa pauza to różnica między „złapaliśmy w review” a „budziliśmy on-calla o 2 w nocy, bo produkcja padła”.

Problem polega na tym, że Plan mode jest opt-in. W 2025 większość zespołów traktowała go jako osobistą preferencję: „włącz Plan mode, jeśli masz na to ochotę”. Przewidywalnie — inżynierowie, którzy najbardziej go potrzebowali (zbyt pewni siebie, w pośpiechu, w kontekście, którego do końca nie rozumieli) — byli tymi, którzy go pomijali. W 2026 post-mortemy dogoniły rzeczywistość. Cursor i Anthropic wypuściły managed-policy tier, który wreszcie daje CTO sposób na wymuszenie „Plan mode wymagany” tak, jak to jedynie może działać: na warstwie tooli, zanim agent zdąży zapomnieć.

Oto brutalna prawda, na której zbudowane jest Q17. Pamięć nie potrafi wymusić „za każdym razem, kiedy X”. Linijka w CLAUDE.md mówiąca „zawsze używaj Plan mode przy migracjach” to grzeczna sugestia. Agent zastosuje się do niej w większości przypadków, a potem ją zignoruje akurat tym razem, który ma znaczenie — zwykle pod presją czasu, przy zmianie, która rozwala produkcję. Konwencje w wiki zespołu są jeszcze słabsze. Jedyne, co może zagwarantować że dane zachowanie wystąpi za każdym razem, to sam harness: hook, którego agent nie może wyłączyć, skonfigurowany przez managed policy, której użytkownik nie może nadpisać, blokujący wywołanie toola zanim ono się ziści.

CTO, którzy maksują Q17, przestali polegać na intencji i zaczęli polegać na enforcement. Zidentyfikowali ścieżki plików, gdzie żyją destrukcyjne zmiany — migrations/, terraform/, infra/, src/lib/auth/, wszystko co matchuje *.sql — i zbudowali hook PreToolUse, który odmawia, by Edit lub Write dotknęło tych ścieżek bez zatwierdzonego planu Plan mode. Hook jest dostarczany przez managed policy. Managed policy jest dostarczana przez MDM. Nowi inżynierowie dostają bramkę pierwszego dnia i dowiadują się o niej pierwszego razu, gdy próbują ją ominąć.

Dźwignia jest ogromna, bo failure mode, które Plan mode łapie, to dokładnie te, które budzą cię o 2 w nocy. Zrzucona kolumna. Obcięty indeks. terraform destroy na złym workspace. Force push schematu auth. To nie są bugi, które łapie code review — to są bugi, które są już na produkcji zanim review w ogóle się zacznie. Hook oparty o managed policy przesuwa bramkę z „po szkodzie” na „zanim agent w ogóle zdąży to zrobić”.

Jak naprawdę wygląda „max score”

Odpowiedź Q17 na max ma cztery elementy, wszystkie działające razem. Pominij jeden, a spadasz tier niżej.

1 · Inwentarz ścieżek wrażliwych (zacommitowany do repo)
  └── .claude/sensitive-paths.json (lub odpowiednik)
        - migrations/**, drizzle/**, *.sql
        - terraform/**, infra/**, k8s/**, *.tf
        - src/lib/auth/**, src/middleware/**
        - .github/workflows/**, wrangler.toml
        - dowolne ścieżki kodu obsługujące sekrety

2 · Hook PreToolUse gatujący Edit/Write/Bash
  └── .claude/hooks/require-plan-mode.sh
        - czyta sensitive-paths.json
        - sprawdza, czy sesja ma zatwierdzony plan Plan mode
        - jeśli ścieżka matchuje i brak planu: exit 2 (block)
        - zapisuje każdy block + override do audit logu

3 · Managed policy wdrażająca hook w skali organizacji
  └── managed-settings.json
        - hooks.PreToolUse referencuje ścieżkę skryptu
        - skrypt dostarczany przez dotfiles albo MDM
        - użytkownicy nie mogą wyłączyć przez disableAllHooks

4 · Jawny escape hatch + audit log
  └── --i-have-a-plan flag lub podpisany plik z planem
        - awaryjna ścieżka dla legitymnych hotfixów
        - każde użycie pisze do ~/.claude/plan-overrides.log
        - audit log shipowany do centralnego log store co tydzień

Słowem kluczowym jest enforced. Dokument mówiący „proszę używać Plan mode” to tier „Reactive”. Przypomnienie w CLAUDE.md to „Coordinated”. Hook w .claude/settings.json projektu, który każdy developer może lokalnie wyłączyć — to maksimum „Optimized”. Dopiero hook dostarczany przez managed policy, referujący zacommitowaną listę wrażliwych ścieżek, blokujący przez exit 2 i logujący każdy block i override do centralnego audit traila stawia cię w „Strategic Leader”.

Aktualny krajobraz (zweryfikowany web search)

Managed policy w Claude Code (settings.json wdrażany przez admina)

Warstwa managed-settings to to, co w ogóle umożliwia „hard-enforced”. Anthropic wypuścił managed settings jako część planów Team/Enterprise: plik JSON na maszynie każdego developera, rozwiązywany przed user settings, project settings i CLI flagami. Cokolwiek tam ustawisz, nie może być nadpisane przez flagę developera ani przez plik projektowy. Ścieżki są zależne od OS:

macOS:        /Library/Application Support/ClaudeCode/managed-settings.json
Linux/WSL:    /etc/claude-code/managed-settings.json
Windows:      C:\ProgramData\ClaudeCode\managed-settings.json

Dla enforcementu Plan mode dwie dźwignie managed-policy mają największe znaczenie. Po pierwsze, hooks.PreToolUse deklaruje skrypt, który odpala się przed każdym wywołaniem toola — agent nie może iść dalej, dopóki skrypt nie zwróci czystego exitu. Po drugie, disableAllHooks: true ustawione na poziomie user, project lub local nie może wyłączyć hooków managed-policy — jedynie disableAllHooks ustawione w samym managed tier może. Ta asymetria to cały sens: organizacja może wypuścić bramkę Plan mode, której developer w pośpiechu fizycznie nie wyłączy.

Kody wyjścia mają tu znaczenie. Developerzy domyślnie sięgają po exit 1, bo to uniksowa konwencja na „polecenie nie wyszło”. Claude Code traktuje exit 1 jako non-blocking error i wywołuje toola mimo to. Dla enforcementu policy musisz exit 2. Pomyl się w tym jednym detalu, a twój hook stanie się grzeczną linijką w logu zamiast realnego blocku — failure mode, który ujawnia się dokładnie tego dnia, kiedy ktoś rozwala produkcję, a ty odkrywasz, że bramka była wyłączona.

Hook blokujący Edit/Write na wrażliwych ścieżkach bez planu

Sam hook jest krótki. Odpala się jako event PreToolUse, dostaje pending tool call na stdin, decyduje czy ścieżka jest wrażliwa, i decyduje czy sesja ma ważny plan. Jeśli wrażliwa i brak planu — exituje 2 z jasnym komunikatem wyjaśniającym, jak ponowić w Plan mode.

#!/usr/bin/env bash
# Hook PreToolUse: blokuje Edit/Write/Bash na wrażliwych ścieżkach bez Plan mode.
# Exit 2 = block (konwencja policy Claude Code). Exit 0 = allow.

set -euo pipefail

INPUT="$(cat)"  # JSON: { tool, params, session_id, ... }
TOOL=$(jq -r '.tool' <<<"$INPUT")

# Gatuj tylko narzędzia write-side. Reads przepuszczamy.
case "$TOOL" in
  Edit|Write|MultiEdit|NotebookEdit) ;;
  Bash)
    CMD=$(jq -r '.params.command // ""' <<<"$INPUT")
    # Allow read-only bash. Gatuj writes, sieć, cokolwiek destrukcyjnego.
    case "$CMD" in
      ls*|cat*|grep*|rg*|head*|tail*|git\ status*|git\ diff*|git\ log*) exit 0 ;;
    esac
    ;;
  *) exit 0 ;;
esac

# Wyciągnij target path(s) dla file-write tooli.
TARGET=$(jq -r '.params.file_path // .params.notebook_path // empty' <<<"$INPUT")

# Wzorce wrażliwych ścieżek, zacommitowane w .claude/sensitive-paths.json.
PATTERNS=$(jq -r '.patterns[]' "$CLAUDE_PROJECT_DIR/.claude/sensitive-paths.json")

is_sensitive=false
for p in $PATTERNS; do
  case "$TARGET" in
    $p) is_sensitive=true; break ;;
  esac
done

# Gatuj też komendy bash matchujące destrukcyjne wzorce.
if [ "$TOOL" = "Bash" ]; then
  CMD=$(jq -r '.params.command' <<<"$INPUT")
  case "$CMD" in
    *"drizzle-kit push"*|*"prisma migrate deploy"*|*"terraform apply"*\
    |*"kubectl apply"*|*"wrangler d1 execute"*|*"rm -rf"*) is_sensitive=true ;;
  esac
fi

[ "$is_sensitive" = false ] && exit 0

# Ścieżka wrażliwa. Czy sesja jest w Plan mode z zatwierdzonym planem?
PLAN_FILE="${CLAUDE_PROJECT_DIR}/.claude/plans/${CLAUDE_SESSION_ID}.md"
if [ -f "$PLAN_FILE" ] && [ "$(stat -f%z "$PLAN_FILE" 2>/dev/null || stat -c%s "$PLAN_FILE")" -gt 200 ]; then
  # Plan istnieje i jest nietrywialny. Allow, ale loguj.
  echo "$(date -u +%FT%TZ) ALLOW $TOOL $TARGET session=$CLAUDE_SESSION_ID" \
    >> "$HOME/.claude/plan-audit.log"
  exit 0
fi

# Block, z jasnym komunikatem na stderr.
cat >&2 <<MSG
Wymagany Plan mode dla wrażliwej zmiany.

Tool:   $TOOL
Target: $TARGET

Ta ścieżka jest objęta firmową polityką Plan mode. Aby kontynuować:
  1. Przełącz na Plan mode (Shift+Tab dwa razy).
  2. Sporządź plan; zostanie zapisany do .claude/plans/.
  3. Zatwierdź plan, by wyjść z Plan mode.
  4. Ponów wywołanie toola — zostanie dopuszczone i zaudytowane.

Ścieżka override (tylko incident hotfix): touch .claude/plans/\${CLAUDE_SESSION_ID}.override
Każdy override jest logowany do ~/.claude/plan-audit.log i shipowany co tydzień do audit store.
MSG

echo "$(date -u +%FT%TZ) BLOCK $TOOL $TARGET session=$CLAUDE_SESSION_ID" \
  >> "$HOME/.claude/plan-audit.log"
exit 2

Skrypt jest celowo krótki. Długie hooki stają się niemaintaninowalne; nikt ich nie reviewuje, drift się wkrada, bramka po cichu słabnie. Trzymaj poniżej 80 linii, zacommituj do centralnego repo w stylu dotfiles, podpisuj commity i pozwól MDM-owi pushować go do ~/.claude/hooks/ każdego developera przy pierwszym loginie.

Cursor Team Rules

Odpowiednikiem warstwy enforcementu w Cursorze są Team Rules: reguły definiowane przez org-admina, które propagują do każdego workspace w Cursor team, siedzące nad user rules i project rules w łańcuchu precedensu. Cursor nie wystawia hooka PreToolUse w tej samej formie co Claude Code, ale Team Rules mogą deklarować „Plan mode wymagany dla migrations/** i terraform/**” jako hard rule, którą agent traktuje jako nienegocjowalną.

Dla orgów Cursor-first praktyczny wzorzec: wypuść regułę przez Team Rules, by agent odmawiał działania bez planu, i nałóż warstwę guardraila po stronie serwera (pre-commit hook, server-side branch protection, OPA policy w CI), który łapie wszystko, co się prześliźnie. Enforcement w Cursorze jest miększy niż kombinacja managed-policy + PreToolUse Claude Code, więc warstwa CI ma większe znaczenie.

Jeśli twoja organizacja używa obu narzędzi, lustrzanie odbij bramkę po obu stronach. Pokrycie połowiczne jest gorsze niż brak pokrycia, bo tworzy fałszywe poczucie bezpieczeństwa.

Co znaczy „wrażliwy” w twojej organizacji (DB, infra, security, auth)

Lista wrażliwych ścieżek to najważniejszy artefakt w całym tym setupie, bo bramka jest tak dobra, jak wzorce, których pilnuje. Zrób ją za wąską — agent ją obejdzie; zrób za szeroką — developerzy nauczą się ją bypassować. Realistyczny baseline dla większości produkcyjnych codebase’ów:

Baza danych: migrations/**, drizzle/**, prisma/migrations/**, *.sql, scripts/schema*.sql, wszystko co mutuje schemat.
Infrastruktura: terraform/**, infra/**, k8s/**, *.tf, wrangler.toml, Dockerfile, deployment manifests.
Security: src/lib/auth/**, src/middleware/**, wszystko obsługujące tokeny, sesje, OAuth callbacks, macierze RBAC.
Sekrety-adjacent: .env* (tylko szablony — realne sekrety nigdy w repo), *.tfvars, wywołania wrangler secret.
CI/CD: .github/workflows/**, .gitlab-ci.yml, wszystko co odpala się w pipeline’ach deploy.
Destrukcyjne wzorce bash: drizzle-kit push, prisma migrate deploy, terraform apply, kubectl apply, wrangler d1 execute, rm -rf, git push --force.

Zacommituj listę do repo jako .claude/sensitive-paths.json. Przeglądaj co kwartał jako część rules audit. Gdy zdarzy się incydent, post-mortem powinien zadać pytanie „czy bramka by to złapała?” i zaktualizować listę, jeśli odpowiedź brzmi „nie”.

Krok po kroku: wdrażanie hard-enforced Plan mode

Zinwentaryzuj wrażliwe ścieżki, zanim napiszesz pierwszą linijkę kodu hooka.

Przejdź każde aktywne produkcyjne repo. Wylistuj każdy katalog i wzorzec pliku, który — gdyby agent po cichu go przepisał — spowodowałby incydent. Migracje DB, infrastructure-as-code, auth middleware, CI pipelines, obsługa sekretów. Wyciągnij listę z głowy jednego inżyniera i przenieś do .claude/sensitive-paths.json, zacommitowanej i zrewiewowanej.
Napisz hook najpierw na najmniejszej możliwej powierzchni.

Zacznij od samego migrations/**. Doprowadź skrypt PreToolUse do działania end-to-end: czyta input, identyfikuje toola, sprawdza ścieżkę, exituje 2 z jasnym komunikatem, gdy ścieżka matchuje i plan nie jest dołączony. Pouruchamiaj lokalnie przez tydzień, zanim go wypuścisz. Potwierdź, że exit 2 faktycznie blokuje — wiele zespołów odkrywa, że ich hook to po cichu no-op, bo użyli exit 1.
Zdecyduj, co znaczy „ma plan” w twoim środowisku.

Dwa działające wzorce. Po pierwsze, plik planu na dysku: gdy użytkownik zatwierdzi plan w Plan mode Claude Code, zapisz markdown do .claude/plans/<session_id>.md i pozwól hookowi sprawdzić jego obecność. Po drugie, trace marker: oprzyj się o zmienną środowiskową w sesji albo flagę przekazywaną przez agenta. Wzorzec z plikiem planu jest prostszy do audytu i działa cross-tool — wybierz ten, chyba że masz powód, żeby tego nie robić.
Dodaj escape hatch dla realnych awarii.

Hook czasem się pomyli. Produkcyjny hotfix o 3 w nocy nie może czekać na pełen cykl draftowania planu. Zapewnij udokumentowany override: touch .claude/plans/<session_id>.override albo flagę CLI --i-have-a-plan. Każdy override pisze wiersz w audit logu z timestampem, użytkownikiem, repo, ścieżką i toolem. Override’y nie są zakazane — są logowane.
Dostarcz hook przez managed policy, nie przez project settings.

Hook w .claude/settings.json jest do obejścia; każdy developer może usunąć plik albo lokalnie ustawić disableAllHooks: true. Ten sam hook referencowany z managed-settings.json przeżywa każde lokalne nadpisanie. Wrzuć skrypt do centralnego repo w stylu dotfiles, pushuj do ~/.claude/hooks/require-plan-mode.sh przez MDM albo bootstrap script z weryfikacją hasha i referencuj z managed file.
Odbij lustrzanie bramkę w Cursor Team Rules (jeśli dotyczy).

Jeśli część organizacji używa Cursora, wypuść równoważną regułę przez Team Rules, by developer pracujący w Cursorze nie miał niezabezpieczonej drogi. Brzmienie: „Dla dowolnej zmiany w migrations/, terraform/ lub src/lib/auth/ musisz najpierw wytworzyć plan. Nie edytuj plików w tych katalogach bez jawnego potwierdzenia planu przez użytkownika.”
Dodaj backstop po stronie CI dla wszystkiego, co się prześliźnie.

Nawet z hookiem zakładaj, że jakieś zmiany uciekną — agent na nie-managed maszynie, developer na forku, użytkownik Cursora bez Team Rules. Branch protection plus zadanie CI, które sprawdza „PR-y dotykające migrations/** wymagają labela plan-approved, nałożonego przez osobnego ludzkiego reviewera”, łapie resztę. Defence in depth: hook to tania bramka, CI to droga.
Podłącz audit log do centralnego log store.

Każdy block, każdy override, każde „allow” na wrażliwej ścieżce pisze wiersz do ~/.claude/plan-audit.log. Shipuj ten plik do centralnego log store co noc (S3, Datadog, Loki, cokolwiek używasz). Gdy musisz odpowiedzieć „czy agent zmienił tę migrację bez planu?”, odpowiedź powinna być jednym zapytaniem dalej, nie „pozwól, że ssh-uję się na czyjegoś laptopa”.
Przeprowadź tabletop exercise w drugim tygodniu.

Wybierz najstraszniejszy realistyczny failure mode — powiedzmy „agent w sesji bez Plan mode przepisuje auth.ts i pushuje do brancha”. Spróbuj to zrobić. Jeśli hook cię zablokuje — dobrze. Jeśli cokolwiek w łańcuchu cię przepuści, napraw to, zanim ruszysz dalej. Tabletop exercises łapią awarie, które realne incydenty odkryłyby w najgorszym możliwym momencie.
Powtarzaj audyt wrażliwych ścieżek co kwartał.

Codebase się zmienia. Pojawiają się nowe katalogi obsługujące wrażliwe sprawy. Stare są deprekowane. Audyt to 30-minutowy meeting raz na kwartał: otwórz repo, przejdź drzewo katalogów, zadaj pytanie „czy byłbym nieszczęśliwy, gdyby agent po cichu to przepisał bez planu?”. Zaktualizuj sensitive-paths.json odpowiednio, zacommituj, wypchnij.

Częste pułapki

Zbyt szeroka bramka, ucząca developerów ją bypassować. Jeśli hook odpala się na każdy Edit pliku *.md albo każdy read-only Bash, developerzy ustawią disableAllHooks: true w swojej osobistej konfiguracji — i bramki nie ma. Trzymaj wzorce wąskie. Właściwa zasada to „gdyby agent po cichu to zmienił, byłbym wezwany do incydentu” — nie „ten plik jest jakoś ważny”.

Brak escape hatcha. Hook bez ścieżki override to bramka, która zostanie wyrwana z korzeniami pierwszego razu, gdy stanie na drodze produkcyjnemu hotfixowi. Właściwa odpowiedź to „override’y są dozwolone i logowane”. Zrób override trudniejszy niż happy path — manualne dotknięcie pliku, flaga CLI, token [override] w commit message — ale nigdy niemożliwy.

exit 1 zamiast exit 2. Najczęstszy błąd w pisaniu hooków Claude Code. exit 1 produkuje linijkę logu, a wywołanie toola idzie dalej. exit 2 faktycznie blokuje. Zweryfikuj jednolinijkowym testem dnia, w którym wypuszczasz hook, a potem co kwartał — bo jedyne, co jest gorsze niż brakująca bramka, to taka, o której myślisz, że istnieje.

Hook w .claude/settings.json projektu zamiast w managed policy. Bramka, którą każdy developer wyłącza lokalnie jedną linijką JSON-a, jest teatrem, nie enforcementem. Hook musi pochodzić z warstwy managed-settings — to jedyna warstwa, gdzie disableAllHooks go nie dosięgnie.

Brak audit logu. Jeśli hook zablokuje akcję i nikt o tym nie wie, bramka jest niewidoczna dla leadership. Jeśli hook przepuści akcję (legalnie albo przez override) i nikt o tym nie wie, nie da się prześledzić incydentów do „czy bramka była aktywna?”. Każdy block, każdy allow na wrażliwej ścieżce, każdy override pisze wiersz. Shipuj log centralnie.

Plan mode wymagany, ale brak treningu z Plan mode. Inżynierowie, którzy nigdy nie używali Plan mode, traktują bramkę jako friction i nią się rzucają. Dwie godziny treningu w pierwszym tygodniu wdrożenia — „tak draftujemy plan, tak iterujemy, tak zatwierdzamy” — zmienia bramkę z „irytującej” na „sposób, w jaki pracujemy”.

Skrypt hooka żyje w dotfilesach jednego inżyniera. Jeśli kanoniczny skrypt hooka jest w repo jednej osoby i ta osoba odejdzie, bramka staje się niemaintaninowalna. Przenieś do team-owned repo ai-platform-internal albo dotfiles, z podpisanymi commitami i realnym procesem review PR-ów.

Traktowanie hooka jako substytutu code review. Bramka zapobiega cichym destrukcyjnym zmianom. Nie zapobiega intencjonalnie złym zmianom inżyniera, który myli się co do tego, co robi. Plan mode + hook to jedna warstwa; PR review przez człowieka, który rozumie system, to inna. Obie są wymagane.

Zapominanie o użytkownikach Cursora. Managed-policy hook w Claude Code nie robi nic dla developerów na Cursorze. Jeśli organizacja używa obu narzędzi, a gatujesz tylko jedno — stworzyłeś niezabezpieczoną drogę, którą znajdzie zły incydent. Lustrzanie odbij bramkę albo wybierz jedno narzędzie.

Jak zweryfikować, że jesteś na miejscu

Dalsza lektura

Q5 · Wspólne reguły agenta Managed policy + per-repo CLAUDE.md + .claude/rules/ — hierarchia reguł, przez którą jedzie twój hook Plan mode.

Q10 · Gates vs guardrails Policy w design-time bije per-PR review w zarządzaniu review bandwidth. Plan mode to kanoniczna bramka design-time.

Q18 · Governance hooków Repo hooków, auto-install via dotfiles, podpisane i audytowane skrypty — mechanizm dostawy hooka Plan mode.

Zrób CTO Scorecard 25 pytań, ~12 minut. Ocena tier + plan 30/60/90 + risk register.