# Harness integration guides Objective Guard is a continuous-verification runtime for coding agents. It runs as a local CLI (`oguard`) plus harness hooks. The CLI behaves the same everywhere; what changes per harness is which events exist, what payload the hook receives, and where the hook configuration lives. One guide per harness. Each guide covers only the integration: how to wire the hooks, how to prove they fired, and what the harness cannot observe. First-run setup — installing the CLI, opening the first round, reading the contract — lives in [../getting-started.md](../getting-started.md) and is not repeated here. For the level model behind the loop (level 0 per edit, level 1 per turn, level 2 at close), see [../product/04-technical-architecture.md](../product/04-technical-architecture.md). The documentation entry point is [../README.md](../README.md). Spanish counterpart: [README.es.md](README.es.md). ## Available guides | Guide | Use this when | | --- | --- | | [Claude Code](claude-code.md) | You edit through Claude Code's structured `Edit`/`Write` tools and want the `PreToolUse` gate to deny mutations until `task-flow` returns `ready`. | | [Codex](codex.md) | You edit through Codex `apply_patch` and want per-patch detectors plus the same pre-edit gate and prompt injection. | No other harness is integrated in code today. Cursor, Gemini CLI, Copilot and Aider have no hook script, no test, and no configuration example in this repository. Do not document them until the wiring exists. ## The contract every guide must satisfy Use these seven H2 headings, in this order, with no additional H2 sections: ``` ## What this integration gives you ## Requirements ## Install ## Verify the integration ## The loop in practice ## What the harness cannot see ## Troubleshooting ``` Content rules: - **What this integration gives you** — three to six bullets. Each names a concrete capability (edit-time detectors, pre-edit preflight gate, prompt injection of `task-flow`, round evidence, sanitized telemetry) and states what that capability does not prove. - **Requirements** — the Node version from `package.json#engines`, a Git repository, and the harness capabilities the code actually depends on. Do not invent a harness version number the code does not imply. - **Install** — copy-pasteable commands and the real configuration file path the harness reads, with the hook configuration as a fenced JSON block. Say explicitly whether that configuration is user-level or project-level. - **Verify the integration** — commands whose output observably proves the hook fired, plus the test file that covers the same wiring. - **The loop in practice** — one fenced block with the normal sequence, then one line of prose per step. Keep it sequential and short. - **What the harness cannot see** — the honest limits. At minimum: the gate only inspects structured tool payloads and does not classify writes performed inside shell commands; a repository with no contract is not blocked; a `ready` authorization is cached against the contract hash and expires; telemetry is sanitized and proves usage, not benefit. - **Troubleshooting** — a table of symptom, likely cause, and the command that shows the truth. Two rules override style preferences. Every command in a guide must exist in the code — prefer `node src/cli.mjs ` for in-repo usage and `oguard ` once the CLI is installed, and say which is which. And never overclaim: a passing guard means only that the checks in scope found no violation, not that the objective was met. ## Adding a new guide 1. Copy [_template.md](_template.md) to `docs/guides/.md`. 2. Keep the seven H2 headings and their order. Replace every `TODO` with something you verified in the harness's own hook script, or delete the claim. 3. Add a Spanish counterpart at `docs/guides/.es.md` — same structure, same commands, translated headings. 4. Add a row to the table above (and to the table in `README.es.md`) with a one-line "use this when". 5. Run `npm run validate:docs`. It checks documentation topology and every relative link.