3 files changed, 215 insertions, 46 deletions
diff --git a/docs/appendices/knowledge-boundaries.md b/docs/appendices/knowledge-boundaries.md
index 5791836..fa1af94 100644
--- a/docs/appendices/knowledge-boundaries.md
+++ b/docs/appendices/knowledge-boundaries.md
@@ -253,12 +253,26 @@ solver. То же относится к редким MSH auxiliary streams и ч
 разрешается в индекс устройства и сдвигает локальный индекс только когда parent
 ID не равен `-1` и IID `0x202` доступен; иначе используется raw локальный индекс.
 В этом потоке нулевой raw kind пропускает узел вместе с потомками, поэтому общий
-assigned ID нельзя получать из preorder-позиции записи. Это закрывает только
-передачу полей в native loader-е; Rust ещё должен строить такую же проекцию.
-
-Control loader также различает добавление устройств и применение одной записи
-к уже выбранному устройству. Для tag `19` найденные поля и ветви описаны в
-главе, но эффективное слияние пока не реализовано. В Rust parser-е
+assigned ID нельзя получать из preorder-позиции записи. Полная загрузка миссии
+в FParkan строит упорядоченную базовую проекцию таблицы
+Control для объектов с Unit DAT: корневые записи добавляются, `EXTO` добавляет
+строки с ключами глобальной MSH-иерархии, а `INTO` обновляет первую строку
+выбранного индекса либо добавляет список при sentinel `-1`. Проверка полной
+загрузки на оригинальном `min_l_n1.dat` получает 11 строк: 10 корневых записей,
+четыре замены `INTO` и одну добавленную строку дочернего `EXTO`. Ветви C4/C8 и
+добавление `EXTO` подтверждены машинными инструкциями оригинальных модулей, но
+полный результат FParkan не сравнивался с таблицей из запущенной игры. Тест на
+искусственном дереве также проверяет ID после пропущенного поддерева с raw kind
+`0`. Проекция хранит общие поля и происхождение записей; она не исполняет все
+обработчики Control.
+
+Control различает добавление устройства и применение одной записи к уже
+выбранному устройству. Исполнение оригинальной 32-битной DLL на искусственных
+данных подтверждает общую ветвь переопределения для получателей tags `9`, `15`,
+`19` и `25`: остаются прежними слот, ключ, ID компонента, множитель и класс,
+а коэффициенты копируются из новой записи. Искусственный tag `9`-объект создан
+без FX-хоста (`+0x3c == 0`), а запись не содержит строк таблицы map; поэтому
+работа FX-хоста здесь не проверялась. В Rust parser-е
 `Unsupported { typed_record_index: Some(_) }` означает, что разбор остановился
 внутри списка typed records; без индекса остановки unsupported может относиться
 к effect-tail после уже разобранного списка. Эти случаи нужно различать.
@@ -268,28 +282,73 @@ Control loader также различает добавление устройс
 подготовленного CTL должно оставаться явным unavailable result, а не
 трактоваться как пустой список.
 
-Глобальные Control selectors `1/2` и setter selector `1` по tag `19` описаны
-там же только по статическому разбору `Control.dll`; execution oracle для этих
-глобальных вызовов нет. Остаются открытыми проверка effective merge на живых
-объектах, полный охват registry types и host factory paths, а также runtime
-жизненный цикл множителя `+0x4c`.
+Global Control getters `1/2` и setter `1` проверены в native x86 oracle для
+искусственных factory/descriptor pairs `9`, `15` и `19`, а в Rust реализованы
+для текущего descriptor tag `19` с factory tags `9`, `15`, `19` и `25`. Для tag
+`25` общий getter slot `+0x10` подтверждён чтением vtable, но агрегатный вызов
+этого класса native oracle не запускал. Rust API обращается к строкам проекции
+конкретного живого `ObjectHandle`; это запрос к уже загруженной таблице, а не
+исполнение Control или Behavior tick. Setter `17`, остальные factory tags и
+внешние эффекты их методов не включены. Для tag `9` selector `0` использует
+отдельный scale `+0x11c`; остальные поддержанные классы используют коэффициент
+напрямую. Пустой набор и нулевой знаменатель остаются native no-result, а
+неподдержанный factory tag и расчётный диапазон произведения/отношения за
+нормальным диапазоном `f32` становятся явной ошибкой Rust.
+
+Проекция полного mission load недоступна для неполного списка typed records,
+Control resource у non-geometric prototype и некоторых неразрешённых EXTO node
+mappings; preview и объекты без Unit DAT root её не строят. Её соответствие
+полной загрузке игры для всех типов компонентов и factory paths ещё не
+установлено. Setter `1` меняет multiplier `+0x4c` выбранных строк, но расписание
+и lifetime этих объектов после конструктора и в отложенной загрузке остаются
+непроверенными.
 
 Для `Control.dll` (SHA-256
 `bcb86318089028548a178b03a21accdce15df0cc85ddd91674cf3c2f55012c6e`) tag-26
 getter selector `0x300` восстановлен локально: RVA `0x21d00` читает provider по
 ключу `fixed_words[1]`, затем умножает provider, CTLD coefficient `fixed_words[11]`
-и поле объекта `+0x4c` именно в таком порядке. Rust helper принимает текущие
-provider и multiplier извне; он не восстанавливает их жизненный цикл или весь
-Control tick. В x86 oracle при x87 control word `0x007f` проверены порядок,
-signed zero, отрицательные входы, расширенный промежуточный диапазон и
-subnormal return. Helper ограничивает себя normal-or-zero значениями, поэтому
-явно отклоняет промежуточные случаи, где результат выходит за поддерживаемый
-диапазон f32, даже если позднее умножение вернуло бы его в диапазон. Это
-ограничение поддержки Rust helper-а, а не неверный native-результат.
+и поле объекта `+0x4c` именно в таком порядке. Provider getter RVA `0xdc40`
+читает type-1 поле `+0x14` строки, которую `FUN_10008b10` (RVA `0x8b10`)
+добавляет из NDP в таблицу с шагом `0x2c`; `FUN_1000b240` (RVA `0xb240`)
+инициализирует это поле как `1.0`. Начальный Rust snapshot повторяет порядок
+NDP строк корневого ресурса и примонтированных `EXTO` (без первой строки
+последнего), сохраняя исходные таблицу и строку как provenance. Ключ устройства
+сначала меняется по подтверждённому MSH mapping для `EXTO`, затем это готовое
+значение применяется напрямую как индекс provider sequence. Длина этой
+sequence определяется NDP: она не дополняется по числу узлов модели и ключ не
+пересчитывается ещё раз по числу provider rows. `INTO` provider строк не
+добавляет. Для примонтированного `EXTO` с пустым NDP невозможно безопасно
+применить native skip-first путь, поэтому Rust явно сообщает unavailable;
+таблица из одной строки допустима и даёт нулевой вклад. Если обязательный NDP
+sidecar недоступен, запрос `0xe00` сообщает это отдельно, оставляя независимые
+агрегатные selectors `1/2` доступными.
+
+Rust query обращается к загруженному объекту и поддерживает `0xe00` только для
+текущего descriptor tag `26` с factory tag `26`; другие активные typed tags и
+factory paths остаются явными границами. Snapshot показывает состояние сразу
+после native-конструкторов, но он не обновляется при Control tick-е. Native
+`FUN_10010f30` (RVA `0x10f30`) изменяет и ограничивает provider amount, а
+связанные callbacks переносят его между строками; их общий переход в Rust ещё
+не реализован. Поэтому вызов нельзя считать живым ресурсным симулятором.
+Behavior selector `0x1002` остаётся отдельной задачей: его множитель
+`Transfer_Ore_OffBoard` приходит из блока `+0x820`, но источник фактических
+текущих настроек для полного runtime-пути пока не подтверждён.
+
+В x86 oracle при x87 control word `0x007f` проверены порядок, signed zero,
+отрицательные входы, расширенный промежуточный диапазон и subnormal return.
+Rust запрос ограничивает себя normal-or-zero значениями, поэтому явно отклоняет
+промежуточные случаи, где результат выходит за поддерживаемый диапазон f32,
+даже если позднее умножение вернуло бы его в диапазон. Это ограничение
+поддержки Rust snapshot, а не неверный native-результат.
 
 В Unit DAT fixture `UNITS/BUILDS/MINE/min_l_n1.dat` проверена реальная связка
-`fr_l_mine.ctl` + `fr_l_mine.ndp`: tag `26`, ключ `2` в таблице из `22` строк,
-коэффициент `1.0`. Это не запись живого resource-device значения в миссии.
+`fr_l_mine.ctl` + `fr_l_mine.ndp`: tag `26`, ключ `2` в локальной NDP таблице
+из `22` строк, коэффициент `1.0`. Игнорируемый runtime-тест выполняет полный
+загрузочный путь, подтверждает root/`EXTO` размеры `22` и `4` и итоговые `25`
+provider rows после пропуска первого `EXTO` row. Он вызывает Rust query по
+восстановленному native правилу адресации и получает начальное значение `1.0`;
+getter оригинальной DLL здесь не исполняется. Это не запись живого
+resource-device значения во время игры.
 
 Закрывающий эксперимент: трассировать `LoadControlSystem`,
 `LoadPhysicalModel`, `CreateCollManager` и создание collision objects; связать
diff --git a/docs/tomes/03-resources.md b/docs/tomes/03-resources.md
index a11ad55..a349a79 100644
--- a/docs/tomes/03-resources.md
+++ b/docs/tomes/03-resources.md
@@ -477,8 +477,15 @@ struct UnitDatRecord112 {
 
 При построении mission prototype graph FParkan сохраняет для каждого root
 упорядоченный список этих raw records. Список передаётся в
-`MissionObjectDraft` с исходными `kind`, `parent_or_link`, description и tails;
-эти данные пока не объединяются в таблицу эффективных устройств Control.
+`MissionObjectDraft` с исходными `kind`, `parent_or_link`, description и tails.
+Во время полного mission load runtime использует дерево и подготовленные CTL
+resources, чтобы построить для такого объекта упорядоченную базовую таблицу
+Control: корневые строки добавляются, дочерний `INTO` может обновить выбранную
+строку или добавить записи при sentinel `-1`, а `EXTO` добавляет строки с
+переведёнными ключами глобальной MSH-иерархии. Результат хранит исходный factory
+tag и provenance; неизвестные tag-specific callbacks он не выполняет. Preview
+режим эту таблицу не строит, а неполная typed-record list оставляет состояние
+явно unavailable.
 
 Каждый graph edge от `UnitDatRoot` к effective component и далее к его MSH
 dependency также несёт `unit_component_index`. Это индекс исходной записи в
diff --git a/docs/tomes/06-behavior.md b/docs/tomes/06-behavior.md
index 9d7b01e..7dc6d66 100644
--- a/docs/tomes/06-behavior.md
+++ b/docs/tomes/06-behavior.md
@@ -593,6 +593,28 @@ parent ID через Control IID `0x202`, virtual slot `+0x44`, только е�
 нужно проверить это поведение явно. `EXTO` проходит отдельную ветвь, поэтому
 это правило нельзя распространять на все registry types.
 
+Ветка `EXTO` заполняет другие поля. В `FUN_10003760` RVA `0x3760` и mount
+`C4`, и target `C8` сначала равны `-1`. Ветка `EXTO` вычисляет mount и
+записывает его только в `C4`; `C8` остаётся `-1`. Поэтому Control добавляет
+все typed records такого компонента в конец общей таблицы. Raw
+`parent_or_link` здесь выбирает mount-узел, а не строку Control.
+
+`AniMesh.dll` (SHA-256
+`65659bf67f20e5be77d67a5b2f59968f61b94293143807fa59ca451c560c4f7e`)
+собирает глобальную нумерацию MSH-узлов: обычная корневая модель добавляет все
+`N` узлов, `EXTO`-дочерняя модель добавляет `N - 1`, начиная со своего узла `1`,
+а `INTO`-компонент не добавляет узлов. `FUN_1000a460` (RVA `0xa460`) выполняет
+эту загрузку MSH; `FUN_10005780` (RVA `0x5780`) находит первый глобальный узел
+с заданным component ID. Если у `EXTO`-модели только один узел, она не добавляет
+глобальных узлов, и поиск первого узла возвращает `-1`.
+
+При добавлении `EXTO` Control отдельно переводит ключи CTLD в пространство
+глобальной MSH-иерархии: нулевой ключ заменяется mount-узлом `C4`; ненулевой
+ключ сдвигается относительно первого глобального узла компонента только при
+`C4 != -1`. Например, если компонент начинается с глобального узла `22`, его
+исходный ключ `1` становится `22`. Этот ключ выбирает модельный узел, а не
+строку Control. Записи корня остаются в исходном виде.
+
 ### Как Control добавляет и переопределяет устройства
 
 В `Control.dll` (SHA-256
@@ -609,6 +631,19 @@ override path применяет первую typed record и не добавл�
 путь `0x20800`, поэтому такой результат парсера сам по себе не доказывает отказ
 оригинального loader-а и не позволяет объявить Rust merge полным.
 
+FParkan строит базовую проекцию этой таблицы во время полного mission load для
+объектов с Unit DAT. Корневые typed records добавляются в исходном порядке;
+`EXTO` тоже добавляет все свои записи с remapped MSH-ключами; `INTO` обновляет
+одну строку по `C8`, а при sentinel `-1` добавляет весь список. Preview таблицу
+не создаёт. Проекция хранит исходный factory tag, текущий typed record и их
+provenance, но не исполняет все tag-specific callbacks и не заменяет полный
+Control runtime. Лицензированный `UNITS/BUILDS/MINE/min_l_n1.dat` подтверждает
+10 исходных устройств, четыре `INTO`-override по индексам `0..3` и добавление
+одной дочерней записи `EXTO` с ключом `22`, всего 11 устройств. Это результат
+Rust full-loader теста на оригинальных ресурсах. Ветви C4/C8 и добавление
+`EXTO` подтверждены статически по native ASM; отдельный native full-load oracle
+для всей таблицы не запускался.
+
 Для tag `19` фабрика создаёт объект с его исходными классом и vtable. Базовый
 конструктор `FUN_100218b0` задаёт multiplier `+0x4c = 1.0`. Override через
 `FUN_1002d890` вызывает у выбранного объекта vtable slot `+0x1c`, то есть
@@ -621,16 +656,55 @@ override path применяет первую typed record и не добавл�
 сбрасывают их. Поэтому «переопределение» здесь означает обновить часть данных
 того же устройства, с ограничениями конкретного метода.
 
+Native x86 oracle для тех же GOG DLL выполняет конструкторы и этот общий setter
+на уже созданных получателях factory tags `9`, `15`, `19` и `25` (размеры
+объектов `0x120`, `0x98`, `0x94` и `0xa4`). У всех проверенных vtable slot
+`+0x1c` указывает на RVA `0x21d50`; тест подтверждает, что override сохраняет
+существующий слот, класс/vtable, ключ, component ID и multiplier `2.5`, копируя
+новые коэффициенты. Slot `+0x24` у tag `9` указывает на отдельный обработчик
+`0x25600`, а у остальных трёх — на no-op `0xbcd0`. Tag `9` проверяется с
+нулевым pointer `+0x3c` и записью без map rows: FX host намеренно не подключён,
+поэтому его поведение этим опытом не подтверждено.
+
 Статический разбор глобального Control interface показывает aggregate getters
 `1/2` (`FUN_1002b410`, RVA `0x2b410`) и setter `1` (`FUN_1002ba30`, RVA
-`0x2ba30`) для устройств tag `19`. Для конечных значений getter `1` вычисляет
-`sum(base * multiplier) / sum(base)`, а getter `2` — `sum(base)`. При встрече
-отрицательного base selector `1` сразу возвращает `1.0`, а selector
-`2` — этот base. Если подходящих записей нет или сумма base неположительна,
-getter возвращает неуспех без записи результата. Setter пишет multiplier `+0x4c`
-только устройствам tag `19` с положительным selector-0 значением; пустой набор
-возвращает успех. Это вывод статического анализа для конечных входных значений,
-без отдельного native execution oracle для глобальных selectors.
+`0x2ba30`) для текущего descriptor tag `19`. Getter `1` складывает ответы
+виртуального selector `0x200` в числитель и selector `0` в знаменатель; getter
+`2` возвращает сумму selector `0`. Для обычного factory tag `19` эти ответы
+равны `coefficient * multiplier` и `coefficient`, то есть отношение сводится к
+`sum(coefficient * multiplier) / sum(coefficient)`. У factory tag `9` selector
+`0` умножает коэффициент на отдельное поле `+0x11c`, тогда как selector `0x200`
+использует коэффициент и multiplier; эта особая база меняет знаменатель.
+Обработчик factory tag `9` расположен в Control RVA `0x255c0`, а его конструктор
+RVA `0x25460` задаёт `+0x11c = 1.0`. При встрече отрицательного ответа selector
+`0` getter `1` сразу возвращает `1.0`, а getter `2` — этот ответ. Если подходящих
+записей нет или сумма базы неположительна, getter возвращает неуспех без записи
+результата. Setter пишет multiplier `+0x4c` только устройствам с текущим
+descriptor tag `19` и положительным selector-0 ответом; пустой набор возвращает
+успех. Фильтр использует **текущий descriptor tag**, который может измениться
+при `INTO`, а виртуальный вызов остаётся методом исходного factory-класса.
+
+Этот путь проверяется native x86 oracle на оригинальной `Control.dll` указанной
+выше: искусственные factory/descriptor пары `9`, `15` и `19` покрывают setter,
+отрицательные ответы, округление и тег `9` с scale `0.5`. Для factory tag `25`
+его vtable slot `+0x10` статически указывает на общий getter RVA `0x21d00`, но
+отдельный aggregate oracle этот класс не запускал. Rust хранит начальный scale
+factory `9` и предоставляет `query_loaded_mission_control_resource` для selector
+`1`/`2` и `set_loaded_mission_control_multiplier` для setter-а `1`. Вызовы
+сначала проверяют живой `ObjectHandle`, затем обращаются к таблице этого объекта
+из полной загрузки миссии. Синтетические тесты проверяют границы пустой таблицы,
+нулевого знаменателя, неподдержанных factory tags и чисел за диапазоном
+нормального `f32`; лицензированный тест сверяет реальные descriptor tags и
+получает для `min_l_n1.dat` сумму `16` и отношение `1` до setter-а.
+
+В этом API пока реализованы только getter selectors `1`/`2` и setter `1`.
+Отдельный native setter selector `17`, tag-specific методы прочих factory tags,
+их внешние эффекты и вызов из регулярного шага Behavior здесь не моделируются.
+Числа должны оставаться конечными и нормальными либо точным нулём; произведения
+и отношения за поддерживаемым диапазоном `f32` возвращают явную ошибку, а не
+подменяются нулём или `None`. При проверке диапазона Rust оценивает операцию в
+`f64`, затем выполняет её в `f32`; это ограниченная проверка диапазона, а не
+эмуляция полного x87 accumulator-а.
 
 Отдельная ветка того же GOG `AniMesh.dll` показывает, когда создаётся Behavior
 для host object. В `FUN_10002ff0` (RVA `0x2ff0`, SHA-256
@@ -658,8 +732,21 @@ Provider interface направляет selector `1` и ключ в Control RVA
 читается текущее type-1 значение выбранной строки. Затем selector умножает
 сначала provider на коэффициент, после чего на множитель: `provider * base *
 multiplier`. Коэффициент приходит из CTLD; NDP связывает ключ с описанной
-строкой, а текущее значение provider нельзя заменить предположением о состоянии
-мира.
+строкой. Native loader создаёт для этой строки отдельное runtime-состояние: у
+`Control.dll` (та же сборка, SHA-256
+`bcb86318089028548a178b03a21accdce15df0cc85ddd91674cf3c2f55012c6e`)
+`FUN_1000b240` (RVA `0xb240`) строит 11 слов строки provider и ставит её
+selector-1 поле `+0x14` в `1.0`. `FUN_10008b10` (RVA `0x8b10`) выбирает строки
+NDP, а `FUN_1000a100` (RVA `0xa100`) добавляет их в общую таблицу с шагом
+`0x2c`; getter `FUN_1000dc40` (RVA `0xdc40`) использует ключ устройства как
+индекс этой таблицы. Для корня загружаются все строки. `INTO` не добавляет
+строк, а примонтированный `EXTO` пропускает свою первую строку. Пустая
+таблица такого `EXTO` не содержит строки, которую native loader должен
+пропустить, поэтому Rust оставляет provider lookup недоступным; sidecar с одной
+строкой даёт пустой вклад. Если mount узел не разрешился, строки этого `EXTO`
+в таблицу не попадают. Это отдельная
+последовательность provider-строк: её длина берётся из NDP, она не дополняется
+до числа узлов MSH и не участвует во второй перенумерации ключа.
 
 Так этот селектор включён в цепочку добычи руды оригинала. В той же сборке
 `Behavior.dll` (SHA-256
@@ -673,24 +760,40 @@ multiplier`. Коэффициент приходит из CTLD; NDP связыв
 5.0 — RVA `0x22d90`; config selector 2 загружает блок через RVA `0x0a1a0`).
 Отдельный query `0x1005` (RVA `0xa490`) возвращает поле `+0x60`
 `Transfer_Power_Out` (имя — RVA `0x22e20`, default 100.0 — RVA `0x22d90`;
-setter — RVA `0xaa40`). Rust helper пока описывает один Control selector `0x300`
-при явно переданных входах; он не реализует эту сумму, Behavior-умножение или
-подключение к игровому циклу.
+setter — RVA `0xaa40`). В полной загрузке FParkan начальные provider-строки
+хранятся вместе с таблицей Control конкретного `ObjectHandle`. Запрос
+`0xe00` проходит по ключу устройства в этот снимок и пока поддержан только для
+текущего descriptor tag `26` с factory tag `26`; для него результат равен
+`provider * fixed_words[11] * multiplier`. Лицензированный тест загружает
+оригинальные CTL/NDP и подтверждает, что tag-26 запись с ключом `2` читает
+начальное значение строки `1.0`. Это проверка начального состояния после
+конструкторов, не результат живого игрового тика.
+
+Поведение provider-строк меняется и после загрузки: например,
+`Control.dll!FUN_10010f30` (RVA `0x10f30`) обновляет и ограничивает текущее
+значение, а соседние процедуры распространяют его между связанными строками.
+Эти изменения пока не отражены в Rust-снимке. Поэтому `0xe00` не является
+исполнением всего Control tick-а, а Behavior query `0x1002` не подключён к
+этому API; его множитель `Transfer_Ore_OffBoard` требует отдельного источника
+текущей конфигурации.
 
 На x87 control word `0x007f` каждое умножение округляет мантиссу до 24 бит,
 но промежуточная степень может выйти за диапазон `f32` и вернуться в него при
-следующем умножении. Rust helper поэтому принимает явные текущие значения
-provider и multiplier, проверяет tag, ключ и строку NDP, сохраняет порядок
-операций, но поддерживает только конечные нормализованные значения или ноль на
-входе, промежуточном и конечном этапах. Остальные случаи за этим численным
-диапазоном он отклоняет; полный x87 accumulator здесь не эмулируется.
+следующем умножении. Native oracle проверяет такой порядок для getter-а
+`0x300`. Rust запрос сохраняет тот же порядок, но поддерживает только конечные
+нормализованные значения или ноль на входе, промежуточном и конечном этапах.
+Остальные случаи за этим численным диапазоном он отклоняет; полный x87
+accumulator здесь не эмулируется.
 
 Лицензированный тест на Unit DAT `UNITS/BUILDS/MINE/min_l_n1.dat` проходит через
-компонент `fr_l_mine.ctl` и sidecar `fr_l_mine.ndp`: у найденного tag-26
-дескриптора ключ равен `2` из `22` строк, а raw коэффициент — `0x3f800000`.
-Тест передаёт helper-у искусственные текущие значения `1.0` только для проверки
-записи и привязки ключа; этот Unit DAT не является наблюдением живого Control
-tick-а.
+`fr_l_mine.ctl` и `fr_l_mine.ndp`: у найденного tag-26 descriptor ключ равен
+`2` в своей записи, raw коэффициент — `0x3f800000`. Корневой NDP содержит 22
+строки, sidecar примонтированного `EXTO` — 4; в общую provider-таблицу входит
+25 строк после пропуска локальной строки `0`. Тест также сравнивает порядок
+всех source-row индексов с порядком строк самих sidecar таблиц. Он вызывает
+Rust query по восстановленному native правилу адресации, а не getter оригинальной
+DLL на полной миссии. Значение `1.0` подтверждает начальное состояние по native
+конструктору, но не наблюдение живого Control tick-а.
 
 ### Control system и physical model