Это главная концептуальная страница, если нужно понять, чем Treker Zadachek отличается от обычных task API.
Treker Zadachek моделирует исполнение как контролируемый workflow, а не как поток комментариев
Раздел
Поток IDE → MCP: создание и исполнение задачи
- create_project создаёт проект, default board и стадии To Do, In Progress, Done; для selected_projects новый проект сразу привязывается к текущему external API key.
- create_task создаёт карточку с кратким описанием; если boardId/stageId не переданы, backend выбирает первый board и первую stage проекта.
- enrich_existing_task должен вести декомпозицию через propose_work_packets, чтобы результат был reviewable proposal, а не скрытая operational mutation.
- После review используйте create_work_packets_from_plan, approve_packet_ready, list_ready_packets и claim_work_packet для запуска разработки по work packets.
- После evidence, convergence и workflow status используйте move_task_to_final_stage, чтобы карточка оказалась в Kanban Done/final stage.
Диаграмма
Путь исполнения из IDE
Этот поток отделяет создание карточки, контрактную декомпозицию, operational execution и финальное перемещение карточки по доске.
create_project
create_task
enrich_existing_task
propose_work_packets
create_work_packets_from_plan
approve + claim
develop + artifacts
convergence + Done stage
Раздел
Состояния жизненного цикла
- proposal: предложение на review, а не уже committed work
- draft или triage: пакет ещё не готов к admission в queue
- ready: execution contract достаточно полный, чтобы пакет можно было брать в claim
- claimed и in_progress: lease активен, текущий executor владеет mutation lane
- handoff_pending или recovery: пакет ещё нельзя считать успешно завершённым
Диаграмма
Жизненный цикл work packet
Packet двигается по контролируемым состояниям с явным proof bundle и понятным recovery path.
proposal
draft/triage
ready
claimed
in_progress
artifact/progress
handoff/recovery
convergence/done
Раздел
Ожидаемый proof bundle
- Комментарий прогресса объясняет, что изменилось и что ещё заблокировано.
- Artifact фиксирует конкретный результат: patch, logs или report.
- Перед release reason=completed нужен delivery proof: git-diff-summary (baseCommit/headCommit/filesChanged) или validated handoff; path-like expectedArtifacts должны быть покрыты filesChanged (DELIVERY_COVERAGE_GAP).
- Структурированный handoff packet несёт summary, open questions, known risks, commands run и next owner role.
- Convergence gate решает, достаточно ли у задачи интегрированного evidence для перехода в review.
Раздел
Почему это важно коммерчески
- Это уменьшает невидимую agent-работу и делает human supervision понятной.
- Это улучшает postmortem, потому что recovery lineage выражена явно.
- Это даёт техническому заказчику уверенность, что автоматизация управляемая, а не декоративная.
Не моделируйте это как обычные комментарии к задаче
Если игнорировать work packet и использовать Treker Zadachek как плоский task API, вы теряете execution guarantees, которые и отличают продукт.
Следующие материалы
Связанные страницы
Справочник 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.
Безопасность и модель доступа
Модель безопасности Treker Zadachek MCP и External API: project scope, работа с API key, token redaction и безопасное поведение оператора.
Ошибки и troubleshooting
Типовые ошибки Treker Zadachek MCP и API: проблемы auth, отказы доступа, stale context и packet authorization denial.
Коротко
О чём эта страница
MCP Treker Zadachek
MCP Treker Zadachek — stdio-мост: отдаёт discovery, исполнение work packet, resources и prompts в supervised runtime агента, сохраняя backend scope и семантику отказов.
FAQ
Когда выбирать MCP вместо REST API?
Выбирайте MCP, когда вызывающая сторона - агент или supervised runtime, которому нужны tools, resources, prompts и workflow-safe мутации packet. REST нужен, когда достаточно прямого HTTP-контракта.
Почему MCP Treker Zadachek требует revision и context token?
Эти CAS-поля предотвращают stale write, делают retry явным и держат исполнение packet согласованным с последним состоянием backend.
Источники
README MCP server
mcp-server/README.md
Главное публичное описание MCP-контракта и ожиданий к оператору.
Контракт OpenAPI
docs/openapi/external-statistics-v1.yaml
Machine-readable reference для tooling и генерации клиентов.
Читать дальше