code-as-harnesslisted

# Code as Harness Choose the smallest executable evidence gate that can falsify the requested completion claim. Keep ordinary changes fast, while making recurring workflow failures and high-risk delivery paths durable and observable. ## Classify once Use the highest matching tier: | Tier | Typical scope | Required evidence | |---|---|---| | `L0` | read-only analysis; non-executable wording/docs-only change with no contract impact | inspect the relevant source or diff | | `L1` | localized implementation affecting one owner or behavior path | one focused check that exercises the changed behavior | | `L2` | multi-file feature; public API/format; shared module; cross-component fix | affected tests plus relevant type/lint/build or quick governance | | `L3` | release/deploy; migration; security; persistence/schema; governance-engine change; DSH Desktop delivery | project-mandated full gate once the tree is stable, then required attestation/runtime evidence | Project and higher-priority rules can raise the tier. Never lower an explicit delivery protocol. ## Establish the acceptance boundary - State the requested behavior and one observable success condition before editing. - For L2/L3, inspect the actual owner, repository contract, and native commands. - Diagnose a repeated issue only after evidence shows the same failure pattern. Wording such as “again” or “every time” is a prompt to inspect history, not proof by itself. - Classify confirmed recurrence as an implementation h