секции роадмапа названы и закреплены линтером

готово | запланировано | направления | разработка, англ. done | planned |
directions | tooling. Из четырёх предложенных имён отвергнуто одно, и по
проверяемой причине: «окружение» уже занято — в architecture.md это боевое
окружение приложения, «где работает, что рядом, кто перезапускает», и одно
слово в двух смыслах развело бы документы канона.

Секции роадмапа стали каноническими, в отличие от секций беклога, и разница
выведена, а не назначена: у каждой секции роадмапа своя семантика, в первую
пишет сам close, и роадмап, названный по-своему, читался бы только своим
автором. Секции беклога — полки, смысла не несут, остаются делом проекта.

check проверяет три вещи: состав закреплён (чужая секция — ошибка), все четыре
обязаны быть, язык один на весь индекс. Проверено на том случае, ради которого
правило и заводилось: «Что уже пройдено», которую healthlog вёл руками, теперь
называется ошибкой поимённо. Оба языка прогнаны вживую, включая close в
английский роадмап.

Ключа tasks.achieved_section не появилось — секция достигнутого опознаётся по
каноническому имени в любом из языков; --roadmap-sections у init упразднён,
выбирать больше нечего.

Названные вслух компромиссы: «готово» слегка тянет в трекерную рамку
«состояние работы», тогда как секция про возможность — перевесила читаемость;
цель в «запланировано» может быть уже наполовину построена, это очередь, а не
«не начато», «в работе» живёт в SPRINT.md.

DECISIONS 19: ГГГ переписан, добавлен ДДД, следствие 78 заменено. TODO 7 закрыт.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

av-dev-pm/skills/tasks/SKILL.md

@@ -69,17 +69,26 @@ docs/tasks/
 
 **Четыре секции роадмапа, и первая отвечает на половину вопроса:**
 
-| Секция | Что в ней |
-| --- | --- |
-| `умеет` | достигнутые цели — строкой с датой, **без ссылки на файл**: файл удалён, поведение живёт в спеках |
-| `строим` | очередь значима и обосновывается прозой рядом |
-| `направления` | очереди нет, тянутся долго |
-| `станок` | инструмент и процесс разработки — не возможности приложения, и потому отдельно |
+| Секция | Англ. | Что в ней |
+| --- | --- | --- |
+| `готово` | `done` | достигнутые цели — строкой с датой, **без ссылки на файл**: файл удалён, поведение живёт в спеках |
+| `запланировано` | `planned` | очередь значима и обосновывается прозой рядом |
+| `направления` | `directions` | очереди нет, тянутся долго |
+| `разработка` | `tooling` | инструмент и процесс — не возможности приложения, и потому отдельно |
 
-Имена секций сейчас **временные**: они читаются хуже, чем должны, и будут
-пересмотрены (`DECISIONS.md`, тема 19). Проект вправе назвать свои иначе —
-секции берутся из заголовков индекса, — но дом достигнутого скрипт обязан знать
-по имени, и оно живёт в `docs/.pm.json`, ключ `tasks.achieved_section`.
+**Секции роадмапа канонические, секции беклога — нет**, и разница не в любви к
+единообразию. У каждой секции роадмапа свой смысл, в первую пишет сам `close`, и
+роадмап, названный по-своему, читался бы только своим автором. Секции беклога
+(`ядро`, `инфра`) смысла не несут — это полки, и остаются делом проекта.
+
+Отсюда три правила, которые проверяет `tasks.py check`: **состав закреплён**
+(чужая секция — ошибка, а не вольность), **все четыре обязаны быть** (нет
+секции — нет ответа на её часть вопроса), **язык один на весь индекс**.
+`--roadmap-sections` у `init` нет: выбирать нечего.
+
+Оговорка про `разработка`: слово `окружение` сюда не годится — в
+`architecture.md` оно уже значит боевое окружение приложения, и одно слово в двух
+смыслах развело бы документы канона.
 
 **Секции «блокеры» в беклоге нет.** Блокер — это *состояние* (спринт не может
 продолжаться ни одной задачей), а не полка: он живёт ровно до ответа человека, и
@@ -101,7 +110,7 @@ docs/tasks/
 всех наборов без отдельного журнала.
 
 **У достигнутой цели запись остаётся, и это единственное исключение.** Файл
-удаляется так же, а строка переезжает в секцию `умеет` с датой. Причина в том,
+удаляется так же, а строка переезжает в секцию `готово` с датой. Причина в том,
 что цель — не работа, а **возможность**: «что приложение умеет» это половина
 вопроса, ради которого роадмап и открывают, и стирать её вместе с файлом значит
 оставить инструмент, отвечающий только «что осталось». Вторым домом это не
@@ -163,9 +172,9 @@ stateDiagram-v2
 отведена отдельная секция роадмапа, чтобы они были видны в том же экране и при
 этом не читались как возможности продукта.
 
-Секция выбирается так: очередь значима и обоснована прозой — `строим`; тянется
-долго и очереди не имеет — `направления`; не про приложение — `станок`;
-достигнутое кладёт туда сам `close`.
+Секция выбирается так: очередь значима и обоснована прозой — `запланировано`;
+тянется долго и очереди не имеет — `направления`; не про приложение —
+`разработка`; в `готово` кладёт сам `close`.
 
 - **Список задач цели выводится, а не хранится.** В теле цели — зачем она и что
   считается её завершением; перечня задач там нет. Он был бы третьим индексом и
@@ -175,7 +184,7 @@ stateDiagram-v2
 - **Статус цели выводится.** Цель достигнута, когда у неё не осталось открытых
   задач; `[x]`/`[~]` руками не ведутся, а `close` цели с живыми задачами
   скрипт запретит. Достижение — `close <цель> --implemented`: файл удаляется,
-  строка с датой переезжает в `умеет`. Ошиблись — `reopen` вернёт файл и
+  строка с датой переезжает в `готово`. Ошиблись — `reopen` вернёт файл и
   **снимет строку достигнутого**, чтобы роадмап не утверждал того, чего нет. Единственная оговорка: цель без задач неотличима — «ещё не
   разобрана» или «всё закрыто». Различает **тег `decomposed`** в мете
   цели: он ставится, когда цель разложена на задачи. Тег, а не строка в теле —