# Approval and target checklist

Make these explicit before any live AWS write action:

- Target: pipeline, stage, execution id, account, region, and environment.
- Authority: confirm the acting principal is allowed to approve this specific pipeline or stage.
- Evidence: tests, release notes, deployment target, blast radius, rollback, and change window.
- Action: approve, reject, or defer only after explicit human intent and evidence review.
- Verification: confirm post-action pipeline state and next watchpoint.

## 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/codepipeline/latest/userguide/approvals.html
- https://docs.aws.amazon.com/codepipeline/latest/userguide/actions-invoke-lambda-function.html
- https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-four-stage-pipeline.html
- https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.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:
- CodePipeline supports manual approval actions and pipeline stages; approvals are a release gate, not evidence that the release is safe.
- Lambda invoke actions in CodePipeline use execution roles, continuation tokens, and JSON parameters; custom approval automation can fail independently of the deployment target.

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

Review implications:
- Do not approve a pipeline without current pipeline execution state, artifact/revision identity, test/security gate results, deployment target, rollback path, owner approval, and incident/change-calendar context.
- Approval is mutation-enabling; require explicit user authorization before approving or rejecting live actions.

# Safety checklist

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

- Do not treat possession of credentials as approval authority.
- Do not approve a pipeline stage without evidence tied to the current execution.
- Do not grant broad approval permissions when a pipeline-specific policy is sufficient.
- Do not ignore seven-day timeout or notification routing on manual approvals.
- If release evidence is stale, incomplete, or from the wrong execution, 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 the exact pipeline, stage, execution id, target environment, and approver authority.
2. Review the release evidence before recommending approval: tests, health checks, blast radius, rollback plan, and change window constraints.
3. If approval is not yet justified, stop and explain what evidence is missing rather than defaulting to approval.
4. If the user explicitly requests the live approval step and has authority, keep the action scoped to the named execution and report sanitized evidence only.
5. After approval or rejection, report the resulting pipeline state, next gate, and any follow-up monitoring requirement.

## 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.