Separate historical engine research from current implementation evidence

docs/IMPLEMENTATION.md

@@ -206,3 +206,25 @@ The final build-service review also reproduced a publication defect: an invalid
 custom-field default can pass the build stage's shallow schema check before the
 Editor rejects it. Full schema validation before publishing `last_build.json` is the
 next bounded correction; checkpoint 4 does not claim this gate is already complete.
+
+
+## Acceptance corrections after checkpoint 4
+
+Gameplay schema publication now uses the same complete metadata validation as the
+Editor, before either the Player generation or `last_build.json` is published.
+A native fixture drives the real BuildService with valid custom schema v2 and twelve
+invalid manifests, checking that the previous binary, schema, manifest and pointer
+remain unchanged. The focused authoring/process/schema/Session/MCP suite passed 5/5.
+An authoring-disabled Player configuration still builds without editor services.
+
+Windows native checks passed for checkpoint 4 (`45bc352`) and `afd773f`, including
+the previous long-path regression. The full graphics runner also passed its Vulkan
+1.3 device probe after registering the pinned software ICD on the disposable elevated
+runner. Full Windows graphics and export acceptance is still in progress; a successful
+probe alone does not close that gate.
+
+The final audit identified additional bounded work: source/dependency freshness in
+the Assets panel, scrolling keyboard focus into view, delivery of explicit gameplay
+schema migrations, GPU pass labels, and wiring optional ImGui diagnostics. These
+remain under implementation and verification; the research map now links current
+implementation evidence instead of claiming the engine has not been started.

docs/PUBLICATION.md

@@ -4,9 +4,9 @@
 
 ## Что публикуется
 
-Собственные архитектурные описания и планы Faset, исследования со ссылками на первичные источники, манифест исследованных snapshots и исходники локальной карты документации. Утверждённый план не выдаётся за готовую реализацию движка.
+Собственный C++-код Faset, тесты, примеры игр, Blender add-on, пользовательский Manual, архитектура и план, исследования со ссылками на первичные источники, манифест исследованных snapshots и исходники локальной карты документации. Выбранные воспроизводимые отчёты и измерения публикуются в docs/validation с указанием исходного состояния и ограничений. Готовность MVP определяется критериями PLAN, а не наличием отдельных подсистем.
 
-Сторонние source checkouts, локальные индексы graphify, node_modules, dist, логи, credentials и пользовательские рабочие каталоги не входят в публикацию. Браузерный source viewer предназначен для локального использования и не является сервисом публичной раздачи стороннего кода.
+Сторонние source checkouts, локальные индексы graphify, node_modules, dist, временные логи, credentials и пользовательские рабочие каталоги не входят в публикацию. Браузерный source viewer предназначен для локального использования и не является сервисом публичной раздачи стороннего кода.
 
 Исходники Unreal требуют соответствующего доступа Epic; публикация ссылки на commit не предоставляет этот доступ. У Godot, UnityCsReference, Blender и остальных источников остаются их собственные условия. Подробности — в [DEPENDENCIES.md](DEPENDENCIES.md).
 
@@ -16,6 +16,6 @@
 
 ## Проверки публикации
 
-Проверяются состав Git, отсутствие локальных секретов и чужих source trees, внутренние ссылки, source pins, запуск/сборка карты и границы её файлового API. Проверки карты и документов не являются тестами будущего C++-движка, Blender integration или графической производительности.
+Проверяются состав Git, отсутствие локальных секретов и чужих source trees, внутренние ссылки, source pins, запуск/сборка карты и границы её файлового API. Проверки карты и документов не заменяют тесты C++-движка, Blender integration или графической производительности. Native CI, GPU-проверки, автономные exports и приёмочные сценарии описаны отдельно в [журнале реализации](IMPLEMENTATION.md) и [результатах проверок](validation/README.md).
 
 Локальные source paths в манифесте являются необязательными относительными подсказками. Публичные Markdown-ссылки на исходники закреплены на upstream commits и не зависят от имени пользователя или расположения Desktop.

docs/studies/07-unreal-graphics-source-study.md

@@ -20,7 +20,7 @@
 6. **Более богатые материалы.** Из Substrate взять ограниченные классы сложности и обработку по тайлам; из glints — фильтруемое распределение микробликов. Небольшой фиксированный clear-coat/двухслойный набор часто разумнее произвольного графа BSDF.
 7. **Большие наборы текстур.** Virtual Texturing полезна, когда именно residency и объём текстур стали проблемой. Стриминг целых mip-уровней проще; переход на страницы имеет смысл по измеренному рабочему набору.
 
-## Принятый план Faset — реализация ещё не начата
+## Принятый план Faset — продвинутая графика после MVP
 
 Решения обновлены 18 сентября 2026. Подробные критерии продукта — в [PLAN.md](../../PLAN.md), технические границы — в [архитектуре](../ARCHITECTURE.md). Результаты чтения UE ниже сохраняются; они не означают, что эти системы уже есть в Faset, входят в MVP или обязательно будут воспроизведены целиком.
 

docs/studies/12-mcp-and-blender-integration.md

@@ -2,7 +2,7 @@
 
 **Принято 18.09.2026: редактор, MCP и интеграции пользуются одним сервисом авторских данных.** Сам сервис умеет работать без окон; GUI добавляет выделение, gizmos и preview, MCP — типизированный доступ для агента, Blender — подготовку и обновление ассетов. Пользователь должен свободно переходить между этими способами, сохраняя историю, идентификаторы, проверки и результат.
 
-Это принятый проект архитектуры, не реализованная интеграция; код движка ещё не создан. Актуальные решения — в [архитектуре](../ARCHITECTURE.md), этапы и критерии готовности — в [PLAN.md](../../PLAN.md). **MCP существует только в Editor/headless editor services: authoring, import, build, Play/Stop и журналы редактора. Никаких runtime inspection/mutation, world/session tools, MCP в Player, экспортной игре или SchemaExporter.** Он дополняет [UX редактора](./02-editor-ux.md), [разбор Godot](./08-godot-ux-source-study.md), [паттерны Blender](./10-blender-editor-patterns.md) и [ECS](./11-ecs-and-ergonomics.md). Исходники сверены в прежних commits: Godot `9c776068d6ed23acd0c78bfe534272d1d2a3a619`, Blender `28d47268bddcb9dc69143f0e2d9410969da16311`. Документация проверена 17.09.2026; для MCP зафиксирована редакция **2026-07-28**, поддержка которой конкретным клиентом не предполагается автоматически.
+Это исследовательский проект контрактов от 17–18.09.2026. Реализованный MVP-профиль, точные имена tools и проверки описаны в [Manual MCP](../manual/editor/mcp.md), [Manual ресурсов](../manual/editor/assets.md) и [журнале реализации](../IMPLEMENTATION.md). Более широкие API-примеры ниже не являются обещанием текущей реализации. Актуальные решения — в [архитектуре](../ARCHITECTURE.md), этапы и критерии готовности — в [PLAN.md](../../PLAN.md). **MCP существует только в Editor/headless editor services: authoring, import, build, Play/Stop и журналы редактора. Никаких runtime inspection/mutation, world/session tools, MCP в Player, экспортной игре или SchemaExporter.** Он дополняет [UX редактора](./02-editor-ux.md), [разбор Godot](./08-godot-ux-source-study.md), [паттерны Blender](./10-blender-editor-patterns.md) и [ECS](./11-ecs-and-ergonomics.md). Исходники сверены в прежних commits: Godot `9c776068d6ed23acd0c78bfe534272d1d2a3a619`, Blender `28d47268bddcb9dc69143f0e2d9410969da16311`. Документация проверена 17.09.2026; для MCP зафиксирована редакция **2026-07-28**, поддержка которой конкретным клиентом не предполагается автоматически.
 
 ## 1. AuthoringService как самостоятельное ядро редактора
 
@@ -76,7 +76,7 @@ Manifest хранится вместе с authoring-данными в Git: `asse
 
 ## 8. Контракт формата и следующий шаг live link
 
-Профиль импорта должен последовательно покрыть triangle meshes, UV/нормали/tangents и metal-rough PBR; skinning, clips и morph targets вводятся на соответствующих этапах [плана](../../PLAN.md). Поддержка пока не реализована и не проверена. Процедурные node graphs и Geometry Nodes не превращаются в engine shaders: нужен bake/evaluated mesh и отчёт о потерях. glTF описывает свою систему материалов, а Blender exporter распознаёт поддержанные узлы. [Blender: glTF materials](https://docs.blender.org/manual/en/4.0/addons/import_export/scene_gltf2.html).
+Профиль импорта должен последовательно покрыть triangle meshes, UV/нормали/tangents и metal-rough PBR; skinning, clips и morph targets вводятся на соответствующих этапах [плана](../../PLAN.md). Текущее проверенное статическое подмножество перечислено в [Manual ресурсов](../manual/editor/assets.md); skinning, clips и morph targets остаются за пределами MVP. Процедурные node graphs и Geometry Nodes не превращаются в engine shaders: нужен bake/evaluated mesh и отчёт о потерях. glTF описывает свою систему материалов, а Blender exporter распознаёт поддержанные узлы. [Blender: glTF materials](https://docs.blender.org/manual/en/4.0/addons/import_export/scene_gltf2.html).
 
 glTF использует правую систему координат, Y-up и метры; наши engine-конвенции фиксируются в recipe, с преобразованием ровно на одной границе. Проверять root transforms, nonuniform/negative scale, winding и tangent handedness. Имена glTF не гарантируют уникальность. [glTF 2.0: координаты и структуры](https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html).
 

docs/studies/13-build-pipeline-and-stack.md

@@ -2,7 +2,7 @@
 
 **Принято 18.09.2026:** C++ core/gameplay, затем Lua отдельным модулем (необязателен для конкретной игры); EnTT; собственный retained C++ editor UI с декларативными layout/styles и тёмной темой, ImGui для debug; Vulkan 1.3 и собственный RenderGraph, Slang/совместимый HLSL; SDL3 за API Faset; CMake+Ninja, Clang Linux и clang-cl Windows. Gameplay — статическая библиотека в Player dev/release, Editor plugins — DLL/SO под точный SDK с restart. Сравнение альтернатив ниже — **история исследования**, не открытый выбор. Канон — [архитектура](../ARCHITECTURE.md), этапы — [PLAN.md](../../PLAN.md). MCP только в Editor/headless editor services, без runtime inspection/mutation и без MCP в Player/SchemaExporter.
 
-Исходные требования: Linux и Windows desktop, игры 2D и 3D, продвинутая графика, полноценное ручное редактирование и управление через MCP. Текущие рекомендации ниже описывают принятый проект; pipeline и движок ещё не реализованы. Исторические варианты помечены отдельно. Проверка источников: 17 сентября 2026. Локальный Godot: `9c776068d6ed23acd0c78bfe534272d1d2a3a619`, версия дерева 4.8-dev; официальные текущие страницы Unity показывают 6.6. Исследованы тела desktop exporter, сбор зависимостей, remap импортированных ресурсов, кэш преобразования, запись PCK и конфигурация editor/player. Unity здесь изучен по документации, без утверждения о просмотре закрытой реализации.
+Исходные требования: Linux и Windows desktop, игры 2D и 3D, продвинутая графика, полноценное ручное редактирование и управление через MCP. Рекомендации ниже фиксируют проект на этапе исследования; текущая реализация pipeline и её проверки описаны в [Manual экспорта](../manual/editor/export.md) и [журнале реализации](../IMPLEMENTATION.md). Исторические варианты помечены отдельно. Проверка источников: 17 сентября 2026. Локальный Godot: `9c776068d6ed23acd0c78bfe534272d1d2a3a619`, версия дерева 4.8-dev; официальные текущие страницы Unity показывают 6.6. Исследованы тела desktop exporter, сбор зависимостей, remap импортированных ресурсов, кэш преобразования, запись PCK и конфигурация editor/player. Unity здесь изучен по документации, без утверждения о просмотре закрытой реализации.
 
 ## Что именно должна делать кнопка Build
 

docs/studies/14-engine-blueprint.md

@@ -2,13 +2,13 @@
 
 **Название проекта — Faset Engine. Синхронизация решений: 18.09.2026.** Каноническая архитектура — [ARCHITECTURE.md](../ARCHITECTURE.md), последовательность до и после MVP — [PLAN.md](../../PLAN.md). Этот отчёт сохраняет исследовательские аргументы и обновлённые принятые решения. Прежние альтернативы отмечены **superseded**; факты о чужих движках не означают, что соответствующие возможности реализованы в Faset.
 
-Дата: 17 сентября 2026. Цель — новый движок для **Linux и Windows, десктопных 2D/3D-игр**, одинаково удобный при ручной работе и через **MCP**, с интеграцией как минимум с **Blender**. Это исследовательская основа реализации. Код нового движка ещё не создавался; ниже принятые архитектурные правила отделены от экспериментальных графических направлений и деталей будущих прототипов.
+Дата: 17 сентября 2026. Цель — новый движок для **Linux и Windows, десктопных 2D/3D-игр**, одинаково удобный при ручной работе и через **MCP**, с интеграцией как минимум с **Blender**. Это исследовательская основа реализации. На момент первоначального исследования код нового движка ещё не создавался; текущая реализация описана в [журнале](../IMPLEMENTATION.md), ниже принятые архитектурные правила отделены от экспериментальных графических направлений и деталей будущих прототипов.
 
 ## Уточнения после обсуждения исследования
 
-**Подтверждённый выбор пользователя: Box2D для 2D-физики, Box3D для 3D-физики.** Под Box3D имеется в виду [erincatto/box3d](https://github.com/erincatto/box3d), анонсированный Erin Catto 30 июня 2026. Это отдельная 3D-библиотека с C API и реализацией на C17; репозиторий указывает поддержку Windows и Linux. [Анонс](https://box2d.org/posts/2026/06/announcing-box3d/), [Box2D overview](https://box2d.org/documentation/). Версии и commits зависимостей пока не выбраны, интеграция и собственные физические тесты не выполнялись.
+**Подтверждённый выбор пользователя: Box2D для 2D-физики, Box3D для 3D-физики.** Под Box3D имеется в виду [erincatto/box3d](https://github.com/erincatto/box3d), анонсированный Erin Catto 30 июня 2026. Это отдельная 3D-библиотека с C API и реализацией на C17; репозиторий указывает поддержку Windows и Linux. [Анонс](https://box2d.org/posts/2026/06/announcing-box3d/), [Box2D overview](https://box2d.org/documentation/). На момент исследования версии ещё не выбирались и собственные физические тесты не выполнялись. Теперь версии закреплены в [dependency lock](../../dependencies.lock.json), а результаты интеграции записаны в [журнале реализации](../IMPLEMENTATION.md).
 
-Принятый принцип интеграции: отдельные PhysicsWorld2D/PhysicsWorld3D, компоненты RigidBody2D/3D и Collider2D/3D, единые правила регистрации, идентичности, Inspector и диагностики. Миры 2D и 3D не сталкиваются автоматически друг с другом. Физика получает команды перед фиксированным шагом; после завершения шага движок переносит результаты и события в runtime. Для динамического тела физика владеет рассчитанным transform; runtime teleport и управление кинематическим телом — отдельные операции. События связываются с entity через проверяемые handles. Названия API предварительны; адаптеры ещё не реализованы.
+Принятый принцип интеграции: отдельные PhysicsWorld2D/PhysicsWorld3D, компоненты RigidBody2D/3D и Collider2D/3D, единые правила регистрации, идентичности, Inspector и диагностики. Миры 2D и 3D не сталкиваются автоматически друг с другом. Физика получает команды перед фиксированным шагом; после завершения шага движок переносит результаты и события в runtime. Для динамического тела физика владеет рассчитанным transform; runtime teleport и управление кинематическим телом — отдельные операции. События связываются с entity через проверяемые handles. Названия API в этом исследовательском описании предварительны; фактический API адаптеров и gameplay описан в [Manual](../manual/scripting/api.md).
 
 **Решение от 18.09.2026: сначала ядро и игровая логика на C++, затем добавляем Lua отдельным модулем. Его будущая реализация принята, использование конкретной игрой необязательно.** Игра на C++ не должна зависеть от Lua; точный Lua API и срок этапа уточняются по [плану](../../PLAN.md). Python и C# сохраняются в сравнении как ранее рассмотренные альтернативы. Каноническое решение записано в [архитектуре](../ARCHITECTURE.md).
 

docs/studies/15-renderer-implementation-notes.md

@@ -129,4 +129,4 @@ D3D12 подтверждает переносимость самой идеи,
 
 Главное дополнение к 07: фиксированные CPU draw templates совместимы с GPU instance visibility; velocity target не требуется для первого HZB; history extraction — output/lifetime контракт; camera reset заменяет весь previous-view набор; indirect и vertex reads требуют разных зависимостей; неполный Main HZB может быть начальным вариантом истории с измеряемой ценой в эффективности.
 
-Прочитаны тела UE `FInstanceCullingContext` создания buffers/submission, `InstanceCullBuildInstanceIdBufferCS`, `ClearIndirectArgInstanceCountCS`, Nanite `FBoxCull::HZB`, `WriteOccludedInstance` и main/HZB/post orchestration; `BuildHZB`, `HZBBuildCS` и HZB parameter helpers; previous-view setup/reset в SceneVisibility; RDG import/extraction, barrier compile/collection и resource reference handling. В Godot — indirect draw validation/tracking и named render-buffer creation/configuration/cleanup. В интернете — официальные Vulkan indirect/features/synchronization и Microsoft D3D12 indirect signatures. Формат/driver capability matrix для конкретных машин и runtime-поведение пока не проверялись.
+Прочитаны тела UE `FInstanceCullingContext` создания buffers/submission, `InstanceCullBuildInstanceIdBufferCS`, `ClearIndirectArgInstanceCountCS`, Nanite `FBoxCull::HZB`, `WriteOccludedInstance` и main/HZB/post orchestration; `BuildHZB`, `HZBBuildCS` и HZB parameter helpers; previous-view setup/reset в SceneVisibility; RDG import/extraction, barrier compile/collection и resource reference handling. В Godot — indirect draw validation/tracking и named render-buffer creation/configuration/cleanup. В интернете — официальные Vulkan indirect/features/synchronization и Microsoft D3D12 indirect signatures. В этом исследовании не проверялись формат/driver capability matrix и runtime-поведение. Позднейшие проверки базового Faset renderer публикуются отдельно в [docs/validation](../validation/README.md); они не подтверждают GPU-driven техники этого раздела.

docs/studies/17-asset-pipeline-and-blender-roundtrip.md

@@ -139,4 +139,4 @@ Collider recipe включает source output, 2D projection/3D local frame, е
 
 Новые относительно предыдущего обзора выводы: UID файла недостаточен для rename частей; UUID property наследуется при duplicate; Actions и outputs могут иметь соответствие многие-ко-многим; зависимости source/artifact/settings нужно различать; публикация source и активация imported generation — две разные точки; physics geometry имеет отдельную идентичность, версию и срок жизни.
 
-**Охват источников.** Локальные тела Godot `9c776068d6ed23acd0c78bfe534272d1d2a3a619`, Blender `28d47268bddcb9dc69143f0e2d9410969da16311`, UnityCsReference `6b50e5544f6efcca1f44dbace3d1778b465ac6d0` соответствуют [манифесту](source-manifest.json). Недостающие пять Blender exporter files прочитаны из official raw source того же commit без расширения sparse checkout. Дополнительно прочитаны отдельные Box2D files commit `77619f4f7baebe5117a2e3ddc3ac8c404e82d243` и Box3D files/docs commit `f555ee42084e0b43cbffa863f40bff8117c08896`; это исследовательские pins, не выбор версий Faset. Их permalink lines сверены по скачанным файлам. Веб-сверка: спецификация glTF 2.0, Unity 6.0 API, Box2D collision documentation; Blender Manual 4.0 использован только для общего material workflow, текущие механизмы сверены по source 5.3 alpha. Native asset database Unity, весь exporter, автоматическая convex decomposition и переносимость cooked binaries не исследованы полностью. Производительность и roundtrip пока не измерялись.
+**Охват источников.** Локальные тела Godot `9c776068d6ed23acd0c78bfe534272d1d2a3a619`, Blender `28d47268bddcb9dc69143f0e2d9410969da16311`, UnityCsReference `6b50e5544f6efcca1f44dbace3d1778b465ac6d0` соответствуют [манифесту](source-manifest.json). Недостающие пять Blender exporter files прочитаны из official raw source того же commit без расширения sparse checkout. Дополнительно прочитаны отдельные Box2D files commit `77619f4f7baebe5117a2e3ddc3ac8c404e82d243` и Box3D files/docs commit `f555ee42084e0b43cbffa863f40bff8117c08896`; это исследовательские pins, не выбор версий Faset. Их permalink lines сверены по скачанным файлам. Веб-сверка: спецификация glTF 2.0, Unity 6.0 API, Box2D collision documentation; Blender Manual 4.0 использован только для общего material workflow, текущие механизмы сверены по source 5.3 alpha. Native asset database Unity, весь exporter, автоматическая convex decomposition и переносимость cooked binaries не исследованы полностью. В рамках этого статического исследования производительность и roundtrip не измерялись. Позднейшие проверки собственного MVP-профиля Faset с Blender опубликованы в [результатах проверок](../validation/README.md).

docs/studies/18-build-cook-and-delivery.md

@@ -1,6 +1,6 @@
 # 18. Сборка, cook и доставка: как сделать результат объяснимым
 
-Дата исследования: 17.09.2026; актуализация решений: **18.09.2026**. Дополнение к [исследованию стеков](13-build-pipeline-and-stack.md). **Приняты** CMake+Ninja, Clang Linux/clang-cl Windows, C++ core/gameplay первым и Lua следующим модулем. Gameplay статически линкуется в отдельный Player dev/release; schema export выполняется служебным процессом; Editor plugins — DLL/SO под точный SDK/restart. MCP существует только в Editor/headless editor services, без runtime inspection/mutation и без MCP в Player/SchemaExporter. Канон — [архитектура](../ARCHITECTURE.md), этапы — [PLAN.md](../../PLAN.md). Ниже описан выбранный проект, не реализованный build service.
+Дата исследования: 17.09.2026; актуализация решений: **18.09.2026**. Дополнение к [исследованию стеков](13-build-pipeline-and-stack.md). **Приняты** CMake+Ninja, Clang Linux/clang-cl Windows, C++ core/gameplay первым и Lua следующим модулем. Gameplay статически линкуется в отдельный Player dev/release; schema export выполняется служебным процессом; Editor plugins — DLL/SO под точный SDK/restart. MCP существует только в Editor/headless editor services, без runtime inspection/mutation и без MCP в Player/SchemaExporter. Канон — [архитектура](../ARCHITECTURE.md), этапы — [PLAN.md](../../PLAN.md). Ниже сохранён проект BuildService на этапе исследования. Реализованный MVP-профиль и проверки — в [Manual экспорта](../manual/editor/export.md) и [журнале реализации](../IMPLEMENTATION.md).
 
 Исходники: Unreal Engine 5.8.2, commit `16d75d84714512edfb744e1fd0a59e9c74d57873`; [общий манифест](source-manifest.json). Ни UE, ни будущий Faset в этом исследовании не собирались. Ниже — чтение тел функций и официальной документации, затем собственный проект контрактов и проверок.
 

docs/studies/README.md

@@ -2,7 +2,7 @@
 
 Обновлено 18.09.2026. Исходники и официальная документация исследовались прежде всего 17.09.2026; затем результаты согласованы с принятой архитектурой.
 
-**Актуальные решения — в [ARCHITECTURE.md](../ARCHITECTURE.md), порядок реализации — в [PLAN.md](../../PLAN.md).** Движок ещё не реализован. Исследования дают обоснования и проверочные сценарии, а не доказанные показатели будущего Faset.
+**Актуальные решения — в [ARCHITECTURE.md](../ARCHITECTURE.md), порядок реализации — в [PLAN.md](../../PLAN.md).** Реализация MVP и проверки идут отдельно: [журнал реализации](../IMPLEMENTATION.md), [результаты проверок](../validation/README.md), [пользовательский Manual](../manual/index.md). Исследования дают обоснования и проверочные сценарии; их статический анализ не является измерением Faset.
 
 ## Принято по результатам обсуждения
 

docs/studies/map/README.md

@@ -1,8 +1,8 @@
 # Карта исследования Faset Engine
 
-Локальное React-приложение с интерактивной картой, просмотром Markdown и переходами к строкам исходников. `research.tsx` хранится здесь же; сборка не зависит от Codex, абсолютного пути к рабочему столу или файлов в домашнем каталоге. Карта показывает принятые решения и будущие критерии этапов; движок ещё не реализован.
+Локальное React-приложение с интерактивной картой, просмотром Markdown и переходами к строкам исходников. `research.tsx` хранится здесь же; сборка не зависит от Codex, абсолютного пути к рабочему столу или файлов в домашнем каталоге. Карта показывает принятые решения и критерии этапов. Текущее состояние C++-реализации и проверок записано в [журнале реализации](../../IMPLEMENTATION.md).
 
-Главные документы: [о проекте](../../../README.md), [план до/после MVP](../../../PLAN.md), [архитектура](../../ARCHITECTURE.md), [исследования](../README.md). Актуальный охват: собственный Vulkan 1.3/Render Graph, Slang, SDL3, C++/EnTT, retained editor UI; две демки в MVP, продвинутая графика и Lua после него. MCP запланирован строго в Editor, без доступа к runtime worlds/сессиям и без MCP в Player.
+Главные документы: [о проекте](../../../README.md), [план до/после MVP](../../../PLAN.md), [архитектура](../../ARCHITECTURE.md), [исследования](../README.md). Актуальный охват: собственный Vulkan 1.3/Render Graph, Slang, SDL3, C++/EnTT, retained editor UI; две демки в MVP, продвинутая графика и Lua после него. MCP работает строго в Editor, без доступа к runtime worlds/сессиям и без MCP в Player.
 
 В этой папке, с установленными Node.js 20+ и npm:
 
@@ -33,6 +33,6 @@ workspace/
 
 Без внешнего checkout локальная source-ссылка показывает пояснение. Карточки UE также ведут на upstream конкретного research commit; доступ к Unreal Engine регулируется Epic. Номера строк проверялись на snapshots из [source-manifest.json](../source-manifest.json); иной локальный commit может иметь другие строки. Исходники движков не копируются в сборку карты.
 
-API принимает пути относительно корня проекта, проверяет реальные пути и разрешает только текстовые файлы из перечисленных областей размером до 8 MiB. Скрытые каталоги и `node_modules` исключены. Сервер предназначен для локального чтения исследования, без изменения файлов. Его следует запускать локально; это не публичный file server и не MCP будущего редактора.
+API принимает пути относительно корня проекта, проверяет реальные пути и разрешает только текстовые файлы из перечисленных областей размером до 8 MiB. Скрытые каталоги и `node_modules` исключены. Сервер предназначен для локального чтения исследования, без изменения файлов. Его следует запускать локально; это не публичный file server и не MCP редактора.
 
 Проверка разрешения ссылок и границ файлового API: `npm test`.

docs/studies/map/research.tsx

@@ -101,7 +101,7 @@ export default function EngineResearch() {
       <Stack gap={5}><Text size="small" tone="tertiary">FASET ENGINE · РЕШЕНИЯ 18.09.2026</Text><H1>Архитектура, MVP и развитие графики</H1><Text tone="secondary">Linux + Windows · 2D / 3D · C++ Editor · Blender</Text></Stack>
       <Row gap={8} wrap><Button onClick={() => open("README.md")}>О проекте</Button><Button onClick={() => open("PLAN.md")}>План до / после MVP</Button><Button onClick={() => open("docs/ARCHITECTURE.md")}>Архитектура</Button></Row>
     </Row>
-    <Card><CardBody><Text><strong>Архитектура принята; реализация движка запланирована.</strong> Эта карта — работающий просмотрщик исследования, не редактор Faset. GPU-бенчмарки и сборки движка ещё не выполнены. MCP предусмотрен строго в Editor; Player не содержит MCP и не предоставляет ему runtime worlds или игровые сессии.</Text></CardBody></Card>
+    <Card><CardBody><Text><strong>Архитектура принята; идёт приёмка реализации MVP.</strong> Эта карта — работающий просмотрщик исследования, не редактор Faset. Результаты сборок, проверок и измерений опубликованы в docs/IMPLEMENTATION.md и docs/validation; исследовательские графические направления не считаются готовыми функциями. MCP предусмотрен строго в Editor; Player не содержит MCP и не предоставляет ему runtime worlds или игровые сессии.</Text></CardBody></Card>
     <Row gap={7} wrap>{["Решение", "Графика", "ECS и данные", "MCP и Blender", "Стек и экспорт", "Прототипы", "Источники"].map(name => <span key={name}><Pill active={tab === name} onClick={() => setTab(name)}>{name}</Pill></span>)}</Row>
     <Divider/>
 
@@ -192,7 +192,7 @@ export default function EngineResearch() {
       ]}/>
       <Text>UI, CLI и MCP редактора запускают один BuildRequest. Компиляторы работают в дочерних процессах; staging публикуется после проверки. Планируемый контракт отмены сохраняет последнюю успешную сборку; cache корректность и повторяемость требуют тестов, а не только hash-ключей.</Text>
       <Text>Windows и Linux сборки проверяются в своих окружениях. Player не включает Editor/MCP, shader compiler или editor plugins. Драйвер всё равно создаёт GPU pipelines; shader hot reload требует собственной проверки bindings/layout и безопасной замены ресурсов.</Text>
-      <Text size="small" tone="secondary">Версии toolchain/dependencies и проверенная GPU/driver matrix ещё не закреплены. C#/.NET и Rust + wgpu остаются историей сравнения вариантов, не параллельными реализациями Faset.</Text>
+      <Text size="small" tone="secondary">Версии закреплены в dependencies.lock.json и документации toolchain; фактически проверенные GPU/driver окружения указаны в docs/validation. C#/.NET и Rust + wgpu остаются историей сравнения вариантов, не параллельными реализациями Faset.</Text>
       <Row gap={8} wrap><Button onClick={() => open(root + reports[7].path)}>Исследование сборки и вариантов стека</Button><Button onClick={() => open(root + reports[11].path)}>Build service, cache и delivery</Button></Row>
     </Stack>}