LMC METHODOLOGY — INDEPENDENT 10-MODEL AUDIT MAXIMÁLNĚ 5 ITE...

Prompt

LMC METHODOLOGY — INDEPENDENT 10-MODEL AUDIT MAXIMÁLNĚ 5 ITERACÍ · EXTERNÍ VALIDACE METODIKY ÚKOL Proveď nezávislý, kritický a systematický audit přiložené metodiky „LMC — DLOUHODOBÁ METODIKA ŘÍZENÉHO VÝVOJE“. Cílem není metodiku pochválit ani ji automaticky přepsat. Cílem je zjistit: 1. zda je metodika vnitřně konzistentní; 2. zda je skutečně vykonatelná v reálném vlákně LLM; 3. zda její rozhodovací pravidla vedou k jednoznačnému a reprodukovatelnému postupu; 4. zda obsahuje chyby, mezery, konflikty, slepé větve nebo neproveditelné požadavky; 5. zda některé části vytvářejí zbytečnou procesní složitost nebo riziko nekonečného vývoje; 6. které identifikované problémy jsou dostatečně podložené pro skutečnou opravu; 7. jaká zlepšení by zvýšila robustnost, efektivitu, epistemickou kvalitu nebo použitelnost metodiky. Toto je AUDIT METODIKY, nikoli běžný vývoj promptu. DŮLEŽITÉ ODDĚLENÍ OD JINÉHO PROCESU Tento audit je samostatná validační větev. Nepoužívej: * výsledky jiných modelů z probíhajícího zrychleného vývoje; * výsledky souborů označených čísly; * předchozí experimentální závěry, pokud nejsou přímo součástí tohoto zadání; * domněnky o tom, co „už bylo potvrzeno“ v jiném procesu. Výsledky tohoto auditu budou následně předány samostatně a označeny písmeny A, B, C ... podle pořadí modelů. Deset modelů tvoří CROSS-MODEL DIVERSITY, nikoli deset replikací stejného modelu. Nevyvozuj intra-model reproducibility z toho, že více modelů dospělo ke stejnému názoru. NEPOUŽÍVEJ WEB SEARCH ani externí zdroje, pokud není jejich použití výslovně nezbytné k ověření čistě faktického tvrzení. Primárním objektem auditu je dodaná metodika jako interní specifikace. Ne nahrazuj její definice vlastními. ZÁKLADNÍ PRAVIDLA AUDITU 1. Rozlišuj minimálně: * skutečnou logickou/instrukční chybu; * specifikační mezeru; * nejednoznačnost; * konflikt dvou pravidel; * neproveditelný nebo prakticky nerealistický požadavek; * experimentální/metodologický defect; * pouze stylistický problém; * alternativní, ale nikoli nutně lepší návrh. 2. Nepovažuj absenci explicitní věty automaticky za chybu, pokud lze pravidlo jednoznačně a bezpečně odvodit z jiné části metodiky. 3. Naopak nepovažuj tvrzení typu „to je definováno“ za skutečnou specifikaci, pokud není jasné, jak by se podle něj měl LLM zachovat v konkrétní situaci. 4. Každý závažný nález se pokus reprodukovat prostřednictvím konkrétní situace, ve které by metodika vedla k chybnému, nejednoznačnému nebo nežádoucímu chování. 5. Nezaměňuj: specification gap experiment-design defect evaluator/judge artifact orchestration/runtime problém intra-model stochasticity cross-model heterogenitu skutečný behavioral failure. 6. Vlastní definici severity můžeš navrhnout, ale nepřepisuj bezdůvodně terminologii metodiky. Tam, kde metodika používá R1/R2/R3, vždy nejprve ověř, zda je daná klasifikace pro konkrétní nález skutečně textově podložená. 7. Majority vote není důkaz. Argumenty hodnoť podle evidence, reprodukovatelnosti, scope a alternativních vysvětlení. 8. Nevymýšlej chybějící části metodiky. Pokud nelze rozhodnout, označ problém jako UNRESOLVED nebo INSUFFICIENT EVIDENCE. 9. Nesnaž se změnit metodiku jen proto, aby byla „čistší“, kratší nebo elegantnější. Každé navržené zlepšení musí mít konkrétní benefit proti complexity cost. 10. Při návrhu změny vždy zvaž: * co přesně se zlepší; * jaké nové riziko vznikne; * zda změna zachová dosavadní capability; * zda lze její přínos následně ověřit. ITERACE 1 — STATICKÝ STRUKTURNÍ AUDIT Proveď úplný průchod metodikou bez navrhování rozsáhlého rewrite. Prověř zejména: * definice stavů a přechodů; * startup a routing; * AKTUÁLNÍ PRODUKČNÍ PROMPT vs. FROZEN BASELINE; * autonomous decision contract; * Experiment Validity Gate; * evidence hierarchy; * Claim–Evidence Ledger; * failure-mode registry; * coverage a interaction model; * prompt invariants; * experiment card; * minimal intervention a complexity budget; * regression, negative controls, ablation a holdout; * judge/meta-judge; * promotion/commit/fresh freeze; * STOP / NO CHANGE / DEFER / ESCALATE; * 20-iterací budget; * hard constraints; * přenos metodiky do nového vlákna. Hledej: * přímé kontradikce; * chybějící transition; * pravidla bez akčního důsledku; * akce bez definovaného výsledku; * stavy bez exit conditions; * circular logic; * neřešené edge cases; * pravidla, která mohou vést k deadlocku; * pravidla, která mohou vyvolat nekonečnou iteraci; * pravidla, která si vzájemně konkurují; * místa, kde model může pravidlo interpretovat více než jedním materiálně odlišným způsobem. Na konci ITERACE 1 vytvoř: A) seznam nejdůležitějších zjištění; B) u každého přesnou lokalizaci v metodice; C) proč je nález materiální; D) jak by se projevil v reálném běhu. ITERACE 2 — PROVOZNÍ SIMULACE Nezůstávej u textové analýzy. Simuluj, jak by metodika fungovala v novém vlákně. Proveď nejméně 5 odlišných scénářů: 1. validní vývojový požadavek bez historie; 2. nevalidní experiment; 3. nalezený skutečný failure mode; 4. dostatečné důkazy → STOP/NO CHANGE; 5. rozpor mezi produkčním promptem a baseline. Podle relevance přidej scénář: * incomplete input; * safety/blocking problém; * nový materiální failure těsně před plánovaným stopem; * vyčerpání 20-iterací budgetu; * potřeba pokračovat nad 20 iterací; * metodická změna během probíhajícího experimentu. U každého scénáře urč: CURRENT STATE → DECISION → HIGHEST DECISION GAP → NEXT ACTION → STOP/ESCALATION CONDITION A ověř, zda metodika skutečně umožňuje dojít k jednoznačnému dalšímu kroku bez vlastního „dovymýšlení“ pravidel. Pokud si některý krok musíš sám doplnit, označ přesně, co metodice chybí. ITERACE 3 — ADVERSARIAL / RED-TEAM AUDIT Nyní se záměrně pokus metodiku prolomit. Hledej zejména: * jak lze obejít decision gate; * jak lze neoprávněně vytvořit candidate; * jak lze false positive vydávat za potvrzený failure; * jak lze použít slabou nebo scope-invalid evidence jako potvrzení; * jak může majority bias vzniknout navzdory pravidlům; * jak může model zaměnit specification gap za behavioral failure; * jak může metodika vyvolat zbytečný ASK/refusal/verbosity; * jak může vzniknout prompt bloat; * jak může 20-iterací budget paradoxně zhoršit vývoj; * jak lze obejít STOP a pokračovat bez nové rozhodovací hodnoty; * jak může dojít k tichému driftu baseline; * jak se může zaměnit cross-model evidence za replication; * zda některý hard constraint vytváří nový konflikt nebo deadlock; * zda některá pravidla nefungují při neúplných nebo rozporných vstupech; * zda bezpečnostní větev skutečně přebíjí běžný workflow. U každého závažného nálezu vytvoř minimální counterexample: INPUT / RELEVANT RULES / EXPECTED BEHAVIOR / FAILURE PATH / WHY RULES DO NOT PREVENT IT Neoznačuj hypotetickou možnost za potvrzenou chybu, pokud jsi nedokázal ukázat konkrétní failure path. ITERACE 4 — NÁVRHY ZLEPŠENÍ Na základě předchozích tří iterací vyber pouze změny s reálným očekávaným přínosem. Rozděl je do: A. MUST FIX B. SHOULD IMPROVE C. OPTIONAL / EXPERIMENTAL U každého návrhu uveď: * PROBLEM * ROOT CAUSE * PROPOSED CHANGE * EXPECTED BENEFIT * COLLATERAL RISK * COMPLEXITY COST * HOW TO VALIDATE * PRIORITY Preferuj: * lokální opravu před přepisem; * společnou kořenovou opravu před množstvím výjimek; * explicitní rule před implicitním předpokladem; * odstranění redundance, pokud bezpečně zachovává funkci; * mechanismus s vysokým information gain per modification. Navrhuj jen změny, které lze formulovat konkrétně. Obecné rady typu „metodika by měla být jasnější“ nejsou dostačující. Zvlášť posuď, zda současné nastavení 20-iterací budgetu funguje správně jako: * plánovaný horní rozpočet; * ochrana proti nekonečnému vývoji; * adaptivní mechanismus; * escalation boundary. Pokud je podle tebe nastaveno nevhodně, navrhni přesnou alternativu. ITERACE 5 — FINÁLNÍ ADJUDIKACE A REGRESSION REVIEW Nyní přehodnot všechny předchozí nálezy. Pro každý původně navržený MUST FIX zkus najít nejsilnější protiargument: * existuje jiné pravidlo, které problém ve skutečnosti řeší? * jde problém pouze o jinou interpretaci? * je nález závislý na nereálném scénáři? * lze jej vyřešit menší změnou? * vytvoří oprava větší problém než původní nález? Následně sestav finální seznam pouze těch problémů, které po této kontrole přežily. U každého finálního nálezu uveď: ID CLASS SEVERITY LOCATION CLAIM EVIDENCE FAILURE PATH ALTERNATIVE EXPLANATIONS CONFIDENCE RECOMMENDED ACTION SEVERITY musí být vysvětlena konkrétním dopadem, nikoli jen názvem. Na závěr vyhodnoť samotnou metodiku jako celek v těchto dimenzích: 1. INTERNAL CONSISTENCY 2. EXECUTABILITY 3. EPISTEMIC INTEGRITY 4. EXPERIMENT VALIDITY 5. AUTONOMOUS DECISION QUALITY 6. REGRESSION / RELEASE CONTROL 7. RESISTANCE TO PROMPT DRIFT 8. COMPLEXITY / PROCESS OVERHEAD 9. TERMINATION CONTROL 10. TRANSFERABILITY TO NEW THREADS U každé dimenze dej: STATUS = PASS / PARTIAL / FAIL / UNRESOLVED a jednu stručnou argumentaci. FINÁLNÍ ROZHODNUTÍ Na konci rozhodni jednu z možností: A — SOUND Metodika je dostatečně robustní; nejsou identifikovány materiální opravy. B — MINOR REPAIR Existují konkrétní opravitelné nedostatky, ale základní architektura je validní. C — MAJOR REPAIR Existují materiální problémy vyžadující strukturální změnu. D — REDESIGN Základní architektura obsahuje zásadní rozpory a měla by být přepracována. E — UNRESOLVED Dostupné informace nestačí k validnímu rozhodnutí. Dále vyber maximálně 5 nejdůležitějších doporučených změn v pořadí priority. NEJDŮLEŽITĚJŠÍ OMEZENÍ * Nepřidávej změnu jen proto, že ji považuješ za elegantnější. * Neprováděj vlastní rewrite celé metodiky. * Nevymýšlej chybějící data. * Nepředstírej potvrzení tam, kde máš pouze hypotézu. * Nerozhoduj podle většiny. * Nezaměňuj cross-model shodu za replikaci. * Neoznačuj každý nesoulad za failure. * Nevyužívej 20 iterací mechanicky jen proto, aby byly všechny vyčerpány. * Pokud je rozhodnutí dostatečně uzavřené dříve, STOP je správný výsledek. * Pokud nalezneš závažný problém, musíš vysvětlit mechanismus, kterým se problém projeví. * Pokud nenalezneš žádnou materiální chybu, řekni to explicitně a uveď, jaké potenciální problémy byly prověřeny a proč nebyly potvrzeny. POŽADOVANÁ STRUKTURA VÝSTUPU 1. EXECUTIVE VERDICT 2. ITERACE 1 — STATIC AUDIT 3. ITERACE 2 — OPERATIONAL SIMULATION 4. ITERACE 3 — RED TEAM 5. ITERACE 4 — IMPROVEMENTS 6. ITERACE 5 — FINAL ADJUDICATION 7. TOP FINDINGS 8. TOP RECOMMENDATIONS 9. OVERALL STATUS Do „TOP FINDINGS“ zařaď pouze nálezy, které po ITERACI 5 považuješ za stále opodstatněné. Do „TOP RECOMMENDATIONS“ zařaď pouze změny, které by podle tebe měly být skutečně předloženy k další metodické úpravě. Neprováděj další šestou iteraci. Po ITERACI 5 proces tohoto auditu uzavři. STATUS: <SOUND / MINOR REPAIR / MAJOR REPAIR / REDESIGN / UNRESOLVED> CONFIDENCE: <HIGH / MEDIUM / LOW> PRIMARY RECOMMENDATION: <jedna nejdůležitější další akce> Sem napiš dotaz: