Stop 4 of 7

The gates

A gate does not advise. It returns a non-zero exit code and the action does not happen. This is the part of the harness that works when the agent is tired, the context is long, and the prose at the top of CLAUDE.md has stopped landing.

A commit meeting a gate

git commit → F004 passing

commit-gate.sh

main

The agent is not asked to reconsider. The tool call is denied, and the only way forward is to make the check pass.

Four hooks that block

These fire on Claude Code lifecycle events and can stop the action outright.

Hook	Event	What it enforces
`verify-task-quality.sh`	TaskCompleted	Tests must pass before a task may be marked complete
`commit-gate.sh`	PreToolUse (Bash)	The full suite must pass before a commit may flip a feature to `passing`
`enforce-scope.sh`	PreToolUse (Edit/Write/MultiEdit)	Edits blocked outside the agent's assigned scope, and to the three lead-owned state files regardless of scope
`verify-git-identity.sh`	PreToolUse (Bash)	Push and pull blocked when identity doesn't match `harness.json`

Why the task gate is not the full suite

This is the most interesting engineering trade-off in the harness, and it generalizes well beyond it. Running the whole suite on every task completion sounds strict. In practice it costs minutes per checkpoint, and — worse — it lets one unrelated red test jam every completion in the session.

So the gate is tiered:

What runs when a task is marked complete

✓smoke_test fast compile/syntax check, under 15 s

✓focused_test only this feature's own recorded test file

·full_test not here — runs at the commit that flips to passing, and at session end

The full suite runs where it actually decides something. And on a stack with no per-file runner, focused_test reports a skip — not a fake green.

.harness/init.sh [smoke_test | full_test | focused_test <test_file>]
# default target: full_test

Three reliability tiers

It matters which tier a rule lives in. Same rule, different tier, different compliance rate — and the tier is a design decision you make, not a property of the rule.

Mechanicalshell hooks, exit codes

Structuralfile existence, JSON schema

Promptedhooks with feedback — agent still decides

Instructionalprose in CLAUDE.md, rules, skills

Relative reliability, as the project describes it — very high for mechanical, high for structural and prompted, medium for instructional, where compliance drifts over long contexts. The bar widths illustrate that ordering; they are not measurements.

The harness's own TDD rule is the worked example. The exact discipline lived as always-on prose for a full measurement window, and buggy code still led the friction table at 33 %. What measurably moved the number was wiring TDD to a gate — the coverage threshold check and adversarial review. Hence the rule: if something matters enough to write down, it matters enough to enforce with a hook.

Where enforcement stops

The project states its own limits, and you should learn them early — knowing exactly which parts are exact is what makes them worth trusting.

Bash coverage is best-effort

enforce-scope.sh and commit-gate.sh inspect Bash commands by pattern — >, tee, cp, sed -i, rm. That is evadable by construction. The goal is stopping accidental drift, not defeating an adversarial agent. Edit/Write coverage is exact, because the tool reports the real target.

SessionEnd cannot block

The end-of-session discipline audit records gaps into SESSION_INCOMPLETE and surfaces them at the next session start. By platform design it cannot stop a session from ending with those gaps. Self-healing, not preventive.

Coverage is self-reported

The coverage gate compares the number a feature records against its target. Where there is no coverage tooling the stage skips; a feature that declares a target but records nothing is flagged rather than blocked.

Lead resumption is partial

If the lead session dies mid-run, completed agents' worktree branches survive and the run is resumable. The lead's own in-flight integration state is reconstructed from features.json and claude-progress.txt — not recovered.

Do not conclude

that a green task gate means the suite is green. It means smoke_test passed and that one feature's own test file passed. The suite is verified at the commit that flips the feature to passing, and again at session end.