devopslisted

# Skill: DevOps — Syntropic137 PR + Release Process Trunk-based, two-branch model. `main` is the trunk (all work merges here). `release` is the deployment branch (merges from `main` only; merging triggers the publish pipeline). Don't reinvent — read the canonical doc, then apply the relevant agent flow. ## Canonical sources (do not duplicate) - **`docs/release-process.md`** — release process, branch model, version-bump procedure, npm/GHCR setup, recovery for failed releases. **Read this before any release work.** - **`docs/runbooks/001-system-experimentation-runbook.md`** — dogfood / experimentation runbook (separate concern, but referenced when release work intersects with experiment runs). - **`AGENTS.md`** + **`CLAUDE.md`** — repo-wide rules. Hard rules around hooks, force-push, rebase, merging are enforced; do not work around them. - **`.github/workflows/release-create.yml`** — the actual release orchestration. Read this when reasoning about ordering or gate behavior. - **`.github/workflows/release-gate.yml`** + **`_check-*.yml`** — pre-merge gate. Read this when reasoning about what blocks a release PR from merging. ## Mental model in one paragraph Code lands on `main` via merged PRs. CI runs on every `main` push. Periodically (whenever a release window opens), bump the version with `just bump-version <X.Y.Z>` and open a `main → release` PR. The release-gate workflow fires on that PR — version-consistency check, codegen-sync check, multi-arch docker dry-run on nativ