Register of instruments

One file

All state lives in a single SQLite file, opened once with WAL journaling, a five-second busy timeout and foreign keys enabled. There is no ORM and no migration framework: schema creation is one idempotent function of CREATE TABLE IF NOT EXISTS statements, and every later addition is a guarded ALTER TABLE … ADD COLUMN whose duplicate-column error is caught and swallowed.

try { db.prepare(`ALTER TABLE operator_progress ADD COLUMN ${col[0]} ${col[1]}`).run(); }
catch (e) { if (!/duplicate column name/i.test(String(e && e.message))) throw e; }

Twenty-four distinct tables are created across the codebase; fifteen of them by the core schema function, six by the runner library’s additive bootstrap, and the rest by the advisor and the voice arbiter.5 Uniqueness is used structurally rather than defensively: several partial unique indexes make an invalid state a hard insert error instead of a condition to be checked for.

The priority function

Urgency is computed by a pure kernel function the model cannot reach. It is deliberately separate from — and never overloaded onto — the legacy hand-set priority column, which runs in the opposite direction.

//   urgent     = deadline proximity (no deadline -> 0.5 neutral; monotone-decreasing in days-left)
//   important  = goalImportance (0..1) of task.serves_goal; default mid 0.5 when absent/unknown
//   ready      = (status !== 'blocked' && !blocker) ? 1 : 0  -> a blocked task sinks to 0
urgent = daysLeft <= 0 ? 1 : clamp01(1 / (1 + daysLeft));
const computed_priority = Number((urgent * important * ready).toFixed(4));

Each computation also writes a human-readable explanation of itself into priority_explain — for instance urgent=0.33(deadline 2.0d)×important=0.80(goal:…)×ready=1 ⇒ 0.264 — so the ranking is auditable without re-deriving it. A blocked task multiplies to zero rather than being filtered out, which keeps it visible in the ordering while sinking it.

The state hash, and what is kept out of it

A short SHA-1 over the salient board state lets a tick tell whether anything actually moved since the last one. It is computed over exactly four projections: each task as id:status:priority:blocker, each decision as id:status, each intent as id:status:policy_decision, and the identifier of the most recent instruction.

What is excluded matters more than what is included. Two categories are deliberately kept out, each with a comment explaining the failure that inclusion would cause:

• computed_priorityRecomputed on every read. Hashing it “would forge per-tick board churn into the no_progress_streak / board_unchanged_streak signal and disarm the stall monitor.”
• observations, salienceThe perceiving layer is volatile by construction; it is loaded after the hash is computed, so it can never enter it.

The same discipline governs the outcome vocabulary. An intent that the gate allowed but that nothing has executed records the outcome staged, which is classified non-advancing on purpose: “an ‘allowed’ intent that nothing fires must NOT reset the no-progress streak, else the loop looks productive while the board never moves.”

Bi-temporality, and what may be deleted

Durable rows are never destructively rewritten. A superseded goal model, an outdated belief, a retired lesson: each is closed by stamping valid_until, so history is preserved and every change is reversible. The world-model documentation states the resulting rule plainly — older active snapshots are “marked superseded, never deleted”, and “draft imports do not change the active model. Activation is explicit.”

Bulk deletion exists, but only for high-volume ephemeral logs, and it is fenced by three hard floors: never prune inside the retention window; always keep at least the most recent N progress rows regardless of age, because the cross-day streak logic reads that window and “must NEVER be starved by pruning”; and never touch the durable tables at all. The durable exclusion list is enumerated in the source: goal models, confidence, decisions, action intents, learnings, plans, memory and the state of play.

The day, and where it comes from

Almost every table is keyed by an operator day rather than a timestamp, and that day is derived from the profile’s timezone — not from the host’s clock, and not from UTC. The runner library and the state layer resolve it through the same profile-timezone source, and a cross-cutting test asserts the two agree at a clock reading near the UTC boundary, so a tick started late at night cannot land on a different day from the gate that judged it.

The same concern shapes the executor: it scans a rolling trailing window of days rather than only today, “so a cross-midnight approval/claim is never invisible.” Three days is the shipped default, and it is environment-overridable.