10 правил для структурированных решений
1. Сначала роутинг, потом разработка
Заголовок раздела «1. Сначала роутинг, потом разработка»forgeplan route "your task" - определяет глубину и конвейер. Не пропускайте этот шаг.
2. Каждое требование: «[Действующее лицо] может [возможность]»
Заголовок раздела «2. Каждое требование: «[Действующее лицо] может [возможность]»»Никаких технических названий в PRD. Описывайте ЧТО, а не КАК. «Пользователь может войти» вместо «React-компонент отображает форму входа».
3. Конвейер = руководство, а не бюрократия
Заголовок раздела «3. Конвейер = руководство, а не бюрократия»Тактическая = только код. Стандартная = PRD → RFC. Не создавайте все 10 типов артефактов для исправления ошибки.
4. Дочерний артефакт ссылается на родительский
Заголовок раздела «4. Дочерний артефакт ссылается на родительский»PRD → Epic, RFC → PRD, ADR → RFC. Всегда прослеживается вверх.
5. Замещайте, не удаляйте
Заголовок раздела «5. Замещайте, не удаляйте»Старые артефакты получают status: superseded. История сохраняется. Никогда не используйте rm.
6. R_eff = min(evidence)
Заголовок раздела «6. R_eff = min(evidence)»Доверие - это слабое звено. Не среднее - минимальное. Одно слепое пятно тянет всё вниз.
7. Доказательства имеют срок действия
Заголовок раздела «7. Доказательства имеют срок действия»valid_until TTL. Истёкшее = 0.1 (просроченное, а не отсутствующее). Периодически перепроверяйте.
8. Сначала Shape, потом Code
Заголовок раздела «8. Сначала Shape, потом Code»Создайте артефакт → заполните ОБЯЗАТЕЛЬНЫЕ разделы → валидируйте → ЗАТЕМ кодируйте. Никаких PRD-заглушек.
9. Тестируйте каждую pub fn
Заголовок раздела «9. Тестируйте каждую pub fn»Пишите тест сразу после функции. Не переходите к следующей функции без теста.
10. Работа не завершена, пока не активирована
Заголовок раздела «10. Работа не завершена, пока не активирована»PRD заполнено + валидировано + доказательство создано + R_eff > 0 + forgeplan activate.