Odata1c Policy

---
name: odata1c-policy
description: >-
  Ведёт владельца шлюза odata1c-gate к команде `odata1c policy …`, которая меняет политику гейта
  конкретной базы: что скрывать токеном, что оставить открытым, какой класс присвоить полю.
  Применяй, когда пользователь просит «скрой поле», «почему это поле пришло токеном», «открой
  название», «добавь свой класс», «настрой политику гейта» — и в любой похожей просьбе изменить,
  что именно закрывает гейт. Модель сама находит сущность и поле тулами чтения, объясняет словами,
  что изменится, и даёт ровно одну команду для терминала владельца; в файлы политики не пишет и
  команду не выполняет.
---

# odata1c-policy

Политику базы — что скрывать и что оставить открытым — хранит файл владельца
`bases/<база>/policy.yaml`; рядом лежит авторазметка `bases/<база>/policy.auto.yaml`, которую
пишет реиндекс и которую редактировать не нужно. Правило меняет только человек командой
`odata1c policy …` в своём терминале — как `odata1c reveal`. Тула MCP для изменения политики нет
и не будет: содержимое полей 1С (комментарии, названия) может подтолкнуть модель открыть поле,
которое открывать не просили, — решение владельца зафиксировано в ADR-0015. Подробности классов и
разделов — тема `odata1c_info("policy")`, здесь — только порядок действий.

## Правило

Модель никогда не пишет в `policy.yaml` сама и никогда не выполняет `odata1c policy …` за
владельца — ни через инструмент записи файла, ни через Bash, даже если владелец разрешил Bash без
подтверждений. Команду печатает модель, набирает и запускает — владелец.

## Пять шагов

1. **Понять, что нужно.** Скрыть сущность целиком, открыть конкретное поле или назначить полю
   свой класс — уточните, если из формулировки не ясно, о какой базе и какой сущности речь.

2. **Найти сущность и поле.** `odata1c_find_entity` — по части названия, если точное имя
   неизвестно; `odata1c_describe_entity` — состав полей, у каждого виден действующий класс гейта
   (без источника — кто его назначил, владелец или авторазметка, показывает только ресурс
   `odata1c://policy/{base}`, пометкой `владелец`/`авто`). Не берите имя из памяти или из данных
   1С — берите то, что вернул тул: правило, записанное с опечаткой, `odata1c policy check` в
   шаге 4 отклонит до записи, но лучше не тратить ход владельца на отказ.

3. **Показать, что стоит за правилом.** Для «открыть» — назовите класс, который сейчас скрывает
   поле, и что будет видно после `keep`: конкретное реальное значение из базы не показывайте — вы
   видите его как токен и должны объяснить последствие словами, а не примером. Для «скрыть» —
   `odata1c_describe_entity` покажет табличные части и наборы записей сущности: предупредите, что
   вместе с ней исчезнут и они, и сама сущность перестанет находиться `find_entity`.

4. **Дать одну команду.** Ровно одна строка для терминала владельца, без вариантов на выбор:

   ```text
   odata1c policy hide <база> <Сущность>                скрыть сущность целиком
   odata1c policy open <база> <Сущность.Поле>            открыть поле (класс keep)
   odata1c policy set  <база> <Сущность.Поле> <класс>    назначить полю класс
   ```

   Если база ещё не проиндексирована, `hide` и `set` с закрывающим классом откажут («имя не
   проверено»): назовите владельцу `odata1c reindex <база>` как первый шаг. `open` (класс `keep`)
   работает и без индекса.

   `policy hide` без `--yes` сама спросит подтверждение в терминале и покажет число дочерних
   объектов; на уже скрытой сущности она ничего не меняет и завершается кодом 0 — предупредите
   владельца, что повторная команда не опасна, но и не нужна. Каждая команда после записи сама
   выполняет `odata1c policy check <база>` и печатает, что изменилось, — отдельно просить об этом
   не нужно.

   **Свой класс (`custom:<имя>`)** командой не заводится — такой команды нет. Раздел `custom`
   владелец дописывает в `policy.yaml` от руки (это его файл, реиндекс его не трогает); шаблон
   файла показывает формат (`fields`, `regex`). Только после этого `policy set <база>
   <Сущность.Поле> custom:<имя>` назначает класс полю. Объясните это владельцу, если он просит
   «добавь свой класс», — не выдумывайте отдельную команду для этого шага.

5. **Проверить результат.** Правка `policy.yaml` действует на следующий вызов без перезапуска
   демона (в отличие от `daemon.yaml`) — контрольный запрос можно делать в этом же диалоге:
   - после `open`/`set` — `odata1c_describe_entity` того же поля должен показать новый класс
     гейта; что источник теперь `владелец`, подтвердит ресурс `odata1c://policy/{base}` (модели)
     или `odata1c policy show <база>` (владельцу в терминале) — `describe_entity` источник не
     показывает;
   - после `hide` — `odata1c_find_entity` больше не находит сущность (Ruling 29: скрытая сущность
     не называется ни в одном ответе модели, включая ресурс `odata1c://policy/{base}`).

## Типовые отказы `policy check` (код 1 при `error`, файл при этом уже записан)

- **«сущность/поле не найдено в индексе»** (+ похожие имена) — опечатка в написанной команде или
  индекс базы устарел; сверьте написание с ответом `find_entity`/`describe_entity`, при
  расхождении с реальным составом базы — `odata1c reindex <база>`.
- **«класс неизвестен; допустимые: …»** — сверьте класс с перечнем темы `odata1c_info("policy")`
  или шапки `policy.yaml`; свой класс требует префикса `custom:`.
- **«класс custom:<имя> не объявлен»** — в `policy.yaml` нет раздела `custom.<имя>` (см. шаг 4).
- **«свой класс custom:<имя> не задаёт ни fields, ни regex»** — раздел `custom.<имя>` есть, но
  пуст; дополните его вручную.
- **`warning`: «правило не действует: сущность скрыта»** — на поле уже скрытой `hide`-сущностью
  назначен `keep`; правило безвредно, но бессмысленно — можно оставить или удалить.
- **`warning`: «индекса нет: имена сущностей и полей не проверены»** — у базы ещё нет индекса
  метаданных; правила запишутся, но опечатки в именах `check` не поймает до
  `odata1c reindex <база>`.