# Состояние проекта

Обновлено: 2026-09-14. Рабочая папка: `/home/emil/Desktop/shacraft-core`.

## Завершено: планирование и первый этап хранения

План сохранён **до реализации**, отдельным Git-коммитом `ddfcef2`. Исходники старой облачной среды не восстановлены и не использованы как доказательство работы новой реализации.

Работают две crate:

- `shacraft-core`: versioned codec секций 16³ (uniform/palette/dense), компактный LRU, долговечный реестр, SQLite/WAL/FULL, блокировка второго писателя, неизменяемые снимки, независимые экземпляры, атомарные edit, revision/idempotency, undo/reset и явная уборка недостижимых blobs.
- `shacraft-tools`: локальная JSON-lines сессия для тестирования API, demo, stats и воспроизводимый storage benchmark. Это не MCP и не игровой сервер.

Проверено на Linux x86_64 с Rust 1.96.0:

- `cargo fmt` и Clippy с запретом предупреждений.
- 29 Rust-тестов: 11 codec, 8 black-box контрактов, 10 хранения.
- Отдельные процессы: 80 подтверждённых правок → SIGKILL → восстановление реестра/данных/replay; прерывание транзакции на 32768 ячеек → отсутствие частичного состояния → безопасный повтор.
- Вытеснение различных секций при превышении кэша; однородная секция остаётся компактной и в RAM.
- Release demo и синтетический benchmark: 256 секций, 100 независимых экземпляров, чтение сверх кэша, edit/reset каждого экземпляра.

Команды и результаты: [DEVELOPMENT](DEVELOPMENT.md), [VERIFICATION](VERIFICATION.md), `docs/verification/`.

## Следующий этап: сервер и тестовый клиент

1. Добавить crate сервера с игровым циклом отдельно от долговечных редакторских транзакций. Не выполнять SQL/FULL commit каждого игрового ввода.
2. Уточнить протокол resync, подписку без разрыва между снимком и изменениями, переключение миров и лимиты очередей.
3. Реализовать серверные движение/коллизии/взаимодействия и минимальный WebGL2-клиент по решению D003.
4. Пройти сценарий двух клиентов с общими блоками и независимыми мирами.
5. Затем подключить собственный MCP через общий Control API, полный каталог и конвертер согласно PLAN.

## Ограничения первого этапа

- Полный MVP ещё не завершён. Нет игрового сервера, графического клиента, MCP, каталога 26.2, конвертера, системы исполняемых модулей и миниигры.
- Undo консервативный: только целевая правка на текущей ревизии, без последующих операций. Каждый новый успешный edit, включая no-op, повышает ревизию. Retry не повышает.
- История остаётся на диске без автоматического удаления. GC ограничивает число удалённых blobs, но не время сканирования. Он не удаляет историю/снимки и не уменьшает физический файл через VACUUM.
- Реестр строк находится в RAM: максимум 262144 состояния по 512 ASCII-байт. Кэш секций не является лимитом всей памяти процесса. SQLite page-cache budget — настройка движка, не жёсткий RSS-лимит.
- Benchmark проверяет хранение, не игроков/тики/полный каталог и не сравнительную экономию относительно Paper.
- SIGKILL не имитирует отключение питания и отказы накопителя. Платформы вне Linux пока не проверены.
- Продакшен, существующий лаунчер и удалённые репозитории не изменялись.

## Правила продолжения

- Перед работой прочитать REQUIREMENTS, PLAN, DECISIONS, CONTRACT и этот файл.
- Новые результаты подтверждать командами, тестами или видимым поведением; старый облачный отчёт не использовать как доказательство.
- Не помечать весь MVP готовым по завершению одного этапа.
- Отмечать точные ограничения контента, конвертера, клиента, модулей и безопасности.
- Команды запуска и проверки сохранять в репозитории; изменения коммитить в локальный Git после проверки.
- Не помещать токены, данные реальных игроков и проприетарные ассеты в Git и архивы.