# Deployment Hotfix Safety Guide

Use this reference for repo-side deployment hotfixes involving manifests, release parameters, environment wiring, deployment groups, pipeline inputs, rollback blockers, or emergency config correction.

## What people get wrong

The lazy story is:

> Hotfix means speed matters more than process.

Wrong. Hotfixes need less surface area, not less discipline. The fastest unsafe diff is how incidents become outages.

Common bad assumptions:

- Emergency context justifies broad config changes.
- A successful validator means production is safe.
- Rollback is obvious because Git has history.
- Deployment parameters are not security-sensitive.
- Temporarily disabling checks is acceptable if we re-enable later.
- The deployment tool will catch blast-radius issues.

## Hotfix risk classes

Classify the patch before editing:

- **Parameter fix:** wrong environment, ARN, image tag, feature flag, or region.
- **Manifest/schema fix:** invalid YAML/JSON/IaC shape blocking deploy.
- **Rollback unblocker:** restore previous deployment path or remove a bad forward-only change.
- **Guardrail fix:** re-enable alarm, approval, rollback, or validation control.
- **Risky workaround:** disables checks, widens permissions, changes traffic, or hides evidence.

Only the first four are normal for this skill. The fifth needs explicit risk acceptance.

## Minimum safe workflow

1. State the failed deployment symptom and evidence source.
2. Identify the exact file/field causing the blocker.
3. Make the smallest diff that corrects only that blocker.
4. Preserve or improve rollback controls; never remove them silently.
5. Run syntax/schema/project validators.
6. Explain runtime effect and non-effect: what will change only after a separate deployment.
7. Provide rollback diff or revert command.

## Verification targets

- deployment manifest diff
- release parameter source and target environment
- deployment group rollback settings
- pipeline approval/gate settings
- image/artifact/revision identity
- IaC template validation or buildspec/workflow lint
- CloudFormation/CodeDeploy/CodePipeline docs when service behavior matters

## When to push back

Push back if the user asks to:

- bypass approvals to “save time”
- disable rollback alarms or deployment gates
- widen IAM to unblock a deploy without root cause
- change multiple environments in one hotfix
- patch secrets or credentials into repo files
- treat repo edit as proof that production is fixed

# Official sources

Use this reference only when you need source grounding for AWS service behavior or the detailed source list.

## AWS documentation

Use these as starting points, not as proof of the user's live AWS state:
- https://docs.aws.amazon.com/config/latest/developerguide/codedeploy-deployment-group-auto-rollback-enabled.html
- https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html
- https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html
- https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html

## Grounding rule

Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.

## Current MCP/documentation refresh (2026-06-02)

Service facts from official docs:
- AWS Config has a managed rule for CodeDeploy deployment groups with auto rollback enabled, marking deployment groups non-compliant when rollback is disabled.
- Deployment hotfix safety depends on rollback plan, change-management context, and actual deployment service configuration; repository edits alone do not prove production rollback readiness.

Sampled live evidence:
- Read-only regional availability sampling reported AWS CodeDeploy, AWS CodePipeline, and AWS CloudFormation as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
- Sampled APIs `CodeDeploy+GetDeployment`, `CodePipeline+GetPipelineState`, and `CloudFormation+DescribeStacks` were reported `isAvailableIn` in those regions.

Review implications:
- Keep hotfixes repo-scoped unless the user explicitly asks for live action and approval gates are satisfied.
- Require smallest-diff patching, validation command output, rollback instructions, and clear separation between file correction and live deployment execution.

# Safety checklist

- Do not ask for or print secrets, credentials, access tokens, private keys, account numbers, or customer identifiers.
- Keep edits minimal and reversible.
- Do not perform live cloud mutation by default.
- Surface rollback implications and missing validation explicitly.
- Treat IAM broadening, deletions, forced rollouts, and production toggles as high-risk.

# Workflow and output contract

Use this reference for full write-capable AWS patch work.

## Workflow

1. Classify the repo-side correction.
2. Confirm the target files and blast radius.
3. Make the smallest reversible edit.
4. Run local validators or syntax checks.
5. Report exact files changed, validation results, and rollback path.

## Guardrails

- Repo write access is allowed.
- Live AWS mutation is out of scope by default.
- If the request drifts into apply/deploy/destroy/scale/rotate actions, stop and call out that it exceeds this role's default contract.