Сейчас satisfactory-cli.php сломается, если нет папки vendor (чего не бывает, когда сервис собран в PHAR и запущен на сервере). У меня два решения - мы либо собираем отдельный satisfactory-cli.phar, либо добавляем кли-команды к основному server.php / satisfactory.phar - но тогда надо менять механизм вызовов. Например, вызывать сервер с ключом --serve (то есть satisfactory.phar --serve --config=/path/to/config --verbose), а cli-команды - без --serve . Что думаешь?
Ключевой факт: внутри satisfactory.phar уже есть всё, что нужно CLI — app/*.php (AppConfig/Database/Setup) и vendor/ (включая arris.toolkit.cli-console — он в require). В phar не попадает только сам файл satisfactory-cli.php (~180 строк задач). Поэтому:
Моё мнение: вариант 2 (CLI в основном phar). Отдельный satisfactory-cli.phar дублирует весь код (server + app + vendor ≈ тот же размер) ради 180 строк — два артефакта, две сборки в build.sh, два файла в DEB и makefile install. Никакого выигрыша по размеру или изоляции.
Но с одной поправкой к твоей схеме. Если сделать --serve обязательным, то после обновления phar без синхронного обновления юнита сервис молча падает: текущий ExecStart в debian/satisfactory.service — --config=... --verbose без --serve → попадёт в CLI-режим «нет задач» → exit(1). Это футган на деплое (на боевой машине юнит обновляется отдельно от phar).
Предлагаю обратную диспетчеризацию — сервер остаётся дефолтом, CLI маркируется своими флагами:
satisfactory.phar --serve --config=... --verbose→ сервер (явно)satisfactory.phar --config=... --verbose→ сервер (старый юнит продолжает работать без правок)satisfactory.phar --delete=vendor/pkg/--clear/--help→ CLI (и--configобщий для обоих режимов)
Реализация тривиальная: перенести deletePackage/clearCache/removeTree в app/CLI.php (finder box.json подхватит автоматически), а в server.php сделать роутинг по флагам перед стартом сервера. App::init() и так уже грузит+валидирует конфиг — CLI переиспользует его.
Если ок — реализую. Если принципиально «--serve обязателен», тогда аккуратно поправим debian/satisfactory.service и README в той же итерации, но живой юнит на сервере всё равно придётся обновить руками.