harness-quality-gate

Run the gate with --mode full --label scheduler before the single commit, using the absolute invocation from docs/harness/measured-gates.md. Inside an implementation lane, use --mode local --label <lane-id> instead.

Exit 0 means pass or breaches only in observe-mode metrics. Exit 1 means a blocking metric is red or a threshold was loosened without a recorded reason. Exit 2 means the gate itself could not run, which is a harness blocker, not failing code.

Propose bootstrapping it at Phase A, where everything except regression_suite is set to observe. Never block a project that has never measured itself, but never call it green either — missing reports route to the full review tier.

No. The gate never edits thresholds directly. If a metric beats its threshold on three consecutive runs, it proposes raising the threshold to the lowest of those three, but the change requires the recorded process in quality-decisions.md.

Use the gate for per-change, binary pass/fail decisions before commits or lane returns. Use the snapshot for per-milestone, qualitative scorecards; its evidence rows cite the latest gate report rather than re-deriving metrics.