dongarandClaude Opus 5.5
b8df5d2066
CI / checks (push) Skipped
CI / checks (pull_request) Successful in 52s
C2's per-tool allow/deny/confirm taxonomy would have to be written in advance for a tool catalog that will grow large, and every mistake in it is friction or a hole. An ops write plan is now a list of literal steps (tool, target, arguments, optional precondition and expected outcome, retry allowance), and one approval covers exactly that sequence: - Code renders the approval message from the steps, flagging irreversible steps, protected targets, and steps that take down the agent's own host - A matcher checks every call: read-only is free, an elevated call must exactly match the next approved step (arguments normalized against the tool's schema), and anything else halts to AWAIT_INPUT - Approvals expire if the plan does not start in time - Classification shrinks to a versioned policy file: instance privilege, protected targets, and each elevated tool's target argument, all failing safe; MCP annotations may only tighten - Bounded matching and standing approvals are deferred, with reasons Supporting changes: - A3: an approved sequence resumes after the agent's own restart only on a verified expected outcome for the step in flight - A4: an operator kill switch, `stop`, for every agent - 0.2: the agent may switch items on its own while the active one waits on the operator; parking unmounts elevated instances; a Matrix reply to a parked item binds to that item - A17: step preconditions replace the staleness bounds, the log-checked verification precondition and the boot-time re-fetch - A18 (new): prompt injection, designed around limiting what a compromised model can do rather than detecting injection - Part H records the decision and parks the deferred items 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.