toolroll 0.9.51 → 0.9.53

package/CHANGELOG.md

@@ -1,5 +1,25 @@
 # Changelog
 
+## 0.9.53 — 2026-10-08
+
+- **Fewer features to learn.** Contests, held sessions and fallback chains
+  are gone. Routines are now scheduled flows; existing routines migrate,
+  paused, and `toolroll routine` points you to flows.
+- **Schedule limits hold.** Moving a flow card can't reset its spending or
+  single-flight limits.
+
+## 0.9.52 — 2026-10-07
+
+- **Smaller database.** Process logs are compacted after each run, so the
+  database file shrinks (one install went from about 116 MB to 26 MB), and
+  backups shrink with it. The action ledger is checkpointed automatically.
+- **Lighter under the hood.** Update checks read history with bounded memory,
+  and live views update without database triggers.
+- **Honest release check.** It runs every unit test on 8 workers, and its
+  tests check behaviour at runtime instead of reading source text.
+- **Webhook alerts keep working.** Legacy Slack and Discord webhooks still
+  send this release, with a notice pointing to Chat settings.
+
 ## 0.9.51 — 2026-10-07
 
 - **No lockout by username.** Wrong passwords slow the source that sent them,

package/README.md

@@ -163,7 +163,10 @@ failed when a result is marked complete.
 - **Triggers start cards on their own.** A button with a few questions, a
   schedule, GitHub (new issues, a label being added, new pull requests,
   failed checks), Linear (a team, a state, a label), or another flow's cards
-  reaching a zone. GitHub is checked through your `gh` login and Linear
+  reaching a zone. A schedule can carry a standing order — the exact task to
+  file each time, with its own per-run budget and a rolling 7-day cost
+  ceiling — and runs one at a time, skipping while the last task is
+  unfinished. GitHub is checked through your `gh` login and Linear
   with an API key kept on this computer; neither spends model tokens. Each
   issue or run makes at most one card; text from outside the repository's
   team is left out unless you say anyone. With a public address, GitHub,
@@ -361,7 +364,7 @@ for people splitting those parts across machines.
    mandatory review step. Older results retain their own links.
 
 Specialized views remain in **Tools** and **Settings**: the activity ledger, the review cockpit,
-routines (tasks that file themselves on a schedule), the fleet,
+the fleet,
 people (invite a second approver), the operating mode (a signed, expiring
 envelope that pre-approves your own filings), and **chat** — the mate, one
 conversation across every project, which only ever proposes.
@@ -597,16 +600,17 @@ deployment require their own authority and checks.
 
 Which agent plans, builds, and repairs a task is decided once, from
 signed facts, and written down with its reasons. The route reads the task's
-declared **risk** (routine, elevated, high), its quality mode, what the
+**size** (small, medium, large, risky or not), its quality mode, what the
 acceptance rubric demands (screenshots, manual review), how far a live
-operating mode may carry the result unattended, and the agents you configured for each phase. Strength is never
+operating mode may carry the result unattended, each provider's plan room, and
+the agents you configured for each phase. Strength is never
 inferred from a model's name: the ordinary phase row is the routine tier, and
 `config set <phase> --tier strong --provider <p> --model <m>` names the agent
-high-risk, strict, screenshot-proof, and automerge routes reach for. With no
+large or risky, strict, screenshot-proof, and automerge routes reach for. With no
 strong row, a demanding task keeps the default and says so.
 
 ```
-toolroll task scope <id> --goal … --acceptance … --risk high
+toolroll task route <id> --size large --as you --token <t>
 toolroll task route <id>                     # every leg, its reason, its readiness
 toolroll task route <id> --phase build --provider codex --model gpt-5-codex --as you --token <t>
 toolroll task route <id> --clear-phase build --as you --token <t>
@@ -625,8 +629,8 @@ an exact model too, and a plan override becomes the planner pin.
 Every override is recorded under the approver's name, in one transaction that
 checks the scope you were reading is still the one on file (`--digest`, or the
 form's own field). Approval seals the route — routine-shaped routes included —
-together with any configured fallback chain, exactly as it seals the execution
-profile; a later risk change or override re-files the scope and the old
+exactly as it seals the execution profile; a later size change or override
+re-files the scope and the old
 approval reads stale, while a global configuration change can never rewrite a
 sealed route. A row filed before routing existed is recognised by a durable
 marker and stays governed by its sealed profile; a routed row whose route data
@@ -636,44 +640,35 @@ readiness without spending — at startup and with `providers --report`, never
 on a timer — and the task page, the chat, and `task show` say **ready**,
 **unavailable** (with the runner's own words), or **unknown** beside the
 agents, outside what the approval signs; an unavailable provider halts before
-any claim and is never substituted, except that an unavailable primary under
-an approved fallback chain moves to the exact approved next entry (and only
-under a live mode that allows paid fallback). Fallback admission re-check readiness and the exact leg inside their transactions.
-Every run is stamped with its route and the actual provider and model at
+any claim and is never substituted. When a provider's plan runs out mid-build,
+the attempt fails with its reason like any other failure and the task waits
+for a retry or for you; nothing switches to another agent or account on its
+own. Every run is stamped with its route and the actual provider and model at
 admission — set once; a run that would spend as anything else refuses.
 
 Admission proves that stamp before any run row exists: its shape (a known
 phase, provenance word, and provider; a digest; an exact, argv-safe model id),
 its phase against the run's role, its provider and model against what the run
 would spend as, and its provenance against the authority the task actually
-holds — the sealed route's digest and that phase's exact leg, the one approved
-fallback-chain entry the run is bound to for a `fallback` run (two entries
-that share a provider and model but differ in auth mode or repair model are
-different authorities, and an ambiguous pair proves nothing), or a proven
+holds — the sealed route's digest and that phase's exact leg, or a proven
 pre-routing row for `legacy`, whose stamp must name the very sealed profile
 (and, for a build or repair, its exact pair) — the bare word `legacy` belongs
 only to a task with no scope. A task filed under routing never opens an
 unstamped run, and the store dictates nothing: every planner, builder, scout,
-reviewer, repair turn, and fallback **presents** the exact authority it holds
+reviewer, and repair turn **presents** the exact authority it holds
 (`routeAuthorityFor` puts it in the caller's hands, in words), and a missing,
 forged, stale, or inexact stamp opens no row — the refusal names what would
-have had to be presented. Chain custody is proved and written in the same
-insert: base custody opens the task's fallback cycle with the row, a
-parked-resume takes the parked tail's custody through the proven transfer,
-a repair turn inherits exactly its same-task parent's binding, and a fallback
-entry is admitted only when everything it is told — the task, the live cycle,
-the approved chain, the index, the entry digest, provider, model, auth mode,
-repair model, and `fallback` provenance — re-proves against durable state; a
-binding that cannot be proved rolls the insert back, and a mismatch creates no
-run and consumes no edge. A reviewer after a fallback spawns under the review
-leg and takes no custody. A run admitted under a route the scope has since
-re-sealed away refuses to spend. Malformed authority — corrupt route, profile,
-chain, or fallback JSON, a model id that is not one, a turn bound or clock
-that is not a positive whole number, a run row whose chain index or auth mode
-does not read — fails closed in words and never shrinks: a fallback row that
-cannot be read files the scope unresolved rather than sealing a single profile
-nobody configured, and an unreadable binding is no binding, never the base
-entry or the subscription credential.
+have had to be presented. A repair turn mends exactly its same-task parent
+under the claim that holds the task now. A run admitted under a route the scope
+has since re-sealed away refuses to spend. Malformed authority — corrupt route
+or profile JSON, a model id that is not one, a turn bound or clock that is not
+a positive whole number — fails closed in words and never shrinks.
+
+Fallback chains and the declared risk level were removed (schema v115). An
+unfinished task that was filed or approved with fallback agents asks again
+after the update — its scope says so, and saving it once chooses its
+agents; finished tasks and routes sealed at elevated or high risk keep their
+exact bytes and still verify.
 
 Codex resumes carry their sandbox as a configuration override (`-c
 sandbox_mode=…`): `codex exec resume` has no `--sandbox` flag, so a structured
@@ -683,49 +678,37 @@ the planning attempt with its typed reason — the recorded session is not
 resumed twice — and the next attempt, after the planning backoff, is a fresh
 planner root in a fresh session.
 
-A **routine** freezes its agents too. Filing a standing order resolves its
-four-role route from the configuration of that moment and binds it into the
-digest you sign; approval seals the snapshot, and every firing re-hashes that
-snapshot against the approval, holds the build and repair legs to the sealed
-profile's exact provider and model, copies it onto the instance verbatim, and
-rolls the whole firing back unless the instance seals under it — a later
-`config set` cannot re-route a firing. One integrity projection answers
-every question about a standing order's agents — what the page says, whether
-a password may be minted, whether a yes may land, whether a firing may proceed
-— read before any write: an approval is *live* only when its frozen snapshot
-reads back, hashes with the stored terms to the digest the approver signed,
-states no leg problem, and agrees with the sealed profile's build and repair
-pairs. A routine approved before agents were frozen (an upgrade from before
-v48), one whose snapshot cannot be read, or one whose snapshot no longer
-verifies fires nothing and pages once; its page and `routine show` say so and
-offer the one road: `toolroll routine refresh <name>` (or the page's
-**Refresh agents** button) re-resolves the agents from today's configuration,
-withdraws an approval that is not live even when the working agents are
-unchanged, and approves nothing — you read the exact agents it now names and
-approve it again with your password, and only that yes fires the new
-snapshot. An authentic v47 database, or one whose v47→v48 upgrade was
-interrupted, upgrades without re-running older data passes, changing ids,
-backfilling a route, or approving anything.
+A **scheduled flow** with a standing order files an ordinary task each time
+it fires: the order's terms (goal, exclusions, touches, requirements, success
+checks, per-run budget) are copied into the task's scope unchanged, and the
+task waits for approval under the project's approval rules like any other
+proposal. A standing order moved over from an old routine keeps that routine's
+approval and its frozen agents while they still verify: each firing re-hashes
+the frozen snapshot against the approval, holds the build and repair legs to
+the sealed profile's exact provider and model, and rolls the whole firing back
+unless the task seals under it — a later `config set` cannot re-route it. Once
+that approval no longer verifies, each firing says why and waits for approval
+as an ordinary proposal. `toolroll flows show` prints a standing order's
+terms; `toolroll flows trigger pause|resume` (or **Resume** on the flow canvas)
+stops and starts its schedule.
 
 Every approval surface — the task page, the focused chat, and `/next` — shows
-the same concise line of exact agents above the password, with the declared
-risk explained in plain words and the runtime limits one tap away; changing
+the same concise line of exact agents above the password, with why stronger
+agents run explained in plain words and the runtime limits one tap away; changing
 any agent invalidates the approval every surface signed under. Where no yes
-could bind — an unreadable route, a route that cannot run, a standing order
-without frozen agents, or a pre-routing row whose old approval no longer
-stands — those surfaces mint no nonce and show no password or approve button,
-only the reason and the act that opens it (re-file the scope, change the
-agents, refresh the routine) — the inbox row reads *needs attention* rather
-than *review & approve*, and the routine's recovery is one labelled, described
-button with nothing to type; an old approval already on a pre-routing row is
-grandfathered, but no new yes lands on it. In the demo sandbox, Chat is a
+could bind — an unreadable route, a route that cannot run, or a pre-routing
+row whose old approval no longer stands — those surfaces mint no nonce and
+show no password or approve button, only the reason and the act that opens it
+(re-file the scope or change the agents) — the inbox row reads *needs
+attention* rather than *review & approve*; an old approval already on a
+pre-routing row is grandfathered, but no new yes lands on it. In the demo sandbox, Chat is a
 scripted lead that never calls a model; real chat evidence is a subscription-backed plane. The task page's controls offer,
 per role, only the agents you configured *for that role* (gemini never
 reviews; repairs stay on the build provider), a current agent the
 configuration no longer names is shown for what runs today and never offered
-again, and each risk level says what it does — truthfully under strict
-quality and screenshot proof too. Chat reads the same route (`get_agents`)
-and proposes one confirmation-gated change (`propose_agents`) — a risk, one
+again, and each size says what it does — truthfully under strict quality and
+screenshot proof too. Chat reads the same route (`get_agents`)
+and proposes one confirmation-gated change (`propose_agents`) — a size, one
 role switched to a listed agent, or a hand-picked role cleared — which lands,
 when you confirm the card, through the same authenticated route edit the page
 uses; the chosen agent is re-proved against the role's configured choices
@@ -947,9 +930,6 @@ Everything below ships in 0.4.0:
   dependencies (cycles refused), "starts after" on the filing form,
   `task next` moves work to the front of its own queue. Scheduling,
   never authority: approvals are untouched by any of it.
-- **Tournaments** — race 2–4 agents on one task under native dollar
-  caps, compare their verified diffs side by side, and pick one through
-  a password ceremony; the losers' branches and evidence are kept.
 - **The live peek** — a running build's page shows what is changing in
   its checkout right now (names and counts, never contents), through a
   native reader that executes nothing — no git command ever runs
@@ -967,8 +947,7 @@ Everything below ships in 0.4.0:
   into one new approval-bound task.
 - **Operating modes** — a per-repository, password-signed, expiring
   envelope that pre-authorizes the SIGNER'S OWN future acts: your
-  filings approve themselves the moment you file them, watched sessions
-  start without retyping your password, merges fire themselves when CI
+  filings approve themselves the moment you file them, merges fire themselves when CI
   is seen green on the exact authorized commit (only through a merge
   grant, never around one), and daily run/dollar rails bound the spend.
   Every term renders in words at the signing ceremony — including the
@@ -981,7 +960,7 @@ Everything below ships in 0.4.0:
   re-verified against its recorded hash, comments are proven
   patch-local, and they land beside your own for YOU to prune and seal
   into a revision task. A revision keeps the source's contract — its
-  goal, exclusions, touches, exact rubric, declared risk, quality,
+  goal, exclusions, touches, exact rubric, quality,
   permission posture, and budget ceiling — however the installation's
   defaults have changed since, re-resolves its agents for a fresh
   approval, and inherits no approval, session, publication, or merge
@@ -1004,10 +983,6 @@ Everything below ships in 0.4.0:
   doing what, and remove access with one ceremony that actually severs:
   sessions, invites, and every mode they signed end together, while
   history stays attributed forever.
-- **Watched sessions, plural** — run several attended sessions per
-  worker under one signed ceiling, each with its own model and
-  permission posture chosen at mint, the whole execution profile under
-  the signature.
 - **Scout tasks** — `task add … --report` (or the "scout" checkbox, or
   the mate's `propose_task` with `report: true`) files a task whose
   deliverable is a report, never a branch: once its scope is approved,

package/dist/agentconfig.d.ts

@@ -20,8 +20,8 @@
  * the caller snapshots it into the run row.
  */
 import { type AgentSpec, type Phase } from "./provider.js";
-import { type Store, type TaskRef } from "./store.js";
-import { type ChainEntry, type ExecutionProfile, type UnattendedPermissionMode } from "./scope.js";
+import type { Store, TaskRef } from "./store.js";
+import { type ExecutionProfile, type UnattendedPermissionMode } from "./scope.js";
 import { type ExactSpec, type PhaseRoute, type RouteCandidates } from "./phase-routing.js";
 import type { AcceptanceCriterion } from "./scope.js";
 export declare const INSTALLATION_SCOPE = "installation";
@@ -66,30 +66,6 @@ export declare function resolveScopeProfile(store: Store, repo: string | null, r
     repairModel?: string | undefined;
     permissionMode?: UnattendedPermissionMode | undefined;
 }): ProfileResolution;
-export type ChainResolution = {
-    ok: true;
-    chain: ChainEntry[];
-    kind: "profile" | "chain";
-} | {
-    ok: false;
-    reason: "base-unresolved" | "bad-fallback" | "duplicate";
-    problem: string;
-};
-/**
- * Resolve the full EXECUTION CHAIN a scope files under (v30): the base
- * (entry 0) is the ordinary single-profile resolution wearing the base
- * provider's auth mode; the fallbacks are the scope's configured entries,
- * each resolved to a WHOLE ExecutionProfile (repair per entry). With no
- * fallbacks configured, the result is `kind: "profile"` — a single-profile
- * approval, byte-identical to today (NOT an explicit chain). With
- * fallbacks, it is `kind: "chain"` and the approval binds the whole thing.
- * The base auth mode is passed in (the caller reads it from the managed
- * key store) so resolution stays pure and testable.
- */
-export declare function resolveScopeChain(store: Store, repo: string | null, ref: Pick<TaskRef, "agentProvider" | "agentModel"> | undefined, flags: PhaseFlags & {
-    repairModel?: string | undefined;
-    permissionMode?: UnattendedPermissionMode | undefined;
-}, baseAuthMode: "subscription" | "api-key"): ChainResolution;
 /**
  * The two candidate tiers the routing policy chooses between, per phase,
  * read from configuration ONLY — never inferred from a model's name:
@@ -166,16 +142,15 @@ export type TaskRoute = {
 };
 export declare function routeOfTask(store: Store, taskId: string, ref: TaskRef | null, now: Date): TaskRoute | null;
 /**
- * THE ROUTINE'S FROZEN AUTHORITY, resolved once at filing: the four-role
- * route a routine's firings will run under, and the execution profile that
- * restates its build and repair legs exactly. Routine tasks declare routine
- * risk; the rubric's evidence needs, the installation's quality default,
- * and the repository's publication authority are the other signed inputs.
- * A configuration that cannot make an exact, runnable route answers with
- * the words — the routine files unresolved and cannot be approved until
- * it is filed again under a configuration that can.
+ * THE EXACT AUTHORITY a project's configuration names today: the four-role
+ * route work would run under, and the execution profile that restates its
+ * build and repair legs exactly. The rubric's evidence needs, the
+ * installation's quality default, and the repository's publication
+ * authority are the other inputs. A configuration that cannot make an
+ * exact, runnable route answers with the words (the recipes preview shows
+ * them before any work is created).
  */
-export type RoutineAuthority = {
+export type AgentAuthority = {
     ok: true;
     route: PhaseRoute;
     profile: ExecutionProfile;
@@ -183,7 +158,7 @@ export type RoutineAuthority = {
     ok: false;
     problem: string;
 };
-export declare function resolveRoutineAuthority(store: Store, repo: string, acceptance: readonly AcceptanceCriterion[], now: Date): RoutineAuthority;
+export declare function resolveAgentAuthority(store: Store, repo: string, acceptance: readonly AcceptanceCriterion[], now: Date): AgentAuthority;
 /** One agent a surface shows for one role: an exact pair, where it comes
  * from, whether it is the role's current leg, and whether it can be
  * CHOSEN — only a pair the active configuration names for this role is

package/dist/agentconfig.js

@@ -20,9 +20,7 @@
  * the caller snapshots it into the run row.
  */
 import { isProviderId, validateSpec } from "./provider.js";
-import { contestantProfileOf } from "./store.js";
-import { CLAUDE_LIMITS, CODEX_SHAPED_LIMITS, GEMINI_LIMITS, chainFromJson, canonicalChainJson } from "./scope.js";
-import { SUBSCRIPTION_CAPABLE } from "./keys.js";
+import { CLAUDE_LIMITS, CODEX_SHAPED_LIMITS, GEMINI_LIMITS } from "./scope.js";
 import { exactModelId, legOf, PHASES, recommendRoute, routeFromJson, routeProblems, sameSpec } from "./phase-routing.js";
 export const INSTALLATION_SCOPE = "installation";
 /**
@@ -177,61 +175,6 @@ export function resolveScopeProfile(store, repo, ref, flags) {
             };
     return { ok: true, profile, provenance: { resolvedFrom: build.source, repairFrom } };
 }
-/**
- * Resolve the full EXECUTION CHAIN a scope files under (v30): the base
- * (entry 0) is the ordinary single-profile resolution wearing the base
- * provider's auth mode; the fallbacks are the scope's configured entries,
- * each resolved to a WHOLE ExecutionProfile (repair per entry). With no
- * fallbacks configured, the result is `kind: "profile"` — a single-profile
- * approval, byte-identical to today (NOT an explicit chain). With
- * fallbacks, it is `kind: "chain"` and the approval binds the whole thing.
- * The base auth mode is passed in (the caller reads it from the managed
- * key store) so resolution stays pure and testable.
- */
-export function resolveScopeChain(store, repo, ref, flags, baseAuthMode) {
-    const base = resolveScopeProfile(store, repo, ref, flags);
-    if (!base.ok)
-        return { ok: false, reason: "base-unresolved", problem: base.problem };
-    const unreadable = repo === null ? null : store.fallbackConfigProblem(repo);
-    if (unreadable !== null)
-        return { ok: false, reason: "bad-fallback", problem: unreadable };
-    const fallbacks = repo === null ? [] : store.fallbackConfig(repo);
-    if (fallbacks.length === 0) {
-        // No fallbacks: a legacy single-profile approval, unchanged.
-        return { ok: true, chain: [{ profile: base.profile, authMode: baseAuthMode }], kind: "profile" };
-    }
-    const entries = [{ profile: base.profile, authMode: baseAuthMode }];
-    for (const one of fallbacks) {
-        if (!isProviderId(one.provider) || one.model === undefined || one.model === "") {
-            return { ok: false, reason: "bad-fallback", problem: `a fallback entry names an unknown provider or empty model (${one.provider}:${one.model})` };
-        }
-        if (one.authMode !== "subscription" && one.authMode !== "api-key") {
-            return { ok: false, reason: "bad-fallback", problem: `a fallback entry has an unknown auth mode` };
-        }
-        // An entry can only pin an auth mode its provider can actually take:
-        // "subscription" on a provider with no login (openrouter) would seal an
-        // entry that can never authenticate (E3d, gateway pin).
-        if (one.authMode === "subscription" && !SUBSCRIPTION_CAPABLE[one.provider]) {
-            return { ok: false, reason: "bad-fallback", problem: `${one.provider} has no subscription login — this entry must use an API key` };
-        }
-        // The model rides provider argv (F+G review, finding 1): the SAME
-        // argv-safety validation every other sealed model passes — never a
-        // leading dash, control bytes, or whitespace into a harness's argv.
-        const argvSafe = validateSpec({ provider: one.provider, model: one.model });
-        if (!argvSafe.ok) {
-            return { ok: false, reason: "bad-fallback", problem: argvSafe.problem };
-        }
-        entries.push({ profile: contestantProfileOf(one.provider, one.model, one.repairModel ?? "inherit", flags.permissionMode ?? store.permissionDefault().mode), authMode: one.authMode });
-    }
-    // Re-prove the whole chain through the strict rehydrator: it rejects
-    // exact-duplicate entries and any malformed shape, so what the approval
-    // seals is exactly what dispatch will re-derive.
-    const proven = chainFromJson(canonicalChainJson(entries));
-    if (proven === null) {
-        return { ok: false, reason: "duplicate", problem: "the fallback chain has a duplicate entry (same profile and auth mode) or is malformed" };
-    }
-    return { ok: true, chain: proven, kind: "chain" };
-}
 const PHASE_NOUN = { plan: "planner", build: "builder", repair: "repair", review: "reviewer" };
 export function resolveRouteCandidates(store, repo, pins = {}) {
     // The LIGHT tier (v2): the operator's named fast builder, project over
@@ -289,7 +232,7 @@ export function resolveRouteCandidates(store, repo, pins = {}) {
         if (!routine.ok)
             return { ok: false, problem: routine.problem };
         if (routine.spec.model === null || routine.spec.model === "") {
-            // A PINNED exact pair (a routine firing's approved profile, a plan
+            // A PINNED exact pair (an approved standing order's frozen profile, a plan
             // request's pin) is the phase's agent whatever the configuration
             // says — it stands in as the candidate when nothing exact is
             // configured, so a firing never depends on today's config.
@@ -417,7 +360,6 @@ export function routeOfTask(store, taskId, ref, now) {
     if (!candidates.ok)
         return { kind: "unreadable", problem: candidates.problem };
     const route = recommendRoute({
-        risk: ref?.riskLevel ?? "routine",
         qualityMode: ref?.qualityMode ?? store.qualityDefault().mode,
         evidence: [],
         publication: store.publicationAuthorityOf(repo, now),
@@ -429,12 +371,11 @@ export function routeOfTask(store, taskId, ref, now) {
     });
     return { kind: "route", route, source: "live" };
 }
-export function resolveRoutineAuthority(store, repo, acceptance, now) {
+export function resolveAgentAuthority(store, repo, acceptance, now) {
     const candidates = resolveRouteCandidates(store, repo);
     if (!candidates.ok)
         return { ok: false, problem: candidates.problem };
     const route = recommendRoute({
-        risk: "routine",
         qualityMode: store.qualityDefault().mode,
         evidence: [...new Set(acceptance.flatMap(one => one.evidence))],
         publication: store.publicationAuthorityOf(repo, now),

package/dist/approval-policy.d.ts

@@ -12,7 +12,7 @@
  */
 /** Who filed a task, as far as anyone can tell: a person (browser, chat, a
  * revision), a coordinator acting for the person who made it, an AI
- * teammate, or automation that names no person (a routine, the CLI, a flow
+ * teammate, or automation that names no person (a schedule, the CLI, a flow
  * with no owner). The requester rule binds only a named person. */
 export type FilerKind = "person" | "coordinator" | "teammate" | "automation";
 export type Filer = {

package/dist/approval-policy.js

@@ -133,5 +133,5 @@ export function gateWords(gate) {
             : `Your approval is recorded (${gate.have} of ${gate.need}). This work is protected, so a second person needs to approve it.`;
     return gate.reason === "requester"
         ? "You filed this task, and this project needs someone else to approve it."
-        : "This work is protected: a person has to approve it, not an operating mode, a routine or an AI teammate.";
+        : "This work is protected: a person has to approve it, not an operating mode, a schedule or an AI teammate.";
 }

package/dist/backup.d.ts

@@ -31,12 +31,20 @@ export declare function backupFiles(folder: string, owner: BackupOwner): {
 }[];
 /** Remove all but this database's newest `keep` backups. Never touches another database's, or anything else in the folder. */
 export declare function pruneBackups(folder: string, keep: number, owner: BackupOwner): number;
+/** The checkpoint made before a backup: the head it records, a broken chain's first break (none recorded), or null (nothing new since the last). */
+export type BackupCheckpoint = {
+    through: number;
+    hash: string;
+} | {
+    problem: string;
+} | null;
 export type BackupOutcome = {
     ok: true;
     id: number;
     file: string;
     bytes: number;
     removed: number;
+    checkpoint: BackupCheckpoint;
 } | {
     ok: false;
     id: number;

package/dist/backup.js

@@ -164,6 +164,15 @@ export async function backupNow(store, databaseFile, trigger, clock = () => new
         let name = `standing-orders-${stamp}.db`;
         for (let n = 2; existsSync(join(folder, name)); n++)
             name = `standing-orders-${stamp}-${n}.db`;
+        // The whole chain walked and its head checkpointed first, so the copy carries the checkpoint. A broken chain gets
+        // none (the walk raises the console's chain alarm, as any whole walk does); the backup goes ahead either way.
+        let checkpoint;
+        try {
+            checkpoint = store.ledgerCheckpoint("system", clock(), {});
+        }
+        catch (error) {
+            checkpoint = { problem: message(error) };
+        }
         partial = join(folder, `.${name}.${randomBytes(4).toString("hex")}.partial`);
         const made = await onlineCopy(databaseFile, partial);
         const file = join(folder, name);
@@ -171,7 +180,7 @@ export async function backupNow(store, databaseFile, trigger, clock = () => new
         partial = null;
         const removed = pruneBackups(folder, settings.keep, backupOwner(store, databaseFile));
         store.finishBackupRun(id, { ok: true, file, bytes: made.bytes, schemaVersion: made.schemaVersion, removed }, clock());
-        return { ok: true, id, file, bytes: made.bytes, removed };
+        return { ok: true, id, file, bytes: made.bytes, removed, checkpoint };
     }
     catch (error) {
         if (partial !== null)

package/dist/board.d.ts

@@ -57,17 +57,9 @@ export type BoardFacts = {
     liveRunId?: number | null;
     /** The top-precedence live hold: operator > backoff > decision > incident. */
     hold: {
-        ownerKind: "operator" | "decision" | "incident" | "backoff" | "contest";
+        ownerKind: "operator" | "decision" | "incident" | "backoff";
         until: string | null;
     } | null;
-    /** The task's open tournament, when agents raced (v14). Optional so
-     * callers that predate tournaments stay valid; absent reads as none. */
-    contest?: {
-        id: number;
-        state: string;
-        agents: number;
-        kind?: "race" | "comparison";
-    } | null;
     /** The first blocker that is not done, when one exists. */
     unmetDependency: string | null;
     /** That blocker's state — pre-redacted by the caller to null when the
@@ -76,11 +68,6 @@ export type BoardFacts = {
     blockerState: string | null;
     /** The first required capability not currently verified, as "kind:name". */
     missingRequirement: string | null;
-    /** The standing order this task is an instance of, when it is one. The
-     * board keeps instances in their track row — they enter the main lanes
-     * only when they need a person, wearing the routine's name. */
-    routineId: number | null;
-    routineName: string | null;
     /** Queue rank — 0 is filing order. Scheduling only; ranks compare
      * within one column, never across columns. */
     priority?: number;
@@ -102,8 +89,6 @@ export type BoardCard = {
     /** The live attempt's ordinal when earlier ones failed — building only. */
     attempt: number | null;
     overdue: boolean;
-    /** The routine this card is an instance of — the chip it wears in lanes. */
-    routineName: string | null;
     /** The task's queue rank, carried for the queued lane's sort and badge. */
     priority: number;
     /** The worker this card is reserved for; null = the shared queue. */
@@ -111,9 +96,8 @@ export type BoardCard = {
 };
 /**
  * Plain words for every hold owner — shared with the task page so "who is
- * holding this" reads the same everywhere. The internal owner tokens
- * ("contest") never reach a page; an unknown future owner degrades to the
- * generic word, never to its raw name.
+ * holding this" reads the same everywhere. An unknown or retired owner
+ * degrades to the generic word, never to its raw name.
  */
 export declare const HOLD_OWNER_WORDS: Record<string, string>;
 export declare function holdOwnerWords(ownerKind: string): string;