feat: discover contexts on login, select with ctx use

[scotwells]

What changes for users

No more --project or --organization on every command.

Before

datumctl auth login
datumctl get organizations              # find your org ID
datumctl get projects --organization X  # find your project ID
datumctl get dnszones --project Y       # pass it on every command, forever

After

datumctl login                          # auth + pick a context in one step
datumctl get dnszones                   # just works

New commands

Command	What it does
datumctl login	Authenticate (PKCE, device, or machine-account) and select a default context
datumctl login --no-browser	Device-code flow for headless / CI environments
datumctl login --credentials FILE	Machine account login via credentials file
datumctl logout [email | --all]	Remove credentials
datumctl whoami	Show who you are and what context you're in
datumctl ctx	List available contexts (tree view by org)
datumctl ctx --refresh	Pull fresh org/project list from the API
datumctl ctx use [context]	Switch context, interactive picker if no argument
datumctl auth list	List authenticated users
datumctl auth switch [email]	Switch users (restores their last context)

Resource commands (get, apply, create, etc.) automatically use the active context.

Removed commands

Command	Replacement
datumctl auth login	datumctl login (all auth modes consolidated here)
datumctl config *	datumctl ctx

First login

Run datumctl login. A browser opens for authentication, then the CLI fetches your orgs and projects and shows a picker:

✓ Authenticated as Jane Doe (jane@acme.com)

Discovering organizations and projects...

You have access to 2 organization(s):

  acme-corp (3 project(s))
  personal (1 project(s))

┃ Select a context to work in
┃ > acme-corp  (Acme Corp)
┃     infra
┃     web-app
┃     billing-api
┃   personal
┃     sandbox

✓ Context set to acme-corp/infra

If you only have one project, the picker is skipped.

Day-to-day

$ datumctl ctx
  DISPLAY NAME         NAME                       TYPE      CURRENT
  Acme Corp            acme-corp                  org
    Infrastructure     acme-corp/infra            project   *
    Web App            acme-corp/web-app          project
  Personal             personal                   org
    Sandbox            personal/sandbox           project

$ datumctl ctx use acme-corp/web-app
✓ Switched to acme-corp/web-app

$ datumctl whoami
User:         Jane Doe (jane@acme.com)
Context:      acme-corp/web-app
Organization: Acme Corp (acme-corp)
Project:      Web App (web-app)

Switching users

$ datumctl auth list
  USER                 STATUS
  jane@acme.com        Active
  bob@acme.com

$ datumctl auth switch bob@acme.com
✓ Switched to Bob Smith (bob@acme.com)
  Context:  acme-corp/billing-api

Each login session remembers its last-used context, so switching users drops you right back where you left off.

CI and scripting

For non-interactive use, environment variables override the active context per-invocation:

DATUM_PROJECT=my-project datumctl get dnszones
DATUM_ORGANIZATION=my-org datumctl get projects

--project and --organization flags still work too. For machine-to-machine auth:

datumctl login --credentials ./my-key.json --hostname auth.datum.net

Existing users

datumctl auth login has been removed — use datumctl login instead. It supports all the same auth modes (PKCE, --no-browser for device flow, --credentials for machine accounts).

Pre-existing keyring credentials are bootstrapped into a v1beta1 session on first run, so previously authenticated users won't have to log in again. They will, however, want to run datumctl ctx use (or rely on DATUM_PROJECT/DATUM_ORGANIZATION) to pick a context.

Anyone with a kubeconfig generated by an earlier datumctl auth update-kubeconfig will need to re-run the command — the kubectl exec plugin args now reference session names rather than the legacy format.

🤖 Generated with Claude Code

[gianarb]

this looks good to me, do you want to get it out of draft so we can move it over and merge?