# Workflow и источник статуса

Canonical definitions: `planning/tasks.json`; canonical status/owner/history: `state/tasks.json`. Matrices/cards/stages генерируются. Allocation не означает implementation.

## Статусы

`todo → in_progress → review → done`. Rejected review → todo без прежнего owner: продолжает новый executor. Blocker → `blocked` + новая remediation; ни один оператор не исправляет её в прежнем запуске.

## При блокере — для всех ролей

Записать handoff и `state/issues/<ID>-<agent>.json` по шаблону. Вызвать:

```sh
python3 scripts/tasks.py escalate <ID> --agent <id> --role <role> \
  --issue state/issues/<ID>-<agent>.json --handoff state/handoffs/<ID>.md
```

Definitions, dependency edge, state, blocker report и handoff сохраняются через короткий lock и recovery journal. Agent id retired; текущий запуск заканчивается. CLI печатает resolution_task и agent_must_exit. Reporter больше не claim/submit/approve другой task.

Resolver имеет свой оператор, reviewer, outcome, paths, steps/checks; он зависит только от доступных prerequisites, не от исходного blocked parent. Проверяется DAG. После reviewed done resolver оригинал автоматически возвращается в todo/review для нового процесса. Bare block/unblock запрещены; нельзя снять tracked blocker обходной командой.

External resolver остаётся blocked без owner, `external_wait=true`. После явного решения координатор вызывает `release-external`; resolver попадает в todo и требует обычного review, не становится done сразу.

## Успешный цикл

```sh
python3 scripts/tasks.py next --role front
python3 scripts/tasks.py list --role crypto --stage S12 --status todo --query OMEMO --limit 10
python3 scripts/tasks.py claim <ID> --agent <id> --role <role>
python3 scripts/tasks.py packet <ID> --agent <id> --output state/context-<ID>.md
python3 scripts/tasks.py submit <ID> --agent <id> --evidence state/evidence/<file>.md --handoff state/handoffs/<ID>.md
python3 scripts/tasks.py approve <ID> --agent <new-reviewer> --role <reviewer-role> --evidence state/evidence/<review>.md
python3 scripts/tasks.py reject <ID> --agent <new-reviewer> --role <reviewer-role> --reason 'Точное замечание'
```

После submit/approve/reject запуск тоже заканчивается. Автоматический runner сам выбирает следующий task/role, создаёт fresh agent id и передаёт master prompt. Подробности: `docs/AUTOMATION.md`.

До submit/approve/reject агент записывает осмысленное сообщение commit по `docs/GIT_WORKFLOW.md`. Runner после проверки scope фиксирует реализацию/review отдельными commits с ID задачи, actual changes и checks. Следующий процесс запускается только после успешного commit. Blocker тоже сохраняется явно незавершённым checkpoint; при нарушении scope или ошибке Git очередь останавливается без сброса изменений.

## Scope и роли

Scope текущей карточки одинаково обязателен для front/backend/protocol/crypto/storage/media/realtime/security/qa/ci-cd/docs/orchestrator и reviewer. Shared interface вне scope — отдельная remediation, не импровизация. Единственное служебное исключение — task metadata/evidence/handoff через инструмент.

У owner максимум одна незавершённая задача. История предыдущего владельца сохраняется. `reassign` предназначен только для согласованного восстановления обычного in_progress, не позволяет вернуть retired reporter или обойти tracked blocked state. Review role проверяется, но идентичность человека инструмент не аутентифицирует.

## Lock, транзакции и восстановление

`.state.lock` удерживается только при mutation. `state/plan-transaction.json` — write-ahead recovery journal для добавления blocker task вместе со state. После сбоя следующий доступ автоматически доводит одну записанную транзакцию до согласованного состояния. Journal нельзя стирать ради обхода проверки.

Если остался `.state.lock`, проверить `.state.lock/owner.json` и процесс. `unlock --reason ...` на POSIX снимает только lock доказанно завершённого PID; на других ОС проверка системными средствами. Не удалять lock живого процесса.

State и rendered matrices имеют разные lifecycle; revision показывает устаревание. После updates — render. При render failure state/definitions/journal остаются источниками истины; новый запуск восстанавливает artifacts.

Не запускать два coordinator в одном checkout, не редактировать исходники одновременно вручную. Source scope audit не является OS sandbox. Git worktrees сами не синхронизируют status; каждому общему проекту нужен один согласованный coordinator.

## Изменение плана и evidence

Плановые изменения вне blocker создаются отдельным bounded task/ADR, не расширяют scope исполняющего агента. Новый ID не переиспользуется. После согласованного изменения definitions — sync/validate/render; удаление task history запрещено. Immutable specs не меняются из-за blocker.

Evidence/handoff paths остаются внутри своих директорий без symlink наружу. Реальный непустой файл не доказывает истинность текста: отдельный reviewer повторяет нужные checks. Недоступный live result не считается passed. Secrets не пишутся в reports/prompts/logs.