Intake Sufficiency PL - ocena wystarczalnosci zlecenia

Filozofia

Polowa zlych opinii prawnych to nie blad analizy, tylko zbyt cienkie wejscie. Klient pisze "sprawdzcie te umowe", po czym okazuje sie, ze nie wiadomo wobec jakiego ryzyka, kto jest druga strona ani jaki jest cel. Ten skill nazywa to, czego brakuje, ZANIM zacznie sie praca - i zamienia luki w konkretne pytania do klienta, zamiast w domysly wpisane do deliverable.

Skill nie wykonuje pracy prawnej. Ocenia kompletnosc wejscia i generuje pytania.

Lustro routera

• legal-request-router-pl patrzy na zadanie i decyduje, jaka kontrole dac outputowi (grounding / debata / paczka).
• intake-sufficiency-pl patrzy na zlecenie i decyduje, czy wejscie wystarcza, by zaczac.

Naturalna kolejnosc: najpierw intake-sufficiency (czy mam dosc), potem praca, potem router (jak skontrolowac wynik).

Rubryka wystarczalnosci (6 wymiarow, 0-100)

Werdykt: strong >= 80, adequate >= 50, insufficient < 50.

Workflow

1. Pseudonimizuj wejscie przez let-it-be, jesli zawiera dane objete tajemnica.
2. Oceń zlecenie wg 6 wymiarow rubryki - kazdy wymiar ma fakty na poparcie oceny, nie ogolnik.
3. Wypisz luki i niejednoznacznosci - co konkretnie jest nieobecne lub niejasne.
4. Wyodrebnij premisy prawne klienta - kazde twierdzenie PRAWNE w zleceniu ("termin juz minal", "umowa jest niewazna, bo brak formy", "przepis X tego zakazuje", "mamy 14 dni na odpowiedz") to premisa do weryfikacji, nie fakt. Klient moze sie mylic co do prawa, a analiza zbudowana na blednej premisie jest bledna w calosci, nawet gdy rozumowanie jest poprawne. Kazda premise:
   • wypisz osobno z tagiem [premisa klienta - do weryfikacji u zrodla],
   • jesli jest ISTOTNA dla wyniku: zweryfikuj przed startem (SAOS / ISAP / saos-orzecznictwo / tekst umowy) albo dodaj do pytan/instrukcji wstepnych jako pierwsze zadanie,
   • jesli weryfikacja ja OBALA: powiedz to wprost i nie kontynuuj na blednym zalozeniu - nawet jesli klient przedstawil je stanowczo.
5. Wygeneruj pytania uzupelniajace - jedno pytanie na luke, kazde przypisane do wymiaru, oznaczone wymagane/opcjonalne. Pytanie ma byc gotowe do wyslania klientowi, nie notatka dla siebie.
6. Zloz szkielet karty zlecenia - cel / zakres / podmiot / ryzyka / kryteria sukcesu / instrukcje wstepne. Pola, ktorych nie da sie wypelnic z wejscia, zostaja jawnie "(do ustalenia - patrz pytania)".

Schemat wyjscia

{
  "wystarczalnosc": {
    "score": 45,
    "werdykt": "insufficient",
    "luki": ["brak zdefiniowanego celu", "podmiot druga strona niezidentyfikowany"],
    "niejednoznacznosci": ["'pilne' bez konkretnego terminu"]
  },
  "premisy_prawne": [
    { "id": "p1", "twierdzenie": "termin na odpowiedz wynosi 14 dni", "istotna": true, "status": "do_weryfikacji", "zrodlo_weryfikacji": "KPC / tekst umowy" }
  ],
  "pytania_uzupelniajace": [
    { "id": "q_cel", "text": "Jaki jest cel - opinia, pismo czy negocjacja?", "wymiar": "cel", "wymagane": true }
  ],
  "karta_zlecenia": {
    "cel": "(do ustalenia - patrz pytania)",
    "zakres": "...",
    "podmiot": "...",
    "ryzyka": [],
    "kryteria_sukcesu": [],
    "instrukcje_wstepne": "..."
  }
}

Output (dla uzytkownika)

## Wystarczalnosc zlecenia: 45/100 (insufficient)

### Luki
- brak zdefiniowanego celu sprawy
- druga strona niezidentyfikowana (brak nazwy / NIP)

### Pytania do klienta (zadac PRZED rozpoczeciem)
- [wymagane] (cel) Czy oczekuja Panstwo opinii, pisma czy wsparcia w negocjacji?
- [wymagane] (podmiot) Jaka firma jest druga strona (pelna nazwa, NIP/KRS)?
- [opcjonalne] (ograniczenia) Czy jest twardy termin?

### Karta zlecenia (szkielet)
- Cel: (do ustalenia - patrz pytania)
- Zakres: weryfikacja umowy dostawy
- Podmiot: (do ustalenia)
- Instrukcje wstepne: zebrac komplet zalacznikow do umowy

Rekomendacja: NIE zaczynaj analizy merytorycznej przed odpowiedzia na pytania wymagane.

Reguly twarde

• Insufficient = stop, nie zgaduj. Przy werdykcie insufficient nie wypelniaj luk domyslami w deliverable - najpierw pytania do klienta. Domysl wpisany jako fakt to zarodek blednej opinii.
• Pytanie na luke, nie na zapas. Nie generuj pytan o rzeczy, ktore wejscie juz zawiera.
• Jedno wejscie, jedna ocena. Skill ocenia kompletnosc, nie jakosc merytoryczna sprawy.
• Premisa prawna klienta to hipoteza, nie fakt. Twierdzen klienta o prawie (terminy, zakazy, niewaznosc, tresc przepisu) nie przenosi sie do karty zlecenia jako ustalen - ida do premisy_prawne ze statusem do_weryfikacji. Analiza merytoryczna nie startuje na istotnej premisie, ktorej nikt nie sprawdzil u zrodla.

Ochrona danych (RODO)

Ocena dziala na tresci zlecenia - jezeli zawiera dane objete tajemnica zawodowa, pseudonimizuj przez let-it-be przed wyslaniem do modelu. Skill nie zapisuje wejscia poza katalogiem sprawy.

Integracja z AI Act

Jawne nazwanie luk i niejednoznacznosci na wejsciu to element nadzoru czlowieka (art. 14) - czlowiek swiadomie decyduje, czy zaczac z niepelnym wejsciem, zamiast dostac deliverable udajacy kompletnosc. Ocena wystarczalnosci moze trafic do legal-ai-audit-bundle jako uzasadnienie startu sprawy.

Atrybucja

Pattern (analiza wystarczalnosci briefu: score + luki + pytania uzupelniajace + karta zlecenia) zainspirowany przez AnttiHero/lavern (Apache 2.0, src/api/briefing/briefing-schema.ts). Rubryka 6 wymiarow, schemat i reguly napisane od zera pod polski kontekst kancelaryjny. Nie skopiowano kodu Lavern.

Wspólne reguły wtyczki fundament-weryfikacyjny (Fundament weryfikacyjny)

Te reguły obowiązują w każdym skillu tej wtyczki, także gdy sam skill milczy. Są skopiowane do każdego skilla, więc działają zarówno po instalacji całej wtyczki, jak i pojedynczego skilla. Pełniejszy standard: https://github.com/matematicsolutions/awesome-matematic-skills-pl/tree/main/references

Pięć warstw ochrony (przed każdym disclaimerem)

1. Weryfikacja źródła - przepisy i orzecznictwo z baz, nie z pamięci modelu.
2. Klasa pewności - każda teza prawna oznaczona: zweryfikowane / do sprawdzenia / nie używać.
3. Kontrola przesłanek - fakty od użytkownika sprawdza się przed analizą.
4. Jawny zakres ujemny - każdy skill mówi, czego NIE robi.
5. Bramka człowieka - uprawniona osoba sprawdza i zatwierdza wynik.

Jeśli błąd przeszedłby bez zatrzymania przez warstwy 1-5, wina jest w skillu. Naprawiamy narzędzie, nie dopisujemy noty. Nota "to nie porada prawna" nie zatrzymuje błędu i nie przenosi odpowiedzialności.

Tagi pewności

• Zweryfikowane - źródło sprawdzone w sesji, z pełną sygnaturą: (kodeks cywilny art. 415), (wyrok SN II CSK NN/RR, SAOS).
• Do sprawdzenia - prawdopodobne, niezweryfikowane: [sprawdź w SAOS].
• Nie używać - zmyślona sygnatura lub przepis. Pomiń, nigdy nie wymyślaj numeru.

Tag stoi przy linii, której dotyczy. Samo istnienie sygnatury nie wystarcza - treść trzeba sprawdzić.

Bramka człowieka

Nic nie zostaje wysłane, złożone, podpisane ani opublikowane, zanim sprawdzi i zatwierdzi to uprawniony człowiek. Wynik skilla to projekt, nie gotowy dokument.

Zakres pluginu

Fundament weryfikacyjny jest neutralny jurysdykcyjnie - to rdzeń metody, nie substancja prawa. Nie łączy się z żadnym źródłem zewnętrznym (brak konektorów MCP) i nie wysyła danych na zewnątrz. Substancję dostarczają osobne pluginy (orzecznictwo, dokumenty).