failure-diagnosislisted

# Failure Diagnosis ## Purpose Replace speculative patching with an evidence-backed Root Cause Analysis and repair direction. ## Trigger Run after a meaningful failure when the responsible layer is uncertain, on regression or integration failure, or before a second broad correction attempt. ## Inputs - Expected/observed behavior, symptom, failing revision, reproduction, environment, logs, and reports. - Recent changes and last-known-good revision. - Relevant Requirements, architecture, detailed design, Contracts, interfaces, data, implementation, tests, and prior attempts. ## Prerequisites - Preserve original failure evidence before changing code/tests/environment. - Define the failure precisely enough to distinguish success from failure. ## Procedure 1. Observe and record the exact failure, scope, timing, revision, and environment. 2. Reproduce with the least invasive reliable method; record deterministic/intermittent status. 3. Build a timeline and compare failing behavior with last known good evidence. 4. Trace affected control, data, interface, and Contract paths. 5. Form multiple plausible hypotheses and identify discriminating checks. 6. Execute bounded diagnostics; falsify alternatives rather than confirming only the first theory. 7. Classify the responsible layer: Requirement, Architecture, Detailed Design, Contract, Interface, Data, Implementation, Test, Environment, or `UNKNOWN`. 8. Identify root cause, contributing factors, affected Artifacts/Components,