Feature Deployment and Infrastructure Review

Feature: Deployment & Infrastructure Review

A Feature-Pages entry. This page explains the capability; it never redefines it — see Feature-Pages for the canonical/Wiki boundary statement that applies to every page in this pattern.

What it does

When a change alters how an application is deployed or run, the review looks further than a normal pass. It reasons about the changed lines together with the files that define and consume the same names, ports, keys, and settings, and reports an evidenced concern as an ordinary finding.

It reviews infrastructure and deployment changes. It does not guarantee that a deployment succeeds, and it does not replace Kubernetes validators, Terraform validation, CI/CD execution, runtime monitoring, or production deployment verification.

Why it exists

Deployment mistakes often hide between files: a port moved in application config while the probe still targets the old one, a token permission widened in a workflow, a resource renamed without a moved block. A reviewer who reads one file at a time misses them.

When it applies

Conditional and automatic — no invocation option. Both Skills. It engages only when the change alters a deployment behavior: rollout and availability, resource bounds, privilege or credential scope, wiring between a definition and its consumer, destructive or state-affecting behavior, failure gating, or the startup contract. A file type, path, or name alone never triggers it, so a comment-only or key-order edit stays silent.

Supported: Kubernetes, Helm, Argo CD, Docker, Terraform, Jenkins, and GitHub Actions configuration. Other technologies (Kustomize-only repositories, Pulumi, CloudFormation, GitLab CI) get the normal review only.

How it works

• Static inspection of the diff always runs and never waits on anything.
• Repository context — unchanged files that define or consume the same values — is read where available.
• Validation output you supply (for example a terraform plan the review could not safely run) is accepted only when it is recognizably the tool's output, names the target, identifies its Base or Head commit, and is complete. Otherwise it is a Context gap, never a clean result. Supplied output can support a finding but cannot by itself make it confirmed.
• DevOps validation tools are optional. Running a tool such as terraform validate or helm template is never required, and the review never waits on it. A tool runs only when it is permitted and safe: the command is the exact one your repository declares, it passes the usual safety checks, and it runs inside a verified isolation boundary. Being installed is not enough, and a command is never allowed or blocked just because of its name.
• Not every safe command needs your opt-in. When the environment already provides a verified sandbox, a safe command can run without any extra approval from you. Explicit trusted-host authorization (for your current invocation only) is needed only when no sandbox is available and you want the command to run on your own machine.
• Never run: infrastructure-mutating commands. apply, sync, push, install, and upgrade without a dry run are prohibited. Commands that depend on secrets, credentials, or external services are skipped under the same safety checks. The review stays read-only.
• When a tool can't run, static review continues and the review says so: the Validation section records the command as skipped or unavailable with the reason, never as a pass. A Context gap is added only when the missing evidence matters to a deployment concern the review actually raised; it is not added for every skipped command.
• Local vs GitHub API-only. local-code-review and repository-backed github-pr-review can use repository context and your supplied output. In the default API-only github-pr-review mode only the changed files are available and no tool can be executed; a concern that needs an unreachable file becomes a Context gap. You can still supply validation output for the review to check.
• Context gaps. When a concern needs unavailable evidence, the review says what is missing and what command or output would resolve it. A gap is never a finding, never raises severity, and never changes the Decision.

Important options / modes

None. Asking for extra attention on deployment safety adds depth; it is not required.

Not supported

No guarantee of deployment success; no reasoning about live cluster, cloud, registry, or Terraform state; no visibility into repository settings such as environment protection rules; no infrastructure mutation or dependency installation; no replacement for helm, kubeconform, terraform validate/plan, actionlint, or CI.

Example

Review my changes. I moved the app's listen port to 9090 in config; also
check the deployment. Terraform plan output for Head is below: …

Related features

Feature-Runtime-Validation-Evidence (the execution boundary this never relaxes) · Feature-Dependency-Tree-Inspection · Specialist-Depth-Review · Feature-Human-Reasoning-Checkpoint.

Canonical references

deployment-infrastructure-deepening.md · usage guide docs/features/deployment-infrastructure-review.md.