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.

• New client? Read CLIENTS.md first.
• Developing on this repo? Also read .agents/dev/CONTRIBUTING.md.

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; see CLIENTS.md for the enrollment flow (the entity needs to exist in planned/provisioning state first).

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. Every call needs Authorization: Bearer <token> — the API has no unauthenticated path except enrollment and /healthz (see "Authentication" below for where the token comes from).

Available tools (33 total):

Context — observe + orient: get_entity(slug), list_entities(type, limit, cursor), get_relations(entity), get_blast_radius(entity), search_knowledge(query) — ILIKE search over documents, investigations, runbooks in the knowledge_entities table get_entity_knowledge(entity_slug) — every document, investigation, and runbook linked to one entity, in one call get_patterns(status, entity_type, action) — learned action patterns get_skills(status) — available automation skills http_get(url) — fetch a public page/raw file (e.g. researching how to deploy something before provisioning it); HTTP/HTTPS only, ~16KB cap

Management — live state: get_service_status(service_slug) — systemctl is-active on target host tail_log(service_slug, lines=200) — journalctl list_lxcs() — all LXC containers with ID, host, IP, health get_lxc_state(lxc_slug) — pct status from Proxmox host ping_service(service_slug) — HTTP reachability from entity_status list_my_secrets(caller_pubkey) — secrets accessible to this client by age public key

Oikos — decisions: explain(service_slug) — compact context card (type, state, health, relations) preflight(service_slug, action) — risk class + approval requirement whoami(hostname) — entity record, peers, health for a client get_change_history(entity_slug, limit=20) — last audit-log entries per entity get_state_snapshot() — fleet health, disk, drift count

Operations — observe + act: get_health_summary() — fleet health counts (healthy/degraded/down/unknown) get_signal_history(entity_slug, state, limit) — open + recent signals get_audit_trail(entity_id) — audit log filter + browse get_agent_activity(limit) — agent self-inspection query_metrics(hours=24) — time-series metric bucketed averages get_trend(entity_id, days=7) — metric slope over time get_event_timeline(severity, entity_slug, limit) — recent events

Knowledge — keep the graph current (none require approval; this updates the knowledge graph, not live infrastructure): upsert_knowledge(title, content) — record what you learned after solving a non-obvious problem; the only way anything persists past a session update_entity_attributes(slug, attributes) — merge a discovered fact (IP, version, port, ...) into an entity so a future task doesn't rediscover it from scratch create_relationship(source, target, type) — record a discovered edge (depends-on, hosts, routes-to, ...) between two entities

Execution — mutating the live infrastructure: run(target, command) — the general execution primitive. Run any shell command against a host or LXC; every command is auto-classified — read-only inspection runs immediately, anything state-changing needs operator approval, and destructive patterns (rm -rf, dd, mkfs, pct/qm destroy, DROP TABLE, reboot, curl-pipe-to-shell, ...) always need approval regardless of what you declare. This is the ONLY mutation tool — request_execution was retired 2026-07-14. run — the general execution primitive. Run any shell (restart, systemctl, pct_exec, apt_upgrade, pct_create). Still the route for those specific actions; policy-gated the same way run is. get_execution_status(execution_id) — poll progress

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. Authentication

Every API/MCP route requires Authorization: Bearer <token> except POST /api/v1/clients/enroll and /healthz. Enrollment (see CLIENTS.md) does not currently issue a per-client API/MCP bearer token — there is one shared secret (OIKOS_MCP_BEARER_TOKEN, validated in internal/httpapi/server.go's combinedAuth); get it from the operator until per-client token issuance exists. The SPA has its own flow instead: a first-launch Config screen that stores a token in localStorage (see web/src/pages/Config.svelte).

5. 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 in knowledge/wiki/ pending archive per the DB-as-source-of-truth plan.

• 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.

6. Acting on the homelab

• Read state: use MCP tools. Nomos (the AI agent) is the primary operator interface — it has 33 MCP tools for observe/orient/decide/act (§3).
• Actions (restart, logs, apt, pct exec, or anything else): Nomos calls run (the general execution primitive) via MCP. reversible_low/read-only actions execute immediately; config_mutation and destructive actions are queued for operator approval via Matrix or the control-room UI's Operations page.
• Secrets: managed by Infisical (oikos secret subcommand for migration). Never hardcode secrets — use env vars from .env.
• Mutations (restart, edit configs, etc.): classified against seeds/policy.yaml. reversible_low actions auto-execute; config_mutation/destructive actions require approval — granted by the operator via Matrix reply or the control-room UI, not a CLI flag. See OIKOS.md.

7. 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.

8. 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:

• Host checks (tools/setup-checks.sh): Deploys checks/install.sh's health-check scripts to /opt/oikos/checks on each host. The scheduler's ssh-script check kind depends on these actually being there — 20 are live in the DB as of 2026-07-12.

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

To trigger sync manually: run /opt/homelab/tools/context-poller.sh, or wait for the 5-min timer. (This mechanism — and the server-side tools_changed detection behind it — only correctly recognized setup-*.sh scripts as of 2026-07-12; before that it silently matched nothing, so nothing auto-ran on any client via this path.)

9. Versioning

Every commit to main MUST bump the version in the VERSION file at the repo root. The format is semver-ish: major.minor.patch (e.g. 0.2.3).

Rules:

• patch (0.2.2 → 0.2.3): bugfixes, small tweaks, docs-only changes
• minor (0.2.3 → 0.3.0): new features, new tools, visible functionality
• major (0.3.0 → 1.0.0): breaking changes (API removal, tool retirement)

The version is shown in the UI sidebar. The v prefix is added at build time.

10. 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.