a981729417
Centralis has shipped the OAuth 2.1 authorization server since b194603, but prod ran with none of it configured, so the connector could only offer a bearer token. buildOAuth() needs a Google client AND a team list; this adds both, plus the Workspace domain. CENTRALIS_TEAM is an allowlist of addresses, not a domain or group rule -- a rule keyed on the domain grants production reads to anyone who can get an address in it, and the group equivalent moves that authority to whoever administers the group. Four addresses, listed: emi.g owner jin.j owner klaudia.j member violet.g member Roles are real gates. owner is everything, including run_on_host, secrets_*, promote and SQL writes; member is the estate's reads plus the writes that become PRs. Identity is re-resolved from this value on every request rather than trusted from the token, so removing a line and restarting revokes someone at once. The audit subjects these derive to -- emi.g, jin.j -- deliberately differ from the CENTRALIS_TOKENS subjects emi and jin. The token registry is for machines now, so a distinct subject is what makes an audit line answer whether a person or a cron job did something. CENTRALIS_GOOGLE_HOSTED_DOMAIN is set because every address is in the Workspace. It is checked server-side as well as hinted to Google, so it narrows who can reach the allowlist; it never populates it. Verified before commit: the vault renders 13 keys that survive `set -a; . <file>` byte-for-byte, and the rendered CENTRALIS_TEAM parses to exactly the four members and capabilities above. |
||
|---|---|---|
| .claude | ||
| .forgejo/workflows | ||
| backend | ||
| docs/onboarding | ||
| frontend | ||
| infra | ||
| observability | ||
| .gitignore | ||
| CLAUDE.md | ||
| CUTOVER-NOTES.md | ||
| Makefile | ||
| README.md | ||
thermograph
The Thermograph monorepo — the split repos reunified (2026-07-22) with full history via subtree merges, while keeping everything the split was actually for: per-domain images, per-domain deploys, and an async FE/BE contract.
Domains
| Dir | What | CI |
|---|---|---|
backend/ |
FastAPI graded-climate API, accounts, notifications (Discord bot, push, mail), data pipeline | build-push → image jinemi/thermograph/backend; deploy |
frontend/ |
Public client: static JS/CSS + SSR pages | same build-push / deploy workflows, matrixed by domain; image jinemi/thermograph/frontend |
infra/ |
Compose (dev, on vps1) + two Swarm stacks co-resident on vps2 (beta, prod), deploy scripts, terraform, SOPS secrets vault, ops cron | infra-sync (host checkout + secrets render), secrets-guard, ops-cron |
observability/ |
Loki + Grafana + Alloy stack | observability-validate |
thermograph-docs deliberately stays its own repo (ADRs + runbooks, no
build artifacts, different change cadence).
New here?
docs/onboarding/ is the developer onboarding
path: orientation, verified local-setup recipes, a per-domain deep dive, the
cross-service contracts that break silently, the release flow, and a list of
which docs in this repo are currently stale.
How CI stays decoupled
Every workflow in .forgejo/workflows/ is path-filtered to its domain: a
push touching only frontend/** builds/deploys nothing else. Images stay
separate (jinemi/thermograph/backend, jinemi/thermograph/frontend, each tagged
sha-<12hex>), deploys stay per-service (infra/deploy/deploy.sh SERVICE=backend|frontend|all), and the API version contract
(GET /api/version, PAYLOAD_VER) still lets FE and BE ship out of lockstep.
The one intentionally coupled piece is pr-build.yml: a single always-running
gate required check that builds only the domains a PR touches (a
path-filtered required check would deadlock auto-merge).
Branch model (unchanged from the split era): PRs → dev, main → beta,
release → prod. Infra isn't environment-staged the same way app images are:
beta's and prod's checkouts (both on vps2) track main; dev's checkout (on
vps1) tracks dev itself, since it's the one environment that isn't a
rehearsal for something downstream.
Before pointing anything live at this repo, read CUTOVER-NOTES.md.