# История изменений (/ru/docs/b24/changelog)

Заметные изменения в `@wirecat/bitrix24-cli`. По одному разделу на версию, новые сверху.

## 0.14.0 — 12.11.2026 [#0140--12112026]

### Добавлено [#добавлено]

- **`b24 guide` показывает сценарии для частых задач**: команды по порядку и зачем каждая. `first-sync` (первая
  синхронизация и доска воронки), `keep-in-sync` (таймер и поиск) и `safe-agent-writes` (агент через MCP, чьи
  записи остаются под вашим контролем). `b24 guide <name> --json` выдает один сценарий как данные.
- **Страницы [MCP](/llms.mdx/docs/ru/b24/mcp/content.md) и [Разрешения](/llms.mdx/docs/ru/b24/permissions/content.md).** Как подключить `b24` к агенту, что агент видит и
  чего ему никогда не предлагают. Каждый уровень, встроенные уровни, ключи, которые проверяет одна команда, и
  проверки, которые не снимает ни один уровень.
- **Вход через локальное приложение.** `b24 <profile> session start --portal <host> --client-id <id>` входит через
  локальное приложение, которое вы создаете на портале, в браузере и действует с правами сотрудника, который вошел.
  Ключ приложения спрашивается скрытым вводом или читается из stdin или `B24_BITRIX24_CLIENT_SECRET`. Вход
  возвращается через `https://wirecat.dev/webhooks/apps/b24-callback` или через адрес, который вы вставите. Токены
  обновляются сами. `session status` и `session list` показывают способ входа, а `session end` забывает любой из
  них. Входящий вебхук остается быстрым способом, см. [вход](/llms.mdx/docs/ru/b24/usage/content.md#with-a-local-application).

### Исправлено [#исправлено]

- **Быстрый старт копирует сделки.** В [README](https://github.com/WireCatLabs/bitrix24-cli/blob/v0.14.0/README.md)
  теперь до первого `sync` выбирается, чьи сделки и лиды копировать, а до этого он ничего не копирует. README больше
  не говорит, что администратор копирует всю CRM, говорит, что через MCP удаление с уровнем `ask` выполняется, и
  называет `wcat-b24` на случай, если первой находится команда `b24` из другого пакета. В
  [устранении неполадок](/llms.mdx/docs/ru/b24/troubleshooting/content.md) есть ошибка "no CRM user is chosen".
- **Через MCP `ask` не останавливает запись.**
  [README](https://github.com/WireCatLabs/bitrix24-cli/blob/v0.14.0/README.md), [безопасность](/llms.mdx/docs/ru/b24/security/content.md) и
  первый экран советовали ставить `deals.move` на `ask` против роботов портала. Но так перемещение останавливается
  только в терминале: через MCP отвечать некому, и запись проходит. Теперь там сказано ставить `readonly` или `deny`
  или включить подтверждение в клиенте агента.
- **Навык агента покрывает то, что агенту нужно.** В `b24 skill show` теперь есть коды выхода и причины ошибок, MCP
  и ловушка с `ask`, первая настройка от вебхука до первой синхронизации, границы записи и подводные камни.
- В примерах везде профиль `work` вместо `personal`.
- **`b24 commands` показывает CRM по разделам.** Сделки, лиды, контакты и компании разделены на Read и Write,
  воронки, стадии, поля, товары, пользователи и `api` стоят в Read, `sync` в Automate, а `session` в Set up. Раньше
  большая часть `b24` была в Other.
- **Два локальных файла состояния пишутся атомарно и остаются закрытыми.** Список ваших собственных компаний и
  дневной счетчик показанных чужих клиентов теперь пишутся через временный файл и переименование, как и файл
  настроек.
- **Ежедневный `sync` больше не читает всех клиентов заново.** Раунд изменений читал каждый контакт и каждую
  компанию из сделок и лидов выбранных пользователей, даже если ничего не менялось. На портале с 50 000 сделок это
  было около 300 запросов и почти три минуты на синхронизацию без новых данных. Теперь он читает только клиентов
  изменившихся сделок и лидов, а сделки пользователей для их клиентов получает один раз за синхронизацию, а не
  отдельно для контактов и для компаний.

## 0.13.0 — 11.11.2026 [#0130--11112026]

### Изменено — может сломать вызовы [#изменено--может-сломать-вызовы]

- **Удаляет и очищает в CRM только вебхук администратора Битрикс24.** Для любого другого вебхука `b24` отклоняет
  `deals delete`, `leads delete`, `api call` к методу, который удаляет (его имя заканчивается на `.delete`,
  `.deletefieldvalue` или `.markdeleted`), обновление или `.set`, которое делает поле пустым (пустое значение,
  `null`, `[]`, связь с компанией, контактом или лидом `0`, телефон или e-mail с пометкой `DELETE: Y`), а также
  `batch`. Отказ приходит как `permission_error` с причиной `employee.delete`, `employee.clear` или `employee.batch`,
  и ни один уровень разрешений его не снимает. При создании поля по-прежнему можно оставить пустыми.
- **Отвязывает записи и объединяет дубли только вебхук администратора Битрикс24.** Для любого другого вебхука
  `api call` отклоняет метод, имя которого заканчивается на `.unbind`, например `crm.timeline.bindings.unbind`, с
  причиной `employee.unbind`, и объединение дублей `crm.entity.mergeBatch`, которое удаляет все записи, кроме одной,
  с причиной `employee.merge`. Как и для удалений, ни один уровень разрешений этого не снимает.
  `crm.deal.contact.delete` и `crm.deal.contact.items.delete` и раньше считались удалениями.
- **Аккаунт портала хранится как рабочий.** Первый `sync`, запись или чтение в профиле сохраняет аккаунт нового
  портала с областью `work`, поэтому рабочие представления и подготовка к встречам читают его копию, а личные чтения
  ее пропускают. Портал, который уже есть в хранилище, сохраняет свою область, а во всех хранилищах до сих пор это
  `personal`. Переключите ее один раз командой `memo groups update bitrix24:<portal> --scope work` (memo 0.131.81
  или новее). Синхронизация никогда не меняет область обратно.

## 0.12.0 — 10.11.2026 [#0120--10112026]

### Добавлено [#добавлено-1]

- `store apply` убирает из копии, сделанной при `scope mine`, контакты, которые не названы ни в одной сделке или
  лиде выбранных пользователей и не относятся ни к одной оставленной компании, а также людей, которые после этого
  остаются пустыми. Без `--yes` команда только считает. Синхронизация, которая сужает копию, или `sync --rescan`
  делают это сами, и в их ответе количество приходит как `contacts_removed`.
- **Основан на cli-core 0.631.0** (было 0.630.0). При первом открытии хранилище переходит на версию 64: сохранение
  или удаление связи сделки с человеком больше не читает все такие связи. Что изменилось, описано в
  [истории изменений cli-core](https://github.com/WireCatLabs/cli-core/blob/main/CHANGELOG.md).

### Изменено — может сломать вызовы [#изменено--может-сломать-вызовы-1]

- Синхронизация копирует только сделки и лиды пользователей, которых владелец выбрал в
  `crm.bitrix24:<portal>.unassigned`, и их клиентов. По умолчанию не выбран никто, даже пользователь самого
  вебхука. Пока владелец не выберет, синхронизация отклоняется (`configuration_error`, причина
  `bitrix.scope-users-unchosen`) и называет `config set`, который нужно выполнить. Обратите внимание, что
  существующая копия упадет при следующей синхронизации, пока владелец не выберет пользователей.
- Ни одна синхронизация больше не копирует всю CRM, даже у администратора. Синхронизация при сохраненном
  `scope all` отклоняется (причина `bitrix.scope-all-refused`, было `bitrix.scope-all-admin-only`) и предлагает
  поставить `mine`. После этого сделки и лиды невыбранных пользователей помечаются удаленными в локальной копии.
  Любого другого клиента можно найти на портале напрямую через `people list` или `organizations list`.
- Вебхук сотрудника может выбрать себя, уволенного пользователя или не сотрудника, а вебхук администратора кого
  угодно.

### Исправлено [#исправлено-1]

- Имя контакта больше не несет `null` или `null #<id>`, которые импорт в портал оставил в полях имени ("Ярослав Орлов
  null #907" теперь "Ярослав Орлов"). На одном живом портале так было у 101 876 из 114 165 контактов. Обратите
  внимание, что имя, сохраненное раньше, сохраняет этот хвост, пока контакт не синхронизируется снова.
- **Основан на cli-core 0.630.0** (было 0.623.0). При первом открытии хранилище переходит на версию 63. Контакт CRM
  больше не присоединяется к вашему собственному человеку и не переименовывает его, а два контакта с общим ящиком
  или телефоном компании остаются двумя людьми. Что изменилось за это время, описано в
  [истории изменений cli-core](https://github.com/WireCatLabs/cli-core/blob/main/CHANGELOG.md).

## 0.11.0 — 10.11.2026 [#0110--10112026]

### Изменено — может сломать вызовы [#изменено--может-сломать-вызовы-2]

- При `scope mine` синхронизация копирует только клиентов пользователя: контакты и компании, назначенные ему или
  пользователю из списка ничьих, и те, что названы в копируемых сделках и лидах. Раньше она копировала всю базу
  контактов и компаний портала, 114 165 контактов на одном живом портале, где у пользователя не было ни одной
  сделки. Ежедневный проход по удалениям тоже перечисляет только эти id. Обратите внимание, что копия, в которой уже
  есть вся база, сохраняет свои контакты, а компании ждут `sync --rescan`.
- Синхронизировать при `scope all` может только администратор Битрикс24. Руководителю отдела отказывают так же,
  как сотруднику (`bitrix.scope-all-admin-only`, было `bitrix.scope-all-manager-only`).
- Все, кроме администратора Битрикс24, видят телефоны и e-mail только своих клиентов. `people list` и
  `organizations list` не показывают их у остальных, а `people show` и `organizations show` для одной записи
  показывают, но не больше 100 таких контактов и компаний в день на пользователя и его агентов вместе. `api call`
  отклоняет чтение контактов и компаний (`crm.contact.*`, `crm.company.*`, `crm.item.*` типа 3 или 4, реквизиты,
  адреса, поиск дублей) для всех, кроме администратора, что бы ни говорили разрешения.
- Назвать работающего сотрудника в `crm.bitrix24:<portal>.unassigned` может только администратор Битрикс24.
  Руководитель отдела, как и все остальные, может назвать только уволенных пользователей и не сотрудников.
- **Основан на cli-core 0.623.0** (было 0.621.0). При первом открытии хранилище переходит на версию 61 (связи между
  людьми, только добавления). Что изменилось за это время, описано в
  [истории изменений cli-core](https://github.com/WireCatLabs/cli-core/blob/main/CHANGELOG.md).

## 0.10.0 — 09.11.2026 [#0100--09112026]

### Добавлено [#добавлено-2]

- `session start` и `session status --check` отвечают рядом с `admin`, `manager` ли пользователь вебхука, то есть администратор
  Битрикс24 или руководитель отдела.

### Изменено — может сломать вызовы [#изменено--может-сломать-вызовы-3]

- Все сделки и лиды копирует только руководитель: синхронизация при `crm.bitrix24:<portal>.scope all` отклоняется
  (`configuration_error`), если пользователь вебхука не администратор Битрикс24 и не руководитель отдела. Это
  проверяется при каждой синхронизации. Все остальные копируют свои сделки и лиды и ничьи, а отказ советует поставить
  `scope` в `mine`. Обратите внимание, что без области `department` у вебхука руководитель отдела считается
  сотрудником.
- Для всех, кроме руководителя, `crm.bitrix24:<portal>.unassigned` учитывает только пользователей, которых портал
  показывает уволенными или не сотрудниками (экстранет, e-mail, бот), и это проверяется при каждой синхронизации.
  Работающий сотрудник в списке пропускается с причиной в `issues` синхронизации (`crm.unassigned-dropped`), а его
  сделки и лиды уходят из локальной копии. Руководитель по-прежнему может указать кого угодно. Обратите внимание,
  что без области `user` у вебхука для сотрудника ничьим не считается никто.

## 0.9.0 — 09.11.2026 [#090--09112026]

### Добавлено [#добавлено-3]

- `sync` хранит в локальном хранилище, кто есть кто. Контакт состоит в каждой своей компании с ролью `contact`, и
  рядом стоит его должность. У сделки и лида есть их контакты с отметкой главного, а ответственный за них стоит как
  `owner`. Сотрудники состоят в ваших собственных компаниях, читаются при каждой синхронизации и подчиняются
  руководителю своего отдела. Сконвертированный лид указывает на свою сделку. Эти связи остаются `reported`, пока вы
  их не подтвердите, завершаются, а не удаляются, когда портал перестает о них говорить, и никогда не меняют связь,
  которую создали вы. Обратите внимание, что вебхуку нужны области `user_basic` и `department` для e-mail
  сотрудников и подчинения. Без них синхронизация читает все остальное.
- `schedule` ставит таймер, который сам запускает `sync` или другую команду `b24`. MCP ее не предлагает.
- По умолчанию синхронизация копирует только сделки и лиды собственного пользователя вебхука и пользователей из
  `crm.bitrix24:<portal>.unassigned`. Битрикс24 всегда называет ответственного, поэтому так сделки из формы на
  сайте или из интеграции считаются ничьими. `config set crm.bitrix24:<portal>.scope all` копирует все. В ответе
  синхронизации есть `scope` (с пользователем вебхука как `self`) и `out_of_scope` для каждого вида записей: сделка,
  переданная другому пользователю, уходит из локальной копии при следующей синхронизации. Контакты и компании, как
  и раньше, копируются целиком.
- Если настройки `scope` нет, первый `mine`, который пометил бы удаленными больше половины сохраненных сделок или
  лидов, оставляет их (`crm.narrowing-held`), пока владелец не задаст `scope`. Агент не может задать `scope`, `self`
  или `unassigned`.
- Копия одного портала принадлежит одному пользователю. Синхронизация через вебхук другого пользователя, чем при
  первой синхронизации, отклоняется до `config unset crm.bitrix24:<portal>.self`.

### Изменено — может сломать вызовы [#изменено--может-сломать-вызовы-4]

- В `people` сделки и лида теперь есть ответственный сотрудник с ролью `owner` рядом с ее контактами. Обратите
  внимание на код, который считал каждую запись в `people` контактом клиента.
- `store status` считает ваши собственные компании среди организаций, а сотрудников портала среди людей.
- `api call department.get` и `crm.mycompany.basic.list` выполняются без вопроса, как и другие чтения, которые
  делает `b24`. `department.get` отклоняется при `users.list: deny`, а `crm.mycompany.*` при
  `organizations.list: deny`.
- Вебхук, созданный только с областями `crm` и `user`, теперь получает запись в `issues` при каждой синхронизации:
  Битрикс24 не отдает ему отделы. Добавьте область `department` или будьте готовы к этой записи.
- Первая синхронизация после обновления помечает удаленными в локальной копии сделки и лиды других пользователей.
  Они пропадают из списков и поиска, а их прежняя копия остается в файле хранилища. Чтобы сохранить их, задайте
  `crm.bitrix24:<portal>.scope all` до нее.
- Ответ списка без элементов теперь проваливает синхронизацию этого вида записей (`invalid_response`), а не
  заканчивает на нем список.

### Исправлено [#исправлено-2]

- `api show department.get` и `api call` называли область метода `basic`, а у Битрикс24 это `department`.
- Метод, который Битрикс24 разрешает вызывать только установленному приложению (`WRONG_AUTH_TYPE`), отклоняется как
  `permission_error` с причиной `webhook.app-only`. Раньше `b24` говорил, что вебхук отклонен, и просил войти снова,
  а это не поможет. Обратите внимание на скрипты, которые ветвились по `authentication_error` для этого отказа.
- `create` и `update` для `people` и `organizations` объявляют свои ответы (`crm_record_created`,
  `crm_record_updated`), поэтому `--json` принимает их поля, а `commands info` их перечисляет.
- `session start` и устранение неполадок называют те же области вебхука, что и README: `crm`, `user_basic` и
  `department`. Устранение неполадок еще просило `catalog`, который `b24` не использует.
- `api show`, `api list` и отказ при вызове называли область `basic` для каждого метода вне пяти префиксов имен,
  например `im.message.add` и `tasks.task.add`. Теперь они называют область из справочника Битрикс24 (`im`, `task`,
  `calendar`) или `unknown`, а отказ для неизвестной области не называет никакой.

### Безопасность [#безопасность]

- `b24` отправляет запросы только на портал из адреса вашего вебхука и отклоняет любой другой хост до того, как с
  машины уйдет хоть один байт. Его манифест говорит об этом (`network`), поэтому WireCat Desktop показывает, куда
  уходят данные.

## 0.8.0 — 08.11.2026 [#080--08112026]

### Добавлено [#добавлено-4]

- Пакет поставляет `contracts/wirecat.json`, поэтому WireCat Desktop до установки может прочитать, что делает `b24`,
  как войти и что копирует `sync`. `b24 --wcat-describe` теперь отвечает в формате 2: раздел Desktop из этого файла и
  его SHA-256.

### Исправлено [#исправлено-3]

- Первая синхронизация большого портала занимает гораздо меньше памяти и идет на треть быстрее: на синтетических
  данных с 20 000 сделок пик падает с 3,7 ГБ до 0,55 ГБ.
- `session start` снова спрашивает вебхук, если ничего не пришло. Пустой Enter в скрытом вводе, например после
  Ctrl+V, который ничего не вставил в терминале Linux, сразу заканчивался ошибкой "no webhook address was given".
  Теперь команда подсказывает вставить через Ctrl+Shift+V (Cmd+V на macOS) и спрашивает снова, до трех раз.
- Сбой при запуске `b24` или в ожидаемом шаге завершается с кодом 1 и ошибкой сбоя b24 (`command.crashed` в JSON,
  когда stdout не терминал). Раньше печатался сырой стек Node.

## 0.7.0 — 08.11.2026 [#070--08112026]

### Добавлено [#добавлено-5]

- Пакет ставит команду еще и как `wcat-b24`, поэтому `wcat b24` ее запускает, а `wcat --help` показывает в списке.
  `b24 --wcat-describe` печатает, что это за инструмент, его версию и страницу документации.
- `config set owner_languages` задает языки, на которых читает владелец.

### Изменено — может сломать вызовы [#изменено--может-сломать-вызовы-5]

- Поиск без единой буквы или цифры отклоняется (`validation_error`). `""`, одинокий `?` или один эмодзи ничего не
  находили и ничего не сообщали. Одинокий `*` по-прежнему читается как подстановочный знак.

### Исправлено [#исправлено-4]

- Первая синхронизация большого портала идет примерно вдвое быстрее. Она больше не замедляется с каждой сохраненной
  сделкой: на синтетических данных с 10 ответственными за сделки 20 000 сделок, 10 000 лидов и 20 000 контактов
  синхронизируются за 30 с вместо 61 с.

## 0.6.0 — 08.11.2026 [#060--08112026]

### Добавлено [#добавлено-6]

- `people list --format csv` и `organizations list --format csv` печатают страницу как таблицу CSV для электронной
  таблицы, как теперь и `deals list` с `leads list`. В stdout идет только таблица; путь к следующей странице идет в
  stderr. Столбцы — собственные поля записи, затем каждое пользовательское поле портала по его названию: денежное поле
  как `<label> amount` и `<label> currency`, а два поля с одним названием различаются по коду. `--json=a,b`
  рядом выбирает столбцы, пользовательское поле — как `provider_metadata.<code>`. Ячейка, с которой электронная таблица
  начала бы формулу, получает в начале `'`. `--jsonl`, `--json` без полей и `--compact` отклоняются с
  `output.conflict`, а агентам этот параметр не дается.
- `pipelines show` — доска воронки продаж: для каждой стадии ее сделки или лиды и их сумма в каждой валюте, а в
  терминале — таблица стадий с суммой открытых, числом выигранных и проигранных и долей выигранных. Воронку можно не
  называть, если на портале она одна.

### Изменено — может сломать вызовы [#изменено--может-сломать-вызовы-6]

- Пользовательское поле, которого на портале нет, названное в запросе списка или в `--json`, отклоняется с `param`
  `--query` или `--json`, а не `--field`.
- Команда для профиля без вебхука отклоняется с причиной `session.missing`, а не `webhook.missing`: это единый ответ
  «не выполнен вход», который дает каждый инструмент WireCat с API-токеном. Вебхук читается и хранится там же, где
  раньше: `B24_TOKEN`, затем запись `token:<profile>` в связке ключей под `bitrix24-cli`, затем закрытый файл; теперь
  это делает общее хранилище токенов cli-core.

## 0.5.0 — 07.11.2026 [#050--07112026]

### Добавлено [#добавлено-7]

- `sync` копирует воронки, компании, контакты, сделки и лиды портала в локальное хранилище WireCat: то, что
  изменилось с прошлой синхронизации, или все с `--rescan`; раз в день он также находит, что портал удалил.
  `store status` показывает, насколько продвинулся каждый вид. Синхронизация останавливается до своего срока или
  `--max-pages`, а следующая продолжает с этого места.
- `deals close <ref> won|lost` и `leads close`, на первую стадию успеха или провала воронки записи, а также
  `deals delete` и `leads delete`, которые сначала спрашивают.
- `deals create` и `update` принимают `--pipeline`, `--stage`, `--amount` с `--currency`, `--close-date` и
  `--owner`; лиды принимают то же, кроме `--close-date`. Стадия проверяет ключ перемещения, а стадия успеха или
  провала — еще и ключ закрытия.
- `search all` находит сохраненные сделки и лиды рядом с сообщениями, заметками и событиями других инструментов
  WireCat. При `deals.list: deny` он не берет сделки и называет их в `missing` и в stderr, и так же для лидов; если
  запрещены все виды, о которых его спросили, он отклоняется (`search.all-denied`).
- `b24 --help` и `b24` без аргументов начинаются с того, для чего нужен `b24`, что попробовать первым и с чего начать.

### Изменено — может сломать вызовы [#изменено--может-сломать-вызовы-7]

- `deals`, `leads`, `pipelines` и `stages` — общие CRM-команды cli-core, одинаковые в каждом CRM-инструменте WireCat.
  Их списки и `show` читают локальное хранилище, поэтому сначала запустите `sync`; `--offline` теперь работает для них.
- Сделка или лид называется своим ref, `deal:12` или `lead:7`, как его печатает список, а не id или названием в
  Битрикс24.
- Сделка или лид отвечает `ref`, `pipeline` и `pipeline_name`, `stage` (ее имя), `status` (`open`, `won` или `lost`),
  `close_date`, `amount` как десятичной строкой в `currency`, оба `null`, если суммы нет, `assignee` как
  `<portal>/user/<id>`, а собственными полями портала — в `provider_metadata` по коду. `stage_id`, `pipeline_id`,
  `outcome`, `closes_on`, `assigned_to` и `person_ids` из них убраны; контакты лежат в `people`, компания — в
  `organization`.
- Их запрос списка принимает `status`, `stage`, `pipeline` и `organization`; свободное слово, временные окна и
  собственные поля портала из него убраны. `--all` убран из этих списков.
- `deals move <ref> <stage>` принимает стадию как аргумент, а не как `--stage`.
- У записи сделок и лидов нет `--body`. `--field <label or code>=<value>` задает пользовательское поле по описаниям,
  которые сохранил последний `sync`: поле-список принимает подпись или id своего варианта, поле с несколькими
  значениями — по одному `--field` на значение, а пустое значение его очищает. Код, который называет стандартное поле
  (`stageId`, `categoryId`, `assignedById`, `STATUS_ID` лида), отклоняется, как и `--field` без ключа перед `=`.
- Подпись пользовательского поля и подпись варианта списка сравниваются так, как cli-core сравнивает имена, для
  каждого `--field` и запроса: `е` находит `ё`, а буква, набранная двумя кодовыми точками, находит ту же букву,
  набранную одной. `people show` и `organizations show` так же сравнивают имя с совпадениями портала. Подпись, которая
  совпадала с одним полем, теперь может совпасть с двумя, и тогда она отклоняется с обоими.
- `fields list <deals|leads|people|organizations>` теперь из cli-core: он читает описания, которые сохранил `sync`,
  поэтому сначала запустите `sync`, и каждое поле называет свои части `untrusted`.
- `api.crm.deal.update` (и другие ключи `api.*` сделок и лидов) при `ask` теперь спрашивает и на `deals update`, `move`
  и `close`, а не только на `api call`. `--dry-run` записи сделки или лида называет каждый ключ, который она может
  проверить: ключ `api.*`, а также ключи перемещения, закрытия и `crm.assign-others` с параметром, при котором каждый
  из них применяется.
- `sync` читает описания полей портала для каждого вида, по одному лишнему запросу на вид, поэтому `--max-pages`
  доходит до записей позже. Вебхук без прав на их чтение все равно синхронизируется; любая другая ошибка там
  проваливает синхронизацию.
- Лиды стоят в одной воронке с именем `Leads`, потому что у лидов Битрикс24 воронок нет.
- `deals.delete` и `leads.delete` по умолчанию равны `ask`; `api call`, который задает стадию, проверяет `deals.close`
  (или `leads.close`) вместе с `deals.move`.
- `mcp` и `doctor` — общие команды cli-core: `mcp` добавляет `config`, `add` и `check`, а также `--profiles` и
  `--permission` у `serve`; `doctor` добавляет `--online`.
- `--body` или метод `api call`, которые можно прочитать больше чем одним способом, отклоняются до отправки: тело,
  которое называет одно поле дважды в любом написании, `entityTypeId`, который не простое число, `fields`, который не
  объект, метод с любым суффиксом, кроме одного `.json`, и метод `crm.item` без `entityTypeId`. Отправляйте каждое
  поле один раз, в одном написании.
- `--operation-id` убран из всех записей. На живом портале создание, повторенное с тем же id, создало вторую запись,
  поэтому повтор никогда не безопасен: после `outcome_unknown` выполните `sync` и `show` и повторите запись, только
  если ее там нет. Запись сделки или лида с `--operation-id` отклоняется до отправки.

### Исправлено [#исправлено-5]

- `sync` после первого работает. Он спрашивал портал об изменениях со временем, которое портал отклоняет, поэтому
  каждый вид завершался ошибкой и ничего нового не копировалось. Время в фильтре теперь уходит в целых секундах со
  смещением, и это же исправляет `updated_at:` и `created_at:` в `people list` и `organizations list`.
- Запись, на которую пришел ответ об ошибке сервера или шлюза (500, 502, 504), — это `outcome_unknown`, а не
  `provider_unavailable`: портал мог ее выполнить. Запись, прерванная отменой, — тоже `outcome_unknown`, никогда не
  `cancelled`.
- Стадии читаются страница за страницей: справочник длиннее первых 50 строк REST 2 терял свои последние стадии.
- Id или ответственный, который не является числом, отклоняется до отправки; раньше он уходил пустым.
- `--body` сохраняет целые числа больше 2^53 как введены; `api call --body -` читает тело из stdin.
- Запрос без ответа прерывается через 10 секунд, а не через 30, чтобы чтение можно было повторить до того, как
  истекут собственные 30 с разовой команды.
- `show` для людей и организаций завершается ошибкой, если подписи полей портала не получены по причине, отличной от
  нехватки прав, а не показывает запись без подписей.

### Безопасность [#безопасность-1]

- Проверки прав в `api call` и в записи `people` и `organizations` читают тело ровно в том виде, в каком оно
  отправляется, поэтому проверяют тот ключ, который нужен записи.
- Чтение через `api call` проверяет те же ключи, что и команды, которые читают эти записи, как уже делала его запись.

## 0.4.0 — 06.11.2026 [#040--06112026]

### Добавлено [#добавлено-8]

- `create` и `update` для сделок, лидов, людей и организаций принимают `--field "<label or code>=<value>"`, повторяя
  его для других полей или для каждого значения поля с несколькими значениями. Подпись ищется на портале; два поля с
  такой подписью отклоняются с их кодами. Поле-список принимает подпись или id своего варианта. `--field` важнее
  `--body` для того же поля, а `--title`, `--name`, `--first-name` и `--last-name` важнее обоих. Остальные значения
  уходят на портал как введены. `--dry-run` имена не ищет.
- `list` для сделок, лидов, людей и организаций фильтрует по собственным полям портала: `<code or label>:<value>`,
  для полей, по которым портал умеет фильтровать; поле-список принимает подпись или id своего варианта. Подпись с
  пробелами пишется `lead_source:web` или `Lead\ source:web`.
- `list --json=…,provider_metadata.<code>` добавляет это пользовательское поле к каждому элементу так, как его выдает
  `show`; `--json=…,provider_metadata` добавляет все. Запрашиваются только коды, которые перечисляет портал.
- `fields list <deals|leads|people|organizations>` перечисляет пользовательские поля портала этого вида: код, подпись,
  тип, держит ли поле несколько значений, может ли список по нему фильтровать, а для поля-списка — его варианты с их id.

### Изменено — может сломать вызовы [#изменено--может-сломать-вызовы-8]

- `show` выдает значение поля-списка подписью его варианта, а не id; id переезжает в `option_id` рядом. Поле с
  несколькими вариантами выдает и то, и другое массивами.
- `api call` работает по списку разрешенного. Чтение CRM, каталога и пользователей и запись четырех типов CRM
  разрешены, как и раньше. Любой другой метод спрашивает, поэтому без терминала ему нужен `--yes`, а семейства,
  которые пишут людям, публикуют или отправляют данные наружу, запрещены: `imconnector`, `log.blogpost`, публичные
  ссылки на файлы и `event.bind` присоединяются к `im`, `imopenlines` и остальным. `api show` называет уровень каждого
  метода.

### Исправлено [#исправлено-6]

- `deny` в профиле снова останавливает команду чтения. `b24` передавал cli-core только `resolveSettings`, поэтому
  cli-core никогда не видел таблицу прав b24: `deals.list: deny` не останавливал `deals list`, в том числе через MCP,
  а с любым ключом b24 в настройках каждый `--dry-run` падал с «names no command».
- `api.crm.<type>.add` и `api.crm.<type>.update` теперь действуют на `create`, `update` и `move` у `deals`, `leads`,
  `people` и `organizations`, как ключи команд уже действовали на `api call`. `--dry-run` называет их рядом с
  собственным ключом команды.
- `api call --dry-run` называет каждый ключ, который проверяет вызов, с его уровнем, например `api.crm.deal.delete`
  при `ask`, вместо «no key, allowed».
- `api call crm.item.add|update|delete` с `entityTypeId` от 1 до 4 проверяет ключ команды лида, сделки, контакта или
  компании, как уже делал `crm.deal.update`: `deals.delete: deny` теперь останавливает `crm.item.delete` для сделки.
- Каждый метод, имя которого заканчивается на `delete`, спрашивает, а не только перечисленные. Имя метода заглавными
  буквами или с суффиксом `.json` читается как его простое имя, поэтому больше не обходит ключ.
- Запись, которая задает стадию, проверяет `deals.move` или `leads.move`: `update` и `create` со `stageId` в
  `--body`, в том числе через MCP, и `api call` со `STAGE_ID` или `STATUS_ID` лида. `ASSIGNED_BY_ID` проверяет
  `crm.assign-others`, как и `assignedById`.
- Запись отправляется один раз. Запись REST 3.0, на которую не пришел ответ, отправлялась до трех раз еще с тем же
  `Idempotency-Key`, что на живом портале еще не проверено; теперь она сразу становится `outcome_unknown`, и ее
  сообщение один раз называет `--operation-id`.
- `pipeline_id:0`, воронка по умолчанию, принимается в `deals list` и `stages list`.
- Список разрешенного, как и до него, оставляет отклоненным чтение запрещенных семейств: `crm.activity.list`,
  `im.*`, `tasks.*` и остальные — `deny`, и `api show` так и говорит.
- Сервер MCP применяет таблицу прав b24 (WC-PERM-23): команда, которую профиль запрещает, показывается в поиске
  инструментов как недоступная, а не предлагается как доступная.

## 0.3.0 — 06.11.2026 [#030--06112026]

### Изменено — может сломать вызовы [#изменено--может-сломать-вызовы-9]

- `show` для сделок, лидов, людей и организаций выдает каждому пользовательскому полю его название на портале:
  `provider_metadata` сопоставляет коду поля `{ "label", "value" }`. `label` равен `null`, если у портала нет
  названия для поля или он не отвечает на запрос названий; `show` при этом все равно отвечает.

## 0.2.0 — 06.11.2026 [#020--06112026]

### Исправлено [#исправлено-7]

- Команды, которые обращаются к порталу, теперь выполняются внутри запуска cli-core: `meta.run_id` каждого ответа
  называет запуск, который находит `runs show`, с запросами к порталу в нем, `meta.duration_ms` измеряет команду, а
  `--timeout` останавливает зависшую команду. Переопределения прав агента MCP теперь тоже доходят до этих команд.
- `show` для сделок, лидов, людей и организаций больше не перечисляет пользовательские поля портала без значения:
  `provider_metadata` пропускает `null`, `""` и `[]` и сам пропускается, если ничего не осталось.

## 0.1.0 — 06.11.2026 [#010--06112026]

### Исправлено [#исправлено-8]

- Причина ошибки, которую определяет и более новый cli-core, больше не роняет каждую неудачную команду вместо того,
  чтобы напечатать ее ошибку.

### Добавлено [#добавлено-9]

- Создан из `@wirecat/cli-template` 0.14.0.
- Клиент REST API Битрикс24 через входящий вебхук: REST 3.0 для сделок, лидов, контактов и компаний, REST 2 для
  остального; ограничения частоты портала соблюдаются и выжидаются; запись повторяется только с
  `Idempotency-Key`; секрет вебхука не попадает ни в одну ошибку и запись запуска.
- `session start | status | end` для каждого профиля и `session list`: адрес вебхука читается скрыто или из stdin,
  проверяется на портале и хранится в связке ключей под `bitrix24-cli`; `session status --check` показывает, чьи
  права у вебхука.
- `list` и `show` для `deals`, `leads`, `people` (контакты), `organizations` (компании), `pipelines`, `stages`
  (с исходом каждой стадии), `products` и `users`, напрямую с портала. Список принимает запрос, который становится
  собственным фильтром портала; свободное слово в нем совпадает с частью названия или имени. Имя, общее для двух
  записей, отклоняется, и обе показываются как кандидаты.
- `create` и `update` для `deals`, `leads`, `people` и `organizations`, а также `move` для сделок и лидов: каждая
  запись отвечает своим `operation_id`, который Битрикс24 получает как `Idempotency-Key`, поэтому `--operation-id`
  безопасно повторяет запись; `--dry-run` показывает ее заранее; назначение записи другому сотруднику запрещено, пока
  его не разрешат (`crm.assign-others`).
- `api list`, `api show <method>` и `api call <method> --body <json>`: любой метод Битрикс24, на той версии REST, где
  он находится, с проверкой `api.<method>` и ключа команды, которая делает то же самое; запись сообщений,
  автоматизации, задач и `batch` запрещена, пока ее не разрешат.