workbench can't start from a fresh checkout — WORKBENCH_DJANGO_SECRET_KEY has no default or documented generation step

[man4ish]

Finding

omnibioai-workbench's DJANGO_SECRET_KEY is wired to WORKBENCH_DJANGO_SECRET_KEY in this repo's docker-compose.yml with no fallback default — unlike almost every other secret in the same file (e.g. MYSQL_ROOT_PASSWORD:-omnibioai, AUTH_SECRET_KEY:-change-me):

# docker-compose.yml, workbench: service, environment: block
DJANGO_SECRET_KEY: ${WORKBENCH_DJANGO_SECRET_KEY}
DJANGO_SECRET_KEY_FALLBACKS: ${WORKBENCH_DJANGO_SECRET_KEY_FALLBACKS:-}

WORKBENCH_DJANGO_SECRET_KEY does not appear anywhere in this repo's .env.example or SECURITY-COMPOSE-HARDENING.md — confirmed by grep, zero hits in either file. Every other required-secret in .env.example (MYSQL_ROOT_PASSWORD, AUTH_SECRET_KEY, LICENSE_SECRET, LIMSX_DJANGO_SECRET_KEY, LIMSX_FIELD_ENCRYPTION_KEY, JUPYTER_TOKEN, NEO4J_PASSWORD, etc.) has a documented "AUTO-GENERATED on first launch" note and, where the format matters (e.g. the Fernet key), an explicit generation command. WORKBENCH_DJANGO_SECRET_KEY has neither.

What happens on a fresh checkout

omnibioai-workbench/omnibioai/settings.py:

_DEV_INSECURE_SECRET_KEY = "django-insecure-t_!1jds!1+(68=ti3-xr3k*=d%%w3bi1&0ti_@6kwl4z)934a1"
SECRET_KEY = os.environ.get("DJANGO_SECRET_KEY", _DEV_INSECURE_SECRET_KEY)
...
DEBUG = os.environ.get("DJANGO_DEBUG", "false").lower() == "true"
...
if not DEBUG and SECRET_KEY == _DEV_INSECURE_SECRET_KEY:
    # refuses to start

With the var unset, ${WORKBENCH_DJANGO_SECRET_KEY} (no :- default) resolves to an empty string, not an absent variable — Compose still sets DJANGO_SECRET_KEY="" inside the container. os.environ.get("DJANGO_SECRET_KEY", _DEV_INSECURE_SECRET_KEY) only falls back to the dev key when the variable is absent, so it returns "" here instead. Django itself rejects an empty SECRET_KEY (ImproperlyConfigured) independent of this app's own dev-key refusal check, which only fires when SECRET_KEY still equals the literal dev-key string. Net effect: cp .env.example .env && docker compose up -d workbench on a fresh checkout should fail at Django startup, with nothing in the error pointing back to WORKBENCH_DJANGO_SECRET_KEY or how to generate one.

(This chain is derived from reading docker-compose.yml's interpolation syntax and settings.py's logic, not reproduced end-to-end against a real fresh checkout — flag it if actual behavior differs.)

Either way, nothing in this repo's own docs tells a new deployer this var exists, that it's required, or how to generate a value for it.

Impact

A fresh clone of omnibioai-studio cannot bring up workbench — the platform's core service — without someone first reading omnibioai-workbench's Django settings source to discover this variable exists. There's no equivalent gap for the other Django secret in this same file (LIMSX_DJANGO_SECRET_KEY is documented and auto-generated).

Fix options

• Add WORKBENCH_DJANGO_SECRET_KEY to .env.example, following the existing "AUTO-GENERATED on first launch" convention used for the other Django/auth secrets in the same file, or
• Have the Studio app's first-launch secret generation (already covers MYSQL_ROOT_PASSWORD, AUTH_SECRET_KEY, etc. per .env.example's own comments) generate this one too.

Cross-reference

Found during a documentation audit of omnibioai-workbench; that repo's README (commit 2887d6e2) now documents this gap explicitly in its Environment Variables section, but documenting it isn't fixing it — this issue tracks the actual fix, filed against omnibioai-studio since .env.example and the first-launch generation logic both live here.