dongarandClaude Opus 5
53ed11f9c4
A frontier model receives a scoped sub-task, works autonomously with full tool access, and hands back; the local loop reads the handback note and the file state, never the reasoning. - Branch at delegation start, and abort discards it. That required committing each turn's work onto the branch: without commits, deleting a branch discards nothing, so "abort discards the work" was a comforting phrase rather than a fact. The caller's own in-flight changes are committed to their branch first, so an abort cannot destroy work nobody delegated - Hard caps on turns and wall clock; a breach is a defined failure return, and its result is not usable, so the caller gates rather than resuming on a half-edited tree - Every event is checkpointed as it arrives, so a crash mid-delegation leaves the branch at a known commit and a truthful transcript - Handback is validated locally: blank fields or a non-boolean success flag are refused and the delegation continues rather than accepting a useless note Two failure modes found by running it against a real model: - A success claim with nothing changed was accepted. The handback plus file state is the entire interface back, so a note describing work that does not exist is worse than no note. Success now requires a successful mutating tool call; reporting failure still does not, since "this is impossible" is a legitimate finding - The delegate invented the absolute path /workspace, wrote there, ran its tests there, and handed back truthfully — with the repo empty and git seeing nothing. Writes outside the workspace are now refused with a message naming the real root, and both prompts state where the workspace is instead of leaving the model to guess. This is not sandboxing: work outside the repo is invisible to git, so the milestone would publish an empty PR 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.