* fix(checks): stop skipped and manual checks reporting as failures
Route every check-classification surface through one shared helper so
desktop renderer, desktop main and mobile agree on the same verdict.
- GitLab `manual` jobs and pipelines are neutral again, not action_required/failure
- `skipped` counts as passed everywhere, including mobile
- a neutral check no longer demotes a summary that has passing checks
* fix(checks): move the check-classification parity test into the renderer project
The parity table lived in src/shared but imported a renderer module, and both
config/tsconfig.node.json and config/tsconfig.cli.json are composite projects
that include src/shared without that renderer path, so `pnpm typecheck` failed
with TS6307 on two of its three projects. Only the web project spans both trees.
Co-authored-by: Orca <help@stably.ai>
* fix(checks): stop the Tasks-grid pill contradicting its own verdict
The checks pill's label, tone and icon all read one ProviderCheckSummary, but
getChecksLabel short-circuited on the raw `neutral` counter while the tone and
icon key off `state`. After the classification fix a PR with 19 success + 1
neutral renders an emerald CheckCircle2 pill that reads "1 unresolved", and
mobile's own label (which keys off `state`) reads "19/20 passed" for the same
summary.
Move the label into src/shared/provider-check-summary.ts so desktop and mobile
cannot fork it again, and key it off `state`.
Also covers deriveWorkItemCheckSummary, the desktop-main producer of the summary
that reaches the Tasks grid and the relay-paired mobile client. It was rewritten
here with no test at all; the parity table stands in derivePRCheckStatusFromRollup,
which is a different normalizer. The new main-process test drives getWorkItem with
a real statusCheckRollup fixture, pinning the StatusContext `state` fallback that
would otherwise be deletable with the whole suite still green.
Co-authored-by: Orca <help@stably.ai>
* fix(gitlab): route the pipeline job-array rollup through the shared check classifier
The array path in derivePipelineStatus kept its own copy of the rollup rules, so
manual-only read green and one unrecognized job status demoted a passing pipeline
to neutral — both disagreeing with every other check surface.
Also retry the packaged-CLI smoke temp cleanup on Windows: the copied Orca.exe can
still be locked by AV/indexers after every assertion passed, failing the package job.
Co-authored-by: Orca <help@stably.ai>
* fix(gitlab): stop the skipped pipeline string diverging from the Checks tab
- classifyPipelineString now counts a skipped pipeline as passing, matching
the per-check classifier; canceled stays neutral and is pinned as an
explicit, sign-off-pending divergence.
- Pin the production string path (head_pipeline.status) in the parity table
and note that the job-array branch has no production caller yet.
- Count skipped checks in the Checks panel's passing header so it agrees
with the checks pill.
- Correct the packaged-CLI smoke retry comment: the EBUSY is the smoke's own
just-exited Electron process, not AV/indexers.
Co-authored-by: Orca <help@stably.ai>
* fix(checks): finish cross-surface check parity and back out the skipped MR-card flip
Review follow-ups on the check-classification PR.
- PullRequestPage and GitHubItemDialog kept private copies of getCheckCounts /
getChecksSummaryLabel that still counted only `success` as passing, so a
2-success/3-skipped PR read "2 passing · 3 skipped" there and "5 passing" in
the sidebar. Both copies move to pr-check-counts.ts, which routes the passing
bucket through classifyCheckOutcome; action_required keeps its own amber
bucket. The summary icon now keys off passing count, so an all-neutral PR
stops painting a green tick above "0 of N checks passing".
- The sidebar checks header and triage strip still called
`{status: completed, conclusion: null}` pending, contradicting the grey
"Unresolved checks" pill. Both now read summarizeProviderChecks and render an
unresolved chip/strip instead of an amber spinner that can never resolve.
- classifyPipelineString('skipped') is reverted to neutral. That flip painted
MR cards green for pipelines that never ran, on the only GitLab path with
production callers, and contradicted the same function's deferral of
`canceled`. Both tone changes stay deferred, pinned by one test.
- classifyPipelineString('manual') resolves to pending rather than neutral: a
blocked pipeline is outstanding, and neutral let the worktree card fall
through to its emerald `open` default while GitLab still refuses the merge.
- TaskPage's checks pill helpers move to task-page-checks-pill.ts so the
"1 unresolved on a green pill" fix is actually pinned by a test.
- smoke-packaged-cli no longer lets an EBUSY cleanup replace the real failure.
* fix(checks): stop completed unknown checks from spinning
---------
Co-authored-by: Orca <help@stably.ai>
* fix(windows): make the GPU fallback actually remove the GPU child, and stop WSL latching absent
Three Windows crash/regression fixes from shipped 1.4.156/1.4.158/1.4.159 crash reports.
GPU fallback (cluster D, 14 reports, exit 0x80000003 STATUS_BREAKPOINT):
the software-rendering fallback called disableHardwareAcceleration() plus
--disable-gpu, neither of which removes the GPU child process — Chromium still
spawns it to host Viz and merely drops the backend to software GL. Measured on
Windows 11 / Electron 43.1.0: gpuProcessCount stays 1. So a GPU process being
killed by a bad driver or an injected DLL kept dying after the fallback engaged,
on every launch, for the life of that build (the marker is sticky per version).
The crash tails show exactly this: gpu_fallback_applied followed by another GPU
crash 1.3s later. --in-process-gpu is the only switch that drops the child count
to 0; --disable-software-rasterizer is deliberately excluded because it also
kills SwiftShader, which would drop every terminal to the DOM renderer.
WSL distro list: a successful-but-empty `wsl --list --quiet` was cached for the
process lifetime. `wsl --install` reports zero distros while one is still
provisioning, so an early probe latched "no WSL" until restart — WSL appeared
during setup and then vanished from the terminal picker. Empty results now
re-probe on an exponential window (15s doubling to a 5min cap) while staying
readable, so a missing distro is still visible to isKnownMissingDistro.
WSL availability: isWslAvailable() latched false on any failure via a bare catch,
so one slow wsl.exe activation disabled WSL for the whole session. Failures are
now classified — a numeric exit status or ENOENT is answer-shaped and holds for
10min, anything else (timeout, spawn failure) retries after 45s — and both back
off per consecutive failure, mirroring isPwshAvailable.
Windows-only: every changed path is behind an existing process.platform check,
so macOS and Linux behaviour is unchanged.
* fix(windows): drop a stale WSL availability failure once a distro list succeeds
The distro-list and availability caches expire independently, and
getWslRepairReason checks availability first. So a definitive availability
failure (numeric exit status or ENOENT) held for 10-30min would keep reporting
`wsl-unavailable` even after `wsl --list --quiet` successfully returned a
distro — i.e. over a WSL that demonstrably just answered. That is the same
latch class this branch fixes, surviving in the gap between the two caches.
A non-empty distro list proves wsl.exe ran, so drop the negative availability
cache and let the next call re-probe. Scoped to non-empty lists only: those are
cached for the process lifetime, so this cannot re-spawn the blocking 5s probe
more than once. An empty list keeps its failure cache, since it re-probes on a
15s-to-5min schedule and would otherwise pay the blocking probe far too often.
* fix(windows): harden GPU safe mode and WSL recovery
* fix(wsl): make capability refresh cleanup explicit
---------
Co-authored-by: OrcaWin <293788423+OrcaWin@users.noreply.github.com>
* feat: rename worktree folder to match branch on first work
When the first agent message auto-renames a freshly created creature branch to a
short, work-derived name, also align the on-disk worktree folder and the sidebar
display name with it. Re-key every worktree-scoped slice of state — renderer
store maps plus the persisted main-process state — through the resulting id
change so the live worktree survives the rename instead of being treated as a
deletion (its tabs, terminals, browser panes, and git status all follow).
The rename is best-effort and local-only: a skip or failure (remote runtime,
Windows lock, destination taken) leaves the folder as-is and never undoes the
branch/display rename that already landed.
Squashed from the original PR #4743 commits, rebased onto upstream/main to drop
accumulated merge commits and i18n formatting churn so the branch carries only
the feature diff:
- Rename worktree folder to match branch on first work
- migrate renamed worktree session ids
- keep the live worktree alive through a folder rename
- address PR review feedback
* Address PR review feedback (#4743)
- orca-runtime: emit in-process worktreesChanged client event on folder rename, mirroring notifyBranchRenamed so onClientEvent listeners aren't left stale
- worktrees: re-key rightSidebarExplorerViewByWorktree and activeWorkspaceKey through a worktree-identity rename (both were worktree-scoped but missed by buildWorktreeRenameState)
- branch-name-from-work: treat prefix-only model output as an empty slug so the caller skips the rename instead of producing a doubled prefix
- worktree-folder-rename-target: document why posix.dirname is safe (Windows filtered out earlier)
- tests for each of the above
* Extract branch rename test helpers to a separate harness file
Move git responders, mock builders, and test event fixtures out of
first-work-branch-rename.test.ts into a new test harness file. This
reduces file length and removes the max-lines ESLint disable directive,
complying with project style guidelines.
* Wrap entire OnboardingFlow in TooltipProvider
Enable the use of tooltips anywhere within the onboarding flow, rather
than restricting them to the step indicators.
---------
Co-authored-by: Jinjing <6427696+AmethystLiang@users.noreply.github.com>
Extend worktree creation, remote-conflict detection, and the Checks panel UI to support linked PRs from Bitbucket, Azure DevOps, and Gitea alongside GitHub and GitLab.
* Extract shared metadata lookup helpers to map provider-specific review identifiers.
* Update remote-conflict validation to check hosted reviews on target providers during worktree creation.
* Propagate provider-specific PR states through the RPC layers and into the Checks and Source Control UI panels.
* fix(tabs): repair mixed tab shortcut switching
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent)
Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
* fix(typecheck): unblock tc:web project checks
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent)
Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
* fix(tabs): split group/fallback id matching into separate branches
Why: matching both `tabId` and `id` in one findIndex predicate mixed two
identifier domains and risked a pathological collision between a tab's
backing entity id and another tab's unified id. Keep the group-path
(strict tabId match) and the fallback-path (backing-id match) in
separate branches.
Also clarify the comment on the dual `setActiveFile` + `activateTab`
write so future readers know why both calls are needed for split-group
disambiguation.
Co-authored-by: Orca <help@stably.ai>
---------
Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
Co-authored-by: Jinjing <6427696+AmethystLiang@users.noreply.github.com>
Co-authored-by: Orca <help@stably.ai>
* chore: clean up repo root for faster README visibility
- Delete unused images (debug_orca.png, orca_3d.jpg, screenshot.png)
- Delete stale design docs from docs/
- Move tsconfig sub-configs, electron-builder config, and vitest config to config/
- Move file-drag.gif to docs/assets/ and design doc to docs/
- Update all path references in package.json, tsconfig.json, and moved configs
* fix: remove stale worktree dialog callback dependency