Enhance Entire CLI with Name Resolution · Entire

Bottom line

Two clusters in entire-core are already dead deprecation stubs pointing at the public CLI — safe to delete now. Everything else in entiredb's entire-* tools is either platform-admin/break-glass (no public equivalent) or data-plane git ops (no public equivalent), so leave those.

Delete from entiredb — already live in public `entire`

entiredb verb	Public CLI home	Status in entiredb
`entire-core context list`	`entire auth contexts`	deprecation stub
`entire-core context use`	`entire auth use`	deprecation stub
`entire-core context bind`	`entire auth use`	deprecation stub
`entire-core context current`	`entire auth contexts`	deprecation stub
`entire-core admin mirrors collaborators add`	`entire repo mirror collaborators add`	deprecation stub
`entire-core admin mirrors collaborators list`	`entire repo mirror collaborators list`	deprecation stub
`entire-core admin mirrors collaborators remove`	`entire repo mirror collaborators remove`	deprecation stub

These already print "DEPRECATED. Please use entire …" — the public command is the canonical home. Pure cleanup, no behavior loss.

Keep in entiredb — NOT in the public CLI (don't move)

entire-core admin core: orgs (list/create/add-member/workos), repos import, access, audit-log, users (list/delete/approve), sa (full service-account suite), mirrors create/list/suspend/resume, oidc list-providers, and all grant/revoke-platform-*. These are platform-admin / break-glass operations. The public entire org/repo/grant verbs look similar but are user-privilege control-plane calls — not substitutes for the admin endpoints.
entire-core client api: permissions, me, audit, reauthorize-github — still canonical here.
entire-repo (all 13): clone, get-file, ls, log, diff, compare, files, merge-base, branches, tags, merge, rebase, revert — data-plane git content ops, none exist in the public CLI. The public entire repo group is lifecycle only (create/list/get/delete/mirror), intentionally excludes content ops.
entire-backup, entire-ci, entire-deploy, entire-mock-idp — operator/infra tooling, no public-CLI overlap.

One gray area to decide

entire-core admin orgs create, admin repos import, and admin access vs public entire org create / entire repo create / entire grant. They overlap conceptually but differ in privilege (admin --owner/import/bypass vs self-service). I'd keep the admin ones in entiredb unless you intend to fold the admin flags into the public CLI behind a platform-admin check — that'd be a new migration, which you said not to do.

CLI vs. backend coverage

Noun	CLI today	Backend v1 offers	Verdict
repo	create, list, get, delete	CreateRepo, ListProjectRepos, GetRepo, DeleteRepo	Complete — the model to match
org	create, list	CreateOrg, ListOrgs only (delete = admin-only, no get)	CLI matches backend; can't add get/delete without backend work
project	create, list	CreateProject, ListProjects, ListOrgProjects (delete = admin-only, no get)	CLI matches except one unused method (see below)
grant org	add, list, remove	full triad	Complete
grant project	add, list, remove	full triad	Complete
grant repo	add only	GrantRepoAccess only — no list, no revoke in v1	Glaring asymmetry, but blocked on backend

The real findings

1. Rename is off the table. No Update/Rename/Patch on org, project, or repo anywhere in the v1 API — they're immutable after creation (name, region, cluster placement all fixed). This isn't "complex," it's "doesn't exist." Pursuing it means designing backend mutation endpoints first. I'd punt unless there's real user demand.

2. org/project delete + get are not yours to expose. The backend only has these as admin-only (/api/admin/...). To give users entire org delete / entire project delete / * get, the backend has to promote them to the user-facing v1 surface with proper authz — a privilege-model decision, not a CLI gap.

3. The repo-grant asymmetry is the worst UX wart. You can grant repo add but can never list or remove repo grants. That's a dead-end — needs backend ListRepoGrants + RevokeRepoAccess before the CLI can fix it.

4. Two genuine CLI-only quick wins (backend method exists, CLI just doesn't surface it):

entire project list --org <id> → backend ListOrgProjects. Today project list only does the global list + name filter.
entire grant project remove --provider <p> --provider-user-id <id> → backend RevokeProjectAccessByProvider. Convenience; today removal requires knowing the grantee ULID.

Recommendation

Don't build rename. Backend-blocked and low value vs. cost.
Don't fake org/project delete/get by reaching into the admin API from the public CLI — that crosses the privilege boundary.
File backend asks for: repo-grant list/revoke (the asymmetry), and a decision on user-facing org/project get/delete.
Land the two quick wins now — they're pure CLI and make project/grant project consistent with repo.

Want me to spec the two quick wins, or write up the backend asks as a list you can hand off?