Local-Cursor/internal/skills/builtin/fd-engineering/references/devops.md

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 for consequential intent/tradeoff blockers.
5. Without approval, follow plan.md and await confirmation. A direct small local request can use the narrow quick path in 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 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.