wb monarch setup will write the front-door secret into a git-tracked config file

[LucasWaki]

Found by the adversarial review of the genesis-loop change set, 11 September 2026.
Open at 492f2a4. Latent, not leaked — nothing is exposed in the repository today.

Current state, verified

The four tracked knowledge-base files hold the front door without a secret:

config/products/appworld.monarch-kb.yaml:16
config/products/enterprise-ops-gym.monarch-kb.yaml:6
config/products/simulated-apps.monarch-kb.yaml:52
config/products/tau2-retail.monarch-kb.yaml:6

  shim_public_url: https://ailabs-studio-production.up.railway.app/front-door

That value is the public Railway hostname and carries no secret segment. Checked
before filing; nothing needs to be rotated or purged from history now.

Why it will not stay that way

wb_orchestrator/monarch_setup.py:409 — _write_kb persists shim_public_url
into config/products/<product>.monarch-kb.yaml, which git tracks, and
public_front_door_url now appends STUDIO_FRONT_DOOR_SECRET to that URL. The
secret is set on Railway and the repository is public. The next wb monarch setup
against a hosted front door writes the secret into a tracked file, and the next
push puts it in history, where deleting the file does not remove it.

Fix

Write the reference rather than the value — ${STUDIO_FRONT_DOOR_SECRET} — the way
the harness files already do:

config/harnesses/monarch.yaml:13

  shim_public_url: ${FRONT_DOOR_URL}

wb_orchestrator/config.py _hashed already carries this convention (secrets by
name, never by value). A second benefit: a secret rotation stops moving the config
hash, which today would make two otherwise identical rounds look like different
configurations.