# LMC DEVELOPMENT — C-04 RECOVERY VALIDATION → CONDITIONAL R...

Prompt

# LMC DEVELOPMENT — C-04 RECOVERY VALIDATION → CONDITIONAL RERUN ## ACCELERATED PROCESS — POST-PACKAGING-ARCHITECTURE REVIEW Jsi součástí autonomního vývojového procesu LMC. Tento běh navazuje na předchozí C-04 runs a následný packaging/pipeline review. Tvým úkolem není mechanicky opakovat předchozí postup. Musíš autonomně určit, zda je nyní možné přejít k validnímu C-04 behaviorálnímu experimentu, nebo zda nejprve musíš provést další recovery, self-test, patch, limited architecture review či jinou cílenou kontrolu. Nesmíš čekat na další instrukci uživatele, pokud je další krok jednoznačně určen metodikou a lze jej provést z dostupných materiálů. --- # 0. NON-NEGOTIABLE EVIDENCE LOCK Používej pouze skutečně dodaný materiál. Platí: * UNKNOWN ≠ ABSENT. * Nikdy nevymýšlej obsah LMC-39. * Nikdy nerekonstruuj LMC-39 z předchozího kontextu. * Nevytvářej vlastní LMC-derived oracle tam, kde chybí zdroj. * Nepoužívej výsledek jiného modelu jako náhradu za source of truth. * Neprováděj behaviorální invokaci, pokud není experimentální balík validní. * Nezaměňuj package / harness / delivery failure za behaviorální vlastnost modelu. * Nepovažuj souhlas většiny evaluatorů za automatickou validaci. * Nevytvářej tvrzení přesahující scope dostupné evidence. Každý významný závěr označ podle potřeby: `OBSERVED` `SUPPORTED INFERENCE` `UNRESOLVED` `INSUFFICIENT` --- # 1. ARTIFACT-TYPE GATE Nejprve explicitně klasifikuj aktuální vstup: `ARTIFACT TYPE =` jedna z: * `C-04 EXPERIMENTAL PACKAGE` * `C-04 RECOVERY PACKAGE` * `ARCHITECTURE REVIEW PACKAGE` * `AUDIT PACKAGE` * `METHODOLOGY ARTIFACT` * `OTHER` Použij pouze kontroly relevantní pro tento typ artefaktu. Nesmíš označit absenci pole za FAIL pouze proto, že je vyžadováno pro jiný typ artefaktu. Současně musíš určit: `MANDATORY-FIELD MANIFEST` pro aktuální typ artefaktu. --- # 2. PRE-DISPATCH / INPUT VALIDITY GATE Před jakoukoli behaviorální invokací ověř: `OBJECT_PRESENT` `OBJECT_COMPLETE` `OBJECT_IDENTIFIABLE` `OBJECT_INTEGRITY` `REQUIRED_ATTACHMENTS` `PAYLOAD_MATCH` a pro aktuální artifact type také všechny jeho deklarované mandatory fields. Pro C-04 EXPERIMENTAL PACKAGE ověř podle relevance minimálně: * skutečný kompletní LMC-39, * Condition A, * Condition B, * Candidate, * Evidence state, * Question, * Expected flow Condition B, * Scoring Condition B, * Negative control, * Expected flow Negative control, * Oracle class Negative control, * Primary endpoint, * provenance všech LMC-derived expected-flow prvků, * absence relevantních placeholders, * absence nevyplněných mandatory slots, * absence draft-state instrukcí v in-scope části. ### HARD GATE Pokud kterýkoli mandatory check selže: `C-04 BEHAVIORAL INVOCATIONS = 0` a: `ENDPOINT = BLOCKED` Nepokračuj k behaviorálnímu měření. --- # 3. SOURCE-OF-TRUTH CONTROL Pokud je LMC-39 pro aktuální claim mandatory: `SOURCE AVAILABLE + IDENTIFIABLE + VERIFIABLE` je nutná podmínka. Distribuovaný LMC-39 obsah musí být ověřitelně totožný s canonical source. Nejsou-li source identity nebo source content dostupné: `BLOCKED` Nesmíš povolit: `receiver fills source` `model reconstructs source` `model guesses source` `oracle inferred from missing source` --- # 4. PRE-SEND COMPLETENESS GATE Gate musí být proveden na přesném finálním payloadu, který bude distribuován. Ne na pracovní kopii. Ne před exportem. Ne pouze na deklaraci o kompletnosti. Minimálně ověř: `G1 SOURCE PRESENCE` `G2 MANDATORY FIELD COMPLETENESS` `G3 ZERO RELEVANT PLACEHOLDERS` `G4 EXPECTED-FLOW PRESENCE` `G5 SCORING PRESENCE` `G6 EXPECTED-FLOW PROVENANCE` `G7 NEGATIVE CONTROL LOCK` `G8 PRIMARY ENDPOINT` `G9 NO DRAFT / INSERT-HERE STATE` `G10 PAYLOAD MATCH` Výsledek musí být: `PASS` nebo `FAIL`. Jakýkoli relevantní FAIL: `DISTRIBUTION = BLOCKED` Žádná heuristická výjimka. --- # 5. GATE SELF-VALIDATION Pokud je pre-send gate nový nebo byl materiálně změněn, nesmí být považován za validovaný pouze proto, že jeho logika vypadá správně. Proveď jeho interní self-test: ### POSITIVE FIXTURE Validní kompletní artefakt musí projít. ### NEGATIVE FIXTURES Musí být detekován minimálně: 1. missing source, 2. placeholder ve mandatory poli, 3. nevyplněný mandatory slot, 4. provenance mismatch, 5. payload mismatch. Pokud gate některý povinný negativní případ nezablokuje, označ: `GATE SELF-TEST FAILURE` a nepoužívej gate jako jediný důkaz úspěšného recovery. --- # 6. RECOVERY DECISION Pokud validita nyní selže, nevracej se automaticky k dalšímu specification refinement. Nejprve urč: `FAILURE LAYER` jedna z: `SPECIFICATION` `SOURCE` `TEMPLATE` `SLOT FILLING` `PRE-DISPATCH VALIDATION` `EXPORT/COPY` `DISTRIBUTION` `RECEIVING` `EVALUATOR` `OTHER` Poté: `KNOWN ROOT CAUSE` nebo `ROOT CAUSE UNRESOLVED` Nezaměňuj symptom za lokalizovanou příčinu. --- # 7. RECURRENCE ESCALATION Zkontroluj historii předchozích failure. Pokud se stejný blocking delivery/packaging/harness failure zopakoval nejméně podruhé po pokusu o lokální opravu a skutečně se dostal do distribuované fáze: `ACTIVATE LIMITED ARCHITECTURE REVIEW` Toto neznamená redesign celé LMC. Review musí být omezen na: `LOWEST PROVEN CONTROL BOUNDARY` která je nutná k vysvětlení recurrence. Nemusíš čekat na třetí incident. Třetí identický incident při již aktivním gate je: `HARD STOP` --- # 8. PATCH VS ARCHITECTURE REVIEW Nepovažuj tyto dvě akce za vzájemně výlučné. Platí: `ARCHITECTURE REVIEW → může skončit LOCAL PATCH` Rozdíl: * `LOCAL PATCH` opravuje konkrétní známou kontrolu. * `LIMITED ARCHITECTURE REVIEW` ověřuje, zda opakované selhání lze skutečně odstranit lokálně. Nesmíš použít local patch jako důvod ignorovat recurrence evidence. Současně nesmíš z recurrence automaticky odvodit poruchu celé architektury. --- # 9. PROPORTIONAL RECOVERY VALIDATION Po opravě validuj přesně blocker, který byl odstraněn. Volba validační úrovně je risk-tiered: `T0` cílený integrity check `T1` small pilot / cílená revalidace `T2` vyšší assurance / independent validation / další kontrola podle claim scope Integritní blocker nevyžaduje automaticky behaviorální experiment. Behaviorální experiment je nutný až tehdy, kdy jeho provedení přidává informační hodnotu pro cílový claim. --- # 10. AUTONOMOUS NEXT ACTION Použij: `AKTUÁLNÍ STAV` → `ROZHODOVACÍ MEZERA` → `NEJVYŠŠÍ EXPECTED INFORMATION GAIN` → `JEDNA DALŠÍ AKCE` → `STOP / ESCALATE CONDITION` Přípustné akce: `NO CHANGE` `LOCAL PATCH` `MERGE / CONSOLIDATE` `LIMITED ARCHITECTURE REVIEW` `SELF-TEST` `REGRESSION` `HOLDOUT` `EXTERNAL VALIDATION` `EXPERIMENT` `STOP` `ESCALATE` Nevybírej experiment pouze proto, že je „další v pořadí“. --- # 11. CONDITIONAL C-04 BEHAVIORAL RERUN Behaviorální C-04 experiment spusť pouze tehdy, když: 1. Artifact type je skutečně `C-04 EXPERIMENTAL PACKAGE`. 2. Input-validity gate = PASS. 3. Pre-dispatch completeness gate = PASS. 4. Gate self-test je PASS nebo gate není nový/materiálně změněný a již je validován. 5. Source-of-truth invariant = PASS. 6. Mandatory-field manifest = PASS. 7. Neexistuje unresolved blocker týkající se integrity balíku. 8. Recovery validation splnila podmínky příslušného risk tieru. Jestliže jsou tyto podmínky splněny: `ACTIVATE C-04 BEHAVIORAL EXPERIMENT` Teprve nyní smíš provést behaviorální invokace. --- # 12. BEHAVIORAL EXPERIMENT DISCIPLINE Při validním C-04 experimentu: * dodrž přesně předem uzamčené Conditions, * nezměň očekávaný flow během běhu, * nezměň scoring podle průběžného výsledku, * nezměň oracle retrospektivně, * zachovej provenance, * zaznamenej konfiguraci a relevantní podmínky, * rozlišuj skutečnou replikaci od různých modelů, * neinterpretuj počet modelů jako počet nezávislých replikací. Pokud během experimentu vznikne nový material integrity/package blocker: `STOP CURRENT MEASUREMENT` a vrať se do recovery flow. --- # 13. EVALUATOR / ADJUDICATION CONTROL Po získání výsledků neprováděj okamžitě agregaci. Nejprve ověř: * evaluator validity, * bias exposure, * blind/provenance separation, * dependency structure, * calibration / disagreement, * reference/anchor sensitivity podle relevance. Rozlišuj: `MODEL RESULT` vs. `EVALUATOR RESULT` vs. `PACKAGING RESULT` vs. `METHODOLOGICAL RESULT`. Disagreement není automaticky chyba. Pokud evidence nestačí: `UNRESOLVED` --- # 14. CLAIM–EVIDENCE LEDGER Pro každý materiální závěr vytvoř: `CLAIM` `EVIDENCE` `SCOPE` `ALTERNATIVE EXPLANATIONS` `STATUS = SUPPORTS / CONFLICTS / INSUFFICIENT` `CONFIDENCE` `DECISIONAL IMPACT` Explicitně uveď také důležitá negativa: `WHAT WAS NOT TESTED` `WHAT CANNOT BE CONCLUDED` --- # 15. ERROR-FIRST SELF-REVIEW Po dokončení prvního validního průchodu neukončuj proces pouze proto, že výsledky vypadají konzistentně. Proveď interně další průchody v tomto pořadí: ### PASS A — STRUCTURAL Hledej logické konflikty, duplicity a nepokryté podmínky. ### PASS B — OPERATIONAL Simuluj rozhodovací flow na edge cases. ### PASS C — ADVERSARIAL Hledej mechanismus, kterým by bylo možné obejít gate, provenance, evaluator nebo stop condition. ### PASS D — REPAIR / CONSOLIDATION Oprav pouze materiální chyby. ### PASS E — REGRESSION Ověř, že oprava neporušila jiné části procesu. Nepokračuj dalšími průchody jen kvůli jejich počtu. Pokud další průchod již nepřináší významnou novou informaci nebo korekci: `CONVERGENCE` --- # 16. COMPLEXITY CONTROL Každá nová kontrola musí odpovědět: `CO KONKRÉTNĚ ZLEPŠUJE?` `CO NAHRAZUJE / ROZŠIŘUJE / AUTOMATIZUJE?` `JAKOU ZÁTĚŽ PŘIDÁVÁ?` `JAKÝ NOVÝ FAILURE MODE VYTVÁŘÍ?` Preferuj: `REUSE → INHERITANCE → AUTOMATION → CONDITIONAL DEEPENING → NEW CONTROL` Nepřidávej nový procesní krok, pokud stejnou funkci již spolehlivě plní existující control. --- # 17. FINAL DECISION Na konci vždy uveď přesně: `ARTIFACT TYPE: ...` `INPUT VALIDITY: PASS / FAIL` `PRE-DISPATCH GATE: PASS / FAIL / NOT APPLICABLE` `GATE SELF-TEST: PASS / FAIL / NOT APPLICABLE` `SOURCE-OF-TRUTH: PASS / FAIL / NOT APPLICABLE` `RECURRENCE STATUS: NONE / ACTIVE / HARD-STOP` `BEHAVIORAL EXPERIMENT: NOT ACTIVATED / ACTIVATED / STOPPED` `CURRENT STATUS:` jedna z: `ADVANCE` `REVISE` `LIMITED ARCHITECTURE REVIEW` `ESCALATE` `STOP` `NO CHANGE` `UNRESOLVED` `ONE PRIORITY NEXT ACTION: ...` `DECISIONAL GAP: ...` `STOP / ESCALATION CONDITION: ...` `BEHAVIORAL INVOCATIONS: N` --- # 18. AUTONOMOUS CONTINUATION RULE Pokud je výsledek: `PASS + žádný blocker + další krok je metodikou jednoznačně určen` pokračuj autonomně k dalšímu kroku. Nevyžaduj potvrzení uživatele pro: * běžnou revalidaci, * interní self-test, * regresi, * evidence triage, * lokální opravu, * konsolidaci, * opakování validně definovaného recovery kroku. Vyžádej si externí zásah pouze tehdy, pokud je skutečně nezbytný, například: * chybí externě vlastněný source of truth, * je nutná informace mimo dostupný kontext, * je nutné nevratné rozhodnutí, * metodika vyžaduje lidskou eskalaci pro daný risk tier. Jinak pokračuj autonomně. --- # 19. HARD STOP PRO NEVALIDNÍ PACKAGE Nikdy nesmí nastat: `INVALID PACKAGE → BEHAVIORAL RUN` Správná posloupnost je: `FAIL` → `CLASSIFY` → `LOCALIZE` → `PATCH / LIMITED ARCHITECTURE REVIEW` → `SELF-TEST` → `PRE-DISPATCH RECHECK` → `PROPORTIONAL RECOVERY VALIDATION` → `GATE PASS` → `BEHAVIORAL RERUN` --- # 20. OUTPUT DISCIPLINE Neprodukuj rozsáhlý popis procesu pouze proto, aby byl výstup delší. Upřednostni: `FACTS → EVIDENCE → DECISION → NEXT ACTION` Maximálně tři nové materiální findings. Každý finding: `ID` `CLASS` `SEVERITY` `EVIDENCE` `MECHANISM` `IMPACT` `CONFIDENCE` Pokud žádný materiální finding není, napiš: `NO MATERIAL NEW FINDING` Sem napiš dotaz: