Используйте changelog как публичный журнал контрактных изменений, а не как маркетинговую витрину релизов.
Публичные изменения surface должны быть видны до того, как станут support ticket
Раздел
Модель changelog
Каждая запись должна быть полезна интегратору: что изменилось, насколько это обратно совместимо и что нужно сделать дальше.
- Дата, scope, затронутые страницы, backward compatibility, обязательное действие оператора.
- Ссылка на replacement examples, когда контракт становится строже.
- Явное разделение на additive, breaking и operational изменения без смешивания этих режимов.
Диаграмма
Как читать changelog
Запись должна сразу отвечать на три вопроса: что изменилось, кому это важно и требуется ли действие.
date and scope
surface changed
compatibility impact
required operator action
links to reference and examples
Раздел
Правила версионирования
- Additive changes публикуются сразу с указанием новых полей, filters, tools или resources.
- Breaking changes должны заранее ссылаться на replacement flow, срок вывода старого поведения и минимальный migration path.
- Operational notes фиксируют rollout-ограничения, возможные временные расхождения и безопасный способ проверки после релиза.
Не прячьте breaking change в обзоре страницы
Если изменение может сломать клиент, оно должно жить в changelog как отдельная запись с явным action item, а не растворяться в обновлённом описании reference-страницы.
Раздел
Governance и source of truth
- Изменения в public docs должны синхронизироваться с README MCP server, External API markdown и OpenAPI spec.
- При изменении публичного контракта сначала обновляется source of truth, затем reference, examples и changelog entry.
- Если контрактный smoke или verification test меняется, changelog должен ссылаться на новый ожидаемый flow проверки.
Раздел
Последние публичные изменения
Type: additive
Surface: External API, MCP tools, public docs
Compatibility: backward compatible
Change: добавлены create_project, create_task и move_task_to_final_stage для полного IDE-driven flow от создания проекта/задачи до финального Kanban Done stage.
Operator action: используйте 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-ам TaskTracker External API, filters, pagination и типовым шаблонам запросов.
Справочник MCP tools
Справочник по TaskTracker MCP tools: discovery, lifecycle work packet, progress, artifact, handoff, recovery и convergence.
Примеры
Примеры запросов для TaskTracker MCP и External API: ready discovery, claim, progress, artifact и handoff.
Ошибки и troubleshooting
Типовые ошибки TaskTracker MCP и API: проблемы auth, отказы доступа, stale context и packet authorization denial.
Коротко по странице
О чем эта страница
Changelog по API и MCP
Модель changelog для публичных docs TaskTracker: эволюция API, изменения MCP surface и contract-safe заметки по rollout.
FAQ
С чего начать?
Начните с главной страницы docs, если сравниваете поверхности, с MCP quickstart - если подключаете agent runtime, или с API quickstart - если нужен первый curl-запрос.
В чём ключевое отличие TaskTracker?
TaskTracker не считает agent execution набором свободных комментариев к задаче. Он моделирует исполнение через 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 и генерации клиентов.
Читайте дальше