Deployment Check

Triggers automatically when relevant; invoke directly with /deployment-check or ask, e.g. "check the deployment".

You've been invoked because a change touched deployment-sensitive files. Before declaring the task done, run through all four checks below in order. If anything fails, fix it and re-run that check (and any downstream checks) until it passes, then show the user proof.

Step 0 — Orient yourself

Before running checks, answer these questions by reading the project files:

1. Compose file location — look for docker-compose.yml, docker-compose.yaml, docker-compose.prod.yml, etc. in the project root and subdirectories.
2. Health endpoint — check docker-compose.yml for healthcheck: stanzas, README for a /health, /status, or /ping route, or any framework-specific health URL. If you can't find one, ask the user before continuing:

   "I couldn't detect a health endpoint in the project. Is there one? (e.g., /health, /status, /ping) Or should I skip the health check for this project?"

3. Services to check — list all services defined in the compose file.
4. Secret patterns — collect any known env var names from .env.example, docker-compose.yml, or README that should never appear in output (e.g., passwords, API keys, tokens, secrets).

Check 1 — Docker build

docker build . 2>&1 | tee /tmp/docker-build-output.txt
echo "Exit code: $?"

If a specific Dockerfile path or build context is used in the compose file, mirror that:

docker build -f path/to/Dockerfile ./context 2>&1 | tee /tmp/docker-build-output.txt

Pass criteria:

• Exit code 0
• No lines containing ERROR, failed, or error: (case-insensitive) in the output (ignore expected strings like "Successfully built")

On failure: Read the error, fix the root cause in the Dockerfile or build context, then re-run Check 1. Don't proceed to Check 2 until this passes.

Show proof: Print the last 10 lines of build output + the exit code.

Check 2 — Compose up and container log inspection

# Bring up all services in detached mode
docker compose up -d 2>&1 | tee /tmp/compose-up-output.txt

# Wait for containers to stabilise (adjust if healthchecks have longer intervals)
sleep 5

# Capture logs from all services
docker compose logs --no-color 2>&1 | tee /tmp/compose-logs.txt

# Check container statuses
docker compose ps

Pass criteria:

• All services show status running or healthy in docker compose ps
• No lines in logs matching: Error, FATAL, panic, exception, Connection refused, failed to connect, OOMKilled, Exiting, exited with code [^0] (use case-insensitive grep — false positives in application debug logs are OK to note but not to fail on if the service is running)

On failure:

• Check which service failed: docker compose ps and docker compose logs <service>
• Fix the root cause (config, missing env var, port conflict, etc.)
• Run docker compose down then re-run Check 2 from the top

Show proof: Print docker compose ps output.

Check 3 — Health endpoint returns 200

Use the endpoint discovered in Step 0. The default port is typically mapped in the compose file under ports:.

# Wait a moment for the app to fully start
sleep 3

# Replace HOST, PORT, and PATH with discovered values
curl -s -o /dev/null -w "%{http_code}" http://localhost:<PORT>/<health-path>

Pass criteria: HTTP status code is 200.

On failure:

• Check if the container is actually running: docker compose ps
• Check logs for startup errors: docker compose logs <service> --tail 50
• If the app needs more startup time, retry up to 3 times with sleep 5 between attempts
• Fix the root cause, restart with docker compose restart <service>, re-run Check 3

Show proof: Print the curl command used and the status code returned.

If no health endpoint exists and the user confirmed to skip: note this explicitly in the final summary.

Check 4 — Secrets and .env leak detection

This check has three parts.

4a — Build output scan

grep -iE "(password|secret|api.?key|token|private.?key|auth.?key)\s*[:=]\s*\S+" \
  /tmp/docker-build-output.txt /tmp/compose-logs.txt && echo "SECRETS FOUND" || echo "Clean"

4b — Committed files scan

Check whether any .env files (not .env.example) are tracked by git:

git ls-files | grep -E "^\.env$|^\.env\." | grep -v "\.example$|\.sample$|\.template$"

Any result here is a hard failure — .env files must not be committed.

Also scan recently modified files for hardcoded secrets:

git diff HEAD --name-only | xargs grep -lE \
  "(password|secret|api.?key|private.?key)\s*[:=]\s*['\"][^'\"]{8,}" 2>/dev/null

4c — Docker image layer scan

# Check if any secret-like strings baked into image layers
docker history --no-trunc $(docker compose images -q | head -1) 2>/dev/null | \
  grep -iE "(password|secret|api.?key|token)" | head -20

Pass criteria:

• 4a: No matches in build output or logs
• 4b: No .env files in git index; no hardcoded secrets in modified files
• 4c: No secret-like strings in image history

On failure:

• 4a/4c: Identify the source (Dockerfile ARG/ENV, app startup log, etc.) and remove the value from the image build chain. Secrets should come from runtime env, not image layers.
• 4b .env committed: Run git rm --cached .env, add to .gitignore, amend or new commit. Rotate the secret immediately — it's now in git history.

Show proof: Print the output of each scan command.

Final Summary

After all checks pass, report to the user:

✅ Deployment Check — All Clear

Check 1 · docker build          PASSED  (exit 0)
Check 2 · compose up / logs     PASSED  (all services running)
Check 3 · health endpoint       PASSED  (HTTP 200 at <url>)
Check 4 · secrets scan          PASSED  (no leaks detected)

Safe to ship.

If any check was skipped (e.g., no health endpoint), say so explicitly with the reason. If you couldn't run Docker checks (e.g., Docker not installed or not available in this environment), say so and list which checks were skipped — don't silently pass them.