Gantry · The write-gate prompt

What this prompt is

id	write-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-gate.md	where the built-in copy sits in Gantry's own tree

pattern	role	stage
milestone	plan	gate-build

Where an override of it goes

tier	the file to write	what it is
run consulted 1st	`.gantry/<plan>/prompts/write-gate.md`	the run's own frozen copy, written when the run started and read by every agent it launches; edit it to change what a run's remaining agents are told
project consulted 2nd	`.gantry/<plan>/write-gate.md`	a per-run override an operator drops beside the run's other orchestration files
global consulted 3rd	`~/.config/gantry/agent-prompts/write-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-gate.md`	the default compiled into the binary

The text

config/agent-prompts/write-gate.md

You author the **tests** — the single script the pipeline runs after every sprint to decide, on
ground truth, whether the build is still good. 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 sprint 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 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 run 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 plan 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` — a script that dies with `command not found` reads as a red build.
The script — and every test it runs that this run 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 — intermittently failing tests
poison every later sprint, and are worse than a narrower one. 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 — gantry re-runs it on the clean tree the moment you finish and refuses to start if it is red,
so a forced pass only moves the failure one step later. 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-sprint 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.

{{PLAN}}