Skip to main content

​
Gate Reference

Complete reference for all gate types, their behavior, and resolution.

​
Shell alias gates

These gates resolve to shell commands via a three-level cascade:
  1. Heuristic — Gump scans the worktree for project markers
  2. Config — gump.toml overrides (project-specific)
  3. Workflow — bash: gate overrides (step-specific)

​
compile

Runs the project’s build command.
MarkerCommand
go.modgo build ./...
package.jsonnpm run build
Cargo.tomlcargo build
requirements.txtpython -m py_compile
Override in config: 
[validation]
compile_cmd = "make build-affected"
Behavior: required. If the compile command can’t be resolved (no known project marker and no config), the gate fails with an error explaining what to configure.

​
test

Runs the project’s test command.
MarkerCommand
go.modgo test ./...
package.jsonnpm test
Cargo.tomlcargo test
Override in config: 
[validation]
test_cmd = "make test-unit"
Behavior: required. Same resolution as compile.

​
lint

Runs the project’s linter.
MarkerCommand
go.modgolangci-lint run
package.jsonnpm run lint
Override in config: 
[validation]
lint_cmd = "golangci-lint run --timeout 5m"
Behavior: optional. If the lint tool isn’t available, the gate is skipped silently. This allows workflows to include lint in their quality gate without breaking on projects where linting isn’t set up.

​
coverage: N

Runs tests with coverage and checks the result against a threshold. 
gate: ["coverage: 80"]
The coverage command is resolved the same way as test, with a coverage flag appended. The output is parsed for a percentage. If the percentage is below the threshold, the gate fails. Behavior: optional. Skipped if coverage tooling isn’t available.

​
Structural gates

​
schema

Validates that a plan step’s output is well-formed JSON matching the expected format. 
gate: [schema]
Checks: the output is a JSON array, each item has a name (string, non-empty) and a description (string, non-empty), files is optional but if present must be an array of non-empty strings. The gate reads from the state bag (not directly from .gump/out/plan.json).

​
touched: “glob”

Verifies that at least one file matching the glob was modified in the step’s diff. 
gate: ["touched: *_test.*"]
The glob matches on the file’s basename, not the full path. "*_test.*" matches pkg/auth/middleware_test.go because the basename is middleware_test.go. Uses Go’s filepath.Match (no recursive ** globbing).

​
untouched: “glob”

Verifies that no file matching the glob was modified. 
gate: ["untouched: *_test.*"]
The inverse of touched. If any file matching the glob appears in the diff, the gate fails. Used to enforce blast radius boundaries (e.g., the implementation step shouldn’t modify test files).

​
tests_found

Verifies that the test runner finds and recognizes tests to execute. 
gate: [tests_found]
Resolves the test command and runs it. If the runner finds tests (exit 0 or a recognized “tests found” output), the gate passes. If the runner reports “no tests found” or fails to start, the gate fails. This is different from test — tests_found doesn’t care if tests pass, only that they exist.

​
Custom gates

​
bash: “command”

Runs any shell command in the worktree. 
gate: ["bash: make integration-test"]
gate: ["bash: ./scripts/check-migrations.sh"]
Exit 0 = pass. Any other exit code = fail. Stderr is captured and injected as error context on retry.

​
Gate execution

Gates run in declaration order. All gates execute even if one fails (no short-circuit). The complete error context — every failure message — is available to the agent on retry. This lets the agent see all problems at once instead of fixing them one at a time. A gate step is considered passed only if every individual gate passes.