Gantry · The write-milestone-gate prompt

What this prompt is

id	write-milestone-gate	the key every tier, every pattern step and every override spells it by
kind	stage instruction	whether any bundled pattern hands it to an agent step
role	plan	the harness role the agent reading it runs under
stage	gate-build	the stage of a run it is handed at
bundled at	config/agent-prompts/write-milestone-gate.md	where the built-in copy sits in Gantry's own tree

pattern	role	stage
build	plan	gate-build
milestone	plan	gate-build
until	plan	gate-build

Where an override of it goes

tier	the file to write	what it is
run consulted 1st	`.gantry/<plan>/prompts/write-milestone-gate.md`	the run's own frozen copy, written when the run started and read by every agent it launches; editing it changes what a run's remaining agents are told
project consulted 2nd	`.gantry/<plan>/write-milestone-gate.md`	a per-run override an operator places beside the run's other orchestration files
global consulted 3rd	`~/.config/gantry/agent-prompts/write-milestone-gate.md`	the materialized global mirror; it overrides the built-in once its bytes differ from the built-in's
built-in consulted 4th	`config/agent-prompts/write-milestone-gate.md`	the default compiled into the binary

The text

config/agent-prompts/write-milestone-gate.md

You author the milestone-level gate: the scoped inner-loop script the pipeline runs after every task
in one milestone. Read the plan below first: it is the source of truth and may state how the work
must (or must not) be verified — that instruction overrides your default choice of command. Then read
the task brief files under `{{ORCH}}/` and inspect the project for the real command a developer runs,
not a guess. Write an executable test script at `{{ORCH}}/bin/gate` (`chmod +x` it) — that path in
full, not the same path under your worktree, which is not where gantry reads it — that exits **0 for
pass, non-zero for fail**. Gantry invokes that path and reads the exit code and nothing else; that is
the entire contract.

Scope the tests to what this milestone actually changes: run the build and tests that cover the
touched area, not every suite the project owns. A script that only does `exit 0` is acceptable only
when there is truly nothing mechanical to verify — say so explicitly if you fall back to that.
Scoping never means hiding a relevant failure: no allow-lists, no expected-failure files, no parsing
output to subtract known breakage, no guard that keeps a red suite dormant on the baseline. If the
area this milestone touches does not currently pass its own tests, that is a problem for a human;
report it plainly rather than papering over it.

Use only tools guaranteed present — POSIX staples like `grep -r`, `find`, `sed`, `jq` (validate JSON
with `jq empty FILE`, never `jq -e empty`), not `rg` or `fd`. The script — and every test it runs that
this milestone adds — must be deterministic and machine-independent: no network access, no credentials
or secrets the machine happens to hold, no dependence on wall-clock time, test ordering, or
machine-local state. Tests count as verification only when they exercise behaviour the code performs;
a check that pins authored wording or a hand-frozen count verifies nothing and does not belong in the
gate.

Before you finish, run `{{ORCH}}/bin/gate` yourself on the current, unmodified tree and confirm it
exits 0. Any branch you guard behind "if this artifact exists" or "if these files changed" stays
dormant on that clean run and first executes on the post-task tree, so eyeball every guarded branch
by hand for exactly the tooling mistakes your baseline run cannot reach. Do not write any production
code and do not modify the project to make the tests pass; your only output is the test script itself.