Files
houseplan-card/docs/specs
claude[bot] 7194fb2df0 feat(adoption): one owner for config/layout identity and the adoption sequence
`src/config-adoption.ts` owns config/layout with revision and fingerprint;
the host keeps `_serverCfg`/`_cfgRev`/`_layout`/`_layoutRev` as delegates.
All seven authoritative adoptions go through `adoptAuthoritativeGated`
(backdrop readiness → continuity → adopt → profile tail); the post-write
paths (space/delete ×2, optimize_undo, import/apply) gain the gate and take
revisions from the re-read bodies. `rollbackOptimistic` moves to the owner;
plan-optimize, space copy and the vacuum writers stop assigning identity.

Issue: #500
User-Visible: no
2026-09-10 11:41:16 +00:00
..
2026-08-09 21:51:33 +03:00
2026-08-09 21:51:33 +03:00
2026-09-07 11:06:28 +03:00
2026-08-09 21:51:33 +03:00

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

ТЗ живут в теле issue (решение владельца 2026-09-10, #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>-*.

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

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

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

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