e04d7868404783a90578607815bd5e13878b55b5
Two invariants only a live homeserver can check, now enforced rather than verified by hand: - The configured NISSE_MATRIX_USER_ID must be the token's real owner. MatrixTransport filters its own messages by comparing sender to that value, so a mismatch would make the bot read its own posts as operator input. - The account must be a testing identity, so a stray live run can never act as the production agent. Both hold today; this keeps them holding when the production nisse-dev account is created. Co-Authored-By: Claude Opus 5 <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.