Покрытие документации100% готово
Модель исполнения
Готово

Это главная концептуальная страница, если нужно понять, чем TaskTracker отличается от обычных task API.

TaskTracker рассматривает исполнение как контролируемый workflow, а не как поток разрозненных комментариев

Задачи остаются delivery-контейнерами; work packet - это единицы исполнения, которые агент и оператор реально берут в claim и двигают дальше.
Suggested packet, committed ready packet, claimed packet, artifact и handoff packet намеренно существуют как разные объекты.
Convergence нужна, чтобы задача не уходила в review без интегрированного verification evidence.

Раздел

IDE -> MCP flow для создания и исполнения задачи

  • 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-driven execution path

Этот flow отделяет создание карточки, контрактную декомпозицию, operational execution и финальное перемещение карточки по доске.

1

create_project

2

create_task

3

enrich_existing_task

4

propose_work_packets

5

create_work_packets_from_plan

6

approve + claim

7

develop + artifacts

8

convergence + Done stage

Раздел

Состояния жизненного цикла

  • proposal: reviewable suggestion, а не committed work
  • draft или triage: packet ещё не готов к admission в queue
  • ready: execution contract достаточно полный, чтобы packet можно было брать в claim
  • claimed и in_progress: lease активен, а текущий executor владеет mutation lane
  • handoff_pending или recovery: packet ещё нельзя считать завершённым успешным путём

Диаграмма

Жизненный цикл work packet

Packet двигается по контролируемым состояниям с явным proof bundle и понятным recovery path.

1

proposal

2

draft/triage

3

ready

4

claimed

5

in_progress

6

artifact/progress

7

handoff/recovery

8

convergence/done

Раздел

Ожидаемый proof bundle

  • Комментарий прогресса объясняет, что изменилось и что ещё заблокировано.
  • Artifact фиксирует конкретный результат: patch, logs или report.
  • Структурированный handoff packet несёт summary, open questions, known risks, commands run и next owner role.
  • Convergence gate решает, достаточно ли у задачи интегрированного evidence для перехода в review.

Раздел

Почему это важно коммерчески

  • Это уменьшает невидимую agent-работу и делает human supervision понятной.
  • Это улучшает postmortem, потому что recovery lineage выражена явно.
  • Это даёт техническому заказчику уверенность, что автоматизация управляемая, а не декоративная.

Не моделируйте это как обычные комментарии к задаче

Если игнорировать work packet и использовать TaskTracker как плоский task API, вы теряете execution guarantees, которые и отличают продукт.

Следующие материалы

Связанные страницы

Коротко по странице

О чем эта страница

TaskTracker MCP

TaskTracker MCP - это stdio bridge, который отдаёт discovery, исполнение work packet, resources и prompts в supervised agent runtime, сохраняя backend scope и семантику отказов.

FAQ

Когда выбирать MCP вместо REST API?

Выбирайте MCP, когда вызывающая сторона - агент или supervised runtime, которому нужны tools, resources, prompts и workflow-safe мутации packet. REST нужен, когда достаточно прямого HTTP-контракта.

Почему TaskTracker MCP требует 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 и генерации клиентов.

Читайте дальше