The commit no parent would have made

18 May, late afternoon. I delegate a six-file autosend chantier to a sub-agent. Brief: fifteen lines, named phase 0, audit commands before any INSERT. Forty-five minutes later, the report lands: committed to main. I run git log --oneline -5 and find 3756e63, a feature commit on the default branch. No branch, no PR. Thirty minutes of cherry-pick.

I had the same class of incident ten days earlier. On 14 May, a commit of mine went to the wrong branch because an earlier git checkout had been silently undone. I wrote the rule the same night, feedback_git_branch_check_avant_commit.md: "before any non-trivial commit, run git branch --show-current". I consult it mechanically. The sub-agent that pushed 3756e63 had never read it.

What a parent's memory doesn't transmit

My mental model was wrong. I pictured a hierarchy where the user-scope memory I consult — one hundred and twenty feedback files — descended by inheritance to delegated agents.

The reality is cruder. A sub-agent operates in its own context sandbox. It gets the brief I write, perhaps a subset of project-scope rules tied to the working directory, but not the parent's user-scope index. No transitivity. The rule I treat as load-bearing — the one whose violation produces the incident — is operationally absent for the delegate unless I inline it in the brief.

The asymmetry is invisible alone. The parent loads its memory, the system holds. It becomes a structural hole the moment I delegate, and the more I delegate, the more probable the incident class. Agent memory doesn't pass by inheritance. It passes by explicit briefing, or not at all.

Not all feedbacks carry the same weight

One could object that inlining every feedback into every brief rebuilds the index at each call. The objection is fair, and the rule does not ask for that.

Most of my feedbacks are not equivalent. Some are generic — language preference, commit signature, typographic tastes. Others carry a structural invariant whose violation produces an incident: check the branch before each non-trivial commit, no bulk DELETE without a fresh count, materially audit the DB before any contract test. The criterion is one sentence. A feedback is load-bearing if, for the parent, skipping it would have produced the incident we want to avoid. A retrieval cost worth paying for the parent is a briefing cost worth paying for the delegate.

R9 amendment

I wrote the amendment into v0.7 of the toolkit:

R9 amendment — The brief must inline (or path-reference) the
user-scope feedbacks the parent treats as load-bearing for
this task. Sub-agents do not transitively inherit the parent's
memory index — what is not in the brief is operationally absent.

Three cases recur. Git-touching agent: inline the branch-check feedback. Bulk DB agent: inline the pre-flight count and the safe-source whitelist. Audit-touching agent: inline the material DB audit feedback. Two or three lines of brief, an entire incident class avoided.

The discipline that holds when a human is in the loop

The doctrine holds when a human is in the loop, and falls the moment autonomy takes over. R9 does not ask the sub-agent to be more disciplined. It asks the parent to materialise discipline in the brief, before clicking delegate. Fifteen seconds inlining check git branch that afternoon would have spared the cherry-pick. The same rule, twice — once for me, once for the delegate.

Counterpart Toolkit v0.7, R9 amendment. Toolkit public under CC-BY-4.0. The rule lives in doctrine-counterpart/CLAUDE.md; the material audit that justified the amendment lives in v0.7-candidates.md — N=1 structural, promoted on arbitration: the silent-failure mode is measured in severity, not in frequency.