5.7 KiB
5.7 KiB
Промпт исполнителю плана исправлений
Скопируйте текст ниже в задачу нейросети, имеющей доступ к репозиторию.
Работай в репозитории RF4 Spotter. Реализуй план docs/RECOVERY_PLAN_2026-09-10.md, а не только предложи изменения.
Сначала прочитай полностью применимые AGENTS.md, RECOVERY_PLAN_2026-09-10.md, ROADMAP.md, REGRESSION_AUDIT_2026-09-09.md, REGRESSION_FIXES_REPORT.md и README.md. Проверь git status и актуальную ревизию. План A01–A13 имеет приоритет над прежней очередью R/T/D/U/S. Старый fixes report противоречив: не принимай отметку «исправлено» за доказательство.
Начни с A01. Затем выполняй A02–A13 по порядку. Для каждого пункта:
1. Подтверди дефект на текущем коде. Если уже исправлен, предъяви проверку и не переписывай работающий код.
2. Найди первопричину и все связанные потребители, конфигурации, миграции и контракты.
3. Добавь небольшой regression case, воспроизводящий дефект до исправления; для требований безопасности проверь и отрицательный сценарий.
4. Исправь первопричину и проверь критерии приёмки из плана, включая соседние сценарии.
5. Обнови статус в плане, ROADMAP/README при изменении поведения и fixes report. Закрывай пункт только при выполнении всех критериев; частичное выполнение оставляй открытым с остатком.
6. Сделай отдельный осмысленный коммит только своих относящихся к пункту изменений. Не коммить чужие файлы, секреты или IDE-настройки.
Обязательные ограничения:
- Сохраняй Astro + FastAPI + PostgreSQL; никаких Next.js/Vinext, смены стека, несвязанных рефакторингов и массовых обновлений зависимостей.
- Сохраняй чужую работу. Не удаляй данные/volumes, не сбрасывай git и cooldown. Не выполняй деплой, push или внешние публикации без отдельного поручения.
- Все тесты парсеров — fixtures/mock transport, без реального scraping. Интервал источников минимум 30 минут на площадку суммарно по endpoint, процессам и способам запуска; ошибки тоже расходуют интервал.
- Источник каждой записи и всех составляющих агрегата обязателен. Неполные данные публикуются с явной пометкой, неизвестное время не подменяется известным.
- Не ослабляй assertions, не отключай проверки, не скрывай ошибки через || true или успешные пустые ответы. Не устраняй цикл readiness безусловно зелёным healthcheck: оставь достоверные отдельные сигналы отказов.
- Сборка Astro не доказывает корректность runtime JSON. Проверь все API-потребители и SSR, данные/пустоту/ошибку, три страницы пагинации и сохранение фильтров.
- UI проверь desktop/mobile, с JS и без него, клавиатурой, zoom и длинными названиями. Для ошибок согласуй HTTP, noindex, cache и structured data.
- Proxy trust и rate limit проверяй по реальной цепочке Caddy → Astro → API, не только unit-тестом helper.
- Docker запускай для необходимых инфраструктурных проверок и общей изолированной приёмки; не перезапускай весь стек после каждой правки.
- Не приписывай себе непроведённые проверки. Указывай точные команды, результаты, skip и ограничения среды. Если проверка заблокирована, пункт не считается принятым.
Не останавливайся на новом плане: начни реализацию A01 и продолжай по согласованному порядку, пока можешь безопасно работать. Если нужны новые полномочия или существенный выбор владельца, объясни конкретный блокер и спроси, не додумывай разрешение.
После каждого пакета кратко сообщай: причина → исправление → доказательство проверки → коммит → остаток → следующий пункт. В конце сверь все A01–A13 с критериями, а не только с зелёным тестовым прогоном.