harness-feedback

# Harness Feedback Treat "the harness is too strict" as an engineering finding, not as permission to disable a safety check. Find the boundary that owns the mismatch and move the check to the narrowest profile that actually needs its evidence. ## Profiles Use these profiles unless the project has a more specific, documented contract: | Profile | Purpose | Typical blocking checks | |---|---|---| | `staging-smoke` | Fast proof that the changed build starts and the critical path works | build, focused regression, one stable smoke/contract check | | `security-proof` | Prove an adversarial or trust-boundary claim | hostile tests, source/collector proof, fresh-context evaluator | | `release-attestation` | Prove the exact releasable artifact and its identity | signing, Authenticode/tool identity, installer/package checks | | `nightly-stress` | Find intermittent and capacity failures | race, stress, AV/OS matrix, long-running evals | `staging-smoke` must not require signing, production credentials, a release certificate, or a long VM stress run. `security-proof` may run on an unsigned staging build when its claim is source or runtime behavior. A release check may remain blocking for release promotion without becoming a per-edit gate. ## Feedback Loop For every overload signal, record: 1. requested profile and change boundary; 2. gate that blocked or dominated the run; 3. command, elapsed time, failure count, and evidence actually produced; 4. whether the gate was relevant, du...