Files
shacraft-core/docs/STATUS.md
T

50 lines
5.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Состояние проекта
Обновлено: 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 и архивы.