Pisma Procesowe V3

⛔ MRG-GATE — AKTYWNY OD KROK 0 DO present_files, BEZ WYJĄTKÓW

REGUŁA MRG: Przed KAŻDĄ odpowiedzią w pipeline pisma procesowego ORAZ
przed KAŻDYM krokiem oznaczonym [CP], model MUSI wykonać OBA wywołania:
  1. view shared/CP-GATE.md
  2. view shared/MOD-STEP-TRACKER.md
Następnie zaktualizować CP-REJESTR (§2 CP-GATE.md) oraz REJESTR KROKÓW
(FAZA 0 MOD-STEP-TRACKER) WYŁĄCZNIE na podstawie ŚWIEŻO odczytanej treści.

⛔ Wywołanie view() jest OBOWIĄZKOWE nawet jeśli:
  • pliki były już wczytane wcześniej w tej samej sesji,
  • model „pamięta" ich treść,
  • użytkownik nie prosił o odczyt,
  • jest to „prosty" krok pośredni,
  • plik „nie zmieniał się" od ostatniego odczytu.

⛔ ZAKAZY MRG (bezwzględne):
  • ZAKAZ polegania na pamięci modelu zamiast wywołania view().
  • ZAKAZ pominięcia odczytu „bo to ten sam plik co poprzednio".
  • ZAKAZ pominięcia odczytu gdy plik „nie zmieniał się" od ostatniego razu.
  • ZAKAZ zamknięcia jakiegokolwiek [CP] bez uprzedniego podwójnego view().
  • ZAKAZ wpisania do pisma jakiejkolwiek treści checkpointu/rejestru
    odtworzonej z pamięci zamiast z bieżącego odczytu.

UZASADNIENIE (dlaczego tylko view() gwarantuje poprawność):
  • Pliki mogą być aktualizowane między odpowiedziami.
  • Pamięć modelu może zawierać poprzednią wersję pliku.
  • Jedynie view() gwarantuje odczyt aktualnej wersji z dysku.

⛔ AUTODIAGNOZA MRG (przed każdym raportem [CP] i przed present_files):
  Zadaj sobie 1 pytanie: „Czy w TEJ odpowiedzi wywołałem view() na OBU
  plikach (CP-GATE.md + MOD-STEP-TRACKER.md) przed bieżącym [CP]?"
  Jeśli NIE → NIE zamykaj [CP], NIE wywołuj present_files — najpierw OBA view().

⛔ SD-GATE — AKTYWNY OD STARTU DO present_files, BEZ WYJĄTKÓW

KROK A — ST-INIT (na starcie, raz):
  view shared/MOD-STEP-TRACKER.md → zainicjuj REJESTR kroków.
  Każdy krok pipeline = jeden wpis ze statusem: ○ OCZEKUJE.

KROK B — ST-TRACK (w trakcie):
  Po każdym kroku ustaw status:
    ✅ WYKONANY  |  ⚠️ POMINIĘTY (+powód)  |  — N/A (+uzasadnienie)
  N/A musi być uzasadnione (np. „brak dowodów pośrednich" dla MOD-LANCUCH).

KROK C — ST-FINAL (OBOWIĄZKOWY i BLOKUJĄCY przed KAŻDYM present_files pisma):
  Wyświetl PEŁNY REJESTR KROKÓW (format FAZA 3 z MOD-STEP-TRACKER):
  kroki ✅ wykonane | ⚠️ pominięte (+powód) | ○ oczekujące | — N/A | STATUS PISMA.

⛔ INFORMACJA WARUNKOWA (sedno bramki):
  Policz kroki WYMAGANE, których status ≠ ✅ WYKONANY i ≠ — N/A
  (tj. wszystkie ⚠️ POMINIĘTY oraz ○ OCZEKUJE).

  • Jeśli liczba = 0:
       STATUS PISMA = ✅ FINAL — GOTOWE DO ZŁOŻENIA.
       Dozwolone present_files bez dalszych pytań.
       Tryb PRAWNIK/kancelaria lub żądanie użytkownika → po present_files:
       `view modules/MOD-AUDIT-BUNDLE.md` (paczka audytowa AI Act art. 12 —
       deliverable dla audytora, nigdy dla sądu ani kontrahenta).

  • Jeśli liczba ≥ 1  →  WARUNEK SPEŁNIONY → URUCHOM INFORMACJĘ WARUNKOWĄ:
       1) STATUS PISMA = ⚠️ DRAFT — NIEZWERYFIKOWANY (X krok(ów) pominięto/do zrobienia).
       2) .docx MUSI nosić wzmocniony watermark „DRAFT — NIEZWERYFIKOWANY"
          (zgodnie z CP-GATE; brak watermarku = błąd krytyczny).
       3) Wyświetl blok ujawnienia:

          ┌─────────────────────────────────────────────────────────────┐
          │ ⚠️ INFORMACJA WARUNKOWA — PISMO NIEPEŁNE                      │
          │                                                             │
          │ Kroki pominięte lub jeszcze do wykonania:                   │
          │  ⚠️/○ [ID] [nazwa] — [powód / co to weryfikuje]            │
          │  ...                                                        │
          │                                                             │
          │ Skutek dla jakości pisma:                                   │
          │  → [czego nie sprawdzono / jakie ryzyko procesowe]          │
          │                                                             │
          │ Decyzja:                                                    │
          │  a) Akceptuję pismo jako DRAFT (bez tych kroków)            │
          │  b) Wykonaj brakujące kroki przed dostarczeniem (zalecane)  │
          └─────────────────────────────────────────────────────────────┘

       4) ⛔ ZAKOŃCZ ODPOWIEDŹ. Czekaj na decyzję a/b.
          - „a"/„tak"  → present_files z plikiem DRAFT — NIEZWERYFIKOWANY.
          - „b"/„nie" → wykonaj brakujące kroki, potem ponów ST-FINAL.

⛔ ZAKAZ-14 (bezwzględny):
  • ZAKAZ present_files jakiegokolwiek pisma BEZ uprzedniego ST-FINAL.
  • ZAKAZ statusu ✅ FINAL, gdy istnieje choćby jeden krok ⚠️ POMINIĘTY lub ○ OCZEKUJE.
  • ZAKAZ „cichego" przeskoku — pominięcie BEZ ujawnienia = błąd krytyczny pipeline.
  • Polecenie „dalej"/„kontynuuj"/„generuj" NIE zwalnia z ST-FINAL ani z INFORMACJI WARUNKOWEJ.

⛔ AUTODIAGNOZA KOŃCOWA (wykonaj tuż przed present_files, nawet jeśli „wydaje się gotowe"):
  Zadaj sobie 1 pytanie: „Czy wyświetliłem REJESTR KROKÓW (ST-FINAL) w tej odpowiedzi?"
  Jeśli NIE → NIE wywołuj present_files. Najpierw ST-FINAL.

⛔ CG-GATE (CONDITIONAL GATE) — WYKONAJ JAKO ABSOLUTNIE PIERWSZY KROK

KROK CG-1 — INFORMACJA WSTĘPNA (wyświetl użytkownikowi przed startem):

  ┌─────────────────────────────────────────────────────────────────────────┐
  │ ⚠️ INFORMACJA PRZED STARTEM — PISMA PROCESOWE v3                        │
  │                                                                         │
  │ Ten skill realizuje wieloetapowy pipeline kancelaryjny (W1 → W2 → W3)  │
  │ z kilkunastoma obowiązkowymi krokami kontroli jakości.                  │
  │                                                                         │
  │ Ważne zastrzeżenie:                                                     │
  │  → Nie wszystkie kroki pipeline'u mogły zostać wykonane w poprzednich  │
  │    sesjach dotyczących tej sprawy.                                      │
  │  → W tej sesji każde pominięcie kroku będzie jawnie zgłoszone         │
  │    (INFORMACJA WARUNKOWA) — nigdy ciche.                               │
  │  → Jeśli pominięto kroki wcześniej i sprawa jest kontynuowana,        │
  │    zaleca się poinformowanie o tym fakcie teraz.                       │
  │                                                                         │
  │ Po Twojej akceptacji wczytam pełną listę kroków i checklistę,          │
  │ a następnie przystąpię do pracy.                                        │
  │                                                                         │
  │ Czy akceptujesz powyższe warunki i chcesz kontynuować?                 │
  │  a) Tak, akceptuję — wczytaj checklistę i rozpocznij                   │
  │  b) Nie — zakończ lub wyjaśnij wątpliwości                             │
  └─────────────────────────────────────────────────────────────────────────┘

  ⛔ ZAKOŃCZ ODPOWIEDŹ PO WYŚWIETLENIU CG-1. Czekaj na decyzję a/b.
  ⛔ NIE wykonuj żadnego kroku merytorycznego przed akceptacją.

KROK CG-2 — PO OTRZYMANIU AKCEPTACJI „a" (WCZYTANIE CHECKLISTY):

  Wykonaj WSZYSTKIE poniższe view() w podanej kolejności:

  1. view pisma-procesowe-v3/references/AUTOMAT-STANOW.md
     → Zawiera: PROTOKÓŁ CHECKPOINT, AUTOMAT STANÓW (STAN 0–3 z KROK 0-TRACKER),
       MAPA CHECKPOINTÓW, ZAKAZY 1–13, REGUŁA NAPRAWY, REGUŁA-KONTYNUACJA,
       REGUŁA AUTODIAGNOZY.

  2. view pisma-procesowe-v3/references/SELF-CHECK-PISMA.md
     → Zawiera: SELF-CHECK przed każdą odpowiedzią (pełna checklista CP),
       REGUŁA FINALNA (11 pytań).

  3. view pisma-procesowe-v3/references/MODULY-MAPA.md
     → Zawiera: matryca engines per etap, pliki kanoniczne shared z triggerami.

  Po wczytaniu — wyświetl użytkownikowi REJESTR KROKÓW (format ST-INIT):

  ┌─────────────────────────────────────────────────────────────────────────┐
  │ ✅ CHECKLIST WCZYTANA — PIPELINE AKTYWNY                                │
  │                                                                         │
  │ Kroki pipeline (status startowy):                                       │
  │  ○ KROK 0: CP-GATE + STEP-TRACKER (inicjalizacja)                      │
  │  ○ Test A / Test B / Test C (routing)                                   │
  │  ○ W1: CLAIM-VALIDATION [CP-1a]                                         │
  │  ○ W1: MOD-STRATEGIA-WYBOR [CP-1b] (gdy ≥2 ścieżki)                   │
  │  ○ W1: SKAN DOWODÓW / MACIERZ / ŁAŃCUCH [CP-1c-*]                     │
  │  ○ W1: MOD-DOKUMENT-ANOMALIE / MOD-POSZLAKI [CP-1d-*]                  │
  │  ○ W1: RAMA + STRATEGIA [CP-W1]                                         │
  │  ○ PRE-W2-GATE [CP-PRE-W2]                                              │
  │  ○ W2: PROJEKT PISMA + ATAK-NA-DRAFT [CP-ATAK]                         │
  │  ○ W3: PODMIOT-GATE [CP-PODMIOT]                                        │
  │  ○ W3: WERYFIKACJA + WALIDACJA [CP-QUALITY]                             │
  │  ○ W3: AUDYT-KOŃCOWY [CP-AUDYT]                                         │
  │  ○ W3: PEER-REVIEW + POST-VALIDATION [CP-PEER]                          │
  │                                                                         │
  │ Zastrzeżenie: nie wszystkie kroki muszą być wymagane w Twojej sprawie  │
  │ (N/A z uzasadnieniem). Każde pominięcie będzie jawnie zgłoszone.       │
  │                                                                         │
  │ Teraz przystępuję do KROKU 0 — routing.                                │
  └─────────────────────────────────────────────────────────────────────────┘

  Następnie wykonaj KROK 0 (CP-GATE → STEP-TRACKER → routing Test A/B/C).

⛔ ZAKAZ-15 (bezwzględny — nowy):
  • ZAKAZ pominięcia CG-GATE na starcie sesji.
  • ZAKAZ rozpoczęcia jakiegokolwiek kroku merytorycznego bez akceptacji „a".
  • ZAKAZ wczytania checklisty bez wyświetlenia najpierw bloku INFORMACJA WSTĘPNA.
  • Polecenie „zacznij pismo" / „pisz" / „generuj od razu" NIE zwalnia z CG-GATE.

W1 — RAMA I STRATEGIA
     Co dowodzimy, czym, jakie przepisy (lista robocza ⚠️ nieweryfikowane)
     → checkpoint: użytkownik zatwierdza ramę przed redakcją
     → STOP po W1 — czekaj na odpowiedź użytkownika

W2 — PROJEKT PISMA
     Pełna redakcja procesowa. Przepisy jako ⚠️[WERYFIKACJA W3].
     Sygnatury orzeczeń: ZAKAZ — tylko placeholder [ORZECZENIE: opis → W3]
     → STOP po W2 — nie pytaj użytkownika, przejdź do W3 automatycznie

W3 — WERYFIKACJA ZE ŹRÓDEŁ + WALIDACJA
     web_fetch dla każdego ⚠️ → zamknięcie przez zweryfikowane cytaty z ELI (RZĄD 1, kanon E-1…E-5)
     web_fetch dla każdego [ORZECZENIE] → sygnatura + teza + URL ze źródła
     MOD-WALIDACJA (bloki A–I) → raport formalny
     Pismo finalne z pełnymi oznaczeniami Dz.U.
     → .docx generowany WYŁĄCZNIE po zamknięciu W3

TAK, gdy WSZYSTKIE są prawdą:
  ✓ Użytkownik dostarczył treść GOTOWEGO pisma (wklejona / plik)
  ✓ Żądanie dotyczy formy/stylu/długości/tonu, nie nowej argumentacji
  ✓ Nie proszono o dodanie nowych przepisów/orzeczeń/zarzutów

Sygnały: "popraw to pismo", "zredaguj", "skróć", "wzmocnij ton", "przeredaguj
na bardziej stanowczy/neutralny/negocjacyjny", "wygładź styl", "sprawdź i
popraw" (po raporcie z KROK F przewodnika).

→ TAK: przejdź do `modules/MOD-REDAKCJA.md` — NIE wykonuj W1-W2-W3, NIE
  sprawdzaj Testu B/C.
→ NIE: przejdź do Testu B.

Test A ma priorytet — jeśli użytkownik dostarczył gotowe pismo i prosi
o poprawki formy, nie kwalifikuj tego jako "pismo proste" (Test B) ani
nie uruchamiaj W1 (Test C) — to są ścieżki dla pism PISANYCH OD ZERA.

□ TYP PISMA:    [pozew / apelacja / sprzeciw / wniosek / riposta / zawiadomienie]
□ DZIEDZINA:    [cywilna / pracownicza / karna / administracyjna / gospodarcza]
□ STRONY:       [powód/wnioskodawca + pozwany/uczestnik]
□ ETAP:         [nowa sprawa / sprawa w toku — sygnatura: ___]
□ CEL:          [co osiągnąć tym pismem]
□ MATERIAŁY:    [czy użytkownik dostarczył dokumenty/akta — TAK/NIE]

TYP PISMA:      [nazwa]
SĄD / ORGAN:    [nazwa — właściwość orientacyjna, weryfikacja w W3]
TRYB:           [uproszczony / zwykły / nakazowy / KPA / PPSA]
OPŁATA:         orientacyjna [kwota ⚠️ — weryfikacja w W3]
TERMIN ZAWITY:  [data lub "brak" — weryfikacja w W3]

"Dowodzimy że [X], co skutkuje [Y], na podstawie [dziedzina prawa]."

KROK ET: Eliminacja tez i weryfikacja przepisów
  view modules/MOD-ELIMINACJA-TEZ.md

  Per każde żądanie z petitum:
  → ET-Q1: Czy istnieje przepis który to żądanie PRZEWIDUJE? (ELI — RZĄD 1)
  → ET-Q2: Czy PRZESŁANKI przepisu są spełnione przez fakty F-nn?
           (subsumpcja — per każda przesłanka osobno)
  → ET-Q3: Czy przepisy z materiału dowodowego są PRAWIDŁOWE?
           (nie przepisuj — weryfikuj samodzielnie)
  → Raport ET-4: ZATWIERDZONE / EWENTUALNE / WYELIMINOWANE

  WYNIK:
  ✅ ZATWIERDZONE → wchodzą do W1.3 i petitum
  ⚠️ EWENTUALNE  → wchodzą jako "ewentualnie" + CV-ALT
  ⛔ WYELIMINOWANE → NIE wchodzą do petitum ani uzasadnienia

⛔ KROK FSL-D: Fact-Source-Lock Dokumentów
  view shared/MOD-FSL-DOKUMENTY.md

  Sekwencja FSL-D (wykonaj w tej kolejności):

  FSL-D-INIT:
    1. Pobierz listę tez T1..Tn z CLAIM-VALIDATION (W1.2a)
    2. Pobierz SD-REJ (D01..D[N]) z MOD-SKAN-DOWODOW-KOMPLETNY
    3. Zbuduj pustą FSL-D-MACIERZ: T[n] × twierdzenia atomowe

  FSL-D-SCAN (per KAŻDA teza T[n], po kolei):
    A. Rozłóż T[n] na twierdzenia atomowe TC[n,1]..TC[n,k]
    B. Per KAŻDE TC[n,k]: przeszukaj WSZYSTKIE D[id] z SD-REJ
       ⛔ ZAKAZ CYTOWANIA Z PAMIĘCI: wracaj do SD-FAKTY[D[id]], nie do
          odtworzenia z kontekstu konwersacji
       ⛔ ZAKAZ WNIOSKOWANIA Z NAZWY PLIKU: przeszukuj każdy D[id]
          niezależnie od tego czy jego nazwa „pasuje" do tezy
    C. Klasyfikuj: ✅ POTWIERDZONE / ⚠️ POŚREDNIE / ⬛ FSL-D-LUKA (🔴/🟠/🟡)
    D. Wpisz do FSL-D-MACIERZ: TC[n,k] → D[id], lok.[strona/zakładka/obraz/godz.],
       treść wyekstrahowana z SD-FAKTY (nie parafrazowana z pamięci)

  FSL-D-ORPHAN:
    Po skanowaniu wszystkich T[n]: czy jest D[id] z 0 przypisań do tez?
    → TAK: sprawdź czy zawiera fakty na nową tezę T_new → zaproponuj użytkownikowi
    → NIE: FSL-D-NEUTRALNY

  FSL-D-REPORT:
    Wyświetl raport z FSL-D-MACIERZ (wg formatu z MOD-FSL-DOKUMENTY.md)
    Policz: ✅ potwierdzone / ⚠️ pośrednie / ⬛ luki per klasa (🔴/🟠/🟡)

  Rozgałęzienie:
    ⬛ FSL-D-LUKA 🔴 → ⛔ STOP: zadaj PYTANIA FSL-D; czekaj na decyzję a/b/c/d
    ⬛ FSL-D-LUKA 🟠 → kontynuuj, ale w piśmie: żądanie ewentualne + UWAGI REDAKCYJNE
    ⬛ FSL-D-LUKA 🟡 → notacja w raporcie; nie blokuje
    brak luk 🔴/🟠 → przejdź do KROK KD (karty dowodowe)

  ⛔ ZAKAZ-FSL-D: NIE przystępuj do KROK KD ani KROK ŁD ani KROK MT
     dopóki FSL-D-REPORT nie jest wyświetlony i luki 🔴 nie są rozwiązane.
     Naruszenie = błąd krytyczny pipeline — równoważny pominięciu CLAIM-VALIDATION.

KROK KD: Wypełnij karty dowodowe i rejestr faktów
  view shared/MOD-KARTA-DOWODU.md
  → Per każdy D[nn] ze SD-FAKTY: wypełnij KD-1 (karta dowodowa)
  → Zbuduj KD-2 (rejestr faktów F-nn z pewnością i źródłem)
  → Narysuj KD-3 (graf relacji dowód→fakt→teza per teza)

KROK ŁD: Zbuduj łańcuchy dowodowe z kart
  view shared/MOD-LANCUCH-DOWODOWY.md
  → Per każda teza T-X: wykonaj ŁD-1..ŁD-7
  → Ogniwa łańcucha = fakty F-nn z rejestru (nie lista plików)
  → BRAMKA EQG (ŁB-5): wyklucz ogniwa szkodliwe
  → Scoring ★-★★★★★ per teza główna
  → OUTPUT łańcucha ŁD-XX → wejście do W1.3

KROK MT: Macierz Dowód × Teza (⛔ OBOWIĄZKOWE gdy ≥2 dowody i ≥2 tezy)
  view shared/MOD-MACIERZ-DOWOD-TEZA.md
  → MT1: inwentaryzacja — lista T1..Tn z przesłankami + lista D1..Dm z kategorią A/B/C/D
  → MT2: skan dwukierunkowy (A: każdy dowód → wszystkie tezy; B: każda teza → pokrycie przesłanek)
  → MT3: klasyfikacja powiązań: [K] KLUCZOWY / [W] WIELOFUNKCYJNY / [R] REDUNDANTNY / [RK] RYZYKOWNY
  → MT4: raport — tabela D×T, pokrycie tez (%), luki KRYTYCZNE/ISTOTNE, decyzje RK
  → MT5: zasilenie pipeline:
       • luki KRYTYCZNE z MT4 → W1.5 jako ⬛ BRAK KRYTYCZNY
       • luki ISTOTNE z MT4   → W1.5 jako ⬛ BRAK ISTOTNY
       • dowody [W] (wielofunkcyjne) → powołuj RAZ w sekcji "Na dowód" z listą tez
       • po W2: MT5-MANDATE-ALL-EVIDENCE (cross-check N_pismo ≥ 0.7 × N_macierzy)

  ⛔ POZYCJA: ten krok jest TUTAJ (W1.2c), NIE w W2.
     Macierz musi powstać PRZED mapą przesłanka→dowód (W1.3).
     Tworzenie macierzy w W2 = błąd architektoniczny: pismo redagowane
     bez wiedzy o lukach i wielofunkcyjności dowodów.

  ⛔ WBUDOWANIE W PISMO: tabela D×T z MT4 WCHODZI do treści pisma
     jako osobna sekcja (przed lub po uzasadnieniu, zależnie od konwencji sądu).
     Macierz nie jest tylko krokiem wewnętrznym — jest widoczna dla sądu,
     bo art. 227 i 232 k.p.c. wymagają wskazania jakie fakty mają być wykazane
     jakim dowodem. Wnioski dowodowe formułowane są PER TEZA (nie jako lista en bloc).

  ⛔ FORMAT SĄDOWY — ZAKAZ SYMBOLI:
     Tabela w piśmie procesowym NIE używa symboli wewnętrznych (●●●, ★, [K], [W], RK).
     Te oznaczenia służą wyłącznie wewnętrznemu pipeline'owi (MT1–MT5).
     Tabela dla sędziego ma WYŁĄCZNIE kolumny czytelne dla prawnika:
       Lp. | Dowód (nazwa i opis) | Lokalizacja w aktach (str./zał./godz.) |
       Roszczenie (T1/T2/... lub pełna nazwa) | Na okoliczność (opis faktów)
     Dla dokumentów z protokołu: obowiązkowe wskazanie strony protokołu i godziny.
     Dla załączników: numer załącznika.
     Klasyfikacje wewnętrzne (siła dowodu, ryzyka krzyżowe) — tylko do użytku
     wewnętrznego modelu; nie trafiają do pisma.

⛔ Generator pisma nie pyta "jakie dowody mam?"
   Pyta: "jakie FAKTY F-nn prowadzą do TEZY T-X i w jakim łańcuchu?"
⛔ ZAKAZ: sekcja "Na dowód" bez powiązania z F-nn z rejestru.
⛔ ZAKAZ: W1.3 bez gotowych łańcuchów ŁD-XX dla tez głównych.
⛔ ZAKAZ: W1.3 bez gotowej macierzy D×T (gdy ≥2 dowody i ≥2 tezy).
⛔ ZAKAZ: wnioski dowodowe jako lista en bloc — każdy wniosek wskazuje tezę Tn.