test(runtime): verify native resource distributor tick

1 files changed, 31 insertions, 3 deletions

diff --git a/docs/tomes/06-behavior.md b/docs/tomes/06-behavior.md
index 62c7b56..cd08969 100644
--- a/docs/tomes/06-behavior.md
+++ b/docs/tomes/06-behavior.md
@@ -203,9 +203,37 @@ SuperAI для записей кланов, затем обновляет Behavi
 Это полезное начало сценария, но ещё не целая игровая жизнь AI. Текущий runtime
 не воспроизводит аргумент обратного вызова в `AI+0x3fc`, защиту от повторного
 входа `AI+0x78`, одноразовую метку `AI+0x8a8` или обновления Behavior на игровых
-тиках. Он также не подменяет очередь оригинала: вызывающая сторона сама
-передаёт время, а локальный генератор Rust пока учитывает только случайные
-числа этого восстановленного шага.
+тиках. При этом один конкретный шаг Behavior — распределение ресурсов — уже
+исполнен на исходной DLL с искусственными объектами; FParkan пока не вызывает
+его, потому что игровой мир Rust ещё не предоставляет нужные ресурсные
+интерфейсы. Runtime также не подменяет очередь оригинала: вызывающая сторона
+сама передаёт время, а локальный генератор Rust пока учитывает только случайные
+числа восстановленного стартового шага.
+
+### Регулярная передача ресурсов
+
+Resource Distributor работает со списком зарегистрированных объектов. За один
+шаг он сначала проходит список и собирает нужные значения, а затем проходит его
+ещё раз и применяет результат. Во втором проходе объект ищется заново, поэтому
+его состояние или ответ getter-а может измениться между чтением и записью.
+Нулевой временной шаг ничего не делает; некоторые состояния объекта также
+пропускают строку ещё до запросов ресурсных интерфейсов.
+
+В синтетическом примере исходного кода два объекта с ключами `41` и `42`
+обрабатываются в порядке `41, 42, 41, 42`: производитель сначала сообщает
+скорость `4`, затем `1`, а получатель со значением `6` заканчивает шаг со
+значением `7`. Это показывает, почему одного результата чтения недостаточно:
+алгоритм снова получает величины при применении. Сценарий был запущен прямо из
+исходной `Behavior.dll`, но объекты и ответы интерфейсов заданы тестом; это ещё
+не воспроизведение реальной миссии.
+
+Пока мы знаем точные границы интерфейсных запросов и некоторые ветви классов
+объектов, но не все доменные значения полей записи и не происхождение реальных
+строк списка. Загрузчик FParkan не должен создавать такие строки из похожих
+полей миссии: сначала нужно доказать путь регистрации и связать его с типами
+ресурсных объектов. Технические идентификаторы и численные векторы приведены
+в [приложении о сценарной машине](../appendices/script-vm.md), а оставшиеся
+вопросы перечислены в [границах знания](../appendices/knowledge-boundaries.md).
 
 Первый часто встречающийся table entry с side effect — `Handler(2)` (176
 records в corpus). Он берёт active instruction, разрешает семь slots через