@wirecat/cli-base 0.52.0 → 0.53.0

package/CHANGELOG.md

@@ -8,6 +8,16 @@ 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.53.0 — 25.10.2026
+
+### Added
+
+- **A rule for the provider registry** (`WC-ARCH-21`, [Architecture](docs/standards/architecture.md)): a CLI registers its provider in the store on every run, and a row whose provider no one registered is skipped, never searched as messages. It matches cli-core's stored registry. The Data model, Store and Security pages also list what the approved Wave 3 design adds and is not built yet: files, calendars, contacts by address, one link log and review list, a CLI's own SQLite file, and the sign-in module. The Data model page now names the attendee table `calendar_entry_participants`, lists `meeting_participants` among the known gaps, and names cli-core's schema test as the check of `WC-DATA-2` to `WC-DATA-4`.
+
+### Changed — may break callers
+
+- **Every handwritten list needs a query declaration.** The command lint checks lists that lack answer metadata too. Release this with the matching cli-core list-query changes and consumer updates.
+
 ## 0.52.0 — 25.10.2026
 
 ### Added
@@ -16,6 +26,7 @@ Every entry says what changed as a caller sees it, why, and what to watch for
 - **`cli-dev <command> --help`** prints the usage, as `cli-dev --help` does, instead of failing on an unknown option.
 
 - **A data-model page in the standards** (`WC-DATA-1` to `WC-DATA-7`, [Data model](docs/standards/data-model.md)). It says which records cli-core owns and which stay private to a CLI, keeps a source's records (a calendar entry, a Drive file, a mail contact) apart from the owner's entities (an event, a document, a person), puts every provider id in `external_id`, lists the standard field names, and makes every link record how it was made, with no link when two candidates tie. Nothing changes in code; older tables follow the rules when they next change.
+
 ## 0.51.1 — 24.10.2026
 
 ### Fixed

package/dist/dev/lint.js

@@ -342,10 +342,10 @@ const CHECKS = {
             .map(({ target, option }) => ({ target, message: `${longName(option.flags)} has no role in the vocabulary` }));
     },
     "list-without-query": (document) => handwrittenLeaves(document)
-        .filter((command) => command.name === "list" && command.output !== undefined && command.query === undefined)
+        .filter((command) => command.name === "list" && command.query === undefined)
         .map((command) => ({
         target: label(command),
-        message: `answers with ${command.output?.entity} but takes no query`,
+        message: "list declares no query",
     })),
     "query-example": (document) => walk(document.commands).flatMap((command) => command.query
         ? exampleProblems(command.query).map(({ field, problem }) => ({

package/docs/standards/README.md

@@ -32,7 +32,7 @@ rules it keeps. A new CLI is ready for its first release when every check under
 | [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 |
 | [Permissions](permissions.md) | `PERM` | 21 | Levels, keys, defaults, hard limits, the write guard and its journal |
-| [Architecture](architecture.md) | `ARCH` | 16 | Layers, dependency direction, vendor types, what goes in which package |
+| [Architecture](architecture.md) | `ARCH` | 17 | Layers, dependency direction, vendor types, what goes in which package |
 | [Lifecycle](lifecycle.md) | `LIFE` | 13 | Opening late, who closes, one-shot exits, long-running commands, the `serve` relay, resumable syncs |
 | [Store](store.md) | `STORE` | 14 | Store areas, account scope, migrations, test isolation |
 | [Data model](data-model.md) | `DATA` | 7 | Core entities, entities and source records, `external_id`, field names, links and duplicates |

package/docs/standards/architecture.md

@@ -204,6 +204,24 @@ at start-up and the `serve` relay are in [Lifecycle](lifecycle.md); the store's
 - **Exceptions:** none.
 - **Applies to:** cli-base. **Since:** cli-base 0.41.0. **Rulings:** NEED-15.
 
+### WC-ARCH-21 · A CLI registers its provider in the store; an unknown provider's rows are skipped, never guessed
+
+Every run, a CLI writes its provider's entry — `{ name, kind, aliases, command }` — with `registerProvider` from
+`@wirecat/cli-core/store`. cli-core reads its built-in providers plus the stored entries when the store opens, so
+every other CLI knows the new provider's kind without a cli-core release. A row whose provider no entry names is left
+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.
+- **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.1. **Rulings:** none
+  (Wave 3 requirements 3.2).
+
 ## 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/data-model.md

@@ -33,6 +33,13 @@ is rewritten only to follow it:
   and nothing joins the two (WC-DATA-6).
 - `events` rows made from Zoom meetings have no source record of their own besides the meeting (WC-DATA-2 holds:
   `meetings` is that record).
+- Local folders are accounts with provider `folder` (an Obsidian vault and a plain folder look the same), and Drive's
+  stand-in account uses it too (WC-DATA-3).
+- Contacts live in `identities`, with no address column: an address is only the `external_id` of provider `email`
+  (WC-DATA-6).
+- `documents` keeps its source columns (`account_id`, `external_id`, `url`, `mime`, `front_matter`…) next to the
+  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).
 
 ## Rules
 
@@ -59,7 +66,7 @@ to its entity. One entity may combine source records from several sources and ac
 
 - **Why:** the same meeting in two calendars and in Zoom is one event to the owner; the same document in Drive and on
   disk is one document.
-- **Enforced by:** review only.
+- **Enforced by:** `cli-core: src/store/sqlite/schema.test.ts`, for the entity tables only; which table is which kind is review.
 - **Example:** a Google Calendar entry is a `calendar_entries` row with `event_id`; the Zoom recording of that meeting
   is a `meetings` row with the same `event_id`.
 - **Exceptions:** an entity the owner makes has no source record; a source record may wait unlinked until matching
@@ -73,7 +80,7 @@ record has no account). Never in a column named after the provider (`google_id`,
 `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.
-- **Enforced by:** review only.
+- **Enforced by:** `cli-core: src/store/sqlite/schema.test.ts`.
 - **Example:** a Drive file: `files.external_id = '<Drive file id>'`; a Google calendar entry:
   `calendar_entries.external_id = '<event id>'`, `ical_uid = '<iCalUID>'`.
 - **Exceptions:** a local file has no provider id; its `external_id` is its path relative to its folder root.
@@ -103,7 +110,7 @@ Times are UTC milliseconds ([Time](time.md)).
 
 - **Why:** a reader of any table knows what a field holds, and a new table does not invent a third name for "edited
   at".
-- **Enforced by:** review only.
+- **Enforced by:** `cli-core: src/store/sqlite/schema.test.ts`.
 - **Example:** `files.external_updated_at`, not `modified_at` or `modifiedAt` in JSON.
 - **Exceptions:** existing columns keep their names until their table changes for another reason.
 - **Applies to:** cli-core. **Since:** cli-base 0.52.0. **Rulings:** NEED-1732.
@@ -141,17 +148,32 @@ link is made and the pair goes to the owner's review list. Title or time overlap
 
 ## Planned — not built yet
 
-From the Wave 3 requirements (cli-private `plans/2026-10-24-open-cli-core-design.md`, under the owner's review):
-
-- a `files` table as the source record of `documents`: a materialised `path` plus `parent_id` to the folder's own
-  row, so a folder is found by path prefix and a document by part of its path (NEED-1739);
-- memo's vault files as documents; an Obsidian vault is provider `obsidian` with its own metadata (tags, aliases,
-  wiki links), a plain folder is `local`; `notes` are only the owner's notes on entities (NEED-1738);
-- a cli-core helper that opens a CLI's own SQLite file (NEED-1737);
-- `calendars`, `calendar_entries` and `calendar_attendees` on the `events` hub;
-- an `email` column on contacts, so one address joins one person across sources;
-- one link log for events and documents, and one review list for ambiguous pairs;
-- renaming `identities` to `contacts`.
+From the Wave 3 requirements, approved by the owner on 2026-10-24 (cli-private
+`plans/2026-10-24-open-cli-core-design.md`, sections 3.3–3.6). Each item moves into the rules in the pull request that
+builds it.
+
+- **Files.** A `files` table holds the source records of `documents`: one row per item in one place (a local file, a
+  Drive file or folder, later a Notion page). It has `account_id`, `external_id` (a local file's path relative to its
+  root), `kind` (`file`, `folder`, `page`), `name`, `path` and `path_folded` from the account root, `parent_id` to the
+  folder's own row, `document_id`, the file facts and the provider's times (NEED-1739).
+- **Matching a file to a document:** the same account and `external_id` is the same file; a `content_hash` equal to
+  the preferred file of exactly one live document joins that document; more than one candidate goes to the review
+  list; otherwise a new document. The document shows its most recently changed file, unless the owner pins one.
+- **Folder accounts by kind.** Provider `obsidian` for a vault (front matter, tags, aliases and wiki links kept as
+  Obsidian's own metadata), `local` for a plain folder; Drive files under a real `google-drive` account. memo's vault
+  files are documents; `notes` are only the owner's notes on entities (NEED-1738).
+- **Calendars.** `calendars` and `calendar_entries` (source records) feed `events` and `event_series` (entities).
+  Attendees are `calendar_entry_participants`; changes to tracked fields go to `calendar_entry_revisions` first. An
+  entry joins an event by, in order: the same Google id; the same series slot (`original_starts_at`); the same
+  `ical_uid` in another calendar; a Zoom event with the same `join_key` and an overlapping time; else a new event.
+- **History on delete.** An event deleted in Google keeps its past occurrences with `source_deleted_at`; future ones
+  become `cancelled`. Nothing is removed without an explicit owner command (NEED-1764).
+- **Contacts by address.** A lower-cased `identities.email` column; contacts with the same address link to one
+  person (method `email`) unless the owner said otherwise; two persons with one address go to the review list.
+- **One link log and one review list.** `entity_link_events` logs link changes for events and documents in the shape
+  of `identity_link_events`; one review list of ambiguous pairs for every entity, resolved by the owner.
+- **A CLI's own SQLite file**, opened through a cli-core helper ([Store](store.md), NEED-1737).
+- **Later:** renaming `identities` to `contacts`; dropping `documents`' source columns once nothing reads them.
 
 ## Sources
 

package/docs/standards/security.md

@@ -1,6 +1,6 @@
 # Security
 
-<!-- cspell:words zizmor -->
+<!-- cspell:words zizmor PKCE -->
 
 ## Scope
 
@@ -271,6 +271,21 @@ not carried out. A name that matches is not proof of who someone is.
   tells an agent about it is [WC-MCP-11](mcp.md#wc-mcp-11--the-server-tells-the-agent-that-message-text-is-data).
 - **Applies to:** all CLIs. **Since:** cli-base 0.44.0. **Rulings:** none.
 
+## Planned — not built yet
+
+From the Wave 3 requirements, approved by the owner on 2026-10-24 (sections 3.4 and 3.7). Each item moves into the
+rules in the pull request that builds it.
+
+- **One sign-in module** in cli-core, `@wirecat/cli-core/oauth`, with no store and no search: authorize (a loopback
+  address on `127.0.0.1` or a relay page, `state`, PKCE S256, a timeout, cancel, a paste fallback), exchange, refresh
+  and revoke, and a token keeper with a lock per profile across processes. A CLI declares its provider and may
+  replace any step, but keeps the explicit profile, the lock, and tokens that are never printed (NEED-1734).
+- **Keys in one place:** one keyring naming scheme for new entries; today's entries of drive and zm are read as they
+  are, so no one signs in again.
+- **Meeting secrets never reach the store:** passcodes, PINs, passwords and access codes from a calendar's conference
+  data, and the query string of any join URL. Lines of a description that carry a passcode, password or PIN are
+  removed.
+
 ## 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/store.md

@@ -185,6 +185,17 @@ messages), or other people's data.
 - **Exceptions:** none.
 - **Applies to:** all CLIs that use the store, and cli-core. **Since:** cli-base 0.41.0. **Rulings:** none.
 
+## Planned — not built yet
+
+From the Wave 3 requirements, approved by the owner on 2026-10-24 (NEED-1737). It moves into the rules in the pull
+request that builds the helper.
+
+- **A CLI's own tables live in its own SQLite file**, next to the shared store, with its own migrations. They refer to
+  core rows by id only, and no other CLI opens that file. A cli-core helper opens it (the path, the migrations, the
+  same driver); it is built when the first CLI needs private tables.
+- **WC-STORE-5 gets a check:** a grit plugin, `no-sqlite-driver`, that refuses a CLI's import of a SQLite driver or
+  of `drizzle-orm`. cli-core, which owns the store, turns it off.
+
 ## Sources
 
 These documents explain the rules on this page in more detail. Where one of them disagrees with this page, this page

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wirecat/cli-base",
-  "version": "0.52.0",
+  "version": "0.53.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",