Nick
b142bab2f3
The unit battery on a fresh checkout: jsonschema/pytest-xdist imported but never pinned (the lock-only law) — extras extended and re-frozen; the engine-seam tests pin the PYTHON oracle in a python-only job; the three kernel-port tests skip honestly when the kernel is absent; the checker tests now pin the intent/strict duality (intent = the default CI mode, strict = the deliberate re-lock); the canary self-module import is pre-bound with raise-guards for honest narrowing. Ratchets green (84e/536w, 0/0).
Rune
Current release: v0.333.0
Highlights — from the latest release (v0.333.0)
- Plain-English jargon dictionary covers the v0.329 vocabulary, plus catch-all sentence simplification pass.
Behind-the-scenes upkeep: 1 commit(s) of docs, tests and tooling this release.
What Rune is
Rune is a personal AI agent that lives on Nick's computer and talks like a person. Ask her something in ordinary language and she answers, does the work, and remembers.
The language model inside her is deliberately treated as a replaceable part — the "thinking engine" she borrows to reason. Everything that actually makes her Rune is kept by Rune itself, independently of any one model provider:
- her memory of conversations and what happened;
- the tasks she is working on and how far they got;
- the skills and techniques she has learned;
- her own judgement, built up from real outcomes.
If the underlying model is swapped tomorrow, she is still Rune.
How you talk to her
Chat is where you simply talk. It works like a continuous conversation, not a series of separate questions: she keeps the thread, follows corrections, and answers follow-ups in context. You can keep chatting while she is busy — she works in the background and speaks when she has something to say.
Tasks is the operations board. When she is doing real work, the plan, the current step, the commands she ran, and what actually happened all show up here — recorded from what really occurred, not from what she claims. You watch the work happen without interrupting it, and finished work lands here rather than cluttering the conversation.
What she can do
- Act on the PC in task mode. Give her real work and she runs commands, reads and edits files, runs the tests, looks at the result, and tries again if it failed — checking real evidence before she says something is done. She does not accept her own word as proof.
- Remember. Conversations, task outcomes, and records persist across restarts in her own store, so a new session picks up where the last one ended.
- Learn skills. Successful techniques are kept as reusable knowledge — the skills engine runs on the Go side and its live state shows in her interface.
- Know her limits. For anything destructive or irreversible she asks first, and she separates what she is capable of from what she is authorised to do.
How to run
rune
The rune command boots the deployed chat window (a text interface in the terminal). To build the current state from source:
bash scripts/build_paired.sh
How she's built
One sentence: a Go agent core does the thinking and acting; a Go "front door" is the only door to it; the chat window in your terminal talks only to that door.
you ⇄ chat window (terminal)
⇄ front door (127.0.0.1:8377)
⇄ agent core (127.0.0.1:8376)
├── conversation & tasks
├── memory store
└── tool loop: reason → act → check → act again → verify → answer
- The agent core is the runtime: it holds the conversation, the task ledger, the memory, and the loop that lets her use tools and keep working until the job is genuinely done.
- The front door is a small Go web interface that stands in front of the core. The chat window never touches the core directly — every request goes through the door, which keeps one honest, inspectable path for everything.
- The chat window shows the two panes above (chat and tasks) plus a live activity strip, and it can run while the front door is down by carrying its own copy of the door as a child process.
The older Python runtime is being retired: new capability lands in Go, and no new Python is added.
What's real vs what's planned
Rune is under active development, and the project holds itself to a strict rule: a thing counts as real only when ordinary execution actually uses it. Code that exists but isn't wired into daily behaviour is labelled as such, not counted.
The authoritative map of what currently runs — and what is still a prototype or planned — is:
docs/v1/AUTHORITY_MAP.mdconfig/v1_authority_map.json
Documentation
docs/v1/AUTHORITY_MAP.md— what is live vs prototype vs planneddocs/wiki/Home.md— documentation indexdocs/wiki/Operations.md— operational proceduresdocs/wiki/Backup-and-Restore.md— Gitea backup and restoredocs/openspec/— experience and architecture specs
Development
Run the Go test batteries (with the race detector, the project's deep code testing):
cd src/go/release-notes && go test ./... -race
cd tui && go test ./... -race
CI installs Python dependencies only from the committed, fully-pinned requirements-ci.txt (issue #150). After any dependency edit in pyproject.toml, regenerate and commit the lock:
uv pip compile pyproject.toml -o requirements-ci.txt --extra dev --extra memory --python-version 3.11
python3 scripts/check_dep_lock.py # must print "in sync" before committing
License
Private — Nick's personal AI agent.