Agent Change Gate

Agent Change Gate

Treat an agent-generated change as a candidate patch, not as proof of completion. Decide whether the exact revision satisfies its intent without creating hidden regressions, unsafe expansion, or unverifiable claims.

Review is read-only by default. Do not edit the patch, post comments, approve, merge, push, rerun external jobs, or trigger deployment unless the user explicitly authorizes that action.

Freeze the review object

Resolve before analysis:

• exact repository, base revision, head revision, and diff range
• dirty or untracked work that is outside the candidate change
• originating issue, task, specification, and acceptance criteria
• author-reported commands, tests, scans, limitations, and environment
• generated files, vendored code, lockfiles, migrations, and deployment artifacts in scope

Do not review the working tree as though every visible change belongs to the agent. If the base, head, or ownership of changes is ambiguous, return a hold instead of guessing or cleaning user work.

Author logs and self-review are useful provenance, but they are claims until reproduced or supported by independent artifacts.

Build the intent-to-diff ledger

Trace both directions:

1. For each acceptance criterion, identify the implementing code path and the evidence that would prove it.
2. For each changed hunk, identify the criterion, invariant, or necessary support work that justifies it.

Flag:

• Uncovered intent: a requirement has no implementation or proof.
• Orphan change: a hunk has no task-relevant justification.
• Hidden contract change: behavior, API, schema, permission, default, or operational semantics changed without being declared.
• Evidence gap: implementation exists but the selected check cannot discriminate correct from plausible behavior.

Do not infer that a passing test covers a criterion merely because both mention the same function or feature.

Map risk before reading line by line

Use the diff to identify surfaces where a small change can have a large consequence:

• authentication, authorization, tenancy, secrets, privacy, and auditability
• persistence, migrations, serialization, caches, queues, retries, and concurrency
• public APIs, schemas, protocols, compatibility, and versioning
• dependency manifests, lockfiles, build scripts, CI, packaging, and generated outputs
• external calls, filesystem effects, infrastructure, feature flags, and deployment paths
• error handling, fallback behavior, resource limits, observability, and rollback

Expand context around high-risk hunks: inspect callers, callees, data producers and consumers, boundary validation, related tests, configuration, and deleted code. A diff can look locally correct while breaking an upstream or downstream contract.

Keep review depth proportional to risk and change size. Do not spend the evidence budget on formatting while a migration, permission check, or dependency boundary remains unexamined.

Look for agent-specific failure patterns

Check whether the patch makes validation easier to pass rather than making behavior correct:

• weakened or deleted assertions, fixtures, types, lints, scanners, or approval gates
• tests rewritten to mirror the implementation instead of the requirement
• broad exception handling, silent fallbacks, hardcoded success, or mocked-away boundaries
• hand-edited generated files without changing their source
• unrelated lockfile churn, new dependencies, copied code, or expanded permissions
• ignored failures, skipped checks, reduced coverage, or configuration that disables enforcement
• user-visible claims not supported by the actual code path

These are investigation triggers, not automatic guilt. Confirm the behavioral consequence before reporting a blocker.

Select independent verification

Independence means the gate obtains evidence separately from the author narrative; it does not require a different model.

• Re-run the smallest authoritative checks from the declared working directory when the environment permits.
• Add or select a negative, boundary, or counterexample case that would fail under the likely wrong implementation.
• For a regression test, establish that it detects the prior failure using an isolated checkout, reversible comparison, or existing failing evidence; do not alter the reviewed worktree merely to prove this.
• Verify generated artifacts through their generator and source-of-truth check.
• Treat existing green CI as revision-specific evidence only after confirming it ran on the reviewed head with relevant jobs enabled.
• Distinguish not-run, passed, failed, flaky, blocked-by-environment, and inherited-from-author results.

Do not silently install dependencies, access secrets, start paid services, change external state, or broaden network access to complete verification. Mark the resulting limitation and decide whether it is material to the gate.

Check security and dependency impact

Use available project scanners when relevant, but do not treat scanner silence as a security review.

Inspect changed trust boundaries for:

• missing authorization or object ownership checks
• unsafe parsing, injection, path traversal, deserialization, or command construction
• sensitive data in code, fixtures, logs, URLs, telemetry, or error messages
• new packages, versions, registries, install scripts, licenses, and transitive reach
• insecure defaults, widened network or production access, and weakened sandboxing
• dependency behavior that differs between manifest, lockfile, and runtime

Report only claims supported by the repository, reproducible behavior, authoritative advisories, or scanner output tied to the reviewed revision.

Produce high-signal findings

Each finding must include:

• severity based on reachable consequence, not stylistic preference
• file and location or a precise behavior path
• violated requirement or invariant
• concrete failure scenario
• evidence already observed and the smallest verification that would settle uncertainty
• whether it blocks the gate

Cluster duplicates and omit speculative comments that cannot change the decision. If no actionable defect is found, say so and list material areas that remain unverified.

Return the gate

Use one verdict:

• PASS: every acceptance criterion is mapped, required checks pass on the reviewed revision, high-risk surfaces were examined, and no material evidence gap remains.
• HOLD: the change may be correct, but revision identity, requirements, environment, ownership, or decision-critical evidence is missing.
• BLOCK: an observed defect, regression, security issue, unjustified scope expansion, or failed required check makes merge or release unsafe.

Include the reviewed base/head, intent-to-diff coverage, commands and results, findings in severity order, unverified risks, and the minimum next action needed to change the verdict.

A PASS verdict is analysis, not authorization to approve, merge, publish, or deploy. If the user separately requests remediation, fix only confirmed findings, rerun the affected gate, and preserve the original review evidence.

Completion criteria

The gate is complete only when:

• the exact candidate revision and user-owned changes are distinguished
• every requirement and changed hunk has a traceable disposition
• verification includes at least one decision-relevant case independent of author claims
• security, dependency, generated-file, and enforcement changes were checked when present
• findings are reproducible and prioritized, or the absence of findings is stated without overstating coverage
• the verdict follows the evidence and does not perform the merge or release action