6 Commits

Include renames

Author	SHA1	Message	Date
Neil	cc03142b9c	feat(wsl-mover): background writers step aside for a project a WSL move is taking (D1b-5c-3) (#28835) ... * feat(wsl-mover): background writers back off a project a WSL move is taking (D1b-5c-3) * fix(wsl-mover): re-check before renames, quiet owned automations, stable folder ids (D1b-5c-3) * test(wsl-mover): seed journals one phase at a time and advance existing moves (D1b-5c-3) * fix(wsl-mover): a branch rename that already ran settles even when the move skips the folder (D1b-5c-3)	2026-10-14 14:13:51 -07:00
Brennan Benson	38255300d9	fix(worktrees): never delete a folder git no longer tracks (#25075) ... * fix(worktrees): a retried or resumed delete only removes the folder it started deleting A failed worktree delete stays listed for a retry, and an interrupted one is finished at the next start. Both later deletes force-deleted whatever was at the recorded path, proven only by "git does not list it and it has no .git", so an ordinary folder the user put at that path since was deleted with its files, with no click needed in the startup case (STA-9338). An accepted removal now records the checkout directory's identity (device, inode, creation time) in its durable record. A retry, a startup finish, and the in-slot check before the force-delete refuse any folder at the path that is not that directory. Startup no longer rebuilds a missing .git for a registered checkout unless the folder is the recorded one. Records without an identity (older builds, or no creation time) are only finished through Git's own checks and never force-deleted. * fix(worktrees): identify the accepted checkout by inode and a real creation time only The device number changes when an external volume is attached again, so a genuine leftover read as a different folder. Windows reports a missing creation time as a negative number rather than 0, which slipped past the guard. * refactor(worktrees): every background removal states the checkout identity it accepted A new acceptance site that forgot the identity used to compile and silently write records no retry or resume could ever finish. The resume tests also assert the identity was read, so their refusals can't pass as unrecorded. * fix(worktrees): a delete that leaves the user's folder in place also ends the workspace When Orca decided the folder at a failed or interrupted delete's path was not the one it started deleting, it dropped the removal record but kept the workspace's metadata. That metadata still says Orca created a checkout there, and with no record left, the next Delete of the same workspace (a runtime Delete from mobile, the CLI or a paired client, or a second desktop Delete on a row not yet refreshed) went to the cleanup that deletes an Orca-created folder Git no longer lists, and removed the user's folder after all. Now, when a removal ends without deleting while Git does not list the path (a listing ends a failed delete, or a retry, resume or first delete fails with no leftover to show), the host runs a finished delete's bookkeeping: metadata, terminal history, caches and change events. The folder and the branch are left alone, and nothing is ended while Git still lists the path. * test(worktrees): cover the in-slot folder check when Git cannot remove a registered checkout Reverting that check left every test green: only the unregistered branch's check had a test where the folder changes during the delete-slot wait. * fix(worktrees): a resumed or retried Git delete checks the folder inside the delete slot The check that the folder at the path is still the one Orca accepted ran before the watcher gate and the delete-slot wait, which can last minutes behind other large deletes. A folder restored there meanwhile with a copy of the checkout's .git file passes Git's own validation, so `git worktree remove --force` deleted it. The resume and retry now repeat the check inside the slot, right before Git deletes, as the non-Git branch already did; the refusal skips the Windows recovery that could otherwise finish the delete itself. A normal first delete is unchanged. * test(worktrees): assert the second desktop Delete refuses the user's folder The handler result is untyped, so the previous catch-all did not typecheck; the assertion now names the refusal the Delete gets once the workspace has ended. * test(worktrees): the desktop Delete test's stand-in host ends the workspace without a cast * fix(worktrees): a listing asks Git before dropping a failed delete, and ends its workspace in the same step * fix(worktrees): a failed delete Git cannot be asked about stays failed for the next listing to decide * test(worktrees): the failed-delete record test states that Git still registers the checkout * fix(worktrees): a restart keeps a failed delete whose checkout is gone, so the first listing ends its workspace * fix(worktrees): a folder Orca cannot read keeps its failed delete and is never deleted * fix(worktrees): a failed delete leaves the disk only after its workspace's end is saved * fix(worktrees): a runtime Delete of a failed delete's row is told when Orca left the folder in place * test(worktrees): the desktop Delete test's stand-in host returns nothing * fix(worktrees): a Delete of a failed delete's leftover whose .git Orca cannot read says so * Revert "fix(worktrees): a runtime Delete of a failed delete's row is told when Orca left the folder in place" This reverts commit 68d65989de. The shortcut reaches no real client: the CLI and mobile list the workspace before deleting it, which ends the failed delete first, so they still answer not found (the folder is kept either way). * fix(worktrees): a failed delete Git could not be asked about is dropped once Git says it still registers the checkout * revert to main before the standard-model rework * fix(worktrees): stop deleting Orca-created folders that have no .git and that Git no longer tracks Deleting an Orca-created workspace whose folder Git no longer tracked and that had no `.git` force- deleted the whole folder once the user confirmed force. "Orca made a workspace here once" and "there is no .git" do not prove the folder still holds that checkout: an ordinary folder the user put at the path was deleted. Such a folder now gets the existing "Refusing to delete unregistered worktree path" answer, forced or not. Once the user removes the folder, Delete takes the existing missing-path branch and drops the workspace. An orphaned worktree whose `.git` file points back at this repo is still deleted after the user confirms force, as before. * fix(worktrees): delete a failed or interrupted workspace only through Git A delete that failed partway (Git dropped the registration, files left) stays listed as "Delete failed", and a delete a quit interrupted is finished at the next launch. Both later deletes removed the folder with Orca's own file removal, proven only by "Git does not list it and there is no .git". An ordinary folder the user put at that path was deleted, at startup without any click. Orca now deletes a checkout only through Git, plus the existing cleanup right after a Git delete that succeeded in the same operation: - Delete on a failed row: if Git registers a checkout at the path, the normal delete runs. If the folder is still there and Git does not register it, Delete refuses with "Git no longer tracks <path>, so Orca won't delete it. Remove the folder yourself; Orca removes this workspace once the folder is gone." and keeps the row. With the folder gone, Delete prunes Git's stale entry, deletes the branch as recorded and drops the workspace. - Startup finish of an interrupted delete: a checkout Git still registers is removed with `git worktree remove` and the user's recorded force choice, no longer always forced. If Git refuses or fails, the row shows Git's error. The step that rewrote a missing `.git` so Git could force the delete is gone. A folder Git does not register becomes a failed row and is not deleted; with the folder gone, the rest of the delete finishes. Records written by earlier daily builds still load; fields this version does not know are ignored. * test(worktrees): read Git's listing before the Delete call in the real-Git failed-delete suite * docs(worktrees): say when a failed delete's record ends under the Git-only delete * fix(worktrees): keep main's handling of a startup finish Git refuses, and say the listing drops the workspace A startup finish that Git refuses for a checkout Git still registers now clears its record and leaves Git's normal row, exactly as an in-session failure does on main; the resumed-only failed record and the listing that put Git's error on Git's own row are gone, and the listing is main's again. An unregistered folder that still exists is still a failed row, and nothing is deleted. The refusal now reads: "Git no longer tracks <path>, so Orca won't delete it. Remove the folder yourself, and Orca will drop this workspace from the list." The listing drops a failed record once its folder is gone, as on main. * fix(worktrees): finish a failed delete's branch and push-target remote when it fails A delete Git fails partway keeps a "Delete failed" row for the folder Git left. The row's record also carried the branch delete and the push-target remote cleanup for later, but the listing drops the record once the user removes the folder, so both were silently left behind. Now, once Git no longer registers the checkout, the failure runs that Git side right away (merged branch only, stale admin entry, push-target remote), in the one settle path desktop and runtime share. It deletes no files, and a failure of this bookkeeping is logged without touching the failed row. * fix(worktrees): unregister an interrupted delete's checkout whose .git Git already deleted A quit mid-delete can leave a checkout Git still registers but whose .git link Git already deleted (Git deletes it first on Windows). No `git worktree remove` can validate it, so the startup finish failed, the record was cleared, and the workspace came back as a normal row no Delete could ever remove. The startup finish now has Git prune that registration (refused while locked; every file kept) and then treats the folder as one Git no longer registers: the "Delete failed" row with the remove-it-yourself message, ending once the user removes the folder. Adds the non-forced partial-delete case: Git refuses, the files stay, and the row returns as before. * fix(worktrees): name a worktree Git registers inside a failed delete's folder before asking the user to remove it The refusal for a folder Git no longer tracks tells the user to remove the folder. When that folder holds another worktree Git still registers, doing so would delete that worktree's files too. Delete on the failed row and the startup finish now run the existing nested-worktree check first, so its message ("contains another registered worktree: <path>") wins, as it did before this branch. * fix(worktrees): don't prune other worktrees when a delete fails The Git side of a failed delete started with a repo-wide `git worktree prune`. It did nothing for the failed delete, whose admin entry Git had already dropped, but it unregistered any other worktree whose folder was missing at that moment (an unmounted drive), so Orca dropped that workspace too. The failure now runs only the branch step; the prune stays where it was on main, in the folder-gone finish and at startup. * test(worktrees): cover the push-target cleanup every delete job wires for a failed delete A failed delete removes the push-target remote Orca added through the hook each job creator passes: desktop Delete, runtime Delete, and the startup finish. Nothing tested that wiring; these tests fail when any creator drops it. * fix(worktrees): say the leftover folder was left on disk instead of what Orca won't do	2026-10-14 10:58:27 -07:00
OrcaWinandm4air	3359fd2bfc	refactor(ipc): worktree handlers are local or runtime only (#27528) ... * refactor(ipc): worktree handlers are local or runtime only * refactor(runtime): explain the route witness on removal listing * test(runtime): pin the SSH create refusal and drop the deleted branch's reliability gap * test(runtime): drop a needless cast in the SSH create refusal test --------- Co-authored-by: m4air <m4air@Mac.localdomain>	2026-10-11 11:48:57 -07:00
OrcaWinandm4air	ec14775f93	refactor(providers): an ssh: route carries no provider and throws one typed error (#27477) ... Co-authored-by: m4air <m4air@Mac.localdomain>	2026-10-11 06:25:41 -07:00
Neil	3c91404820	fix(worktrees): route managed worktree removal by resolved execution host (#18529) ... `removeManagedWorktree` resolved its host once — for the metadata prune (`cleanupHostId ?? getRepoExecutionHostId(repo)`) — and then read raw `repo.connectionId` for every step that touches the filesystem: the `git worktree list` deciding whether the path is registered, the provider handed to the unregistered-removal branch, the registered-remote-vs-local fork, and the PTY/history teardown. One function, two spellings. For a row naming its owner only as `executionHostId: 'ssh:<target>'` — the exact class #18296 names — the list ran on the client against a remote path, `removeRuntimeUnregisteredWorktree` was entered with `provider: null`, and the metadata was pruned under `ssh:<target>` while a same-named *local* directory was the one considered for deletion (#11163). #18358 made this reachable: it migrated the cleanup scan, so `executionHostId`-only rows now surface as removable candidates, but removal did not move with it. Routing is now one answer for the whole removal, taken from the host the prune already used, through #18296's host-keyed dispatch. The ambiguous `provider: SshGitProvider | null` carrier is deleted from the callees rather than supplemented, so every remaining reader is a compile error in the typed modules that do the destructive work (`runtime-unregistered-worktree-removal`, `runtime-registered-remote-worktree-removal`, `runtime-worktree-filesystem`). The orchestrator itself carries `@ts-nocheck` from its mechanical split, so that guarantee does not reach it — tests cover it instead. Every change is in the refusing direction; nothing became more aggressive: - an `ssh:` host with no registered provider throws instead of deleting a client-side path (`requireSshGitProvider` already threw for rows that spelled the same host as `connectionId`); - `runtime:<env>` throws rather than dialling a same-named target in this client's namespace, matching `workspace-cleanup-git-route` and `runtime-git-command-target`; - the folder-workspace teardown resolves its connection instead of reading the raw field, so a `runtime:` row stops dialling the wrong namespace. No wire or persistence change: `removeWorktreeMetadataAndHistory` already took the resolved host, and the removal RPC result shape is untouched.	2026-09-03 16:21:52 -07:00
Neil	a5796ec8eb	refactor(runtime): split OrcaRuntimeService and compatibility tests (#17605) ... * refactor(runtime): split OrcaRuntimeService into focused modules * test(runtime): cover admission tiers and strict worktree reconciliation * fix(runtime): preserve owner and structured session visibility * fix(runtime): port post-extraction compatibility fixes * fix(runtime): preserve skill-share cancellation barrier * test(runtime): update identity inventory after extraction * fix(runtime): preserve hook transport environment cleanup * fix(runtime): consolidate idle probe imports * test(runtime): retire split file process allowlist entry * fix(runtime): route child process types through shared boundary * test(runtime): preserve worktree host metadata precedence * fix(runtime): update extracted test seams * fix(runtime): gate the split's ts-nocheck set and restore the stop-confirmed contract Audit follow-ups for the OrcaRuntimeService split: - Freeze the 171 @ts-nocheck files behind a ratchet so no new file can disable type checking. The split's linear mixin chain cannot express forward references yet, so the existing suppressions are grandfathered; the baseline may only shrink. - Drop the stray @ts-nocheck at the end of orca-runtime-get-status.ts. It sat after the first statement, where TypeScript ignores it, so the module was already checked. - Restore `retireRejectedPty(ptyId, stopConfirmed: boolean)` as a required argument. The split widened it to optional and patched the resulting error with `stopConfirmed === true`; an omitted argument would have silently taken the unverified-stop path instead of failing to compile. - Guard that every orca-runtime-tests fragment is imported by the compatibility entrypoint. The fragments are .spec.ts, which no Vitest include glob matches, so one left out of the list would silently stop running. * fix(runtime): restore four behaviors the OrcaRuntimeService split dropped Audit findings against the refactor's true base (ad5ba2572e): - retirePtyAgentLaunchAuthority collected pane keys after deleting the restored-authority receipt instead of before it. collectPaneKeysForPty reads that receipt, so a receipt-only pane lost its key and never had its agent-hook compatibility authority retired. on-pty-exit.ts already carried a comment naming this exact invariant. - The PTY-exit path kept orchestrationMailboxNotifications.retirePty but lost the loop that schedules a debounced mail-pointer repoint for the dead pty's terminal handle and any run bound to its panes. Restores the schedule call count to 7, matching base. - subscribeToPtyExit lost isPtyKnownExited's leaf fallback and its post-registration lifecycle-generation recheck. leavesByPtyId is rebuilt from the renderer graph independently of ptysById, so a leaf can outlive its pty record; without the fallback a caller waiting on an already-dead pty never gets released. - The chain root declared `[key: string]: unknown`, which base had nowhere. It leaked through the exported runtime type into every consumer, so any misspelled member access typechecked as unknown instead of erroring, and it accounted for 957 of the suppressed errors. Removing it costs zero type errors. * fix(runtime): restore escalation prose and unscoped automation publication Two more behaviors the split dropped, each with a regression test that fails against the pre-fix code: - The worker-exit escalation stopped deriving its title through buildOrchestrationTaskDisplayMetadata and inlined `task.spec` instead. That ignored an explicit task_title, dropped the single-line normalization and the 80-character bound, and turned the no-spec case into a quoted, duplicated id. A multi-paragraph spec landed verbatim in the coordinator's banner. The existing 11 tests all use short single-line specs, where the derived title and the raw spec are identical, so none of them could see it. Also reverts an added `if (!handle) return` guard: the dispatch lookup is deliberately keyed on the pane as well, because a reminted handle no longer matches the row while the pane identity outlives the remint. - updateAutomation stopped going through automationChangePublications and published `source` unconditionally while gating the fallback on a non-null destination. A destination the store can no longer name then published only the stale source, so subscribers scoped elsewhere kept rendering a row that had left them — the exact case the helper documents. The helper had been left with zero callers; all three sites use it again. * fix(skills): stop swallowing lookup errors and hard-erroring on non-ssh hosts Follow-ups from auditing the skill install path against the refactor's base: - resolveWorktree wrapped showManagedWorktree in `.catch(() => null)`, so a transient git or IO failure surfaced to the user as skill-install-workspace-not-found with the real cause discarded. Errors propagate again; a genuine id mismatch still returns null. - resolveSkillSshTarget threw skill-install-workspace-host-unavailable when the execution host was neither local nor ssh, on both the repo and folder branches. Base gated these on connectionId, so a runtime-owned repo simply was not an SSH install and fell through to the local path. Both return null again, and the error code the split invented is now unreferenced. - listManagedSkillInstalls awaited the receipt walk and the worktree resolve in sequence. They are independent and either can hit disk, WSL, or an SSH scan, so Promise.all is restored. Deliberately unchanged: resolving the worktree through listResolvedWorktrees rather than showManagedWorktree, which disambiguates a worktree id colliding across hosts and is covered by its own test, and the SSH-folder skill-install-ssh-dispatch-required throw, which matches the repo branch. * fix(runtime): merge duplicate worktree-logic imports The #17448 port added a third import from ../ipc/worktree-logic, which the code-quality oxlint config rejects under --deny-warnings. Plain oxlint does not flag it, so it only surfaced in CI's static analysis job. * ci: run the ts-nocheck ratchet in PR checks pr-workflow-lint-parity requires every leaf command in `pnpm lint` to have a matching step in pr.yml. The ratchet was wired into lint but not the workflow, so PR CI would not have enforced it. * Merge remote-tracking branch 'origin/main' and retry the paired-host launch evaluate main advanced 9 commits; none touch the orca-runtime.ts this branch splits, so nothing needed porting. CI failed twice on `Execution context was destroyed` thrown from headless-paired-runtime-host's first `evaluate` after launch — a different spec each run, which is the signature of the flake #17780 describes rather than a regression. That commit added retryTransientMainEvaluate and adopted it in five helpers but not this call site, even though its docblock names exactly this case: the first evaluate after electron.launch() resolves, before the app is ready. Wrapped it the same way.	2026-08-31 19:34:55 -07:00