Decap is served from vienalatina.com and posts its OAuth code to
git.vienalatina.com/login/oauth/access_token from the browser. Gitea disables
CORS by default, so the browser discarded the response and Decap surfaced it
as "TypeError: Failed to fetch" after a successful authorize — the login looks
broken at the last step, with nothing wrong on either side individually.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NizVpJ2dwzCbjCrTLCjeHn
The block was parked behind a comment marker until the domain's A record
pointed at this server. It does now, so the checked-in config should match
what is actually serving; leaving it commented meant a redeploy from the
repo would silently take the site down.
Also corrects the header note to say why the order is DNS-then-reload: the
ACME HTTP-01 challenge for vienalatina.com can only pass once the domain
already resolves here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NizVpJ2dwzCbjCrTLCjeHn
- infra/caddy/Caddyfile: git.* and ci.* proxies live now; main-site block
(with WP 301 redirects) commented until cutover day
- infra/gitea and infra/woodpecker: Docker Compose bound to localhost
behind Caddy, with .env.example for the Woodpecker OAuth credentials
- docs/server-setup.md: every command from ordering the CX22 through the
end-to-end translation test, plus the cutover-day checklist
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017z2rT1oN7vMS4ggo23n5WG
