Docs The Harness

The Harness

6 components. 9 gates. Zero shortcuts. Agent = Model + Harness.

Level 1: Process Rules

Agent remembers rules from AGENTS.md. Load-bearing for simple tasks, but fails when attention drifts.

Level 2: Visible Manifest (Guardian Pattern)

Before any mutation (commit, push, merge, rebase), the agent must present a DECISION POINT block, explain rationale, and wait for explicit approval. Invalid responses like "ok" and "continue" are rejected.

Level 3: Time-Window Approval

The commit-msg hook v5 verifies that a .git/COMMIT_APPROVED file exists, is less than 5 minutes old, and matches the commit message. No SHA256 tokens, no hash math. The agent writes this file only after user says "yes commit" in chat.

Level 4: Manifest Gate

Before a commit approval can be written, a manifest file must exist at .git/COMMIT_MANIFEST. The agent MUST write this file before running commit-approval.sh. This prevents committing without presenting changes.

Pre-Commit Gates (v8)

The pre-commit hook runs 9 checks before every commit:

The Harness Architecture

A harness is the mechanical infrastructure that enforces agent behavior. This project implements 6 harness components that turn "please follow the rules" into "you literally cannot break them":

Incident History

Three Rule 12 violations in 48 hours produced three levels of enforcement:

Honest Limitations

These gates create friction, not guarantees. The hooks enforce git operations, but cannot prevent the agent from generating tokens without presenting the manifest, interpreting ambiguous responses as approval, or pushing without asking. The human must stay alert.

Scripts Reference

Key scripts that enforce the workflow:

ScriptPurpose
commit-approval.shWrite commit approval (requires manifest, time-window checked)
edit-guard.shVerify file structural integrity
pre-flight.shCheck git state before editing
skill-gate.shVerify skills were consulted