Gates

A gate decides whether a workflow may advance. Its result must refer to the actual artifact under review. It needs enough evidence to explain a pass or a failure. It may instead request a human decision.

Match The Gate To The Question

A script can check whether saved steps retain their order. A model reviewer can look for requirement gaps that are difficult to express as assertions. A person can decide whether the result meets a product need. Describe an automatic transition that applies no check as exactly that.

Model judgments remain fallible. Require concrete findings and inspect their supporting evidence. Combining two model opinions does not turn the result into a deterministic proof.

Rank Gates By Reliability

Quality gates come in four kinds and the order matters. A deterministic check such as a test suite or a type check gives the same answer every time. A model acting as judge covers fuzzy questions a script cannot express. Human in the loop review of AI output covers taste and product calls. An automatic pass applies no check and suits only low-risk steps.

Prefer the most reliable kind the question allows. A judge can also route work instead of passing or failing it. It might send an unclear bug report to a triage stage rather than to implementation.

Record An Auditable Result

An auditable result records the run and stage it belongs to. It identifies the artifact under review by tested revision or content hash. It records the exact command that ran and its actual exit code. It also records the resulting status, plus a log location and a timestamp. The runner records that real exit code; agent prose saying the tests passed cannot substitute for it.

Handle Missing Evidence Explicitly

A timeout or missing dependency is not a pass, nor is an unreadable result. It may call for an environment repair or human decision instead of another code change. Preserve the reason so the next attempt starts with a useful diagnosis.

Approval applies to a particular artifact. If the patch changes after review, invalidate the approval and repeat the affected checks. The approval operation should confirm both the run's current state and the artifact being approved.

Write A Checkable Objective

A goal describes the result a task must reach. A stop condition tells the surrounding workflow when to finish or pause for a decision, and when to end an unsuccessful attempt.

“Finish the app” leaves the boundary unclear. The objective should name the deliverable and relevant requirements, plus evidence of completion. Budget and authorization boundaries belong alongside it.

Goal Commands Are Tool Features

Codex documents a /goal command for attaching a persistent objective to a chat. It offers controls to view and edit the objective, and to pause, resume, or clear it. This is a product feature rather than a universal slash command shared by all agents.

Use the documented controls and a task file or external runner to maintain the objective in Claude Code or another application. A custom course command or plugin may provide additional behavior; inspect that implementation before relying on it.

A goal declaration does not prove completion or grant additional permissions, nor does it replace a runner's limits. The same artifact checks apply regardless of how you started the task.

Distinguish Completion From Exhaustion

A run that reaches its budget with unfinished work should report that limit and preserve the next action. A run waiting for a product decision should state the decision. Neither outcome belongs in the same state as a verified result.

Pausing also needs defined behavior. Does the current process stop immediately or finish its stage? How does it reconcile its output on resume?

Exercise 10: Prove A Quality Gate Can Say No

Choose one check in a working project, such as its test suite or type check. Write a script that runs it and records the revision, the exact command, the exit code, the status, and a timestamp.

Run it three times. Clean code should produce a pass. Code with a deliberate error should produce a fail. For the third run, remove a dependency or force a timeout so the command never starts. The script must record it as did not run rather than as a pass. Store each record next to the revision it tested so the result can be checked later.

September, 2026