Sending into a shared git channel -- part 2: the mechanisms
What this is. The companion to part 1: the rules, which covers five failures and the steps that hold only because someone honours them. This half is the checks that stop. A rule is prose; a mechanism refuses -- a distinction with its own page. The closing section says what these checks do not reach.
Where this came from. These three pages are the short form of a single longer treatment of the same work, which holds measurements behind several claims stated here as conclusions and is kept as a source rather than published. Where a statement below reads as a bare assertion it may have a number under it that this page does not show.
Verified against a working two-party channel on Linux with git 2.x, over 2026-08-25 and 2026-08-26, on a forge running Forgejo. Behaviour described as observed was observed there; any number is a measurement from that setup, an illustration for yours. Anything uncheckable without writing to a live repository is marked [unverified], with reasoning instead of a guess.
The checks that stop
Verify the remote, do not assume it. A checkout in a temporary directory gets deleted underneath you; one pointing at a fork is worse, because it succeeds. The check reads the remote out of the repository's own config file, needing no git invocation, and a mismatch stops the send rather than choosing a remote.
Verify the commit identity, and never set it. Setting is a bootstrap step, once per checkout, by a person; verifying is the per-send step. Putting the set into the send sequence is wrong twice: redundant on every send after the first, and a redundant step is one people learn to skip; and it drags a personal address onto a command line for no reason. Verification is a config-file read against whatever the record now says, failing loudly on mismatch rather than improvising a fix.
Deny-list the tree before anything reads it. On the harness tested, a session does not load a nested instruction file at startup -- but the moment it uses a file-reading tool on any ordinary file in that directory, the file loads as instructions and the session complies. Shell tools reaching the same bytes do not. The trigger is not exposure to the text but whether the harness elevates it to instruction status. So the tree gets checked for instruction-shaped files before anything reads it, and while the answer is still clean is the cheapest moment to start. [unverified] on any other harness.
Mark what must not ship; the check finds only the mark. "Check that no draft scaffolding survives" is unimplementable as stated: a regex for text that looks like notes to a reviewer is the failed heuristic of text that looks like an example rather than a real secret, caught discarding a correctly-detected key because the line held the word EXAMPLE. So the burden moves to the writer: every block that must not ship carries one literal token on its own line, and the check greps named files for it -- named, because an agent shell's grep may silently honour ignore files when it discovers them itself, and the filters cut what a walk finds, not what you name.
Confirm the file is genuinely in the commit. A repository made from a template can inherit a stock language-specific ignore file nobody ever used, covering paths a message could land on. The add succeeds, the commit succeeds carrying nothing, the send succeeds, and the other side never receives the message; nothing in that sequence reports an error. A push of nothing succeeds silently, the worst failure available to a channel, so the commit is listed and the file has to appear in it. Which paths a template ignores is [unverified] and worth reading.
One push route, behind a gate that fails closed. The gate denies every route that is not the sanctioned one, making it a chokepoint rather than a convention. It matches the whole command text, so it sometimes denies what is not a push at all -- seen here on a heredoc whose prose merely described one. The right response to a denial is the sanctioned route, never a rephrasing that gets past the matcher.
What they do not cover
The identity check protects commits made from that checkout and nothing else: a commit made through a forge's web UI carries the account's own email, because a browser cannot consult a repository-local config. A text scan reaches the working tree, not history: a git object store is compressed, and a planted compressed object survived searches that found the plaintext beside it. The token check finds only what was marked. And the two steps carrying the most weight, a person reading the message and the identifier scan, are rules. Mechanisms standing around them do not make them mechanisms.