`opm config` перезаписывает `opm.cfg` урезанным JSON и теряет неизвестные ключи

[EvilBeaver]

Команда opm config сохраняет настройки через ПараметрыПриложенияOpm.СохранитьТекущиеНастройки(), которая не делает read-modify-write исходного файла, а собирает новый JSON из in-memory модели НастройкиOpm.

В результате при любой записи из конфига пропадают корневые ключи и поля элементов СервераПакетов, которые модель не знает, но которые runtime уже использует или пользователь мог добавить вручную.

Где в коде

• src/cmd/Классы/КомандаOpm_Config.os — вызов СохранитьТекущиеНастройки()
• src/cmd/Модули/ПараметрыПриложенияOpm.os:
  • СохранитьТекущиеНастройки() → НормализоватьНастройкиДляЗаписи()
  • в записываемый документ попадают только три ключа: СоздаватьShСкриптЗапуска, Прокси, СервераПакетов
• src/core/Модули/НастройкиOpm.os — модель не содержит ТокенПубликацииПакетов и произвольных полей remote
• src/cmd/Классы/КомандаOpm_Push.os — ТокенПубликацииПакетов читается напрямую из сырого JSON файла, минуя модель

Шаги воспроизведения

1. Создать opm.cfg (в каталоге, откуда будет запускаться opm config):

{
  "ТокенПубликацииПакетов": "ghp_xxxxxxxx",
  "СоздаватьShСкриптЗапуска": false,
  "Прокси": {
    "ИспользоватьПрокси": false
  },
  "СервераПакетов": [
    {
      "Имя": "myhub",
      "Сервер": "https://hub.example",
      "Порт": 443,
      "ПутьНаСервере": "/download/",
      "РесурсПубликацииПакетов": "/push",
      "CustomField": "keep-me"
    }
  ],
  "FutureSetting": true
}

2. Выполнить любую команду, которая сохраняет настройки, например:

opm config --winCreateBashLauncher true

3. Открыть записанный opm.cfg.

Фактический результат

• Ключ ТокенПубликацииПакетов удалён → opm push без --token перестаёт находить токен в конфиге.
• Ключ FutureSetting удалён → любые будущие/пользовательские корневые поля не сохраняются.
• В элементах СервераПакетов пропадают неизвестные поля (например, CustomField).
• При чтении конфига отсутствующие значения подменяются дефолтами и затем материализуются в файле как явные значения (ПутьНаСервере → "/", РесурсПубликацииПакетов → "/", Порт → 80, Приоритет → 0 и т.д.).
• Запись сервера без Имя при чтении получает сгенерированное ДопСервер_N, которое после сохранения фиксируется в файле.

Ожидаемое поведение

Сохранение настроек должно быть lossless read-modify-write:

• прочитать существующий JSON целевого файла;
• обновить только те ключи/поля, которые команда реально меняет;
• сохранить ТокенПубликацииПакетов, прочие неизвестные корневые ключи и неизвестные поля элементов СервераПакетов;
• не подставлять дефолты в файл там, где пользователь их явно не задавал.

Влияние

• Push: потеря ТокенПубликацииПакетов ломает сценарий «токен только в конфиге».
• Расширяемость конфига: нельзя безопасно хранить дополнительные поля в opm.cfg.
• Блокер для opm remote: CRUD remote не должен использовать СохранитьТекущиеНастройки(); нужен отдельный lossless RMW (см. план по управлению remote).

Предлагаемое направление исправления

1. Вынести общий механизм адресной записи JSON (read → patch → atomic write).
2. Перевести opm config на обновление только затронутых секций (Прокси, СоздаватьShСкриптЗапуска), без пересборки всего документа из НастройкиOpm.