dtoro
8a6422bd7d
Problem: node and cross-cutting narratives lived at the repo root
(containers/, vms/, infrastructure/, host .md files), interleaved with the
machine-readable substrate.
Change:
- Move containers/ -> knowledge/wiki/containers/, vms/ -> knowledge/wiki/vms/,
infrastructure/ -> knowledge/wiki/infrastructure/, hosts/{hubris,strong}.md ->
knowledge/wiki/hosts/, infrastructure/references/ -> knowledge/sources/references/,
GLOSSARY.md -> knowledge/GLOSSARY.md.
- Add knowledge/{index.md,log.md,sources/index.md} scaffolding.
- Rewrite all relative links repo-wide via a path-resolving mapper (inbound +
outbound + between-moved-files), including .hermes/, runbooks, operations,
investigations, plans, README, AGENTS.
- Repoint inventory.yaml doc_page fields and regenerate hosts/*.yaml (which
embed doc_page); update oikos/gen-topology.py output path, candidate doc
paths, and footer links; update code-comment doc paths.
Substrate untouched in place: inventory.yaml, hosts/*.yaml (regenerated,
idempotent), oikos/ code, mcp/, secrets/, bin/.
Verification:
- Logical broken-link set identical to pre-move baseline (net 128 -> 127; the
topology regen fixed one, introduced none). Remaining are pre-existing refs
to destroyed/archived nodes, out of scope for this move.
- gen-topology.py --check exit 0 (in sync); cards carry knowledge/wiki/ doc paths.
- build_host_files.py idempotent; all inventory doc_page targets resolve.
- MCP contract verified: get_page/search_docs/get_changelog resolve moved pages.
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.
|