Используйте changelog как публичный журнал контрактных изменений, а не как маркетинговую витрину релизов.
Публичные изменения поверхности должны быть видны до того, как превратятся в тикеты поддержки
Раздел
Модель changelog
Каждая запись должна быть полезна интегратору: что изменилось, насколько это обратно совместимо и что нужно сделать дальше.
- Дата, область изменения, затронутые страницы, обратная совместимость, обязательное действие оператора.
- Ссылка на replacement examples, когда контракт становится строже.
- Явно разделяйте additive, breaking и operational изменения — не смешивайте режимы в одной записи.
Диаграмма
Как читать changelog
Запись должна сразу отвечать на три вопроса: что изменилось, кому это важно и требуется ли действие.
дата и scope
затронутая поверхность
влияние на совместимость
действие оператора
ссылки на reference и примеры
Раздел
Правила версионирования
- Аддитивные изменения публикуйте сразу: новые поля, filters, tools или resources.
- Breaking changes заранее ссылаются на replacement flow, срок вывода старого поведения и минимальный migration path.
- Operational notes фиксируют ограничения rollout, возможные временные расхождения и безопасный способ проверки после релиза.
Не прячьте breaking change в обзоре страницы
Если изменение может сломать клиент, оно должно жить в changelog как отдельная запись с явным action item, а не растворяться в обновлённом описании reference-страницы.
Раздел
Управление и источник правды
- Изменения в публичных docs синхронизируйте с README MCP-сервера, External API markdown и OpenAPI spec.
- При изменении публичного контракта сначала обновляйте источник правды, затем reference, examples и запись changelog.
- Если меняется контрактный smoke или verification test, changelog должен ссылаться на новый ожидаемый сценарий проверки.
Раздел
Последние публичные изменения
Тип: additive
Поверхность: External API, MCP tools, public docs
Совместимость: обратно совместимо
Изменение: добавлены create_project, create_task и move_task_to_final_stage для полного IDE-driven flow от создания проекта/задачи до финальной стадии Kanban Done.
Действие оператора: используйте enrich_existing_task/propose_work_packets для reviewable декомпозиции, затем create_work_packets_from_plan, approve_packet_ready, claim_work_packet, evidence/convergence и move_task_to_final_stage после завершения.Следующие материалы
Связанные страницы
Справочник API
Справочник по endpoint-ам Treker Zadachek External API, filters, pagination и типовым шаблонам запросов.
Справочник MCP tools
Справочник MCP tools Treker Zadachek: discovery, жизненный цикл work packet, progress, artifact, handoff, recovery и convergence.
Примеры
Примеры запросов для Treker Zadachek MCP и External API: ready discovery, claim, progress, artifact и handoff.
Ошибки и troubleshooting
Типовые ошибки Treker Zadachek MCP и API: проблемы auth, отказы доступа, stale context и packet authorization denial.
Коротко
О чём эта страница
Changelog по API и MCP
Модель changelog для публичных docs Treker Zadachek: эволюция API, изменения MCP surface и contract-safe заметки по rollout.
FAQ
С чего начать?
Начните с главной страницы docs, если сравниваете поверхности, с MCP quickstart - если подключаете agent runtime, или с API quickstart - если нужен первый curl-запрос.
В чём ключевое отличие Treker Zadachek?
Treker Zadachek не сводит работу агента к свободным комментариям. Исполнение моделируется через work packet, lease, artifact, handoff и convergence.
Источники
README MCP server
mcp-server/README.md
Главное публичное описание MCP-контракта и ожиданий к оператору.
Обзор External API
docs/api/external-statistics-api-overview.md
Высокоуровневая рамка API и модель аутентификации.
Reference External API
docs/api/external-statistics-api.md
Семейства HTTP endpoint-ов, filters, shape ответа и примеры.
Контракт OpenAPI
docs/openapi/external-statistics-v1.yaml
Machine-readable reference для tooling и генерации клиентов.
Читать дальше