Skip to content

Require project IDs for CLI request scoping - #218

Open
IlyaasK wants to merge 1 commit into
mainfrom
hypeship/cli-project-id-scope
Open

Require project IDs for CLI request scoping#218
IlyaasK wants to merge 1 commit into
mainfrom
hypeship/cli-project-id-scope

Conversation

@IlyaasK

@IlyaasK IlyaasK commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

Summary

  • document the global --project flag as accepting project IDs only
  • use the Go SDK's typed option.WithProjectID client option
  • align KERNEL_PROJECT examples with the merged API contract

Why

X-Kernel-Project-Id is an ID selector on the merged API. Advertising project names here can scope a command incorrectly or produce a confusing not-found response. The typed SDK option also keeps client configuration aligned with generated SDK behavior.

Implementation

The request still carries the same X-Kernel-Project-Id header. This changes the public CLI guidance and replaces the manually named header option with the SDK's first-class project option.

Verification

  • go test -short -timeout=2m ./...
  • go vet ./...
  • gofmt -l cmd
  • git diff --check
  • crap4go: changed resolveProjectSelection CRAP 2.0; root init CRAP 5.8

Note

Low Risk
Docs and a typed SDK client option with the same header behavior; no new resolution logic beyond existing flag/env selection.

Overview
Clarifies that global --project and KERNEL_PROJECT must be project IDs, not names, so CLI guidance matches the API’s X-Kernel-Project-Id contract and avoids misleading “name or ID” wording.

When a project is selected, the authenticated client is configured with the Go SDK’s option.WithProjectID instead of manually setting the project header. README and api-keys create --project-id docs are updated to distinguish request scoping from project-scoped API key creation; tests use *-project-id example values.

Reviewed by Cursor Bugbot for commit 666951e. Bugbot is set up for automated code reviews on this repo. Configure here.

Document the global project selector truthfully and use the SDK's canonical project option so request scoping continues to match the ID-only API header contract.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant