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.45.1 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.

1. Response Adapter — Normalizes provider output (strips reasoning leakage)
2. Event Envelope — Normalizes all inputs (user messages, task events, tool results)
3. Salience Gate — Decides if cognition beyond deterministic handling is needed
4. Cognitive Budgeter — Decides how much cognition the event deserves
5. Model Registry — Configurable resource ladder (T0-T4)
6. Tiered Executor — Routes to appropriate tier
7. Verification Layer — Objective checks (exit codes, tests, schemas)
8. Progressive Escalation — Only when evidence warrants it
9. Attention Capsule — Compact working set (300-600 tokens)
10. 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.