LMC DEVELOPMENT — C-04 THIRD-FAILURE PACKAGING ARCHITECTURE ...

Prompt

LMC DEVELOPMENT — C-04 THIRD-FAILURE PACKAGING ARCHITECTURE REVIEW + GATE RECOVERY ÚKOL Tento běh je pokračováním C-04 po dvou po sobě jdoucích nevalidních testovacích balících. Úkolem nyní NENÍ provádět behaviorální experiment C-04. Úkolem je zjistit, zda opakované selhání stejného mechanismu již představuje pouze lokální SPECIFICATION GAP, nebo SYSTEMATIC PACKAGING / DELIVERY FAILURE, a určit nejmenší změnu, která zabrání třetímu opakování stejné chyby. Dále musíš definovat přesný pre-send mechanismus, který musí být splněn před tím, než může být další C-04 balík vůbec distribuován k behaviorálnímu měření. DŮKAZNÍ ZÁMEK Používej pouze materiál dodaný v tomto promptu. Nesmíš: * vymýšlet chybějící text LMC-39, * rekonstruovat pravidla LMC-39 z kontextu, * vytvářet vlastní LMC-derived expected flow, * používat výsledky jiných modelů jako oracle, * tvrdit, že behaviorální experiment proběhl, * simulovat modelové invokace, * zaměňovat chybu testovacího balíku za behaviorální chybu modelu. Unknown ≠ Absent. Pokud skutečný obsah LMC-39 není přítomen, nesmíš jej doplnit ani odhadovat. AKTUÁLNÍ EVIDENCE Z PŘEDCHOZÍCH DVOU BĚHŮ BĚH 1 — C-04: * skutečný text LMC-39 nebyl v testovacím promptu přítomen; * Condition B nebyla kompletně uzamčena; * expected flow a scoring nebyly uzamčeny; * behaviorální měření proto bylo správně zastaveno. BĚH 2 — C-04 REVALIDACE: * skutečný text LMC-39 opět nebyl přítomen; * v bloku LMC-39 zůstal pouze placeholder; * Condition B měla Candidate / Evidence state / Question, ale Expected flow a Scoring zůstaly placeholdery; * Negative control měla podobně neuzamčený Expected flow a Oracle class; * behaviorální měření bylo opět zastaveno; * doporučeným krokem bylo SPECIFICATION REFINEMENT. Tuto evidenci můžeš použít pouze jako dokumentaci předchozích stavů. DŮLEŽITÁ ZMĚNA PRO TENTO BĚH Protože stejný packaging defect nastal dvakrát po sobě, nesmíš automaticky předpokládat, že třetí opakování lze řešit stejnou lokální opravou. Musíš explicitně rozlišit: # A. ISOLATED SPECIFICATION ERROR jednorázová chyba obsahu testovacího balíku, která je lokálně opravitelná. # B. PACKAGING PROCESS FAILURE proces opakovaně nedokáže přenést nebo vložit materiál, který musí být před rozesláním přítomen. # C. ARCHITECTURE / PIPELINE FAILURE mechanismus vytváření, validace nebo distribuce promptu dovoluje, aby neúplný balík opakovaně prošel do další fáze. Nevol automaticky C. Musíš jej odvodit z evidence. 1. INPUT / VALIDITY GATE Nejprve ověř, co je skutečně přítomno v tomto promptu. Zkontroluj minimálně: 1. skutečný kompletní text LMC-39, 2. Condition A, 3. Condition B, 4. Expected flow Condition B, 5. Scoring Condition B, 6. Negative control, 7. Expected flow Negative control, 8. Oracle class Negative control, 9. Primary endpoint, 10. provenance všech expected-flow prvků, 11. absence placeholderů, 12. absence nevyplněných „SEM VLOŽ...“, „[...]", „TBD“, „TODO“ nebo ekvivalentních konstrukcí. Každou položku označ: PASS / FAIL / UNRESOLVED / NOT APPLICABLE. Důležité: Tento gate je gate TESTOVACÍHO BALÍKU, nikoli behaviorální výsledek modelu. 2. ANALÝZA OPAKOVANÉHO SELHÁNÍ Porovnej mechanismus selhání BĚHU 1 a BĚHU 2. Urči: * co se nezměnilo, * co bylo opraveno, * co zůstalo rozbité, * zda oba běhy selhaly na stejné úrovni, * zda druhý běh skutečně implementoval deklarovanou opravu, * zda existuje důkaz, že problém vzniká při konstrukci/distribuci promptu a nikoli jen v návrhu experimentu. Nesmíš tvrdit konkrétní technickou příčinu, pokud pro ni nemáš důkaz. Používej formulace: OBSERVED SUPPORTED INFERENCE UNRESOLVED HYPOTHESIS. 3. ROOT-CAUSE TREE Vytvoř stručný strom možných příčin: CONTENT SOURCE → TEMPLATE → SLOT FILLING → PRE-SEND VALIDATION → EXPORT / COPY → DISTRIBUTION → RECEIVING MODEL U každého uzlu označ: * evidence existuje / neexistuje, * co lze vyvrátit, * co nelze vyvrátit. Nezaměňuj „nevíme, kde chyba vznikla“ za „chyba je pravděpodobně v X“. 4. ARCHITECTURE REVIEW DECISION Rozhodni, zda současná evidence již odůvodňuje: A. SPECIFICATION REFINEMENT B. PATCH C. ARCHITECTURE REVIEW D. STOP / NO CHANGE E. ESCALATE Výběr musí být odvozen přes: AKTUÁLNÍ STAV → NEJVYŠŠÍ ROZHODOVACÍ MEZERA → EXPECTED INFORMATION GAIN → JEDNA PRIORITNÍ AKCE → STOP / ESCALACE. Vysvětli zejména, zda druhé po sobě jdoucí selhání stejného typu stačí k přechodu z lokální opravy na architecture review. Pokud podle evidence architecture review zatím odůvodněno není, řekni proč. 5. PRE-SEND COMPLETENESS GATE Navrhni minimální povinný gate, který musí být proveden PŘED rozesláním dalšího C-04 promptu. Gate musí být mechanicky kontrolovatelný a nesmí záviset pouze na lidském dojmu „prompt vypadá kompletně“. Minimálně musí ověřovat: * LMC-39 je přítomen a není placeholder, * všechny deklarované mandatory slots jsou vyplněny, * žádný placeholder nezůstal, * expected flow je skutečně vložen, * scoring je skutečně vložen, * provenance je určena, * negative control je uzamčena, * oracle class je explicitně vybrána, * primary endpoint je explicitní, * testovací balík neobsahuje nepředanou instrukci „doplň před odesláním“. Pokud některý bod selže: DISTRIBUTION = BLOCKED. Žádná další heuristická výjimka nesmí být použita. 6. ATOMICITY / CONSISTENCY CHECK Posuď, zda je vhodné kontrolovat také: * počet placeholderů před a po finalizaci, * počet mandatory fields, * přítomnost přesně definovaných markerů, * hash nebo jiný integrity check pro LMC-39, * shodu mezi zdrojovou a odeslanou verzí, * automatickou detekci změny obsahu mezi finalizací a distribucí. Nenavrhuj konkrétní technologii jako nutnou bez důkazu. Rozliš: MINIMAL REQUIRED CONTROL vs. OPTIONAL HARDENING. 7. SINGLE-SOURCE-OF-TRUTH Posuď, zda současný mechanismus implicitně dovoluje, aby: * existovala zdrojová verze LMC-39, * existovala šablona C-04, * existovala rozesílaná verze, * ale nebylo možné dokázat, že rozesílaná verze obsahuje skutečně stejný text. Pokud ano, navrhni minimální provenance invariant: SOURCE → FINALIZED TEST PACKAGE → DISTRIBUTED PAYLOAD. Každý přechod musí být auditovatelný. 8. BEHAVIORAL EXPERIMENT — EXPLICITLY DEFERRED Behaviorální experiment v tomto běhu nespouštěj. Počet nových behaviorálních invokací: 0 Důvod: tento běh je architecture/package validation, nikoli validní behaviorální C-04 experiment. I kdyby byl testovací balík v tomto promptu kompletní, nesmíš předstírat realizaci externích nezávislých invokací. 9. RECOVERY SPECIFICATION Navrhni přesný stav, který musí být splněn, aby další běh mohl legitimně přejít z: BLOCKED na: READY FOR BEHAVIORAL EXPERIMENT. Definuj minimální recovery invarianty. Příklad formátu: READY ONLY IF: R1 ... R2 ... R3 ... Pokud některý invariant není splněn: BLOCKED. 10. THIRD-FAILURE RULE Definuj explicitní pravidlo pro další opakování: Pokud další distribuovaný balík znovu obsahuje stejný blocking placeholder / missing mandatory field, NEJDŘÍVE se nesmí opakovat samotný C-04 experiment. Namísto toho musí být aktivováno: ARCHITECTURE REVIEW / PACKAGING PIPELINE REVIEW a musí být přezkoumán mechanismus tvorby a distribuce experimentálních promptů. Posuď, zda je takové pravidlo metodologicky přiměřené. 11. CLAIM–EVIDENCE LEDGER Na konci uveď pouze tvrzení, která lze z tohoto běhu legitimně podpořit. Používej: CLAIM EVIDENCE SCOPE ALTERNATIVE EXPLANATION STATUS: SUPPORTS / CONFLICTS / INSUFFICIENT DECISIONAL IMPACT Nevytvářej behaviorální tvrzení. 12. POVINNÝ VÝSTUP A. INPUT / VALIDITY GATE B. REKONSTRUKCE SELHÁNÍ BĚH 1 → BĚH 2 C. ROOT-CAUSE TREE D. JE TO JIŽ PACKAGING / ARCHITECTURE FAILURE? E. MINIMAL REQUIRED FIX F. PRE-SEND COMPLETENESS GATE G. PROVENANCE / SOURCE-OF-TRUTH CONTROL H. RECOVERY CONDITIONS FOR C-04 I. CO LZE / NELZE ZJISTIT J. MAX. 3 SKUTEČNÁ ZJIŠTĚNÍ K. JEDNA PRIORITNÍ DALŠÍ AKCE Každé zjištění musí obsahovat: ID CLASS SEVERITY EVIDENCE MECHANISM IMPACT CONFIDENCE Nepoužívej více než 3 skutečná zjištění. 13. PRIORITNÍ ROZHODNUTÍ Na závěr uveď přesně: STATUS: NEXT ACTION: ENDPOINT STATUS: BEHAVIORAL INVOCATIONS: STATUS může být: ADVANCE / REVISE / ESCALATE / STOP / DEFER ENDPOINT STATUS může být: READY / BLOCKED / UNRESOLVED BEHAVIORAL INVOCATIONS musí být v tomto běhu: 0 14. ZÁSADNÍ DISCIPLÍNA Nesmíš: * doplnit LMC-39, * navrhnout jeho obsah, * vytvořit zástupný LMC-derived oracle, * spustit behaviorální experiment, * označit opakované selhání balíku za behaviorální vlastnost modelu, * zaměnit modelový konsenzus za nezávislou validaci, * rozhodnout o architecture review pouze podle počtu modelů. Musíš naopak: * zachovat Evidence Lock, * rozlišovat pozorování od inference, * explicitně pracovat s opakovaností stejného defektu, * hledat nejmenší účinný zásah, * zabránit třetímu opakování stejné packaging chyby, * určit, zda další nejlepší krok patří ještě do specifikace, nebo již do architektury procesu. Sem napiš dotaz: