Real-script companion: worktree, tool gate, WAL, non-vacuous tests

This is the runnable companion to the day-05 LinkedIn video. It demonstrates where an instruction file stops and executable enforcement begins. It is a narrow example, not a complete security sandbox or a claim that every Claude Code route has been tested.

The boundary chain

1. A trusted launcher runs prepare_worktree.sh, which creates a fresh linked Git worktree. The agent does not choose the allowed root.
2. The launcher sets AGENT_ALLOWED_ROOT to that root and places claude_pretool_guard.py outside the worktree. On covered Claude Code PreToolUse events, it allows read tools, allows Write/Edit only when the resolved target stays inside the root, and exits 2 for an unreviewed route. It denies arbitrary Bash/PowerShell commands because regex inspection of a command string is not OS confinement.
3. claude_posttool_wal.py appends a small receipt after a successful or failed write. The trusted runner sets AGENT_RUN_ID and AGENT_WAL_PATH to an external, agent-inaccessible location. A post-tool hook records an action; it cannot reverse it.
4. Trusted CI runs the tests itself from the assigned worktree and writes reports outside the agent's authority. verify_evidence.py rejects zero executed tests, normal-suite failures, a deliberate fault that survives, stale reports, and missing WAL receipts relative to the runner's expected successful write-tool IDs. The deliberate fault must target a consequential project invariant.

Claude Code's hook reference documents PreToolUse blocking and exit code 2. It also says command hooks that cannot start or time out may let the call proceed. For a hard boundary, use managed hook deployment, test a deny canary on the actual runtime, and place sensitive files/credentials behind OS permissions or a sandbox the agent cannot change. A hook is a useful interceptor, not the only control. Git worktree docs explain checkout isolation; a worktree is not itself a security sandbox.

Example wiring

The exact command paths are deployment-specific. Put hook files and policy settings outside the agent-writable checkout or in managed policy. This is a template; check registration and timeout behavior on the installed version before relying on it:

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "*",
      "hooks": [{"type": "command", "command": "python3 /trusted-control/claude_pretool_guard.py", "timeout": 5}]
    }],
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{"type": "command", "command": "python3 /trusted-control/claude_posttool_wal.py", "timeout": 5}]
    }],
    "PostToolUseFailure": [{
      "matcher": "Write|Edit",
      "hooks": [{"type": "command", "command": "python3 /trusted-control/claude_posttool_wal.py", "timeout": 5}]
    }]
  }
}

The policy must also review other mutation routes, including MCP tools and shell, or deny them. If the hook has a missing path, times out, or is not loaded in a cloud/hosted surface, the script never gets to return exit 2. Scoped credentials and independent CI remain necessary.

Tests run here

test_harness.py exercises in-root and out-of-root writes, default shell denial, missing configuration, WAL writing, zero-test rejection, a surviving fault, stale reports and missing receipts. It passed locally on 2026-09-24. run_negative_control.sh ran a real two-test pytest suite against demo_policy.py, then deliberately changed the zero-test rule through an environment-controlled mutant: normal suite 2 passed, mutant suite 1 failed / 1 passed. The normal and deliberate-fault JUnit reports are preserved.

The shell worktree launcher created a real temporary Git worktree in a disposable fixture. Its cleanup was rejected by the host's automatic approval review as “blocked by policy”; the fixture was left in the OS Temp directory. This is not a deployed Claude Code hook test. The first real gate test still needs a harmless denied write in the installed Claude Code runtime, followed by trace and actual-file readback.

Why this is non-vacuous

pytest documents an exit code for no tests collected. Mutation testing checks whether an intentional behavioral fault turns tests red. A green test process alone is insufficient: verify the selected test count, report freshness, expected worktree, a relevant killed mutant and the independent business outcome. The demo mutant only proves the example gate catches its own chosen fault.

Commerce invariant harness: illustrative local experiment

This small runnable example accompanies the revised day-one Instagram, TikTok and LinkedIn videos. It uses SQLite and an in-process fake payment provider to exercise the test design. It does not establish PostgreSQL, Stripe or deployed-agent behavior. The PostgreSQL transaction documentation explains why a guarded competing update re-evaluates its condition; Stripe's idempotency documentation explains safe same-key retries and the possibility of key pruning after 24 hours.

Run python examples/commerce-harness/run_contract.py from the workspace root. The runner executes two independent contracts, then deliberately introduces (a) a false stock confirmation and (b) per-attempt payment rekeying. It accepts the run only if the normal contracts pass and both mutants fail. JUnit reports are in reports/.

The inventory contract starts with one unit, races two distinct buyer intents, requires exactly one successful reservation, then repeats the winning intent without consuming a second unit. The payment contract drops only the first provider acknowledgment after capture, retries, checks that the same key was sent, simulates key pruning, and requires reconciliation to leave one capture on the provider ledger.

In a real agent workflow, the trusted runner, acceptance contract, reports and service credentials must live outside the agent's writable worktree. A protected service or database role should own raw inventory writes and direct provider calls; feature code receives only the guarded API. A PreToolUse hook can deny covered route violations, but it is not a filesystem or network security boundary. The independent CI job checks the consequential outcome and a selected negative control. This local fixture demonstrates the logic; it has not been run through a real PostgreSQL/Stripe integration or a deployed product hook.