# Domains and OAuth

MMI owns the central project registry and provisioning workflows. Read
`mmi-cli oracle org project get <owner/repo> --json` before changing hostnames or login settings.
Use the declared edge domains for each stage; do not guess hostnames from a slug or create a
second DNS/deployment control plane in a product repository. New project setup goes through
[bootstrap](../../bootstrap/SKILL.md). An MM-Work suite module serves from its own
`dev.<name>.mutmut.work` and `<name>.mutmut.work` hosts, with no rc host; bootstrap declares them
with `--var SUITE=mm-work`.

Cloudflare owns public DNS and edge TLS. Preserve unrelated records during an authorized change.
The Hub creates each registered host's proxied record during bootstrap and never edits an existing
one; check or re-run it with `mmi-cli devops runtime edge dns status|ensure <owner/repo> <stage>`.
A dev or rc host also needs its advanced edge certificate: `mmi-cli devops runtime edge cert status|ensure <owner/repo> <stage>`.
A dev stage is private only after its independent edge-block check succeeds. A configured record
or successful deployment alone does not prove access control. Use [stage](../../stage/SKILL.md)
for the supported private live workflow.

Inbound mail on `mutmut.work` is Hub-owned: Cloudflare Email Routing sends every address to MM-Work's
inbound mail Worker, which delivers to the owning module. A product never adds MX records or routing
rules itself; it asks MM-Work for an address.

## Google OAuth

An MM-Work suite module gets no Google client: it signs in through the MM-Work pass and reaches
Google only via `ctx.act`. Any other eligible project uses one Google web client across local, dev, rc, and main, not one per stage.
The registry declares OAuth metadata and extra callback paths for additional login/connect flows.
Generate the current origins and redirects with
`mmi-cli vault org oauth plan --repo <owner/repo> --json`; do not assemble a copied URI list.
The plan includes the declared edge hosts, callback paths, and supported loopback redirects.

Client creation and editing are human Google Console actions. Add the planned origins and redirects
to that client. Store its downloaded credentials through
`mmi-cli vault org oauth set-creds --repo <owner/repo>` using the file on stdin, never its contents
in chat or command arguments. Keep credential files outside the repository and remove the temporary
download after the authorized import. The stored pair is shared across stages through the vault.

Run `mmi-cli vault org oauth verify --repo <owner/repo>` before removing a working redirect.
Verification probes redirect acceptance; it does **not** inspect registered JavaScript origins.
Reconcile those against the plan in Console. Check actual authority and use the
[vault guide](vault.md) for the credential boundary.