# Политика хранилища по слоям конфигурации 1С

Каждая конфигурация имеет собственную политику: основная конфигурация — слой
`base`, каждое расширение — слой `extension:<GUID>`. Подключение основной
конфигурации к хранилищу не означает подключения расширения и наоборот.

Адаптер работает с метаданными 1С только через SQL. Он не считает SQL-таблицы
доказательством нативного захвата объекта в хранилище.

Заявки на захват и явные ручные подтверждения — это служебные данные адаптера,
а не данные 1С. Они хранятся в `/data/onec-repository-locks.json` в named
volume Docker `adapter-1c-data` и переживают пересоздание контейнера. Это
хранилище не используется для вывода о нативном захвате и не требует записи в
какую-либо базу 1С.

## Настройка

В `development_layers` для каждого фактически используемого слоя задаётся
`repository.connection_state`:

```json
{
  "base": {
    "repository": {"mode": "manual", "connection_state": "configured"},
    "support": {"mode": "unknown"}
  },
  "extension:86d12be8-086c-11f0-925c-0050568c1b38": {
    "repository": {"mode": "none", "connection_state": "not_configured"},
    "support": {"mode": "unknown"}
  }
}
```

Допустимые состояния:

| Состояние | Политика записи |
| --- | --- |
| `not_configured` | Слой не подключён к хранилищу; захват не требуется. Ограничения поддержки сохраняются. |
| `configured` | Подключение известно. В SQL-only режиме нужен запрос и явное подтверждение захвата. |
| `unavailable` | Подключение предполагается, но проверить его нельзя; нужен запрос и явное подтверждение захвата. |
| `unknown` | Не делать предположений: запись в слой блокируется до настройки. |

Для ручного подтверждения всегда передаётся точный объект и явный флаг
`user_confirmed_locked`. Имя пользователя хранилища берётся из
`repository_user` настройки данного слоя. Поэтому при заполненной настройке
его не нужно повторять в каждой заявке или подтверждении. Если клиент всё же
передаёт `confirmed_repository_user`, оно должно совпадать с настроенным
именем. Если имя не настроено, подтверждение попросит его явно.

## Сохранение факта подключения агентом

Агент может сохранить подтверждённый факт в служебной конфигурации адаптера
через `repository.layer.connection.set`. Метод не меняет SQL-базу 1С и требует
явного флага подтверждения.

Основная конфигурация подключена к хранилищу:

```json
{
  "method": "repository.layer.connection.set",
  "payload": {
    "base_id": "neft",
    "layer_id": "base",
    "connection_state": "configured",
    "repository_user": "ivanov",
    "confirm_repository_connection_change": true
  }
}
```

Расширение точно не подключено:

```json
{
  "method": "repository.layer.connection.set",
  "payload": {
    "base_id": "neft",
    "extension_guid": "86d12be8-086c-11f0-925c-0050568c1b38",
    "connection_state": "not_configured",
    "confirm_repository_connection_change": true
  }
}
```

При `not_configured` адаптер устанавливает режим слоя `none`. При
`configured` или `unavailable` новый слой по умолчанию получает ручную
политику захвата. Рекомендуется сразу передать постоянный
`repository_user`: он сохраняется только в конфигурации адаптера для этого
слоя и используется во всех последующих ручных подтверждениях.

## Ручное подтверждение захвата

После `repository.lock.request` клиент должен использовать возвращённый
`next_call` без самостоятельного подбора имён полей. Поля из
`next_call.params` передаются как RPC `payload`; его эквивалент:

```json
{
  "method": "repository.lock.confirm",
  "payload": {
    "base_id": "neft",
    "request_id": "rreq-…",
    "user_confirmed_locked": true
  }
}
```

`objects`, `operation` и `layer_id` не передаются повторно: подтверждение
берёт их из неизменяемой сохранённой заявки. Если имя пользователя сохранено
для слоя, оно тоже не передаётся. Успешный ответ содержит `lock_session_id`;
его необходимо передать в preflight и операцию записи.

Ответ `repository.lock.confirm` содержит готовый `write_context`. Его можно
передать целиком либо верхнеуровневым полем `write_context`, либо алиасом
`repository_lock`; адаптер нормализует поля до проверки захвата:

```json
{
  "base_id": "neft",
  "target": {"module_id": "Config:<form-guid>.0"},
  "repository_lock": {"lock_session_id": "rlock-…", "repository_object": "Document.Имя.Form.ИмяФормы", "layer_id": "base"}
}
```

Если одновременно переданы вложенное и верхнеуровневое значение, они должны
совпадать; иначе возвращается `repository_lock_context_conflict`.

## Проверка

`repository.layers.audit` обнаруживает основную конфигурацию и расширения из
live SQL и выдаёт для каждого слоя состояние хранилища, общий режим поддержки
и безопасное следующее действие:

```json
{
  "method": "repository.layers.audit",
  "payload": {"base_id": "neft"}
}
```

Ключевые действия в ответе:

- `repository_lock_not_required` — слой явно не подключён к хранилищу;
- `request_and_confirm_repository_capture` — перед записью требуется
  подтверждение захвата;
- `configure_repository_connection_state` — слой нельзя менять, пока не
  установлен один из статусов подключения.

Проверка поддержки выполняется отдельно от хранилища. Для конкретного объекта
используйте `metadata.write.preflight`: разрешение объекта определяет его
`origin`, и адаптер применяет политику найденного слоя, а не клиентский выбор
слоя.

## Захват формы владельца

Для формы документа, справочника, обработки или отчёта область захвата задаётся
точно, без сворачивания к владельцу:

```json
{
  "method": "repository.lock.request",
  "payload": {
    "base_id": "neft",
    "objects": ["Document.тл_Планировщик.Form.ФормаДокументаНовая"],
    "operation": "modify"
  }
}
```

До создания заявки `repository.lock.plan` и сама заявка разрешают форму через
live SQL, получают GUID формы и сохраняют точную каноническую область. После
ручного подтверждения эта сессия не даёт права на соседние формы или модуль
владельца.

Также принимается `Form.<GUID>`. Для него адаптер проверяет связь формы с
владельцем по live SQL; при отсутствии готовой производной записи владельца
выполняется ограниченный SQL-скан форм поддерживаемых типов владельцев. Если
владелец не найден, планирование и заявка завершаются `not_found`, а не
возвращают ложный `ready`.
