# Approval and target checklist

Make these explicit before any live AWS write action:

- Target: exact account, region, profile or role, workload, and command family.
- Identity: confirm active caller identity before any live write command.
- Preview: run describe, plan, status, change set, or dry-run style commands first where supported.
- Approval: require explicit human approval before the live write step, not after it.
- Rollback: define the rollback trigger, previous version or config, and abort condition before execution.
- Verification: define the success signal, alarms, health checks, and observation window after the change.

## Refusal triggers

Refuse or stop at planning when:

- the target account, region, or principal is ambiguous,
- the user has not explicitly approved the live step,
- rollback or monitoring posture is missing, or
- the action scope expands beyond the named target.

# 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/codedeploy/latest/userguide/welcome.html
- https://docs.aws.amazon.com/config/latest/developerguide/codedeploy-deployment-group-auto-rollback-enabled.html
- https://docs.aws.amazon.com/codepipeline/latest/userguide/approvals.html
- https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/drift-aware-change-sets.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:
- CodeDeploy automates deployments for EC2, Lambda, and ECS and supports deployment types such as rolling and blue/green traffic shifting depending on compute platform.
- AWS Config has a managed rule checking whether CodeDeploy deployment groups have auto rollback enabled.

Sampled live evidence:
- Read-only regional availability sampling reported AWS CodeDeploy 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+CreateChangeSet` were reported `isAvailableIn` in those regions.

Review implications:
- Live deployment operation must be approval-gated and evidence-driven: current deployment state, rollback trigger, health alarms, blast radius, change set/diff, and stop/rollback command path.
- Do not perform or recommend live mutation from stale docs or repo-only evidence.

# Safety checklist

Before recommending or running a live AWS action, enforce these checks:

- Do not assume the current AWS credentials are the right ones. Confirm identity and environment every time.
- Do not turn a repo-write task into a live deploy just because credentials are present.
- Do not bypass manual approvals, change windows, alarms, or rollback controls unless the user explicitly accepts that risk and the reason is documented.
- Do not continue if blast radius, rollback, or current state is unknown.
- If evidence is partial, say so. Refusal is better than an accidental prod action.

## Mandatory posture

- Prefer the smallest reversible change.
- Prefer preview, describe, or dry-run style evidence before mutation.
- Treat the absence of rollback as a blocker, not a detail.
- If live AWS credentials are present but target identity is unclear, stop.

# Workflow and output contract

Use this sequence when the request may touch a live AWS environment:

1. Verify target identity first: account, region, profile or role path, environment name, and exact service or resource.
2. Inspect current live state before proposing mutation. Use dry-run, preview, describe, or status commands first when available.
3. Require an approval checkpoint before mutation. If the user has not explicitly authorized the live step, stop at plan or preview.
4. Prefer rollout controls such as change calendars, approval actions, alarms, canaries, circuit breakers, and stack policies when the target service supports them.
5. After any approved live step, report the exact command class, sanitized evidence, rollback posture, and post-change verification results.

## Output shape

Return concise sections in this order:

1. Target confirmation
2. Preflight evidence
3. Approval status
4. Proposed or executed action
5. Rollback posture
6. Post-change verification
7. Open risks or refusal reason

Keep command evidence sanitized. Do not paste secrets, tokens, or raw env dumps.