oikos/AGENTS.md

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 seeds/policy.yaml; when the class requires approval, stop and ask the operator.

Agent-facing instruction lives 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).

Source of truth: The Postgres database is the single source of truth for all structured data and knowledge. It is bootstrapped from seeds/ at deploy time: seeds/ontology.yaml (entity types, relationships, lifecycles), seeds/inventory.yaml (hosts, services, entities), seeds/policy.yaml (risk classes, approval rules), and seeds/knowledge.yaml (documents, investigations, runbooks). The old narrative wiki is archived at archive/knowledge/ for historical reference.

1. Who you are

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

/opt/homelab-context/inventory.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. This is the seed file; at runtime the DB is authoritative (query via MCP get_entity or the REST API).
• /opt/homelab-context/seeds/knowledge.yaml — full narrative knowledge: 36 documents, 6 investigations, 12 runbooks. Ingested into the DB on deploy.
• /opt/homelab-context/.agents/operations/commands.md — the operator's cheatsheet for pct, caddy, DNS, and the Oikos command surface.

3. The MCP server

The homelab exposes a Model Context Protocol server with structured tools. Endpoint: https://mcp.hubris.network/mcp.

Available tools:

Context (read-only): get_entity(slug), list_entities(type, limit, cursor), get_relations(entity), get_blast_radius(entity), search_knowledge(query) — full-text search over documents, investigations, runbooks (PostgreSQL FTS, replaces the old Python search_docs) get_entity_knowledge(slug) — all documents, investigations, and runbooks linked to an entity get_topology(), 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 preflight(service) — risk class, approval requirement, verification command 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: always for knowledge queries. search_knowledge("jellyfin hardware acceleration") returns ranked results from the DB with entity links. get_entity_knowledge("lxc:jellyfin") returns documents, runbooks, and investigations in one call. Grep the clone only when MCP is unreachable.

4. Knowledge conventions

All narrative knowledge (documents, investigations, runbooks) lives in the DB (knowledge_entities table) and is seeded from seeds/knowledge.yaml. Agents can register new knowledge via the API:

POST /api/v1/knowledge/{entity_slug}
{"title": "...", "content": "...", "tags": ["..."]}

The DB is the truth. The old wiki files are archived at archive/knowledge/ for historical reference.

• Runbook procedures live as runbook entities in the DB and as SKILL.md files under .agents/skills/<name>/. They carry risk_class, procedure (JSON-schema-validated), and are linked to entity types via applies_to_type.
• Investigations are investigation entities linked to affected entities via about edges.
• Documents are document entities linked to entities via documents edges. They carry at_glance (structured attributes) and changelog (parsed entries).
• Live state precedence. If you observe a discrepancy between the docs and running state, update the DB in the same session via the API. The oikos export command regenerates seeds/knowledge.yaml for version control.

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.
• Secrets: never hardcode. Call homelab secret <name> to decrypt on demand using the per-client age key at /etc/age/key.txt.
• Mutations (restart, edit configs, etc.): classify against seeds/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.

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

Use MCP tools: search_knowledge <query> for narrative context, get_entity <slug> for structured data, get_entity_knowledge <slug> for everything linked to an entity. The clone is the fallback; MCP is the index.