dongarandClaude Opus 5.5
66c8ded409
D3's preflight and install recording become the toolchain step: a bounded run of the item's driver model that makes the build VM and the project's own files (pins, setup docs, CI configuration) agree, with the repository as the record. The harness starts it when the VM isn't set up for the project (and then it edits nothing in the repository); the driver requests it once work is agreed, and its edits land in the current milestone. Versions stay facts the harness reads itself; a rebuilt VM's new host key is trusted only on the operator's word. D1 gains the rule that until the go-ahead the agent only looks: anything that changes something is refused by the fast path, so what the work needs goes in the restatement. The Development Plan's M4.2 follows: the toolchain step, in place of recording installs. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE
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 L) |
nisse-dev/ |
Dev Agent — plans and implements software projects (Part D) |
nisse-ops/ |
Sysadmin Agent — operates infrastructure (Part O) |
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.md. It covers the
shared library, both agents, the supporting services, the build order, and the
remaining open decisions.