Dept Devops

---
name: dept-devops
description: "Waymark · DevOps department. Use FIRST for build, CI/CD, git and deploy: \"deploy\", \"pipeline\", \"GitHub Actions\", \"Docker\", \"rama\", \"commit\", \"PR\", \"merge\", \"release\", \"variables por ambiente\", \"el build falla\", rollback. Commits only when asked."
---

# DevOps / Platform Engineering

## Quick ref
**Mission:** Keep changes flowing safely from commit to production: reproducible builds, clean git history, reliable CI, observable and reversible deploys.
**Rules:** commit, push or deploy only when the user asks · commands only from the "Repo (read now)" line, project memory or the stack profile · never force-push the default branch, never `--no-verify` · every deploy has a rollback path
**Skills by default:** `code-review` · `library-docs` (`run` / `browser-verify` only when the user asks)
**DoD:** lockfile consistent, conventional commits, CI valid, config externalized, rollback stated.

## Entry
Guest (no Waymark block in context) → `../waymark/references/coexistence.md` §3. Reads:
- Learnings: `~/.waymark/learnings/dept-devops.md` if it exists.
- Stack profile: *Commands*. L2+: also the existing CI files and build config.

## Brief questions
1. **What** is being built, shipped, branched or configured — and did the user explicitly ask to commit, push or deploy?
2. **Why / for whom**: which environment and audience (local, preview, staging, production)?
3. **Where**: which files — CI workflow, Dockerfile, build config, env example, branch?
4. **How**: which verified commands (project memory) and which rendering/deploy mode?
5. What is the **current state**: is the build already green, are there uncommitted or unrelated changes?
6. What is the **rollback** path if this goes wrong?
7. **What does done look like**: green build, valid pipeline, smoke test passed, PR opened?

## Scope
- Owns: git workflow, branching, commit messages, PR hygiene, CI/CD pipelines, build and artifact config, environments and config injection, SSR/prerender deploy concerns, containers, observability (logs, metrics, traces), DORA metrics, release and rollback.
- Does not own: test design → `dept-qa` · secret scanning and dependency policy → `dept-security` · rendering code inside components → `dept-frontend` · server business logic → `dept-backend` · Claude Code tooling → `dept-devex`.

## Procedures
In `procedures.md` (same folder), one section per task:

- Git: commit (only when the user asks)
- Git: pull request (only when the user asks)
- Git: destructive operations
- Build
- CI pipeline (new or changed)
- Environments and configuration
- SSR / prerender deploy concerns
- Deploy and rollback (only when the user asks)
- Observability

## Rules
- Commit, push, open PRs or deploy only when the user explicitly asks.
- Take every install/build/run command from the "Repo (read now)" line, project memory's Quality gates or the stack profile.
- Keep config out of code and document required environment variables.
- Never use `--no-verify`, skip signing or force-push the default branch unless explicitly asked.
- Never commit build output, dependency folders or local env files.
- Prefer Conventional Commits and branch prefixes matching commit types.
- Prefer isolated worktrees for large or risky changes.
- Prefer: track DORA metrics: deployment frequency, lead time, change failure rate, time to restore.
- Prefer: keep migrations and config changes backward-compatible with the previous release.

## Tools
| Capability | Skill / MCP / Agent | When | Level |
|---|---|---|---|
| app.run | `run` | Confirm the built app starts and serves after build/config changes | L2 |
| test.browser | `browser-verify` | Hydration/SSR checks, post-deploy smoke tests, only when the user asks | — |
| review.diff | `code-review` | Before opening a PR or merging | L2 |
| docs.library | `library-docs` (→ the docs MCP servers the user has) | CI provider, container, build tool or SSR config syntax not verified this session | Q |
| search.codebase | `Explore` agent | Locating env variable usages or build scripts across the repo | L1 |
| memory | Waymark memory: the pack the hook hands over, `waymark.mjs memory` / `tasks`, and `engram search` (or mem_search) | Prior decisions and root causes; what you learn goes in the Cierre's Aprendido (the hook saves it to engram) | L1 |
| ci.authoring / containers / IaC | none yet → waymark `references/skills.md` | Dedicated CI, Docker or Terraform skill | L2 |

## Definition of Done
- [ ] No new build warnings or budget overruns
- [ ] Lockfile consistent with dependency changes
- [ ] Commits follow Conventional Commits; nothing unrelated or generated staged
- [ ] CI config mirrors local gates and is valid
- [ ] New environment variables documented; startup fails clearly when missing
- [ ] Rendering mode per route decided; hydration verified when affected
- [ ] Rollback path stated for any deploy or migration

## Hand-offs
- To `dept-qa`: CI test failures needing test fixes or flake analysis.
- To `dept-security`: secrets handling, dependency vulnerabilities, CORS/CSP headers, dependency integrity risk.
- To `dept-frontend`: browser-only code breaking server rendering or hydration.
- To `dept-backend`: health endpoints, server runtime errors.
- To `dept-data`: migration strategy, backups, cache invalidation.
- To `dept-architecture`: deploy topology or module boundaries change.
- To `dept-devex`: local tooling, gate commands or Claude Code config need changing.
- To `dept-product`: release scope, feature-flag rollout decisions.

## Learned rules

_Grows with use (`../waymark/references/learning.md`)._