Repository Endpoints CLI Usage Analysis · Entire

Repository endpoint map — Entire CLI

How the two planes are wired

Control-plane core (coreapi): coreapi.New() dials the active-context login core; coreapi.NewForCluster(ctx, host) dials the core fronting a specific cluster (discovered via /.well-known/entire-cluster.json). Base path is <core-host>/api/v1. All the entire repo … commands run through the runCore* helpers in cmd/entire/cli/corecmd.go.
Data-plane / entire-api cell (api.Client): two flavors — the data-API/BFF client NewAuthenticatedAPIClient targeting api.BaseURL(), and the per-cell client auth.NewEntireAPICellClient that dials a specific entire-api cell directly with a jurisdictional identity token.

CORE (coreapi) — the entire `repo` command group

Every subcommand of entire repo hits the control-plane core:

Command	HTTP method + path	CLI call site	coreapi send fn
`entire repo create <name>`	`POST /api/v1/repos`	`repo.go:137`	`oas_client_gen.go:955`
`entire repo list <project>`	`GET /api/v1/projects/{projectId}/repos`	`repo.go:176`	`oas_client_gen.go:4476`
`entire repo get <repo>`	`GET /api/v1/repos/{repoId}`	`repo.go:199`	`oas_client_gen.go:2388`
`entire repo delete <repo>`	`DELETE /api/v1/repos/{repoId}`	`repo.go:219`	`oas_client_gen.go:1667`
`entire repo visibility get <repo>`	`GET /api/v1/repos/{repoId}/visibility`	`repo.go:283`	`oas_client_gen.go:2488`
`entire repo visibility set <repo> <vis>`	`PUT /api/v1/repos/{repoId}/visibility`	`repo.go:316`	`oas_client_gen.go:6413`

CELL (entire-api) — repo-scoped calls against a specific cell

These reach a data-plane cell via auth.NewEntireAPICellClient. The api.Client paths are plain strings:

Command	HTTP method + path	CLI call site
`entire experts ...` (resolve owner/repo → ULID)	`GET /api/v1/repos`	`experts_cmd.go:413`
`entire experts ...` (main call)	`POST /api/v1/repos/{repoId}/experts`	`experts_cmd.go:296`
`entire activity` / `entire recap`	`GET /api/v1/me/recap?repo={ulid}`	`activity_cmd.go:66`
`entire api --to cell <path>`	any `/api/v1/...` on the home cell	`api_cmd.go:135`

Endpoints called against BOTH planes (core to resolve, then cell)

entire experts — core GET /api/v1/mirrors and cell GET /api/v1/repos.
entire recap / entire activity — core GET /api/v1/mirrors then cell GET /api/v1/me/recap?repo={ulid}.
entire api ... {repo_id} — core GET /api/v1/mirrors followed by templated request against --to core or --to cell.

DATA-API / BFF (`api.BaseURL()`) — repository-related calls

These use the data-API client against api.BaseURL():

Command	HTTP method + path	CLI call site	client method
`entire search` (`--repo` completion)	`GET /api/v1/repositories?sort=recent`	`search_cmd.go:255`	`ListRepositories`
`entire enable`	`POST /api/v1/cli/enable`	`api/enable.go:35`	`ReportEnable`
`entire search` (code search)	search service on the data-API host	`search_cmd.go:123`	`search` package

Bottom line: all CRUD/mirror management (entire repo …) is core-only; repo content/insight endpoints live on the cells, relying on core lookup to determine the hosting cell.