P 17 — EXTERNÍ VALIDACE M36 — PRACOVNÍ KANDIDÁTNÍ ARCHITEKTU...

Prompt

P 17 — EXTERNÍ VALIDACE M36 — PRACOVNÍ KANDIDÁTNÍ ARCHITEKTURA / VOI / KAPACITA / HANDOFF STATUS: CANDIDATE TEST PROMPT TARGET: M36 + Z36 PURPOSE: Independent external validation of M36's candidate-architecture layer model, lifecycle, data contracts, traceability, integration controls, effective prompt-capacity use, VOI allocation, Failure-Free Discovery, external recommendation intake, self-improvement integrity and convergence governance. PURPOSE: Independent external validation of M36 candidate architecture + recommendation closed-loop + capacity/VOI + handoff + robustness. MANDATORY BOUNDARY 1. Pracuj pouze s artefakty skutečně dodanými v tomto testu. Neodvozuj M36/Z36/P17 obsah z historické konverzace, názvů souborů ani očekávání. 2. P17 je mandát, ne důkaz obsahu M36/Z36. Expectation-vs-target separation je povinná. 3. Pokud M36 nebo Z36 chybí, jsou neinspektovatelné, identita nesouhlasí nebo P17 cílí na jinou verzi, target-specific audit BLOCKED. Nevydávej target PASS/FAIL, neopravuj target a nic nerekonstruuj. 4. WORKING ≠ FACT; UNKNOWN ≠ ABSENT; ESTIMATE ≠ MEASUREMENT; PROPOSED ≠ EXECUTED; SELF-TEST ≠ INDEPENDENT VALIDATION. 5. Web Search není předpokládán pro competitor/test target. Centrální externí kalibraci lze evidovat pouze odděleně jako external evidence; nesmí změnit target payload. DELIVERY / BOOTSTRAP 6. Ověř M36 + Z36 + P17 jako přesně identifikovatelný tří-souborový handoff: version, identity/fingerprint, parent, lifecycle, iteration, current state a next action. 6. Ověř M36 + Z36 + P17 jako identifikovatelný handoff: version, fingerprint, parent, lifecycle, iteration, state, next action. 7. Ověř C65/C66/C67/C76 a negativně missing-M, missing-Z, stale-target, wrong-P, capacity-underfill. CANDIDATE ARCHITECTURE — CORE STRUCTURE 9. Ověř, zda M36 skutečně obsahuje operativní architekturu, nikoli pouze seznam candidate mechanismů. Identifikuj vrstvy, jejich odpovědnosti, vstupy/výstupy a invarianty. 9. Ověř, zda M36 obsahuje operativní architekturu, nikoli jen katalog; identifikuj vrstvy, vstupy/výstupy, odpovědnost, invariants. 10. Ověř L0–L7 a authority boundaries. 12. Ověř invariant: discovery autonomy nesmí rozšířit governance/release authority; candidate ≠ canonical mechanism; observation ≠ fact; closure advisory ≠ release. 13. Ověř end-to-end tok: EVIDENCE INTAKE → CLASSIFY → FAILURE/COVERAGE/UNCERTAINTY → CANDIDATE GENERATION → UNIQUENESS/MERGE → VOI PORTFOLIO → EXPERIMENT → VALIDATION → ATTRIBUTION/ADJUDICATION → INTEGRATION/ROLLBACK → MONITOR/REVALIDATE → CONVERGENCE/CANDIDATE REOPEN. 13. Ověř end-to-end tok Evidence→Classify→Failure/Coverage/Uncertainty→Candidate→Uniqueness/Merge→VOI→Experiment→Validation→Integration→Monitor/Convergence. DATA CONTRACTS / TRACEABILITY 15. Ověř OBSERVATION, CANDIDATE, EXPERIMENT, VALIDATION a CHANGE/INTEGRATION records jako rozhraní mezi vrstvami. 15. Ověř Observation/Candidate/Experiment/Validation/Change records jako interfaces. 16. Ověř shared key: run/experiment ID, candidate/mechanism ID, provenance, scope, dependencies, evidence status, lifecycle, lineage. 18. Ověř C81–C85: layer contract, data contract, traceability, architecture completeness a orphan/lineage control. Samotné uvedení C-ID nestačí; musí existovat provozní vazba. REGISTRY / LIFECYCLE / PORTFOLIO 19. Ověř Canonical Mechanism Registry vs Candidate Mechanism Registry, mechanism fingerprint a zákaz nového C-ID při pouhém přejmenování nebo lokálním rozšíření. 20. Ověř SAME / EXTENSION / SIMILAR-BUT-DISTINCT / SPLIT / MERGE / SUPERSEDE / NEW a povinnou lineage. 20. Ověř SAME/EXTENSION/SIMILAR-BUT-DISTINCT/SPLIT/MERGE/SUPERSEDE/NEW + lineage. 22. Ověř lifecycle PROPOSED → SCREENED → REFINED → TESTING → DECISION a z něj pouze PROMOTED/DEFERRED/REJECTED/MERGE/SUPERSEDED. 23. Ověř, že každý transition má precondition, evidence a decision record. Generator nesmí potvrdit vlastní promotion; žádný candidate nesmí přímo vstoupit do active methodology/C-ID. 24. Ověř portfolio balance: additive, reduction/merge/prune, boundary, adversarial a evaluator-integrity candidates. Negativně testuj mechanism bloat bez netto přínosu. 25. Ověř C86: candidate-architecture health musí zahrnout diversity, orphan/lineage, stale/deferred debt, bypasses a evidence→decision traceability. 26. Ověř Candidate Decay/Staleness a Rejected-Candidate Memory: revival jen při nové relevantní evidenci a se zachovanou lineage. AUTONOMOUS CANDIDATE GENERATION / RECOMMENDATION 27. Ověř ACMG: failure, near-miss, negative evidence, uncertainty, coverage gaps, interaction anomalies, capability/distribution shifts, evaluator disagreement, stale evidence a external recommendations. 27. Ověř ACMG sources: failure/near-miss, negative evidence, uncertainty, coverage/interaction gaps, drift, evaluator disagreement, stale/external signals. 29. Ověř Candidate Development Loop: evidence-driven refinement, minimal experiment, a možnost WEAKEN/MERGE/REMOVE/DEFER, nejen ADD. 30. Negativně testuj low-value flood, confirmation bias a opakování jediné mechanism family. Požaduj diversity/rejection nebo změnu priority. VOI / EXPERIMENT / ALLOCATION 31. Ověř VOI-G mezi internal experiment, fresh/sequestered holdout, adversarial challenge, ablation, external research a human escalation. 31. Ověř VOI-G routing mezi internal, holdout, adversarial, ablation, external research a human escalation. 32. Ověř information gain, failure/coverage/safety/uncertainty/novelty/cost/redundancy and overfit risk. 34. Ověř EDD/Branch Value Decay a UCL/VRT: predicted vs realized VOI se eviduje; chybějící data = UNVERIFIED, ne nula. 34. Ověř EDD/Branch Value Decay/UCL/VRT: predicted vs realized VOI; missing data ≠ zero. ADAPTIVE PROMPT-SPACE ALLOCATION — POVINNÉ 35. Před vlastním hodnocením ověř skutečný počet znaků P17 a porovnej jej s hard limit 15 000 a working limit 14 200. Efektivní využití je povinný decision step. 36. Ověř APSA: mandatory core, current objective, high-VOI, discovery/near-miss, exploration a reserve podle situace. 37. Ověř C67+C76: každý P x musí provést CAPACITY-EXHAUSTION-SCAN proti candidate/test portfolio. Gate platí i při underfill <800 znaků. Bez fit s kladným netto přínosem musí být podložen UNDERFILL-JUSTIFICATION. 38. Negativně testuj padding, unexplained underfill a unexplained increase working slack proti poslednímu validnímu P x. Správné chování je evidence-driven utilization, nikoli délka pro délku. 39. Ověř Prompt-Space Opportunity Cost: záznam toho, co nový blok vytlačil. P0/P1/safety/epistemic nesmí být vytlačeny P3/P4. 40. Ověř VOI-Based Compression a CAPACITY-AWARE-COMPRESSION. Low-VOI/redundancy se komprimují/deferují před vyššími vrstvami; neúplnost safety/acceptance/observability je nepřípustná. 41. Ověř C77 CAPACITY-ALLOCATION-RECORD: selected inserts, rejected/deferred high-value candidates, utilization, slack, reserve a rationale. 42. Ověř C78 NO-COSMETIC-PADDING a C79 PROMPT-CAPACITY-REGRESSION. Vyšší utilization bez decision value není improvement. FAILURE-FREE DISCOVERY / EVIDENCE FLOW 43. Ověř FAILURE-FREE jako datový subsystém, ne automatický důkaz robustness. Rozliš NEGATIVE CASE, NEAR-MISS, UNRESOLVED, CONTRADICTORY. 47. Ověř NO-POSITIVE-EVIDENCE-AUTO-PROMOTION. Data flow musí být RAW RESULT → NORMALIZED OBSERVATION → CASE TYPE → MECHANISM/BOUNDARY → QUALITY/CONFIDENCE → COVERAGE/UNCERTAINTY → VOI/CANDIDATE UPDATE. EXTERNAL STANDARDS / RECOMMENDATIONS RADAR 49. Ověř ESR, Recommendation Freshness & Conflict, Research Contradiction Search a Research-to-Candidate Gate. 49. Ověř ESR, freshness/conflict, contradiction search a Research-to-Candidate Gate. 50. Ověř source/date/scope/authority/supersession/conflict/recheck date. 52. Ověř Research-Experiment Arbitration. Pokud Search není dostupný, explicitně eviduj Search-off a nesimuluj výsledky. 52. Ověř Research-Experiment Arbitration; Search-off musí být explicitní. SELF-IMPROVEMENT / EVALUATOR INTEGRITY 54. Ověř SIF: Discovery Autonomy ≠ Governance Autonomy. 56. Ověř AAD + MIC: material improvement musí mít risk-matched adversarial nebo fresh-path challenge. DRIFT / CHANGE / REVALIDATION 59. Ověř CIP direct/indirect/interaction impacts. 60. Ověř ARS2/NTG: debt se vrací do portfolio dle risk/VOI. CAUSALITY / NET IMPROVEMENT 62. Ověř CAG: timing ≠ causality. Improvement claim musí být omezen na testovaný scope a validity window. 62. Ověř CAG: timing ≠ causality; improvement claims mají scope/validity window. 63. Ověř A/B, ablation, integration/impact analysis a reversibility dle potřeby. CONVERGENCE / CLOSURE 64. Ověř MVD, CCC, CET. Nízký počet failure sám nestačí. 65. Negativně testuj false convergence: low failure + low coverage + low exploration. Nesmí vzniknout advisory. 66. Pozitivně testuj genuine convergence: relevant coverage + exploration + low future VOI + adversarial/escape bez material finding + nízký relevantní external candidate yield + přijatelná validation debt. 67. Ověř advisory data: marginal-value trend, coverage, exploration, debt, external signal, escape, confidence, closure recommendation. Advisory sama nemění release/freeze. 68. Ověř přesnou formulaci advisory: „MEZNÍ PŘÍNOS DALŠÍCH PLÁNOVANÝCH ITERACÍ VÝRAZNĚ KLESÁ. DOSAVADNÍ EVIDENCE NEUKAZUJE NA DOSTATEČNÝ OČEKÁVANÝ PŘÍNOS DALŠÍHO ROZVOJE V OPROTI NÁKLADŮM A RIZIKŮM. DOPORUČUJI UZAVŘENÍ AKTUÁLNÍ VERZE PROMPTU A PŘECHOD DO VALIDACE/PROVOZNÍHO MONITORINGU.“ AUTONOMOUS HORIZON / DECISION GATES 69. Vyhodnoť, zda router deterministicky odhaduje zbývající experimentální value a volí bounded next block. 70. Pokud další block nemá dostatečný expected value, horizon se zkracuje. Nový P0/P1, material drift nebo významný discovery signal může horizon prodloužit pouze v rámci ≤20 budgetu. 71. Ověř, že continue recommendation ≠ PROMOTE a closure recommendation ≠ RELEASE. INTEGRATION / WHOLE-SYSTEM CHALLENGE 72. Proveď end-to-end challenge celé kandidátní architektury alespoň jedním scénářem observation→candidate→experiment→validation→integration→monitoring a jedním adversarial bypass scénářem. 72. End-to-end challenge architecture + adversarial bypass. 73. Fault injection: missing dependency, duplicate/orphan, stale identity, capacity underfill, candidate flood, self-confirmation, proxy drift, false convergence. EVIDENCE / FINDINGS RULES 75. Pro každý test: TEST | VÝSLEDEK | RATING | STRUČNÉ ODŮVODNĚNÍ. Používej PASS / FAIL / BLOCKED / UNVERIFIED / N/A. 76. BLOCKED kvůli dependency neinterpretuj jako target FAIL ani jako důkaz čistoty targetu. Absence targetu není evidence absence defectu. 77. U každého FAIL uveď claim, evidence/oporu, impact, root-cause level a reproduction path. 78. Nejvýše 5 nejvýznamnějších reprodukovatelných findings; další rozhodovací nálezy eviduj jako subsidiary evidence. Žádná povinná oblast nesmí být vynechána. 79. Odděluj FINDING od HYPOTHESIS. Hypothesis není patch basis. 80. Self-test není independent validation. Agreement evaluators ≠ proof. FINAL OUTPUT 81. 1 EXECUTIVE VERDICT + právě jedna dominantní NEXT ACTION. 82. 2 BOOTSTRAP RESULT. 83. 3 ARCHITECTURE-LAYER / INTERFACE RESULT. 84. 4 LIFECYCLE / REGISTRY / TRACEABILITY RESULT. 85. 5 DEPENDENCY/SCOPE RESULT. 86. 6 STATE-MODEL RESULT. 87. 7 VERDICT/COVERAGE RESULT. 88. 8 CAPACITY / APSA / VOI RESULT. 89. 9 FAILURE-FREE DISCOVERY RESULT. 90. 10 EXTERNAL-RADAR RESULT. 91. 11 SELF-IMPROVEMENT / EVALUATOR RESULT. 92. 12 DRIFT / CHANGE / REVALIDATION RESULT. 93. 13 CONVERGENCE RESULT including whether advisory is justified. 94. 14 WHOLE-SYSTEM / INTEGRATION RESULT. 95. 15 TOP 5 FINDINGS. 96. 16 FINDING vs HYPOTHESIS. 97. 17 RELEASE/ITERATION IMPACT. 98. 18 NEED FOR REPAIR / NO-REPAIR. 99. 19 FINAL STATUS. TARGET-ABSENCE FINAL GATE 100. If M36 or Z36 is absent, invalid, stale, contradictory or not identity-bound, STOP target evaluation at intake. Do not reconstruct, do not patch unseen content, do not advance release/iteration state, and do not treat architecture/capacity/registry declarations in P17 itself as proof that M36 implements them. === M36 CLOSED-LOOP RECOMMENDATION ARCHITECTURE TEST PACK === A1. Ověř C87: vezmi všechna actionable doporučení z předchozího auditního/validačního stavu a vytvoř explicitní Recommendation Ledger s RID, source, scope, priority a disposition. Žádné doporučení nesmí zůstat jen jako poznámka. A2. Ověř C88: každé IMPLEMENTED/PARTIALLY-IMPLEMENTED recommendation musí mít přesný binding na C-ID/MC-ID/test/change a acceptance criterion. „Zapracováno“ bez locatoru je FAIL. A3. Ověř C89/C92: proveď pre-close reconciliation. Každé předchozí RID musí být IMPLEMENTED, PARTIALLY-IMPLEMENTED, DEFERRED, REJECTED, DUPLICATE nebo NOT-APPLICABLE; D/R/N-A musí mít důvod. Silent disappearance = FAIL/BLOCK. A4. Ověř C90 fault injection: vlož syntetické high-priority recommendation do previous-cycle ledgeru. Ověř trasu recommendation→disposition→implementation→validation→Z→next-P. Jakýkoli silent drop musí být rozpoznán jako control-plane failure. A5. Ověř C91/CLOSED-LOOP ACCEPTANCE: samotné uvedení doporučení v metodice není sufficient evidence. Musí být dohledatelná implementace a následný validation step nebo explicitní disposition. A6. Ověř C93: doporučení uživatele/auditora je input pro decision process, nikoli automaticky fact ani normativní command. Status nesmí být povýšen pouze zápisem do ledgeru. A7. Negative control: vytvoř podobné dvě recommendation records, z nichž jedna je skutečně implementována a druhá pouze zmíněna. Systém musí rozlišit IMPLEMENTED vs NOT-CLOSED/SILENT-DROP a nesmí obě označit jako splněná. A8. Pre-dispatch gate: bezprostředně před external issue porovnej Recommendation Ledger s M36. Jakékoli unbound actionable RID musí zablokovat dispatch. Po opravě disposition se gate musí otevřít bez přepisu historie. A9. Regression: porovnej M35→M36. Ověř, že nové controls nezrušily target-absence immutability, capacity-exhaustion, single-P, competitor no-Web boundary, ten-slot state model ani deterministic verdict precedence. A10. Whole-system challenge: simuluj doporučení, které má být podle evidence REJECTED, doporučení DUPLICATE a recommendation s kladným VOI. Ověř, že lifecycle a ledger udrží správné odlišné stavy a lineage.