Making your repo agent-friendly

Last Light works on any repo — it does not depend on anything on this page. Its build and fix gates judge your test suite by exit code and run it under a budget you control. These habits just make those runs faster and the verdicts easier to read.

1. The test command exits non-zero on failure

The build workflow's guardrails gate runs your full suite once and reads only its exit code: 0 is READY, anything else is BLOCKED. A script that swallows failures (|| true, a wrapper that always exits 0, a watch mode that never exits) turns a broken suite into a green one — or a hang into a timeout.

2. Keep test logging quiet

When a gate fails, the agent diagnoses it from the tail of the log. If every test prints application logs, the summary and the failing assertion get buried. Default your logger to silent (or error) under test, and let a developer opt back in with an environment variable such as LOG_LEVEL=debug.

3. Size gate.timeoutSeconds to your real suite

One full build/test gate command gets gate.timeoutSeconds (900 by default). If your suite takes longer, set it in the repo:

# .lastlight/lastlight.yml
gate:
  timeoutSeconds: 1200         # our full suite takes ~14 minutes on a cold sandbox

The guardrails report records the command it ran and how long it took, so use that number plus some headroom. A repo value is clamped to the operator's gate.maxTimeoutSeconds (1500 by default) — see Per-repo config. A suite that doesn't finish in time is reported BLOCKED with "raise gate.timeoutSeconds", never retried with a bigger budget.

4. CI runs the same test command

Guardrails proves the suite is green before work starts, and CI checks the pull request after. If both run the same command (say, pnpm test), a green guardrails gate means the same thing as a green CI check — and a red CI run is something the agent can reproduce.