Imported from PixelSculptor/osce-triager (.claude/skills/10x-shape/SKILL.md). Install upstream with npx skills add PixelSculptor/osce-triager --skill 10x-shape. Copyright stays with the author.

Shape: Ułatwianie odkrywania (Greenfield & Brownfield) Przed /10x-prd

Ta umiejętność jest początkiem łańcucha rozruchowego. Dla greenfield: /10x-shape → /10x-prd → 10x-tech-stack-selector → bootstrapper. Dla brownfield: /10x-shape → /10x-prd → 10x-stack-assess → 10x-health-check. Jej jedyne zadanie: przeprowadzić użytkownika od "Mam pomysł" (greenfield) lub "Chcę zmienić ten system" (brownfield) do ustrukturyzowanego pliku context/foundation/shape-notes.md, który /10x-prd może przekształcić w PRD zgodny z zablokowanym schematem.

Umiejętność ta jest facylitatorem, a nie generatorem treści. NIGDY nie pisze wizji, wymagań funkcjonalnych, zasad logiki biznesowej ani żadnych innych treści domenowych, których użytkownik nie powiedział. Jej wartość tkwi w kształcie pytań i ich kolejności, a nie w oferowanych odpowiedziach.

Zablokowany schemat, do którego dostosowują się zarówno ta umiejętność, jak i /10x-prd, znajduje się w references/prd-schema.md (względem tego SKILL.md). Przeczytaj go przed wytworzeniem jakiegokolwiek artefaktu i ponownie sprawdź go przy każdym zapisie punktu kontrolnego.

Kiedy używać, kiedy pominąć

Użyj, gdy: użytkownik opisuje nowy pomysł na projekt (greenfield), znaczącą zmianę w istniejącym systemie — nowy moduł, istotną funkcję, ulepszenie architektury (brownfield) lub produkt, który chce przebudować od podstaw. Użyj również, gdy istniejący context/foundation/shape-notes.md jest niekompletny i wymaga wznowienia. Umiejętność automatycznie wykrywa typ kontekstu na podstawie znaczników projektu w bieżącym katalogu roboczym i dostosowuje się.

Pomiń, gdy: projekt ma już PRD lub zestaw ADR (użyj zamiast tego /10x-frame lub /10x-plan), lub użytkownik rozważa pojedynczy błąd / refaktoryzację / małą funkcję w istniejącej bazie kodu, która nie wymaga pełnego PRD (użyj /10x-frame). W przypadku projektów brownfield, gdzie użytkownik chce ukształtować znaczącą zmianę, ta umiejętność JEST właściwym punktem wyjścia.

Relacje z innymi umiejętnościami

• /10x-init — tworzy szkielet /context (changes/, archive/, foundation/) oraz uniwersalne pliki README w każdym z nich. /10x-shape wymaga istnienia context/foundation/; jeśli go brakuje, deleguje do /10x-init za pomocą narzędzia Skill (Krok 0 poniżej).
• /10x-prd — konsumuje shape-notes.md. Przekazanie to zapis do schowka w ## Krok 8.
• /10x-frame — do przeformułowania problemów o małym zakresie w istniejących systemach, gdzie pełne PRD jest przesadą. /10x-shape jest przeznaczony do większych zmian brownfield (nowe moduły, znaczące funkcje), które wymagają ustrukturyzowanego odkrywania i PRD.
• /10x-stack-assess — następny po /10x-prd dla projektów brownfield. Ocenia istniejący stos pod kątem bram jakości.
• /10x-health-check — następny po /10x-stack-assess dla brownfield. Audytuje istniejący stan projektu.
• /10x-plan — następny po /10x-prd, nigdy nie wywoływany bezpośrednio stąd.

Początkowa odpowiedź

Gdy ta umiejętność zostanie wywołana:

1. Jeśli jako argument podano swobodny pomysł (np. /10x-shape aplikacja z przepisami, która sugeruje posiłki z tego, co jest w lodówce), zapisz go dosłownie jako pomysł początkowy. Nie zmieniaj sformułowania. Przejdź do Kroku 0.
2. Jeśli podano ścieżkę pliku (np. /10x-shape @notes/idea.md), przeczytaj go W CAŁOŚCI i użyj jego zawartości jako pomysłu początkowego. Przejdź do Kroku 0.
3. Jeśli nic nie podano, odpowiedz:

Pomogę Ci ukształtować pomysł w ustrukturyzowane notatki, które /10x-prd może
przekształcić w prawdziwe PRD — niezależnie od tego, czy zaczynasz od zera
(greenfield), czy kształtujesz zmianę w istniejącym systemie (brownfield).

Proszę podziel się:
1. Pomysłem początkowym — co chcesz zbudować lub zmienić, własnymi słowami?
2. (Opcjonalnie) Wszelkimi wstępnymi notatkami, szkicami lub linkami, które
   powinienem przeczytać.

Wskazówka: przekaż pomysł w linii — `/10x-shape aplikacja z przepisami, która
     wykorzystuje zawartość lodówki`
     lub dla brownfield — `/10x-shape dodaj silnik rekomendacji do mojej
     aplikacji z przepisami`

Następnie poczekaj.

Proces

Krok 0: Sprawdź warunek wstępny 10xWorkflow

Sprawdź szkielet 10xWorkflow, testując dwie ścieżki:

test -d context/foundation

Jeśli istnieje, przejdź do Kroku 0.5.

Jeśli brakuje, projekt nie został zainicjowany dla 10xWorkflow. Zapytaj:

AskUserQuestion:

• question: "Ten katalog nie jest zainicjowany dla 10xWorkflow (brakuje context/foundation/). Uruchomić /10x-init teraz?" header: "Inicjalizacja?" options:
  • label: "Tak — uruchom /10x-init (Zalecane)" description: "Tworzy szkielet /context (changes/, archive/, foundation/) z plikami README, a następnie kontynuuje kształtowanie."
  • label: "Nie — zatrzymaj tutaj" description: "Wyjdź bez zmian. Będziesz musiał zainicjować przed uruchomieniem kształtowania." multiSelect: false

W przypadku "Tak": wywołaj /10x-init za pomocą narzędzia Skill (NIE za pomocą Bash). Gdy /10x-init zwróci wynik, ponownie sprawdź warunek wstępny; jeśli teraz przejdzie, kontynuuj do Kroku 0.5. W przypadku "Nie": wydrukuj "Zatrzymywanie. Uruchom /10x-init, gdy będziesz gotowy, a następnie ponownie wywołaj /10x-shape." i ZATRZYMAJ.

Nie duplikuj logiki szkieletu /10x-init. Narzędzie Skill jest poprawną ścieżką delegacji.

Krok 0.5: Wykrywanie wznowienia

Przed rozpoczęciem od nowa, sprawdź, czy istnieje poprzednia sesja:

test -f context/foundation/shape-notes.md

Jeśli brakuje, przejdź do Kroku 1 z nową sesją.

Jeśli istnieje, przeczytaj plik W CAŁOŚCI. Przeanalizuj blok checkpoint: w nagłówku YAML zgodnie z odniesieniem do schematu (references/prd-schema.md, sekcja "shape-notes.md checkpoint format"). Wyodrębnij: current_phase, phases_completed, frs_drafted, quality_check_status.

Podsumuj, co znalazłeś:

Znaleziono poprzednią sesję kształtowania w context/foundation/shape-notes.md:

  Projekt:                 [z pola projektu w nagłówku YAML, lub "(bez nazwy)"]
  Bieżąca faza:            [N — Nazwa fazy]
  Ukończone fazy:          [lista]
  Wymagania funkcjonalne (FRs) sporządzone do tej pory: [liczba]
  Status kontroli jakości: [oczekujące | ostrzeżenie | zaakceptowane]

Następnie zapytaj:

AskUserQuestion:

• question: "Jak chcesz postąpić?" header: "Wznowić?" options:
  • label: "Wznów od Fazy [następna] (Zalecane)" description: "Kontynuuj od miejsca, w którym zakończyła się poprzednia sesja. Ukończone fazy są podsumowywane, a nie odtwarzane."
  • label: "Rozpocznij od nowa" description: "Zarchiwizuj istniejący shape-notes.md do context/foundation/archive/ i rozpocznij nową sesję."
  • label: "Anuluj" description: "Wyjdź bez zmian." multiSelect: false

W przypadku "Wznów": przejdź bezpośrednio do następnej nieukończonej fazy (Krok current_phase + (1, jeśli bieżąca jest w phases_completed, w przeciwnym razie 0)). NIE uruchamiaj ponownie ukończonych faz — tylko podsumuj każdą z nich użytkownikowi w 1-2 zdaniach ("Faza 1 uchwyciła: ; Faza 2 uchwyciła: ; …"), aby miał kontekst tego, co już zostało ustalone.

W przypadku "Rozpocznij od nowa": przenieś istniejący plik do context/foundation/archive/shape-notes-<RRRR-MM-DD-GGMM>.md (utwórz katalog archiwum, jeśli go brakuje), a następnie przejdź do Kroku 1 z nową sesją.

W przypadku "Anuluj": ZATRZYMAJ bez zmian.

Krok 0.7: Wykrywanie typu kontekstu

Przed wejściem w pętlę odkrywania, określ, czy jest to sesja greenfield czy brownfield. Wykrywanie odbywa się raz; wynik (context_type) jest zapisywany w nagłówku YAML pliku shape-notes.md i rządzi zachowaniem fazy przez resztę sesji.

Automatyczne wykrywanie: oceń bieżący katalog roboczy w trzech poziomach sygnałów. Pojedynczy plik manifestu nie wystarczy — pusty katalog npm init -y nie powinien wywoływać brownfield.

# Poziom 1 (silny): kontrola wersji z historią
git log --oneline -1 2>/dev/null && echo "T1:git-history"

# Poziom 2 (średni): pliki lockfiles dowodzą, że nastąpiło rzeczywiste rozwiązywanie zależności
ls package-lock.json yarn.lock pnpm-lock.yaml Cargo.lock poetry.lock go.sum Gemfile.lock composer.lock 2>/dev/null | while read f; do echo "T2:$f"; done

# Poziom 3 (słaby): same pliki manifestu — może to być świeża inicjalizacja
ls package.json Cargo.toml pyproject.toml go.mod Gemfile composer.json 2>/dev/null | while read f; do echo "T3:$f"; done

# Dodatkowe sygnały (potwierdzają, ale nie wywołują samodzielnie): katalogi źródłowe, konfiguracje frameworków, CI
ls -d src/ app/ lib/ .github/ .gitlab-ci.yml Dockerfile tsconfig.json next.config.* vite.config.* 2>/dev/null | while read f; do echo "B:$f"; done

# PowerShell (Windows) — użyj tego bloku zamiast powyższego bloku bash w powłokach Windows.
# NIE pozwól, aby tłumacz bash→PowerShell przepisał blok bash: wzorzec `while read f; do echo "B:$f"`
# generuje dosłowny ciąg "B:$f", który Windows interpretuje jako dysk `B:`, wywołując
# monit o uprawnienia dla nieistniejącego dysku.

# Poziom 1 (silny): kontrola wersji z historią
if (git log --oneline -1 2>$null) { "T1:git-history" }

# Poziom 2 (średni): pliki lockfiles dowodzą, że nastąpiło rzeczywiste rozwiązywanie zależności
@('package-lock.json','yarn.lock','pnpm-lock.yaml','Cargo.lock','poetry.lock','go.sum','Gemfile.lock','composer.lock') |
  Where-Object { Test-Path -LiteralPath $_ } | ForEach-Object { "T2:$_" }

# Poziom 3 (słaby): same pliki manifestu — może to być świeża inicjalizacja
@('package.json','Cargo.toml','pyproject.toml','go.mod','Gemfile','composer.json') |
  Where-Object { Test-Path -LiteralPath $_ } | ForEach-Object { "T3:$_" }

# Dodatkowe sygnały (potwierdzają, ale nie wywołują samodzielnie): katalogi źródłowe, konfiguracje frameworków, CI
@('src','app','lib','.github','.gitlab-ci.yml','Dockerfile','tsconfig.json') |
  Where-Object { Test-Path -LiteralPath $_ } | ForEach-Object { "B:$_" }
Get-ChildItem -Path . -Filter 'next.config.*' -File -ErrorAction SilentlyContinue |
  ForEach-Object { "B:$($_.Name)" }
Get-ChildItem -Path . -Filter 'vite.config.*' -File -ErrorAction SilentlyContinue |
  ForEach-Object { "B:$($_.Name)" }

Punktacja:

• Trafienie Poziomu 1 (istnieje historia git) → silny sygnał brownfield
• Trafienie Poziomu 2 (istnieje plik lockfile) → silny sygnał brownfield
• Poziom 1 + Poziom 2 → brownfield o wysokiej pewności
• Tylko Poziom 3 (manifest, brak pliku lockfile, brak git) → niejednoznaczne — może to być świeży npm init
• Brak sygnałów → greenfield

Logika decyzji:

• Dowolne trafienie Poziomu 1 lub Poziomu 2 → proponuj context_type: brownfield
• Tylko Poziom 3 → proponuj brownfield, ale zaznacz niejednoznaczność: "Znalazłem plik manifestu, ale brak pliku lockfile lub historii git — może to być świeżo zainicjowany projekt, a nie prawdziwy brownfield."
• Brak sygnałów → proponuj context_type: greenfield

Wydrukuj, co zostało wykryte:

• Brownfield o wysokiej pewności (T1 lub T2):

  Wygląda na istniejący projekt:
    [lista wykrytych sygnałów, np. "historia git (47 commitów)", "package-lock.json", "katalog src/"]
  Będę działać w trybie brownfield — skupiając się na tym, co istnieje, co się zmienia,
  i co musi zostać zachowane.
  

• Niejednoznaczne (tylko T3):

  Znalazłem [plik manifestu], ale brak pliku lockfile lub historii git — może to być
  świeżo zainicjowany projekt lub prawdziwy brownfield. Zaproponuję tryb brownfield,
  ale zmienię na greenfield, jeśli zaczynasz od zera.
  

• Greenfield (brak sygnałów):

  Nie znaleziono znaczników projektu w tym katalogu — będę działać w trybie greenfield,
  co zakłada, że zaczynasz od zera.
  

Następnie potwierdź z użytkownikiem:

AskUserQuestion:

• question: "Wykryty kontekst: [greenfield|brownfield]. Czy to poprawne?" header: "Kontekst" options:
  • label: "[Greenfield|Brownfield] — poprawne (Zalecane)" description: "[Opis trybu automatycznie wykrytego]"
  • label: "[Inny tryb] — nadpisz" description: "Zamiast tego przełącz na [inny tryb]." multiSelect: false

Natychmiast zapisz potwierdzony context_type w nagłówku YAML pliku shape-notes.md (obok checkpoint:). Ta wartość jest kluczowa dla automatycznego routingu /10x-prd.

Przy wznowieniu (Krok 0.5), jeśli shape-notes.md ma już context_type: w nagłówku YAML, pomiń automatyczne wykrywanie — tryb jest zablokowany z poprzedniej sesji.

Wzorzec odkrywania (dotyczy każdego z poniższych Kroków 1-6)

Każda faza odkrywania przebiega według tej samej pętli. Zinternalizuj to przed przeczytaniem kroków dla poszczególnych faz; zawartość dla poszczególnych faz to to, o co pytać, a nie jak pytać.

Wzorzec to BMAD-Facilitator + GSD-Gray-Area + mattpocock-recommended-answer + Socrates challenge:

1. Rozpocznij fazę jednolinijkowym stwierdzeniem, co ta faza produkuje, i jednym otwartym pytaniem, aby wywołać pierwszą próbę użytkownika. (Postawa facylitatora BMAD: nigdy nie generuj treści samodzielnie.)
2. Wyprowadź 3-5 szarych stref jako decyzje wielokrotnego wyboru, gdy pierwsza próba użytkownika zawiera niejasności. Użyj AskUserQuestion. Każda opcja to prawdziwa pozycja z kompromisem, a nie symbol zastępczy. (Odkrywanie szarych stref GSD.)
3. Oznacz zalecaną opcję jako "(Zalecane)" w etykiecie i umieść ją na pierwszym miejscu. Zawsze dołącz opcję "Nie jestem pewien / nie zdecydowałem". (mattpocock-recommended-answer, łagodzenie zmęczenia.)
4. Zablokuj decyzję z powrotem u użytkownika jako jednolinijkowe podsumowanie, które potwierdza, zanim zapiszesz na dysku.
5. Zapisz sekcje fazy do shape-notes.md i zwiększ checkpoint.current_phase oraz checkpoint.phases_completed zgodnie ze schematem.

Twarde zasady:

• NIGDY nie generuj treści, których użytkownik nie powiedział. Jeśli sekcja potrzebuje wartości, której użytkownik nie podał, zapytaj — nie wymyślaj. Wyjątkiem jest formatowanie mechaniczne (numeracja FR-NNN, nagłówki sekcji, szkielet nagłówka YAML).
• NIGDY nie zobowiązuj się z góry do stosu technologicznego (framework, baza danych, platforma hostingowa, rodzina języków). PRD zawiera tylko priorytety na poziomie produktu — product_type, target_scale, timeline_budget. Kwestie związane ze stosem są zbierane po /10x-prd.
• NIGDY nie używaj języka 10xDevs / kohorty / certyfikacji w dostarczanym wyniku. Mechanika tutaj to uniwersalne wskaźniki dobrze zdefiniowanego projektu. Artefakt skierowany do użytkownika wygląda jak ogólna umiejętność kształtowania.

Krok 1: Wizja i problem

Ta faza tworzy sekcje ## Vision & Problem Statement i ## User & Persona (tylko główna persona) w shape-notes.md. Dwie sekcje, a nie jedna, ponieważ persona wiąże problem. Brownfield tworzy również sekcję ## Current System.

Tryb Greenfield

Rozpocznij od: "Zacznijmy od bólu. W jednym lub dwóch zdaniach — kto go odczuwa, w którym momencie go odczuwa, ile go to dziś kosztuje?"

Słuchaj. Powtórz trzy komponenty oddzielnie:

Ból:         [dosłowny problem]
Osoba:       [kto go odczuwa — nazwij rolę, a nie "użytkowników"]
Moment:      [kiedy go odczuwa — sytuacja, która wywołuje ból]
Koszt dziś:  [co obecnie robią i ile ich to kosztuje]

Jeśli którykolwiek z czterech jest niejasny ("wszyscy", "zawsze", "dużo bólu"), zakwestionuj go pytaniem Sokratesa: "Co musiałoby być prawdą, aby to był zły problem do rozwiązania?" lub "Kogo konkretnie widziałeś, kto doświadczył tego w ostatnim miesiącu?"

Następnie wyprowadź szare strefy (użyj AskUserQuestion z 2-4 pytaniami, multiSelect w pytaniach, gdzie wiele pozycji może współistnieć):

• Kategoria bólu — jaki to rodzaj bólu? (tarcie w przepływie pracy / brakująca funkcja / dane uwięzione gdzieś / paraliż decyzyjny / narzut koordynacji / inne)
• Wgląd — co użytkownik wie, czego nie wie status quo? (użyj Sokratesa: "Jeśli twój pomysł jest oczywisty, dlaczego to nie zostało zbudowane?")
• Zakres głównej persony — kto dokładnie? (konkretna rola w organizacji / osoby w wielu organizacjach / jeden konkretny użytkownik, w tym ty sam / niszowe hobby / nie jestem pewien)

Tryb Brownfield

Rozpocznij od: "Zacznijmy od obecnego systemu. W kilku zdaniach — co istnieje dzisiaj, kto tego używa i jaki jest punkt bólu lub brakująca funkcja, która napędza tę zmianę?"

Słuchaj. Powtórz pięć komponentów oddzielnie:

Obecny system:  [co istnieje — nazwij produkt/usługę/moduł]
Stos technologiczny: [języki, frameworki, infrastruktura, o których wspomina użytkownik]
Użytkownicy:    [kto tego używa dzisiaj — nazwij role, a nie "użytkowników"]
Ból / luka:    [co jest nie tak lub czego brakuje — wyzwalacz tej zmiany]
Musisz zachować: [co NIE MOŻE się zepsuć — istniejące zachowanie, integracje, dane]

Jeśli użytkownik nie potrafi sprecyzować "musisz zachować", zakwestionuj go pytaniem: "Gdyby ta zmiana jutro coś zepsuła, co by cię zaalarmowało?" lub "Co twoi obecni użytkownicy zauważyliby najpierw?"

Następnie wyprowadź szare strefy:

• Kategoria zmiany — jaki to rodzaj zmiany? (nowy moduł / znacząca funkcja / ulepszenie architektury / migracja / integracja / inne)
• Wgląd — co użytkownik wie o obecnym systemie, co sprawia, że ta zmiana nie jest oczywista? (Sokrates: "Dlaczego to nie zostało jeszcze zrobione?")
• Zakres głównej persony — tak samo jak w greenfield

Najpierw napisz sekcję ## Current System (sekcja tylko dla brownfield — opisuje, co istnieje), następnie ## Vision & Problem Statement (przeformułowane jako delta: co się zmienia i dlaczego), a następnie ## User & Persona.

Oba tryby

Zablokuj przechwyconą treść, dopasowując ją do struktury sekcji schematu. Dołącz do shape-notes.md. Zwiększ checkpoint.current_phase: 2 i dodaj 1 do checkpoint.phases_completed.

Krok 2: Persona i kontrola dostępu

Ta faza tworzy sekcję ## Access Control. Persona została przechwycona w Kroku 1; tutaj pytamy, jak persona dociera do produktu.

Tryb Greenfield

Rozpocznij od: "Jak ta osoba dostaje się do aplikacji? Logowanie, profil lokalny, klucz dostępu, czy w ogóle bez uwierzytelniania?"

Użyj AskUserQuestion z opcjami zaczerpniętymi z najczęstszych form:

• Logowanie (e-mail + hasło / OAuth / bezhasłowe) (Zalecane dla wieloużytkownikowych aplikacji webowych/mobilnych)
• Profil lokalny (dane przechowywane na urządzeniu, brak serwera) (Zalecane dla pojedynczych użytkowników / priorytet prywatności)
• Klucz dostępu (link lub token; brak tworzenia konta)
• N/A — pojedynczy użytkownik, pojedyncze urządzenie, brak separacji

Jeśli odpowiedź jest inna niż N/A, zadaj jedno pytanie uzupełniające dotyczące separacji ról: czy jest to płaski model użytkownika, czy istnieją role (np. administrator / członek / gość), które widzą różne rzeczy? Sokrates: "Jaki jest najmniejszy model dostępu, który nadal sprawiłby, że MVP byłby użyteczny?"

Tryb Brownfield

Rozpocznij od: "Opisz obecne uwierzytelnianie i role użytkowników w tym systemie. Jak użytkownicy logują się dzisiaj i jakie role istnieją?"

Słuchaj. Następnie zapytaj, co się zmienia:

• "Czy model uwierzytelniania zmienia się w ramach tej pracy?" (tak — opisz / nie — pozostaw bez zmian)
• "Czy dodawane są nowe role, czy zmieniają się istniejące granice ról?" (tak — opisz / nie — pozostaw bez zmian)

Jeśli użytkownik powie, że uwierzytelnianie się nie zmienia, zapisz obecny model uwierzytelniania jako ## Access Control z notatką: Brak planowanych zmian — obecny model zachowany. Jeśli planowane są zmiany, przechwyć zarówno obecny model, jak i planowane zmiany.

Sokrates: "Jaka jest najmniejsza zmiana dostępu, która nadal sprawiłaby, że ta funkcja byłaby użyteczna bez zakłócania istniejących użytkowników?"

Oba tryby

Zapisz przechwyconą treść jako blok ## Access Control zgodnie ze schematem. Zwiększ checkpoint.current_phase: 3 i dołącz 2 do checkpoint.phases_completed.

Krok 3: Dyscyplina MVP

Ta faza tworzy wstępny blok ## Success Criteria (podsekcje Primary / Secondary / Guardrails zgodnie ze schematem) i zasila pole timeline_budget w nagłówku YAML.

Tryb Greenfield

Rozpocznij od: "Naszkicuj najmniejszy, kompleksowy przepływ użytkownika, który udowodniłby, że ten produkt działa. Przeprowadź mnie przez pierwszą sesję, klik po kliku."

Słuchaj. Gdy użytkownik opisze przepływ, powtórz go jako sekwencję numerowaną ("1. użytkownik otwiera aplikację, 2. użytkownik robi X, 3. użytkownik widzi Y, …") i zapytaj: "Gdybyś miał trzy tygodnie pracy po godzinach, czy możesz dostarczyć ten przepływ?"

Powierzchnia kosztów zakresu: jeśli przepływ ma więcej niż ~6 odrębnych akcji użytkownika przed wygenerowaniem wartości, LUB własne oszacowanie użytkownika przekracza ~3 tygodnie pracy po godzinach, LUB przepływ wymaga wielu integracji / usług zewnętrznych / niestandardowej infrastruktury przed jakąkolwiek widoczną dla użytkownika korzyścią, wyraźnie przedstaw koszt. Celem jest świadomy wybór, a nie egzekwowanie — dłuższe terminy są ważne, ale użytkownik powinien je świadomie wybrać:

Ta pierwsza wersja jest większa niż to, co zazwyczaj jest dostarczane w ciągu trzech
tygodni pracy po godzinach. Pułapka greenfield polega na tym, że nic nie jest
dostarczane, ponieważ pierwsza wersja była zbyt duża, aby ją ukończyć. Dwie
ważne ścieżki stąd:

  Zmniejsz zakres — utrzymuj krótki harmonogram. Typowe posunięcia:
    - Odrzuć [zidentyfikowany kosztowny element] dla v1; dodaj go w v2, gdy
      coś zadziała.
    - Zastąp [zidentyfikowaną integrację] wersją ręczną / zakodowaną na stałe
      na razie.
    - Zmniejsz liczbę użytkowników do jednego (siebie) dla v1.

  Zobowiąż się do dłuższego harmonogramu — zaakceptuj koszt. Wielotygodniowy
  MVP jest wykonalny, ale wymaga stałego zaangażowania, ciężkiej pracy przez
  okres wieczorów lub weekendów oraz tolerancji na okresy, w których postęp
  wydaje się niewidoczny. Większość projektów greenfield, które przekraczają
  swoje pierwsze oszacowanie, umiera nie z powodu samej pracy, ale z powodu
  rozbieżności między oczekiwanym a rzeczywistym wysiłkiem.

Użyj AskUserQuestion z trzema opcjami:

• Zmniejsz zakres (Zalecane) — wybierz to, jeśli powyższy koszt jest nowością; ponownie uruchomimy ten krok z mniejszym pierwszym przepływem.
• Zobowiąż się do dłuższego harmonogramu — rozumiem, że będzie to wymagało stałego wysiłku — wybierz to tylko wtedy, gdy naprawdę przemyślałeś, jak wygląda wielotygodniowe zaangażowanie po godzinach i podchodzisz do tego z otwartymi oczami.
• Uruchom ponownie Krok 3 z innym pierwszym przepływem — wybierz to, jeśli żadna opcja nie pasuje i chcesz ponownie naszkicować MVP od podstaw.

Jeśli użytkownik wybierze "Zobowiąż się do dłuższego harmonogramu":

1. Przechwyć jego szacowaną mvp_weeks (zapytaj, jeśli nie została jeszcze podana).
2. Dołącz linię ## Timeline acknowledgment pod blokiem budżetu czasowego w shape-notes, która zapisuje: szacowane tygodnie, że użytkownik wyraźnie zaakceptował koszt stałego wysiłku i datę. Format: Potwierdzono dnia <RRRR-MM-DD>: <N>-tygodniowy MVP wymaga stałego zaangażowania; użytkownik zaakceptował.
3. Kontynuuj bez dalszego narzekania — potwierdzenie jest bramą, powtarzające się ostrzeżenia nie.

Tryb Brownfield

Rozpocznij od: "Opisz najmniejszą przyrostową zmianę, która udowodniłaby, że to ulepszenie działa. Przeprowadź mnie przez to, jak zmienia się doświadczenie użytkownika — co robią inaczej po wdrożeniu tej zmiany?"

Słuchaj. Powtórz jako numerowaną sekwencję delta: "1. użytkownik otwiera [istniejącą funkcję], 2. teraz widzi [nową rzecz], 3. może [nowa funkcja]…"

Następnie zadaj dwa pytania specyficzne dla brownfield:

• "Jaki jest zasięg tej zmiany? Które istniejące funkcje, integracje lub przepływy danych mogą się zepsuć?" (Sokrates: "Co istniejący użytkownik zauważyłby najpierw, gdyby ta zmiana poszła źle?")
• "Gdybyś miał trzy tygodnie pracy po godzinach, czy możesz dostarczyć tę zmianę?" (ta sama dyscyplina harmonogramu co w greenfield)

Powierzchnia kosztów zakresu: ta sama logika co w greenfield, ale przeformułowana:

Ta zmiana jest większa niż to, co zazwyczaj jest dostarczane w ciągu trzech
tygodni pracy po godzinach. Pułapka brownfield polega na rozpoczęciu dużej
zmiany w istniejącym systemie i pozostawieniu jej niedokończonej — częściowo
zmodyfikowany kod jest gorszy niż oryginał. Dwie ścieżki:

  Zmniejsz zakres — znajdź najmniejszy fragment, który udowodni, że zmiana
  działa. Typowe posunięcia:
    - Ogranicz do jednego przypadku użycia / jednej roli użytkownika na
      początku.
    - Zachowaj istniejące zachowanie jako awaryjne; dodaj nową ścieżkę obok.
    - Odrzuć [zidentyfikowaną kosztowną integrację] dla v1.

  Zobowiąż się do dłuższego harmonogramu — tak samo jak w greenfield:
  stały wysiłek, zaakceptowany.

Te same opcje AskUserQuestion co w greenfield.

Oba tryby

Gdy przepływ jest zablokowany, przechwyć go jako kryterium sukcesu ### Primary (działający przepływ = produkt/zmiana zadziałała). Zapytaj jeszcze raz o ### Secondary (1 miły dodatek) i ### Guardrails (1-2 rzeczy, które nie mogą się zepsuć — prywatność, minimalna wydajność, UX). Dla brownfield, guardrails powinny wyraźnie obejmować istniejące zachowanie, które musi zostać zachowane.

Ustaw timeline_budget.mvp_weeks (greenfield) lub timeline_budget.delivery_weeks (brownfield) w nagłówku YAML na liczbę podaną przez użytkownika — 1, jeśli zakres został zmniejszony, w przeciwnym razie zaakceptowane oszacowanie.

Zapisz blok ## Success Criteria. Zwiększ checkpoint.current_phase: 4 i dołącz 3 do checkpoint.phases_completed.

Krok 4: Wymagania funkcjonalne i historie użytkowników

Ta faza tworzy sekcje ## Functional Requirements i ## User Stories.

Tryb Greenfield

Rozpocznij od: "Teraz przejdźmy do konkretów. Z naszkicowanego przepływu MVP, co aktor musi być w stanie zrobić? Wymień możliwości — sformatuję je jako FR."

Przechwyć każdą możliwość jako pojedynczą linię FR zgodnie z formatem schematu:

- FR-NNN: [Aktor] może [możliwość]. Priorytet: musi być | miły dodatek

NNN to trzycyfrowa liczba z wiodącymi zerami, zaczynająca się od 001. Domyślny Priorytet: musi być dla wszystkiego w przepływie MVP; zapytaj wyraźnie, czy jakakolwiek możliwość jest miłym dodatkiem.

Tryb Brownfield

Rozpocznij od: "Teraz przejdźmy do konkretów. Z opisanej zmiany, jakie możliwości są dodawane, modyfikowane lub zachowywane? Wymień je — sformatuję je jako FR z kategorią zmiany."

Przechwyć każdą możliwość z dodatkowym tagiem Change::

- FR-NNN: [Aktor] może [możliwość]. Priorytet: musi być | miły dodatek. Zmiana: nowa | zmodyfikowana | zachowana

• new — możliwość, która nie istnieje w obecnym systemie
• modified — istniejąca możliwość, której zachowanie się zmienia
• preserved — istniejąca możliwość, która musi nadal działać bez zmian (defensywne FR — sprawia, że zachowanie jest jawne)

Poproś użytkownika, aby pomyślał o zachowanych FR: "Które istniejące możliwości muszą wyraźnie przetrwać tę zmianę? Jawne zachowanie zapobiega przypadkowym uszkodzeniom." Jeśli użytkownik zidentyfikuje zachowane FR, przechwyć je — staną się one FR-ami zabezpieczającymi dla PRD brownfield.

Oba tryby

Grupuj tematycznie z podnagłówkami ###, jeśli liczba FR przekracza ~6 (np. ### Uwierzytelnianie, ### Dopasowywanie przepisów, ### Trwałość).

Po przechwyceniu FR, poproś użytkownika o przetłumaczenie co najmniej głównej ścieżki przepływu MVP (greenfield) lub głównej ścieżki zmiany (brownfield) na historię użytkownika ### US-01: z Given/When/Then zgodnie ze schematem. Każda dodatkowa historia użytkownika jest opcjonalna, ale zalecana dla każdego FR, które ma nieoczywiste kryteria akceptacji.

Zaktualizuj checkpoint.frs_drafted do liczby wpisów FR-NNN.

Zwiększ checkpoint.current_phase: 4.5 i przejdź bezpośrednio do rundy Sokratesa (NIE oznaczaj fazy 4 jako ukończonej w phases_completed, dopóki runda Sokratesa nie zapisze z powrotem).

Krok 4.5: Runda wyzwań Sokratesa

Jest to dedykowana runda wsadowa — dokładnie jedno wyzwanie na każde FR przechwycone w Kroku 4, ani więcej, ani mniej.

Dla każdego FR-NNN w kolejności dokumentu, zapytaj:

FR-NNN: [Aktor] może [możliwość]. Priorytet: ...
Co musiałoby być prawdą, aby to FR było błędne — tzn. aby jego wdrożenie
zaszkodziło produktowi zamiast mu pomóc? LUB: jaki jest najsilniejszy
kontrargument za włączeniem tego do MVP?

Użyj AskUserQuestion dla każdego FR z 2-4 opcjami sformułowanymi jako wiarygodne kontrargumenty (zaczerpnięte z domeny FR — nie ogólne). Zawsze dołącz opcję "Brak kontrargumentu; pozostaje bez zmian" jako OSTATNIĄ opcję (nie pierwszą), aby pytanie zmuszało użytkownika do rozważenia wyzwania przed jego odrzuceniem.

Przechwyć każdą odpowiedź użytkownika jako blok cytatu > Socrates: pod odpowiednim FR w shape-notes.md:

- FR-001: Użytkownik może zapisać przepis do ulubionych. Priorytet: musi być
  > Sokrates: Rozważono kontrargument: "ulubione duplikują listę przepisów,
  > jeśli przepisów jest już mało." Rozwiązanie: zachowano; ulubione są
  > między sesjami, główna lista jest na lodówkę.

Jeśli runda Sokratesa skłoni użytkownika do zmiany FR (np. podzielenia na dwa, obniżenia priorytetu do miłego dodatku, całkowitego usunięcia), zaktualizuj linię FR na miejscu i ponownie wyemituj checkpoint.frs_drafted.

Gdy każde FR ma blok cytatu Sokratesa, dołącz 4 do checkpoint.phases_completed, zwiększ checkpoint.current_phase: 5.

Krok 5: Logika biznesowa i właściwości jakościowe

Ta faza tworzy sekcje ## Business Logic i ## Non-Functional Requirements. Brownfield tworzy również sekcję ## Constraints & Preserved Behavior. Encje i pola celowo NIE są przechwytywane jako oddzielna sekcja — wyłaniają się z FR i Historii Użytkowników (odpowiednio Kroki 4 i 4 tej umiejętności) i są przypinane podczas późniejszego wyboru stosu / planowania implementacji.

Tryb Greenfield

Rozpocznij od: "Opisz regułę działania w JEDNYM zdaniu — decyzję domenową, którą podejmuje Twoja aplikacja, odróżniającą ją od ogólnej listy CRUD."

Jeśli użytkownik potrafi sformułować jednolinijkową regułę, przechwyć ją jako pierwszą linię ## Business Logic. Następnie poproś o ≤ 3 akapity wspierające, wyjaśniające, jakie dane wejściowe reguła konsumuje (jako dane wejściowe dla użytkownika, a nie komponenty systemowe), jaki jest jej wynik i jak użytkownik napotyka ją w przepływie produktu. NIE nazywaj komponentów ani aktorów, którzy wykonują obliczenia — to są późniejsze wybory architektoniczne. Sformułuj regułę tak, jakby implementacja była nieznana.

Wykrywanie antywzorca pustego CRUD: jeśli "logika biznesowa" użytkownika sprowadza się do "użytkownicy mogą dodawać, przeglądać, aktualizować i usuwać rekordy" bez żadnej reguły, którą sama aplikacja stosuje (brak rekomendacji, priorytetyzacji, klasyfikacji, walidacji, punktacji, przepływu pracy, obliczeń), wyraźnie to przedstaw:

To, co opisałeś, to lista CRUD — a to jest znany antywzorzec greenfield.
CRUD bez decyzji domenowej oznacza, że aplikacja nie dostarcza żadnej
wartości, której użytkownik nie mógłby uzyskać z arkusza kalkulacyjnego
lub pliku notatek. Produkt jest pusty.

Prawdziwa reguła domenowa odpowiada na pytanie "co aplikacja decyduje za
użytkownika?". Typowe formy:

  - Rekomendacja:  aplikacja sugeruje elementy na podstawie stanu użytkownika
  - Priorytetyzacja: aplikacja porządkuje elementy według domniemanej
                    pilności / ważności
  - Klasyfikacja:  aplikacja taguje elementy według kategorii / sentymentu /
                   jakości
  - Walidacja:     aplikacja sprawdza elementy pod kątem reguły domenowej i
                   oznacza problemy
  - Punktacja:     aplikacja ocenia elementy, aby użytkownik mógł je
                   porównać
  - Przepływ pracy: aplikacja przenosi elementy przez stany z regułami
                    przejścia
  - Obliczenia:    aplikacja oblicza wartość na podstawie danych
                   wejściowych dostarczonych przez użytkownika

Jaką regułę stosuje TWOJA aplikacja?

Użyj AskUserQuestion z powyższymi kształtami reguł jako opcjami wielokrotnego wyboru (plus "Chcę dodać regułę — daj mi chwilę na zastanowienie" i "I tak buduję to jako czysty CRUD — zapisz to"). Jeśli użytkownik wybierze regułę, wróć do jednolinijkowego pytania. Jeśli zaakceptuje etykietę pustego CRUD, zapisz ją jako # TODO: reguła domenowa — patrz Otwarte Pytania zgodnie ze schematem i dodaj wpis do bieżącego bloku ## Open Questions w shape-notes.md.

Tryb Brownfield

Rozpocznij od: "Jaka jest istniejąca reguła domenowa — decyzja, którą Twój obecny system podejmuje za użytkownika? Następnie: czy ta zmiana dodaje nową regułę, modyfikuje istniejącą, czy jest tylko infrastrukturalna (brak zmiany reguły)?"

Słuchaj. Skategoryzuj odpowiedź:

• Dodaje nową regułę domenową — przechwyć jak w greenfield (jednolinijkowa reguła dla nowej możliwości).
• Modyfikuje istniejącą regułę — najpierw przechwyć obecną regułę ("System obecnie robi X"), następnie zmianę ("Ta zmiana modyfikuje ją, aby robiła Y"). Obie linie trafiają do ## Business Logic.
• Tylko infrastruktura — zmiana nie dotyka logiki domenowej (np. migracja, poprawa wydajności, integracja). Zapisz: "Brak zmiany logiki domenowej. Jest to zmiana infrastrukturalna/techniczna." Pomiń sprawdzanie pustego CRUD — nie dotyczy to prac infrastrukturalnych brownfield.

Po logice biznesowej, przechwyć ograniczenia i zachowane zachowanie jako ## Constraints & Preserved Behavior:

• "Jakie istniejące integracje, API lub kontrakty danych musi respektować ta zmiana?"
• "Czy są w to zaangażowane migracje danych? Co dzieje się z istniejącymi danymi?"
• "Jakie gwarancje kompatybilności wstecznej są potrzebne?"

Oba tryby

Po zablokowaniu logiki biznesowej (lub zarejestrowaniu jej braku), zadaj jedną rundę pytań dotyczących wymagań niefunkcjonalnych: "Czy istnieją cechy, które aplikacja musi spełniać na swojej zewnętrznej granicy — co użytkownik, operator lub regulator mógłby zmierzyć bez sprawdzania implementacji? Pomyśl o: czasie odpowiedzi, jak postrzega go użytkownik, zobowiązaniach dotyczących prywatności, dostępności, obsłudze przeglądarek/urządzeń, oknach retencji." Dla brownfield, dodaj: "Czy istnieją istniejące, zewnętrznie obserwowalne zachowania lub SLA, które nie mogą ulec pogorszeniu?"

Przechwyć jako punkty ## Non-Functional Requirements zgodnie ze schematem. Każde NFR łączy właściwość z mierzalnym celem (lub binarnym zobowiązaniem) i unika nazywania mechanizmu, strategii egzekwowania, miejsca wykonania lub udogodnienia interfejsu użytkownika — to są późniejsze wybory. Jeśli użytkownik sformułuje NFR mechanicznie ("limitowanie liczby żądań na IP", "spinner podczas ładowania", "zapytanie Postgres < 50ms"), odzwierciedl to w formie obserwowalnej z zewnątrz przed przechwyceniem ("uwierzytelnianie jest odporne na ataki brute-force bez blokowania użytkowników z błędami w pisowni"; "ciągła widoczna informacja zwrotna podczas każdej operacji > 2s"; "postrzegany przez użytkownika czas odpowiedzi < 800ms p95").

NIE pytaj "jakie encje użytkownik tworzy, odczytuje, aktualizuje lub usuwa?" — encje nie są problemem PRD. Rzeczowniki, którymi manipuluje produkt, pojawiają się w FR (Krok 4) i Historiach Użytkowników. Jeśli pytanie na poziomie pola wydaje się konieczne do wyjaśnienia reguły biznesowej, skieruj je do ## Open Questions w celu późniejszego rozwiązania, a nie do przechwytywania modelu danych.

Dołącz 5 do checkpoint.phases_completed, zwiększ checkpoint.current_phase: 6.

Krok 6: Ramowanie produktu

Ta faza tworzy sekcję ## Non-Goals oraz pola nagłówka YAML na poziomie produktu (product_type, target_scale, timeline_budget).

Nagłówek YAML PRD dotyczy tylko poziomu produktu. Kwestie związane ze stosem technologicznym — skład zespołu, preferencje językowe, listy technologii do unikania, tryb/region/budżet wdrożenia, kształt potoku CI/CD — oraz zobowiązania architektoniczne — decyzje implementacyjne, strategia testowania, plan wdrożenia — NIE są częścią PRD. Są one zbierane po /10x-prd, po zablokowaniu kształtu produktu. Zadawanie ich teraz zachęca użytkownika do nadmiernego zobowiązania przed wyborem stosu, a odpowiedzi zazwyczaj wymagają ponownego rozważenia po wybraniu stosu.

Tryb Greenfield

Rozpocznij od: "Ostatnia faza — ustalmy kilka szczegółów ramowania, a następnie sprecyzujmy, czego ten MVP wyraźnie NIE robi. Nie wybieramy tutaj frameworków, wdrożenia ani planów testów/CI — te pojawią się później, gdy zostanie wybrany stos."

Zadaj użytkownikowi te trzy krótkie pytania ramujące, PO JEDNYM (oddzielne AskUserQuestion dla każdego pytania, a nie pojedynczy blok wielokrotnych pytań). Sformułuj każde pytanie prostym językiem, jak sugerowano poniżej — NIE drukuj nazw pól, takich jak product_type lub target_scale w tekście pytania ani w etykietach opcji. Wewnętrznie mapuj odpowiedź użytkownika na podstawowe pole nagłówka YAML.

1. Jaki rodzaj rzeczy budujesz?

   • Opcje: "Strona internetowa lub aplikacja webowa" / "API lub usługa backendowa" / "Narzędzie wiersza poleceń" / "Aplikacja mobilna" / "Aplikacja desktopowa" / "Biblioteka lub SDK" / "Potok danych" — plus opcja swobodnego tekstu.
   • Mapuj wybraną etykietę na product_type: web-app / api / cli / mobile / desktop / library / data-pipeline / other.

2. Z grubsza, ile osób będzie tego używać, gdy już będzie działać?

   • Opcje: "Tylko ja, lub garstka" / "Dziesiątki do stu" / "Do dziesięciu tysięcy" / "Więcej niż dziesięć tysięcy".
   • Mapuj wybraną etykietę na target_scale.users: small / medium / large / enterprise.
   • Po odpowiedzi, zadaj krótkie pytanie Sokratesa: "Jak zmieniłaby się twoja reguła domenowa przy 100-krotnej skali?" Przechwyć wszelkie spostrzeżenia jako jednolinijkową notatkę w sekcji Vision w shape-notes, jeśli pojawi się coś nowego.

3. Dwa szybkie pytania dotyczące czasu.

   • Zapytaj w jednej rundzie: "Czy jest jakiś twardy termin, do którego dążysz? Jeśli tak, jaka data — jeśli nie, po prostu powiedz 'bez terminu'." (Mapuj na timeline_budget.hard_deadline: data ISO lub null.)
   • Następnie: "Czy będzie to praca po godzinach, czy część Twojej pracy?" (Mapuj na timeline_budget.after_hours_only: bool.)
   • timeline_budget.mvp_weeks zostało już zablokowane w Kroku 3 — nie pytaj ponownie.

Tryb Brownfield

Rozpocznij od: "Ostatnia faza — ustalmy kilka szczegółów ramowania i czego ta zmiana wyraźnie NIE robi. Nie zmieniamy tutaj stosu — te decyzje pojawią się później."

Dla brownfield, pytania dotyczące ramowania produktu stają się bramkami tak/nie "czy to się zmienia?" plus przechwytywanie ograniczeń:

1. Czy zmienia się typ produktu?

   • Jeśli istniejący system to aplikacja webowa i ta zmiana tego nie zmienia → zapisz product_type bez zmian z notatką: Brak zmian — istniejący [typ].
   • Jeśli zmiana wprowadza nową powierzchnię produktu (np. dodanie CLI do aplikacji webowej) → przechwyć nowy product_type obok istniejącego.

2. Czy zmienia się baza użytkowników?

   • Ten sam wzorzec: zapisz obecny target_scale i czy zmiana na niego wpływa. Jeśli zmiana otwiera system na nowych użytkowników lub inną skalę, przechwyć deltę.

3. Czas — te same dwa pytania co w greenfield (hard_deadline, after_hours_only). timeline_budget.delivery_weeks zostało już zablokowane w Kroku 3.

Po zablokowaniu ramowania produktu, dodaj: "Jakie ograniczenia narzuca istniejący system na tę zmianę? Pomyśl o: oknach wdrożenia, istniejących wymaganiach CI/CD, kompatybilności wstecznej z obecnymi konsumentami API, istniejącym monitoringu/alertowaniu." Przechwyć w ## Constraints & Preserved Behavior (rozszerz sekcję utworzoną w Kroku 5).

Oba tryby

Po zablokowaniu ramowania produktu, przeprowadź jedną rundę wielokrotnego wyboru Non-Goals. Kształt to lista unikania wielokrotnego wyboru — ale skierowana na unikanie zakresu (możliwości, których MVP nie zbuduje / zmiana nie dotknie, wymiary jakości, do których nie będzie dążyć), a nie unikanie technologii. Zapytaj:

Czego ten [MVP/zmiana] wyraźnie NIE robi? Wybierz wszystko, co powinno być
wykluczone *teraz*, aby nie wkradło się później. Zarówno funkcjonalne
nie-cele (możliwości, których nie zbudujemy/zmienimy), jak i niefunkcjonalne
nie-cele (wymiary jakości, do których nie będziemy dążyć) należą tutaj.

Użyj AskUserQuestion z multiSelect: true i 3-5 opcjami zaczerpniętymi z domeny użytkownika — NIE ogólnymi. Przykłady (generuj ponownie dla każdego projektu):

• "Unikaj: budowania własnego [algorytmu domenowego — np. rekomendacji, planowania, punktacji]" — silne unikanie zakresu; wymuś decyzję kupić-vs-zbudować teraz.
• "Unikaj: [kosztownego elementu infrastruktury — np. lokalnego LLM, synchronizacji w czasie rzeczywistym, wielu regionów]" — silne unikanie zakresu; brak kształtuje przepływ danych.
• "Unikaj: [drugorzędnej persony — np. współdzielonych talii, przestrzeni roboczych zespołu, funkcji administracyjnych]" — jawne zablokowanie pojedynczego najemcy.
• "Unikaj: [wymiaru jakości — np. offline-first, pełne WCAG-AA, opóźnienie poniżej 100ms]" — jawny niefunkcjonalny nie-cel.
• Dla brownfield: "Unikaj: [zmiany istniejącego systemu — np. migracji bazy danych, przepisywania uwierzytelniania, zmiany celu wdrożenia]" — jawny nie-cel istniejącego systemu.
• "Inne (powiedz mi)" — przechwytywanie swobodnego tekstu.

Dołącz wybrane elementy do ## Non-Goals zgodnie ze schematem (jednolinijkowe uzasadnienie dla każdego). Jeśli pojawią się unikania technologii (np. "unikaj: PHP", "unikaj: monorepo"), NIE dodawaj ich do ## Non-Goals — przechwyć je w treści shape-notes pod blokiem ## Forward: tech-stack (informacyjne, nie część schematu PRD), aby następny krok łańcucha mógł je podjąć.

NIE pytaj o decyzje implementacyjne, strategię testowania ani plan wdrożenia i CI/CD w tej umiejętności. Te kwestie znajdują się po wyborze stosu / ocenie stosu. Jeśli użytkownik dobrowolnie poda treści o takim kształcie, przechwyć je w shape-notes pod ## Forward: technical-roadmap (informacyjne; nie sekcja PRD), aby późniejsza umiejętność mogła je podjąć.

Dołącz 6 do checkpoint.phases_completed, zwiększ checkpoint.current_phase: 7. Przejdź bezpośrednio do Kroku 7.

Krok 7: Końcowa kontrola jakości (soft-gate)

Ta faza uruchamia kontrolę jakości dla wszystkiego, co zostało przechwycone. Jest to soft gate: ostrzega, ale pozwala na nadpisanie.

Odczytaj bieżący shape-notes.md i sprawdź każdy z poniższych elementów. Dla każdego oznacz obecny lub brakujący/słaby:

1. Kontrola dostępu — blok ## Access Control istnieje z nietrywialną wartością (nie tylko pusty placeholder).
2. Logika biznesowa (reguła jednolinijkowa) — ## Business Logic zaczyna się od jednego deklaratywnego zdania (nie akapitu, nie "TBD"). Dla zmian infrastrukturalnych brownfield, "Brak zmiany logiki domenowej" jest prawidłowe.
3. Artefakty projektu — sam shape-notes.md istnieje z prawidłowym punktem kontrolnym w nagłówku YAML. (W tym momencie zawsze jest obecny.)
4. Potwierdzenie kosztu czasowego — albo timeline_budget.mvp_weeks / delivery_weeks ≤ 3, ALBO blok ## Timeline acknowledgment istnieje w shape-notes, rejestrujący, że użytkownik zaakceptował koszt stałego wysiłku w Kroku 3. Dłuższe terminy są ważne; bramą jest to, że koszt został przedstawiony i zaakceptowany, a nie to, że termin jest krótki.
5. Non-Goals — blok ## Non-Goals istnieje z co najmniej jednym wpisem.
6. Zachowane zachowanie (tylko brownfield) — blok ## Constraints & Preserved Behavior istnieje i wyraźnie nazywa, co nie może się zepsuć. Pomiń to sprawdzenie dla sesji greenfield.

NIE sprawdzaj ## Testing Strategy, ## Deployment & CI/CD ani ## Implementation Decisions — nie są one częścią schematu PRD. Znajdują się one po wyborze stosu / ocenie stosu, a nie w PRD.

Wydrukuj tabelę wyników:

═══════════════════════════════════════════════════════════
  KONTROLA JAKOŚCI
═══════════════════════════════════════════════════════════

  Kontrola dostępu:           [obecny | brakujący — opisz]
  Logika biznesowa:           [...]
  Artefakty projektu:        obecny
  Potwierdzenie kosztu czasowego:        [obecny | brakujący — opisz]
  Non-Goals:                [...]
  Zachowane zachowanie:       [obecny | brakujący — opisz | n/a (greenfield)]

═══════════════════════════════════════════════════════════

Dla każdego brakującego/słabego, wymień go z nazwy z jednolinijkową konsekwencją: "Logika biznesowa: nie przechwycona jako jednolinijkowa reguła — Twoje PRD będzie puste bez decyzji domenowej." Ogólne ostrzeżenia "Twoje PRD ma luki" unieważniają bramę; nie pisz ich.

Następnie zapytaj:

AskUserQuestion:

• question: "Jak chcesz postąpić?" header: "Kontrola krzyżowa" options:
  • label: "Usuń luki teraz" description: "Ponownie wejdź do odpowiedniej fazy, aby uzupełnić brakujące elementy. Zalecane, jeśli brakuje wielu elementów."
  • label: "Akceptuj i zakończ" description: "Kontynuuj pomimo luk. Zostaną one zarejestrowane jako ostrzeżenia w punkcie kontrolnym i przedstawione w Otwartych Pytaniach /10x-prd."
  • label: "Uruchom ponownie fazę [N]" description: "Wróć do konkretnej fazy i odbuduj od tego miejsca." multiSelect: false

W przypadku "Usuń luki teraz": zapytaj, która luka; wróć do fazy, która ją posiada (Krok 1-6); uruchom ponownie tylko tę fazę; następnie wróć do Kroku 7.

W przypadku "Akceptuj i zakończ": ustaw checkpoint.quality_check_status: warned (jeśli pozostały jakieś luki) lub accepted (jeśli wszystkie elementy są obecne — 6 dla greenfield, 7 dla brownfield). Dołącz sekcję ## Quality cross-check do shape-notes.md, wymieniając każdą lukę z nazwy z jej jednolinijkową konsekwencją — /10x-prd odzwierciedla je w ## Open Questions.

W przypadku "Uruchom ponownie fazę [N]": przejdź do tej fazy. NIE usuwaj wcześniejszej treści; pozwól fazie nadpisać własne sekcje.

Dołącz 7 do checkpoint.phases_completed, zwiększ checkpoint.current_phase: 8. Przejdź do Kroku 8.

Krok 8: Przekazanie

Ostateczny zapis shape-notes.md:

• Potwierdź, że checkpoint.quality_check_status to warned lub accepted (nigdy pending w tym momencie).
• Zaktualizuj updated: do dzisiejszej daty w nagłówku YAML.
• Ponownie zweryfikuj zgodność ze schematem referencyjnym: dla greenfield, treść powinna przewidywać 10 sekcji PRD w kolejności wymaganej przez schemat; dla brownfield, 11 sekcji PRD brownfield. Nagłówek YAML powinien zawierać pełny blok checkpoint: plus context_type. Wszelkie treści wybiegające w przyszłość przechwycone w Kroku 6 pozostają w swoim bloku ## Forward: ... — NIE są włączane do sekcji mapowanych na PRD.

Następnie skopiuj polecenie następnego kroku do schowka i ogłoś:

echo -n "/10x-prd" | pbcopy 2>/dev/null || echo -n "/10x-prd" | clip.exe 2>/dev/null || echo -n "/10x-prd" | xclip -selection clipboard 2>/dev/null || true

# PowerShell (Windows)
Set-Clipboard "/10x-prd"

Wydrukuj:

═══════════════════════════════════════════════════════════
  KSZTAŁTOWANIE ZAKOŃCZONE
═══════════════════════════════════════════════════════════

  Projekt:                [nazwa projektu]
  Typ kontekstu:           [greenfield | brownfield]
  Przechwycone fazy:        1, 2, 3, 4, 5, 6
  Sporządzone FR:            [liczba]
  Kontrola jakości:          [ostrzeżenie | zaakceptowane]

  ► Notatki:  context/foundation/shape-notes.md
  ► Następny:   /10x-prd  (✓ skopiowano do schowka)

  Po /10x-prd, następny krok łańcucha podejmie:
    Greenfield → wybór stosu technologicznego, następnie bootstrap
    Brownfield → ocena stosu, następnie kontrola stanu
  Żadne z nich nie należy do samego PRD.
═══════════════════════════════════════════════════════════

ZATRZYMAJ. Nie przechodź automatycznie do /10x-prd — użytkownik uruchamia go, gdy jest gotowy.

Krytyczne zabezpieczenia

1. Facylitator, nie generator. Umiejętność nigdy nie pisze treści domenowych, których użytkownik nie powiedział. Jeśli sekcja potrzebuje wartości, której użytkownik nie podał, zapytaj. Wyjątkiem jest formatowanie mechaniczne (numeracja FR-NNN, szkielety nagłówków schematu, klucze nagłówka YAML).

2. Schemat jest umową. Kształt shape-notes.md i osadzony szkielet dla przyszłego PRD są dyktowane przez references/prd-schema.md. Sprawdzaj ponownie przy każdym zapisie punktu kontrolnego. Jeśli schemat zmieni się w trakcie implementacji, zaktualizuj treść tej umiejętności, aby pasowała — dryf jest trybem awarii.

3. Otwartość stosu jest wiążąca. Nigdy nie pytaj, nie rekomenduj ani nie zobowiązuj się do frameworka, bazy danych, rodziny języków ani konkretnej platformy. PRD przechwytuje tylko priorytety na poziomie produktu (product_type, target_scale, timeline_budget); skład zespołu, preferencje językowe, wdrożenie i kształt CI/CD są zbierane po /10x-prd. Jeśli użytkownik dobrowolnie poda treści związane ze stosem, przechwyć je w treści shape-notes pod ## Forward: tech-stack — nie w sekcjach mapowanych na PRD.

4. Antywzorce są przedstawiane z nazwy, a nie ogólnie. Wykrywanie pustego CRUD nazywa brakujące kształty reguł i prosi użytkownika o wybranie jednego. Wykrywanie zbyt dużego MVP nazywa kosztowne elementy i oferuje konkretne ruchy zmniejszające zakres. Ostrzeżenia "Twój pomysł ma problemy" unieważniają bramę; nie pisz ich.

5. Soft gate, nie hard gate. Końcowa kontrola krzyżowa OSTRZEGA, ale pozwala użytkownikowi nadpisać każdą lukę. Ścieżki nadpisania są rejestrowane w punkcie kontrolnym jako quality_check_status: warned i przedstawiane w ## Open Questions w /10x-prd. Odmowa zakończenia nie wchodzi w zakres.

6. Zachowanie uwzględniające tryb. Umiejętność automatycznie wykrywa typ kontekstu (greenfield vs brownfield) na podstawie znaczników projektu w bieżącym katalogu roboczym i odpowiednio dostosowuje wszystkie sześć faz odkrywania. Dla brownfield, pętla odkrywania zmienia się z "co budujesz od podstaw?" na "co istnieje, co się zmienia, co musi zostać zachowane?". Jeśli użytkownik wywoła tę umiejętność dla problemu o małym zakresie w istniejącej bazie kodu (pojedynczy błąd, szybka refaktoryzacja), zasugeruj zamiast tego /10x-frame — /10x-shape jest przeznaczony do zmian, które wymagają pełnego PRD.

7. Tylko język uniwersalny. Brak odniesień do 10xDevs / kohorty / certyfikacji w jakimkolwiek wyniku skierowanym do użytkownika lub w jakimkolwiek artefakcie zapisanym na dysku. Mechanika tutaj to uniwersalne wskaźniki dobrze zdefiniowanego projektu; kontekst persony, który je motywował, znajduje się w folderze zmian, a nie w dostarczonej umiejętności.

8. Wznowienie zachowuje wcześniejszą pracę. Przy wznowieniu, ukończone fazy są PODSUMOWYWANE w 1-2 zdaniach każda, nigdy nie są uruchamiane ponownie. Wcześniejsze decyzje użytkownika są kluczowe; ich ponowne odtwarzanie frustruje użytkownika i grozi sprzecznością z wcześniejszymi przechwyceniami.

Notatki

• To jest umiejętność kształtowania. Wynikiem jest shape-notes.md, a nie prd.md. /10x-prd jest generatorem dokumentów.
• Schemat referencyjny (references/prd-schema.md) jest jedynym źródłem prawdy. Każda nazwa pola, nazwa sekcji lub klucz punktu kontrolnego, do którego odwołuje się ta treść, MUSI istnieć w dokumencie schematu — jeśli nie, najpierw popraw dokument schematu.
• Dla greenfield, 10 sekcji PRD jest przewidywanych w kolejności treści shape-notes.md, aby /10x-prd mógł je czysto mapować. Dla brownfield, zamiast tego przewidywanych jest 11 sekcji PRD brownfield (patrz references/prd-schema.md). Nazwy są dokładnie takie same. Treści wybiegające w przyszłość (pozostałości po selektorze stosu technologicznego / ocenie stosu; przyszłe kwestie mapy drogowej technicznej) znajdują się w oddzielnych blokach ## Forward to ... w treści shape-notes i NIE mapują się na PRD.
• Jeśli użytkownik nalega na pominięcie fazy ("po prostu wygeneruj PRD"), wyjaśnij konsekwencje: brakujące fazy tworzą puste sekcje PRD. Następnie zaoferuj pominięcie z wyraźnie określonym kosztem. Wybór należy do nich.