Part VII

Harnesses

Prefer Hooks + CLI for coding harnesses with local shell access. Use MCP for clients that cannot invoke local commands. Keep configuration in version-controlled files rather than copying a site's example into every repository.

The public integration outline below describes the lifecycle without requiring source access. Ready-to-use extensions and configuration assets in Table 7.1 require access to their source repository; signing into GitHub alone does not grant it. These links are optional implementation references, not a public setup prerequisite. Public binary distribution is still pending.

Setup and access prerequisites

Before installing an integration:

1. Obtain CNS and organ binaries through an authorized distribution path. The operator installation guide requires source/release access; this website is not a public binary installer.
2. Install the chosen coding harness separately. Ensure its command environment can find cns, axon, soma and engram, plus zsh and jq for cns. Set CNS_ROOT to the CNS checkout when using an installed CLI copy.
3. Run cns init --domain your-domain from the target Git repository. Review the authored Soma concerns and the generated OTE rather than treating scaffolding as certification.
4. For remote retrieval, configure an actual THALAMUS_URL or organ-specific endpoints and models. With no relay, init provisions local-only retrieval. Rubric gating is a separate explicit opt-in, not a requirement for local structural checks.

cns install-harnesses installs the CLI and organ binaries in ~/.local/bin/ and symlinks the Pi extension to ~/.pi/agent/extensions/cns.ts. It does not install Pi, configure Claude/Codex/Gemini, start the relay, or run cns init in target repositories. It invokes the binary installer, so release-asset access is required even when the extension itself is already available. Inspect the checked-in frontier assets: they include machine-specific executable paths and example relay addresses, not portable defaults.

Table 7.1 · Integration sources

Listing 7.1 · Minimal Claude Code edit hook

This single-hook example follows the checked-in Claude PostToolUse configuration, replacing its machine-specific executable path with cns from PATH. Merge the hooks entry into your existing Claude settings; do not overwrite unrelated settings. Run the harness from the initialised target repository and ensure its hook environment has the PATH and CNS_ROOT configured above.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|MultiEdit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "[ -f .axon/axon.db ] && cns hook axon post-tool-use -- axon index >/dev/null 2>&1 || true"
          }
        ]
      }
    ]
  }
}

After a matching edit, the hook refreshes an existing Axon index and records an axon/post-tool-use vitals row. If no index exists, it skips the command; it does not initialise a repository. Inspect cns status for the channel result. This is an index-refresh integration only, not a full memory lifecycle or a gate. The command shape is checked against bin/cns and harnesses/frontier/claude-settings.json; that source check is not a claim that your Claude installation has run it successfully.

Fig. 7.1 · The integration boundary

1. Orient: read Soma's maps and Engram's memory block.
2. Edit: incrementally refresh Axon's index through hooks.
3. Close out: run cns gate, preserving the distinction between failed and not evaluated.
4. Consolidate: run cns curate to refresh maps and memory.

Erratum 7.1 · Rubric evaluation is opt-in

Note 7.1 · Hooks do not certify a change

The hook wrapper records vitals and is fail-open for the harness. Its exit status is not a closeout verdict. Use cns status to inspect channel health and cns gate to evaluate the requested oracles.