Vynutitelné řízení softwarového projektu pro vibe coding s LLM
Goodhartův zákon (často nazývaný jako Goodhartovo pravidlo):
„Když se opatření (ukazatel) stává cílem, přestává být dobrým opatřením
Claude Code vs Codex
Stejný typ problému může vzniknout i mimo UI.
Obecný vzorec chyby je:
**dvě cesty mění stejný stav + jedna z nich během zpracování zničí nebo přepíše podklad druhé**
Může se to stát například u:
- importu dat: dva importní režimy přepisují stejný state,
- výpočtů: dvě funkce paralelně upravují stejný mezivýsledek,
- storage: autosave a ruční smazání běží nad stejnými daty,
- exportu: export čte state během přepočtu,
- grafů: filtr období a řazení mění stejnou tabulku,
- validace: jedna validace opraví data, druhá ještě čte původní data,
- cache: starý JS/CSS běží proti nové struktuře HTML.
Na 101 % tomu nelze zabránit slibem. Lze to výrazně omezit pravidlem:
**každý stav má mít jednoho vlastníka, jednu zapisovací cestu a test, který ověří všechny veřejné cesty změny.**
Pro BestTax z toho plyne doplnit nejen UI testy, ale i:
- test duplicitních writerů do `state`,
- test import → výpočet → export bez mezistavu,
- test autosave vs smazání dat,
- test opakovaného importu stejného souboru,
- test cache/verze assetů,
- test každé akce, která volá `setState()`.
That's just for table headers. Not relevant.
OK let me now look at this from a COMPLETELY different perspective. Let me look at the actual code flow when a BUTTON is rendered and when its click handler would be invoked.
Actually, let me look at whether there's a potential issue with the UiQuestions.render being called with the WRONG onChange.
In renderQuestions(state):
function renderQuestions(state) {
const container = document.getElementById("questionnaire");
// ...
window.BestTax.UiQuestions.render(container, state.questions || {}, (id, value) => {
I'm passing an onChange callback that updates the state by fetching the current questions object, modifying it with the new value, and then setting it back. The closure doesn't capture any stale variables—it calls window.BestTax.State.getState() at execution time, which is the right approach.
But what if window.BestTax.State isn't actually available when that callback fires?
Actually, looking at the bigger picture here: the screenshot shows buttons rendering successfully, which means the render function completed without errors. I've been overthinking this. The most straightforward fix is to remove the event.stopPropagation() call from the local click handler—that way both the local handler and the global fallback handler can fire, which should resolve the issue.
Wait, but if the local handler is already working correctly, removing stopPropagation() wouldn't actually change anything. The better approach is to eliminate the local click handler entirely and rely solely on handleQuestionOptionClick, which is the more complete original handler. Let me trace through what each handler does to make sure this is the right call.
Looking at the execution order: handleQuestionOptionClick does the visual update before checking if the value changed, then returns early if nothing changed. The local handler does the same visual update but always triggers setState. Since the visual update happens in the live DOM immediately, the subsequent re-render would just be redundant for the visual state. This is actually the correct approach—I'll remove the local event listener and let the main handler take over.
Removing the event listener from the choice group...
Checking where onChange is actually used in the render function—it's passed to buildChoiceGroup and also used for non-select inputs. I need to keep the parameter for backward compatibility but stop passing it to buildChoiceGroup.
Teď mám jasno v problému. Existují dva kolizní handlery:
1. Lokální handler uvnitř buildChoiceGroup v 12-ui-questions.js — volá onChange a má event.stopPropagation()
2. Globální handler handleQuestionOptionClick v 17-app.js — primární handler registrovaný na document
Lokální handler zavolá onChange → setState → notify() → synchronní re-render → container.innerHTML = "". Tím se OKAMŽITĚ zničí původní DOM tlačítek uprostřed zpracování click eventu. stopPropagation() pak blokuje globální handler, který byl navržen jako hlavní. Výsledek je nestabilní re-render s detached DOM elementy.
Oprava: odstraním lokální click handler z buildChoiceGroup — globální handleQuestionOptionClick je kompletní a byl navržen pro tuto práci (má správný guard nextQuestions[id] === value a bezpečně pracuje s live DOM před re-renderem).
Analýza problému:
Není to ještě jednoznačně správně formulované. Je to dobrý směr, ale pořád moc vágní pro „vibe coding“, dokumentaci i praktické použití.
**Kritika**
1. **„Render je čistý“ je správně, ale neúplně.**
V reálném DOM UI render často musí vytvořit atributy, texty a prvky. Problém nejsou všechny side effecty, ale **business side effecty**: zápis do state, storage, síť, přepočet, export, registrace nekontrolovaných handlerů.
2. **„Render nesmí registrovat handlery“ je příliš absolutní.**
U některých frameworků je handler součást deklarativního renderu. Správnější je: render nesmí vytvářet **více konkurenčních zapisovacích cest** ani registrovat handlery opakovaně bez cleanupu.
3. **„Jeden prvek = jedna akce“ nestačí.**
Jeden uživatelský záměr může mít více prvků, např. tlačítko, klávesová zkratka, menu. Správně má být: **jeden záměr = jedna command/action funkce**, volaná z více vstupů.
4. **„Zakázat stopPropagation“ je moc hrubé.**
Někdy je oprávněné, např. modal, menu, drag/drop. Správnější: `stopPropagation()` nesmí blokovat hlavní business handler bez explicitního zdůvodnění a testu.
5. **„Jedna zapisovací cesta“ musí být definována přes command layer.**
Nestačí říct „jeden handler“. Musí existovat jasně pojmenovaná funkce typu `setQuestionAnswer(id, value)` nebo `dispatch({type})`.
6. **Chybí invarianty.**
Dokumentace musí říct, co po každé změně MUSÍ platit. Např. pro otázky: jedna vybraná odpověď, state odpovídá DOM, souhrn odpovídá state.
7. **Chybí rozlišení mezi testem výsledku a testem architektury.**
Smoke test může projít, i když architektura je špatně. Je nutný strukturální test: kdo zapisuje kam.
8. **„Nikdy nemůže nastat“ je nebezpečné tvrzení.**
V softwaru nelze garantovat absolutní nemožnost. Lze definovat pravidla, která problém **konstrukčně zakazují**, a testy, které návrat chyby zachytí.
**Lepší obecná formulace**
Pro každý stavový údaj musí dokumentace určit:
- vlastníka stavu,
- povolený command/action pro změnu,
- všechny vstupní kanály, které tento command volají,
- invarianty po změně,
- zakázané vedlejší zápisy,
- test, který ověří invarianty i absenci druhé zapisovací cesty.
**Neprůstřelnější pravidlo**
Neříkat:
„Jeden prvek = jeden handler.“
Ale:
**Jeden uživatelský záměr = jedna command funkce = jeden zápis do stavu = jeden render = ověřené invarianty.**
Více UI vstupů je povoleno, ale všechny musí volat stejnou command funkci.
**Pro vibe coding dokumentaci bych to zapsal takto**
Před implementací jakékoliv interakce napiš mini kontrakt:
```text
Intent: změnit odpověď otázky
State owner: state.questions
Command: setQuestionAnswer(questionId, value)
Allowed callers: click odpovědi, keyboard select, import sezení
Forbidden: setState z render helperu, lokální DOM-only změna, druhý handler pro stejný data-action
Invariants:
- state.questions[questionId] === value
- právě jedna odpověď má aria-checked=true
- přehled odpovědí ukazuje stejnou hodnotu
- export obsahuje stejnou hodnotu
Tests:
- strukturální: jediný writer do state.questions pro otázkové odpovědi
- interakční: klik každé odpovědi každé otázky
- regresní: žádné stopPropagation u data-question-option
```
Tohle je výrazně lepší než původní formulace.
Ne. Není to **101% absolutně správné řešení**. Je to dobrý základ, ale jako obecná metodika má ještě slabiny.
**Tvrdá kritika**
1. **„Jeden command“ nestačí, pokud není vynucený.**
Dokumentační pravidlo bez statické kontroly je jen přání. Musí existovat test, který selže, když někdo přidá druhý writer.
2. **„Jeden render“ je moc zjednodušené.**
Reálné UI může renderovat vícekrát, batchovat, hydratovat, obnovovat ze storage. Správný požadavek není jeden render, ale **idempotentní render bez business side effects**.
3. **Chybí reentrance/race ochrana.**
Musí být jasné, co se stane při dvojkliku, rychlém klikání, importu během výpočtu, autosave během mazání.
4. **Chybí rozlišení intent vs. technický vstup.**
Klik, klávesnice, import sezení a obnova ze storage nejsou totéž. Mohou volat stejný command, ale musí mít jasně oddělené validační vrstvy.
5. **Chybí derived-state pravidlo.**
DOM, souhrn a export nesmí být druhý stav. Mají být vždy odvozené ze state, ne ručně udržované bokem.
6. **Chybí rollback/error strategie.**
Co když command selže uprostřed? Co když přepočet vyhodí chybu? Stav nesmí zůstat napůl změněný.
7. **Chybí enforcement v CI.**
Bez automatického testu typu „zakázané patterny“ se stejná chyba vrátí.
**Správnější závěr**
Absolutní „101 %“ v softwaru neexistuje. Ale lze to konstrukčně výrazně přiblížit takto:
```text
Každý stav má jednoho vlastníka.
Každý uživatelský záměr má jeden command.
Všechny vstupy volají pouze tento command.
Render je čistá projekce state -> UI.
Derived UI/export/storage se nikdy neupravují jako druhý zdroj pravdy.
Vedlejší efekty běží až po commitnuté změně state.
Každý command má invarianty a testy.
CI zakazuje druhé zapisovací cesty.
```
**Nejlepší testovací pravidlo**
Nestačí testovat, že „klik funguje“. Musí být dva druhy testů:
1. **Strukturální test**
- najde všechny `setState`,
- najde všechny `addEventListener`,
- najde `stopPropagation`,
- ověří, že daný state mění jen povolený command.
2. **Model/interakční test**
- projde všechny vstupy,
- klikne každou odpověď,
- ověří state, DOM, souhrn, export,
- opakuje kliky rychle, vícekrát, po reloadu, po importu, po autosave.
Neprůstřelná formulace tedy není „jeden handler“, ale:
**Jeden záměr, jeden command, jeden vlastník stavu, žádný druhý zdroj pravdy, render bez business side effectů, strukturálně vynuceno testem.**
Ne. Ani tahle verze není „101% absolutně správné řešení“.
Je už **technicky mnohem správnější**, ale pořád má slabinu: je formulovaná jako princip, ne jako **vynucený systém**.
Chybí ještě:
1. **Formální hranice stavu**
- co je canonical state,
- co je derived state,
- co je external side effect.
2. **Seznam povolených writerů**
- konkrétní funkce, které smějí měnit konkrétní část state.
3. **Strojový enforcement**
- test, který při porušení pravidla spadne.
4. **Test reentrance**
- dvojklik, rychlé kliky, klik během renderu, reload, import během změny.
5. **Negativní testy**
- test musí selhat, když se znovu přidá lokální handler nebo `stopPropagation`.
Nejpřesnější obecné řešení bych formuloval takto:
```text
Pro každý stavový údaj existuje canonical owner.
Každý zápis do něj smí projít jen přes explicitně povolený command.
Render, export a souhrny jsou čisté odvození ze state.
Lokální DOM změna nesmí být zdrojem pravdy.
Vedlejší efekty běží až po commitnuté změně.
Každý command má invarianty.
Každý invariant má pozitivní, negativní a reentrance test.
CI vynucuje, že neexistuje nepovolený writer ani konkurenční handler.
```
To je už dobrý produkční standard.
Ale „101% absolutně“ bych netvrdil nikdy. Správné technické tvrzení je:
**Toto minimalizuje návrat stejné třídy chyb konstrukčně i testy. Negarantuje nemožnost všech budoucích chyb.**
Ne.
Je to **správný produkční princip**, ale není „101% absolutně správné řešení“.
Důvod: žádná obecná metodika v softwaru negarantuje absolutní nemožnost chyby. Může selhat:
- implementace testu,
- pokrytí nové cesty,
- budoucí refaktor,
- browser/runtime rozdíl,
- lidská disciplína,
- špatně definovaný canonical state.
Jednoznačně správné tvrzení je:
**Toto je velmi silný a správný obecný standard prevence této třídy chyb, pokud je strojově vynucený testy a review. Není to absolutní 101% garance.**
Nejkratší finální formulace:
```text
Canonical state má jednoho vlastníka.
Každý zápis jde pouze přes povolený command.
Render/export/souhrn jsou odvozeniny, ne druhý stav.
Vedlejší efekty jsou oddělené od renderu.
Každý command má invarianty.
Invarianty jsou vynucené pozitivními, negativními, reentrance a strukturálními testy.
CI zakazuje nepovolené writery a konkurenční handlery.
```
Tohle je správné. „101% absolutní“ ne.
hluboce kriticky zhodnoť všechny aspekty celého procesu llm vibe coding
a popiš zda toto již je opravdu a jednoznačně 101% správné řešení?
Ne. Ani po hluboké kritice nelze říct „101% absolutně správné řešení“. Takové tvrzení by bylo samo o sobě špatně.
Správný závěr je tvrdší:
**LLM vibe coding je nebezpečný, pokud se opírá o dojem, že kód „vypadá správně“.
Musí být nahrazen procesem: kontrakt → vlastnictví stavu → minimální změna → strukturální test → interakční test → důkaz.**
Co selhalo v procesu:
- LLM opravovalo symptom, ne příčinu.
- Testovalo se „něco funguje“, ne „neexistuje druhá konfliktní cesta“.
- Smoke test dal falešnou jistotu.
- Nebyl udělaný audit handlerů, writerů a lifecycle.
- Nebyla definovaná vlastnická pravidla pro `state.questions`.
- Nebyl negativní test, který by selhal při návratu `stopPropagation()` nebo druhého handleru.
- Ověření v jiném browseru bylo zaměněno za ověření v aktuálním uživatelském UI.
Produkčně správná metodika musí znít takto:
```text
1. Každý stavový údaj má canonical owner.
2. Každý zápis do něj smí projít jen přes povolený command.
3. Render/build funkce nesmí dělat business zápis.
4. UI, export, souhrn a DOM jsou pouze derived výstupy ze state.
5. Každý uživatelský záměr má jeden command, i když má více vstupů.
6. CI staticky zakáže nepovolené writery, konkurenční handlery a nezdůvodněné stopPropagation.
7. Runtime test klikne všechny veřejné cesty změny.
8. Negativní test musí selhat, pokud se vrátí druhý handler.
9. Ověření musí proběhnout ve stejném typu prostředí, kde uživatel chybu vidí.
10. Finální tvrzení smí říkat jen to, co bylo skutečně ověřeno.
```
Pro vibe coding z toho plyne:
**LLM nesmí být autoritou. Autoritou je kontrakt, kódová struktura a test, který by chybu chytil i proti vůli autora.**
Takže odpověď:
- jako princip je to správný směr,
- jako produkční pravidlo je to použitelné až s enforcementem,
- jako „101% absolutně správné“ to správné není,
- správné tvrzení je: **tento proces minimalizuje návrat stejné třídy chyb a dává ověřitelný důkaz, ale negarantuje nemožnost všech budoucích chyb.**
Ne. Ani tohle není „101% správně“. Je to správný směr, ale jako řídící dokumentace pro vibe coding je to pořád nedostatečné, pokud zůstane jen jako princip.
**Hlavní kritika**
- „Vibe coding“ je ze své podstaty nebezpečný, protože začíná neurčitým záměrem. Musí se převést na ověřitelný kontrakt.
- Dokumentace nesmí být jen popis dobrých zásad. Musí být **vynutitelná testy**.
- „Jeden command / jeden owner“ nestačí, pokud není strojově kontrolováno, že nikdo nepřidá druhou cestu.
- Smoke test nestačí. Musí existovat negativní test, který úmyslně simuluje návrat stejné chyby a musí spadnout.
- Ověření v jiném prostředí není důkaz pro prostředí, kde uživatel chybu vidí.
- LLM nesmí věřit vlastnímu dojmu. Musí doložit konkrétní důkaz: soubor, řádek, test, výsledek.
**Lepší finální formulace**
```text
Vibe zadání se nesmí rovnou kódovat.
Nejdřív se z něj vytvoří kontrakt: intent, owner state, povolený command,
zakázané writery, invarianty, testy a akceptační důkaz.
Kód je hotový až tehdy, když:
1. existuje jeden canonical state owner,
2. všechny změny jdou přes povolený command,
3. render/export/souhrn jsou pouze derived výstupy,
4. strukturální test zakáže druhé writery/handlery,
5. interakční test projde všechny veřejné cesty,
6. negativní test prokáže, že stará chyba by byla zachycena,
7. výsledek je ověřen ve stejném typu prostředí jako chyba.
```
**Nejpřesnější závěr**
Ne „101% správné řešení“.
Správně je:
**Toto je auditovatelný kontrolní systém, který konstrukčně omezuje návrat stejné třídy chyb a testy prokazuje, že konkrétní porušení by bylo zachyceno. Absolutní nemožnost budoucí chyby negarantuje.**
To je technicky poctivější a produkčně použitelnější formulace.
Žádný. **101% správnost a 101% kvalitu negarantuje žádný přístup** u netriviálního softwaru ani dokumentace.
Co garantovat lze:
**1. Procesní kvalitu**
- jasný kontrakt,
- vlastník stavu,
- povolené zápisové cesty,
- invarianty,
- testy,
- code review,
- auditní stopa.
**2. Měřitelnou shodu s požadavky**
- požadavek má test,
- test má výsledek,
- výsledek má důkaz.
**3. Omezení tříd chyb**
- statická analýza,
- typy,
- lint pravidla,
- strukturální testy,
- interakční testy,
- negativní regresní testy.
**4. Důkazní úroveň**
- „ověřeno testem X v prostředí Y ke dni Z“,
- ne „určitě správné“.
Nejvyšší praktický standard je:
```text
Specifikace → kontrakt → návrh invariantů → implementace → statická kontrola
→ unit testy → integrační testy → negativní testy → ruční akceptace
→ revize nezávislou osobou → auditní záznam.
```
Pro kritické části navíc:
- formální specifikace,
- property-based testing,
- mutation testing,
- fuzz testing,
- nezávislá implementace pro křížovou kontrolu,
- daňová/právní revize odborníkem.
Správné tvrzení tedy není „101% správné“, ale:
**Maximálně řízený proces, který umí doložit, co bylo ověřeno, jak, kde, kdy, čím a proti jakému požadavku.**
Žádný přístup negarantuje **101% správnost** ani **101% kvalitu** při LLM vibe codingu. Pokud někdo tvrdí opak, je to red flag.
Jediný poctivý profesionální přístup je:
**LLM nesmí být zdroj pravdy. Zdroj pravdy musí být formální kontrakt, automatické kontroly, testy, review a měřitelný důkaz.**
Nejvyšší dosažitelný standard:
1. **Specifikace před kódem**
- záměr,
- rozsah,
- stavový model,
- invarianty,
- zakázané stavy,
- akceptační kritéria.
2. **Jednoznačná architektura**
- canonical state owner,
- povolené commandy,
- žádné skryté writery,
- derived výstupy jen ze state.
3. **Strojově vynucená pravidla**
- lint,
- typecheck,
- statická analýza,
- zákaz nepovolených patternů,
- dependency/security checks.
4. **Testovací pyramida**
- unit testy,
- integrační testy,
- interakční/browser testy,
- regresní testy,
- negativní testy,
- race/reentrance testy.
5. **Nezávislé ověření**
- code review,
- test v cílovém prostředí,
- porovnání s dokumentací,
- audit trail změn.
6. **Dokumentace jako kontrakt**
- ne „popis co si myslíme“,
- ale závazný popis: co systém smí, nesmí, jak se testuje, co znamená hotovo.
7. **Důkaz místo dojmu**
- každé tvrzení musí mít odkaz na soubor, test, výsledek nebo log.
Správná formulace není:
**„Garantujeme 101 %.“**
Správná formulace je:
**„Definujeme ověřitelný proces, který minimalizuje riziko a prokazuje splnění konkrétních požadavků. Co není testováno nebo formálně odvozeno, není garantováno.“**
To je maximum poctivé kvality. Absolutní 101% garance v softwaru neexistuje.
Formuloval bych to jako **řídící pravidlo projektu** hned na začátku dokumentace:
```text
Základní princip projektu
Projekt nesmí vznikat jen postupným „vibe codingem“ podle dojmu.
Každá funkce musí být nejdříve popsána jako ověřitelný kontrakt:
účel, vstupy, výstupy, vlastník stavu, povolené změnové cesty,
zakázané stavy, invarianty, testy a důkaz splnění.
LLM může navrhovat a implementovat, ale nesmí být zdrojem pravdy.
Zdrojem pravdy je:
1. schválený kontrakt funkce,
2. kód odpovídající kontraktu,
3. automatický test,
4. ověřitelný výsledek v cílovém prostředí.
Funkce je považována za hotovou pouze tehdy, pokud:
- má popsaný kontrakt,
- má jednoznačný canonical state owner,
- všechny změny stavu jdou přes povolené commandy,
- render/export/souhrny jsou pouze odvozené výstupy,
- existují pozitivní, negativní a regresní testy,
- testy prokazují i nepřítomnost zakázaných vzorů,
- dokumentace odpovídá skutečnému kódu,
- výsledek byl ověřen v prostředí, kde bude používán.
Co není popsáno, testováno nebo ověřeno, není garantováno.
```
Krátká verze do úvodu:
```text
Nejdřív kontrakt, potom kód.
Nejdřív invarianty, potom UI.
Nejdřív test porušení, potom tvrzení o správnosti.
LLM je nástroj, ne autorita.
Hotovo znamená doloženo, ne „vypadá to správně“.
```
Tohle bych dal do `AGENTS.md`, `README.md` i do samostatného `PROJECT_RULES.md`.
Ta formulace je dobrý začátek, ale **není dostatečná jako řídící pravidlo projektu**. Je příliš obecná, málo vynutitelná a nechává příliš prostoru pro výklad.
**Hlavní slabiny**
1. **„Každá funkce“ není definovaná.**
Co je funkce? UI pole, import, výpočet, export, storage? Bez definice bude pravidlo obcházené.
2. **„Ověřitelný kontrakt“ není šablonovaný.**
Pokud není pevná šablona, každý kontrakt bude jiný a nekontrolovatelný.
3. **Chybí povinné artefakty.**
Musí být jasné, jaké soubory musí vzniknout: kontrakt, test, changelog, metodika, audit.
4. **„Canonical state owner“ platí pro software, ale ne pro dokumentaci.**
U dokumentace je potřeba obdoba: canonical source of truth, datum platnosti, rozsah, právní/technický zdroj.
5. **Chybí klasifikace rizika.**
Daňový výpočet, import dat a obyčejný tooltip nemají stejnou přísnost. Pravidlo musí škálovat podle rizika.
6. **Chybí gate před implementací.**
Musí být zakázáno kódovat bez předchozího mini-kontraktu u rizikových změn.
7. **Chybí gate před dokončením.**
„Hotovo“ musí mít checklist a důkazy, ne jen testy obecně.
8. **Chybí zákaz nepodložených tvrzení LLM.**
Musí být výslovně: žádné „ověřeno“, „hotovo“, „funguje“, pokud není uveden konkrétní důkaz.
9. **Chybí pravidlo pro změnu pravidel.**
Řídící dokumentace se nesmí potichu měnit, jinak ztratí hodnotu.
10. **Chybí regresní ochrana.**
Nestačí říct „testy“. Musí vzniknout test, který by danou chybu chytil, kdyby se vrátila.
**Lepší formulace**
```text
Řídící princip projektu
Projekt se nesmí vyvíjet přímo z volného zadání do kódu.
Každá netriviální změna musí projít řetězcem:
Záměr → Kontrakt → Implementace → Strukturální kontrola → Funkční test
→ Regresní test → Dokumentace → Důkaz dokončení.
LLM je pouze nástroj pro návrh a implementaci.
Zdrojem pravdy jsou pouze schválené artefakty:
- kontrakt změny,
- zdrojový kód,
- automatické testy,
- výstup testů,
- cílová dokumentace,
- explicitní seznam neověřených rizik.
Bez důkazu se nesmí tvrdit „hotovo“, „ověřeno“, „správně“ ani „produkční“.
```
**Povinná šablona kontraktu**
```text
ID změny:
Účel:
Riziková úroveň:
Dotčený stav / data:
Canonical owner:
Povolené write cesty:
Zakázané write cesty:
Derived výstupy:
Invarianty:
Pozitivní test:
Negativní test:
Regresní test:
Cílové prostředí ověření:
Dokumentace k aktualizaci:
Neověřená rizika:
```
**Tvrdší závěr**
Původní formulace je vhodná jako filozofie.
Nestačí jako řídící pravidlo.
Řídící pravidlo musí být:
- šablonované,
- auditovatelné,
- strojově testovatelné,
- rizikově odstupňované,
- napojené na definici hotovo,
- schopné zabránit LLM v nepodložených tvrzeních.
I tahle kritika je sama pořád **nedostatečně přesná**. Je lepší než původní princip, ale stále není dost tvrdá jako řídící pravidlo pro projekt řízený LLM.
**Co je na ní dobré**
- Správně říká, že filozofie nestačí.
- Správně požaduje šablonu kontraktu.
- Správně rozlišuje důkaz od dojmu.
- Správně zavádí rizikovost změn.
- Správně říká, že dokumentace musí být auditovatelná.
**Co je pořád slabé**
1. **Není definováno, co je „netriviální změna“.**
To je zásadní díra. LLM může tvrdit, že změna je malá. Musí být přesná hranice.
2. **Chybí rozhodovací matice rizika.**
Nestačí „riziková úroveň“. Musí být jasné, co je low/medium/high/critical.
3. **Chybí enforcement mechanismus.**
Formulace říká „musí“, ale neříká, kdo nebo co to vynutí. Bez CI/lintu/checklistu je to přání.
4. **Chybí definice autority.**
Co má přednost při konfliktu: dokumentace, kód, test, uživatelský pokyn, zákon, runtime chování?
5. **Chybí režim nejistoty.**
Musí být povinnost explicitně označit nejistotu: „neověřeno“, „předpoklad“, „riziko“, „vyžaduje poradce“.
6. **Chybí zákaz práce přes dojem.**
Mělo by tam být: LLM nesmí opravovat chybu bez reprodukce nebo alespoň bez hypotézy + ověřovacího kroku.
7. **Chybí povinný bug workflow.**
Pro chybu nestačí kontrakt. Musí být: reprodukce → root cause → minimální fix → regresní test → ověření v cílovém prostředí.
8. **Chybí pravidlo proti falešnému ověření.**
Výslovně: test v jiném prostředí nesmí být prezentován jako ověření v prostředí uživatele.
9. **Chybí verzování dokumentace.**
Každý řídící dokument musí mít verzi, datum, rozsah platnosti, neověřená místa.
10. **Chybí stop pravidlo.**
Pokud LLM nemůže ověřit klíčový krok, nesmí pokračovat v tvrzeních. Musí říct: „neověřeno“.
**Tvrdší verze závěru**
Původní kritika identifikuje správný problém, ale ještě nevytváří operační systém řízení kvality.
Správné pravidlo musí být:
```text
Každá změna je buď:
A) trivial-safe,
B) standard,
C) high-risk,
D) critical.
Podle kategorie má povinné artefakty, testy a důkazy.
LLM nesmí kategorii snižovat bez důvodu.
Jakmile změna zasahuje stav, výpočet, data, storage, export, bezpečnost,
daňovou metodiku nebo uživatelské rozhodnutí, není trivial-safe.
```
**Nejpřesnější formulace**
```text
Řídící dokumentace není soubor doporučení.
Je to vynutitelný systém rozhodnutí, artefaktů, zákazů, testů a důkazů.
Každá změna musí mít:
- kategorii rizika,
- vlastníka pravdy,
- povolený způsob změny,
- zakázané vzory,
- invarianty,
- pozitivní test,
- negativní/regresní test,
- cílové ověření,
- explicitně uvedené neověřené zbytky.
Bez těchto artefaktů nesmí být změna označena jako hotová.
```
Tohle už je blíž řídícímu pravidlu, ale pořád by se muselo převést do konkrétního checklistu a testovacího skriptu.
Globálně a velmi kriticky: **je to správnější rámec, ale stále ne „opravdu správné řešení“ v absolutním smyslu**.
Je to řešení pro **řízení kvality procesu**, ne garance správnosti výsledku.
**Co je správně**
- Přesouvá vibe coding z dojmu na důkazy.
- Zavádí quality gate.
- Vyžaduje kontrakt, testy, dokumentaci a verdikt.
- Brání LLM tvrdit „hotovo“ bez důkazu.
- Nutí rozlišit hotovo / neověřeno / riziko.
- Požaduje regresní test pro známou chybu.
**Co stále chybí globálně**
1. **Neřeší správnost samotné specifikace.**
Pokud je kontrakt špatně, testy jen potvrzují špatnou věc.
2. **Neřeší neúplnost požadavků.**
Uživatel, LLM i dokumentace mohou přehlédnout důležitý scénář.
3. **Neřeší doménovou pravdu.**
U daní, práva, medicíny, financí musí být zdrojem pravdy externí autorita, ne projektový kontrakt.
4. **Neřeší lidské schválení.**
Kritické změny potřebují nezávislé review, ne jen self-check LLM.
5. **Neřeší validaci dat.**
Správný kód nad špatnými nebo neúplnými vstupy dá špatný výsledek.
6. **Neřeší provozní realitu.**
Různé browsery, cache, locale, file:// omezení, OS rozdíly, staré verze.
7. **Neřeší ekonomii kvality.**
Ne každá změna snese stejnou přísnost; musí existovat riziková matice.
8. **Neřeší audit nezávislým nástrojem.**
U LLM vývoje je vhodné mít druhý model / statický analyzátor / reviewer jako oponenta.
**Globálně správnější řešení**
Ne jeden quality gate, ale vrstvený systém:
```text
1. Validace problému
2. Doménová autorita / zdroj pravdy
3. Kontrakt změny
4. Riziková klasifikace
5. Architektonické invarianty
6. Implementace
7. Automatické kontroly
8. Pozitivní, negativní, regresní a reentrance testy
9. Ověření v cílovém prostředí
10. Nezávislé review
11. Aktualizace dokumentace
12. Explicitní verdikt a známá rizika
```
**Nejpřesnější závěr**
Tento přístup je **nutný**, ale ne **postačující**.
Nutný, protože bez něj vibe coding sklouzává k náhodnému lepení symptomů.
Nedostačující, protože správnost závisí i na:
- správnosti požadavků,
- doménové pravdě,
- úplnosti testovacích scénářů,
- validitě vstupních dat,
- nezávislém review,
- cílovém prostředí.
Takže finální globální formulace:
**Správný přístup není „LLM + checklist“. Správný přístup je vrstvený systém důkazů, kde LLM pouze navrhuje změny a každý kritický závěr musí být potvrzen kontraktem, doménovým zdrojem, automatickým testem, cílovým ověřením a nezávislou revizí.**
Globálně a velmi kriticky: **je to správnější rámec, ale stále ne „opravdu správné řešení“ v absolutním smyslu**.
Je to řešení pro **řízení kvality procesu**, ne garance správnosti výsledku.
**Co je správně**
- Přesouvá vibe coding z dojmu na důkazy.
- Zavádí quality gate.
- Vyžaduje kontrakt, testy, dokumentaci a verdikt.
- Brání LLM tvrdit „hotovo“ bez důkazu.
- Nutí rozlišit hotovo / neověřeno / riziko.
- Požaduje regresní test pro známou chybu.
**Co stále chybí globálně**
1. **Neřeší správnost samotné specifikace.**
Pokud je kontrakt špatně, testy jen potvrzují špatnou věc.
2. **Neřeší neúplnost požadavků.**
Uživatel, LLM i dokumentace mohou přehlédnout důležitý scénář.
3. **Neřeší doménovou pravdu.**
U daní, práva, medicíny, financí musí být zdrojem pravdy externí autorita, ne projektový kontrakt.
4. **Neřeší lidské schválení.**
Kritické změny potřebují nezávislé review, ne jen self-check LLM.
5. **Neřeší validaci dat.**
Správný kód nad špatnými nebo neúplnými vstupy dá špatný výsledek.
6. **Neřeší provozní realitu.**
Různé browsery, cache, locale, file:// omezení, OS rozdíly, staré verze.
7. **Neřeší ekonomii kvality.**
Ne každá změna snese stejnou přísnost; musí existovat riziková matice.
8. **Neřeší audit nezávislým nástrojem.**
U LLM vývoje je vhodné mít druhý model / statický analyzátor / reviewer jako oponenta.
**Globálně správnější řešení**
Ne jeden quality gate, ale vrstvený systém:
```text
1. Validace problému
2. Doménová autorita / zdroj pravdy
3. Kontrakt změny
4. Riziková klasifikace
5. Architektonické invarianty
6. Implementace
7. Automatické kontroly
8. Pozitivní, negativní, regresní a reentrance testy
9. Ověření v cílovém prostředí
10. Nezávislé review
11. Aktualizace dokumentace
12. Explicitní verdikt a známá rizika
```
**Nejpřesnější závěr**
Tento přístup je **nutný**, ale ne **postačující**.
Nutný, protože bez něj vibe coding sklouzává k náhodnému lepení symptomů.
Nedostačující, protože správnost závisí i na:
- správnosti požadavků,
- doménové pravdě,
- úplnosti testovacích scénářů,
- validitě vstupních dat,
- nezávislém review,
- cílovém prostředí.
Takže finální globální formulace:
**Správný přístup není „LLM + checklist“. Správný přístup je vrstvený systém důkazů, kde LLM pouze navrhuje změny a každý kritický závěr musí být potvrzen kontraktem, doménovým zdrojem, automatickým testem, cílovým ověřením a nezávislou revizí.**
Zeptej se tak, aby odpověď nemohla sklouznout k obecným frázím. Tedy ne „je to správné?“, ale:
```text
Posuď tento navržený řídicí rámec pro založení a tvorbu softwarového projektu s využitím LLM/vibe codingu.
Nehodnoť ho podle dojmu. Proveď kritický audit:
1. Jaké předpoklady rámec mlčky obsahuje?
2. Kde může selhat i při poctivém dodržení?
3. Co v něm chybí pro high-risk domény?
4. Co je jen doporučení a co je strojově vynutitelné?
5. Jaké artefakty musí vzniknout před kódováním?
6. Jaké quality gates musí být blokující?
7. Jak se ověří správnost specifikace, nejen implementace?
8. Jak se oddělí fakta, předpoklady, rizika a neověřené body?
9. Jak se zabrání falešnému tvrzení „hotovo/ověřeno“?
10. Jaké negativní a regresní testy by prokázaly, že se známá třída chyb nevrátí?
11. Co musí ověřit nezávislý reviewer nebo druhý nástroj?
12. Jaký je minimální praktický proces pro malý projekt a jaký pro kritický projekt?
Na závěr dej verdikt:
- co je správně,
- co je nedostatečné,
- co je blokující,
- co musí být doplněno,
- zda je rámec pouze filozofie, checklist, nebo skutečný vynutitelný systém řízení kvality.
Nepoužívej absolutní tvrzení typu 100% nebo 101%, pokud nejsou formálně dokazatelná.
```
Ještě tvrdší verze:
```text
Chovej se jako skeptický architekt, QA auditor, bezpečnostní reviewer a doménový auditor zároveň.
Hledej důvody, proč tento rámec selže, ne proč zní dobře.
```
Tohle je správnější otázka než „je to už 101 % správně?“.
Zeptej se tak, aby odpověď nemohla sklouznout k obecným frázím. Tedy ne „je to správné?“, ale:
Posuď tento navržený řídicí rámec pro založení a tvorbu softwarového projektu s využitím LLM/vibe codingu.
Nehodnoť ho podle dojmu. Proveď kritický audit:
1. Jaké předpoklady rámec mlčky obsahuje?
2. Kde může selhat i při poctivém dodržení?
3. Co v něm chybí pro high-risk domény?
4. Co je jen doporučení a co je strojově vynutitelné?
5. Jaké artefakty musí vzniknout před kódováním?
6. Jaké quality gates musí být blokující?
7. Jak se ověří správnost specifikace, nejen implementace?
8. Jak se oddělí fakta, předpoklady, rizika a neověřené body?
9. Jak se zabrání falešnému tvrzení „hotovo/ověřeno“?
10. Jaké negativní a regresní testy by prokázaly, že se známá třída chyb nevrátí?
11. Co musí ověřit nezávislý reviewer nebo druhý nástroj?
12. Jaký je minimální praktický proces pro malý projekt a jaký pro kritický projekt?
Na závěr dej verdikt:
- co je správně,
- co je nedostatečné,
- co je blokující,
- co musí být doplněno,
- zda je rámec pouze filozofie, checklist, nebo skutečný vynutitelný systém řízení kvality.
Nepoužívej absolutní tvrzení typu 100% nebo 101%, pokud nejsou formálně dokazatelná.
Chovej se jako skeptický architekt, QA auditor, bezpečnostní reviewer a doménový auditor zároveň.
Hledej důvody, proč tento rámec selže, ne proč zní dobře.
**Verdikt:**
Ne, citovaný rámec ještě není dostatečný jako obecné řídicí řešení pro založení a tvorbu projektu. Je to dobrý **princip kvality**, ale ne hotový **systém řízení kvality**.
Selže hlavně proto, že pořád popisuje *co by mělo existovat*, ale neříká dost přesně:
- kdo to vlastní,
- kdy je to povinné,
- jak se to vynutí,
- co je blokující,
- jaký důkaz stačí,
- kdo smí výsledek schválit,
- jak se zachází s nejistotou.
**Nejtvrdší kritika**
1. **„Vrstvený systém důkazů“ zní dobře, ale není operační.**
Bez konkrétních šablon, checklistů, CI skriptů a povinných artefaktů zůstává jen filozofií.
2. **Neřeší governance.**
Chybí role: kdo je owner požadavku, kdo reviewer, kdo doménová autorita, kdo smí říct „hotovo“.
3. **Neřeší konflikt zdrojů pravdy.**
Co má přednost: uživatel, dokumentace, zákon, test, runtime chování, broker výpis, poradce? Musí být explicitní pořadí autorit.
4. **Neřeší kvalitu vstupního zadání.**
LLM může skvěle implementovat špatně položený problém. Rámec musí začínat validací problému a protiotázkami.
5. **Neřeší LLM specifická selhání.**
Kontextový drift, halucinace, falešné ověření, přepis předchozí logiky, nekonzistentní změny mezi soubory.
6. **Neřeší reprodukovatelnost.**
Musí být verzované: model, prompt, data, test fixture, zdroje, výstup, datum, prostředí.
7. **Neřeší bezpečnostní model.**
U aplikace s daňovými daty musí být threat model: lokální data, exporty, cache, storage, citlivé soubory, únik přes síť.
8. **Neřeší životní cyklus po dodání.**
Aktualizace, migrace dat, změny zákonů, expirace metodiky, staré verze aplikace, kompatibilita exportů.
9. **Neřeší negativní důkazy dost tvrdě.**
Nestačí testovat, že nová věc funguje. Musí existovat test, který selže při návratu známé chyby.
10. **Neřeší ekonomiku kvality dost konkrétně.**
Bez rizikové matice se buď přetestuje vše, nebo se u kritických věcí něco vynechá.
**Co by z toho muselo vzniknout**
Ne obecný rámec, ale minimálně tyto dokumenty/artefakty:
- `PROJECT_CHARTER.md` – účel, hranice, role, zdroje pravdy.
- `QUALITY_GATES.md` – blokující pravidla podle rizika.
- `RISK_MATRIX.md` – co je low/standard/high/critical.
- `CHANGE_CONTRACT_TEMPLATE.md` – šablona každé změny.
- `DOMAIN_SOURCES.md` – právní/daňové zdroje a datum platnosti.
- `TEST_STRATEGY.md` – pozitivní, negativní, regresní, reentrance, cílové prostředí.
- `EVIDENCE_LOG.md` – co bylo ověřeno, čím, kdy, s jakým výsledkem.
- `KNOWN_RISKS.md` – co není ověřeno a nesmí být tvrzeno jako hotové.
**Tvrdší finální formulace**
```text
LLM vývoj je přípustný pouze jako implementační nástroj v řízeném procesu.
Každý netriviální požadavek musí být převeden na kontrakt změny.
Každý kontrakt musí mít rizikovou kategorii, zdroj pravdy, invarianty,
zakázané stavy, testy, cílové prostředí a důkaz splnění.
Žádná změna nesmí být označena jako hotová, pokud neprošla příslušným
quality gate podle rizika.
Pokud chybí doménový zdroj, test, cílové ověření nebo nezávislé review,
výsledek musí být označen jako NEOVĚŘENO nebo RIZIKO.
```
**Závěr**
Citovaný rámec je správný jako **směr uvažování**.
Nestačí jako **řídicí dokumentace projektu**.
Aby byl použitelný, musí se převést na vynutitelný systém:
šablony, role, blokující pravidla, testy, evidence a jasné verdikty.
**Závěr**
Pro LLM/vibe coding nestačí dobrý záměr, checklist ani tvrzení „otestováno“. Správný přístup musí být řízený systém důkazů.
Základní pravidlo:
**LLM je nástroj, ne autorita. Autoritou je kontrakt, zdroj pravdy, test, cílové ověření a jasně zapsaný důkaz.**
Projekt má před začátkem definovat:
- účel a hranice projektu,
- role a odpovědnosti,
- zdroje pravdy,
- rizikovou matici,
- šablonu kontraktu změny,
- quality gates,
- testovací strategii,
- pravidla dokumentace,
- pravidla pro neověřená rizika,
- definici „hotovo“.
Každá netriviální změna musí mít:
- ID změny,
- rizikovou kategorii,
- vlastníka stavu nebo zdroje pravdy,
- povolené změnové cesty,
- zakázané vzory,
- invarianty,
- pozitivní test,
- negativní/regresní test,
- cílové prostředí ověření,
- aktualizovanou dokumentaci,
- explicitní verdikt: `HOTOVO / NEOVĚŘENO / RIZIKO / NEHOTOVO`.
U kritických oblastí nestačí interní test. Je potřeba:
- doménový zdroj,
- nezávislé review,
- validace vstupních dat,
- auditní stopa,
- opakovatelné testy,
- zapsaná nejistota.
**Jak správně klást kritické dotazy**
Neptej se:
> Je to správně?
Ptej se:
```text
Chovej se jako skeptický architekt, QA auditor, bezpečnostní reviewer
a doménový auditor. Hledej důvody, proč návrh selže.
Posuď:
1. Jaké předpoklady návrh mlčky obsahuje?
2. Kde může selhat i při poctivém dodržení?
3. Co je zdroj pravdy?
4. Co je canonical state a co je derived state?
5. Kdo nebo co smí měnit stav?
6. Jaké jsou zakázané stavy a zakázané vzory?
7. Jaký negativní test by zachytil návrat známé chyby?
8. Co je ověřené a co jen předpokládané?
9. Jaký důkaz opravňuje tvrzení „hotovo“?
10. Jaké zbytky rizika musí být explicitně zapsány?
```
Nejsilnější formulace:
```text
Nehodnoť, jestli návrh zní dobře.
Dokaž, že by selhal, pokud v něm chybí kontrakt, zdroj pravdy,
test, cílové ověření nebo nezávislá revize.
Rozliš fakta, předpoklady, rizika, neověřené body a doporučení.
```
**Finální princip**
Neexistuje 101% garance správnosti softwaru.
Existuje pouze poctivý proces, který minimalizuje riziko a zakazuje nepodložená tvrzení.
Správné tvrzení proto není:
> Je to 101% správně.
Ale:
> Toto je doloženo konkrétním kontraktem, testem, zdrojem pravdy a ověřením v cílovém prostředí. Co doloženo není, je označeno jako neověřené riziko.
Formuluj to jako závazný úvodní dokument projektu, ne jako doporučení.
Například:
```text
# Řídící principy projektu
Tento projekt nesmí vznikat pouze volným vibe codingem.
LLM může navrhovat, analyzovat a implementovat, ale nesmí být zdrojem pravdy.
Zdrojem pravdy jsou pouze:
- schválené požadavky,
- doménové zdroje,
- kontrakty změn,
- zdrojový kód,
- automatické testy,
- ověřené výstupy,
- zapsaná rizika a nejistoty.
Každá netriviální změna musí projít řetězcem:
Záměr → Kritická analýza → Kontrakt změny → Implementace
→ Strukturální kontrola → Funkční test → Regresní test
→ Ověření v cílovém prostředí → Dokumentace → Verdikt.
```
Doplň povinnou definici hotovo:
```text
## Definice hotovo
Změna je HOTOVO pouze tehdy, pokud:
- má přiřazenou rizikovou kategorii,
- má jasný zdroj pravdy,
- má popsaný stavový/datový model,
- má určené povolené a zakázané změnové cesty,
- má definované invarianty,
- má pozitivní test,
- má negativní nebo regresní test,
- byla ověřena v cílovém prostředí,
- dokumentace odpovídá skutečnému kódu,
- zbylá rizika jsou výslovně zapsána.
Jinak musí být označena jako:
NEHOTOVO / NEOVĚŘENO / RIZIKO.
```
A šablonu pro každou změnu:
```text
## Kontrakt změny
ID změny:
Účel:
Riziková kategorie:
Zdroj pravdy:
Dotčená data/stav:
Canonical owner:
Povolené write cesty:
Zakázané write cesty:
Derived výstupy:
Invarianty:
Pozitivní test:
Negativní/regresní test:
Cílové prostředí:
Dokumentace k aktualizaci:
Neověřená rizika:
Důkaz ověření:
Verdikt:
```
Krátká zásada do `AGENTS.md`:
```text
Nejdřív kontrakt, potom kód.
Nejdřív invarianty, potom UI.
Nejdřív negativní test, potom tvrzení o opravě.
LLM není autorita.
Hotovo znamená doloženo.
Co není ověřeno, musí být označeno jako neověřené.
```
Ano, směr je správný, ale tvrzení ještě není dostatečně přesné pro LLM vibe coding. Je to dobrý **workflow rámec**, ne úplná metodika.
**Co je správně**
- Dokumentace má vznikat před kódem.
- Každá změna má mít kontrakt.
- Musí existovat risk matrix.
- Musí být jasný quality gate.
- Musí se evidovat důkazy a neověřená rizika.
- „Hotovo“ nesmí znamenat dojem.
**Co je slabé**
- Neříká přesně, kdy je změna „netriviální“.
- Neříká, co je minimální kontrakt pro urgentní bug.
- Neobsahuje pravidlo „nejdřív reprodukce chyby“.
- Neobsahuje zákaz nepodloženého tvrzení LLM.
- Neřeší konflikt mezi uživatelským pokynem, dokumentací, kódem a doménovým zdrojem.
- Neříká, jak se vynucuje aktualizace dokumentace.
- Neobsahuje negativní test jako povinný důkaz opravy.
- Neříká, co dělat, když cílové prostředí nelze ověřit.
**Kritická úprava**
Pro LLM vibe coding musí workflow obsahovat ještě tato pravidla:
```text
1. LLM nesmí začít kódovat high-risk změnu bez kontraktu.
2. U bugu musí nejdřív reprodukovat nebo přesně označit nereprodukovatelnost.
3. Oprava bugu musí obsahovat root cause, ne jen změnu symptomu.
4. Každá oprava musí přidat regresní test, který by starou chybu chytil.
5. LLM nesmí tvrdit „ověřeno“, pokud neuvádí konkrétní test/prostředí.
6. Pokud cílové prostředí nelze ověřit, výsledek je NEOVĚŘENO.
7. Dokumentace se musí měnit ve stejné změně jako chování.
8. Známá rizika se nesmí schovat do obecné formulace.
```
**Verdikt**
Tvrzení je správné jako základní směr.
Pro řízení LLM vibe codingu je ale potřeba doplnit ho o:
- reprodukční workflow pro chyby,
- root-cause povinnost,
- negativní/regresní test,
- zákaz falešného ověření,
- jasné blokující stavy,
- pravidla konfliktu zdrojů pravdy.
Bez toho může LLM dál vytvářet dobře znějící, ale neověřené změny.
Chovej se jako skeptický architekt, QA auditor, bezpečnostní reviewer a doménový auditor zároveň.
Hledej důvody, proč tento rámec stejně v této logice musí selhat, ne proč zní dobře.
**Verdikt:**
Ano, i tento rámec může selhat.
Je lepší než volný vibe coding, ale pořád spoléhá na to, že lidé/LLM správně určí rizika, kontrakty, zdroje pravdy a testy.
To je slabé místo.
**Proč musí selhat, pokud se bere jako „dostatečný“**
1. **Rizikovou kategorii určuje stejný subjekt, který chce kódovat.**
LLM i člověk mají motivaci označit změnu jako menší, aby mohli pokračovat.
2. **Kontrakt může být špatný.**
Když je požadavek neúplný nebo mylný, kontrakt jen formalizuje chybu.
3. **Testy mohou ověřovat špatnou věc.**
Test může potvrdit implementaci kontraktu, ale ne pravdivost kontraktu.
4. **Doménový zdroj může být špatně interpretován.**
U daní/práva nestačí citace zákona. Je potřeba výklad, kontext, aktuálnost a případně poradce.
5. **LLM může falšovat jistotu.**
I s pravidly může napsat „ověřeno“, pokud se systémově nevynucuje evidence.
6. **Quality gate může být formální rituál.**
Checklisty často degenerují na odškrtávání bez skutečné kontroly.
7. **Cílové prostředí nemusí být reprodukovatelné.**
File URL, cache, browser, OS, locale, uložený state, staré JS – to může rozbít věc i po passing testech.
8. **Negativní test může být moc úzký.**
Zachytí přesně starou chybu, ale ne stejnou třídu chyby v jiné části systému.
9. **Dokumentace může zestárnout okamžitě.**
Pokud není generovaná nebo kontrolovaná proti kódu, rychle se stane lživou.
10. **Nezávislé review nemusí být nezávislé.**
Druhý LLM může sdílet stejné slepé skvrny. Člověk může jen potvrdit výstup bez hluboké kontroly.
11. **Invarianty mohou být neúplné.**
Definují, co autor napadlo. Ne co se skutečně může stát.
12. **Proces může být příliš těžký.**
Pokud je příliš náročný, lidé ho začnou obcházet.
13. **Bez automatického enforcementu je to jen kultura.**
Kultura selže pod tlakem času, frustrace nebo složitosti.
14. **Bez vlastnického modelu dat selže u importů/exportů.**
Data, mezivýpočty, cache, storage a exporty mohou mít skryté druhé zdroje pravdy.
15. **Bez auditní reprodukovatelnosti nelze zpětně zjistit, co se ověřilo.**
Nestačí říct „test prošel“. Musí být jasné s jakými daty, verzí, prostředím a očekáváním.
**Co z toho plyne**
Rámec musí být doplněn o obranu proti vlastnímu selhání:
```text
1. Riziko nesmí určovat pouze implementátor.
2. Kontrakt musí mít oponentní review.
3. Test musí ověřovat nejen výsledek, ale i architektonickou cestu.
4. Dokumentace musí být buď generovaná z kódu, nebo kontrolovaná proti kódu.
5. Quality gate musí být automaticky blokující.
6. Neověřené prostředí musí vést k verdiktu NEOVĚŘENO.
7. Každý bug musí mít test třídy chyby, ne jen konkrétní instance.
8. Každý důkaz musí být reprodukovatelný.
```
**Nejtvrdší závěr**
Tento rámec nesmí být považován za záruku kvality.
Správně je:
**Je to kontrolní systém, který sám potřebuje kontrolu.**
Musí mít:
- automatické blokace,
- oponenturu,
- reprodukovatelné důkazy,
- nezávislou doménovou validaci,
- pravidla proti obcházení,
- a povinnost označit výsledek jako neověřený, kdykoli některá vrstva chybí.
Ta formulace není správná.
Problém je hlavně výraz **„101% vynutitelná“**.
To je rétoricky silné, ale technicky nepřesné. Dokumentace sama o sobě nikdy není 101% vynutitelná.
Vynutitelná je až kombinace:
**dokumentace + checklist + automatický quality gate + testy + review + blokující verdikt.**
Správnější formulace:
```text
Aktualizuj řídící dokumentaci projektu tak, aby nebyla pouze doporučením,
ale aby definovala vynutitelný quality-gate proces pro LLM/vibe coding.
Dokumentace musí:
1. jasně rozlišit fakta, předpoklady, rizika a neověřené body,
2. definovat rizikové kategorie změn,
3. určit povinné artefakty pro každou kategorii,
4. určit blokující podmínky, kdy se nesmí tvrdit HOTOVO,
5. popsat kontrakt změny,
6. popsat povinné pozitivní, negativní, regresní a cílové testy,
7. zavést pravidlo, že LLM nesmí tvrdit „ověřeno“ bez konkrétního důkazu,
8. popsat, jak se ověřuje dokumentace proti kódu,
9. popsat, co dělat, když cílové prostředí nelze ověřit,
10. zavést explicitní verdikty HOTOVO / NEOVĚŘENO / RIZIKO / NEHOTOVO.
Při návrhu dokumentace se chovej jako skeptický architekt, QA auditor,
bezpečnostní reviewer a doménový auditor zároveň. Hledej hlavně způsoby,
jak může proces selhat, jak může být obcházen a jaké automatické nebo
procedurální pojistky tomu mají zabránit.
Nepoužívej formulaci „101% garance“. Místo toho uveď, které části jsou
strojově vynutitelné, které jsou kontrolované review a které zůstávají
lidským/doménovým rizikem.
```
Ještě kratší příkaz:
```text
Aktualizuj řídící dokumentaci projektu na auditovatelný a částečně strojově
vynutitelný quality-gate systém pro LLM/vibe coding. Neformuluj absolutní
garance. U každého pravidla uveď, zda je vynucené skriptem, testem, review,
nebo zůstává explicitním rizikem.
```
Tohle je přesnější a technicky obhajitelné.
Chovej se jako skeptický architekt, QA auditor, bezpečnostní reviewer a doménový auditor zároveň.
Hledej důvody, proč tento rámec níže stejně v této logice musí selhat, ne proč zní dobře:
Aktualizuj řídící dokumentaci projektu na auditovatelný a strojově
vynutitelný quality-gate systém pro LLM/vibe coding.
Neformuluj absolutní garance. U každého pravidla uveď, zda je vynucené skriptem, testem, review,
nebo zůstává explicitním rizikem.
**Verdikt:** formulace je lepší, ale pořád může selhat. Největší problém je věta **„strojově vynutitelný quality-gate systém“**. To může znít jako absolutní kontrola, ale mnoho pravidel strojově vynutit nejde. Lze vynutit jen část.
**Proč rámec selže**
1. **Strojově vynutitelné není všechno.**
Skript pozná `stopPropagation`, duplicitní handler nebo chybějící test. Nepozná spolehlivě špatný daňový výklad, neúplný požadavek nebo chybnou doménovou interpretaci.
2. **Auditovatelnost není správnost.**
I perfektně zdokumentovaná chyba je pořád chyba.
3. **LLM může klasifikaci zfalšovat nebo podhodnotit.**
Např. označí high-risk změnu jako standard, aby mohla pokračovat.
4. **„U každého pravidla uveď vynucení“ nestačí.**
Musí být uvedeno také: kdo je owner, co je blokující, jaký je důkaz, co se stane při selhání.
5. **Chybí konflikt zdrojů pravdy.**
Musí být jasné pořadí: zákon/doménový zdroj > schválený kontrakt > kód > test > LLM tvrzení.
6. **Chybí fail-closed princip.**
Pokud ověření chybí, výsledek nesmí být „asi hotovo“, ale automaticky `NEOVĚŘENO`.
7. **Chybí zákaz „papírového quality gate“.**
Checklist bez skriptu/testu/review se snadno odškrtne formálně.
**Lepší formulace**
```text
Aktualizuj řídící dokumentaci projektu na auditovatelný quality-gate systém
pro LLM/vibe coding.
Neformuluj absolutní garance. U každého pravidla povinně uveď:
- ID pravidla,
- rozsah platnosti,
- rizikovou kategorii,
- zdroj pravdy,
- zda je pravidlo blokující,
- způsob vynucení: skript / test / review / doménová autorita / explicitní riziko,
- konkrétní důkaz splnění,
- co se stane při selhání,
- zda je pravidlo aktuálně implementované, nebo pouze požadované.
Pokud pravidlo není strojově vynucené existujícím skriptem nebo testem,
nesmí být označeno jako strojově vynutitelné.
Při návrhu se chovej jako skeptický architekt, QA auditor, bezpečnostní reviewer
a doménový auditor. Hledej, jak lze proces obejít, kde může selhat a jaké
blokující pojistky tomu brání.
Výstup musí jasně rozlišit:
FAKT / PŘEDPOKLAD / RIZIKO / NEOVĚŘENO / DOPORUČENÍ.
```
**Nejpřesnější zkrácení**
```text
Nevytvářej dokumentaci jako doporučení.
Vytvoř systém pravidel, důkazů a blokujících verdiktů.
Co není vynuceno skriptem, testem, review nebo doménovým zdrojem,
musí být označeno jako riziko, ne jako garance.
```
znamená to že potom nikdy nemůže nastat problém jako např.:
1. Lokální handler uvnitř buildChoiceGroup v 12-ui-questions.js — volá onChange a má event.stopPropagation()
2. Globální handler handleQuestionOptionClick v 17-app.js — primární handler registrovaný na document
Lokální handler zavolá onChange → setState → notify() → synchronní re-render → container.innerHTML = "". Tím se OKAMŽITĚ zničí původní DOM tlačítek uprostřed zpracování click eventu. stopPropagation() pak blokuje globální handler, který byl navržen jako hlavní. Výsledek je nestabilní re-render s detached DOM elementy.
Oprava: odstraním lokální click handler z buildChoiceGroup — globální handleQuestionOptionClick je kompletní a byl navržen pro tuto práci (má správný guard nextQuestions[id] === value a bezpečně pracuje s live DOM před re-renderem).
Ne. Neznamená to, že **nikdy** nemůže nastat podobný problém.
Znamená to jen, že pokud bude quality-gate správně zavedený, tak:
1. **tento konkrétní problém by měl být zachycen dřív**,
2. **návrat stejné chyby by měl spadnout na testu**,
3. **LLM by nesmělo tvrdit „hotovo“, dokud není doložené, že konfliktní handler neexistuje**.
Aby se přesně tahle chyba už nevrátila, musí existovat konkrétní pravidla:
```text
QG-UI-01:
Pro jeden data-action/data-question-option smí existovat jen jedna business write cesta.
QG-UI-02:
Render/build helper nesmí registrovat business click handler, který volá setState/onChange.
QG-UI-03:
stopPropagation je zakázaný u běžných formulářových voleb bez výslovné výjimky.
QG-UI-04:
Klik odpovědi musí mít regresní test:
klik → state změněn → právě jedna odpověď selected → přehled odpovídá state.
QG-UI-05:
Statický test musí selhat, pokud se v 12-ui-questions.js objeví
addEventListener("click") u data-question-option nebo stopPropagation.
```
Teprve potom lze říct:
**Tato konkrétní třída chyby je chráněná strukturálním i interakčním testem.**
Ale nelze říct:
**Nikdy nevznikne podobný problém jinde.**
Podobná chyba může vzniknout v importu, storage, grafech, exportu, autosave, mazání dat nebo výpočtu, pokud tam nebude stejně konkrétní pravidlo a test.
Aktualizuj řídící dokumentaci projektu na auditovatelný quality-gate systém
pro LLM/vibe coding.
Neformuluj absolutní garance. U každého pravidla povinně uveď:
- ID pravidla,
- rozsah platnosti,
- rizikovou kategorii,
- zdroj pravdy,
- zda je pravidlo blokující,
- způsob vynucení: skript / test / review / doménová autorita / explicitní riziko,
- konkrétní důkaz splnění,
- co se stane při selhání,
- zda je pravidlo aktuálně implementované, nebo pouze požadované.
Pokud pravidlo není strojově vynucené existujícím skriptem nebo testem,
nesmí být označeno jako strojově vynutitelné.
Při návrhu se chovej jako skeptický architekt, QA auditor, bezpečnostní reviewer
a doménový auditor. Hledej, jak lze proces obejít, kde může selhat a jaké
blokující pojistky tomu brání.
Výstup musí jasně rozlišit:
FAKT / PŘEDPOKLAD / RIZIKO / NEOVĚŘENO / DOPORUČENÍ.
vibe coding
