Recenzent PR/diffow dla PATRONa - polski LegalTech AI agent dla kancelarii. Wylapuje regresje specyficzne dla repo PATRON ktorych nie zlapie generyczny lint - org scoping multi-tenant, authless routes, niespodzianki w migracjach SQLite/Postgres, bezposredni SQL poza warstwa db, brak worker sync w cache, UI bez generated SDK, sekrety w logach, regresje audit_log, brak grounding cytatow, AI Act art. 12 record-keeping. Format findings file:line -> problem -> correct pattern, 3 buckets Blocker/Should-fix/Nit. Uzywaj gdy - recenzja PR/diff PATRON przed merge, code review pre-commit, audyt zmian w mcp-security-gateway/audit_log/ring-policy/auth, review zmian w MCP serverach matematicsolutions/*, weryfikacja czy nowy kod nie wprowadza wyciekow danych klienta kancelarii (RODO/tajemnica adwokacka), audyt drift dokumentacji vs kod. Trigger - "marko review PR", "code review PATRON", "audyt diff", "review tej zmiany", "sprawdz PR", "czy bezpiecznie merge", "PR audit", "security review PATRON", "blast radius zmiany".
El comando permanece en una sola línea. Desplázate horizontalmente para revisarlo antes de copiarlo.
¿Prefieres una copia local? Descarga los archivos que SkillsMP tiene disponibles ahora.
Mostrando SKILL.md
SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
matematic-patron-pr-review-pl
description
Recenzent PR/diffow dla PATRONa - polski LegalTech AI agent dla kancelarii. Wylapuje regresje specyficzne dla repo PATRON ktorych nie zlapie generyczny lint - org scoping multi-tenant, authless routes, niespodzianki w migracjach SQLite/Postgres, bezposredni SQL poza warstwa db, brak worker sync w cache, UI bez generated SDK, sekrety w logach, regresje audit_log, brak grounding cytatow, AI Act art. 12 record-keeping. Format findings file:line -> problem -> correct pattern, 3 buckets Blocker/Should-fix/Nit. Uzywaj gdy - recenzja PR/diff PATRON przed merge, code review pre-commit, audyt zmian w mcp-security-gateway/audit_log/ring-policy/auth, review zmian w MCP serverach matematicsolutions/*, weryfikacja czy nowy kod nie wprowadza wyciekow danych klienta kancelarii (RODO/tajemnica adwokacka), audyt drift dokumentacji vs kod. Trigger - "marko review PR", "code review PATRON", "audyt diff", "review tej zmiany", "sprawdz PR", "czy bezpiecznie merge", "PR audit", "security review PATRON", "blast radius zmiany".
license
Apache-2.0
attribution
{"source":"dograh-hq/dograh","url":"https://github.com/dograh-hq/dograh","license":"BSD-2-Clause","relationship":"pattern-only","note":"Cherry-pick struktury review-pr (v1.31.0): format znalezisk plik:linia i trzy kubełki Blocker/Should-fix/Nit. Reguły specyficzne dla repo PATRON napisane od zera.\n"}
allowed-tools
["Read","Grep","Glob","Bash"]
data-residency
local
requires-human-approval
false
pii-egress
none
matematic-patron-pr-review-pl
Recenzent PR/diffow PATRON - polskiego LegalTech AI agenta dla kancelarii. Cherry-pick struktury z dograh v1.31.0 review-pr (BSD-2, 286 linii), zaadaptowane pod kontekst MateMatic.
Komplementarny do:
Wewnetrzny pipeline QA MateMatic dla tresci PL (artykuly, copy LI, BW) - ocena czytelnosci i poprawnosci. Ten skill ocenia diff kodu.
matematic-konstytucja-ai (w tym hubie) - dokument governance dla klienta. Ten chroni kod produktu.
Self-review pre-commit (6 zasad MateMatic) - poprzedza ten skill, sprawdza ogolne, ten skill nad nimi sprawdza repo-specific risks.
Kiedy uzywac
Recenzja PR przed merge do main w repo PATRON / KGLF / matematicsolutions MCP serwery
Pre-commit audit wlasnego diffu w PATRONie
Audyt zmian w komponentach krytycznych: mcp-security-gateway, audit_log, ring-policy, auth
Po duzej refaktoryzacji - sweep pod katem regresji
Przed pushem do origin po sesji 3+ commitow
Glowne tryby awarii w repo PATRON
Multi-tenant - brak org scoping na request-reachable read/write (kancelaria A widzi sprawe kancelarii B)
Authless route lub websocket - silently public endpoint
Webhook bez signature verification lub trust w unsigned fields
SQL pisany poza lib/db/*_client.ts - inkasacja warstwy
Cache per-worker bez worker sync - stale state w innych procesach
UI bypassuje generated SDK - direct fetch('/api/v1/...') zamiast typed client
Migracja niebezpieczna na produkcji - NOT NULL bez backfilla, brak downgrade()
Brak globalnego middleware auth w PATRON. Kazda trasa deklaruje swoja auth.
Zaleznosci auth z lib/auth/depends.ts:
getUser (user kancelarii w organizacji)
getUserWs (websocket - kancelaria realtime)
getSuperuser (root MateMatic, NIE klient kancelaria)
requireRing(N) (ring-policy ADR-0027) - dla decyzji authorization
Checks:
Nowy @router.<verb>(...) bez auth dependency = silently public. Finding chyba ze plik ustanawia public auth pattern (np. webhook signed, public token).
getUser na impersonation / cross-org / global reporting -> powinno byc getSuperuser.
Route reimplementujaca Bearer/X-API-Key parsing zamiast shared dependency = finding.
WebSocket bez Depends(getUserWs) i bez public-token flow = finding.
Tightening CORS do fixed origin list potrzebuje strong justification - PATRON polega na cross-origin embedding (widget kancelarii).
Nowy endpoint zwracajacy dane kancelarii BEZ wpiecia w ring-policy (requireRing(2)+) = finding.
2. Organization scoping (THE CROSS-TENANT RULE - PRIORYTET #1)
NAJWAZNIEJSZA regula w PATRON. Kancelaria A NIGDY nie widzi danych kancelarii B. Kazdy request-reachable read/write resourca org-scoped MUSI filtrowac/walidowac przez organization_id.
Polega na: AGENTS.md canonical summary + ADR-0027 ring-policy.
Determinacja scope:
Direct scope: model ma organization_id (cases, documents, prompts, agents)
Indirect scope: model siega org przez parent FK (e.g. comments -> document -> org)
Legacy spelling moze istniec w starych migracjach (org_id, tenant_id), ale nowy kod uzywa organization_id
Checks:
Kazdy *ById(...) / getXById(...) w route handler = suspicious. Jesli request-reachable i unscoped = finding.
Nowe list* / get* endpointy filtruja w SQL (WHERE organization_id = ?), NIE w TS po .all().
Jesli request pisze FK do innego org-scoped resourca, route MUSI najpierw fetch target row z user.selectedOrganizationId i odrzucic jesli nie nalezy do org.
Services wolane z routes preserva scoping. Drop organization_id w DB client call = trace caller.
Background tasks NIE dostaja org context for free. Musza reload parent row i derive org z tego.
Webhooki derive org z signed identifier, NIE z caller-supplied body fields organization_id.
Nowy kod uzywa kanoniczne organizationId, nie orgId, tenantId, organisationId.
Nowe tools uzywaja authenticateMcpRequest() (lub Pythonowy authenticate_mcp_request()), NIE reimplementuja API-key validation.
Nowe tool DB lookups preserva org scoping jak REST routes.
Tools wolajace external URLs waliduja URL i konsideruja SSRF.
Nowe MCP tool wymieniony w instructions ma istniec w registry (drift test).
errorCode zwracane przez tool sa w docstring tool (drift test).
ToolAnnotations dla read-only (readOnlyHint=true) dla tooli ktore nie mutuja.
8. Telephony / webhook handlers
Checks:
Nowy provider webhook flow implementuje verifyInboundSignature() lub provider equivalent.
Minimal pre-verification work moze byc wymagana zeby zidentyfikowac candidate config, ALE route NIE robi unrelated workflow/user/stateful work przed verification.
Org derivation z provider identifiers walidowanych przez webhook auth flow.
Webhook NIE ufa raw body organizationId.
Jesli webhook referencuje numer telefonu, walidacja ze numer istnieje dla derived org.
9. UI (apps/ui/**, apps/dashboard/**) - generated SDK only
Frontend rozmawia z backendem przez apps/ui/src/client/ (generated typed SDK).
Checks:
fetch('/api/v1/...') lub fetch(\${backendUrl}/api/v1/...`)` w app code = finding chyba ze aktualny kod udowadnia narrow exception.
SDK calls firowane przed auth state ready = finding.
Local interfaces duplikujace generated types = finding.
Backend API shape zmienione + UI konsumuje = apps/ui/src/client/ powinno tez sie zmienic.
10. Logging, secrets, constants
Checks:
Nowy kod uzywa shared logger (np. pino z PII masking), NIE console.log.
Nowy process.env.X poza lib/constants.ts = finding.
NIE logujemy: API keys, bearer tokens, credentials, full webhook bodies, PII klienta kancelarii (PESEL, NIP, imiona, sygnatury aktualnych spraw).
Common offender shapes:
logger.info(\config: ${JSON.stringify(config)}`)`
logger.debug(requestBody)
Logging raw config / user configuration rows
11. Tests (tests/**, __tests__/**)
Checks:
Async waits uzywaja bounded timeout (pTimeout, setTimeout race), NIE while (!done).
Tests run against .env.test, NIE .env.
Integration tests NIE neutered przez mockowanie zeby test passed - musza hit prawdziwy testowy DB.
Tests zalezne od mutable shared DB state across test cases = suspicious.
12. Schemas (lib/schemas/*.ts, lib/dto/*.ts)
Checks:
Nowe response schemas NIE expose internal FKs / IDs chyba ze caller naprawde potrzebuje.
Request schemas akceptujace org-scoped FK values = trigger do inspekcji corresponding route pod katem section 2 ownership validation.
13. PATRON-specific - PII, audit_log, AI Act art. 12
Tej sekcji NIE ma w dograh - to MateMatic-specific dla legal AI.
Checks:
Operacja decyzyjna (klasyfikacja dokumentu, rekomendacja, generowanie pisma, anonimizacja) MUSI zapisac do audit_log (ADR-0033). Brak entry = finding (AI Act art. 12 record-keeping).
PII detection / anonimizacja inline PRZED storage uzytkowych logow (matematic-anonimizacja-pl jako pre-storage filter). Bypass = finding.
Cytat z orzeczenia / ustawy w odpowiedzi LLM musi przejsc citation-grounding-pl (mechaniczna weryfikacja string-match). Jesli kod generuje odpowiedz LLM bez tego layera = finding.
Pisma procesowe MUSZA przejsc wewnetrzny pipeline QA MateMatic (anti-slop PL + senior review min 2 rundy) przed docx. Kod generujacy .docx bez tej walidacji = finding.
Dane z prawdziwych akt klienta (kwoty, sygnatury, inicjaly) w README/aktualnosci/post LI = czerwona linia tajemnicy adwokackiej (art. 6 ust. 1 PrAdw) / radcowskiej (art. 3 ust. 3 RadcPrU). Grep przed push.
Nowy retention policy: dane klienta kancelarii max 90 dni in-memory / 7 lat archive (RODO + KPK + KC).
ADR rezerwacja: kazdy duza zmiana decyzyjna potrzebuje ADR proposed przed implementacja (NIE post-hoc).
Komendy:
rg -n "auditLog|writeAuditEntry|recordDecision" lib/audit/ lib/services/
rg -n "anonymize|piiDetect|let-it-be" lib/pii/ lib/services/
rg -n "PESEL|NIP|REGON" README.md docs/ aktualnosci/ # zero hits expected w public
14. Konstytucja drift - per AGENTS.md
Po gh repo create / push nowego komponentu PUBLICZNEGO uruchom 7-stopniowa checkliste catchup (zasada hub kuratorski MateMatic - kod wyprzedza dokumentacje). Ten skill sprawdza w PR diffe:
Checks:
Nowy komponent zarejestrowany w main? README repo update? AGENTS.md update? CHANGELOG entry?
Konstytucja PATRON wymaga SEMVER bump przy nowym ADR przyjetym (rezerwacja chronologii przy sesjach rownoleglych).
Errata: jesli ADR rodzic mial nazwe tabeli/funkcji ktora sie zmienila, sprawdz literal cytat w nowych ADR (propagacja erraty przez literal cytat).
Final pass: shape the report
Findings w 3 buckets:
Blocker (MUST fix przed merge):
Missing org scope na request-reachable lookup (sekcja 2)
Route bez auth bez deliberate public auth mechanism (sekcja 1)
Webhook bez signature verification lub significant unrelated work przed verification (sekcja 8)
Migracja bez safe backfilla lub meaningful downgrade (sekcja 6)
UI bypassuje generated SDK dla internal API calls (sekcja 9)
Secrets/PII klienta logowane (sekcja 10, 13)
Operacja decyzyjna BEZ audit_log entry (sekcja 13)
Generowanie LLM bez citation-grounding lub pisma docx bez wewnetrznego pipeline QA (sekcja 13)
Dane z realnych akt w public artefactach (sekcja 13)
