shacraft-core/docs/STATUS.md

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

Обновлено: 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, VERIFICATION, 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 и архивы.