FIX | CR skills

[pekral]

Potřebuji zajistit, aby všechny skilly rozšířili výstup do technické a do funkcionální části tak, že technické code review bude striktně kontrolovat napsaný kod podle všech pravidel v projektu.

Funkcionální bude report toho, zdali úpravy splnili cíl zadání a všechny požadavky jsou splněny!

[pekral]

Plán (metis) — #737 FIX | CR skills: dvoudílný výstup Technical + Functional

Read-only analýza. Neimplementuje se zde nic — plán pro talos. Kanonická próza CR pravidel zůstává anglicky (konvence projektu, Exception — technical CR findings on the GitHub PR); handoff je česky.

Goal (cíl)

Každý plnohodnotný CR wrapper (code-review, code-review-github, code-review-jira, code-review-bugsnag) musí produkovat výstup explicitně rozdělený na dvě části:

1. Technical review — striktní kontrola napsaného kódu proti všem pravidlům projektu. = stávající chování (Core Analysis / Strict rule compliance / Architecture / security / coverage walks). Žádná změna logiky. Publikuje se na PR komentáři.
2. Functional review — explicitní, vždy vyrenderovaný report odpovídající na: (a) je splněn cíl zadání? (Goal met: Yes / No) a (b) jsou splněny všechny požadavky / acceptance criteria? — jmenovitý seznam každého extrahovaného požadavku / acceptance criterion se stavem Met / Not met / Partial / Divergent, plus stávající detail Critical gapů u nesplněných. Publikuje se na konsolidovaném linked-tracker komentáři (přes pr-summary); jednořádkový verdikt se zrcadlí na summary line PR komentáře.

Klíčové rozhodnutí (nutné potvrzení): issue vyžaduje afirmativní funkcionální report ("report toho, zdali úpravy splnili cíl zadání a všechny požadavky jsou splněny"). To záměrně obrací hluboce zakořeněnou konvenci projektu "report only what needs action; never render a positive 'satisfies the assignment' banner; omit when clean" — a to výhradně pro funkcionální verdikt. Technické sekce si ponechávají omit-when-empty. Tuto výjimku je nutné zapsat explicitně do kanonického pravidla.

Architecture (návrh — reuse-first, nejmenší bezpečné řešení)

Funkcionální vrstva už z 90 % existuje — znovupoužíváme ji, nestavíme nový engine (potvrzeno daidalos hintem "navázat na existující assignment conformance"):

• assignment-compliance-check už extrahuje každé acceptance criterion (krok 2) a klasifikuje každé (krok 4: Satisfied / Partial / Missing / Divergent) — dnes ale Satisfied zahazuje a při čistém stavu vrací skip.
• code-review SKILL má Assignment Conformance Gate s verdiktem assignment conformance: conformant / N gap(s) / no linked issue na summary line.
• pr-summary má {assignment_verdict} top banner (dnes jen negativní).

Jeden normativní kontrakt + reuse propagace:

1. Kanonický kontrakt v rules/code-review/general.mdc — rozšířit stávající sekci ## Assignment Conformance (řádky 26–30) na "Two-part CR output — Technical & Functional review":

   • Pojmenovat obě povinné části a co každá reportuje (viz Goal).
   • Functional review reportuje (a odlišuje se od technické): NE stav kódu vůči pravidlům, ale splnění zadání — verdikt Goal met: Yes/No + checklist extrahovaných acceptance criteria / požadavků se stavem Met / Not met / Partial / Divergent. Goal met: No, pokud aspoň jedno není Met (každé takové zůstává Critical gap).
   • Explicitní výjimka z "report-only-what-needs-action": funkcionální verdikt je afirmativní — na čistém stavu renderuje Goal met: Yes — all N acceptance criteria satisfied, ne ticho. Výjimka je scoped POUZE na funkcionální verdikt.
   • Zachovat single-lens carve-out: api-review / security-review funkcionální část nevlastní (reuse princip, řádek 29). Rozhodnutí pro uživatele: zadání jmenuje api-review — viz "Otevřené rozhodnutí" níže.

2. skills/code-review/SKILL.md — tenká reference na dvoudílný kontrakt v Assignment Conformance Gate + Output Rules; verdikt vždy renderovaný (afirmativní i negativní). Pozor na 5000-token cap (skill má ~4563 slov) → jen reference na pravidlo, žádné opakování prózy.

3. skills/assignment-compliance-check/SKILL.md (jádro expanze) — z "gaps-only, omit-when-clean" na funkcionální report: emitovat celý checklist (včetně Satisfied → Met) + afirmativní verdikt; už neomítá při čistém stavu. Upravit Output Format, Done when, Constraints ("Do not list satisfied requirements" → obrátit pro funkcionální report).

4. skills/pr-summary/SKILL.md + templates/pr-summary-github.md + templates/pr-summary-jira.md — {assignment_verdict} banner renderuje i afirmativní verdikt (✅ Changes satisfy the assignment — all N acceptance criteria met / cs ✅ Změny splňují zadání — všech N acceptance criteria splněno); funkcionální blok embedován na každém běhu (ne jen při gapu). Obrací klauzuli "never render a positive banner".

5. Output templates wrapperů — orámovat PR-comment body explicitně jako Technical review a ponechat funkcionální verdikt na summary line:

   • skills/code-review/templates/review-output.md
   • skills/code-review-github/templates/pr-comment-output.md
   • skills/code-review-jira/templates/github-output.md
   • skills/code-review-bugsnag/templates/github-output.md

Implementation steps (uspořádané, každý samostatně reviewovatelný)

1. Kanonický kontrakt — rules/code-review/general.mdc ## Assignment Conformance → two-part contract + afirmativní výjimka + definice co funkcionální report obsahuje. (Verify: composer build — pin krok 8.)
2. assignment-compliance-check/SKILL.md — full checklist + afirmativní verdikt + always-render; srovnat Constraints/Output Format/Done when. (Verify: čtený obsah odpovídá kontraktu.)
3. pr-summary SKILL + oba templates — afirmativní {assignment_verdict} + always-embed funkčního bloku. (Verify: obě jazykové varianty.)
4. code-review/SKILL.md — tenká reference, hlídat 5000-token cap. (Verify: skill-check + token cap.)
5. 4× wrapper output templates — orámování Technical review + funkcionální verdikt na summary line.
6. api-review — dle rozhodnutí (default: vynechat + zdokumentovat carve-out; pozn.: má už vlastní assignment cross-check, řádek 77).
7. CHANGELOG.md — feat(code-review) entry.
8. Content-pin testy tests/Installer/CodeReviewContentTest.php — viz níže. Nejdřív spustit pin suite (content-pin-tests-are-the-contract-enforcement), zjistit které staré fráze jsou load-bearing, teprve pak měnit.
9. composer build zelený před push.

Content-pin: co přidat / změnit v CodeReviewContentTest.php

• ADD pin na nové fráze two-part kontraktu v rules/code-review/general.mdc (např. Two-part CR output, Technical review, Functional review, Goal met, formulace afirmativní výjimky) + odpovídající reference v code-review/SKILL.md a v output templates.
• UPDATE/REPLACE pins vázané na obracenou konvenci — dnes pinují starý stav:
  • řádky ~31–42: Assignment non-compliance verdict (top banner), {assignment_verdict}, do not satisfy the assignment → rozšířit o afirmativní verdikt.
  • assignment-compliance-check "omit when clean" / "Do not list satisfied requirements" pins (pokud existují) → přerámovat.
  • pr-summary "never render a positive banner" → obrátit.
• Řídit se content-pin-tests-are-the-contract-enforcement: každá nová/změněná normativní věta = pin ve stejném PR; konsolidace prózy = spustit pin suite předem (fráze jako Reuse Existing Logic uvnitř seznamů bývají load-bearing pro jiný kontrakt).

Sources (klíčové soubory a kotvy)

• rules/code-review/general.mdc:26-30 — ## Assignment Conformance (kanonický home, k rozšíření).
• skills/code-review/SKILL.md:55-64 — Assignment Conformance Gate; :145-168 — Output Rules; 5000-token cap.
• skills/assignment-compliance-check/SKILL.md — celý (jádro expanze; dnes gaps-only + omit-when-clean).
• skills/pr-summary/SKILL.md:24,52 + templates/pr-summary-{github,jira}.md:1 — {assignment_verdict} banner (dnes jen negativní).
• Output templates: skills/code-review/templates/review-output.md, skills/code-review-github/templates/pr-comment-output.md, skills/code-review-jira/templates/github-output.md, skills/code-review-bugsnag/templates/github-output.md.
• tests/Installer/CodeReviewContentTest.php:26,28,31-42,286-304 — assignment pins (~142 assertions celkem, 5000-token cap).
• Vzor mechanismu: PR feat(code-review): add self-documenting comment & doc hygiene lens #735 / commit bbb3c4e (self-documenting lens: normativní próza do rule verbatim → tenká reference ve skill → content-pin test) a commity f386b29/ce2056f (class-refactoring lens).
• Memory: content-pin-tests-are-the-contract-enforcement, cross-cutting-rule-belongs-in-compound-engineering, laravel-rules-tracked-source (edituj root rules/, ne .claude/).

Success criteria

• Kanonický kontrakt v rules/code-review/general.mdc definuje dvoudílný výstup (Technical + Functional) vč. afirmativní výjimky a přesné náplně funkcionálního reportu (Goal met Yes/No + checklist se stavy).
• Všechny 4 CR wrappery produkují oba díly; funkcionální verdikt je vždy vyrenderovaný (afirmativní i negativní), s enumerovaným seznamem acceptance criteria a jejich stavem.
• assignment-compliance-check + pr-summary reverzují omit-when-clean / no-positive-banner pouze pro funkcionální verdikt.
• Content-pin testy pinují nové fráze a starý (obrácený) stav je odstraněn/přepsán.
• composer build zelený (skill-check, token cap, README count testy nedotčeny — nepřidává se skill dir).

Otevřené rozhodnutí (pro uživatele / daidalos)

1. api-review: zadání jej jmenuje, ale je to single-lens skill záměrně vyjmutý z assignment conformance (řádek 29). Doporučení metis: vynechat z funkcionální části (reuse princip, respekt k architektuře); volitelně mu přidat jen lehký funkcionální verdikt navázaný na jeho už existující assignment cross-check (api-review/SKILL.md:77), bez spuštění plného assignment-compliance-check. Potvrdit.
2. Rozsah funkcionálního reportu: plný checklist (Met/Not met u každého criteria — cíl zadání) vs. redukovaná varianta (jen Goal met: Yes/No + gap list). Doporučení: plný checklist dle zadání; redukovaná varianta jako fallback, pokud content-pin churn naroste neúměrně.

[pekral]

Authors: @pekral

Summary of changes

Hotovo — co se změnilo a jak otestovat

Každý plnohodnotný CR skill (code-review, code-review-github, code-review-jira, code-review-bugsnag) nyní vrací dva jasně oddělené výstupy místo jednoho: technickou kontrolu kódu proti všem pravidlům projektu (beze změny chování, publikuje se na PR komentáři) a funkční kontrolu, která vždy zkontroluje, zda úpravy skutečně splňují zadání — plný checklist každého požadavku se stavem Splněno / Nesplněno / Částečně / Odchylně a jasný souhrnný verdikt "Goal met: Ano/Ne". Funkční kontrola se nově vypisuje na propojeném issue/JIRA i tehdy, když je vše v pořádku (dřív se při čistém stavu report úplně vynechával), a jednořádkový verdikt se navíc zrcadlí do řádku Summary na PR komentáři. api-review má odlehčenou variantu tohoto verdiktu vázanou na API kontrakt, a čtyři šablony výstupů (github/jira/bugsnag/base) mají tuto novou strukturu sjednocenou beze zbytku. Změna je čistě v prozaických/pravidlových souborech CR infrastruktury (rules/, skills/, testy) — nemění žádnou aplikační/produkční logiku.

How to test

1. Spusť code-review-github (nebo code-review-jira / code-review-bugsnag) na libovolném PR s propojeným issue nebo JIRA ticketem a zkontroluj, že PR komentář je rámovaný jako "Technical review" s odkazem na Functional review a že řádek Summary obsahuje assignment conformance: ….
2. Na propojeném issue/JIRA ticketu zkontroluj, že se objevil komentář z pr-summary s plným checklistem acceptance criteria (Met/Not met/Partial/Divergent) a explicitním Goal met: Yes/No verdiktem — a to i v případě, že je zadání splněno beze zbytku (afirmativní verdikt se už nevynechává).
3. Spusť samostatně api-review na PR, které mění API povrch, a zkontroluj řádek API contract matches assignment: Yes/No; při vnořeném volání uvnitř plného CR wrapperu ověř, že se tento řádek nevykresluje (aby nevznikl duplicitní funkční signál vedle plné Functional review).
4. Spusť composer build — musí projít zeleně (skill-check, phpcs, Pint, Rector, phpstan, composer audit, Pest test suite se 100% pokrytím) a skills/code-review/SKILL.md musí zůstat pod limitem 5000 slov.