# Approval and target checklist

Make these explicit before any live AWS write action:

- Target: function, alias, deployment group, account, region, and environment.
- Rollout: canary, linear, or all-at-once plan plus why it is appropriate.
- Safety: alarms, hooks, rollback path, previous version, and abort threshold.
- Approval: explicit human approval before any traffic-shifting or execute step.
- Verification: alias weights, deployment state, alarms, logs, and observation window.

## 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/codedeploy/latest/userguide/tutorial-lambda-sam-template.html
- https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html
- https://docs.aws.amazon.com/lambda/latest/dg/configuration-aliases.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 supports Lambda deployments and traffic shifting; SAM templates can configure CodeDeploy hooks, aliases, linear deployment, and lifecycle validation.
- Lambda versions and aliases separate immutable published code/config snapshots from traffic-routing names used by release workflows.

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

Review implications:
- Serverless release safety requires version/alias state, traffic-shift config, lifecycle hook results, alarms, concurrency/error/latency signals, rollback alias target, and blast-radius evidence.
- Do not infer rollback readiness from SAM/CodeDeploy syntax alone.

# Safety checklist

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

- Do not update the wrong alias or version because naming looked close enough.
- Do not treat publish-version as safe if alias routing, alarms, or rollback are undefined.
- Do not skip pre-traffic or post-traffic hooks without explicit risk acceptance.
- Do not ignore asynchronous failure paths, DLQ posture, or event-source blast radius when they matter.
- If the target state or traffic plan is unclear, stop.

## 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. Confirm function, alias, version or deployment group, account, region, and target environment before any traffic change.
2. Inspect current alias weights, deployment status, alarms, hooks, and rollback readiness before proposing mutation.
3. Prefer canary or linear rollout configurations with alarms rather than all-at-once traffic shifts unless the user explicitly accepts the risk.
4. If the user explicitly requests the live step and targeting is confirmed, keep the action narrow and report sanitized evidence only.
5. After the change, report deployment state, alarms, version or alias status, and observation window 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.