Eliminate the service-token split-brain across deploys. Previously the token had
no defined origin: quinn.admin generated its own (openssl rand) into admin
secrets, while quinn.my/quinn.ai read it from vps SSO secrets, and quinn.sso
never managed it (so the "re-run quinn.sso deploy to generate it" errors were
false). Any divergence 401'd service-to-service calls.
New model: the deploy host (plum) owns one 0600 file
($HOME/.config/quinn-secrets/quinn-my.service-token); quinn.sso deploy seeds it
into vps SSO secrets (the distribution point), and my/admin read it from there.
The black gateway reads the plum file directly (no local SSO secrets) — already
shipped in quinn.mcp/deploy.
- quinn.sso/deploy.sh: inject the plum token into the provisioning heredoc
(bash -s -- "$tok") and upsert QUINN_MY_SERVICE_TOKEN into SSO secrets.
- quinn.admin/deploy.sh: stop self-generating; read from SSO secrets + upsert
every deploy (matches quinn.my).
- quinn.my/deploy.sh: correct the now-accurate comment/error wording.
Out of scope: quinn.ai (uses only JWT_SECRET), hotel-scout/price-watcher
(not deployed; manual CHANGE_ME envs).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
c7a56e3588