behavior-validation

# Behavior Validation Judge what the product does, not how its source appears to do it. ## Establish isolation Write or read the behavior contract before exercising the target. Use [behavior-contract.md](references/behavior-contract.md). The contract must name user tasks, expected outcomes, setup, allowed interfaces, negative cases, and required evidence. Do not inspect source, diffs, internal tests, Git history, or implementation notes during validation. Interact only through public browser, CLI, API, artifact, accessibility, or operator surfaces. If source is required, mark the clause blocked and hand it to `root-cause-debugging`. ## Exercise the contract 1. Run each task through the same entry point a real user or operator uses. 2. Vary input and state to detect hard-coded success, stale data, or display-only behavior. 3. Test invalid, empty, interrupted, retry, persistence, and permission paths where the contract makes them relevant. 4. Capture redacted screenshots, terminal excerpts, response summaries, or artifact facts. 5. Mark every clause pass, fail, blocked, or out of scope. Lack of evidence is not a pass. When a finding is fixed, rerun the failed clause and nearby regression probes; do not rerun unrelated expensive scenarios without reason. ## Completion condition Every relevant contract clause has a status and reproducible evidence, anti-fake probes were attempted, secrets and private data were excluded, and the report does not infer implement...