Intake Sufficiency Pl

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 / szukaj-orzeczen-v2 / 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.