Initialize Project Sacrifice backlog and source baseline

docs/BEADS_WORKFLOW.md

@@ -0,0 +1,65 @@
+# Beads: отслеживание выполнения плана
+
+Beads инициализирован локально в `~/tmp/goon-game` поверх embedded Dolt. Remote не настроен: база задач существует только на этой машине.
+
+Источники требований:
+
+- [`DEVELOPMENT_PLAN.md`](DEVELOPMENT_PLAN.md) — утверждённый GDD + TDD + production roadmap;
+- [`CURRENT_ROADMAP.md`](CURRENT_ROADMAP.md) — ближайшая последовательность работ для существующего vertical slice.
+
+## Структура backlog
+
+- master epic: `goon-game-plan`;
+- 16 доменных эпиков `goon-game-e01` … `goon-game-e16` из раздела 62 основного плана;
+- milestones Prototype, Vertical Slice, Production, Alpha, Beta и Release Candidate;
+- предметные задачи с acceptance criteria, приоритетами и зависимостями;
+- уже подтверждённые кодом и QA элементы закрыты с причиной.
+
+На момент инициализации создано 68 beads: 13 закрыты, 4 находятся в работе и 51 открыт. Эти числа нельзя трактовать как точный процент готовности, потому что в базе смешаны эпики, features и задачи разного размера.
+
+Текущий gate — `goon-game-milestone-vslice`. Первая приоритетная незаблокированная задача — `goon-game-bot-framework`.
+
+## Ежедневные команды
+
+Выполнять из `~/tmp/goon-game`:
+
+```sh
+bd status
+bd ready --exclude-type epic
+bd list --all --tree
+```
+
+Посмотреть задачу и её зависимости:
+
+```sh
+bd show goon-game-bot-framework
+bd dep tree goon-game-milestone-vslice
+```
+
+Начать работу:
+
+```sh
+bd update goon-game-bot-framework --claim
+```
+
+Закрыть после выполнения acceptance criteria:
+
+```sh
+bd close goon-game-bot-framework --reason "Acceptance criteria выполнены; проверки зелёные"
+```
+
+После изменения графа:
+
+```sh
+bd dep cycles
+bd export --output .beads/issues.jsonl
+```
+
+## Правила ведения
+
+1. Не закрывать задачу по факту написания кода — сначала выполнить её acceptance criteria и проверки.
+2. Новую найденную работу добавлять дочерней к одному из 16 эпиков и связывать blocking dependency, если она влияет на milestone.
+3. Реальные softlocks и непроходимые уровни заводить как `bug` с P0/P1, а не прятать внутри общего balance task.
+4. Vertical Slice закрывать только после `10/10 passed`, внешнего playtest и остальных зависимостей в его дереве.
+5. Не редактировать `.beads/issues.jsonl` вручную: source of truth — embedded Dolt в `.beads/embeddeddolt`.
+6. Перед передачей базы другой машине отдельно настроить Dolt remote либо передать весь Git/Beads-каталог; сейчас удалённой синхронизации нет.

docs/CURRENT_ROADMAP.md

@@ -0,0 +1,181 @@
+# Текущий roadmap реализации Project Sacrifice
+
+Этот документ описывает ближайшие работы относительно существующего vertical slice. Полный утверждённый GDD + TDD + production roadmap находится в [`DEVELOPMENT_PLAN.md`](DEVELOPMENT_PLAN.md).
+
+Актуально на 18 августа 2026 года.
+
+## 1. Текущее состояние
+
+Проект находится на стадии проверенного vertical slice:
+
+- реализованы 10 последовательных уровней;
+- работают движение, прыжок и мобильное multitouch-управление;
+- смерть не сбрасывает состояние уровня, тела остаются физическими объектами;
+- реализованы шипы, пила, нажимные и временные кнопки, двери, движущиеся платформы, заморозка и электричество;
+- сохраняются прогресс, лучшее время и минимальное число жертв;
+- уровень 5 защищён Android acceptance-тестом: бот проходит реальную игровую сцену примерно за 8,2 секунды с одной смертью и одним оставшимся телом;
+- финальный debug APK проверен на Android 16: установка, холодный запуск, ZIP-структура и v1/v2-подписи корректны.
+
+Главный текущий риск: автоматическая проходимость доказана только для уровня 5. Остальные уровни могут содержать тупики, нестабильную физику или слишком точные действия.
+
+## 2. Принципы разработки
+
+1. Сначала acceptance-тест, затем исправление уровня.
+2. Бот использует те же команды движения и прыжка, что и игрок, без прямого перемещения персонажа или подмены физики.
+3. Новый контент не добавляется, пока текущие 10 уровней не проходят обязательный регрессионный набор.
+4. Изменения физики проверяются на всех уровнях, потому что скорость, импульсы и коллизии являются общими.
+5. Debug APK используется для внутренней проверки; внешняя альфа собирается отдельной release-подписью.
+
+Оценки ниже указаны в рабочих днях для одного Android-разработчика при доступности дизайнера и QA на проверках. Это ориентиры, а не календарные обещания.
+
+## 3. Этапы
+
+### Этап 1. Боты проходимости для уровней 1–10 — P0, 4–6 дней
+
+Задачи:
+
+- выделить общий сценарный движок поверх существующего `LevelPlaytestBot.Driver`;
+- добавить наблюдаемые состояния: положение и скорость игрока, опора, активные сигналы, состояние платформ и дверей;
+- реализовать отдельный маршрут для каждого уровня;
+- выдавать полезную диагностику таймаута: координаты, число смертей, тела, сигналы и последняя выполненная команда;
+- запускать все сценарии одной Gradle-командой на эмуляторе;
+- исключить случайные повторы как способ скрыть нестабильность.
+
+Критерии завершения:
+
+- уровни 1–10 проходят по три последовательных запуска;
+- каждый сценарий использует предусмотренную механику уровня;
+- один полный прогон укладывается в 5 минут;
+- падение теста показывает этап и состояние, на котором бот остановился.
+
+### Этап 2. Исправление уровней и баланс — P0, 4–7 дней
+
+Задачи:
+
+- исправить найденные ботами тупики и нестабильные взаимодействия;
+- увеличить допуски у прыжков и зон срабатывания, не убирая смысл головоломок;
+- проверить, что тела не выталкиваются с плит и не застревают в дверях;
+- выровнять кривую сложности: знакомство, закрепление, комбинация механик;
+- уточнить подсказки и целевые показатели времени/жертв;
+- провести минимум две ручные сессии на каждом уровне.
+
+Критерии завершения:
+
+- `10/10 passed` в автоматическом прогоне;
+- каждый уровень впервые понимается тестировщиком не более чем за три попытки либо содержит достаточную подсказку;
+- restart всегда возвращает чистое начальное состояние;
+- после смерти невозможно потерять обязательный объект без возможности перезапуска.
+
+### Этап 3. Управление, интерфейс и доступность — P1, 3–5 дней
+
+Задачи:
+
+- добавить настройку размера и прозрачности экранных кнопок;
+- улучшить зоны multitouch и визуальную обратную связь на нажатия;
+- добавить короткое обучение без блокирующих длинных окон;
+- доработать экран завершения: время, жертвы, лучший результат и следующая цель;
+- локализовать интерфейс и подсказки на русский и английский;
+- проверить контраст, масштаб текста, вибрацию и режим без вибрации;
+- корректно обрабатывать pause/resume и системную кнопку Back.
+
+Критерии завершения:
+
+- игра полностью управляется на телефоне без внешней клавиатуры;
+- элементы управления не перекрывают игровую информацию на поддерживаемых экранах;
+- смена языка и настроек не сбрасывает прогресс;
+- UI проверен минимум на форматах 16:9, 20:9 и планшете.
+
+### Этап 4. Контентная архитектура и инструменты — P1, 5–8 дней
+
+Задачи:
+
+- перенести описания уровней из Java-констант в валидируемый JSON-формат;
+- добавить загрузчик с проверкой геометрии, сигналов и обязательных объектов;
+- создать простой desktop-скрипт предпросмотра или экспортёр координат;
+- закрепить версию физики и формата уровня;
+- сохранять воспроизводимый журнал команд бота для расследования регрессий.
+
+Критерии завершения:
+
+- геометрию и подсказки уровня можно изменить без перекомпиляции игрового кода;
+- некорректный сигнал, дверь или объект отклоняется валидатором при сборке;
+- все существующие уровни после миграции проходят тех же ботов.
+
+### Этап 5. Художественная и звуковая альфа — P1, 8–15 дней
+
+Задачи:
+
+- утвердить самостоятельный визуальный стиль, не копирующий коммерческий референс;
+- заменить prototype-графику персонажа, опасностей, окружения и интерфейса;
+- добавить анимации движения, смерти, respawn и реакции механизмов;
+- добавить звуки управления, механизмов, результата и фоновую музыку;
+- предусмотреть независимые настройки музыки, эффектов и вибрации;
+- оптимизировать ресурсы для Android.
+
+Критерии завершения:
+
+- все игровые состояния визуально различимы без чтения внутренней логики;
+- звук не является единственным источником обязательной информации;
+- проект сохраняет стабильную частоту кадров на целевых устройствах.
+
+### Этап 6. Техническая стабилизация — P0 перед внешней альфой, 4–7 дней
+
+Задачи:
+
+- проверить Android 8–16 и устройства с 2–4 ГБ памяти;
+- измерить frame time, память, запуск и размер APK;
+- протестировать сворачивание, возврат, блокировку экрана и уничтожение Activity;
+- добавить журналирование необработанных ошибок без персональных данных;
+- проверить обновление приложения поверх предыдущей версии и сохранность прогресса;
+- подготовить release build, отдельный application ID для тестового канала и закрыто хранимый keystore;
+- сформировать APK для прямой установки и AAB для Google Play Internal Testing.
+
+Критерии завершения:
+
+- нет блокирующих падений, ANR и потери прогресса;
+- 95-й перцентиль кадра соответствует целевым 60 FPS либо документированному минимуму 30 FPS на слабых устройствах;
+- release APK/AAB подписан, устанавливается и запускается на чистом устройстве;
+- debug-инструменты не попадают в публичную конфигурацию без необходимости.
+
+### Этап 7. Закрытая альфа — 1–2 итерации по 5–7 дней
+
+Задачи:
+
+- привлечь 20–30 тестировщиков разного игрового опыта;
+- собирать по каждому уровню время, число смертей, restart и точку выхода;
+- разделять дефекты на блокирующие, значимые и косметические;
+- повторно проверять исправления ботами и ручным smoke-тестом;
+- определить уровни с высоким процентом выхода или неверно понятой механикой.
+
+Критерии завершения:
+
+- 90% тестировщиков завершают уровни 1–5 без помощи разработчика;
+- 70% завершают все 10 уровней;
+- отсутствуют открытые блокирующие дефекты;
+- все значимые дефекты имеют решение или явно принятое продуктовое решение.
+
+## 4. Обязательный набор проверок каждого APK
+
+Перед передачей тестировщикам должны выполняться:
+
+1. `testDebugUnitTest` — математика, каталог и валидация уровней;
+2. `lintDebug` — Android Lint без ошибок;
+3. `connectedDebugAndroidTest` — боты уровней 1–10;
+4. проверка APK через `unzip -t`;
+5. проверка package/version через `aapt2 dump badging`;
+6. проверка подписи через `apksigner verify`;
+7. установка поверх предыдущего билда и на чистое устройство;
+8. холодный запуск и проверка crash-буфера;
+9. ручной smoke-тест уровня 1 и одного сложного комбинированного уровня.
+
+## 5. Ближайшая итерация
+
+Следующая итерация ограничивается этапом 1:
+
+- обобщить существующего бота уровня 5;
+- добавить ботов уровней 1–4;
+- затем добавить ботов уровней 6–10;
+- зафиксировать единый отчёт `10/10 passed`;
+- не добавлять уровень 11 и новые механики до выполнения этого критерия.
+
+Результатом итерации должны стать обновлённый исходный проект, проверенный APK и отчёт с длительностью и результатом каждого сценария.