# DevOps: project-appropriate engineering and delivery

For /FD-devops or explicit build, packaging, environment, CI/CD, release, deployment, or operations work. Default to investigation and a proposal unless implementation is authorized.

## Select capabilities independently

| Capability | When needed | Inspect |
|---|---|---|
| Local validation | Evidence that a change meets its goal | Tests, static/type checks, manual acceptance |
| Reproducible builds/packaging | Execution, distribution, or artifacts | Runtime, declared/locked dependencies, commands, artifacts, usage |
| Git | Existing repository or explicit version-control need | Worktree/branch conventions, change ownership, commit strategy |
| Remote hosting/collaboration | Explicit collaboration or hosting need | Actual remote and review workflow |
| CI | Required automated checks or an existing pipeline | Actual platform, triggers, checks, build steps |
| Release/deployment/operations | A real installation, release, or runtime target | Environment, configuration, permissions, artifacts, health, monitoring, rollback |

Do not create Git, remotes, containers, CI, or cloud infrastructure merely for engineering completeness. Local projects can ship verified files or packages. Missing infrastructure alone is not a defect.

## Investigate and plan

1. Establish the deliverable, environment, and acceptance. Inspect docs, scripts, dependencies, and existing pipelines.
2. Reuse existing tools/conventions; verify consequential version uncertainty with official documentation.
3. Separate necessary gaps for this delivery from larger future engineering work.
4. Explain each addition's purpose, cost, affected files, checks, and necessary rollback. Use [grill.md](grill.md) for consequential intent/tradeoff blockers.
5. Without approval, follow [plan.md](plan.md) and await confirmation. A direct small local request can use the narrow quick path in [workflow.md](workflow.md); dependency, persistent-data, security, public-interface, or external changes cannot. With valid approval, complete the relevant local edits/checks continuously.

Use DEVOPS sub-stages for investigation, planning, implementation, and validation as applicable. Track multi-step work with [todo.md](todo.md) in the effective protocol plan. Implementation and external operations retain their actual approval boundaries; no host-mode transition is needed.

## Implement only applicable capabilities

- Environment/dependencies: reuse current runtimes and locking; identify clean-environment needs and undeclared developer-machine assumptions.
- Checks/builds: use real commands and propagate failure; never publish failed artifacts as successful.
- Artifacts: identify location, version/identity, startup, and usage. Building alone does not prove target-environment execution.
- Configuration/secrets: declare required settings, reuse appropriate storage, and keep credentials out of logs/reports.
- CI: prefer existing workflows; inspect triggers/permissions and validate runnable local steps. Mark unrun remote pipelines unverified.
- Release/deployment: identify target, verified artifact, configuration/data compatibility, health checks, failure signals, and necessary rollback.

Before triggering remote pipelines, uploading artifacts, publishing, deploying, or changing a real environment, verify explicit authorization already given. Local configuration approval does not authorize every external action. Do not reconfirm already explicit instructions. Before retrying high-impact operations, inspect actual state and idempotency; report unknown state instead of repeating blindly.

## Smoke-check the actual deliverable

When delivery includes a package, archive, or executable, exercise that actual artifact rather than relying only on the source checkout/build exit code. Use a suitable separate directory, isolated environment, or target device according to risk; a VM is not mandatory. Verify startup away from the source directory, included assets, declared configuration/dependencies, absence of developer-only absolute paths, and one relevant core user operation. Use safe representative data and existing authorization.

Preserve the command, artifact identity, environment, and result. If target execution is unavailable, distinguish built/packaged from startup/operation unverified; do not claim target readiness. For data/schema changes, validate the agreed old-data compatibility/migration and restoration approach without treating code rollback as data recovery. No mandatory packaging, deployment, or extra infrastructure for tasks that do not need it.

## Output and stop

In Chinese, state selected capabilities and reasons, local changes, actual validation, artifacts/instructions, and external or unverified work. For a runtime target, report actual health/rollback status; otherwise use local-delivery acceptance.