dtoro
5c5016b3c7
Problem: runbooks are agent-executable procedures but lived at the repo root, separate from the other agent instruction now under .agents/. Change: - Move runbooks/<name>.md -> .agents/skills/<name>/SKILL.md (folder per skill, matching the wiki-hq skills layout). Frontmatter (name, risk_class, inputs, verification, docs_update_checklist, transition) preserved. - Rewrite links (inbound from plans; between-skill siblings) via the move map. - Update prose references in AGENTS.md, HERMES.md, .agents/OIKOS.md, and the operations schema; fix a pre-existing stale link to operations/commands.md. No code consumed runbooks/ by path, so nothing else changes. Verification: all SKILL.md frontmatter parses with valid risk_class; every lifecycle transition resolves to an oikos/ontology.yaml state; broken-link count 127 -> 126 (fixed one, introduced none). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
35 lines
1.5 KiB
Markdown
35 lines
1.5 KiB
Markdown
---
|
|
name: config-change-deploy
|
|
risk_class: config_mutation
|
|
inputs: [service_name, change_description]
|
|
verification: "curl -sf <service_url> (or homelab service <name> health)"
|
|
docs_update_checklist: [doc_page, changelog]
|
|
---
|
|
|
|
# Config change + deploy
|
|
|
|
Goal: change a tracked config repo (Caddy, Gitea customizations, an app's
|
|
own repo) and get it live, safely.
|
|
|
|
1. `homelab change preflight <service>` — current health, the service's
|
|
`config_repo`, its risk class, and the verification command to run
|
|
after. If risk class requires approval (`config_mutation` or
|
|
`destructive`), stop and get operator sign-off before editing — see
|
|
`oikos/policy.yaml`.
|
|
2. Clone/pull the `config_repo` (never edit the backend's working tree
|
|
directly — tracked configs change by commit + push, per
|
|
[OIKOS.md](../../../OIKOS.md) conventions).
|
|
3. Make the change, commit, push to `main`.
|
|
4. The Gitea webhook fires the deploy pipeline for that repo (see
|
|
[infrastructure/auto-deploy.md](../../../knowledge/wiki/infrastructure/auto-deploy.md) for
|
|
the exact receiver/reload for this service).
|
|
5. Run the preflight's verification command. If it fails, check
|
|
`homelab service <name> log` for the reload/restart error.
|
|
6. Record the change: once `oikos/ledger.py` is wired into deploy tooling
|
|
(Week 3), this is automatic; until then, note the change and outcome
|
|
in the relevant investigation/plan doc.
|
|
|
|
Docs-update checklist: update the service's `doc_page` if the change
|
|
alters its behavior, ingress route, or ownership; add a changelog entry
|
|
if the page has one.
|