Provider setup and parity across deployment rows

The infrastructure command creates cloud resources; an accountable operator must still authorize provider accounts, contracts, domains, and organization access. Treat each deployment row as a separate provider attachment. Store row identities and public coordinates in its external config.toml; store credentials in its encrypted secrets.enc.yaml. The approved operator system supplies the row-to-provider mapping. The source repository contains no provider IDs, callback host map, organization slugs, or per-row operational checklist.

For browser sign-in, configure one OAuth client per row and derive its exact callback from that row's NAVIGATOR_PUBLIC_HOST (/auth/callback). Keep each client restricted to its own host and project. Store its client ID in the external config and its client secret in the encrypted secret file. Provider consoles may require an authorized human to set consent branding, audience, and test users; the CLI cannot establish those approvals.

For repository access, create an organization-owned application with only the repository permissions the installation needs. Keep the organization, application ID, and installation identity with the selected private row; keep its private key encrypted. Do not reuse one row's application credentials or webhook secret in another row. Apply the principle of least privilege and review the installation scope with the organization's owner.

Rotate credentials at the provider first, then write the replacement directly into the selected row's encrypted file with sops. Synchronize through the CLI using the same external root, then verify the row's provider smoke test. Never place plaintext credentials in Git, issue text, chat, screenshots, or shell history. A dry-run can check names and local configuration, but it cannot prove that a provider account, nonempty credential, contract, or callback is valid.

Provider-specific accounts may require human approval, paid plans, domain verification, delegated Workspace authority, or production eligibility. Keep those decisions and their evidence in the approved operator system. Use synthetic data for smoke tests and verify that each test remains confined to the selected row's external resources.