The pre-dispatch gate

Four checks. Every one exists because skipping it drew an operator correction, and three drew seven or
more.

1. Direction currency - is this the CURRENT rail?

Measured: the operator restated one strategic directive near-verbatim three times (transition away
from Anny-only assets, MPFB-first), then had to catch the drift anyway - "Aren't you transitioning to
MPFB instead, why are you working on anny", "confirm that you're working on viseme on MPFB2 models
and not ANNY models", "put a pin in it" for stale Anny work.

• Before any asset/humanoid/room slice, grep the latest operator directives and active MADRs for the
  current rail. If the slice advances a deprecated one: pin it, re-scope onto the current rail.
• The cause is dispatchable-certainty bias - known files and writable contracts on the old rail
  keep winning selection. "I know how to contract it" is not a reason.
• A migration is not done until it is VISIBLE. "have you promoted mpfb2 - I don't see those
  humanoids in scenes". A transition claimed in coordination files without promoted assets is drift.

2. Prior art before authoring - the operator is not my scout

Twelve messages handed me a URL, a tool, or a review document for something I was building or
about to build: MakeHuman asset packs (skins, eyebrows, eyelashes, all packs), MPFB script samples and
the makehair thesis, MPFB community viseme support, meshoptimizer, a storybook harness, the
Mesh2Motion/Animato evaluation package, a room-realism review, Rapier + IWSDK.

Search these FIRST for any hair / skin / eyes / brows / lashes / clothing / viseme / animation / room
capability:

• MakeHuman asset packs: https://static.makehumancommunity.org/assets/assetpacks.html
• MPFB script samples: https://github.com/makehumancommunity/mpfb2/blob/master/script_samples/index.md
• meshoptimizer, for post-generation decimation - never gate early output on triangle count
• prior in-repo evaluation packages and MADRs, before any new bake-off

Record FOUND (with licence) or NOT FOUND in the slice record. If the operator hands me a URL for
something I was about to hand-author, that is a failed search - log it so the registry list grows.
The repo has a curious-researcher rule and it did not bind; a rule without a gate is prose.

3. Collision - is another writer on this surface?

"The other agent is working on clothing - you should avoid overwriting it's work", and "there was
work that grok did independently with infigen - check latest in codebase".

• Before touching a surface, check peer handoffs and recent commits on that lane.
• Claimed by another agent means take a disjoint lane, or coordinate through the handoff file first.
• Overwriting another agent's uncommitted work is unmergeable loss - this repo has already lost 40
  tracked files to exactly that.

4. Size to capability, not to the contract I already know how to write

"please take on this work through to completion - these smaller slices are inefficient", then
"Is it possible to take on bigger efforts each tick... I feel it understates your capabilities" - and
then the same correction again, near-verbatim. One repeat is a pattern.

• Default slice = the biggest coherent vertical the workers can carry with staged checkpoints.
  Staging mechanics live in grok-worker-monitoring section 3.
• If two consecutive slices could have been one, that was one slice. Log it.

5. The brief text itself - a sed-derived dispatch carries stale references

Measured 2026-08-25. I built #651's dispatch by sed-ing #652's script. The if (issue.number !== N) exit(1) guard - added after a dispatch once ran against the wrong issue - passed, because the NUMBER
was right. The payload was not: the appended brief still said

"The planted header in no-actor-can-be-cast-onto-the-anny-rail.test.ts is IMMUTABLE. Flip the two
it.fails..."

That is the PREVIOUS slice's landed, green contract, and #651's contract has ONE it.fails. A worker
following it would have edited the wrong file. Caught at 60 seconds; killed, corrected, re-dispatched.

The guard covered the address and not the letter. Third stale-reference incident from a copied
dispatch script.

The mechanical check, before every dispatch built from a previous one:

grep -o '[a-z0-9-]*\.test\.ts' <dispatch script> | sort -u

Every filename it prints must appear in this slice's done_when proofs. If one does not, it is a
leftover. Also count the it.fails clauses in the planted contract and check the brief's number
matches.

Better: assert it in the script rather than eyeballing it.

const planted = brief.proofs.find((p) => String(p).includes(".test.ts"));
if (!extra.includes(plantedBasename)) throw new Error("brief names a different test than the contract");

A brief that names the wrong artifact is my defect, and the worker has no way to know.

6. When the isolation guard fires, ask the CHEAP question first

Measured 2026-08-25. The guard failed a dispatch:

Worktree-bound worker leaked writes into the MAIN checkout despite the path deny:
.openclinxr/evidence/issue-297/landmark-comparison.json

I diagnosed it as REPO_ROOT = resolve(HERE, "../../..") — scripts rooting themselves at their own file
location, so a worktree-bound process running a main-rooted script writes to main. I counted 72 such
scripts and published it as the cause. It was wrong. The leaked change was a generatedAt
timestamp, and:

5fae7afd  10:42  fix(#297): landmark instrument refuses a disconnected surface

A peer lane committed at exactly that timestamp, touching that very instrument. My worker never went
near issue-297. The windows overlapped, and #344 already documents this detector answering
"did main get dirty during this dispatch's window?" while reporting "did THIS worker write to main?"

The order to work in, cheapest first:

1. What changed? git diff <leaked path>. A timestamp or a regenerated artifact points at a tool
   run, not a worker edit.
2. Was anyone else writing? — the question I skipped:

   git log --all --since="<dispatch start>" --until="<now>" --format="%h %ad %an %s" --date=format:"%H:%M"

   A commit inside the window touching the same area ends the investigation.
3. Was the file already dirty before the dispatch? Compare against a git status you took earlier.
4. Only then reach for a mechanism inside your own worker.

Search the board before filing. gh issue list --search on the guard's own wording found #344,
#51 and #34 already covering it. I nearly filed a duplicate carrying a wrong cause.

The general failure: I ran an expensive, interesting diagnosis and skipped a one-command check that
would have refuted it. A plausible mechanism you can describe in detail is not evidence — it is the
§1b fabrication shape wearing an engineer's clothes.

The gate, compressed

One line each, before every dispatch:

1. Direction - which current-rail directive does this advance? (cite it)
2. Prior art - which registry was searched, what was found?
3. Collision - which handoffs and commits were checked?
4. Size - why is this not two slices?
5. Brief text - if this script was copied, which filenames did I re-check? (§5)
6. On a guard failure - did I check for a concurrent writer before diagnosing? (§6)

Six answers is aligned. Six silences is drift on credit.