toolroll 0.9.55 → 0.9.56

package/CHANGELOG.md

@@ -1,5 +1,15 @@
 # Changelog
 
+## 0.9.56 — 2026-10-09
+
+- **One lead.** Your assistant in the console, on your phone, in chat and in
+  the CLI is the same lead. Teammates are now its subagents, with their
+  personalities and rules: "ask Rosa to…", or from a flow step.
+- **Retiring soon.** The central team service and native coding sessions are
+  hidden and warn when used; they are removed next release.
+- **Fresh baseline.** New installs start from a baseline schema. Databases
+  older than 0.5.0 are asked to update through 0.9.x first.
+
 ## 0.9.55 — 2026-10-09
 
 - **One door per route.** Every page's access comes from one table with one

package/README.md

@@ -366,7 +366,7 @@ for people splitting those parts across machines.
 Specialized views remain in **Tools** and **Settings**: the activity ledger, the review cockpit,
 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
+envelope that pre-approves your own filings), and **chat** — your lead, one
 conversation across every project, which only ever proposes.
 
 ### In the terminal
@@ -383,7 +383,7 @@ toolroll decide <id> --choose <option>      # answer a parked decision
 toolroll task show retries                  # attempts, outcome, where the branch is
 
 toolroll task add "Why does the login test flake?" --id flaky --report   # a scout
-toolroll chat --say "what is waiting on me across every project?"       # the mate
+toolroll chat --say "what is waiting on me across every project?"       # your lead
 ```
 
 Every command takes `--json` and answers with one envelope; every mutation
@@ -808,21 +808,37 @@ contents or command lines, with credential-shaped lines redacted at
 write. Digits focus one pane, `a` shows them all, `q` leaves. Outside a
 terminal, or with `--json`, it prints one snapshot and exits.
 
-## The mate, and the gateway
+## The lead, its subagents, and the gateway
 
-`/chat` in the console (or `toolroll chat` in the terminal) is one
-conversation across every project you serve. The mate reads the fleet
+`/chat` in the console (or `toolroll chat` in the terminal, or your chat app on
+the phone) is one conversation with your lead across every project you serve.
+The console, the terminal, Telegram, Slack, Discord and Teams all talk to the
+same lead with the same tools. The lead reads the fleet
 and **only proposes**: file a task (or a scout), move one to the front,
 reserve it for a worker, hold it, rewrite a scope, retry/replace/unlink a
 terminal dependency, guide a task's next attempt, cancel, or suggest an answer to a parked decision. Every
 proposal is a card you confirm, with
 every consequence and the builder's recommendation shown beside the
-mate's pick; a scope the mate wrote never seals under an operating mode.
+lead's pick; a scope the lead wrote never seals under an operating mode.
 Absolute paths, internal digests and account names are redacted; source context includes relative file citations. Direct API use spends
 against a ceiling you set per conversation. The console keeps a live pulse for every
 admitted project beside that shared thread, with one-click fleet questions
 and a direct road to each project's board.
 
+The lead has **subagents**: named helpers, each with its own personality,
+instructions and rules (what it does on its own, what it asks first, what it
+never does). Say "ask Maya to draft the refund reply" and the lead shows a card
+with exactly what goes to Maya; once you confirm, Maya works it within her rules
+and her answer comes back to you. A flow step can call a subagent by name too.
+They live in **Settings → Lead → Subagents** ([guide](docs/guide/subagents.md)).
+Subagents used to be called AI teammates; each carried over unchanged.
+
+The central team service (`toolroll connect`, the central `toolroll lead
+list|create|update|member|transfer`, `toolroll conversation …`, team chat) and
+native coding sessions (`toolroll session …`, the `/code` page) are deprecated:
+they still work for this release, hidden from help and the console, print one warning
+when used, and are removed in the next minor release.
+
 Every task has an **Overview / Ask** switch. **Ask** opens a focused companion
 to that task without creating another conversation: Toolroll attaches
 the current task to each new message, keeps the live status beside the thread,
@@ -831,7 +847,7 @@ result inspection. Proposed guidance is inert until you confirm its card, then i
 reaches the next attempt without interrupting work already running.
 
 New work starts the same way: describe the outcome once in ordinary language.
-The mate infers a concise title, narrow scope, safe non-goals, and proof
+The lead infers a concise title, narrow scope, safe non-goals, and proof
 criteria; it asks only when the project or outcome is genuinely ambiguous, or
 when an irreversible or compatibility tradeoff changes what should be built.
 Questions are grouped, carry a recommended default, and stop for reversible
@@ -985,7 +1001,7 @@ Everything below ships in 0.4.0:
   sessions, invites, and every mode they signed end together, while
   history stays attributed forever.
 - **Scout tasks** — `task add … --report` (or the "scout" checkbox, or
-  the mate's `propose_task` with `report: true`) files a task whose
+  the lead's `propose_task` with `report: true`) files a task whose
   deliverable is a report, never a branch: once its scope is approved,
   a read-only session investigates the goal as a question and hands
   back a title, a summary, a document, and up to five follow-ups, each

package/dist/action-ledger.d.ts

@@ -16,11 +16,9 @@ export type LedgerEntry = {
     /** v99: what changed, in a short line (a policy's "before → after"); never a secret, prompt or body. */
     detail: string | null;
 };
-/** The table as v54 made it: the one earlier shape the v99 rebuild accepts. */
-export declare const LEDGER_V54_TABLE: (name: string) => string;
-export declare const LEDGER_V54_COLUMNS: readonly ["id", "at", "actor", "repo", "task_id", "run_id", "action", "outcome", "source"];
-/** The table as v99 made it: the v110 rebuild accepts this shape and v54's. */
+/** The table as v99 made it (v107 has it): the one earlier shape the v110 rebuild accepts. */
 export declare const LEDGER_V99_TABLE: (name: string) => string;
+export declare const LEDGER_COLUMNS: readonly ["id", "at", "actor", "repo", "task_id", "run_id", "action", "outcome", "source", "detail"];
 export declare const LEDGER_TABLE: (name: string) => string;
 export declare const LEDGER_SCHEMA: string;
 /** Installed after all table migrations. Work events commit with the work,

package/dist/action-ledger.js

@@ -1,16 +1,7 @@
 /** v99: sign-ins (and refusals, lockouts, sign-outs) and policy changes are their own kinds of event.
  * v110: commands a person ran on this server with their API token, from the CLI ('api') or their agent ('mcp'). */
 export const LEDGER_SOURCES = ["work", "request", "access", "sign-in", "policy", "api", "mcp"];
-/** The table as v54 made it: the one earlier shape the v99 rebuild accepts. */
-export const LEDGER_V54_TABLE = (name) => `CREATE TABLE ${name} (
-  id INTEGER PRIMARY KEY AUTOINCREMENT,
-  at TEXT NOT NULL, actor TEXT NOT NULL, repo TEXT,
-  task_id TEXT, run_id INTEGER,
-  action TEXT NOT NULL, outcome TEXT NOT NULL,
-  source TEXT NOT NULL CHECK (source IN ('work','request','access'))
-)`;
-export const LEDGER_V54_COLUMNS = ["id", "at", "actor", "repo", "task_id", "run_id", "action", "outcome", "source"];
-/** The table as v99 made it: the v110 rebuild accepts this shape and v54's. */
+/** The table as v99 made it (v107 has it): the one earlier shape the v110 rebuild accepts. */
 export const LEDGER_V99_TABLE = (name) => `CREATE TABLE ${name} (
   id INTEGER PRIMARY KEY AUTOINCREMENT,
   at TEXT NOT NULL, actor TEXT NOT NULL, repo TEXT,
@@ -19,6 +10,7 @@ export const LEDGER_V99_TABLE = (name) => `CREATE TABLE ${name} (
   source TEXT NOT NULL CHECK (source IN ('work','request','access','sign-in','policy')),
   detail TEXT
 )`;
+export const LEDGER_COLUMNS = ["id", "at", "actor", "repo", "task_id", "run_id", "action", "outcome", "source", "detail"];
 export const LEDGER_TABLE = (name) => `CREATE TABLE ${name} (
   id INTEGER PRIMARY KEY AUTOINCREMENT,
   at TEXT NOT NULL, actor TEXT NOT NULL, repo TEXT,

package/dist/approval-policy.d.ts

@@ -5,21 +5,21 @@
  * - The person who filed a task can't approve it ("not the requester").
  * - Protected work (the whole project, or tasks that touch protected paths)
  *   needs two different people to approve the same exact scope, and an AI
- *   teammate or an operating mode can never decide it.
+ *   subagent or an operating mode can never decide it.
  *
  * The store enforces these at the one place every approval is sealed
  * (`Store.sealScopeApproval`); this module holds the pure parts.
  */
 /** 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 schedule, the CLI, a flow
+ * subagent, 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 FilerKind = "person" | "coordinator" | "subagent" | "automation";
 export type Filer = {
     name: string | null;
     kind: FilerKind;
 };
-/** A filer from a name as the ledger writes it: an AI teammate's ends " (AI)"; a coordinator's starts "coordinator:"; none is automation. */
+/** A filer from a name as the ledger writes it: a subagent's ends " (AI)"; a coordinator's starts "coordinator:"; none is automation. */
 export declare function filerFor(name: string | null | undefined): Filer;
 export type ApprovalRules = {
     notRequester: boolean;
@@ -27,7 +27,7 @@ export type ApprovalRules = {
     protectedPaths: string[];
 };
 export declare const NO_RULES: ApprovalRules;
-/** Who is sealing: a person at a ceremony, an operating mode, an AI teammate, or automation. */
+/** Who is sealing: a person at a ceremony, an operating mode, a subagent, or automation. */
 export type ApproverKind = "person" | "mode" | "ai" | "automation";
 export type ApprovalGate = {
     verdict: "seal";

package/dist/approval-policy.js

@@ -5,17 +5,17 @@
  * - The person who filed a task can't approve it ("not the requester").
  * - Protected work (the whole project, or tasks that touch protected paths)
  *   needs two different people to approve the same exact scope, and an AI
- *   teammate or an operating mode can never decide it.
+ *   subagent or an operating mode can never decide it.
  *
  * The store enforces these at the one place every approval is sealed
  * (`Store.sealScopeApproval`); this module holds the pure parts.
  */
-/** A filer from a name as the ledger writes it: an AI teammate's ends " (AI)"; a coordinator's starts "coordinator:"; none is automation. */
+/** A filer from a name as the ledger writes it: a subagent's ends " (AI)"; a coordinator's starts "coordinator:"; none is automation. */
 export function filerFor(name) {
     if (name == null || name === "")
         return { name: null, kind: "automation" };
     if (name.endsWith(" (AI)"))
-        return { name, kind: "teammate" };
+        return { name, kind: "subagent" };
     if (name.startsWith("coordinator:"))
         return { name, kind: "coordinator" };
     return { name, kind: "person" };
@@ -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 schedule or an AI teammate.";
+        : "This work is protected: a person has to approve it, not an operating mode, a schedule or a subagent.";
 }

package/dist/approval-rules-ui.js

@@ -16,9 +16,9 @@ export function rulesSummary(rules) {
     if (rules.notRequester)
         parts.push("The person who filed a task can't approve it.");
     if (rules.protectProject)
-        parts.push("All work here is protected: two people approve it, never an AI teammate or an operating mode.");
+        parts.push("All work here is protected: two people approve it, never a subagent or an operating mode.");
     else if (rules.protectedPaths.length > 0)
-        parts.push(`Work touching ${rules.protectedPaths.join(", ")} is protected: two people approve it, never an AI teammate or an operating mode.`);
+        parts.push(`Work touching ${rules.protectedPaths.join(", ")} is protected: two people approve it, never a subagent or an operating mode.`);
     return parts.length === 0 ? "No approval rules: anyone who can approve on this project can approve its work, including their own." : parts.join(" ");
 }
 export function approvalRulesHtml(view, notice) {