[leemour]

Why

cli-core 0.384.0 (WireCatLabs/cli-core#1730) makes every typed date filter say how it read the date: meta.timezone names the zone a value without its own zone was read in, and meta.window: { since?, until? } gives the bounds in UTC (WireCat Time rules WC-TIME-3 and WC-TIME-5). cli-core 0.384.0 needs cli-base >=0.49.0 <0.50.0.

What

• @wirecat/cli-core 0.380.0 → 0.384.0 and @wirecat/cli-base 0.48.0 → 0.49.0, exact pins.
• docs/commands.md regenerated by pnpm generate: chats show 2 more fields (muted_until, marked_unread, cli-core 0.382.0), messages 1 more (delivery, which max does not send).
• CHANGELOG.md, under Не выпущено: the new meta fields with max's own commands, and the changes 0.381–0.383 also bring to max users — new chat fields, inbox/review over stored chats leave out muted and archived chats, an unwritable store is permission_error (exit 5), a name copied with its emoji finds the chat.
• .github/workflows/ci.yml still pins the cli-base workflow at v0.48.0; no check asked for a change.
• MCP snapshot (contracts/mcp-tools.json) unchanged: the tools take generic arguments, so no output schema is recorded there.

Testing

• pnpm test under TZ=Asia/Vladivostok, TZ=America/Los_Angeles and TZ=UTC: 132 files, 1539 passed, 7 skipped in each.
• pnpm lint, typecheck, docs:check, contracts:check, version:check, standards:check, lint:commands, test:matrix, parity:check, security:no-leak, package:check, and generate:check after the commit: all pass.
• release:check fails only on release-time items (version already on npm, Не выпущено not dated); expected, no release here.

🤖 Generated with Claude Code

[leemour]

Blocked by a cli-core bug, so this PR is a draft now.

contracts:upgrade fails at candidate-rejects-legacy-store: it expects exit 3 and gets exit 1 (internal_error, command.crashed in fillFolded). The same thing happens locally.

Cause: the legacy store that @wirecat/legacy-cli 0.43.1 seeds records schema version 29 with min_compatible 28 in schema_migrations. That number comes from the old schema numbering. migrate() refuses a file only when minCompatible > ours:

• cli-core 0.380.0 speaks schema 25, so 28 > 25 and the file is refused with configuration_error (exit 3).
• cli-core 0.382.0+ speaks schema 28, so 28 > 28 is false. The file is taken as a newer store that is still compatible, opened, and then the first read of a column it does not have crashes.

Once cli-core reaches schema 29, this legacy store will look current. The fix belongs in cli-core: detect the legacy schema line some way other than the version number. The rest of the bump is green.