# Спецификации задач — архив

**ТЗ живут в теле issue** (решение владельца 2026-09-10, [#517](https://github.com/Matysh/houseplan-card/issues/517)): раздел `## ТЗ` в самом issue, файл здесь больше не создаётся. Каталог сохраняет ТЗ, написанные до этой даты; задачи, у которых файл уже есть, доживают по старой схеме, и их файлы редактируются свободно.

Почему переехало: файл решал ровно одну задачу — доказать, что вердикт ревью вынесен на конкретном тексте, — и создавал две. Индекс в этом README конфликтовал между параллельными задачами и служил вторым, отстающим словарём статусов; каждая правка ТЗ стоила коммита, пуша и метки. Доказуемость теперь обеспечивает конвейер: в блок якорей документа ревью пишется `sha256` нормализованного тела issue, а правка ТЗ после зелёного ревью ТЗ приходит ревьюеру кода находкой (`PROCESS.md` §2.3, §7.1).

Единственный канонический backlog проекта — GitHub Issues; статус задачи — её метка `S1-new`…`S8-merged` (`PROCESS.md` §9). Индекс «issue ↔ ТЗ» здесь не ведётся: имя файла архива начинается с номера issue, этого достаточно, чтобы найти его командой `ls docs/specs/<NN>-* legacy/specs/<NN>-*`.

Здесь остались только ТЗ, на которые ссылаются живые код, тесты и документы (ADR, `ISOMETRIC.md`, `SUN.md`, `RADAR.md`, `LIGHT.md`, `DECOR-EDITOR.md`, support-relay), и те, на которые ссылаются они сами. Остальные ТЗ выпущенных задач перенесены в [`legacy/specs/`](../../legacy/specs/) (#682): историю не переписываем, ссылки из документов ревью ведут по SHA и живут дальше. Каталог нужен `scripts/task-packet.mjs` и проверке 3 `scripts/process-gate.mjs`.

## Обязательные release-артефакты ТЗ

Если задача меняет пользовательское поведение, её ТЗ обязано явно перечислить:

- записи в `docs/CHANGELOG.md` и `docs/CHANGELOG.ru.md`;
- затронутую пользовательскую документацию;
- требуемые screenshots/golden и способ их review, если меняется визуал;
- release/performance/security artifacts, если они входят в acceptance gate.

Отсутствие этого раздела не означает, что документация необязательна. Для чистого refactoring ТЗ должно прямо зафиксировать отсутствие пользовательских изменений и перечислить технические доказательства безопасного поведения.