## 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?