Nick
5a87338a67
Run 353's debug proved: adding a label emits action=label_updated with the payload label present; 'labeled' never fires. Gate accepts both spellings and verifies the issue's current labels.
Rune — Stateful Coding Assistant with Elastic Cognition
Rune is a stateful coding assistant that dynamically spends the minimum cognition needed for reliable results.
Quick Start
# Launch Rune
rune
# Or from the source directory
cd /mnt/workdrive/rune/src
python3 -m rune
Architecture
Rune v1 authority source
Rune v1 admits runtime changes through the machine-readable
config/v1_authority_map.json and the human decision record at
docs/v1/AUTHORITY_MAP.md. These distinguish current execution authority from
the intended v1 owner and classify every parallel path as retained, adapter,
archive candidate, or dormant.
No subsystem may inject model context outside the future authoritative ContextBroker. The map is an admission and migration plan; it does not claim those migrations are already implemented.
Rune's ordinary v0.49.0 turn currently runs through RuneApp → RuneOperator →
LocalToolRuntime. The repository also contains the following layered Elastic
Cognition prototypes. They are migration candidates, not the authoritative live
path; ownership is recorded in docs/v1/AUTHORITY_MAP.md.
- Response Adapter — Normalizes provider output (strips reasoning leakage)
- Event Envelope — Normalizes all inputs (user messages, task events, tool results)
- Salience Gate — Decides if cognition beyond deterministic handling is needed
- Cognitive Budgeter — Decides how much cognition the event deserves
- Model Registry — Configurable resource ladder (T0-T4)
- Tiered Executor — Routes to appropriate tier
- Verification Layer — Objective checks (exit codes, tests, schemas)
- Progressive Escalation — Only when evidence warrants it
- Attention Capsule — Compact working set (300-600 tokens)
- Outcome Ledger — Performance tracking
Elastic Cognition target/prototype
Event
-> EventEnvelope (normalize input)
-> SalienceGate (does this deserve cognition?)
-> CognitiveBudgeter (how much cognition?)
-> TieredExecutor (cheapest competent process)
-> VerificationLayer (objective checks)
-> ProgressiveEscalation (only if needed)
-> ResponseAdapter (strip reasoning leakage)
-> RuneResponse (one clean response)
Cognitive Resource Ladder
T0 — deterministic
Python, parsers, retrieval, schemas, tests
T1 — cheap local
qwen2.5:3b or measured equivalent
T2 — medium local
qwen3:14b and/or qwen2.5-coder:14b
T3 — strong local
Qwen3.6 27B Fable Fusion through Ollama
T4 — cloud
MiMo V2.5 Pro
Commands
/project <name> — set subject header
/mode <mode> — switch mode (task/chat/build/research/plan)
/model <model> — switch model (local/cloud/auto/<name>)
/theme <name> — switch theme
/persona — show defining principles
/abstraction — show abstraction pipeline stats
/claims — show claim audit report
/neurons — show warm neuron stats
/graph — show graph memory stats
/pressure — show context pressure
/events — show event bus stats
/plugins — show microkernel status
/env — show environment info
/persona-gate — show persona gate decision
/hooks — show hook engine status
/growth — show growth delta
/improve — show self-improvement suggestions
/voice — show voice blend
/voice-sync — show voice sync status
/drift — show drift ledger status
/sleep — show sleep-time status
/help — show available commands
Native Modules
27 modules import natively with zero subprocess overhead:
- warm_router, capability_broker, memory_store, witness, cache
- model_connect, task_persist, pins, prompt_sync, abstraction
- claim_audit, memory_env, warm_neuron_store, graph_memory
- context_pressure, event_bus, microkernel, persona_gate
- hook_engine, growth_delta, self_improve, recall_router
- voicebox, voice_hybrid, voice_sync, sleep_time, drift_ledger
Configuration
Configuration is stored in /mnt/workdrive/rune/config/rune.json.
Governed builds
Explicit fix and build requests use the canonical ledger/worktree → research → pin findings → feasibility → complexity → consult → plan → canaries → consent → Foundation → Implementation → Integration → verification → scope guardian → documentation → commit/push → Gitea PR/CI → record pipeline. Each code change is linked to a Gitea issue, isolated branch, pull request, and protected required checks. Routine work defaults to local models and Gitea Actions; placeholder phase output is never accepted as evidence that a command, push, or check ran.
Local tools and interstitial objects
Tool-capable Ollama models use native /api/chat tool calls. Other local
models use a validated compatibility protocol. Read-only calls execute through
the tool authority boundary; mutations pause for explicit approval and are
revalidated before one-time execution.
The TUI renders thinking, tool calls, results, approvals, and assistant chat as separate typed objects. Tool objects appear before the assistant continuation, so chat remains interstitial rather than swallowing protocol data as prose.
Memory
Memory is stored in /mnt/workdrive/rune/memory/.
Development
# Run canary to verify all imports
cd /mnt/workdrive/rune/src
python3 rune/canary_native.py
# Run tests
python3 -m pytest tests/
Gitea repository state
Branch protection, the 11 managed labels, three milestones, and six wiki pages are declared in the declarative repository state. Wiki bodies are tracked as Markdown under the wiki documentation.
# Read-only drift check (also the default when no mode is supplied)
python3 shared/gitea_provision.py --check
# Create or update managed state, then verify convergence
python3 shared/gitea_provision.py --apply
The provisioner loads credentials at runtime through shared/gitea_auth.py.
Set GITEA_TOKEN, or use its mode-0600 token file. Check mode sends GET
requests only. Apply mode never deletes labels, milestones, wiki pages, or
other unmanaged repository objects.
Gitea backup and restore verification
The daily backup action invokes the root-owned
/usr/local/sbin/rune-gitea-backup on the Gitea host. It stops Gitea only for
the official gitea dump, restores service and verifies health, validates all
mandatory archive members, and publishes the archive, metadata, and SHA-256
sidecar to the separate Foundry disk. The checksum is linked last as the
publication commit marker, and complete backup sets have bounded retention.
Before creating the backup directory or dumping, the helper requires
BACKUP_MOUNT (default /media/pi/Foundry) to be the exact active mount,
requires BACKUP_DIR to remain inside it lexically and after symlink
resolution, and verifies that its backing device differs from /.
Run it only through the installed, administrator-controlled entry point:
sudo /usr/local/sbin/rune-gitea-backup
Restore verification is an explicit, rootless, disposable drill. As a
non-root user, acknowledge the guard and supply an archive with its adjacent
.sha256 sidecar:
RUNE_GITEA_RESTORE_VERIFY=1 scripts/gitea-restore-verify.sh \
/media/pi/Foundry/backups/gitea/gitea-dump-<timestamp>.tar.gz
The verifier requires the audited digest-pinned Gitea image to exist locally;
it uses --pull=never, no container network, no published ports, and a
read-only container root. It extracts only into a fresh temporary directory
and mounts only that disposable restore tree. Archived application data is
restored into /data/gitea before the reconstructed SQLite database and
generated isolated configuration overwrite archived versions. Every
database-declared repository must exist at its canonical owner/name path and
pass Git integrity checks; extra repositories such as wikis remain allowed.
Production Gitea configuration, data, repositories, and service paths are
therefore never accepted or mounted as a restore target. See the tracked
backup and restore runbook and
operations guide.
License
Private — Nick's personal AI assistant.