Handover

Goal (COR-389 + your follow-ups)

Consolidate the two auth views, get the CLI fully onto the context-aware/JWT model, and ultimately auto-refresh JWTs on every control-plane call. Broadly: make auth/login UX coherent.

Where we got to — shipped in #1341:

• Auth command surface trimmed from 7 → 5: dropped auth list + auth revoke.
• auth status is now context-aware: profile via /me on the active context's core, shows identity + active context. auth use finally retargets it.
• auth contexts → styled table. logout revokes server-side via entire-core (--all = all sessions on the core).
• Burned all ent_ PAT machinery — the CLI never used PATs; that surface is being sunset.

Key thing we learned (the expensive lesson):

There are two same-shaped "auth/tokens" surfaces — entire-core /api/auth/tokens (login sessions) vs entire.io /api/v1/auth/tokens (legacy ent_ PATs). The CLI was wrongly hitting the PAT one for "sessions" → empty lists + logout 400s. Everything now targets entire-core. Full write-up in the COR-389 Linear comment (corrected) and memory auth-token-surfaces.

What's NOT done (next session):

1. The actual COR-389 deliverable — silent JWT refresh on control-plane calls (contextTokenStore + RefreshPath into defaultManager). Untouched. This is the real prize; everything so far was prerequisite + cleanup.
2. Multi-core retargeting for the rest of the control plane — org/repo/project/grant (via coreapi.New()) still use static AuthBaseURL. Only auth status was retargeted. Same bug pattern as the one we just fixed.

Verification gaps:

Go lint clean, per-package tests green; full mise run test:ci (integration + canary) not run. None of it exercised against a live core — please sanity-check entire auth status / logout against your local eu.auth.entire.io.

What we want to work on today:

Make sure that any time we hit an upstream URL from this CLI, we use the same mechanism to discover which "auth context" to use (as in contexts.json).

Example:

ENTIRE_API_BASE_URL=https://partial.to ENTIRE_AUTH_BASE_URL=https://us.auth.partial.to entire activity

What we prefer is to be able to call: ENTIRE_API_BASE_URL=https://partial.to entire activity and have it automatically know to use the us.auth.partial.to auth context.

We need:

https://partial.to to expose /.well-known/entire-auth.json too, just like entire-server does to say "I accept auth from login servers [au.auth.partial.to, us.auth.partial.to]".

Bottom line

The mechanism you're describing already exists — you don't need a new /.well-known/entire-auth.json, and entire-server likely needs zero changes. The blast radius is a wiring job in the CLI, not new protocol/server work. Two facts change the framing:

1. The discovery endpoint already exists: /.well-known/entire-cluster.json on the data plane returns core_urls (the login/core servers it accepts auth from).
2. The CLI already has the full resolver in internal/entireclient/clusterdiscovery.

Audit: who resolves hosts how

Deliverables

• api.AuthBaseURLOverridden() + auth.insecureHTTPEnabled() readers
• auth.ResolveControlPlaneTarget() — the shared resolver
• rewire coreapi.New() through it
• unit tests for precedence + the token-source wiring
• a short design doc in the "one core + resource servers" framing, recording what's deferred

What today explicitly does NOT touch:

• Cluster (git-remote-entire) — already context-aware, nothing to do.
• entire.io API family (activity/search/trail/dispatch) — deferred; needs the new entire-api.json well-known on your side first + the audience token-exchange. Design only.

Conclusion

All tests pass; lint clean. Since entire auth use <ctx> now retargets org/repo/project/grant, they follow the active auth context instead of the static default core, and refresh their token silently.