Files
oikos/AGENTS.md
dtoro 8a6422bd7d docs: move narrative wiki under knowledge/wiki/ (phase 3)
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>
2026-07-06 14:35:23 +02:00

6.8 KiB

AGENTS.md — orientation for any agent on a homelab client

You are running on a machine that is part of the hubris homelab. The full context is in this checkout at /opt/homelab-context/. This file is the entry point. Read it once at start, then keep working.

The operating model — OODA loop, risk classes, approval rules, the ontology, and node lifecycle — is defined in OIKOS.md. Before any mutation, classify the action against oikos/policy.yaml; when the class requires approval, stop and ask the operator.

Agent-facing instruction is separated from human content under .agents/: .agents/shared/ holds the conventions every agent applies (writing-style, caveman, page-templates, llm-wiki), and .agents/domains/ holds the per-domain schemas (knowledge, operations). The narrative wiki lives under knowledge/wiki/; the machine-readable substrate (inventory.yaml, hosts/*.yaml, oikos/) stays at the repo root.

1. Who you are

Run hostname (Linux) or scutil --get LocalHostName (macOS), then read:

/opt/homelab-context/hosts/<your-hostname>.yaml

That file tells you your role, your peers, what's mounted, and what services you host. If it does not exist, this client was not enrolled — stop and tell the operator to run homelab client add <hostname> from an existing client.

2. The topology

  • /opt/homelab-context/inventory.yaml — every host, LXC, VM, and workstation with their mesh addresses, roles, and service mappings. Treat this file as authoritative; anything you read in narrative pages should agree with it.
  • /opt/homelab-context/knowledge/wiki/infrastructure/mesh.md — Tailscale → Netbird state. Both meshes are accepted today; Netbird is preferred for new traffic.
  • /opt/homelab-context/knowledge/wiki/infrastructure/dns.md — split-horizon DNS via Technitium on dns (107). *.hubris.network resolves to 192.168.x.x on the LAN and to mesh addresses off-LAN.
  • /opt/homelab-context/operations/commands.md — the operator's cheatsheet for pct, caddy, DNS, and the Oikos command surface. Use these verbs when you take actions.

3. The MCP server

The homelab exposes a Model Context Protocol server with structured tools. Endpoint is in inventory.yaml under services.homelab_mcp.endpoint.

Available tools:

Context (pure read): get_host(name), list_services(), find_service(name_or_role), get_topology(), search_docs(query), get_page(path), get_changelog(page, since?), whoami(hostname), list_my_secrets(caller_pubkey?)

Management (read-only): get_service_status(service), tail_log(service, lines=200), list_lxcs(), get_lxc_state(lxc), ping_service(service)

Oikos (read-only; see OIKOS.md): explain(service) — compact context card, cheaper than search_docs+get_page preflight(service) — risk class, approval requirement, verification command get_relations(entity) — ontology blast-radius query (host: or service: id) get_change_history(entity, limit=20) — change-ledger entries get_state_snapshot() — last scheduler Observe-pass (health, disk, drift count)

Mutations are not exposed via MCP. Use the homelab CLI for those, with operator confirmation — see OIKOS.md's risk classes and approval flow.

When to prefer MCP over grepping the clone: any time you need to resolve a name to an address, look up service status, or search the wiki by content. Grep is fine for browsing or when MCP is unreachable.

4. Wiki conventions

  • Narrative pages live under knowledge/wiki/{containers,hosts,vms,infrastructure}/; procedural pages under investigations/, operations/, runbooks/, plans/. Cross-link liberally; orphans are bugs.

  • Every page ends with a ## Changelog section, entries in reverse-chrono order:

    ### YYYY-MM-DD — short title
    one or two lines describing what changed and why.
    
  • Investigation files are dated and slugged: YYYY-MM-DD-slug.md.

  • Live state takes precedence over docs. If you observe a discrepancy, update the docs in the same session (per the same-session update rule).

5. Acting on the homelab

  • Read state: prefer MCP tools, then files, then shell. Examples: homelab whoami, homelab list, homelab status, homelab logs caddy.
  • Cross-host actions (caddy reload, pct exec, etc.): use the homelab CLI — it resolves hostname → mesh address → ssh / pct path for you. Direct SSH still works; the CLI just removes the lookup burden.
  • Secrets: never hardcode. Call homelab secret <name> to decrypt on demand using the per-client age key at /etc/age/key.txt. Secrets ARE available in this system — list_my_secrets() (MCP) shows what you can decrypt.
  • Mutations (restart, edit configs, etc.): classify against oikos/policy.yaml first (homelab decide <action> <entity>). reversible_low actions just need the interactive confirmation prompt; config_mutation/destructive actions are mechanically refused without a valid --approval-id from homelab approval request — see OIKOS.md. For ad-hoc work, SSH and edit directly — but commit changes that touch tracked configs (caddy, gitea custom, artifacto, mule-image, etc.; see knowledge/wiki/infrastructure/auto-deploy.md).
  • Wiki updates: same-session rule applies to any meaningful state change this client makes.

6. Communication mode

Read and apply /opt/homelab-context/.agents/shared/caveman.md (if present). It defines the lab's terse-communication standard — drop filler, keep substance, use fragments.

7. Auto-setup mechanism

The homelab-context repo ships tooling that gets automatically installed on every client after git pull. This is handled by tools/post-pull.sh (replaces the raw git pull in the sync timer) which runs any script matching tools/*.setup.sh after pull.

Currently auto-setup:

  • Caveman + templates (tools/setup-caveman.sh): Installs Caveman npm package, wrapper scripts, and compact output templates for token-efficient CLI output. Wrapper at ~/bin/caveman_wrapper.sh.
  • Hermes agent persona (tools/setup-hermes-soul.sh): Provisions ~/.hermes/SOUL.md from HERMES.md on Hermes agents. This ensures every Hermes agent follows the canonical homelab persona (token efficiency, source of truth hierarchy). No-op on non-Hermes agents.

To add a new auto-setup, create tools/<name>.setup.sh in the repo, commit and push. All enrolled clients pick it up within 5 minutes.

To trigger sync manually: sudo homelab sync or wait for the 5-min timer.

8. When in doubt

Run homelab mcp search_docs <query> or homelab mcp get_host <name>. The clone is the fallback; MCP is the index.