* Accept host aliases and infer the host for a single-setup project `orca worktree create --project scalp-it` failed with "Project is not set up on the selected host" even though the project has exactly one ready setup, and `--host trader-local` was rejected as an invalid value even though `orca host list` prints that name. Three separate causes: - `--project` was matched against the stored `projectId` only, which is a provider-scoped string (`github:owner/repo`). The display name shown by `orca project list` never matched, so the lookup found nothing and the failure was reported as a missing host. - With no `--host`, the host fallback existed but was unreachable, because the project lookup above had already filtered to zero candidates. - `parseExecutionHostId` accepts only `local`, `ssh:<id>` and `runtime:<id>`, so a bare alias could not parse at all. `ssh:<label>` already resolved labels; only the unprefixed spelling was missing. Now: - `--project` takes the project id or the display name, resolving through `project.list` and falling back to the setup's own display name for hosts that predate that method. Two projects sharing a name are refused rather than guessed. - `--host` is only required when the project is set up on more than one host. A single setup is used directly; an ambiguous one fails with every host and the flag to select it. - `--host <alias>` resolves against both axes: paired servers by name before routing, SSH targets by label once a client exists. An alias that names a machine on both is refused with the prefixed flag for each. Errors now echo the flag the caller typed instead of an `ssh:` spelling they did not use, and carry the hosts to retry with in `nextSteps`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Refuse a host alias that collides with duplicated SSH labels assertAliasNamesOneHost asked findSshTargetByName whether the alias also named an SSH target, but that function returns undefined for a label two targets share — deliberately, so an ambiguous label never resolves. Read as a boolean it says "no SSH target by that name", so an alias naming one paired server and two same-labelled SSH targets looked conflict-free and resolved to the server. The opposite direction was already covered: a unique SSH target against two servers sharing a name fails through assertEnvironmentNameUnambiguous. Fall back to ambiguousSshTargets so both axes refuse, and list every colliding target in nextSteps rather than only the first. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Only fall back to setup display names on a server without project.list findProjectsByName caught every error from project.list and returned an empty list, so a network failure, a permission error, or a genuine server fault was indistinguishable from "no project by that name" — and the caller was then told `Project is not set up on the selected host` for a project that exists and is set up. Narrow the catch to method_not_found, the only code that means the weaker fallback is warranted, matching callProjectHostSetup and listSshTargets in the same layer. The function now returns null for that version gap and an empty array for a real miss, so the two cases stay distinguishable at the call site. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Refuse a legacy display-name match that spans two projects The pre-project.list fallback matches ProjectHostSetup.displayName, which is the repo's folder name rather than the project's name, so two projects holding repos with the same folder name both match. selectSetupOnHost would then have taken the first candidate — targeting a project the caller never named. Reject when the matched setups span more than one projectId and name each one, the same rule the project.list path already applies to duplicate display names. A single project with several setups is unaffected; the host selection below still decides between them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Spell the --host placeholder as <host> in the project setup usage lines The worktree create usage was updated to <host> when aliases became valid, but the four project setup-* lines kept <host-id> in both the command specs and the root help text they mirror. Those commands accept an alias too, so the narrower placeholder hid it from anyone reading help. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Document host names and the optional --host in the CLI docs The published CLI reference described `--host` as taking only `local`, `ssh:<target-id>` or `runtime:<environment-id>`, and the automations page showed `--host <hostId>` as required alongside `--project`. Both now understate what the commands accept, which is how the original report started: `orca host list` prints a name, the docs never said you could type it, so the generated id looked mandatory. Spell out that `--host` takes the bare name from `host list` on either axis, that a name resolves only when unique and is otherwise refused with the prefixed flag for each candidate, and that `--host` is unnecessary when the project has a single setup. Also note `--project` accepts the display name from `orca project list`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Name the runtime host id as the paired-server tie-breaker in the docs The host-selection page told readers to fall back to ids when a name is ambiguous but only ever showed `--environment <server-name>` for paired servers — and that selector is exactly the one that cannot separate two servers sharing a name. Spell out the pair the resolver actually emits in its nextSteps: `--host ssh:<target-id>` and `--host runtime:<environment-id>`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Spell the automations create usage as --project <id-or-name> [--host <host>] `automations create` resolves --project and --host through the same alias-capable resolver as `worktree create`, and its own notes already say --project takes a display name and --host takes a bare host name. The usage line still read `--project <id> [--host <id>]`, the last spot left on the old spelling (flagged by CodeRabbit after the main merge). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Give the fake runtime client cast in the host alias tests its SAFETY note Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(cli): accept every name host list and project list print, everywhere --project/--host is taken Extends the alias work to the commands it did not reach and the names it missed: - `project setups --project <display name>` filtered by projectId only. - `project setup-existing-folder|setup-clone|setup-create --project <name>` now send the project id that name resolves to (pass-through for ids and for servers without project.list). - `--host "this machine"` (the local row's name) resolves to local, and is refused if an SSH target or paired server shares it. - One pair of wrapping quotes is ignored, since cmd.exe passes single quotes through literally. - With --environment/--pairing-code, a bare --host name is a machine the routed server reaches, not a different locally paired server. - An unknown project is reported as a project miss, not a host miss. Co-authored-by: Younghwan Chae <chyohw97@gmail.com> * fix(cli): keep exact project ids over names, and refuse an unverifiable host name An exact --project id whose only setup is not ready no longer falls through to a project whose display name equals that id. A bare --host name that matches a paired server now routes there only once this machine's SSH targets were actually read, and under --environment/--pairing-code a bare name always means a machine the routed server reaches. Co-authored-by: Younghwan Chae <chyohw97@gmail.com> --------- Co-authored-by: younghwan <chyohw97@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
@orca/docs
This package contains the product documentation and public media intended to ship alongside Orca's source code.
Open-source product documentation for Orca, served at /docs (same URL shape as https://www.onorca.dev/docs).
This package is a self-contained Next.js app. It is intentionally not a root monorepo workspace member, so installing Electron app dependencies does not pull Next/fumadocs.
Local development
cd docs/site
pnpm --ignore-workspace install
pnpm --ignore-workspace dev
Open http://localhost:3004/docs.
Linting
Run pnpm --ignore-workspace lint inside this directory. The isolated Oxlint
configuration keeps the native equivalents of the previous Next.js, React,
React hooks and accessibility checks at their existing severities, including
alt text on Next.js Image components. Generated Next.js and MDX output is
excluded. Oxlint also reports its default correctness warnings.
The migration does not provide equivalents for React's deprecated-API check,
React Compiler configuration/gating diagnostics, or Next.js's relative
location.assign advisory. JSX variable-use bookkeeping is handled by Oxlint's
parser. Keep TypeScript and the production Next.js build in the validation
workflow; this is not a claim of complete ESLint rule parity.
Production build
cd docs/site
pnpm --ignore-workspace install
pnpm --ignore-workspace build
pnpm --ignore-workspace start
pnpm start serves the production build on port 3004. Paths:
| Path | Purpose |
|---|---|
/ |
Redirects to /docs |
/docs |
Docs index |
/docs/... |
Nested doc pages from content/docs |
/docs/api/search |
Fumadocs search index |
/docs/og/... |
Per-page Open Graph image route |
Layout
content/docs/— MDX pages +meta.jsonnavigationpublic/docs/— docs-only media, logo, and favicon (GIFs, posters, screenshots)src/app/docs/— fumadocs routes, OG imagessrc/components/— docs-scoped chrome (header/footer/search), not marketing site
Updating content
Treat the documentation tree as a deliberate publication boundary. Before importing source material, review the diff for internal references, credentials, third-party media rights, and feature/version claims, then copy only approved pages and assets. Keep the app shell and deployment configuration in this repository so a docs-only pull request can be reviewed and built independently.
Same-domain routing
The docs app is a separate Vercel project (the docs zone) and keeps the
public /docs URL namespace. The marketing site remains the default zone for
www.onorca.dev; configure its Next/Vercel proxy with these beforeFiles
rewrites, replacing DOCS_ORIGIN with the docs project's production URL:
return {
beforeFiles: [
{
source: '/docs',
destination: `${DOCS_ORIGIN}/docs`
},
{
source: '/docs/:path*',
destination: `${DOCS_ORIGIN}/docs/:path*`
},
{
source: '/docs-static/:path*',
destination: `${DOCS_ORIGIN}/docs-static/:path*`
}
]
}
/docs-static is the docs zone's assetPrefix; it prevents _next asset
collisions with the marketing zone. Keep the rewrites in the default zone and
use ordinary <a> links when navigating between zones. Do not add
basePath: '/docs' to this app: its route tree and Fumadocs baseUrl already
include /docs, so doing so would publish /docs/docs/... URLs. If a future
deployment needs basePath, first move the route tree to an unprefixed
src/app/[[...slug]] shape and update every generated/link URL together.
Deploy (Vercel)
- Create a Vercel project with Root Directory unset (
.). The workflow invokes Vercel fromdocs/site, so that directory is already the deployment root; setting it again would resolvedocs/site/docs/site. Leave automatic Git deployments disabled so this workflow remains the only deployment path. - Framework preset: Next.js. Use
pnpm --ignore-workspace install --frozen-lockfilefor install andpnpm --ignore-workspace buildfor build; this package has its own lockfile beside the root workspace. - Set GitHub Actions secrets (required by the production deploy job):
VERCEL_TOKENVERCEL_ORG_IDVERCEL_PROJECT_ID(docs project, not the marketing site)
- Protect the
docs-productionGitHub environment with required reviewers and custom deployment branch policies formainandv*tags. The release-cut dispatch runs frommain; the direct published-release fallback runs from a stable tag, while the workflow still authorizes only exact stable tags. - Prepare the three rewrites above in the
www.onorca.devmarketing project, but leave them disabled until the docs deployment is verified. A Vercel custom domain cannot delegate only/docsby itself; the default zone must proxy both page/API/media requests and/docs-staticassets. Keep the marketing project's old docs routes available for rollback during the transition; putting the proxy rules inbeforeFilesensures they win once enabled. - Deploy a stable desktop tag that contains
docs/site, verify the docs origin, then enable the marketing rewrites. Tags cut before this package was added cannot bootstrap the docs project because production intentionally checks out the tag's exact commit. Remove the old marketing docs routes in a follow-up after the proxy is stable.
.github/workflows/docs.yml runs credential-free checks for every pull request.
It intentionally does not deploy PR previews: a PR-controlled build must not
receive Vercel credentials. A maintainer can add a separate trusted preview
workflow later. Production deploys only from an authorized stable desktop release: an exact
vX.Y.Z tag, a published non-prerelease release, and the
github-actions[bot] release author. Manual dispatch must run from the default
branch and name an existing release that meets the same checks. Mobile,
prerelease, draft, and human-authored releases are skipped. Fork pull requests
remain build-only because GitHub does not expose deployment secrets to fork
jobs.
Versioning
versioning.config.ts keeps the current unversioned /docs URLs stable while
reserving content/versions/<id> for future snapshots. Versioned routes are not
live yet; when they are needed, add the corresponding loader/routes and a
version entry. The release workflow can then deploy them without a trigger
change.
Isolation from the desktop app
- Own
package.json+pnpm-lock.yamlunderdocs/site/ - Not listed in the root
pnpm-workspace.yaml; install withpnpm --ignore-workspace - Engineering notes remain in repo-root
docs/— do not confuse with this package