- Эти зеркала не требуют доработки. Все внесенные изменения будут затерты автоматическими процессами синхронизации 1С и OneScript версии (в пользу 1С версии из `src/ru/BSL`)
- Текст тестовых модулей используется для формирования примеров кода в документации
- Служебные комментарии `//SKIP` и `//END` используются для исключения частей кода теста при формировании примера для документации. `// SKIP` позволяет исключить конкретную строку внутри теста, `//END` - завершает запись примера. Весь служебный код, который идет после `//END` не попадает в пример кода для документации
- В каждом атомарном тесте должен быть **хотя бы один** вызов `OPI_ПолучениеДанныхТестов.Обработать` с **незаполненным** параметром `Вариант` (основной сценарий). Это **первый** такой вызов в процедуре, он размещается **до**`//END`; его результат попадает в онлайн-документацию как пример результата метода. Дополнительные варианты проверяются последующими вызовами `Обработать` с заполненным `Вариант` — они идут **после**`//END` и в пример документации не включаются
- При формировании атомарных тестов нельзя выносить повторяющийся код в служебные функции, так как это может привести к недопониманию при их использовании в качестве примеров для документации
- В `OPI_ПолучениеДанныхТестов`**нельзя** вызывать методы функциональных модулей библиотеки (`OPI_MessagePack`, `OPI_Lua`, `OPI_Telegram` и т.п.). Модуль проверок должен оставаться независимым от тестируемых API. Если для проверки нужны подготовленные данные (десериализация, round-trip, повторный вызов метода), это делается в атомарном тесте `OPIt_*` и передаётся в `Обработать` / `ОбработатьCLI` через дополнительные параметры (`Восстановленное`, `Исходное` и т.д.).
**Обязательный шаблон** для любой новой нативной компоненты и для переработки существующих. Не создавать add-in «с нуля» в монолитном `lib.rs` с `Arc<Mutex<…>>` — сразу закладывать структуру ниже.
| **Backend** | `common-backend`: поток worker + `catch_panic` на цикл handler | Паника в драйвере; после фатала — `health`, следующие `call`/`send` → `Err` |
`catch_unwind` только на FFI **не заменяет** worker-поток: не решает `!Send` соединений (SQLite), гонки при параллельных вызовах из 1С, poisoned `Mutex` вокруг драйвера.
**Не защищает** ни один уровень: segfault/abort в C-библиотеке драйвера — падает весь процесс 1С. Изоляция только отдельным процессом (вне этой схемы).
Worker-поток сериализует работу с драйвером, но **не** защищает поля и флаги на стороне `AddIn`: `started`, `logger`, `datasets`, вызовы делегата в `backend`/`common-server`. Если платформа держит один экземпляр компоненты и вызывает методы **из разных потоков** (параллельные задания, внешний хостинг, общий кэш объекта), без mutex на оболочке возможны гонки — даже при корректном worker.
**Обязательно** в `addin.rs` (и в server-`wrapper.rs`, где есть обёртка):
-`Arc<Mutex<State>>` — backend-делегат, служебное состояние, logger; все FFI-методы через `common_utils::lock_unpoisoned`;
- для SQL с dataset — `datasets` внутри того же `State`, не отдельное поле на `AddIn` (в `lib.rs` — тонкие `datasets_*` на `AddIn`).
Свойства getset (`connection_string`, `server_address`, `address` и т.п.) допустимо оставить на `AddIn`**вне** mutex; методы, которые читают их вместе с `State`, берут lock и при необходимости клонируют строку до обращения к backend (см. `grpc``connect`).
Это **не** отменяет запрет ниже: `Arc<Mutex<соединение/драйвер>>` на addin по-прежнему нельзя — драйвер только в worker/`Session`.
`common-server` — тот же канал команд, но свой API (`send_command`, `handle_async_command`); не смешивать с паттерном `addin/backend/worker` без необходимости.
### Общие зависимости (`Cargo.toml`)
-`common-core` — макросы FFI, `catch_panic` на границе.
