docs: clarify --project flag does not resolve names

[hiroTamada]

Summary

The docs currently claim the global --project flag (and KERNEL_PROJECT env var) accepts either a project ID or a name and resolves names case-insensitively. That's not actually what the CLI does — it forwards the raw value as the X-Kernel-Project-Id header without any client-side lookup. Name resolution is only wired into the projects subcommand positional arguments (get, delete, limits get, limits set).

This PR updates three pages to reflect the real behavior:

• reference/cli.mdx — global flags table
• reference/cli/projects.mdx — "Scoping commands to a project" section
• info/projects.mdx — "Using Projects from the CLI" section

Test plan

• Visual review of the three pages in a docs preview
• Confirm with CLI maintainers whether the API itself accepts a name in X-Kernel-Project-Id — if it does, we may want to revisit the framing

---

Note

Low Risk
Documentation-only changes with no runtime or API behavior impact.

Overview
Corrects documentation that incorrectly described the global --project flag and KERNEL_PROJECT as accepting project names with case-insensitive resolution.

info/projects.mdx, reference/cli.mdx, and reference/cli/projects.mdx now state that those values must be a project ID, are sent unchanged as X-Kernel-Project-Id, and that users should run kernel projects list to find IDs. Examples drop name-based scoping (e.g. staging) in favor of proj_abc123.

The docs also clarify that name resolution still applies only on kernel projects positional args (get, delete, limits get, limits set), where the CLI resolves names before calling the API.

^{Reviewed by Cursor Bugbot for commit 35afc3d. Bugbot is set up for automated code reviews on this repo. Configure here.}

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
Kernel	🟢 Ready	View Preview	Jun 3, 2026, 7:00 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[firetiger-agent]

Firetiger deploy monitoring skipped

This PR didn't match the auto-monitor filter configured on your GitHub connection:

PRs in the kernel, infra, hypeman, and hypeship repos. kernel is a ~mono repo with many logical services underneath, ensure to focus on the implicated service for the PR

Reason: This PR only modifies documentation files and does not change any service code, so it does not require deploy monitoring.

To monitor this PR anyway, reply with @firetiger monitor this.

[cursor]

Risk assessment: Very Low

The diff only updates three .mdx documentation pages to clarify how the CLI --project flag and KERNEL_PROJECT env var handle project IDs. There are no code, config, prompt-instruction, infrastructure, API, or navigation changes, and the examples/text changes are narrowly scoped to CLI documentation. I also found no CODEOWNERS file and no existing approvals, so this is safe to approve.

  

_{Sent by Cursor Automation: Assign PR reviewers}