Tasks

/polisade:tasks [PLAN-XXX | SPEC-XXX | FEAT-XXX | BUG-XXX | DEBT-XXX | CHORE-XXX] — Создание задач через субагент

Создание атомарных задач из плана, спецификации, Feature Brief, Bug Report, Tech Debt или Chore через изолированный субагент.

Использование

/polisade:tasks PLAN-001   # Задачи из детального плана (итерация по items)
/polisade:tasks SPEC-001   # Задачи из спецификации
/polisade:tasks FEAT-001   # Задачи напрямую из фичи (для простых случаев)
/polisade:tasks BUG-001    # Задача из бага (обычно 1 TASK)
/polisade:tasks DEBT-001   # Задачи из техдолга (обычно 1-3 TASK)
/polisade:tasks CHORE-001  # Задача из chore (обычно 1 TASK)
/polisade:tasks            # Выбрать из доступных ready артефактов

Когда что использовать

Источник	Когда использовать	Типичное кол-во TASKs
PLAN	Крупная инициатива с фазами и зависимостями	5-20
SPEC	Техническая работа, требующая архитектуры	3-10
FEAT	Простая фича, понятная из описания	2-5
BUG	Багфикс с конкретным воспроизведением	1 (реже 2-3)
DEBT	Рефакторинг, обычно ленивая декомпозиция после регистрации	1-3
CHORE	Простая задача, когда --no-task использовался при регистрации	1

Архитектура с субагентом

Для PLAN (итерация по roadmap items)

┌─────────────────────────────────────────────────────────────┐
│  PM: /polisade:tasks PLAN-001                                   │
└─────────────────────────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  ОСНОВНОЙ АГЕНТ                                             │
│  1. Валидация: PLAN со статусом ready                       │
│  2. Читает PLAN + SPEC + PRD                                │
│  3. Извлекает список roadmap items                          │
│  4. Запускает субагенты для ВСЕХ items (параллельно)        │
└─────────────────────────────────────────────────────────────┘
                        │
            ┌───────────┼───────────┐
            ▼           ▼           ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│  СУБАГЕНТ     │ │  СУБАГЕНТ     │ │  СУБАГЕНТ     │
│  Item MVP-1.1 │ │  Item MVP-1.2 │ │  Item MVP-2.1 │
│  → 3 TASKs    │ │  → 2 TASKs    │ │  → 4 TASKs    │
└───────────────┘ └───────────────┘ └───────────────┘
            │           │           │
            └───────────┼───────────┘
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  ОСНОВНОЙ АГЕНТ                                             │
│  1. Собирает ВСЕ TASK в память (НЕ сохраняет файлы)        │
│  2. Consolidated PM Checkpoint (один на весь PLAN)          │
│  3. После подтверждения — сохраняет файлы                   │
│  4. Обновляет PROJECT_STATE.json                            │
│  5. Обновляет counters.json                                 │
└─────────────────────────────────────────────────────────────┘

Для SPEC/FEAT/BUG/DEBT/CHORE (один субагент)

┌─────────────────────────────────────────────────────────────┐
│  PM: /polisade:tasks SPEC-001 / FEAT-001 / BUG-001 /            │
│                  DEBT-001 / CHORE-001                       │
└─────────────────────────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  ОСНОВНОЙ АГЕНТ                                             │
│  1. Валидация: SPEC/FEAT/BUG/DEBT/CHORE со статусом ready   │
│  2. Читает документ + knowledge.json                        │
│  3. Запускает субагент для декомпозиции                     │
└─────────────────────────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  СУБАГЕНТ general-purpose (чистый контекст)                 │
│                                                             │
│  System role: Task Planner                                  │
│  Input: SPEC/FEAT/BUG/DEBT/CHORE + project context          │
│                                                             │
│  Делает:                                                    │
│  1. Анализирует требования                                  │
│  2. Читает затронутые файлы кода                            │
│  3. Декомпозирует в атомарные задачи                        │
│  4. Определяет зависимости                                  │
│  5. Проводит self-review постановки                         │
│  6. Возвращает: список TASKs                                │
└─────────────────────────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  ОСНОВНОЙ АГЕНТ                                             │
│  1. Собирает ВСЕ TASK в память (НЕ сохраняет файлы)        │
│  2. Consolidated PM Checkpoint если > 3 задач               │
│  3. После подтверждения — сохраняет файлы                   │
│  4. Обновляет PROJECT_STATE.json                            │
│  5. Обновляет counters.json                                 │
└─────────────────────────────────────────────────────────────┘

Алгоритм работы основного агента

⚙️ Выбор режима (первым делом). Если settings.experimental.changeSpec == true и source — change-spec (kind: change-spec), работаешь в Coordinate-task mode (см. одноимённую секцию ниже: координаты из §3 локализации, impact-ансамбль на графе, строгий линт). Иначе — обычная декомпозиция ниже.

1. Валидация

1. Прочитай .state/PROJECT_STATE.json
2. Найди PLAN, SPEC, FEAT, BUG, DEBT или CHORE со статусом ready
3. Если указан ID — проверь что он ready
4. Если не указан:
   • Покажи список всех ready артефактов (PLAN, SPEC, FEAT, BUG, DEBT, CHORE)
   • Спроси какой использовать
   • Если нет ready → предложи альтернативы

Нет готовых артефактов для создания задач.

Доступные действия:
   → /polisade:feature для добавления фичи
   → /polisade:defect для репорта бага
   → /polisade:spec для создания спецификации
   → /polisade:state для обзора проекта

2. Подготовка контекста

Прочитай и собери:

1. Исходный документ (PLAN, SPEC, FEAT, BUG, DEBT или CHORE)
2. Связанные документы:
   • Для PLAN: SPEC + PRD
   • Для SPEC: PRD (если есть parent)
   • Для FEAT: ничего дополнительно
   • Для BUG: ничего дополнительно (баг самодостаточен)
   • Для DEBT: ничего дополнительно (техдолг самодостаточен, parent SPEC отсутствует)
   • Для CHORE: ничего дополнительно (chore самодостаточен, parent SPEC отсутствует)
3. Design package (опционально): если SPEC имеет ребёнка типа DESIGN-PKG, прочитай README.md package'а и (если есть) api.md — это OpenAPI контракт. Передай как дополнительный контекст в субагент: точные endpoints/schemas помогают создавать корректные TASKs (правильные routes, request/response shapes, error codes). Если у DESIGN-PKG статус draft/waiting_pm — выведи предупреждение PM, но не блокируй.
4. Out of scope и Constraints (из source SPEC, если source — SPEC или PLAN→SPEC):
   • Извлеки Out of scope из секции назначения/области (ISO-29148 — §1 «Purpose & Scope»; change-spec — §1 «Что и зачем»)
   • Извлеки Constraints (C-N) и Dependencies (D-N) — адресуй по имени секции, не по номеру (#233):
     • source без kind (legacy ISO-29148) → §4 «Assumptions, Constraints, Dependencies»
     • source kind: change-spec → C-N/D-N в этом формате нет. Вместо них технологические рамки несёт §4 «Контракты» (Operations / Data / Events). Не выдумывай C-N/D-N, которых в источнике не существует
   • Передай в субагент: out-of-scope items определяют что НЕ должно стать TASK; constraints определяют технологические рамки для implementation steps
   • Если source — FEAT/BUG/DEBT/CHORE без SPEC в chain: "N/A"
5. System boundary (из SPEC frontmatter, если source — SPEC или PLAN→SPEC):
   • Извлеки system_boundary и external_systems из SPEC frontmatter
   • Если system_boundary задан — передай в субагент: НЕ создавай TASK для external_systems, реализуй ТОЛЬКО system_boundary
   • Если source — FEAT/BUG/DEBT/CHORE без SPEC: "N/A" Integration Contract Pre-check (если external_systems non-empty):
   • Для каждой записи в external_systems проверь: contract_ref указан и файл существует?
   • Если contract_ref пуст или файл не найден → добавь Open Question (НЕ блокируй генерацию): "Контракт для [системы] отсутствует (contract_ref: [значение]). Задачи создаются, но интеграционные тесты будут неполными без контракта."
   • Выведи предупреждение PM перед PM Checkpoint
6. Knowledge base (.state/knowledge.json):
   • projectContext, patterns, antiPatterns, decisions
   • glossary — ubiquitous language project-wide (federated из DESIGN packages). Передавай в субагент как source-of-truth для именования сущностей в коде и тестах.
7. Шаблон задачи (docs/templates/task-template.md)
8. Текущие счётчики (.state/counters.json)

2.5. Design Gate (условная блокировка)

1. Определи source SPEC:

   • source = SPEC-NNN → spec_id = source
   • source = PLAN-NNN → spec_id = parent PLAN'а (через PROJECT_STATE.artifacts[plan_id].parent)
   • source = FEAT-NNN / BUG-NNN → SKIP (design не обязателен для простых фич и багов)
   • Если SPEC не найден → SKIP

2. Проверь наличие DESIGN-PKG:

<!-- polisade:claude-only BEGIN -->

• Living-corpus (#187, experimental): если architecture.corpus.mode == "living", дизайн ведётся в едином корпусе, а не per-SPEC пакетом. Считай gate удовлетворённым, если FR/NFR этой SPEC покрыты в docs/architecture/trace.json (FR → element) — т.е. для SPEC уже есть docs/specs/SPEC-NNN/changeset.yaml. Если покрытия нет → рекомендуй /polisade:design-corpus {spec_id} (вместо /polisade:design). Не ищи per-SPEC DESIGN-PKG в этом режиме; silo-логика ниже не применяется.

<!-- polisade:claude-only END -->

• Проверь design_package field в SPEC frontmatter, ИЛИ
• Сканируй docs/architecture/*/manifest.yaml на parent: {spec_id}
• Если DESIGN-PKG существует:
  • Если design_waiver: true в SPEC → сбрось: установи design_waiver: false (waiver был временным, теперь design создан — enforcement восстанавливается)
  • SKIP (design уже сделан)

3. Проверь SPEC frontmatter на design_waiver:

   • Если design_waiver: true → SKIP (PM дал waiver, DESIGN-PKG ещё не создан)

4. Lightweight trigger detection:

   • Прочитай skills/design/references/conditional-triggers.md
   • Сканируй содержимое SPEC на trigger patterns из reference
   • Собери needed_artifacts set (какие типы артефактов triggered: erd, openapi, sequence, etc.)

5. Если needed_artifacts НЕ пустой → БЛОКИРОВКА с waiver:

═══════════════════════════════════════════
⛔ DESIGN GATE
═══════════════════════════════════════════
{spec_id} имеет архитектурные триггеры,
но DESIGN package не создан.

Обнаруженные триггеры:
  • {тип} — {краткое описание что обнаружено}
  • ...

Варианты:
  1. /polisade:design {spec_id} — создать design package (рекомендуется)
  2. Продолжить без дизайна (explicit waiver)

При выборе waiver: задачи создаются с design_waiver: true.
Enforce-проверки Design Conformance при review
не применяются для этих задач.
═══════════════════════════════════════════

6. Дождись ответа PM:

   • PM выбирает /polisade:design → прервать создание задач, PM запускает design
   • PM выбирает waiver: a. Добавь design_waiver: true в SPEC frontmatter (persistent marker) b. Все TASKs, создаваемые из этого SPEC, наследуют design_waiver: true c. При повторном вызове /polisade:tasks PLAN-NNN → gate проверяет SPEC frontmatter → видит design_waiver: true → SKIP (не переспрашивает)

7. Если needed_artifacts пустой → SKIP (SPEC не имеет архитектурных триггеров, design не нужен)

2.6. Pre-check: design_refs mapping (основной агент)

<!-- polisade:silo-legacy CAPSULE BEGIN -->

Силос → корпус. Живой корпус docs/architecture/ — источник правды по архитектуре. Пакет docs/architecture/DESIGN-NNN-<slug>/ — legacy-силос: сначала ищи факт в корпусе (model/, c4/, glossary/, quality/, flows/, contracts/, decisions/), и только если там его нет — читай силос. Прочитал силос — скажи вслух, отдельной строкой в выводе: ⚠️ переходное чтение силоса: <путь> (источник правды — корпус docs/architecture/). Молчаливое чтение силоса — дефект, а не экономия: PM не видит, что решение принято по устаревшему укладу. Если в пакете есть MIGRATED.md, его карта домов обязательна к прочтению, и читается она так: из силоса перестают читать ТОЛЬКО файлы таблицы «Перенесено 1:1» — они уже лежат в корпусе целиком. Файлы таблицы «Ещё НЕ в корпусе» не переносились: там назван целевой дом, которого ещё нет, и единственная копия факта — в силосе. Такой файл читают отсюда (громко), пока модель не свернула его в корпус; считать его устаревшим — потерять факт. Перевод силоса на корпус — python3 scripts/polisade_migrate_silo.py <пакет> (dry-run по умолчанию, запись — явным --apply, конфликты — выбор человека, не скрипта).

<!-- polisade:silo-legacy CAPSULE END -->

Если DESIGN-PKG существует И design_waiver != true:

1. Прочитай manifest.yaml DESIGN-пакета
2. Извлеки все FR/NFR из секции требований source SPEC — адресуй по имени секции, не по номеру (#233): legacy ISO-29148 (без kind) → §5 «Functional Requirements» + §6 «Non-Functional Requirements»; kind: change-spec → §2 «Дельта требований (FR/NFR)» (⛔ не §5/§6 — там дельта интента и открытые вопросы)
3. Для каждого FR/NFR проверь: есть ли хотя бы один артефакт в manifest.artifacts[] где realizes_requirements содержит этот FR/NFR?
4. Если есть unmapped requirements (FR/NFR не покрыты ни одним артефактом в manifest):
   • STOP — НЕ запускай субагент
   • Спроси PM:

   ═══════════════════════════════════════════
   ⛔ UNMAPPED REQUIREMENTS
   ═══════════════════════════════════════════
   Следующие requirements из {spec_id} не покрыты
   ни одним артефактом в {DESIGN-NNN}/manifest.yaml:
   
     • FR-003 — {title}
     • NFR-002 — {title}
   
   Действие:
     Обновите manifest.yaml — добавьте unmapped requirements
     в realizes_requirements соответствующих артефактов.
     После обновления повторите /polisade:tasks.
   ═══════════════════════════════════════════
   

   • Дождись обновления manifest.yaml PM'ом → повторить шаг 2.6
5. Если все requirements mapped → продолжить к шагу 3

Если DESIGN-PKG не существует ИЛИ design_waiver: true → SKIP

3. Формирование prompt для субагента

Субагенты работают в режиме read/plan only — они читают код и планируют декомпозицию, но НЕ присваивают финальные TASK ID и НЕ являются авторитетом для сохранения; финальную материализацию делает лидер (основной агент) в шаге 6.

Для отдельного roadmap item из PLAN:

Prompt-шаблон (SYSTEM ROLE Task Planner: принципы атомарности/конкретности/ зависимостей/полноты/верификации/покрытия + полный SELF-REVIEW чеклист, ROADMAP ITEM, SPEC-контекст, OUT OF SCOPE, CONSTRAINTS, SYSTEM BOUNDARY, PROJECT CONTEXT, TASK TEMPLATE, OUTPUT REQUIREMENTS, ФОРМАТ ОТВЕТА с COVERAGE).

Прочитай references/prompt-plan-item.md перед этим шагом.

Для SPEC/FEAT напрямую:

Prompt-шаблон для декомпозиции SPEC/FEAT (те же принципы; INPUT DOCUMENT целиком, parent-chain resolve для FEAT, группировка по логическим фазам Setup→Core→API→UI→Tests→Integration, COVERAGE-блок).

Прочитай references/prompt-spec-feat.md перед этим шагом.

Для BUG / DEBT / CHORE напрямую:

Один общий prompt для всех трёх типов (work-unit без parent SPEC). Различия — в трёх подстановках: {SOURCE_TYPE}, {SOURCE_FILE_PATH}, {SYSTEM_ROLE}. Обычно 1 TASK (BUG/CHORE), 1-3 (DEBT); requirements: [] graceful.

Прочитай references/prompt-bug-debt-chore.md перед этим шагом.

Coordinate-task mode — аддендум к промпту субагента (ОБЯЗАТЕЛЬНО в режиме):

⚙️ Если включён Coordinate-task mode (гейт: settings.experimental.changeSpec == true и source — change-spec, kind: change-spec), к выбранному выше базовому промпту (prompt-plan-item.md для PLAN-item / prompt-spec-feat.md для change-spec напрямую) допиши аддендум references/prompt-coordinate-task.md. Без него субагент (M3-генерация) эмитит «плоские» таски без структурных координат — контракт coordinate-task не доезжает до генерации (первопричина находок h/i вердикта exit-Ф5): тест-файлы уезжают в прозу вместо coordinates: (TDD-гейт active=False), creates_files: [] при create-file таске (untracked-слепота). Аддендум несёт: kind: coordinate-task, coordinates: (включая тест-координаты структурно), creates_files: (реальными путями), requirements:, Gherkin-AC, ## Приёмка + coordinate-task self-review + few-shot.

Прочитай references/prompt-coordinate-task.md перед этим шагом.

4. Запуск субагента

Для PLAN (итерация):

Для каждого roadmap item в PLAN:
  Task tool:
    subagent_type: "general-purpose"
    description: "Create TASKs for {item_id}"
    prompt: [prompt для конкретного item]

Для SPEC/FEAT/BUG/DEBT/CHORE:

Task tool:
  subagent_type: "general-purpose"
  description: "Create TASKs from {SPEC-XXX/FEAT-XXX/BUG-XXX/DEBT-XXX/CHORE-XXX}"
  prompt: [prompt с полным документом]

⚙️ В Coordinate-task mode prompt = базовый промпт + аддендум references/prompt-coordinate-task.md (см. §3). Субагент обязан вернуть таски с kind: coordinate-task, структурными координатами (impl и тест-файлы), заполненным creates_files:, Gherkin-AC и ## Приёмка. Проверка структурной эмиссии — линт в §8 (в риге блокирующий, перегенерация при красноте).

⚠️ Параметры инструмента субагентов — ТОЛЬКО те, что в шаблоне вызова выше. НЕ добавляй параметры окружения (working_dir, isolation, песочницы и т.п.) — ни вместе, ни по отдельности: субагент наследует текущий каталог, этого достаточно. На некоторых CLI (qwen-code) working_dir и isolation взаимоисключающие, и их совместная передача отвергает вызов. Если запуск субагента два раза подряд отвергнут ошибкой параметров — не перебирай параметры дальше: выполни декомпозицию сам, в текущем контексте, по тому же промпту. Декомпозиция без субагента лучше, чем зацикленный перебор сигнатуры вызова.

5. PM Checkpoint (consolidated)

При создании > 3 задач — ОБЯЗАТЕЛЬНАЯ остановка.

Ключевой принцип: ОДИН checkpoint на весь запуск, а не на каждый roadmap item. Все субагенты завершают работу, все TASKs собираются в память, и только потом PM видит консолидированный обзор и принимает решение. Файлы сохраняются ТОЛЬКО после подтверждения.

Формат consolidated checkpoint (блок «НУЖНО РЕШЕНИЕ PM» с группировкой по фазам Setup→Core→API→UI→Tests→Integration + COVERAGE + действия 1/2/3), таблица группировки по фазам и опциональный per-item mode вынесены в reference.

Прочитай references/checkpoint-format.md перед этим шагом.

6. Обработка результата

Субагенты отработали в режиме read/plan only — их выход это план декомпозиции, а не финальные файлы. Лидер (основной агент) присваивает финальные TASK ID и выполняет финальное сохранение строго здесь, в шаге 6.

После подтверждения PM в consolidated checkpoint (или сразу если ≤ 3 задач):

1. Вычисли next-id для TASK по протоколу из skills/tasks/references/compute-next-id.md (единый max по .state/counters.json, PROJECT_STATE.artifactIndex и file-scan tasks/TASK-*.md). При Counter drift — АБОРТ с рекомендацией python3 {plugin_root}/scripts/polisade_sync.py . --apply --yes.
2. Batch-режим. После первого next_id внутри цикла присваивай next_id, next_id+1, next_id+2, … БЕЗ повторного чтения диска. Это безопасно: никто не создаёт TASK параллельно в той же сессии.
3. Write-guard на каждый файл. Перед Write tasks/TASK-{k}-slug.md проверь, что файл не существует и что TASK-{k} нет в state.artifactIndex. При коллизии — АБОРТ (до IO всего батча или после частичной записи: любой guard-fail останавливает оставшуюся пачку и сообщает, сколько файлов уже создано).
4. Инкрементируй счётчик TASK на количество созданных (counters.json[TASK] = last_written_n).
5. Обнови .state/PROJECT_STATE.json:
   • Добавь все TASK в artifacts
   • Задачи без зависимостей → ready + в readyToWork
   • Задачи с зависимостями → ready но НЕ в readyToWork
   • Обнови parent: добавь TASK в children
   • Если PLAN → parent статус in_progress
   • Если SPEC/FEAT/BUG/DEBT/CHORE → parent статус остаётся ready

Coordinate-task mode (experimental — Pipeline V2 Ф2, issue #211)

⚙️ Гейт совместимости. Режим включается ТОЛЬКО когда одновременно: settings.experimental.changeSpec == true в .state/PROJECT_STATE.json И source-артефакт — change-spec (frontmatter kind: change-spec). Иначе — обычная декомпозиция выше, ничего не меняется. Так BUG/DEBT/CHORE и legacy-задачи остаются с мягким линтом, а change-spec порождает таски «уровня джуна» с точными координатами.

Идея (roadmap §5, «ТЗ уровня джуна»): таск несёт координаты файл/символ, и реализатору не нужен свободный поиск — implement-рука с LOCALIZE берёт цели прямо из TASK. Координаты берутся из §3 «Локализация» change-spec, а порядок и охват тасков усиливаются impact-ансамблем по графу кода.

⚠️ Контракт доезжает до субагента (M3-генерация), а не только до лидера. Правила ниже субагент применяет при генерации — поэтому в §3/§4 к его промпту дописывается аддендум references/prompt-coordinate-task.md. Без аддендума субагент эмитит «плоские» таски без структурных координат (первопричина находок h/i вердикта exit-Ф5). Лидер (основной агент) отвечает за материализацию ID (§6) и линт (§8) — но структурную эмиссию делает субагент по аддендуму.

Когда режим включён — что меняется

1. Frontmatter TASK. Проставь kind: coordinate-task. Это включает строгий линт (coordinates / requirements / Gherkin-AC обязательны).

2. coordinates: — из §3 «Локализация» change-spec. Для каждого FR, который закрывает эта TASK, скопируй его строки локализации (file + symbol) в coordinates. Формат:

   coordinates:
     - file: src/path/file.ext
       symbol: Class.method
   

2a. creates_files: — декларация create-file таска (issue #228). Если таск создаёт новые файлы (координата указывает на ещё-не-существующий файл), перечисли эти пути в creates_files::

creates_files:
  - src/path/NewClass.ext

Зачем: (1) координата на файл из creates_files освобождается от линт-ошибки E-task-coord-missing (файл задекларирован как создаваемый, а не «сломанная» координата — снимает коллизию create-таск × проверка существования, Ф3.8/TG.3); необъявленная несуществующая координата остаётся ошибкой. (2) это машиночитаемый контракт с исполнительным контуром (T5): validate/no-op-гейт не краснеет и не эскалирует по untracked-файлам, которые этот таск создаёт (голый git diff их не видит — первопричина спурьёзной эскалации, true-baseline-v1.2 §8).

2b. Тест-координаты — структурно, не в прозе (issue #230, первопричина находки h). Тест — это КООРДИНАТА, а не пункт в секции «Тесты». Для каждого таска, меняющего проверяемое поведение, добавь в coordinates: явный путь к тест-файлу (символ = тест-класс/метод); новый тест-файл — также в creates_files::

coordinates:
  - file: src/main/java/org/acme/UserService.java       # impl
    symbol: UserService.create
  - file: src/test/java/org/acme/UserServiceTest.java    # тест-координата
    symbol: UserServiceTest.rejectsDuplicate

Зачем: исполнительный контур (TDD-гейт Ф3.8) собирает команду собственных тестов репо (tests_cmd) из тест-файловых координат цепочки (путь-тест распознаётся по сегменту test/spec). Нет тест-координаты → гейт active=False → некомпилирующийся/пустой тест руки проходит в done (003 на пилоте Ф5). Можно вынести тесты отдельным зависимым тест-таском (coordinates: — только тест-файлы, depends_on: на impl), но у каждой цепочки, меняющей поведение, обязана быть ≥1 тест-координата.

3. requirements: [...] — composite FR/NFR-ID из change-spec (P0-7), которые закрывает TASK. Формат {SPEC_ID}.FR-NNN.

4. Gherkin-AC — перенеси сценарии AC-FR-NNN-MM из §2 change-spec в подсекцию ### Gherkin AC тела TASK (≥1 сценарий Given/When/Then).

5. Приёмка — проверяемый контракт сущностей (см. отдельную секцию ниже). Таск, несущий координаты, обязан назвать точные имена создаваемых/ переименовываемых сущностей и их контракт вход→выход, иначе рука уезжает в near-miss. Линт поднимает W-task-acceptance-missing, если секции приёмки с явным именем нет.

6. depends_on: — порядок исполнения по зависимостям между тасками (таск, меняющий контракт, идёт до тасков, зависящих от него).

7. Impact-оценка #184 — честная деградация без графа кода. У клиента нет инструментов обхода графа (blast-radius / co-changed — способность исполнительного контура со знанием-слоем; в клиенте их нет — V3-P2, ADR-0004). Поэтому здесь действует v0-деградация как штатный путь:

   • координаты берутся только из §3 change-spec;
   • для символа, чья правка меняет контракт/сигнатуру, допустим точечный grep -rn "<symbol>" — попадания в файлы уже названные в §3 помогают разложить coordinates и рёбра depends_on между тасками;
   • полный impact-набор (что ещё сломается ВНЕ §3) ансамблем НЕ считается. Молча — нельзя (F1): пометь таск impact_complete: false + строкой в теле ⚠️ impact-набор НЕПОЛОН: ансамбль графа не выполнялся — координаты только из §3. ⛔ «impact посчитан» / «зависимостей нет» здесь запрещены: набор неполон по построению, а downstream читает его как полный.

8. Линт тасков — дефектный таск не выпускается + предупреждения. После сборки тасков (до финальной записи) прогони линт в два прохода. (а) Ошибки — на каждом таске (в цикле):

   python3 scripts/polisade_spec_lint.py --root . --json tasks/TASK-{k}-{slug}.md
   

   exit 1 (нет координат / нет FR-ID / нет Gherkin / координата на несуществующий файл) → почини таск и повтори; выпускать красные таски нельзя. W-task-acceptance-missing (warning, exit 0) — таск несёт координаты, но ни одна секция «Приёмка»/«Критерии приёмки» не называет сущность в бэктиках → допиши секцию «Приёмка» (см. ниже) с точными именами. Не блокирует выпуск, но игнорировать нельзя: это и есть страховка от near-miss «руки». W-task-createfile-blind-verify (warning, exit 0) — create-file таск (с creates_files:) проверяет результат голым git diff (слеп к untracked; issue #228) → перепиши самопроверку untracked-safe (existence+компиляция / git add -N / git status --porcelain, см. секцию «Приёмка»). Не блокирует, но игнорировать нельзя: голый git diff на create-file — топливо спурьёзной эскалации.

   ⚙️ Блокирующий режим для рига/автономного контура (issue #230). В интерактивном PM-запуске оба предупреждения — advisory (warning, exit 0). В риге (автономный исполнительный контур, где нет человека дописать секцию) прогони линт с флагом --strict-acceptance:

   python3 scripts/polisade_spec_lint.py --root . --strict-acceptance --json tasks/TASK-{k}-{slug}.md
   

   Флаг эскалирует W-task-acceptance-missing и W-task-createfile-blind-verify до E-level (exit 1). Красный → перегенерируй таск (допиши ## Приёмка с бэктик-именами / untracked-safe самопроверку) и повтори; выпускать красный в риге нельзя. Эквивалент — переменная окружения POLISADE_SPEC_LINT_STRICT_ACCEPTANCE=1 (исполнительный контур выставляет её вместо флага). Дефолт (без флага/env) — прежнее advisory-поведение, обратная совместимость для legacy-проектов не ломается. (б) Пересечение координат — на всём наборе тасков этой спеки сразу (одним вызовом — иначе линт не увидит кросс-таск overlap):

   python3 scripts/polisade_spec_lint.py --root . --json tasks/TASK-*.md
   

   W-task-coord-overlap (warning, exit 0) на общий координатный файл двух тасков → пересмотри разбиение по правилу гранулярности ниже. Пересечение неустранимо → оставь, но зафиксируй дизъюнктность требований в теле тасков. Warning не блокирует выпуск, но игнорировать его без разбора нельзя. Линт-скрипт доставлен /polisade:init'ом (проектный scripts/).

Гранулярность тасков и пересечение координат (обязательно)

⛔ Один изменяемый файл/символ — один таск, где выполнимо. Пересечения координатных файлов между тасками одной спеки — минимизировать. Пересекающиеся координаты — топливо для тихого пропуска исполнителя (idempotency-skip: правка соседнего таска наводит зелёный тест, критический таск не исполняется молча — вердикт Ф3.5). Атомарный таск дешевле, диагностичнее и лишает этот механизм топлива.

Правила разбиения (буквально):

1. Раскладывай FR по тасками так, чтобы множества координатных файлов не пересекались. Разный файл → разный таск.
2. Один файл правится в двух тасках только если это действительно неустранимо (общий контракт и его вызов лежат в одном файле). Тогда:
   • requirements: этих тасков обязаны быть дизъюнктны (закрывают разные FR/NFR, не один и тот же);
   • в теле каждого таска (Scope / Notes) явно напиши: «общий файл <path> с TASK-XXX, моя правка — <символ/участок>, не пересекается».
3. depends_on: задаёт порядок: таск, меняющий сигнатуру/контракт символа, идёт до зависящего от него — не два параллельных таска на один символ.

Негативный пример (⛔ НЕ ДЕЛАЙ ТАК):

# TASK-010 — «валидация email»
coordinates:
  - file: src/user/service.py
    symbol: UserService.create
# TASK-011 — «нормализация телефона»   ← тот же файл, тот же символ
coordinates:
  - file: src/user/service.py
    symbol: UserService.create

Два таска правят UserService.create в одном файле → пересечение координат → риск тихого skip. Правильно: один таск на UserService.create (обе правки внутри одного символа — это один атомарный change) ИЛИ разнести по разным символам/файлам, если правки логически независимы.

Позитив (✅ — разные файлы, пересечения нет, W-task-coord-overlap молчит):

# TASK-010 — валидация email
coordinates:
  - file: src/user/email_validator.py
    symbol: validate_email
# TASK-011 — нормализация телефона
coordinates:
  - file: src/user/phone.py
    symbol: normalize_phone

Если общий файл неизбежен (разные символы в одном файле) — линт всё равно поднимет W-task-coord-overlap как сигнал перепроверить: убедись, что требования дизъюнктны, и зафиксируй это в теле тасков; это не запрет, а осознанное решение.

Секция «Приёмка» — проверяемый контракт сущностей (обязательно)

⛔ Координаты говорят «где», приёмка говорит «что именно получится». Координатный таск наводит руку на место в коде, но не фиксирует контракт результата — и рука уезжает в near-miss: создаёт «почти то». Два типовых промаха: (1) не то имя — приёмка требует класс OrderTotalCalculator, а рука создаёт близкое OrderSumCalculator; (2) не та семантика — метод слияния дедуплицирует по индексу вместо ключа. В обоих случаях координаты были верны — не было явного, проверяемого имени и контракта в приёмке. Секция «Приёмка» закрывает этот зазор.

Каждый координатный таск, который создаёт или переименовывает сущность либо меняет контракт, несёт секцию ## Приёмка (или подсекцию ### Приёмка: сущности и контракт внутри «Критериев приёмки») из трёх частей:

1. Создаваемые/изменяемые сущности (точные имена). Каждая сущность — своим бэктик-именем и видом: класс, метод (с сигнатурой), исключение, функция, поле, эндпоинт. Имя берётся из §4 «Контракты» и §3 «Локализация» change-spec — не выдумывай своё, перенеси то, что уже решено спекой (стабильность имён сквозь SPEC→TASK→PR, P0-3). Именно бэктик-имя проверяет линт.

2. Контракт поведения (вход → выход). Хотя бы: главный путь (вход → выход), ≥1 краевой случай (null/пусто/дубль → что происходит), и что не меняется. Согласуй дословно с Gherkin-AC и §4 change-spec.

3. Самопроверка (при уместности). Команда из knowledge.json (<test-command> --filter …, curl …, компиляция целевого модуля), которой исполнитель локально убедится в результате до review.

   ⛔ Для create-file таска самопроверка обязана быть untracked-safe. Новые файлы untracked — голый git diff их не видит (ложно-пустой diff → красный validate → спурьёзная эскалация; issue #228). Не проверяй результат голым git diff. Проверяй существованием + компиляцией, git add -N перед diff, либо git status --porcelain:

   # ✅ create-file: existence + компиляция целевого модуля
   test -f src/path/NewClass.java && ./gradlew :module:compileJava
   # ✅ либо intent-to-add делает untracked видимым для diff
   git add -N src/path/NewClass.java && git diff --stat
   # ❌ голый `git diff` — слеп к untracked, для create-file запрещён
   

   Линт (шаг 8) поднимает W-task-createfile-blind-verify, если у create-file таска (с creates_files:) секция самопроверки/Verification проверяет голым git diff.

Пример (near-miss «почти то имя» закрыт — имя и контракт явные и проверяемые):

## Приёмка

**Создаваемые/изменяемые сущности (точные имена):**
- `OrderTotalCalculator` — новый класс (`com.example.orders`)
- `OrderTotalCalculator.calculate(List<LineItem>)` — новый метод,
  сигнатура `public Money calculate(List<LineItem> items)`
- `EmptyOrderException` — новое исключение (`extends RuntimeException`,
  поля `orderId`)

**Контракт поведения (вход → выход):**
- ≥1 позиция → `Money` = сумма `price × qty` по всем позициям;
- `null` / пустой список → `throw EmptyOrderException` с `orderId`;
- краевой: позиция с отрицательной ценой → `throw NegativePriceException`;
- НЕ меняется контракт сериализации `OrderDto`.

**Самопроверка:**
```bash
./gradlew :orders-core:compileJava

Линт (шаг 8) поднимает `W-task-acceptance-missing`, если координатный таск не
называет ни одной сущности бэктиком ни в «Приёмке», ни в «Критериях приёмки» —
это сигнал допиши контракт, а не косметика. Обратная совместимость: warning, не
error; таск, уже называющий сущности в критериях (legacy WP3.4), молчит.

Всё остальное (валидация source, Design Gate, PM Checkpoint, материализация
ID лидером в шаге 6) — без изменений.

## Формат вывода

Два варианта финального вывода — «ЗАДАЧИ СОЗДАНЫ» при ≤ 3 задачах (без
checkpoint) и развёрнутый по фазам после consolidated PM Checkpoint — с
примерами и блоком «СЛЕДУЮЩИЙ ШАГ» (`/polisade:implement` / `/polisade:continue`).

**Прочитай `references/output-examples.md` перед этим шагом.**

## Структура TASK файла

Полный пример TASK-файла (frontmatter: id/title/status/parent/priority/
depends_on/blocks/requirements/design_refs + секции Контекст / Что нужно
сделать / Файлы для изменения / Критерии приёмки / Edge cases / Тесты).

**Прочитай `references/task-template-example.md` перед этим шагом.**

В **Coordinate-task mode** (см. выше) frontmatter дополнительно несёт
`kind: coordinate-task` и `coordinates:` (файл/символ из §3 локализации
change-spec), для create-file таска — `creates_files:` (новые пути; issue #228),
критерии приёмки — подсекцию `### Gherkin AC`, а тело — секцию `## Приёмка`
(точные имена сущностей + контракт вход→выход; untracked-safe самопроверка для
create-file; линт `W-task-acceptance-missing` / `W-task-createfile-blind-verify`).
Шаблон: `docs/templates/task-template.md`.

## Важно

- **PM Checkpoint обязателен при > 3 задачах** — всегда **consolidated** (один на весь запуск, НЕ per-item)
- Все TASKs собираются в память до сохранения файлов. Файлы создаются ТОЛЬКО после подтверждения PM
- Задачи должны быть атомарными (можно сделать за один подход)
- Для FEAT обычно 2-5 задач достаточно
- Для BUG обычно 1 задача (фикс + тесты вместе)
- Чётко описывай что нужно сделать
- Указывай конкретные файлы где возможно
- **Субагент ОБЯЗАН читать затронутый код** — не полагаться только на описание бага/фичи
- **Субагент ОБЯЗАН провести self-review** — задача должна быть самодостаточной для автономного агента
- `/polisade:implement` работает только с TASK
- При итерации по PLAN — запускай субагенты параллельно для ВСЕХ items, собирай результаты, показывай один checkpoint
- Субагент работает в чистом контексте — передавай весь необходимый контекст

## Inline references (auto-embedded for Qwen/GigaCode builds)

<!-- polisade:tasks INLINE REFERENCES BEGIN -->
<!-- For Claude Code: read references/<f>.md from this skill dir at runtime as instructed
     inline above (`**Прочитай `references/...`**`). НЕ реконструируй содержимое
     референсов из контекста — читай файл. The converter replaces this span with the
     verbatim reference bytes for Qwen/GigaCode builds (where the install-dir is
     Filesystem-Guard read-protected). -->
<!-- polisade:tasks INLINE REFERENCES END -->