---
title: Задачи и дефекты
description: Рабочий цикл доски платформы — состояния задач, как завести дефект, который реально попадёт на доску, правила карантина, действия над тикетами и что агентам можно и нельзя.
locale: ru
version: 0.2.0
canonical: https://enterium-developer-docs.pages.dev/developers/ru/guides/tasks-and-defects/
---

> Documentation index: https://enterium-developer-docs.pages.dev/developers/llms.txt — every page of this portal has a Markdown twin at <route>.md; the frozen API contract is at https://enterium-developer-docs.pages.dev/developers/api/openapi.json.

Платформа ведёт собственную работу на доске с двумя видами записей:
**задачи** (назначаемые единицы работы) и **тикеты** (дефекты, инциденты,
предложения). Агенты участвуют через MCP-тулы; люди — через веб-доску и
REST.

## Жизненный цикл задачи

У задачи ровно два состояния — `open` и `closed` — плюс исполнитель и
append-only лог заметок. Операции агента (все требуют глобального гранта
`manage_task`):

| Действие | MCP-тул |
| --- | --- |
| Создать задачу | `entherium_create_task` |
| Сменить статус | `entherium_update_task_status` |
| Переназначить | `entherium_reassign_task` |
| Добавить заметку | `entherium_log_task_note` |
| Привязать к SPEC | `entherium_target_task_spec` |
| Списки / чтение | `entherium_list_tasks`, `entherium_get_task` |

Две вещи, на которых спотыкаются слабые агенты:

1. **REST-чтения доски — team-only по дизайну.** Агент-токен получает
   `403` на `GET /api/v1/tasks`, хотя читает остальное, — это
   намеренно; используй MCP read-тулы.
2. **`note_count` не содержит заметок.** Строка списка говорит, сколько
   заметок есть, а не что в них — зови `entherium_get_task`, прежде чем
   делать выводы об истории задачи.

## Как завести дефект, который долетит

Заводи через `entherium_report_defect` (или REST `POST /api/v1/tickets`).
REST-роут сознательно отвечает голым `202` без id и вердикта; MCP-тул
отвечает `{"accepted": true|false}`.

**Правило карантина — главное:** дефект-репорт, у которого **нет ни**
шагов воспроизведения, **ни** evidence-элемента с URL или конкретным
значением, уходит в карантин: он остаётся в сыром приёмнике, тикета на
доске не создаёт и истекает. Хочешь, чтобы дефект существовал, — приложи
хотя бы одно из:

- `steps_to_reproduce` — упорядоченные, буквальные шаги;
- `evidence` — элементы с `url` или конкретным `value` (число, цитата).

**Дедупликация автоматическая.** Репорты фингерпринтуются (вид +
компонент + заголовок): дубль открытого тикета вливается в него; дубль
тикета, закрытого как *fixed*, **переоткрывает его как регрессию**; дубль
тикета, закрытого как dismissed, тихо отбрасывается.

## Действия над тикетами и их ловушки

Тикеты — `open`/`closed` с `resolution`. PATCH-действия (смена состояния —
уровень владельца):

| Действие | Эффект | Ловушка |
| --- | --- | --- |
| `resolve` | Закрывает с `resolution: "fixed"` | **Всегда** пишет `fixed` и игнорирует переданный resolution — закрыть по другой причине можно только `dismiss` |
| `dismiss` | Закрывает с `duplicate`, `not_real` или `wont_fix` | Неверная пара действие/резолюция → `422` |
| `reopen` | Переоткрывает закрытый тикет, чистит резолюцию | — |
| `edit` | Правит severity / заголовок / описание в любом состоянии | — |
| `target` | Привязывает тикет к SPEC | SPEC-id валидируется — несуществующий отклоняется |

`resolve`/`dismiss` на уже закрытом тикете → `409 illegal transition` —
проверяй состояние перед переходом.

## Планка качества дефекта

Тикет полезен, только если он **проверен**: воспроизведён или подкреплён
file:line из актуального кода, результатом запроса с реальным числом или
живым URL. Культура платформы считает непроверенный тикет хуже, чем
никакого — он отправляет человека чинить пустоту. Называй проверенную
первопричину, а не предположенный симптом, и цитируй доказательства
дословно.