Change reaches CI, infrastructure or build output

CI, infrastructure or generated files touched, or a change too large to review.

Check scope-creepShip Check

Why it matters

Agents fix whatever stands between them and a passing run. If CI fails, they may edit the workflow; if a container will not start, they may change its resources. Generated files get committed because they were in the working tree. None of that was in the task, and it arrives mixed in with the change you asked for.

CI configuration decides what is checked before code ships and which secrets the pipeline can reach, so an edit there affects every future deploy. Infrastructure files can resize or replace running services when applied. And a change past a few hundred lines stops getting a real review from anyone, so whatever is wrong in it tends to ship.

Example

 jobs:
   test:
     runs-on: ubuntu-latest
+    continue-on-error: true
+    permissions:
+      contents: write
     steps:
       - uses: actions/checkout@v4
-      - run: pnpm test -- --coverage
+      - run: pnpm test -- --passWithNoTests

What it detects

• CI configuration changes, rated higher when lines touch run, permissions, secrets, env, if, continue-on-error, pull_request_target or write permissions.
• Infrastructure definition changes, rated higher when they touch replicas, privileged mode, images, resource limits, ports, deletion protection, 0.0.0.0/0, public access or instance sizes.
• Generated or build output committed to the repository.
• Changes over 400 lines across reviewable files (lockfiles, generated files and data files excluded), rated high over 1,200.
• Comment-only edits and pure version pin bumps, the kind Dependabot and Renovate make, are not reported.

What to do when it fires

Read CI and infrastructure edits line by line. Confirm no test, gate or approval step was removed and no new secret or permission was granted, and run a plan or dry run before applying infrastructure changes. If an edit was not part of the task, revert it.

Add generated paths to .gitignore and build them in CI. Split a large change into commits by concern, starting by separating refactors and formatting from behaviour changes.