Real-world failure: configure_caddy_for_service's own domain prompt
defaults to "<subdomain>.${SITE_DOMAIN}", which only equals
$DOMAIN_NAME if SITE_DOMAIN happens to be set to match. In practice
SITE_DOMAIN is never set when this service is run by name (e.g.
`sudo ./setup.sh asterisk-do`), since that path skips setup.sh's own
site-defaults wizard — so the reconstructed default silently came out
wrong/blank, and a user had to guess whether to type the SIP domain or
something else at a bare "Domain [ ]:" prompt.
There's exactly one correct domain for this site block — $DOMAIN_NAME,
the same one already used for SIP — so it's no longer asked for at
all. This inlines the same Caddyfile-writing logic
configure_caddy_for_service uses (backup, dedup check, reload; local
and remote-Caddy modes both preserved) but targets $DOMAIN_NAME
directly. The only remaining question is a plain yes/no to proxy it.
Verified the block-generation logic directly against a real Caddy
directory + domain (produces the exact expected Caddyfile entry), plus
a full end-to-end regression run.
Claude
57797c4ad7