BC reqplan-v3

Движок управления полным жизненным циклом проекта. Используется для систематического и процессного выполнения задач программной инженерии. **Когда использовать**: - Пользователь говорит «Помоги мне разработать…», «Реализовать… функцию», «Добавить…», «Написать…» - Пользователь говорит «Помоги мне проанализировать…», «Проверить…», «Посмотри на этот дизайн…» - Пользователь говорит «Ошибка», «Ошибка выполнения», «Исправить… ошибку», «Исправить…» - Пользователь говорит «Помоги мне спланировать…», «Как сделать…», «Какие есть варианты» - Пользователь говорит «Дополнить документацию…», «Добавить документацию…», «Написать документацию…» - Пользователь говорит «Рефакторинг…», «Оптимизировать архитектуру…», «Технический долг…» - Пользователь говорит «Тестировать…», «Написать тесты…», «Покрытие…» - Пользователь вводит команду «/reqplan» - Любые сложные задачи, требующие многошагового планирования, проектирования, реализации и проверки **Когда НЕ использовать**: - Одиночные простые вопросы (например, «Как сортировать список в Python?»), не требующие планирования многошаговых задач - Чистое общение без конкретной цели (без намерения разработки/анализа/исправления) - Чисто информационный запрос (например, «Что нового в React 18?»), не требующий вывода кода - Пользователь только просит просмотреть код, без необходимости анализа, модификации или проектирования - Требования крайне расплывчаты, и пользователь отказывается уточнять, невозможно определить границы конкретной задачи - Цель/область задачи четко определены, требуется только однократное изменение кода, без многоэтапного сотрудничества **Как это работает**: 0. Определение пути проекта (мета-задачи следуют основным правилам, не пропускаются из-за неопределенности пути) 1. Чтение «эстафетной палочки» (.agent/harness/_baton.md) для получения текущего состояния 2. Автоматическое выполнение в соответствии с конечным автоматом: START→ANALYZE→CONFIRM→DESIGN→IMPLEMENT→VERIFY→JUDGE (без необходимости пошаговых команд пользователя) 3. Каждый этап должен проверять выходные данные перед переходом к следующему этапу 4. Все выходные данные передаются через файлы, устные передачи запрещены 5. Пользователь должен подтвердить на этапе CONFIRM, прежде чем продолжить 6. Первая строка каждого ответа должна выводить «Текущее состояние: [имя состояния], следующий шаг: [действие]» 7. В конце каждого шага выполняется проверка цепочки валидации (проверка счетчиков/списков/файлов) для предотвращения ложного завершения **Что это производит**: - Отчет об анализе требований (_analysis.md) - Документ технического проектирования (_design.md) - Сводка реализации (_implementation.md) - Отчет о проверке (_verification.md) - Состояние «эстафетной палочки» (_baton.md) - **Отчет об аудите качества (_quality_audit_analysis.md / _quality_audit_design.md / _quality_audit_implement.md / _quality_audit_verify.md / _quality_audit_judge.md)**

Движок управления полным жизненным циклом проекта.

Как процесс C 57/100 · Есть пробелы — слабые места: результат и критерий готовности, когда включается, входы и предусловия