dongarandClaude Opus 5.5
31bef59151
Records a design session on MCP server deployment as a standalone amendment, ahead of folding it into the spec: - Every agent gets its own VM, justified by inter-agent isolation and per-agent credential attribution; Docker-in-Docker stays as an extra Dev Agent reason rather than the rule's foundation - Egress is a declared, per-agent-instance default-deny allowlist, covering what MCP servers reach on the agent's behalf, with the tailnet's 100.64.0.0/10 called out as outside RFC1918 - MCP servers run per agent VM, one instance per (service, site, privilege), with site in the server identity rather than a tool argument - Third-party MCP images are digest-pinned and excluded from Watchtower - Routed meta-tools rejected; stateful-server relocation parked Two consequences settled with the operator while drafting: each MCP server instance gets its own Vaultwarden machine account (A7), and any write, reversible or not, requires an approved plan (C2). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Nisse
Two self-hosted AI agents sharing a common library, named for the Nordic farm spirit that keeps the place running overnight and expects to be treated well in return.
| Package | Role |
|---|---|
nisse-core/ |
Shared library both agents sit on (Part A) |
nisse-dev/ |
Dev Agent — plans and implements software projects (Part B) |
nisse-ops/ |
Sysadmin Agent — operates infrastructure (Part C) |
One repository, three packages. The library does not exist as code yet: it is
extracted from nisse-dev once that agent works (build-order step 10), as a
package split within this tree.
Architecture
The system-level specification lives at
docs/Architecture-Build-Spec.md. It covers the
shared library, both agents, the supporting services, the build order, and the
remaining open decisions.