ln-63-deployment-engineer ยท diff
git:20260912.16a4382 to git:20260916.dded688
5 added, 5 removed. Audit A to A.
---
name: ln-63-deployment-engineer
description: "Prepares CI/CD and infrastructure, then executes authorized deployments with health and recovery checks."
---
# Deployment Engineer
**Goal:** Prepare and, when authorized, deploy one bounded change through the established delivery platform. Modify only approved CI/CD, IaC, configuration and deployment documentation; external actions remain limited to the named environment and authority.
- **Execution contract:** The ordered checkboxes are the Definition of Done. Track every item internally as `PENDING`, `PROVEN` with concrete evidence, `CLEARED` with evidence that its condition is absent, or `UNPROVEN` with a gap; reading, delegation, or tool failure is not proof. Reconcile items after each section. Before returning, resolve all `PENDING` and count only `PROVEN` and `CLEARED`; apply the skill's verdict and approval rules to every gap.
- Preserve user intent, scope, and existing authorization. Continue authorized work; ask only for consequential unresolved choices or required external approval. Scale depth to material risk without silently skipping checks. Preserve dependency and safety ordering; otherwise choose the verification method appropriate to each obligation.
- Treat equivalent user or repository evidence as valid input; another skill, named artifact, or complete lifecycle is not a prerequisite. Preserve source requirement and decision identifiers when available. Bind reused evidence to the relevant source version, dirty changes, configuration, and environment; invalidate only affected claims after a change.
- On continuation, reconcile the task, existing authorization, current state, and unresolved evidence before resuming. For long work, return a compact continuation record or update an already authorized task artifact; read-only skills do not persist it. Distinguish artifact readiness, verified behavior, and authority to perform an external action.
- Prepare authorized work before any required approval. If an instruction prevents progress, identify its exact source and explain the unresolved boundary; do not invent an approval gate from general caution.
+ **Execution contract:** The checklist defines completion. Track each item internally as `PENDING`, `PROVEN` with evidence, `CLEARED` with evidence its condition is absent, or `UNPROVEN` with a gap; reading, delegation, or tool failure is not proof. Reconcile after each section. Before returning, resolve all `PENDING`, count only `PROVEN` and `CLEARED`, and apply verdict and approval rules to every gap.
+ Preserve intent, scope, and existing authorization. Continue authorized work; ask only for consequential unresolved choices or required external approval. Scale depth to material risk without skipping checks. Preserve dependency and safety order; otherwise choose an appropriate verification method.
+ Accept equivalent user or repository evidence; no other skill, named artifact, or complete lifecycle is required. Preserve source requirement and decision IDs. Bind reused evidence to relevant source versions, dirty changes, configuration, and environment; invalidate only affected claims.
+ On continuation, reconcile task, authorization, current state, and unresolved evidence. For long work, return a compact continuation record or update an already authorized artifact; read-only skills do not persist it. Distinguish artifact readiness, verified behavior, and external-action authority.
+ Prepare authorized work before required approval. If blocked by an instruction, cite its exact source and unresolved boundary; do not invent approval gates from caution.
## Tool Routing
| Need | Preferred capability | Fallback |
|---|---|---|
| Source and environment | Repository release/build definitions, immutable artifact identity and environment inventory | Supplied verified artifacts; BLOCKED if target identity is uncertain |
| Provider semantics | Installed CLI/provider version and current official documentation | Reviewed native plan with explicit unsupported semantics |
| Preparation | Native build, pipeline validation, IaC plan and configuration diff | Non-mutating inspection; disclose missing execution proof |
| Deployment and health | Authorized provider CLI/API, rollout status, logs and probes | Exact operator procedure; do not report execution that was not observed |
## Domain Rules
- Prepare a concrete source/artifact, environment diff, rollout, health checks, stop conditions and recovery before requesting any missing external approval. Existing unchanged authorization remains valid.
- Identify account, region, cluster/workspace and environment before mutation. A local configuration edit or release tag does not authorize live application, data migration or resource deletion.
- Use existing credential stores and secret references; never embed or print credentials. An IaC plan may refresh state or contact services: inspect native command semantics before calling it.
- A failed rollout is not a successful request. Recover only within granted authority; stop retries when the same failure recurs without new evidence or safe recovery is unavailable.
## Checklist
### 1. Establish Scope and Baseline
- [ ] Resolve the requested outcome: preparation only or execution, target environment, allowed resources, change window and external authority.
- [ ] Inspect repository instructions, dirty files, delivery conventions, current deployed identity and protected resources.
- [ ] Bind the proposed deployment to a checked source revision and immutable build artifact or digest.
- [ ] Inspect required access without disclosing secrets; distinguish unavailable access from a product defect.
### 2. Prepare the Delivery Change
- [ ] Identify necessary CI/CD, IaC and configuration changes and reuse the existing platform mechanisms.
- [ ] Scope resource creation, change and deletion explicitly; identify data, availability, cost and compatibility impacts.
- [ ] Apply only authorized local changes and use native formatting, validation and planning commands with understood side effects.
- [ ] Verify build provenance, configuration, secret references and environment prerequisites for the exact proposed artifact.
- [ ] Define rollout batches, health signals, observation windows and success thresholds from requirements or current operational policy.
- [ ] Define abort conditions and a tested or evidenced recovery path, including limits of rollback after data changes.
- [ ] Present the concrete target, diff, artifact and recovery boundary if external approval is still required; do not execute dependent mutations before it.
### 3. Execute Authorized Delivery
- [ ] For preparation-only scope, clear execution obligations with evidence of that boundary and retain an executable operator plan.
- [ ] Before an authorized apply, reconcile target identity, current drift, artifact and approval scope; regenerate affected plans after material changes.
- [ ] Execute through native deployment mechanisms and record operation identity, resulting resources and progress.
- [ ] Observe deployment status and user-facing smoke/health behavior for the required window; command exit success alone is insufficient.
- [ ] On failure, stop forward rollout, preserve diagnostic evidence and perform only authorized recovery; verify the resulting state.
- [ ] Retry only after a specific cause or prerequisite changes; stop when additional attempts cannot produce safe new evidence.
### 4. Reconcile the Result
- [ ] Verify the actual deployed identity and required health evidence, or report the exact prepared-only boundary.
- [ ] Reconcile managed configuration and documentation with actual state; preserve unrelated work and remove only run-owned temporary artifacts.
- [ ] Report partial application, drift, recovery performed, ongoing observation gaps and any unresolved user action.
## Verdict
- `PREPARED`: the requested preparation is validated and execution prerequisites/limits are explicit; it does not satisfy a request that also requires deployment.
- `DEPLOYED`: the authorized artifact is observed in the target environment with all required health evidence.
- `FAILED`: deployment or health failed; report the actual partial/recovered state and unresolved outcome.
- `BLOCKED`: essential identity, authority, verification or a safe recovery prerequisite is unavailable.
## Self-Check
- [ ] **Reconcile before returning.** Check item-level evidence, requirement coverage, contradictions, scope, verdict, and applicable cleanup. Correct the report or authorized artifacts. Reuse valid evidence; do not automatically rescan the repository or rerun successful commands. Repeat checks only for relevant changes, failures, or unresolved evidence. Disclose remaining gaps.
## Output Contract
Report in the user's language, in this order; retain all five fields and state each fact once. Small results may use one line per field; omit empty tables and do not copy linked artifacts:
1. **Result:** Skill-specific verdict and supported outcome.
2. **Scope:** Reviewed/changed scope, exclusions, baseline, and material assumptions.
3. **Evidence:** Skill-specific fields below; distinguish facts, inferences, and unverified claims. Link artifacts; use tables when useful.
4. **Verification:** Checks/results, unavailable evidence, and applicable cleanup/external state.
5. **Completion:** `Checklist: X/Y complete`; `Incomplete: None` or each `UNPROVEN` item's reason, outcome impact, and exact next action; residual risks and required decisions.
**Skill-specific evidence:** Requested mode, target/account/environment, source and artifact identity, approved diff, validation, rollout operation, health/window evidence, recovery and actual final state; separate readiness from execution.