Generated compose emits FORGE_BOT_USER_LLAMA — legacy name, should derive from forge_user #849

New issue

Closed

opened 2026-04-16 10:09:52 +00:00 by dev-bot · 0 comments

dev-bot commented

2026-04-16 10:09:52 +00:00

Collaborator

Problem

The TOML-driven compose generator emits the line:

FORGE_BOT_USER_LLAMA: "dev-qwen"

in the agents-llama service block (see /home/johba/disinto/docker-compose.yml line 353, generated from lib/generators.sh). The suffix _LLAMA is a hardcoded legacy name from the ENABLE_LLAMA_AGENT=1 era.

This clashes with the naming convention used for every other per-agent env var, which is <BASE>_<FORGE_USER_UPPER> (dashes → underscores, uppercased). See FORGE_TOKEN_DEV_QWEN, FORGE_PASS_DEV_QWEN for examples. The canonical form would be FORGE_BOT_USER_DEV_QWEN.

Why fix

Any downstream code reading "which forge user is this service running as?" has to know both forms — fragile.
Onboarding new hired agents produces inconsistent env-var names unless the generator is patched.
The environment becomes noisy once multiple [agents.X] blocks exist (e.g. dev-qwen, review-qwen) since they would all emit _LLAMA regardless of forge user.

Fix

In lib/generators.sh, derive the suffix from forge_user the same way FORGE_TOKEN_* / FORGE_PASS_* are derived:

FORGE_BOT_USER_${forge_user^^//-/_}: "${forge_user}"

Update any consumer (entrypoint, bin/disinto helpers) to prefer the new form and fall back to the legacy form during one deprecation window, then drop the fallback.

Acceptance

docker-compose.yml emitted for dev-qwen contains FORGE_BOT_USER_DEV_QWEN (not _LLAMA).
Consumers read the new form; legacy form emits a deprecation warning or is gone.
No agent-name-specific hardcodes remain in lib/generators.sh for this field.

Related: #846, #847.

## Problem The TOML-driven compose generator emits the line: ``` FORGE_BOT_USER_LLAMA: "dev-qwen" ``` in the `agents-llama` service block (see `/home/johba/disinto/docker-compose.yml` line 353, generated from `lib/generators.sh`). The suffix `_LLAMA` is a hardcoded legacy name from the `ENABLE_LLAMA_AGENT=1` era. This clashes with the naming convention used for every other per-agent env var, which is `<BASE>_<FORGE_USER_UPPER>` (dashes → underscores, uppercased). See `FORGE_TOKEN_DEV_QWEN`, `FORGE_PASS_DEV_QWEN` for examples. The canonical form would be `FORGE_BOT_USER_DEV_QWEN`. ## Why fix - Any downstream code reading "which forge user is this service running as?" has to know both forms — fragile. - Onboarding new hired agents produces inconsistent env-var names unless the generator is patched. - The environment becomes noisy once multiple `[agents.X]` blocks exist (e.g. `dev-qwen`, `review-qwen`) since they would all emit `_LLAMA` regardless of forge user. ## Fix In `lib/generators.sh`, derive the suffix from `forge_user` the same way `FORGE_TOKEN_*` / `FORGE_PASS_*` are derived: ``` FORGE_BOT_USER_${forge_user^^//-/_}: "${forge_user}" ``` Update any consumer (entrypoint, bin/disinto helpers) to prefer the new form and fall back to the legacy form during one deprecation window, then drop the fallback. ## Acceptance - `docker-compose.yml` emitted for `dev-qwen` contains `FORGE_BOT_USER_DEV_QWEN` (not `_LLAMA`). - Consumers read the new form; legacy form emits a deprecation warning or is gone. - No agent-name-specific hardcodes remain in `lib/generators.sh` for this field. Related: #846, #847.