The spec file solved exactly one problem — proving that a review verdict
was passed on a given text — and created two: docs/specs/README.md
conflicted between parallel tasks and served as a second, stale status
dictionary, and every spec edit cost a commit, a push and a label. The
proof moves into the pipeline.
- review-doc-guard: normalizeIssueBody / issueBodyDigest (CRLF, trailing
whitespace, trailing newlines), the anchor line `Тело issue: <sha256>`,
anchorIssueBodyFrom, and issueBodyChanged — the finding "the spec
changed after a green spec review", judged against the pipeline's own
record in the last green SPEC-REVIEW, never against prose.
- reusableGreenVerdict takes the current digest: reuse (#499) skips the
model entirely, so without this a spec edit between rounds would pass
unseen. Documents without the record (the whole backlog) keep judging
by tree.
- process.yml: the material step reads the body with `gh issue view` in
the same run that fixes the material — the event snapshot describes a
text the reviewer may never see; the digest goes into the anchors, into
reuse and, when it differs, into the reviewer's prompt.
- process-gate: rule 3 judges the text (a `## ТЗ` heading or an AC1) with
the archived file still accepted; adding a new file under docs/specs/
warns — the directory is frozen.
- task-packet reads AC from the body first, the archived file second.
- PROCESS.md §2.3/§5/§7.1/§7.3/§10.5, AGENTS.md and docs/specs/README.md
say so; the index table is gone with the long-standing §7.3 debt.
Mutants: review-anchor-drops-issue-body, review-ignores-changed-spec-body,
reuse-ignores-changed-issue-body, process-gate-requires-spec-file.
Issue: #517
User-Visible: no
ТЗ живут в теле 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 ТЗ должно прямо зафиксировать отсутствие пользовательских изменений и перечислить технические доказательства безопасного поведения.
Codex
156835c048