# Approval and target checklist

Make these explicit before any live AWS write action:

- Target: cluster, service, task definition, account, region, and environment.
- Safety: circuit breaker, alarms, health checks, bake time, and rollback behavior.
- Evidence: current deployment status, service events, latest healthy revision, and blast radius.
- Approval: explicit human approval before any live rollout or force-new-deployment step.
- Verification: service deployment state, alarms, events, 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/AmazonECS/latest/developerguide/service-deployment.html
- https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-steps-ecs.html
- https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html
- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/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:
- ECS service deployment history tracks lifecycle states, circuit breaker failures, CloudWatch alarms, rollbacks, and recent deployment history.
- ECS blue/green deployments with CodeDeploy shift traffic between replacement task sets and can use lifecycle hooks; rollback depends on deployment configuration and health signals.

Sampled live evidence:
- Read-only regional availability sampling reported Amazon ECS, AWS Fargate, and AWS CodeDeploy as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
- Sampled APIs `ECS+DescribeServices`, `ECS+DescribeTasks`, `CloudWatch+DescribeAlarms`, and `CodeDeploy+GetDeployment` were reported `isAvailableIn` in those regions.

Review implications:
- Guard live ECS rollout with current service/deployment state, stopped-task reasons, target health, alarms, deployment controller, desired/running counts, and rollback/stop path.
- Regional/API availability does not prove a service is safe to roll forward.

# Safety checklist

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

- Do not force a new deployment just because the service looks stale.
- Do not ignore unhealthy tasks, missing alarm coverage, or rollback-disabled settings.
- Do not treat a task definition registration as equivalent to a safe live rollout.
- Do not widen blast radius across multiple services when one named service is the target.
- If deployment safety signals are weak or contradictory, 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 cluster, service, task definition, account, region, and environment before any live ECS action.
2. Inspect current deployment state, service events, health checks, alarm state, and rollback posture before proposing mutation.
3. Prefer circuit breaker or alarm-backed failure detection and a defined bake window rather than a blind forced rollout.
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, rollback status, alarms, service events, and post-rollout 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.