0.51.0

Что нового

• У каждого max watch своя очередь. Медленный наблюдатель больше не задерживает остальных; буфер — 64 MiB на
  наблюдателя и 256 MiB на всех, max serve --max-subscriber-buffer-bytes и --max-subscriber-total-buffer-bytes
  меняют их, 0 снимает предел.
• max mentions: телефоны, почта, ссылки и документы Google из сохранённых сообщений (cli-core 0.264.0,
  версия базы 7). mentions list kind:phone, mentions list domain:google.com; слово без поля — значение в любой
  записи, 89001234567 найдёт +79001234567. mentions show <id> показывает текст вокруг. Сообщения, сохранённые
  раньше, читает один max <профиль> mentions rebuild; новые читаются при записи.
• max mentions confirm|reject, упоминания в файлах и голосовых, поиск по phone:, email:, url:, domain:
  (cli-core 0.269.0, версия базы 11). mentions confirm <id> [person:<uid>|organization:<id>] записывает, чей это
  телефон или адрес (организации тоже), mentions reject <id> отклоняет значение насовсем; автор записи — агент
  или владелец (--as-owner). Текст из файлов и расшифровки голосовых тоже даёт упоминания (поле file_text или
  transcript); сохранённые раньше читает один mentions rebuild. Поиск сообщений находит их по phone:"8 900 000-00-01", domain:docs.google.com, email:"ana@example.com". Старые сборки базу читают как раньше.

Изменено — может сломать скрипты

• Сборка на @wirecat/cli-core 0.269.0: contacts timeline листается как остальные списки. Список, обрезанный
  --limit, отвечает page.has_more: true, page.cursor и шагом page.next (--cursor продолжает с теми же
  --scope, --since-time и --until-time); раньше было has_more: false и meta.truncated. meta.truncated
  остаётся для изменений, ещё стоящих в очереди. Заметка «cut at --limit» на stderr исчезла. Что учесть: скрипты,
  читавшие meta.truncated у contacts timeline, читают page.has_more.
• Ключи ошибок — snake_case и у max bot, и у отправки без ответа. Код отказа MAX у бота теперь
  error.details.max_code (был maxCode); outcome_unknown при отправке сообщения отдаёт send_id (был sendId).
• На @wirecat/cli-core 0.270.0 и @wirecat/cli-base 0.27.2.
• --json=<поля> заменяет --fields и --agent-json, их больше нет. --json=id,text оставляет эти поля каждого
  элемента. JSON в CLI сохраняет текст как есть; ответы MCP по-прежнему показывают невидимые символы.
• tags list, tasks list и conversations list принимают запрос вместо флагов-фильтров.
  tags list tag:work type:chat, tags list sources:auto; tasks list state:open kind:promise chat:<id>;
  conversations list <чат> started_at>=7d. Флагов --tag, --type, --source, --state, --chat, --before-time
  и --since-time у этих списков больше нет. Элементы — общие сущности: метка называет, на чём она, как target,
  разговор отдаёт messages_count, started_at, first_message.

Исправлено

• max serve не теряет вход, если его закрыли в момент ответа MAX. Состояние профиля и обновлённый токен
  сохраняются до проверки на закрытие: MAX этот вход уже засчитал, и следующий запуск не входит заново.
• Переполненный общий буфер max watch отключает того, кто держит больше всех, а не того, кому пишут следующим.
  Отказ приходит в watch с кодом invalid_response и причиной output.too-large, а не provider_error.
• Запись о неудачном запуске снова хранит код отказа MAX (providerError, например proto.payload). С cli-core
  0.263.0 он читается из error.details.provider_error, а max писал providerError, и код терялся; так же опрос
  «уже проголосовали» и повторная попытка после not.found смотрят на новый ключ.
• MaxClient называет файл от 2 ГиБ таким, а не «it cannot be read». Файл по пути в send({ files }) и фото
  группы или профиля сначала проверяются по размеру: Node не читает файл от 2 ГиБ, и ошибка теперь говорит это.
• max <бот> bot chats members add берёт не больше 100 человек за раз. Bot API MAX принимает до 100 id в одном
  запросе; список длиннее теперь отказывается до запроса и просит разбить его на несколько запусков.