Иерархия конфигурации

Несколько источников настроек действуют одновременно. Важно понимать, что перекрывает что, чтобы не искать параметр «не там».

Порядок силы (от сильного к слабому)

Параметры командной строки при одном запуске
    ↓
odpm.json и user_settings.json (файлы в каталоге проекта / в git)
    ↓  (в whitelist-строках: ${VAR} ← process env, затем effective .env: project поверх ~/.odpm/.env)
файл .env в каталоге проекта (overlay)
    ↓
файл ~/.odpm/.env (базовый профиль пользователя)
    ↓
переменные окружения оболочки (при создании .env без диалога)
    ↓
встроенные значения по умолчанию odpm

Два уровня .env при чтении (4.7)

При чтении odpm объединяет оба файла, если они существуют:

1. ~/.odpm/.env — база (общие пути, SSH, locale, значения по умолчанию для всех проектов).
2. .env в каталоге odpm-окружения — overlay; совпадающий ключ перекрывает home.

Итоговый effective dict используется для портов, сценария, ${VAR} в manifest и раннего ODPM_LOCALE (см. locale.md). Подробнее: env-dotenv.md, ADR-013.

При записи (мастер первого запуска, non-interactive create) по-прежнему один primary файл: project .env, если он уже есть, иначе ~/.odpm/.env. odpm не копирует home в project автоматически — в project достаточно указать только отличающиеся ключи.

Ситуация	Поведение
Только home	Как раньше при отсутствии project .env
Только project (полный)	Как раньше при наличии project .env
Оба, разные ключи	Merge: home fill-in + project override
Оба, один ключ	Значение из project .env

Сгенерированные файлы

docker-compose.yml, .odpm/runtime/config.json, .odpm/database/last_run.json, корневой .dockerignore генерируются odpm из описания проекта и сценария. Их не следует считать местом «ручной правды» — см. сгенерированные файлы и состояние PostgreSQL.

Фиксация версий git

При работе с репозиториями: --no-git-update сильнее --update-lock, затем существующий lock-файл, затем конец ветки / дата nightly. Подробнее: deps.lock.json.