docs: present Shacraft Core and its documentation in English

docs/REQUIREMENTS.md

@@ -1,31 +1,30 @@
-# Исходные требования
+# Original requirements
 
-Источник: переписка [«Динамическое распределение ресурсов»](https://chatgpt.com/share/6aa7eba7-d0e8-83ed-804a-818e7d94cef5), прочитанная с прокруткой 14 сентября 2026 года, и продолжение в Codex. Этот документ сохраняет требования, а не подтверждает реализацию из старой среды.
+Source: the [“Dynamic resource allocation” conversation](https://chatgpt.com/share/6aa7eba7-d0e8-83ed-804a-818e7d94cef5), read in full by scrolling on September 14, 2026, and its continuation in Codex. This document preserves the requirements; it does not validate the implementation from the previous environment.
 
-## Зачем нужен проект
+## Project motivation
 
-У Shacraft два сервера на машине с 8 ГБ RAM: выживание на NeoForge (примерно 300 модов, включая Create) и миниигры на Paper 26.2. Исследование динамического распределения памяти привело к самостоятельному проекту воксельного движка. Перенос существующих NeoForge-модов не является требованием первой версии.
+Shacraft runs two servers on a machine with 8 GB of RAM: survival on NeoForge (about 300 mods, including Create) and minigames on Paper 26.2. Research into dynamic memory allocation led to a standalone voxel engine project. Porting existing NeoForge mods is not a requirement for the first version.
 
-## Обязательные направления
+## Required capabilities
 
-- Самостоятельное открытое ядро на Rust с собственной архитектурой. Низкоуровневые библиотеки допустимы; готовый игровой движок не является основой.
-- Серверная RAM — главный измеряемый критерий. Не выдавать Rust, остановку тиков или битовые палитры сами по себе за доказательство экономии относительно Minecraft.
-- Независимые ядро, тестовый сервер, тестовый клиент и отдельный собственный MCP. Ядро не зависит от графики, сокетов, MCP и лаунчера.
-- Общие неизменяемые карты, независимые изменения экземпляров, выгрузка неактивного состояния, ограничение кэшей, очередей и истории. Один процесс обслуживает несколько миров/арен.
-- Полный базовый каталог блоков, состояний и типов сущностей Minecraft Java 26.2. Нужны формы, коллизии и сохраняемые свойства. Полнота каталога и точность механик проверяются отдельно; полная ванильная симуляция не была согласована как обязательная первая реализация.
-- Импорт Minecraft → Shacraft и обратный экспорт Shacraft → Minecraft. Основной результат — мир; `.schem` для построек — дополнительный формат. Неизвестные данные сохраняются или явно отражаются в отчёте; тихие потери недопустимы.
-- Единая модель расширений: общие определения, серверная и клиентская логика, текстуры, звуки и шейдеры в одном формате пакетов. Сервер объявляет необходимый набор; клиент загружает недостающее, проверяет версии и хеши, использует кэш. Серверные секреты и код с секретами не раздаются клиенту.
-- Политика допустимых клиентских модификаций. Сервер проверяет действия и совместимость пакетов. Контрольная сумма, сообщённая самим клиентом, не доказывает неизменность клиента.
-- В перспективе — запуск через Shacraft Launcher. Существующая инфраструктура является интеграционной целью, не зависимостью ядра.
-- Оригинальные текстуры/звуки/модели Minecraft не включаются в распространяемые файлы. Лицензии контента учитываются отдельно от лицензии кода.
+- An independent open-source Rust core with its own architecture. Low-level libraries are allowed; an existing game engine must not form the foundation.
+- Server RAM is the main measured criterion. Rust, suspended ticks, or bit-packed palettes alone must not be presented as proof of savings relative to Minecraft.
+- Separate core, test server, test client, and a dedicated MCP implementation. The core must not depend on graphics, sockets, MCP, or the launcher.
+- Shared immutable maps, independent changes for each instance, unloading of inactive state, and limits on caches, queues, and history. One process serves multiple worlds/arenas.
+- The complete base catalog of Minecraft Java 26.2 blocks, states, and entity types. Shapes, collisions, and persistent properties are required. Catalog completeness and mechanical accuracy are checked separately; full vanilla simulation was not agreed as a mandatory first implementation.
+- Import from Minecraft to Shacraft and export back from Shacraft to Minecraft. The main output is a world; `.schem` is an additional format for builds. Unknown data must be preserved or explicitly reported; silent loss is unacceptable.
+- A unified extension model: shared definitions, server and client logic, textures, sounds, and shaders in a single package format. The server declares the required set; the client downloads missing resources, checks versions and hashes, and uses a cache. Server secrets and code containing secrets must not be distributed to clients.
+- A policy for permitted client modifications. The server validates actions and package compatibility. A checksum reported by the client itself does not prove that the client is unmodified.
+- Future support for launching through Shacraft Launcher. The existing infrastructure is an integration target, not a core dependency.
+- Original Minecraft textures, sounds, and models must not be included in distributed files. Content licenses must be tracked separately from the code license.
 
-## Качественный MCP
+## A capable MCP implementation
 
-Minecraft Builder MCP — источник опыта, а не сервер, который нужно переименовать. Нужны самостоятельные инструменты осмотра и поиска, пакетного строительства, сущностей и арен, визуальной проверки и диагностики. Основы: общая Control API, ожидаемые ревизии, идентификаторы операций, конфликтобезопасная отмена, ограниченные ответы, история на диске, ограничения нагрузки и авторизация.
+Minecraft Builder MCP is a source of experience, not a server to rename. The project needs its own tools for inspection and search, batch construction, entities and arenas, visual verification, and diagnostics. Foundations: a shared Control API, expected revisions, operation identifiers, conflict-safe undo, bounded responses, on-disk history, load limits, and authorization.
 
-## Что считать фактом
+## What counts as evidence
 
-В старом чате заявлялись 1 196 блоков, 158 типов сущностей, семь тестов и частичная реализация. Эти числа необходимо заново проверить по источникам и локальным результатам. Не переносить их в новый отчёт как установленные факты.
-
-Пожелание «в 2–4 раза меньше RAM» обсуждалось как возможная цель, не достигнутый результат. Сравнивать нужно одинаковые карты, загруженные области, игроков и механики, учитывая весь процесс и необходимые сервисы.
+The previous conversation claimed 1,196 blocks, 158 entity types, seven tests, and a partial implementation. These figures must be checked again against sources and local results. They must not be carried into a new report as established facts.
 
+The wish to use “2–4 times less RAM” was discussed as a possible target, not an achieved result. Comparisons must use the same maps, loaded regions, players, and mechanics, accounting for the entire process and all required services.