av
3849f084be
Тип goal и индекс ROADMAP.md убраны: цель — зонтик над параллельными направлениями, а у проекта на одного человека список работ линеен. Роадмап при этом наполовину дублировал беклог, а «что уже умеет» отвечают спеки и git log индекса. Секция «Готово» удалена, а не перенесена. Вместо цели — ось «стадия проекта»: build (беклог это план стройки, порядок строк значит зависимость, секция одна) и support (очередь правок, порядок значит важность, секции — полки домена). Стадия объявляется ключом [tasks] stage, меняется командой stage, без неё check отказывает: порядок строк нечем прочитать. Ушли теги goal:/decomposed, поле «Секция», раздел «Завершение», флаги --goal и edit --section. Версия раскладки 2 → 3, перевод проекта расписан записью журнала.
4.9 KiB
✨ feature — снаружи появляется то, чего не было
Задача, после которой наблюдаемое поведение меняется в сторону новой возможности. Отвечает на «что нужно сделать» и пишется глаголом в неопределённой форме.
Общая форма записи (мета, слаг, строка индекса) — task-format.md. Здесь только то, что у этого типа своё.
Схема
| Заголовок отвечает на | что нужно сделать («Печатать поле одним куском кода») |
| Обязательные разделы | Затрагивает, Критерии приёмки |
| Допустимые сверх того | Рамки, Вопросы |
| Поле места | Категория — полка домена беклога |
| Индекс | BACKLOG.md |
| Берётся в работу | да |
Алгоритм
- Проверить, что возможность и правда новая. Поведение расходится с уже
заявленным — это
fix, а неfeature, и требования у него другие. - Назвать границы в разделе
Затрагивает: эндпоинт или команда, таблица и миграция, формат на диске, публичный тип пакета, внешний сервис. Названы границы, а не замысел: «переписать хранилище на новый драйвер» — замысел,таблица points и её миграция— граница. Проверяется вопросом «это можно назвать до того, как решено как делать?». - Написать критерии приёмки — 2–5 проверяемых утверждений списком, у каждого назван оракул. Не «работает корректно», а «повторный прогон даёт тот же отпечаток — оракул: команда сверки».
- Поставить её на место в списке. На стройке место называет зависимость:
move <слаг> --after <шаг, без которого нельзя>. На доработке место в очереди назначает груминг, и конец списка законен. - Проверить, что задача одна. Отвечается всё, но задача не делается одним заходом и не мерджится целиком — это несколько задач, дроби сразу (split.md) и ставь их в списке подряд.
- Реализация — дело конвейера проекта, не этого скилла. Закрывается
close <слаг> --implemented: файл и строка удаляются, суть переезжает вopenspec/specs/и документацию.
Что видит машина, а что человек
Схему типа судит ready на входе в работу: наличие непустого раздела
Затрагивает и число критериев (меньше двух — отказ, больше пяти —
замечание). Наличие оракула проверяется эвристикой — словом «оракул»
в пункте. check этого поимённо не говорит, а считает строкой здоровья
(SKILL.md, «Что механизировано, а что нет»).
Полнота перечня границ машине не видна: границу, которую забыли назвать, она от отсутствующей не отличает. Настоящий оракул от слова «оракул» тоже не отличает. Поэтому в докладе это называется как есть: «проверено число пунктов и наличие границ, годность оракулов и полнота границ — глазами».
Критерии — пол, но расхождение с ними есть дефект критериев. Видишь, что критерии закрыты, а суть задачи не достигнута — правь критерии и возвращай задачу, а не держи невидимое сверх-требование: иначе исполнитель никогда не знает, закончил ли, и мотивирован занижать критерии заранее.