1 files changed, 106 insertions, 10 deletions
diff --git a/docs/appendices/knowledge-boundaries.md b/docs/appendices/knowledge-boundaries.md
index 9db3f49..3744d84 100644
--- a/docs/appendices/knowledge-boundaries.md
+++ b/docs/appendices/knowledge-boundaries.md
@@ -247,22 +247,118 @@ CTLD и связанные resources структурно читаются, coun
 известны. Не названы все секции, shape types, coefficients и точный contact
 solver. То же относится к редким MSH auxiliary streams и части CTPT/NDPR flags.
 
+Одна цепочка Unit DAT → AniMesh descriptor → Control теперь восстановлена
+статически в [главе о Behavior и Control](../tomes/06-behavior.md): raw
+`parent_or_link` копируется в descriptor. В non-`EXTO` registry path parent ID
+разрешается в индекс устройства и сдвигает локальный индекс только когда parent
+ID не равен `-1` и IID `0x202` доступен; иначе используется raw локальный индекс.
+В этом потоке нулевой raw kind пропускает узел вместе с потомками, поэтому общий
+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 после уже разобранного списка. Эти случаи нужно различать.
+Ветка default native-фабрики вызывает конструктор по RVA `0x20800`, поэтому
+неизвестный Rust parser-у tag не доказывает отказ оригинального loader-а. Подготовка assets
+сейчас пропускает Control refs у non-geometric prototype, поэтому отсутствие
+подготовленного CTL должно оставаться явным unavailable result, а не
+трактоваться как пустой список.
+
+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 selectors `0x1002` и `0x1005` используют значения выбранного
+профиля из `behpsp.res`, разобранного до создания нового мира. `0x1002` складывает
+только текущие descriptor tag `26` запросы `0xe00`, затем применяет
+`Transfer_Ore_OffBoard`; `0x1005` возвращает `Transfer_Power_Out`. Это начальный
+снимок: он не отражает последующие изменения provider-строк, Control tick-а или
+профиля. Полная загрузка сохраняет результат у `ObjectHandle` и возвращает
+ошибку, если известный код класса не имеет корректной записи; класс,
+отсутствующий в таблице выбора, сохраняет начальные значения конструктора.
+Preview и объекты без полного Unit DAT не получают профильное состояние.
+Native oracle подтвердил соответствия кода класса выбранной записи, разбор
+`.var` и применение второй области данных;
+оригинальный aggregate getter Behavior RVA `0xa490` остаётся статически
+исследованным, но не исполнен в oracle.
+
+В 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; связать