What I Kept After Turning Off the Gate

On the Windows PC I created the kill-switch file and backed up the settings so I could inspect the gate again. On the Mac I deleted the hooks and the policy document.

What Prompted Turning It Off

After the main session moved to a newer model, the gate tripped less often and for different reasons.

With the earlier model, a trip usually meant the session had started editing files directly, reached the limit, and then delegated. The newer model generally delegated large tasks without reaching the limit, so the gate mostly confirmed behavior that had already changed.

The remaining trips were mainly false positives: touching one code block while editing a document or changing a single configuration file. Delegating each small change added more overhead than the gate prevented, and I used the kill switch almost as often as the gate fired.

What I Deleted and What I Kept

I deleted the three hooks and the policy document. The edit counter, the Bash block, the size gate, and the kill switch went with them. I removed the hook wiring from the settings and swept the settings files and project documents for leftover references. I also deleted the orchestration-contract section in CLAUDE.md. If the contract text stays while the enforcement is gone, a later session can mistake it for a rule that is still in force.

I kept the three agent definitions. They are still sitting in ~/.claude/agents/ on the Mac.

deep-reasoner.md
default-worker.md
task-worker.md

I continued to use the role split after removing enforcement. I handed hard judgment calls to an agent strong at reasoning and mechanical work to a lighter model. Now I call each agent only when I need it.

The review method stayed too. I had attached a different-lineage review to risky changes several times, and I kept using the same method after removing the rule.

On the Windows side I turned things off instead of deleting them. I appended .disabled to the names of the agent definitions and the policy document, and for the hook scripts I left the names alone and removed only the wiring from the settings. When I want to check the decision order again, I open those files.

If I Built It Again

If I built the same thing again, I would first record the count and size of main-session edits without blocking them. I could then set a threshold after finding where repeated edits actually occur, reducing the trial and error of starting at 100 lines and later raising the limit to 400.

A recording hook only needs to append observations. The blocking verdict, fail-closed parsing, and shared counter lock were required by enforcement, not measurement.

Today I would collect records for a while and enforce only the problems that recur. In the first implementation, I guessed at the problem, made the rule first, and tuned the threshold later.

I also set conditions for considering enforcement again: repeated rule violations or work where a violation is expensive. I would reconsider a hook for data that is hard to delete or commands that are hard to undo. For this gate’s goal of reducing conversation context, I would first record the editing behavior and confirm that the pattern recurs.

The Working Method That Remained

The remaining method is to split a large task by role before implementation and attach an independent review to risky code changes. Once that became routine, the enforcement machinery no longer changed the workflow.

References

• Claude Code hooks
• Claude Code subagents