mirror of
https://github.com/stablyai/orca.git
synced 2026-10-31 17:17:38 +00:00
4940654793
* 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>