workflow

The full skill.

Original instructions from the publisher’s SKILL.md

# Workflow

## Режим и трекер — независимые решения

- **report-only** — только ответ или явно запрошенный report artifact; без Task Master, `.taskmaster/`, product/config/data writes.
- **track-only** — только явно разрешённые task metadata; не разрешает implementation.
- **remediation** — изменения в пределах запроса пользователя.

По умолчанию **session-first**: план, scope, прогресс и evidence остаются в текущей сессии. Нетривиальная задача не требует установки трекера, MCP, API-ключей или runtime. Наличие `.taskmaster/`, подключённого MCP или команды `/vorcl` не означает согласие использовать Task Master. Другой выбранный трекер используй через его доступные инструменты и границы текущей цели, не мигрируй backlog.

## Session-first цикл

1. Зафиксируй цель, владельца scope, ограничения, acceptance criteria и `testStrategy`.
2. Разбей работу на ограниченные шаги в сессии. Оркестратор распределяет независимые scopes; не выдавай один изменяемый scope двум исполнителям одновременно.
3. Executor реализует разрешённый scope и передаёт changed paths, проверки и ограничения.
4. Независимый Checker выполняет `testStrategy`, не меняет implementation и acceptance tests, возвращает `ГОТОВО`/`НЕ ГОТОВО` с evidence. Если отдельный контекст недоступен, честно укажи ограничение проверки; не имитируй независимого Checker.
5. Только Orchestrator завершает шаг после проверки и останавливается по текущей цели. Работа не требует файлового task-state.

## Контекст и доказательства

Для нетривиальной передачи работы используй [краткий handoff](references/handoff.md): цель, границы, проверяемые критерии, relevant paths и ограничения. Загружай тело только выбранной роли и нужные references по мере работы; каталог навыков не является списком обязательных чтений. Executor с ограниченным scope продолжает выданную задачу, а не запускает весь orchestration заново.

Свяжи каждый критерий с наблюдаемым результатом и способом проверки. Checker сначала независимо сопоставляет actual diff с критериями (пропуски, противоречия, лишние изменения), затем проверяет качество и регрессии в затронутом scope. Отчёт Executor — указатель на evidence, не доказательство успешности. Для каждой проверки различай `PASS`, `FAIL`, `NOT_RUN`; отсутствие инструмента или доступа не считается PASS.

Масштаб проверки соответствует риску: простой обратимый edit не требует новой тестовой инфраструктуры. Не повторяй весь suite без новых изменений, сбоев или нерешённых рисков. Handoff и acceptance labels остаются в сессии; сами по себе они не разрешают создание task/report файлов, вызов Task Master или дополнительные пользовательские approval checkpoints.

## Task Master: только по явному выбору

Этот адаптер включается только если пользователь явно выбрал Task Master для текущей работы. Сначала прочитай **task-master** и обнаружь реальные capabilities текущей сессии; имена MCP-серверов и tools не фиксированы. Без доступного адаптера продолжай независимую работу session-first и сообщи, что persistence недоступна. Не устанавливай сервер, не запускай init и не меняй providers/models/ключи автоматически.

1. Создай задачи через доступные операции `add_task`/`parse_prd` и сохрани IDs из результата записи. Не импортируй чужие задачи и не перезаписывай существующий PRD. Bare `next_task` по общему backlog запрещён.
2. Создай scoped run: `node <plugin-root>/scripts/vorcl-run.mjs create --run <run-id> --tasks <id,id> --owner <agent> --root <project>`. В standalone skill используй `<workflow-skill>/scripts/vorcl-run.mjs`. AVF хранит claims/runs в `.agent-vorcl/`, никогда в `.taskmaster/`.
3. Для каждого allowlisted ID: atomic `claim --run <run-id> --task <id>` → чтение задачи → проверка статуса → `in-progress`. Продлевай lease через `renew`; `reclaim --from-run <expected-old-run>` и `unlock --expected-lock <id>` требуют ожидаемого владельца/lock. Не обходи отказ claim.
4. Executor работает только над claimed task; `update_subtask` — только для существующего subtask ID, не top-level task. Не редактируй Task Master JSON вручную.
5. Checker возвращает независимый verdict по `testStrategy`; только Orchestrator записывает `done`. Цикл ограничен allowlist run, не repository backlog.

## PROJECT_DESCRIPTION maintenance

Это общий Definition of Done для любой изменяющей роли.

1. До реализации проверь `<scope-root>/PROJECT_DESCRIPTION.md`. Если файл существует, прочитай его до изменения кода; если отсутствует — не создавай автоматически.
2. После реализации перед Checker собери только changed paths текущей задачи и запусти, если доступен:

   ```bash
   node <init-code-skill>/scripts/check-impact.mjs --root <scope-root> --changed <path> [--changed <path> ...] [--external <kind[:detail]> ...]
   ```

3. Передавай `--external` для выполненных вне worktree мутаций (`render-deploy`, `environment`, `integration`, `database-schema`, `runtime`), даже если changed paths пусты. При `review-required` сравни файловый diff и external mutations с утверждениями документа. Material impact есть, когда изменились назначение/возможности, команды запуска/build/test, стек/runtime, packages/modules/boundaries/entrypoints/routes, data flow/schema, integrations, env names, testing/CI/deploy context.
4. Если material impact подтверждён, в той же задаче обнови только затронутые разделы `PROJECT_DESCRIPTION.md`, сохрани корректные пользовательские пояснения, замени stale evidence paths и запусти `validate-description.mjs` из `$init-code`.
5. Если material impact отсутствует, документ не редактируй; передай Checker краткое evidence-based объяснение `description impact: none`.
6. Изменение контекста при оставшемся stale `PROJECT_DESCRIPTION.md` означает **НЕ ГОТОВО**. Report-only роли и Checker сами этот файл не исправляют.

Роли для маршрутизации: `architect`, `principal-architect`, `backend`, `frontend`, `expo-mobile`, `analyzer`, `integrity`, `swagger`, `firecrawl`, `render`, `database`, `resilience`, `logging`, `screenshot`, `design-studio`, `visual-research`, `pinpoint`, `drawio`, `archmap`, `mermaid`, `testing`, `gitflow`, `security`, `docs`, `devops`, `liveboard`. Канонические ownership/negative criteria находятся в `scripts/roles.json`.

## Запреты

- Не изменять MCP configuration, providers, модели или секреты ради обычного workflow.
- Не создавать Task Master state без явного выбора; report-only не пишет task/product state.
- В Task Master режиме не брать чужие IDs и не работать без успешного atomic claim перед `in-progress`.
- Не закрывать задачу без доказательств проверки и не скрывать отсутствие независимого Checker.
- Не закрывать modifying task с подтверждённым дрейфом существующего `PROJECT_DESCRIPTION.md`.