ТЗ, у которого есть процент готовности
Техническое задание по фазам и пунктам с вечными номерами. У каждого пункта три шага: согласован, выполнен, проверен другим участником. На странице «ТЗ» вместо «вроде бы всё сделали» вы видите полосу «готово 7 из 11» и точно знаете, какие два пункта ждут проверки.
Знакомая ситуация
Требования живут в REQUIREMENTS.md. Через две недели один агент правит пункт, вы этого не замечаете, а другой агент реализует старую версию. Что готово, что проверено, что вообще согласовано, никто точно не знает, и на каждый вопрос «где мы?» отвечает человек, который перечитывает файл.
Модуль ТЗ превращает требования в объекты со статусами. Вы согласуете текст, назначаете исполнителей и смотрите на полосу готовности. Агенты берут пункты через cct и отмечают выполнение, а проверяет всегда кто‑то другой.
Как это устроено
Фазы и пункты с вечными номерами
ТЗ состоит из полей «Какую проблему решаем» и «Общая информация», фаз с целью и пунктов. Номер пункта выдаёт программа: 1, 2, 3.1. Он не меняется и не используется повторно, даже если пункт исключён. На номер можно ссылаться в задачах, документах и переписке через год.
Версия текста и согласование
Каждая правка текста повышает версию пункта. Согласование привязано к версии: поправили текст, и старое согласование устарело, пункт снова требует решения. Два участника правят один пункт: конфликт разрешается явно, с показом текущего текста, а не затиранием.
Три шага у каждого пункта
Согласование ставит автор, второй редактор или владелец. Выполнение отмечает исполнитель. Проверку ставит участник, который не является исполнителем этого пункта: программа проверяет это при каждой попытке. Пункт готов, когда все три отметки актуальны для текущей версии текста.
Зависимости
Пункт B зависит от пункта A: B нельзя проверить, пока A не готов. Граф зависимостей читается командой и показывает, что реально блокирует завершение.
Статусы ТЗ
«Черновик» обсуждается и не выполняется. «В работе» включается только тогда, когда у каждого пункта есть исполнитель. «Завершено» доступно только для чтения, пока ТЗ не вернут в работу. «В архиве» убирает из списка, ничего не удаляя. Владелец может завершить ТЗ с незавершёнными пунктами только с причиной, которая остаётся в истории.
Снимки на ревью
Неизменяемая копия состояния ТЗ на момент времени. Рецензенты, люди и агенты, читают один и тот же текст и ссылаются на один снимок, а не на «то, что было вчера».
Журнал событий и история
Каждое изменение получает номер события. История текста пункта, сравнение версий и возврат старого текста новой версией. Кто согласовал, кто выполнил, кто проверил, с какой причиной: всё записано от имени токена, подделать нельзя.
Связь с задачами и документами
Пункт ТЗ связывается с задачей доски: в задаче видна строка «↔ ТЗ», в пункте видна задача. Задача описывает работу, пункт описывает требуемый результат, и они не меняют статусы друг друга тайком.
Как это выглядит для агента
Backend ❯ cct tz remaining TZ-AUTH --mine
2.3 v4 согласован · исполнитель Backend · зависимости готовы
3.1 v2 нужно согласовать
Backend ❯ cct tz context TZ-AUTH 2.3
… текст пункта v4, критерий приёмки, задача TASK-124, предпосылки 1.2 и 2.1 готовы …
Backend ❯ cct tz done TZ-AUTH 2.3
OK · 2.3 выполнено (Backend), ждёт проверки
Reviewer ❯ cct tz check TZ-AUTH 2.3 --expect-verification-state sha256:9f3c…
OK · 2.3 проверено (Reviewer)
Reviewer ❯ cct tz check TZ-AUTH 2.4 --expect-verification-state sha256:71ab…
tz_rule: verifier is an assignee of this itemСколько контекста это экономит
Агенту, который берёт пункт в работу, не нужно всё ТЗ. Ему нужен текст пункта, критерий приёмки, предпосылки и связанная задача. Команда cct tz context собирает ровно это, на одном номере события, так что все части пакета согласованы между собой.
cct tz context для одного пункта: текст, критерии, предпосылки, задача, состояние проверкиcct tz progress: сводка готовности по всему ТЗ для владельца или координатораЗамер 13 октября 2026 на реальном ТЗ в базе программы. Экономия около 99 % против чтения файла требований целиком; для ТЗ обычного размера в 30–100 КБ это примерно 90–95 %.
Что это даёт
- Вы уходите от md‑требований. Текст живёт в базе с версиями, а не в файле, который каждый правит по‑своему.
- Вы видите готовность, а не слышите о ней. Полоса по пунктам, содержание по фазам с «готово 1 из 4», переключатель «Только то, что осталось».
- Независимая проверка встроена, а не договорена. Правило «проверяет не исполнитель» выполняет программа.
- История решений сохраняется. Почему пункт исключён, кто и когда его согласовал, что было в предыдущей версии: всё на месте через полгода.
- Контекст агента не тратится на чужие пункты. Пакет одного пункта вместо всего документа, и проверка привязана к точному состоянию, а не к тому, что агент помнит.
В сравнении с обычным терминалом
| Ситуация | md‑файл в репозитории | Модуль ТЗ |
|---|---|---|
| Что готово? | Перечитать файл и спросить всех | Полоса «готово 7 из 11» и список оставшегося |
| Агент поправил требование | Никто не заметил | Версия выросла, согласование устарело, пункт требует решения |
| Кто проверял? | Тот же, кто делал, если проверял вообще | Другой участник, иначе программа откажет |
| Ссылка на требование | Строка файла, которая завтра сдвинется | Вечный номер 2.3 |
| Агент берёт пункт в работу | Читает файл требований целиком | Пакет контекста одного пункта: 4,4 КБ вместо 806 КБ |