dtoro
69964abe2e
R13 — on-client path reconciliation: - AGENTS.md: 6 occurrences of /opt/homelab-context/ → /opt/homelab/ (sections 1, 2, 5, 7) - .agents/NOMOS.md: 2 occurrences of /opt/homelab-context/ → /opt/homelab/ - CLIENTS.md already used /opt/homelab/ — now consistent across all docs. The repo is still named 'homelab-context' (git remote), it just clones to /opt/homelab/ on enrolled clients per CLIENTS.md. R14 — golangci-lint/staticcheck/govulncheck tooling: - .golangci.yml (new): config enabling govet, staticcheck, ineffassign, unused, errcheck, gosimple, typecheck, misspell, revive. Excludes generated code (internal/httpapi/gen/, internal/db/sqlcgen/) and relaxes errcheck in test files. - Makefile: split 'lint' target into vet, golangci, govulncheck subtargets. Each checks if the tool is installed and prints install instructions if not. 'make lint' runs all three. - CI already had golangci-lint-action + govulncheck (both advisory); the action auto-discovers .golangci.yml.
1.9 KiB
NOMOS.md — Agent persona for homelab clients
This file is the canonical agent persona for AI agents running on machines in the hubris homelab (Claude Code, Codex, or similar). It prescribes behaviour, token-efficiency conventions, and the source-of-truth hierarchy.
The production Nomos agent (cmd/nomos, the containerized MCP client
gateway everyone actually talks to) uses a separate, code-adjacent persona —
nomos/SOUL.md, baked into its Docker image at build time
(compose/nomos/Dockerfile). This file is unrelated to that one; it's for
AI coding agents working on a homelab client machine, not the Nomos
service itself.
Source of truth
The homelab-context repo at /opt/homelab/ is the single source of
truth for:
- Fleet topology (
inventory.yaml) - Agent behaviour and conventions
- Everything in this file
When in doubt, check /opt/homelab/ first, or query the Oikos API/MCP
server directly (see AGENTS.md §3-4) — the database is
authoritative at runtime.
Runbooks — load, don't rediscover
For the canonical workflows (service health check, config change +
deploy, client enrollment, incident investigation, and each node
lifecycle transition), read the matching .agents/skills/<name>/SKILL.md before
acting. Each skill carries its risk class, required inputs, the
verification command, and a docs-update checklist in its frontmatter —
classify against seeds/policy.yaml using that risk class before any
mutation. Don't re-derive topology or the mutation path by grepping the
wiki when a runbook already encodes it. See OIKOS.md for the
operating model these runbooks execute inside (OODA loop, risk classes,
approval flow, ontology).
Token efficiency
Apply caveman.md — terse, fragment-heavy chat responses (not committed documentation). There's no separate tool to install for this; it's a response-style convention any agent follows by reading the file.