Control Plane Delete and Revoke Safety

I'll leave the finding-resolution to you (it's a visible external state change you didn't ask for).

Bottom line

Fixed trail #642's current finding — delete commands echoed the user's input instead of the resolved ULID. Committed on feat/control-plane-crud-gaps (rebased clean on origin/main).

• Finding: repo delete (and the identical latent bug in org/project delete) printed args[0], so a name-based delete confirmed a name while the op used a ULID — ambiguous when names are reused.
• Fix: added resolvedRefLabel(ref, id) in resolveref.go → renders name (ULID) for names, bare ULID when the arg was already a ULID. Wired into all three delete success messages.
• Tests: added TestResolvedRefLabel; mise run fmt + lint clean (0 issues); resolveref tests pass.
• Commit: eb2c0db28e. Not pushed.

Notes:

• fmt's --fix pass also stripped three now-unused //nolint:ireturn directives in checkpoint/open.go and strategy/manual_commit.go — unrelated to the finding, so I left them uncommitted in the working tree. Discard or commit separately as you prefer.
• The other 3 findings on this trail are stale (org delete idempotency, missing --force/confirmation, missing command-level wiring tests) and weren't touched — say the word if you want those addressed too.
• Didn't resolve the finding in the tracker (blocked as an external write you didn't request). To close it: entire trail finding resolve 019ef39b-6ce --trail 642 -m "fixed in eb2c0db28e".

No — the finding I addressed (019ef39b-6ce, the only current one) was solely about the success message printing the user's arg instead of the resolved ULID. It said nothing about delete confirmation.

Delete confirmation is a separate, stale finding (019ef4a6-14e, org.go): "Destructive deletes have no confirmation and no --force/--yes flag." I flagged it in my summary but didn't touch it.

Want me to address that one too (add a confirmation prompt + --force/--yes flag to the delete commands)?

Clean tree, lint green. Done.

Bottom line

Added confirmation prompts + --force/-f (and --yes/-y alias) to org/project/repo delete. Three commits on feat/control-plane-crud-gaps, not pushed.

Why the finding was "stale": freshness = whether the code it points at is unchanged since filing. It isn't a correctness flag — the concern was still valid. The branch's 7 new commits + your requested rebase onto origin/main + my earlier org.go edit all changed those blobs, so the finding's line refs went stale.

What I did:

• New confirmControlPlaneDeletion gate (mirrors the existing confirmTrailDeletion trail pattern): --force/--yes proceeds silently; non-interactive without force refuses rather than deleting unprompted; interactive shows a huh confirm; clean cancel on Esc/Ctrl-C.
• addForceFlag/forceRequested helpers register -f/--force + -y/--yes (both skip the prompt).
• Extracted the shared runControlPlaneDelete body so the three commands are thin closures — keeps dup checker happy (the expanded blocks would otherwise duplicate).
• Unit test TestConfirmControlPlaneDeletion covers force / non-interactive-refusal / cancelled-context. Prompt shows the resolved ULID label from the earlier fix.

Commits:

• eb2c0db28e — resolved-ULID success messages (earlier finding)
• b3f5c4f707 — delete confirmation + flags
• 2749cb4c4b — drop now-unused //nolint:ireturn (rebase fallout; local --fix strips them, CI fails without)

Verified: go build, mise run lint (0 issues), dup:staged (0), full cmd/entire/cli tests pass, --force/--yes render in org delete --help.

Scope note: I covered the three delete verbs you named. The finding also mentioned grant repo remove (and grant project/org remove are similar) — those are reversible revocations, so I left them. Want confirmation on the grant removes too?

Didn't touch the tracker. To close the finding: entire trail finding resolve 019ef4a6-14e --trail 642 -m "fixed in b3f5c4f707".

Lint clean, all tests pass. Let me review the staged diff, then commit and push.

Base confirmed ✓. Integration tests are slow; let me run them with a longer timeout (my changes are control-plane commands, not hooks/strategy, but verifying per the checklist).

Confirmed. Pushed, and all 4 findings are addressed in code and marked resolved.

Status

(All four show stale freshness — expected, since the rebase changed the underlying blobs. That's a code-version marker, not a correctness signal; status is resolved.)

Branch

• feat/control-plane-crud-gaps is now based on feat/control-plane-friendly-names (verified: it's an ancestor), 13 commits.
• The rebase reconciled crud-gaps against friendly-names' independent resolver rework: kept friendly-names' client-side pickOrg/pickProject resolver, dropped crud-gaps' server-side ?name= variant, dropped the redundant nolint commit (already upstream), and adapted the seams (resolveOrgRef now paginates; restored isNotFound/resolvedRefLabel; added the test helper).
• Local verification before push: go build ./..., go vet, mise run lint (0 issues), full cmd/entire/cli unit tests pass. Integration tests left to CI per your call.
• Force-pushed (history was rewritten by the rebase). Backup tag backup/crud-gaps-on-main-… exists locally if you need the pre-rebase state.

One judgment call to flag: I made pickRepo case-insensitive (EqualFold) to match friendly-names' pickOrg/pickProject style. Shout if you'd rather it stay exact-match.

Verified, not guessed. No — case handling is not uniform, and there's a related field-read bug. Three resolvers behave three different ways.

What the code actually does today

These all feed grant org/project/repo, repo get/delete, project create --owner, etc. (confirmed above), so the asymmetry is repo-wide.

The two surprises

1. Projects resolve case-sensitively; orgs and repos don't. resolveProjectRef delegates filtering to the server's name query param, which the spec documents as "Optional: exact-match project name." (org and repo name params say the same). So entire ... widgets works but Widgets returns "no project named". The pickProject EqualFold re-check cannot help — the server has already dropped the case-variant row before the client sees it. The doc comment on resolveProjectRef claiming "the server enforces lower(name) uniqueness… case-insensitive end to end" is contradicted by the spec — nothing supports case-folding server-side.

2. project list is case-inconsistent with itself, and resolveProjectRef likely reads the wrong field.

• project list --org X --name foo → client-side filterProjectsByName (EqualFold) → case-insensitive.
• project list --name foo (no --org) → server exact-match → case-sensitive.
• Worse: the ?name= response is returned under the singular out.Project field (that's how project list --name reads it, line 133: out.Project.Set), but resolveProjectRef reads the plural out.Projects (line 115). If the server populates only project for a name query, resolveProjectRef resolves nothing by name regardless of case. Its unit test passes only because the mock fills the plural field. (This last point depends on real server response shape, which I can't exercise from here — but the code paths demonstrably disagree on which field to read.)

Honest bottom line

• Orgs/repos: normalized (case-insensitive), consistent.
• Projects: not normalized, and resolveProjectRef has a probable field-read bug independent of case.
• I introduced none of this — it's friendly-names' resolver, which I kept per your instruction. My pickRepo EqualFold change actually added consistency on the repo side.

This is exactly the "surprising results" risk you flagged. To make it uniform, the cleanest fix is to make resolveProjectRef mirror the org/repo pattern: drop the server name filter, list projects, and pickProject client-side with EqualFold (and read the right field). Want me to do that — and align project list --name (and the repo/org list --name filters) the same way?

This project list needs a real reconciliation: friendly-names added server-side name filtering (singular Project + toProjectList) to both global and org-scoped endpoints, while my commit added pagination for the list-all case. The correct merge keeps both: server-side O(1) name lookup when --name is set, pagination otherwise. Let me rewrite the function body cleanly (also fixing Cursor→PageToken and the stray isNotFound).

Partly — but that's not its headline purpose. Quick recap from the branch's own commits:

• Trail #642 title / primary purpose: "Control-plane CLI: org/project get+delete, repo grant list+remove" — i.e., filling CRUD gaps in the control-plane commands.
• Paging is also in here, as supporting work — these commits:
  • consume paginated v1 list endpoints (COR-580)
  • rename pagination params to pageToken convention
  • regenerate client for PageInput/PageMeta pagination
  • paginate repo mirror list (COR-583)

So: the branch adds the CRUD commands and makes the list calls page through all results (COR-580/583), plus my added work (delete confirmation/--force, idempotency, resolved-ULID messages, tests).

Relevant to where we just paused: the project list conflict is exactly at the seam between the paging work (yours, COR-580) and friendly-names' new server-side name resolution — which is why the clean resolution needs both (page through the list-all case; O(1) server lookup when --name is given). Nothing changed on disk; the rebase is still paused mid-conflict awaiting your go-ahead.

Verified. Here's the honest status:

O(1) lookups: ✅ yes, uniformly

Every name→ID resolver now makes one server call (zero for a ULID — passthrough). No client-side list-and-filter anywhere; I grepped and the only remaining EqualFold uses are unrelated (plugins, trails). Confirmed in code and the resolver tests assert exactly 1 call:

The CLI no longer pages-and-scans for resolution — that asymmetry (orgs/repos client-side, projects server-side) is gone. List commands still page through everything (that's COR-580's point — listing all ≠ O(1)), but they're not lookups.

Case-insensitive: ⚠️ now uniformly delegated to the server — but the spec only documents it for 1 of 4

Since all four resolvers now delegate filtering to the server, case behavior is 100% a server property and is uniform across the CLI (no client-side folding to diverge). But the committed spec param descriptions are inconsistent:

• exact-match project name (case-insensitive). ← org-scoped projects only
• exact-match org name. / exact-match project name. / exact-match repo name. ← no case-insensitive annotation

So I can confirm CLI-side: uniformly O(1), uniformly server-delegated for case — no asymmetry left in our code. What I cannot confirm from here is that the server folds case for all four; the spec only annotates it for the org-scoped project lookup. The friendly-names resolver comment claims "server matches on lower(name)", but 3 of 4 param docs don't say so. If your entiredb change made all four case-insensitive, just the spec text is lagging; if not, org/global-project/repo lookups would still be case-sensitive server-side.

That's the one thing left to verify on your end (server behavior / spec text), not in the CLI.

Branch state

Rebase onto refreshed feat/control-plane-friendly-names is complete: my 3 coreapi-regen commits were dropped as redundant (full schema now precedes this branch), leaving a focused PR. go build ./..., go vet, mise run lint (0 issues), full cmd/entire/cli tests all pass. Uncommitted: the isNotFound→isCoreNotFound fixup in corecmd.go. Not pushed. Want me to commit the fixup (and squash the now-near-empty reconcile commit) and push?

Yes — it's not a stray file, it's the required build fix (the idempotent-delete code calls the 404 helper, which friendly-names renamed isNotFound→isCoreNotFound). Without it the branch doesn't compile. So it must be committed.

The clean home is the tip reconcile… commit — it's already the catch-all for adapting this branch to friendly-names' resolver, and it went near-empty after the rebase (only writeNotFoundProblem + an import survived). Folding this in keeps every commit building and the PR focused.

That means amending the tip commit, which your rule says I shouldn't do without explicit say-so. Two options:

• Amend the tip reconcile commit (recommended) — cleanest history, tip-only so no risk to earlier commits.
• New commit (e.g. fix(control-plane): use isCoreNotFound after resolver rename) — follows your default no-amend rule, but adds a one-line "fix the previous commit" commit to the PR.

Which do you want? (I haven't committed or pushed anything.)

Updated. The old description was materially inaccurate after the rebases.

What was wrong, and what I fixed

• "Client regen" section was false. It claimed the PR regenerates internal/coreapi (GetOrg, DeleteOrg, …). The branch now has zero internal/coreapi changes — the full schema dump moved to the base branch. Replaced with a one-line note that the client is regenerated on the base.
• Pagination was unmentioned. COR-580/583 (page through org/project/repo list, the grant … list commands, and repo mirror list) is now a headline part of the PR. Added a section.
• Delete safety was unmentioned. Confirmation prompt + --force/-f / --yes/-y, non-interactive refusal, idempotent 404-as-no-op, and resolved-ULID success messages. Added a section.
• Friendly-name resolution was stale. Rewrote to reflect the base branch's server-side, O(1), case-insensitive lookups (the old text predated that refactor).
• Commits list + test:ci (59 + 4) count were stale — dropped the verbatim commit list and the specific count (didn't re-verify exact numbers); kept an honest verification line.

Preserved the trail-link and entire-shadow-pr markers. Title and base branch were already correct, so left untouched.

All pass. Let me review the staged diff and commit.