@wirecat/cli-base 0.64.0 → 0.65.0

package/CHANGELOG.md

@@ -8,6 +8,125 @@ Versions before 0.8.0 are in the [git tags](https://github.com/WireCatLabs/cli-b
 Every entry says what changed as a caller sees it, why, and what to watch for — the rules are
 [`docs/dev/CONVENTIONS.md`](docs/dev/CONVENTIONS.md#the-changelog).
 
+## 0.65.0 — 27.10.2026
+
+### Added
+
+- **Calendar words for moving an event and for "this and all following".** Flag `--following` (`target`, switch):
+  this occurrence and every later one of a repeating event (`events update|delete --following`), beside `--series`.
+  `--scope` already means personal or work, so it is not reused. Flag `--to-calendar <id>` (`target`, id): the
+  calendar an event moves to (`events move --to-calendar`); `--calendar` keeps its meaning, the calendar the event is
+  on. The verb `move` now says what moves in general: a file to a folder, an event to a calendar. cli-core's shared
+  calendar commands use all three; gcal-cli carries `lint/overrides.json` entries for them until this release.
+- **Every CLI that signs in has `session start`, `session status`, `session end` and a profile-free `session list`.**
+  [WC-ACCT-12](docs/standards/accounts.md#wc-acct-12--sign-in-is-session-start-status-and-end-and-session-list-names-the-profiles)
+  is the owner's ruling: `status` says whether one profile is signed in, `list` which profiles exist. Each
+  CLI's missing commands are listed as known gaps: tg, max and wa lack `session status` and list profiles with
+  `account list`; drive lacks `session status`; gcal lacks `session list`; zm lacks `session end` and `session list`;
+  memo has no `session` group.
+- **A sync spends a request budget sized to its deadline and says how to continue.**
+  [WC-LIFE-16](docs/standards/lifecycle.md#wc-life-16--a-sync-spends-a-request-budget-sized-to-its-deadline-and-its-answer-says-how-to-continue)
+  describes what cli-core 0.464.0 (cli-core #2118) builds for the calendar sync: `floor((deadline − margin) /
+  requestMs)` requests, one `requestMs` per CLI, `--max-pages` only lowering it, a partial stop that exits 0 with the
+  exact command to continue, and progress in the sync's status command. The other syncs and gcal's own `requestMs`
+  are listed as gaps.
+
+- **The command vocabulary has the verbs `serve` (run a server in this process and answer its clients until stopped)
+  and `revoke` (take back what was granted, so it stops working).** cli-core 0.463.0 names the MCP server
+  `mcp serve` and gives forgetting browser logins its own command, `mcp revoke`; `revoke` also covers
+  `chats link revoke` and the `consents revoke` commands that were baselined as unknown verbs.
+
+### Changed — may break callers
+
+- **A command that reads the service and only saves what it read is a read, also over MCP.**
+  [WC-CMD-17](docs/standards/commands.md#wc-cmd-17--declare-effects-on-every-command) defines a write, and WC-CMD-6,
+  WC-CMD-28, [WC-MCP-4](docs/standards/mcp.md#wc-mcp-4--read-runs-only-reading-commands-and-write-only-writing-ones)
+  and WC-OUT-9 point at it: `{ remote: "read", local: "write" }` (`sync`, `calendars list`) runs through the `read`
+  tool; `{ remote: "none", local: "write" }` (`store reindex`) stays a write. cli-base's `writes()` still counts every
+  local write, so cli-core serves `sync` through `write` until a follow-up changes it; watch for that release, which
+  moves those commands between tools.
+- **Deadlines: 30 s for a one-shot command, 5 min for a cooperative one at a terminal and 45 s over MCP.**
+  [WC-LIFE-5](docs/standards/lifecycle.md#wc-life-5--bound-every-one-shot-command-by-a-deadline) and WC-LIFE-10 say
+  so, as cli-core 0.464.0 builds it, because MCP clients cut a tool call at about 60 s.
+- **A non-messenger CLI allows ordinary writes, asks before deletes, and denies mail to other people and deleting
+  a whole series.**
+  [WC-PERM-22](docs/standards/permissions.md#wc-perm-22--a-cli-that-is-not-a-messenger-declares-its-own-keys-and-defaults-with-commandpermissions)
+  follows the owner's ruling, and a CLI's generic API path must check the shared keys (`events.notify`,
+  `events.delete.series`) too. Its example said sharing a calendar is `deny`; the owner made it `ask`. cli-core's
+  `CALENDAR_WRITE_DEFAULTS` and gcal's `api` defaults do not follow it yet; both are listed as gaps.
+- **Meeting passcodes stay out of command output and agent answers, not only out of the store.**
+  [WC-SECR-23](docs/standards/security.md) covers answers that come straight from the provider: gcal's `api` answers
+  still keep a description's passcode lines, a listed gap.
+- **Each CLI pins the command catalogue behind its MCP tools.** The [MCP](docs/standards/mcp.md) page no longer
+  claims `mcp-tools.json` pins the catalogue: with three tools it does not. `contracts/mcp-catalogue.json` does; tg and
+  max have it, and wa, zm, gcal and drive do not yet.
+
+- **An MCP server serves the profiles it is told, and refuses without them.**
+  [WC-MCP-9](docs/standards/mcp.md#wc-mcp-9--a-server-serves-the-profiles-it-is-told-with-one-connection-for-each)
+  now allows one named profile (`<cli> <profile> mcp serve`), a list (`<cli> mcp serve --profiles work,personal`) or
+  every profile (`<cli> mcp serve --profiles all`), with one messenger connection per served profile. With no profile
+  and no `--profiles`, `mcp serve` fails with `validation_error` and lists the profiles; it never serves every profile
+  by default. With several profiles, each call names its profile. WC-ACCT-1, WC-ACCT-2 and WC-ACCT-5 say how
+  `--profiles` fits the profile rules, and a profile lock refuses `--profiles all`. The flag registry has `--profiles`.
+  The owner ruled it; cli-core does not build `--profiles` yet.
+- **The handbook names the MCP server `mcp serve` and has no `mcp --revoke` exception.** The
+  [MCP](docs/standards/mcp.md) and [Lifecycle](docs/standards/lifecycle.md) pages say `mcp serve`, `mcp serve --http`,
+  `mcp serve --permission`, `bot mcp serve` and `mcp revoke`, as cli-core 0.463.0 builds them.
+  [WC-CMD-6](docs/standards/commands.md#wc-cmd-6--give-one-action-or-one-report-one-leaf-command) no longer lets
+  `--revoke` stay an option: forgetting every browser login is the `mcp revoke` command. A CLI with its own server
+  (drive, memo, zoom) moves to the same shape.
+- **A lint baseline entry for `serve` or `revoke` goes stale, and `cli-dev lint` fails on it.** cli-core lists
+  `bot mcp serve`, `mcp serve`, `mcp revoke` and `replies consents revoke` in `lint/baseline/unknown-verb.json`;
+  tg-cli and max-cli list `replies consents revoke`. Remove those entries in the same change that takes this version.
+- **The HTTP MCP server rule covers every CLI that offers `mcp serve --http`, not only the messenger CLIs.**
+  [WC-MCP-12](docs/standards/mcp.md#wc-mcp-12--an-mcp-server-over-http-follows-the-same-permissions-and-short-lived-logins)
+  now applies to cli-template and every CLI made from it, which have offered `mcp serve --http` with no rule over it.
+  The template already follows it; a CLI that changed its copy of the HTTP server checks it against the rule.
+
+### Fixed
+
+- **`cli-dev audit` compares gcal only on the commands it already shares with every CLI, for now.** cli-base 0.64.0
+  put gcal into the `all` parity group, and gcal's release audit then blocked on 20 `same-path-contract` differences
+  in `doctor`, `mcp`, `search` and `skill` that already exist among the other six published CLIs and that gcal
+  cannot remove alone (gcal-cli#13). gcal leaves `all` and has its own group, `gcal-shared`, with every CLI over
+  `commands`, `upgrade`, `notes` and `meetings`. It rejoins `all` once tg, max, wa, drive, zoom and memo release on
+  cli-core's shared `mcp serve`, `doctor` and `skill` ([#390](https://github.com/WireCatLabs/cli-base/issues/390)).
+  The other CLIs' audits are unchanged: a path is compared across every member of every group that covers it.
+
+- **`cli-dev bundle`'s loader finds a server after a flag: `<cli> personal --read-only mcp serve`.** It looked for
+  `serve`, `watch` or `mcp` in the first three words of the command, and since cli-core 0.463 named the server
+  `mcp serve`, a flag before it pushed `serve` to the fourth word. Such a server loaded no chunks ahead and could fail
+  after an in-place upgrade (measured on drive: 91 of 138 chunks loaded, instead of 138). The loader now skips flags
+  and looks at four words. Rebuild a CLI with this release to take it.
+- **The handbook no longer contradicts itself on gcal's audit findings.**
+  - WC-OUT-8 and WC-OUT-14: an answer with `meta.complete: false` is an answer on stdout, also after a non-zero
+    exit; only a run with no answer prints one JSON error with stdout empty.
+  - WC-CMD-10 names `--max-pages` a `budget` option, not a paging one, and says why the calendar `--id` exists beside
+    `--operation-id`; gcal's `events create`, with `--id` and no `--operation-id`, is a listed gap. WC-CMD-11 lists `--duration-minutes` as a known gap until the vocabulary has
+    `--duration <duration>`.
+  - WC-REL-16 says `packContents` checks the pack against the list it is given, so a check that passes the `files`
+    list itself cannot fail on a wrong list; the fix belongs in cli-template.
+  - WC-TIME-5 matches an all-day event by local dates, not UTC moments; cli-core's event filter is a listed gap.
+  - WC-ARCH-3 counts generated API types as vendor types, WC-ARCH-5 and WC-ARCH-6 cover calendar CLIs, and
+    WC-ARCH-21's example is gcal's real provider entry.
+  - WC-TOOL-16 puts a word waiting for the vocabulary in `lint/overrides.json` with a link and a date, never in the
+    baseline. The [Documents](docs/standards/docs.md#wc-doc-3--every-document-states-current-facts-rewrite-a-wrong-sentence-in-place)
+    rule on current facts sends a false template-owned file to cli-template.
+  - WC-DATA-3 makes a calendar entry's `external_id` unique per calendar, WC-STORE-3 lists the calendar areas as not
+    bound, WC-TEST-12 says what a reason names, and WC-TEST-14 counts the shared store as local state.
+  - The "who follows" lists name gcal.
+
+- **The handbook's pages on the template match cli-template 0.9.0.** The [Kit surface](docs/standards/kit-surface.md)
+  table lists `LOCAL_WRITE` and `revokeAll`, which the template now imports, and counts imports loaded on demand.
+  [New CLI](docs/standards/new-cli.md) says the MCP server has three tools that reach every command, not a tool for
+  every command.
+- **The handbook says where a lint violation that a shared package forces goes, and which cli-core files are not a
+  CLI's local state.** [WC-TOOL-16](docs/standards/toolchain.md) puts such a violation in the CLI's lint baseline
+  until the shared package catches up.
+  [WC-TEST-14](docs/standards/testing.md#wc-test-14--check-the-upgrade-from-the-previous-published-version) names
+  the update check, MCP logins and lock files that only cli-core writes as outside the upgrade contract; tests still
+  keep them in the sandboxed home.
+
 ## 0.64.0 — 27.10.2026
 
 ### Added

package/dist/dev/bundle.d.ts

@@ -20,6 +20,12 @@ export declare const DEFAULT_EXTERNAL: string[];
 export declare const DEFAULT_ANCHORED: string[];
 export declare const DEFAULT_HARMLESS: string[];
 export declare const LOADER_MARK = "// cli-dev bundle loader\n";
+/**
+ * Whether the loader runs a server: `serve`, `watch` or `mcp serve`, or `mcp` alone as before cli-core 0.463. Flags
+ * are skipped, so `<cli> personal --read-only mcp serve` counts; four words leave room for one flag's value. It is
+ * written into the loader as source, so it uses nothing from outside.
+ */
+export declare const isServer: (words: readonly string[]) => boolean;
 /** The bin that replaces the compiled one: `name` is the bundle's entry, `chunks` what a server preloads. */
 export declare const loaderSource: (name: string, version: string, chunks: readonly string[]) => string;
 export declare const bundle: (options: BundleOptions) => Promise<BundleResult>;

package/dist/dev/bundle.js

@@ -166,6 +166,17 @@ const commonJsNames = {
         });
     },
 };
+/**
+ * Whether the loader runs a server: `serve`, `watch` or `mcp serve`, or `mcp` alone as before cli-core 0.463. Flags
+ * are skipped, so `<cli> personal --read-only mcp serve` counts; four words leave room for one flag's value. It is
+ * written into the loader as source, so it uses nothing from outside.
+ */
+export const isServer = (words) => {
+    const plain = words.filter((word) => !word.startsWith("-"));
+    return plain
+        .slice(0, 4)
+        .some((word, at) => word === "serve" || word === "watch" || (word === "mcp" && plain[at + 1] === undefined));
+};
 /** The bin that replaces the compiled one: `name` is the bundle's entry, `chunks` what a server preloads. */
 export const loaderSource = (name, version, chunks) => `#!/usr/bin/env node
 ${LOADER_MARK}import * as module from "node:module"
@@ -181,9 +192,7 @@ if (
 } else {
   // Before the bundle compiles: the bundle's own call comes after its chunks.
   module.enableCompileCache()
-  const serves = words
-    .slice(0, 3)
-    .some((word, at) => ["serve", "watch"].includes(word) || (word === "mcp" && !/^[^-]/.test(words[at + 1] ?? "")))
+  const serves = (${isServer.toString()})(words)
   if (serves && module.registerHooks) {
     const bundle = new URL("../bundle/", import.meta.url).href
     module.registerHooks({

package/dist/standards/audit.js

@@ -64,10 +64,18 @@ export const PARITY_GROUPS = defineParityGroups([
     { name: "messengers", members: ["tg", "max"], covers: "tree", differences: [] },
     {
         name: "all",
-        members: ["tg", "max", "memo", "drive", "zm", "wa", "gcal"],
+        members: ["tg", "max", "memo", "drive", "zm", "wa"],
         covers: ["commands", "doctor", "skill", "mcp", "upgrade", "search", "notes", "meetings"],
         differences: [],
     },
+    // gcal is compared on what it already shares with every CLI; doctor, mcp, search and skill wait until the published
+    // CLIs agree there (https://github.com/WireCatLabs/cli-base/issues/390), then gcal moves back into "all".
+    {
+        name: "gcal-shared",
+        members: ["tg", "max", "memo", "drive", "zm", "wa", "gcal"],
+        covers: ["commands", "upgrade", "notes", "meetings"],
+        differences: [],
+    },
 ]);
 const requiredRootSchema = v.strictObject({ path: v.pipe(v.array(segment), v.minLength(1)), meaning: text });
 export const defineRequiredRoots = (input) => parseRegistry("required roots", v.array(requiredRootSchema), input, (roots) => duplicates(roots.map((root) => root.path.join(" "))).map((path) => `"${path}" is listed twice`));

package/dist/standards/flags-calendar.js

@@ -56,4 +56,17 @@ export const CALENDAR_FLAGS = [
         type: "switch",
         meaning: "act on the whole repeating event, not only this occurrence",
     },
+    {
+        name: "--following",
+        role: "target",
+        type: "switch",
+        meaning: "act on this occurrence and every later one of the repeating event",
+    },
+    {
+        name: "--to-calendar",
+        value: "<id>",
+        role: "target",
+        type: "id",
+        meaning: "the calendar it moves to, of the same account",
+    },
 ];

package/dist/standards/flags-what.js

@@ -187,6 +187,13 @@ export const WHAT_FLAGS = [
         type: "string",
         meaning: "the profile to use, instead of the first word",
     },
+    {
+        name: "--profiles",
+        value: "<names|all>",
+        role: "scope",
+        type: "list",
+        meaning: "the profiles an MCP server serves, comma-separated, or all of them",
+    },
     {
         name: "--history-since-time",
         value: "<time>",

package/dist/standards/vocabulary.js

@@ -115,7 +115,9 @@ const verbs = [
     ["start", "start a running process, or a login session"],
     ["stop", "stop a running process"],
     ["restart", "stop and start a running process"],
+    ["serve", "run a server in this process and answer its clients until stopped"],
     ["end", "end a login session"],
+    ["revoke", "take back what was granted, so it stops working: a login, an invite link, a consent"],
     ["install", "install a system unit"],
     ["uninstall", "remove a system unit"],
     ["cancel", "stop a job or a pending thing"],
@@ -180,7 +182,7 @@ const verbs = [
     ["reject", "the owner refuses what an agent proposed"],
     ["review", "list what waits for the owner's decision"],
     ["resolve", "settle one thing that waits for the owner's decision, with the owner's choice"],
-    ["move", "move a file in the source"],
+    ["move", "move a thing to another place in the source: a file to a folder, an event to a calendar"],
     ["copy", "copy a file in the source"],
     ["run", "run a saved job once, now, as its timer would"],
     ["claim", "take a thing for a while so no other agent works it at once; the claim lapses by itself"],

package/docs/standards/README.md

@@ -32,10 +32,10 @@ the four steps that need a person. A new CLI is ready for its first release when
 | [Commands](commands.md) | `CMD` | 28 | Paths, vocabulary, flags, arguments, effects, lifetime, query, help, external references |
 | [Output](output.md) | `OUT` | 23 | Data on stdout only, envelopes, errors, exit codes, partial answers, projection |
 | [MCP](mcp.md) | `MCP` | 13 | The MCP tools, how they come from commands, what each permission shows |
-| [Accounts](accounts.md) | `ACCT` | 11 | The explicit profile, reads across accounts, scope flags, linked identities |
+| [Accounts](accounts.md) | `ACCT` | 12 | The explicit profile, reads across accounts, scope flags, linked identities, sign-in commands |
 | [Permissions](permissions.md) | `PERM` | 22 | Levels, keys, defaults, hard limits, the write guard and its journal |
 | [Architecture](architecture.md) | `ARCH` | 17 | Layers, dependency direction, vendor types, what goes in which package |
-| [Lifecycle](lifecycle.md) | `LIFE` | 14 | Opening late, who closes, one-shot exits, long-running commands, the `serve` relay, resumable syncs, the run log |
+| [Lifecycle](lifecycle.md) | `LIFE` | 15 | Opening late, who closes, deadlines, long-running commands, the `serve` relay, resumable syncs and their request budget, the run log |
 | [Store](store.md) | `STORE` | 14 | Store areas, account scope, migrations, test isolation |
 | [Data model](data-model.md) | `DATA` | 9 | Core entities, entities and source records, `external_id`, field names, links and duplicates, files, calendar entries |
 | [Testing](testing.md) | `TEST` | 17 | Sandbox, no network, no real waits, leak tests, coverage, contracts, test matrix, parity |

package/docs/standards/accounts.md

@@ -3,7 +3,7 @@
 ## Scope
 
 How a CLI chooses an account: the profile is always explicit, a read across accounts covers all of them and says so,
-and scope flags work the same everywhere.
+scope flags work the same everywhere, and sign-in has the same four commands in every CLI.
 
 A **profile** is the name of one login of a CLI on one computer, for example `personal` or `work`. One profile can
 hold a personal session, a bot token, or both.
@@ -16,7 +16,8 @@ Rule ids on this page are `WC-ACCT-<n>`. How to read a rule, how ids work and wh
 cli-core resolves the profile for tg, max and wa. WC-ACCT-1 needs cli-core 0.319.0 or newer. memo has no messenger profile: its shared commands run without one, and they pick accounts with `--provider`
 and `--account` (WC-ACCT-7). zoom resolves its own profile word by the same rules (`zm <profile> …`, `ZM_PROFILE`,
 `ZM_PROFILE_LOCK`) from zoom-cli 0.35.0, with cli-core's `liftProfile` and `usableProfileName`. drive still has its own
-profile code: it registers its own profiles. That is a known gap, not an exception.
+profile code: it registers its own profiles. That is a known gap, not an exception. gcal resolves the profile through
+cli-core's `run()`, like tg, max and wa. Which CLIs lack a sign-in command of WC-ACCT-12 is listed in that rule.
 
 ## Rules
 
@@ -31,9 +32,11 @@ on the computer.
 - **Example:** `tg personal chats list`, or `TG_PROFILE=personal tg chats list`. When no profile is named and the
   config file still has `default_profile`, cli-core stops and says which profile to type. `config set default_profile`
   is refused.
-- **Exceptions:** a command that touches no account runs without a profile, for example `account list`,
-  `config show` and `commands`.
-- **Applies to:** all CLIs. **Since:** cli-base 0.41.0. **Rulings:** NEED-84.
+- **Exceptions:** a command that touches no account runs without a profile, for example `session list`
+  ([WC-ACCT-12](#wc-acct-12--sign-in-is-session-start-status-and-end-and-session-list-names-the-profiles)),
+  `config show` and `commands`; tg, max and wa still name their list `account list`. `mcp serve` may name its profiles with `--profiles <names|all>` instead
+  ([WC-MCP-9](mcp.md#wc-mcp-9--a-server-serves-the-profiles-it-is-told-with-one-connection-for-each)); `all` is the owner's explicit choice, never a fallback.
+- **Applies to:** all CLIs. **Since:** cli-base 0.41.0. **Rulings:** NEED-84, NEED-1881.
 
 ### WC-ACCT-2 · The profile is a word, never a flag
 
@@ -44,8 +47,9 @@ profile.
 - **Enforced by:** `cli-core: src/cli/profile.test.ts`.
 - **Example:** `max work bot messages send …` uses the same first word as `max work chats list`. `tg --json chats list`
   still works, because `--json` is an option.
-- **Exceptions:** none.
-- **Applies to:** all CLIs. **Since:** cli-base 0.41.0. **Rulings:** NEED-84, NEED-294.
+- **Exceptions:** `mcp serve --profiles <names|all>` names the profiles one server serves ([WC-MCP-9](mcp.md#wc-mcp-9--a-server-serves-the-profiles-it-is-told-with-one-connection-for-each)). It is used in
+  place of the first word, never with it.
+- **Applies to:** all CLIs. **Since:** cli-base 0.41.0. **Rulings:** NEED-84, NEED-294, NEED-1881.
 
 ### WC-ACCT-3 · A missing profile is an error that lists the choices
 
@@ -78,8 +82,8 @@ top-level command, such as `chats` or `bot`, is refused when the profile is crea
 
 ### WC-ACCT-5 · A profile lock pins a process to one profile
 
-When `<PREFIX>_PROFILE_LOCK` is set, a first word or `<PREFIX>_PROFILE` that names any other profile is refused with
-`permission_error`.
+When `<PREFIX>_PROFILE_LOCK` is set, a first word, `<PREFIX>_PROFILE` or `mcp serve --profiles` that names any other
+profile is refused with `permission_error`. `--profiles all` names every profile, so it is refused too.
 
 - **Why:** an agent must not escape its guards by naming a profile with fewer of them.
 - **Enforced by:** `cli-core: src/cli/settings.test.ts`.
@@ -155,6 +159,35 @@ inferred from a matching name, and `unlink` undoes it.
 - **Exceptions:** none.
 - **Applies to:** all CLIs. **Since:** cli-base 0.43.1. **Rulings:** none.
 
+### WC-ACCT-12 · Sign-in is `session start`, `status` and `end`, and `session list` names the profiles
+
+Every CLI that signs in has four commands under `session`:
+
+- `<cli> <profile> session start` signs the profile in.
+- `<cli> <profile> session status` says whether this profile is signed in, and as whom.
+- `<cli> <profile> session end` signs the profile out and forgets its login.
+- `<cli> session list` takes no profile and lists the profiles on this computer.
+
+`status` answers about one profile; `list` answers which profiles exist. Neither one connects to more than it must:
+`list` reads only what the computer holds.
+
+- **Why:** the owner and an agent look for sign-in in the same place in every CLI. Today each CLI has a different
+  part of the set, so an agent that learned one CLI guesses wrong in the next.
+- **Enforced by:** review only.
+- **Example:** `gcal personal session status` answers whether the `personal` profile holds a Google login;
+  `gcal session list` lists `personal` and `work` with no profile named.
+- **Exceptions:** known gaps, as of 2026-10-27:
+  - tg, max and wa have `session start` and `session end`, no `session status`, and list their profiles with
+    `account list` instead of `session list`.
+  - drive has `session start`, `session list` and `session end`, and no `session status`.
+  - gcal has `session start`, `session status` and `session end`, and no `session list`.
+  - zm has `session start` and `session status`, and no `session end` or `session list`.
+  - memo signs in per mail account with `mail add` and has no `session` group.
+
+  A CLI that adds a missing command adds it under `session`; a renamed path keeps no alias
+  ([WC-CMD-8](commands.md#wc-cmd-8--keep-no-aliases-a-renamed-path-stops-working-in-the-release-that-renames-it)).
+- **Applies to:** every CLI that signs in. **Since:** cli-base 0.65.0. **Rulings:** NEED-1884.
+
 ## Sources
 
 These documents explain the rules on this page in more detail. Where one of them disagrees with this page, this page

package/docs/standards/architecture.md

@@ -20,7 +20,9 @@ at start-up and the `serve` relay are in [Lifecycle](lifecycle.md); the store's
 - **Service:** a use case, written once, that both a command and an MCP tool call.
 - **Composition root:** the place in a CLI where real implementations are chosen and connected, usually
   `program.ts` and the command context.
-- **Vendor type:** a type from a provider library, such as `@mtcute/*` or `ws`.
+- **Vendor type:** a type from a provider library, such as `@mtcute/*` or `ws`, and a type generated from a
+  provider's API description, such as gcal's and drive's types under `src/generated/` from a Google Discovery
+  document: both change when the provider changes, not when we do.
 
 ## Rules
 
@@ -57,7 +59,9 @@ at start-up and the `serve` relay are in [Lifecycle](lifecycle.md); the store's
   `src/adapter/` maps the client onto the shared messenger port. A field that only one provider has travels in
   `providerMetadata`.
 - **Exceptions:** a bot slice that talks to an official HTTP API keeps its own transport, beside the personal
-  account's adapter, never above it.
+  account's adapter, never above it. Generated API types may also be used by the generated `api <method>` commands,
+  which are the provider's own API by design; the shared ports and services never see them. In gcal,
+  `calendar-source.ts` and `calendar-writer.ts` translate the generated event type into cli-core's calendar entry.
 - **Applies to:** all CLIs. **Since:** cli-base 0.41.0. **Rulings:** NEED-12.
 
 ### WC-ARCH-4 · Put code in the lowest shared package that can hold it
@@ -77,14 +81,16 @@ at start-up and the `serve` relay are in [Lifecycle](lifecycle.md); the store's
 
 ### WC-ARCH-5 · Build a feature that another provider could have as a shared command behind a capability
 
-- **Why:** a command written once in cli-core gives every messenger the same path, flags and output.
+- **Why:** a command written once in cli-core gives every provider of a kind the same path, flags and output.
 - **Enforced by:** review only.
 - **Example:** topics and polls are port groups and shared commands in cli-core. A messenger that lacks a capability
   refuses the command; it does not silently do less. A bot is another messenger with fewer capabilities, and tg and
-  max share the bot code.
-- **Exceptions:** a feature stays in one CLI only when the other providers cannot have it, such as MAX's socket server
-  or Telegram's app registration.
-- **Applies to:** messenger CLIs (tg, max, wa). **Since:** cli-base 0.41.0. **Rulings:** NEED-820, NEED-440,
+  max share the bot code. Calendars have the same shape: cli-core's `addCalendarCommands` builds `calendars`,
+  `sync`, `status`, `events` and `search` over the `CalendarSource` and `CalendarWriter` ports, and mounts
+  `calendars busy` or the event writes only when the provider has them.
+- **Exceptions:** a feature stays in one CLI only when the other providers cannot have it, such as MAX's socket server,
+  Telegram's app registration, or gcal's generated `api` commands.
+- **Applies to:** messenger CLIs (tg, max, wa) and calendar CLIs (gcal). **Since:** cli-base 0.41.0. **Rulings:** NEED-820, NEED-440,
   NEED-301, NEED-444.
 
 ### WC-ARCH-6 · Replace a use case, not a command
@@ -93,9 +99,10 @@ at start-up and the `serve` relay are in [Lifecycle](lifecycle.md); the store's
 - **Enforced by:** review only.
 - **Example:** `Messenger.services` receives the shared services and returns only the ones it changes:
   `services: (base) => ({ messages: { ...base.messages, list: maxList } })`. To add a subcommand, a CLI calls
-  `addCommand` on the command a factory returns.
+  `addCommand` on the command a factory returns. A calendar CLI changes what the shared calendar commands do through
+  the source and writer it passes to `addCalendarCommands`, never by writing its own `sync` or `events list`.
 - **Exceptions:** none.
-- **Applies to:** messenger CLIs. **Since:** cli-base 0.41.0. **Rulings:** none.
+- **Applies to:** messenger CLIs and calendar CLIs. **Since:** cli-base 0.41.0. **Rulings:** none.
 
 ### WC-ARCH-7 · Keep policy in the service; a command or MCP handler only parses input and presents the result
 
@@ -215,9 +222,9 @@ out of search and listed under `skipped`, with the hint to run that CLI once.
 - **Why:** a new source joins search and memo without editing cli-core, and a provider nobody described is never read
   as something it is not (until this rule, an unlisted provider was searched as a messenger).
 - **Enforced by:** `cli-core: src/store/sqlite/providers.test.ts`.
-- **Example:** cal registers `{ name: "google-calendar", kind: "events", aliases: ["cal"], command: "cal" }` each
-  time it starts. On a machine where cal has never run, a search across accounts lists cal's accounts under
-  `skipped` instead of reading their rows as messages.
+- **Example:** gcal registers `{ name: "google-calendar", kind: "events", aliases: ["gcal", "calendar"], command:
+  "gcal" }` each time it opens the store. On a machine where gcal has never run, a search across accounts lists
+  gcal's accounts under `skipped` instead of reading their rows as messages.
 - **Exceptions:** the built-in providers of cli-core need no entry. Two entries that disagree on a kind are an error
   naming both.
 - **Applies to:** cli-core and every CLI with a provider of its own. **Since:** cli-base 0.53.0. **Rulings:** none

package/docs/standards/commands.md

@@ -75,11 +75,12 @@ catalogue and parity manifest stay in cli-core
 - **Why:** an option that turns a command into a different report hides that report from anyone reading the tree.
 - **Enforced by:** review only.
 - **Example:** ranking is `stats messages top`, not a ranking mode on `search messages`. Options choose the scope,
-  measure, order or format of the same action. No command both shows and changes something.
+  measure, order or format of the same action. No command both shows and changes something; saving what it read
+  into the local store is not a change ([WC-CMD-17](#wc-cmd-17--declare-effects-on-every-command)).
 - **Exceptions:** a documented preparatory fetch such as `--sync-first`. It keeps its own permissions and reports
-  its outcome. `mcp --revoke` forgets every login given to a browser app; it stays an option on `mcp` because it
-  belongs with the HTTP server's login state.
-- **Applies to:** all CLIs. **Since:** cli-base 0.41.0. **Rulings:** NEED-1864.
+  its outcome.
+- **Applies to:** all CLIs. **Since:** cli-base 0.41.0. **Rulings:** NEED-1880 (`mcp revoke` is its own command; it
+  replaces NEED-1864, which kept `--revoke` as an option on `mcp`).
 
 ### WC-CMD-7 · Never let two commands overlap
 
@@ -117,9 +118,16 @@ catalogue and parity manifest stay in cli-core
 - **Why:** `--limit` must mean "how many items" in every command of every CLI.
 - **Enforced by:** `flag-synonym` · `flag-two-meanings` · `same-flag-meaning` (weekly audit; it does not block a pull
   request yet).
-- **Example:** `--limit <n>`, never `--max`, `--take` or `--count`. `--cursor <cursor>`, never `--offset`. How much
-  to read is `--limit`, `--page` and `--page-size`. A count of pages is never an option.
-- **Exceptions:** generated commands (`bot api`) are exempt from the naming rules.
+- **Example:** `--limit <n>`, never `--max`, `--take` or `--count`. `--cursor <cursor>`, never `--offset`. How big
+  the answer is: `--limit`, `--page` and `--page-size`; a count of pages is never a paging option. How much work a
+  command may do is a `budget` option: `--max-pages <pages>` caps the pages a sync reads from the source, and
+  `--max-output-bytes` the size of the answer. A budget changes how far the command gets, never which items one page
+  of the answer holds. A retry after `outcome_unknown` is `--operation-id`: the attempt in the send journal. The
+  calendar vocabulary's `--id <id>` is a different value: the provider's own id for a thing being created, chosen
+  before the create, so a retry finds it at the provider. A CLI whose provider takes such an id may offer both.
+- **Exceptions:** generated commands (`bot api`) are exempt from the naming rules. Known gap, as of 2026-10-27: gcal's
+  `events create` offers `--id` and no `--operation-id`, so its `outcome_unknown` names the event id instead of an
+  `operation_id` (WC-LIFE-9, WC-OUT-10).
 - **Applies to:** all CLIs. **Since:** cli-base 0.41.0. **Rulings:** none.
 
 ### WC-CMD-11 · Name an option in plain words, with the kind of value in the name
@@ -129,7 +137,10 @@ catalogue and parity manifest stay in cli-core
 - **Example:** `--operation-id`, not `--cid`. `--before-id` takes a message id, `--after-time` a time, `--before-n` a
   count: two kinds are two options. A length of time is a `<duration>` with a unit (`500ms`, `30s`, `2m`, `4h`, `1d`),
   never a bare number.
-- **Exceptions:** none.
+- **Exceptions:** `--duration-minutes <minutes>` (zm's meeting length, gcal's `calendars busy`) takes a bare count of
+  minutes. It is a known gap in the vocabulary, as of 2026-10-27: it stays until the vocabulary has
+  `--duration <duration>`, and then moves in the release that adds it, under "Changed — may break callers". No new
+  option follows it.
 - **Applies to:** all CLIs. **Since:** cli-base 0.41.0. **Rulings:** none.
 
 ### WC-CMD-12 · Give every option a role from the vocabulary, and filter a list with its query
@@ -188,13 +199,25 @@ Each of these is set with `annotate(command, { … })` from `@wirecat/cli-base/c
 
 ### WC-CMD-17 · Declare `effects` on every command
 
+A command **writes** when it changes something on the service (`remote: "write"`), or when it changes the local
+store or files without reading the service first (`remote: "none"`, `local: "write"`, such as `store reindex` or
+`config set`). A command that reads the service and only saves what it read into the owner's local store
+(`{ remote: "read", local: "write" }`, such as `sync` or `calendars list`) is a **read**: on the command line, in
+[WC-CMD-6](#wc-cmd-6--give-one-action-or-one-report-one-leaf-command), over MCP
+([WC-MCP-4](mcp.md#wc-mcp-4--read-runs-only-reading-commands-and-write-only-writing-ones)) and as a next step
+([WC-OUT-9](output.md#wc-out-9--offer-at-most-two-next-steps-and-mark-a-step-safe-only-when-it-changes-nothing-on-the-service)).
+
 - **Why:** retries and unasked next steps are judged on effects, and a command without them counts as a write.
 - **Enforced by:** `missing-command-effects` · `cli-core: src/cli/effects.test.ts` · `cli-memo: src/effects.test.ts`.
 - **Example:** `annotate(send, { effects: { remote: "write", local: "write" } })`. Each side is `none`, `read` or
   `write`. A sync that reads the service and writes the local store is `{ remote: "read", local: "write" }`.
 - **Exceptions:** none. Without `effects`, the error handler never marks a failure safe to retry, and a next step
-  that runs the command is never safe to run unasked.
-- **Applies to:** all CLIs. **Since:** cli-base 0.41.0. **Rulings:** none.
+  that runs the command is never safe to run unasked. Known gap, as of 2026-10-27: cli-base's `writes()`
+  (`src/standards/effects.ts`) still counts every local write as a write, so cli-core's MCP router serves `sync` and
+  `calendars list` through the `write` tool. The follow-up makes `writes()` true for `remote: "write"`, or for
+  `local: "write"` when `remote` is `none`.
+- **Applies to:** all CLIs. **Since:** cli-base 0.41.0 (what counts as a read: cli-base 0.65.0). **Rulings:** the
+  owner's ruling on what counts as a read over MCP (2026-10-27).
 
 ### WC-CMD-18 · Declare `lifetime` and `cooperative` instead of matching command names
 
@@ -328,8 +351,9 @@ The references, each for its own part:
   [WC-OUT-18](output.md#wc-out-18--exit-with-cli-bases-code-for-each-kind-of-failure), prompts follow
   [WC-CMD-15](#wc-cmd-15--never-prompt-when-no-person-can-answer), and a renamed path keeps no alias
   ([WC-CMD-8](#wc-cmd-8--keep-no-aliases-a-renamed-path-stops-working-in-the-release-that-renames-it)), unlike the
-  deprecation advice of the Command Line Interface Guidelines. A read may have documented local effects, such as storing what it read or recording a failed
-  run, so a failed command does not promise that it wrote nothing. A write is never retried on its own, and a tool's
+  deprecation advice of the Command Line Interface Guidelines. A read may have documented local effects, such as
+  storing what it read or recording a failed run, so a failed command does not promise that it wrote nothing; what
+  counts as a read is in [WC-CMD-17](#wc-cmd-17--declare-effects-on-every-command). A write is never retried on its own, and a tool's
   whole payload is never logged. The `stats` root and its resources are the project's own choice.
 - **Exceptions:** the CLI Agent Spec's rule that help goes to stderr when stdout is not a terminal is not adopted. The
   Agent Client Protocol links an editor to a coding agent; a WireCat CLI is a tool an agent calls, so it adds no

package/docs/standards/data-model.md

@@ -37,6 +37,8 @@ is rewritten only to follow it:
   entity's own fields (WC-DATA-2).
 - `meeting_participants` is unique on the meeting and the contact; its `external_id` is in no unique key (WC-DATA-3).
 
+The calendar tables that gcal fills through cli-core (`calendars`, `calendar_entries`) follow them from the start.
+
 ## Rules
 
 ### WC-DATA-1 · A record more than one tool needs is a core entity in cli-core; a CLI's own tables stay private
@@ -73,7 +75,9 @@ to its entity. One entity may combine source records from several sources and ac
 ### WC-DATA-3 · A provider's id goes in `external_id`
 
 The id a provider gives a record is stored in `external_id`, unique with `account_id` (or with `provider` where the
-record has no account). Never in a column named after the provider (`google_id`, `file_id`) and never only in
+record has no account). Where the provider's id is unique only inside a container the record belongs to, it is unique
+with that container instead: a calendar entry's `external_id` is unique with its `calendar_id`, because the same event
+id appears in each calendar that holds a copy of the event, and the calendar is unique with `account_id`. Never in a column named after the provider (`google_id`, `file_id`) and never only in
 `metadata`. A second id the provider also uses gets a named column of its own (`ical_uid`).
 
 - **Why:** one place to look for every provider's id, and one unique key to update a record by.

package/docs/standards/docs.md

@@ -37,7 +37,10 @@ Rule ids on this page are `WC-DOC-<n>`. How to read a rule, how ids work and whi
 - **Enforced by:** review only.
 - **Example:** a claim that turns out wrong is rewritten to the current fact, with no "correction" note and no dated
   "measured on" trail. A finished plan or handoff is deleted. A done backlog or cleanup line is deleted.
-- **Exceptions:** `CHANGELOG.md` is the one place with version history.
+- **Exceptions:** `CHANGELOG.md` is the one place with version history. A template-owned file (`AGENTS.md`,
+  `docs/dev/TESTING.md`, the skills under `docs/dev/skills/` and the others
+  [New CLI](new-cli.md) lists) that has turned false is fixed in cli-template, never only in the CLI: `upgrade` brings
+  the fix to every CLI, and a local edit would make `upgrade` ask about it each time.
 - **Applies to:** all CLIs, user and developer pages. **Since:** cli-base 0.41.0. **Rulings:** none.
 
 ### WC-DOC-4 · A generated page is never edited by hand

package/docs/standards/kit-surface.md

@@ -12,7 +12,8 @@ This page is a reference, not a rule page: it assigns no rule ids. How to start
 
 ## What the template imports
 
-The list is what the template's `src/` and `scripts/` import today, type imports and re-exports included. `kit/` imports
+The list is what the template's `src/` and `scripts/` import today, type imports, re-exports and imports loaded on
+demand included. `kit/` imports
 nothing from either package.
 
 | Package and path | Exports |
@@ -20,9 +21,9 @@ nothing from either package.
 | `@wirecat/cli-base` | `catchCrashes`, `CliError`, `configFilePath`, `mcpErrorResult`, `resolvePaths` |
 | `@wirecat/cli-base/commands` | `annotate`, `CommandInfo`, `COMMANDS_PAGE_LABELS` (in `scripts/`), `commandsPage` (in `scripts/`), `describeOptions` (in `scripts/`), `describeProgram` |
 | `@wirecat/cli-base/codegen` | `writeArtifacts` (in `scripts/`) |
-| `@wirecat/cli-base/release` | `DocsRules`, `JOURNAL_IDS`, `markdownFiles`, `packContents` (in `scripts/`) |
-| `@wirecat/cli-core/cli` | `AppIdentity`, `changesAuthorityAt`, `commandHelpMarkdown` (in `scripts/`), `commandsCommand`, `configCommand`, `Configuration`, `createProgram`, `environmentOf`, `GlobalFlags`, `httpTokenFile`, `itemOf`, `LOCAL_READ`, `MCP_HTTP_DEFAULT_PORT`, `mcpServerCommand`, `outputFor`, `privateFiles`, `profileFree`, `ProgramDefinition`, `ProgramOptions`, `readOnlyLockOf`, `refuseUnderReadOnly`, `REMOTE_WRITE`, `renderAnswer`, `rootOf`, `run`, `RunOptions`, `runsCommand`, `settingsFor`, `skillCommand`, `upgradeCommand` |
-| `@wirecat/cli-core/mcp` | `httpLockFile`, `MCP_PATH`, `McpCommand`, `portOf`, `publicUrlOf`, `registerCommands`, `runCommandForAgent`, `serveOverHttp`, `toolsFromCommands` |
+| `@wirecat/cli-base/release` | `DocsRules`, `JOURNAL_IDS`, `markdownFiles`, `packContents` (all in `scripts/`) |
+| `@wirecat/cli-core/cli` | `AppIdentity`, `changesAuthorityAt`, `commandHelpMarkdown` (in `scripts/`), `commandsCommand`, `configCommand`, `Configuration`, `createProgram`, `environmentOf`, `GlobalFlags`, `httpTokenFile`, `itemOf`, `LOCAL_READ`, `LOCAL_WRITE`, `MCP_HTTP_DEFAULT_PORT`, `mcpServerCommand`, `outputFor`, `privateFiles`, `profileFree`, `ProgramDefinition`, `ProgramOptions`, `readOnlyLockOf`, `refuseUnderReadOnly`, `REMOTE_WRITE`, `renderAnswer`, `rootOf`, `run`, `RunOptions`, `runsCommand`, `settingsFor`, `skillCommand`, `upgradeCommand` |
+| `@wirecat/cli-core/mcp` | `httpLockFile`, `MCP_PATH`, `McpCommand`, `portOf`, `publicUrlOf`, `registerCommands`, `revokeAll`, `runCommandForAgent`, `serveOverHttp`, `toolsFromCommands` |
 | `@wirecat/cli-core/sends` | `Level` |
 | `@wirecat/cli-core/update` | `appUpdate` |
 | `@wirecat/cli-core/testing` | `ARGV_LOG`, `argvLogSetup` |

package/docs/standards/lifecycle.md

@@ -20,9 +20,13 @@ and [WC-SECR-2](security.md#wc-secr-2--a-log-keeps-only-known-attribute-keys-and
 
 ### Who follows these rules today
 
-- **WC-LIFE-15:** tg, max, wa and the template. drive, memo and zm do not keep runs yet; each is adding them on a
+- **WC-LIFE-15:** tg, max, wa, gcal and the template. drive, memo and zm do not keep runs yet; each is adding them on a
   `feat/runs` branch (2026-10-25). zm's `resolveSettings` also returns `keepFailedRuns: false`, which turns off the
   failure log cli-core's `run` would keep.
+- **WC-LIFE-16:** cli-core's shared calendar `sync`, from cli-core 0.464.0 (cli-core #2118); gcal gets it when it
+  moves up from cli-core 0.459.0. The deadlines of WC-LIFE-5 come with the same release. The other syncs
+  (`messages sync` in tg, max and wa, drive's `sync`, memo's mail import, zm's `recordings sync`) are cooperative but
+  spend no request budget yet, and gcal sets no `requestMs` of its own, so it uses the 2 s default.
 
 ## One-shot commands
 
@@ -74,15 +78,31 @@ and [WC-SECR-2](security.md#wc-secr-2--a-log-keeps-only-known-attribute-keys-and
 
 ### WC-LIFE-5 · Bound every one-shot command by a deadline
 
-- **Why:** a command that waits for ever on a dead connection never fails, so nobody learns why it hangs.
+| Command | At a terminal or in a script | Called over MCP |
+|---|---|---|
+| one-shot | 30 s | 30 s |
+| `cooperative` ([WC-LIFE-10](#wc-life-10--mark-a-long-command-cooperative-when-it-should-stop-at-its-own-pace-and-keep-its-work)) | 5 min | 45 s |
+
+`--timeout 2m` or the `<PREFIX>_TIMEOUT` variable sets the deadline, higher or lower. Past the deadline a one-shot
+command fails with `timeout` (exit 9).
+
+- **Why:** a command that waits for ever on a dead connection never fails, so nobody learns why it hangs. Over MCP
+  the client cuts a tool call at about 60 s: the MCP TypeScript SDK's `DEFAULT_REQUEST_TIMEOUT_MSEC` is 60000
+  (`@modelcontextprotocol/sdk` 1.32.1, `dist/esm/shared/protocol.js:8`), and users report the same for Claude Desktop
+  and ChatGPT. A cooperative command answers at 45 s, so the agent gets the answer and the way to continue instead of
+  a cut call. Claude Code waits longer ([its MCP page](https://code.claude.com/docs/en/mcp)), but a CLI does not know
+  its client, so it takes the shortest.
 - **Enforced by:** `cli-core: src/cli/deadline.test.ts` · `cli-core: src/cli/program.test.ts`.
-- **Example:** the default is 30 seconds. `--timeout 2m` or the `<PREFIX>_TIMEOUT` variable changes it. Past the
-  deadline the command fails with `timeout` (exit 9).
+- **Example:** from cli-core 0.464.0, a calendar `sync` in a terminal may run 5 minutes; the same command called over
+  MCP stops at 45 seconds with what it saved. cli-core's `DEFAULT_COMMAND_MS`, `DEFAULT_COOPERATIVE_MS` and
+  `DEFAULT_AGENT_COOPERATIVE_MS` (`src/cli/execution.ts`) hold the three values, and `run()` picks one when it starts
+  the command.
 - **Exceptions:** a `persistent` command has no deadline and ignores `--timeout`. An `interactive` command has none
   while a person is at the terminal; run headless, it keeps the deadline. `--help` and `--version` need none. A
   background fetch started with `<PREFIX>_BACKFILL_JOB` is bounded only by an explicit `--timeout`.
 - **Applies to:** CLIs that run on cli-core's `run()`; other CLIs use cli-base's `createDeadline`. **Since:** cli-base
-  0.41.0. **Rulings:** none.
+  0.41.0 (the cooperative deadlines: cli-base 0.65.0, cli-core 0.464.0). **Rulings:** the owner's deadlines and
+  request budgets (2026-10-27).
 
 ### WC-LIFE-6 · Open nothing until an action needs it
 
@@ -131,7 +151,9 @@ and [WC-SECR-2](security.md#wc-secr-2--a-log-keeps-only-known-attribute-keys-and
 - **Enforced by:** review only.
 - **Example:** `annotate(fetch, { cooperative: true })`. The runner then does not cut the command when the run is
   aborted from outside. The command passes the signal to every operation that can be cancelled, checks it before
-  each write, and stops after the current step. `persistent` commands count as cooperative.
+  each write, and stops after the current step. `persistent` commands count as cooperative. A cooperative command
+  gets the longer deadline of WC-LIFE-5, and a sync among them spends a request budget (WC-LIFE-16), so it stops
+  before the deadline instead of at it.
 - **Exceptions:** none.
 - **Applies to:** all CLIs. **Since:** cli-base 0.41.0. **Rulings:** none.
 
@@ -147,14 +169,15 @@ and [WC-SECR-2](security.md#wc-secr-2--a-log-keeps-only-known-attribute-keys-and
   a CLI's own commands included, connects through `connectFor`: a relayed run gets serve's own adapter, and a run for
   another profile is refused. With no live `serve`, the command connects on its own. A `serve` that offers the socket
   but does not answer gives `provider_unavailable`, never a second connection.
-- **Exceptions:** `serve`, `server`, `bot`, logins, `--offline`, `--dry-run` and `mcp --http` are not relayed.
+- **Exceptions:** `serve`, `server`, `bot`, logins, `--offline`, `--dry-run` and `mcp serve --http` are not relayed.
 - **Applies to:** messenger CLIs with an exclusive connection (wa today). **Since:** cli-base 0.41.0.
   **Rulings:** NEED-1389.
 
 ## Resumable syncs
 
 A long sync — a mailbox, a chat history, a Drive folder, a recording archive — is stopped by a kill, a reboot or a
-provider's limit as often as it ends. These three rules make the next run carry on.
+provider's limit as often as it ends. These three rules make the next run carry on, and WC-LIFE-16 stops a run
+before its deadline.
 
 ### WC-LIFE-12 · Save a long sync's work per item or per page, so a kill loses nothing saved
 
@@ -221,6 +244,44 @@ every value that may be content
 - **Exceptions:** none.
 - **Applies to:** all CLIs. **Since:** cli-base 0.56.0. **Rulings:** none.
 
+## Request budgets
+
+A sync that resumes (WC-LIFE-12 to WC-LIFE-14) also stops on its own before its deadline.
+
+### WC-LIFE-16 · A sync spends a request budget sized to its deadline, and its answer says how to continue
+
+Before each request to the provider, a sync asks its budget whether one more may go. The budget is
+
+`requests = floor((deadline − margin) / requestMs)`, at least one,
+
+where `margin` is the larger of 5 s and 15 % of the deadline, and `requestMs` is how long one request of this CLI is
+expected to take: one constant per CLI, `AppIdentity.requestMs` (2 s when it is not set). `--timeout` changes the
+deadline, and the budget is computed again from it; `--max-pages <pages>` can only lower it. The budget also stops
+when the deadline is closer than the margin plus the slowest request so far, and when the run is cancelled.
+
+When the budget stops the sync before its end, the sync saves where it is (WC-LIFE-12), exits 0 as a declared
+`partial` answer ([WC-OUT-8](output.md#wc-out-8--exit-0-on-a-partial-answer-only-when-the-command-declares-partial))
+and says in the answer why it stopped and how far it got. Its `next` holds the exact command that continues it, the
+same `sync` with the same budget and timeout, marked safe to run unasked; over MCP the step carries that command and
+its arguments for the `read` tool. A run that moved nothing on offers no step, so an agent cannot loop. The sync's
+status command answers how far it is
+([WC-LIFE-14](#wc-life-14--a-syncs-status-command-says-how-far-it-is-in-one-shape)).
+
+- **Why:** a first sync of a large account does not fit one deadline. Without a budget the deadline cuts it mid-page
+  and the run loses its round; with one, every run ends with an answer, saves its work and says how to go on. One
+  `requestMs` per CLI, in one place, keeps the arithmetic the same in every sync of that CLI.
+- **Enforced by:** `cli-core: src/background/budget.test.ts` · `cli-core: src/calendar/testing/sync-contract.ts`.
+- **Example:** `gcal personal sync` over MCP has 45 s: margin 6.75 s, so with the 2 s default about 19 requests. It
+  answers `state: "partial"`, `stopped: "requests"`, `progress: { calendars, calendarsDone, requests, saved }`, and
+  `next` with `gcal personal sync`; `gcal personal status` shows each calendar's progress. cli-core builds the budget
+  with `runBudgetOf(command, maxPages)` from `@wirecat/cli-core/cli` over `runBudget` in
+  `@wirecat/cli-core/background`.
+- **Exceptions:** known gaps, as of 2026-10-27: only the calendar sync spends a budget (see "Who follows"). The
+  continuing step names the command, not the MCP tool, and until the WC-CMD-17 follow-up the router sends that
+  command to `write`, not `read`.
+- **Applies to:** every CLI with a sync. **Since:** cli-base 0.65.0. **Rulings:** the owner's deadlines and request
+  budgets (2026-10-27).
+
 ## Sources
 
 These documents explain the rules on this page in more detail. Where one of them disagrees with this page, this page

package/docs/standards/mcp.md

@@ -15,9 +15,12 @@ Rule ids on this page are `WC-MCP-<n>`. How to read a rule, how ids work and whi
 
 ### Who follows these rules today
 
-tg, max and wa serve cli-core's personal server (`<cli> <profile> mcp`) and bot server (`<cli> <profile> bot mcp`).
-zoom serves the three shared tools over its own commands from zoom-cli 0.35.0 (`zm <profile> mcp`, cli-core's
-`toolsFromCommands` and `runCommandForAgent`). memo and drive have their own servers: memo has hand-written tools, and
+tg, max and wa serve cli-core's personal server (`<cli> <profile> mcp serve`) and bot server (`<cli> <profile> bot mcp serve`).
+`mcp serve --profiles` ([WC-MCP-9](#wc-mcp-9--a-server-serves-the-profiles-it-is-told-with-one-connection-for-each)) is not
+built yet: cli-core serves one named profile.
+zoom serves the three shared tools over its own commands from zoom-cli 0.35.0 (`zm <profile> mcp serve`, cli-core's
+`toolsFromCommands` and `runCommandForAgent`), and gcal does the same (`gcal <profile> mcp`; it moves to `mcp serve`
+when it takes cli-core 0.463.0). memo and drive have their own servers: memo has hand-written tools, and
 drive builds one tool per command from its command tree and skips commands through its own list. Those two are known
 gaps against these rules.
 
@@ -66,12 +69,22 @@ Every entry in the catalogue must be a command the CLI has.
 
 Every command says whether it writes. `read` refuses a command that writes, and `write` refuses one that only reads.
 Both declare the answer envelope (a list `{ items, page, … }` or one thing `{ item, … }`) as their `outputSchema`.
-
-- **Why:** an agent host can let `read` run freely and ask a person before `write`.
+A command that reads the service and only saves what it read into the owner's local store, such as `sync` or
+`calendars list`, is a read and runs through `read`
+([WC-CMD-17](commands.md#wc-cmd-17--declare-effects-on-every-command) defines it).
+
+- **Why:** an agent host can let `read` run freely and ask a person before `write`. `read` carries the MCP
+  `readOnlyHint`, which the [MCP schema](https://modelcontextprotocol.io/specification/2025-11-25/schema#toolannotations)
+  describes as "the tool does not modify its environment". A local copy of what the service already holds changes
+  nothing the owner would have to undo, so a sync stays under it; sending it through `write` would make a host ask a
+  person before every refresh.
 - **Enforced by:** `cli-core: src/mcp/mcp.test.ts` · `cli-core: src/mcp/output-schema.test.ts`.
-- **Example:** `max_read { "command": "messages send", … }` is refused.
-- **Exceptions:** none.
-- **Applies to:** all CLIs. **Since:** cli-base 0.41.0. **Rulings:** none.
+- **Example:** `max_read { "command": "messages send", … }` is refused. Once the gap below is closed,
+  `gcal_read { "command": "sync" }` runs.
+- **Exceptions:** none. Known gap, as of 2026-10-27: cli-core decides with cli-base's `writes()`, which still counts
+  the local write, so `sync` runs through `write` until that follow-up lands (WC-CMD-17).
+- **Applies to:** all CLIs. **Since:** cli-base 0.41.0 (what counts as a read: cli-base 0.65.0). **Rulings:** the
+  owner's ruling on what counts as a read over MCP (2026-10-27).
 
 ### WC-MCP-5 · Unknown arguments are refused before anything runs
 
@@ -116,29 +129,36 @@ profile's permissions, the recipient list and the hourly limit decide.
 
 ### WC-MCP-8 · No `mcp` flag grants access
 
-`mcp --permission <key=level>` may only make a level stricter for that server. An override that would loosen the
+`mcp serve --permission <key=level>` may only make a level stricter for that server. An override that would loosen the
 profile is refused at start-up with `validation_error` naming the key. This includes a parent key that would hide a
-stricter key under it, and lifting a built-in `ask`. `mcp setup --allow-writes` only confirms, at install time, that
+stricter key under it, and lifting a built-in `ask`. `mcp add <client> --allow-writes` only confirms, at install time, that
 the owner saw the profile offers writes.
 
 - **Why:** whoever writes the agent's MCP config must not get more than the profile allows.
 - **Enforced by:** `cli-core: src/cli/messenger/mcp-command-http.test.ts`.
-- **Example:** `max work mcp --permission messages=readonly` works. `max work mcp --permission messages.delete=allow`
+- **Example:** `max work mcp serve --permission messages=readonly` works. `max work mcp serve --permission messages.delete=allow`
   is refused, because the built-in level is `ask`.
-- **Exceptions:** `bot mcp` takes no `--permission` at all. cli-base's flag registry still describes `--allow-writes`
+- **Exceptions:** `bot mcp serve` takes no `--permission` at all. cli-base's flag registry still describes `--allow-writes`
   as "permit writing"; that wording is a gap.
 - **Applies to:** all CLIs. **Since:** cli-base 0.41.0. **Rulings:** NEED-1423.
 
-### WC-MCP-9 · A server speaks for one named profile over one connection
+### WC-MCP-9 · A server serves the profiles it is told, with one connection for each
 
-`mcp` needs a profile, like every command ([WC-ACCT-1](accounts.md)). The server opens one messenger connection and
-every call shares it.
+`mcp serve` serves one named profile (`<cli> <profile> mcp serve`), or the profiles that `--profiles` lists:
+`--profiles work,personal`, or `--profiles all` for every profile on this computer. With neither, it refuses with
+`validation_error` and lists the profiles, like any missing profile ([WC-ACCT-3](accounts.md)). It never serves every
+profile by default. The server opens one messenger connection for each profile it serves, and every call for that
+profile shares it. When it serves more than one profile, each call names its profile; a call without one is refused
+and lists the profiles served. Each call follows its own profile's permissions.
 
-- **Why:** a connection per call would break the messenger's pace limits and look unlike the official client.
+- **Why:** which accounts an agent can reach is the owner's choice, written in the agent's config. A connection per
+  call would break the messenger's pace limits and look unlike the official client.
 - **Enforced by:** review only.
-- **Example:** `max work mcp`. Plain `max mcp` stops and lists the profiles.
+- **Example:** `max work mcp serve`, `max mcp serve --profiles work,personal` or `max mcp serve --profiles all`.
+  Under the last two, a call reads `max_read { "profile": "work", "command": "inbox", "arguments": {} }`.
+  `max mcp serve` alone is refused, and its message lists `personal` and `work`.
 - **Exceptions:** the bot server needs no held connection: each Bot API call is plain HTTPS.
-- **Applies to:** messenger CLIs. **Since:** cli-base 0.41.0. **Rulings:** none.
+- **Applies to:** messenger CLIs. **Since:** cli-base 0.41.0. **Rulings:** NEED-1881.
 
 ### WC-MCP-10 · A tool and its command give the same answer and the same error
 
@@ -170,15 +190,16 @@ it carries.
 
 ### WC-MCP-12 · An MCP server over HTTP follows the same permissions and short-lived logins
 
-`mcp --http` serves on `127.0.0.1` for agents in a browser, behind the owner's tunnel. Writes follow the profile's
+`mcp serve --http` serves on `127.0.0.1` for agents in a browser, behind the owner's tunnel. Writes follow the profile's
 permissions. An access token lives one hour and a refresh token 30 days, replaced on each use. To log in, a browser app
-needs a one-time code that the owner reads in a terminal. `--revoke` ends every login.
+needs a one-time code that the owner reads in a terminal. `mcp revoke` ends every login.
 
 - **Why:** a server reachable from a browser must not be a softer way in than the local one.
 - **Enforced by:** review only.
-- **Example:** `max work mcp --http --public-url https://<name>.ts.net`.
+- **Example:** `max work mcp serve --http --public-url https://<name>.ts.net`.
 - **Exceptions:** none.
-- **Applies to:** messenger CLIs. **Since:** cli-base 0.41.0. **Rulings:** NEED-594, NEED-774.
+- **Applies to:** every CLI that offers `mcp serve --http`: the messenger CLIs, cli-template and every CLI made from
+  it. **Since:** cli-base 0.41.0. **Rulings:** NEED-594, NEED-774.
 
 ### WC-MCP-13 · A tool's hints and descriptions never stand in for the permission check
 
@@ -213,8 +234,11 @@ cli-core builds its personal and bot MCP catalogues from the command tree with `
 - **One server per subtree.** The personal server is built from the program without its `bot` group; the bot server
   from the `bot` group. Both keep three tools (WC-MCP-1).
 - **The profile still decides at run time** what is listed (WC-MCP-6).
-- **The whole catalogue is pinned** in each CLI's `contracts/mcp-tools.json`, so a command that becomes visible to
-  agents shows up as a diff in its pull request.
+- **Two snapshots pin what agents see.** `contracts/mcp-tools.json` pins the tools themselves: with three tools
+  (WC-MCP-1) that is three names and their schemas, which do not change when a command is added. So each CLI also
+  pins the command catalogue behind the tools, every command `tools_search` can return and whether it runs through
+  `read` or `write`, in `contracts/mcp-catalogue.json`. A command that becomes visible to agents then shows up as a diff in
+  its pull request. tg and max keep both; wa, zm, gcal and drive pin only the tools, a known gap as of 2026-10-27.
 
 ## Sources
 

package/docs/standards/new-cli.md

@@ -51,8 +51,8 @@ The reference CLI is the one to compare with when a step is unclear.
 
 The copy already holds every file this handbook asks for: the required root commands (`commands`, `doctor`,
 `skill show`, `skill install`, `mcp`, `upgrade`) and `config` from cli-core, the run log and its `runs` commands
-([WC-LIFE-15](lifecycle.md#wc-life-15--keep-a-run-log-through-cli-core-and-read-it-back-with-runs)), the MCP server with a tool for every
-command, writes included, the community presets in `config/wirecat/`, the TypeScript, Biome and vitest setup,
+([WC-LIFE-15](lifecycle.md#wc-life-15--keep-a-run-log-through-cli-core-and-read-it-back-with-runs)), the MCP server with its three tools
+([WC-MCP-1](mcp.md#wc-mcp-1--a-server-offers-three-tools-not-one-per-command)) that reach every command, writes included, the community presets in `config/wirecat/`, the TypeScript, Biome and vitest setup,
 `contracts/`, `lint/`, the test matrix, the user pages, `CHANGELOG.md`, `SECURITY.md`, `bin/release`, and the
 `pr.yml`, `ci.yml`, `main.yml`, `standards.yml`, `changelog-guard.yml`, `monthly.yml` and `release.yml` workflows.
 The rules they keep are on the area pages: [Commands](commands.md), [MCP](mcp.md), [Accounts](accounts.md),

package/docs/standards/output.md

@@ -93,7 +93,11 @@ JSON Schema 2020-12.
 - **Why:** a caller that checks only the exit code must not take half an answer for a whole one.
 - **Enforced by:** review only.
 - **Example:** a search across accounts declares `annotate(search, { partial: true })` and exits 0 with
-  `meta.complete: false`. Any other command prints what it read, then exits with the code of its first issue.
+  `meta.complete: false`. Any other command prints the whole envelope of what it read on stdout, with
+  `meta.complete: false` and its `issues`, then exits with the code of its first issue. Such an answer is an answer,
+  not a failure, so [WC-OUT-14](#wc-out-14--print-a-failure-in-machine-mode-as-one-json-object-on-stderr-with-stdout-empty)
+  does not apply to it: a caller reads stdout whenever it is not empty, also after a non-zero exit. cli-core's
+  `renderAnswer` does this.
 - **Exceptions:** none.
 - **Applies to:** all CLIs. **Since:** cli-base 0.41.0. **Rulings:** none.
 
@@ -103,7 +107,8 @@ JSON Schema 2020-12.
 - **Enforced by:** review only.
 - **Example:** `next` holds the step to take, then one alternative. Each has `kind` (`command`, or `user_action` with
   no command) and `safe_to_auto_execute`. A step that reads the service and writes only the local store (a sync) is
-  safe. A step that reads nothing remotely and writes locally (`store reindex`) is not: it waits to be asked. A step
+  safe; it counts as a read, also over MCP
+  ([WC-CMD-17](commands.md#wc-cmd-17--declare-effects-on-every-command)). A step that reads nothing remotely and writes locally (`store reindex`) is not: it waits to be asked. A step
   is built from ids, counts and cursors the CLI holds, never from text a message, mail or document carried. A CLI
   answer's command step also has `line`, the whole command with the profile (`tg personal mcp config`), because
   `command` is the bare path an MCP router takes and a copied path without the profile fails.
@@ -160,6 +165,12 @@ JSON Schema 2020-12.
 
 ### WC-OUT-14 · Print a failure in machine mode as one JSON object on stderr, with stdout empty
 
+A failure is a run that has no answer: the command threw. A command that answers with what it could read and
+`meta.complete: false` has not failed, even when it exits non-zero; that case is
+[WC-OUT-8](#wc-out-8--exit-0-on-a-partial-answer-only-when-the-command-declares-partial). So a non-zero exit does not
+mean stdout is empty: stdout empty and one JSON object on stderr is a failure; an envelope on stdout is an answer,
+whole or partial.
+
 - **Why:** a caller tells success from failure without parsing text, and stdout never holds half an answer and an
   error.
 - **Enforced by:** `src/failure.test.ts` · `cli-core: src/cli/agent-contract.test.ts`.

package/docs/standards/permissions.md

@@ -320,9 +320,15 @@ A messenger's keys come from its resources (`messages`, `chats`). Any other CLI
 - **Keys.** Each command is checked against its own path (`events.create`), the default `keyOf`. Housekeeping has no
   key (WC-PERM-5). `extra` adds the keys a command checks inside itself, such as one per generated API method
   (`api.calendar.events.insert`). A key that names no command is refused when it is set or saved.
-- **Defaults.** `defaults` holds the CLI's built-in levels, beside cli-core's. They only ever tighten (WC-PERM-7). A
-  CLI picks them for what its writes do, not by WC-PERM-6's messenger list: they ask before a write people other
-  than the owner see or cannot easily undo, and deny what an agent must never do unasked.
+- **Defaults.** `defaults` holds the CLI's built-in levels, beside cli-core's. They only ever tighten (WC-PERM-7).
+  Like WC-PERM-6 for the messengers, and as tg and drive do: an ordinary change is `allow`; a delete is `ask`; a
+  write that mails or notifies people other than the owner, or deletes a whole series from their calendars, is a key
+  of its own, `deny` until the owner allows it.
+  Sending a message is not this kind of write; a messenger CLI keeps WC-PERM-6.
+- **Shared keys on every path.** A key a shared command checks inside itself, such as `events.notify` or
+  `events.delete.series`, is checked by every path that can do the same thing, the CLI's own generic API commands
+  included. A gcal `api` call that deletes an event with `sendUpdates: "all"` checks `events.notify` as well as
+  its own `api.calendar.events.delete`; otherwise the generic path is a way round the shared key.
 - **Read-only lock and guard.** `<PREFIX>_READ_ONLY` refuses every write to the service, as in WC-PERM-12. Every
   write runs through cli-core's write guard with `permissionDefaults: configuration.permissions.defaults`
   (cli-core 0.455.0), so `ask` is a y/N question at a terminal (WC-PERM-9) and every attempt goes into the send journal
@@ -331,14 +337,21 @@ A messenger's keys come from its resources (`messages`, `chats`). Any other CLI
 - **Why:** one permission model for every CLI; a CLI-own layer drifts from the shared one and is audited by nobody.
 - **Enforced by:** `cli-core: src/cli/command-permissions.test.ts` · `cli-core: src/calendar/cli/writes.test.ts`.
 - **Example:** a calendar CLI takes cli-core's `CALENDAR_WRITE_DEFAULTS` and `CALENDAR_WRITE_KEYS`
-  (`@wirecat/cli-core/calendar`, cli-core 0.458.0): `events create`, `update`, `respond` and `delete` ask, since each
-  changes a calendar other people may share or be invited from; `events.delete.series` (a whole repeating series) and
-  `events.notify` (mail the attendees) are `deny` until the owner allows them. gcal adds its own: a generated
-  `api <method>` that writes asks, and one that shares, empties or gives away a calendar is `deny`.
-- **Exceptions:** known gaps: drive keeps its own policy and `--read-only` flag, zoom reads its own
-  `remote-meetings` key with `levelFor`, and memo uses cli-core's permissions for the shared commands only. None of
-  them declares `commandPermissions` yet.
-- **Applies to:** every CLI that writes and is not a messenger. **Since:** cli-base 0.64.0. **Rulings:** none.
+  (`@wirecat/cli-core/calendar`, cli-core 0.458.0). By this rule `events create`, `update` and `respond` are `allow`
+  and `events delete` is `ask`. `events.delete.series` (every occurrence of a repeating series, in every attendee's
+  calendar) and `events.notify` (the provider mails the attendees) are `deny` until the owner allows them: over MCP
+  `ask` runs without a question, and each reaches people other than the owner. gcal adds its own keys for its generated
+  `api <method>` commands: sharing a calendar is `ask` (NEED-1857), and emptying the main calendar
+  (`api.calendar.calendars.clear`) is `deny`.
+- **Exceptions:** known gaps, as of 2026-10-27:
+  - cli-core's `CALENDAR_WRITE_DEFAULTS` (`src/calendar/writer.ts`) still has `events create`, `update` and
+    `respond` at `ask`.
+  - gcal's generated `api` commands default every write to `ask`, ordinary changes included, and check neither
+    `events.notify` nor `events.delete.series`.
+  - drive keeps its own policy and `--read-only` flag, zoom reads its own `remote-meetings` key with `levelFor`, and
+    memo uses cli-core's permissions for the shared commands only. None of them declares `commandPermissions` yet.
+- **Applies to:** every CLI that writes and is not a messenger. **Since:** cli-base 0.64.0 (the levels and the shared
+  keys on every path: cli-base 0.65.0). **Rulings:** NEED-1857, NEED-1883.
 
 ## Sources
 

package/docs/standards/releases.md

@@ -192,8 +192,14 @@ fixtures, `scripts/`, `.github/`, `bin/release`, `config/`, `lint/`, `contracts/
 
 - **Why:** a stray file in the package can leak local data and grows every install.
 - **Enforced by:** `node-ci.yml:check` · `<app>: pnpm package:check` · `whatsapp-cli: pnpm release:check`.
-- **Example:** `package.json` `files` lists what ships. The CLI's `pnpm release:check` runs `packContents` from
-  `@wirecat/cli-base/release` and fails on any other path in `npm pack --dry-run`.
+- **Example:** `package.json` `files` lists what ships. `packContents(root, allowed, said)` from
+  `@wirecat/cli-base/release` fails on any path in `npm pack --dry-run` outside `allowed`. It checks the pack against
+  the list it is given, not against this rule: a CLI that passes its own `files` list as `allowed`, as the template's
+  `scripts/smoke.ts` does, checks only that npm packs what `files` says, and cannot fail on a wrong `files` list.
+  `npm pack --dry-run` in gcal-cli (2026-10-27) packs 256 files, `src/`, `scripts/`, `.github/`, `config/`,
+  `contracts/`, `lint/` and `template.json` among them, because its `files` list names them; its check cannot see it. The check this rule needs
+  refuses the forbidden paths above whatever `files` says; it belongs in cli-template, so every CLI gets it by
+  `upgrade` ([cli-template#77](https://github.com/WireCatLabs/cli-template/issues/77)).
 - **Exceptions:** cli-template's own package ships the skeleton's sources and configs, since `new` copies them; the
   `files` list `new` writes into a CLI follows this rule. Each CLI's `package:check` runs `packContents`; tg and max
   as `release-check.ts --package-only`.

package/docs/standards/security.md

@@ -310,16 +310,23 @@ store and runs no search. A CLI declares its provider and may replace any step.
   printed. A CLI that signs in another way (a bot token, a session) does not use the module.
 - **Applies to:** every CLI that signs in with OAuth. **Since:** cli-base 0.57.1. **Rulings:** NEED-1734.
 
-### WC-SECR-23 · Meeting passcodes and the query of a join link never reach the store
+### WC-SECR-23 · Meeting passcodes and the query of a join link never reach the store, the output or an agent
 
-- **Why:** a passcode, PIN or join-link query lets anyone who reads the store join the meeting.
+- **Why:** a passcode, PIN or join-link query lets anyone who reads the store, a terminal log or an agent's
+  transcript join the meeting.
 - **Enforced by:** `cli-core: src/store/calendar.test.ts`.
 - **Example:** a calendar entry's description loses each line that carries a passcode, password or PIN, and every
   link loses its query string, so `join_url` holds `https://zoom.us/j/123` without `?pwd=`. A meeting is matched by
   its room (`join_key`, such as `zoom:<number>`), never by a link that carries the passcode.
-- **Exceptions:** a title that names a PIN or a password is kept: it is the meeting's name.
-- **Applies to:** cli-core and every CLI that stores meetings or calendar entries. **Since:** cli-base 0.57.1.
-  **Rulings:** none (Wave 3 requirements 3.4).
+  The same holds for what a command prints and what an MCP tool answers, also when the answer comes straight from
+  the provider and never touched the store: a generic API command removes the provider's passcode fields (Google's
+  `conferenceData.entryPoints[].passcode`, `pin`, `accessCode`, `password`), the query of every join link and the
+  dial sequence after a phone number, and the passcode lines of a description or a location.
+- **Exceptions:** a title that names a PIN or a password is kept: it is the meeting's name. Known gap, as of
+  2026-10-27: gcal's `api` answers drop the conference entry points' secrets (`src/conference.ts`) but keep the
+  description and location as Google sent them.
+- **Applies to:** cli-core and every CLI that stores or shows meetings or calendar entries. **Since:** cli-base 0.57.1
+  (output and agent answers: cli-base 0.65.0). **Rulings:** none (Wave 3 requirements 3.4).
 
 ## Sources
 

package/docs/standards/store.md

@@ -52,8 +52,9 @@ Related pages: which account a read covers, and how a read across accounts is as
   accounts on purpose asks for the whole store with `crossAccount(deps, reason)`; see [Accounts](accounts.md).
 - **Exceptions:** `forAccount` binds only the account areas (accounts, chats, sync, messages, attachments, roster,
   people, conversations, vectors, counters, tags, mentions). The `chats`, `conversations` and `attachments` services
-  use the bound store; the other services still pair `deps.store()` with `deps.account()`. New code uses the bound
-  store.
+  use the bound store; the other services still pair `deps.store()` with `deps.account()`. The calendar areas
+  (calendars, calendar entries, their sync cursors) are not bound either: cli-core's calendar commands pass
+  `accountId` to every call, a known gap as of 2026-10-27. New code uses the bound store.
 - **Applies to:** cli-core and every CLI that adds a service. **Since:** cli-base 0.41.0. **Rulings:** none.
 
 ### WC-STORE-4 · Reach the store through its public module, never a table module

package/docs/standards/testing.md

@@ -171,8 +171,9 @@ and which run after merge is in [CI](ci.md).
 - **Enforced by:** `node-ci.yml:check` · `<app>: pnpm test:matrix:check`.
 - **Example:** under vitest, `run()` appends each parsed command path and option name (never a value) to
   `coverage/argv.jsonl`. `pnpm test:matrix` turns that into `docs/dev/test-matrix.md` and fails on a command or
-  option with neither a test nor a reason. A reason names the live scenario that covers it. A test that calls a
-  function directly does not count.
+  option with neither a test nor a reason. A test counts only when it runs the command through `run()`: a test that
+  calls a function directly records no command line, so the matrix does not see it. A reason says what covers the
+  command instead: the live scenario that runs it, or, for a generated group, the two tests below.
 - **Exceptions:** commands generated from a service's API description, such as drive's and gcal's
   `api <method>` from a Google Discovery snapshot, share one reason for the whole group (`api *` and its options).
   It names two tests: one that checks every generated command's options against the snapshot, and one that drives a
@@ -198,9 +199,13 @@ and which run after merge is in [CI](ci.md).
 - **Enforced by:** `node-ci.yml:check` · `<app>: pnpm contracts:upgrade`.
 - **Example:** `pnpm contracts:upgrade` runs the previous published package and this build on the same synthetic
   state and checks that the data survives. Each store migration also has its own upgrade test (WC-STORE-9).
-- **Exceptions:** a CLI with no local state, or with no published version yet. Local state is data the CLI's own
-  code writes and reads back in a later run, such as a store, a session or a cache. A config file and run records
-  that only cli-core writes do not count.
+- **Exceptions:** a CLI with no local state, or with no published version yet. Local state is data the CLI writes
+  and reads back in a later run, such as a store, a session or a cache. The shared store counts, also when cli-core's
+  code writes it, because the CLI's release decides which cli-core and so which migrations run: gcal's calendars and
+  events in the store are its local state. A config file, run records, the
+  update check, MCP logins and lock files that only cli-core writes do not count. Tests still keep them in the
+  sandboxed home, like every other path
+  ([WC-TEST-1](#wc-test-1--point-every-path-a-test-could-write-at-a-temporary-directory)).
 - **Applies to:** all CLIs with local state. wa has no upgrade contract yet. **Since:** cli-base 0.41.0. **Rulings:** none.
 
 ### WC-TEST-15 · A refactor keeps `commands --json` and the MCP tool list as they were

package/docs/standards/time.md

@@ -76,7 +76,14 @@ local midnight. The answer gives the window it used, in UTC.
 - **Why:** "messages of 1 September" means the owner's day, not the UTC day, which starts hours earlier or later.
 - **Enforced by:** review only.
 - **Example:** in `Asia/Vladivostok`, `--since-time 2026-09-01` gives `meta.window.since` = `2026-08-31T14:00:00.000Z`.
-- **Exceptions:** none.
+  A thing that has only dates, such as an all-day event (`start_date` 2026-09-01, `end_date` 2026-09-02, the end
+  not included), matches by comparing local dates, never UTC moments: it is in the window when its dates overlap the
+  local dates the window covers. So in `Europe/Madrid` a filter for 1 September returns the all-day event of
+  1 September and not the one of 31 August, whatever zone the event's calendar is in.
+- **Exceptions:** none. Known gap, as of 2026-10-27, read from the code and not run: cli-core's event filter
+  (`src/store/sqlite/calendar.ts`, the `events` query) compares `starts_at` and `ends_at` with the UTC window for
+  all-day events too, and gcal stores an all-day event's start as midnight in its calendar's zone. The two agree
+  when the calendar's zone is the zone in use, and miss by a day at the edges when it is not.
 - **Applies to:** all CLIs. **Since:** cli-base 0.48.0. **Rulings:** none.
 
 ### WC-TIME-6 · Run the tests in a zone that is not UTC, and prove stored values do not depend on it

package/docs/standards/toolchain.md

@@ -200,8 +200,13 @@ no-unbounded-spread ([WC-TOOL-12](#wc-tool-12--do-not-spread-a-list-of-user-data
   request.
 - **Enforced by:** `<app>: pnpm lint:commands`.
 - **Example:** `"lint:commands": "cli-dev lint --cli dist/bin/max.js"`, run by `ci:quick` after the build. Known
-  violations live in `lint/baseline/<rule-id>.json`; an entry with no violation left fails the run. A permanent
-  exception goes in `lint/overrides.json` with `rule`, `target`, `reason`, `owner` and `review_after`. More than 10
+  violations live in `lint/baseline/<rule-id>.json`; an entry with no violation left fails the run. A violation that a
+  shared package forces, such as a verb cli-core names before the vocabulary has it, goes in the baseline too and
+  comes out when the shared package catches up. A word the CLI needs that the vocabulary does not have yet goes in
+  `lint/overrides.json`, never in the baseline: its `reason` links the cli-base pull request or issue that adds the
+  word, and it comes out in the change that takes the cli-base release with the word. The shared package's words
+  go in the baseline, as above; the CLI's own go in the overrides, where the count and the date keep them few. A permanent exception also goes in `lint/overrides.json`, with `rule`, `target`, `reason`, `owner`
+  and `review_after`. More than 10
   overrides fail the run, and so does one past its date. The rules themselves are on the
   [Commands page](commands.md).
 - **Exceptions:** zoom runs `lint:commands` in full validation only. cli-core runs its own command lint test in

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wirecat/cli-base",
-  "version": "0.64.0",
+  "version": "0.65.0",
   "description": "The parts every command line tool needs: output modes, terminal rendering, error model, exit codes, credentials, clocks",
   "license": "Apache-2.0",
   "author": "Viacheslav Ptsarev",