2 Commits

Include renames

Author	SHA1	Message	Date
Neil	9cda5a9dc0	fix(worktrees): stop a resolved-worktree snapshot answering for repos it never saw (#18295) ... * fix(worktrees): stop a resolved-worktree snapshot answering for repos it never saw `listResolvedWorktrees` caches one fleet-wide snapshot for RESOLVED_WORKTREE_CACHE_TTL_MS (1s) and reuses it on time alone. Nothing invalidates it when a repo is registered, so for up to a second after a repo row lands, every caller reads a snapshot computed before that repo existed -- and reads the gap as a verdict. The visible failure is the SSH skill install. `resolveSkillSshTarget` resolves a workspace-scope destination through that snapshot, so installing into a worktree on a host connected moments earlier threw `skill-install-workspace-not-found`: the client asserting a remote workspace is absent on the strength of client-side bookkeeping that had never looked at the host. That is the shape `docs/reference/ssh-execution-boundary.md` rules out -- absence from a client-side set is not evidence about the execution host. It made `tests/e2e/ssh-skill-installation.spec.ts:108` fail 3 runs in 4 locally and deterministically in the Docker SSH lane, where connect-then-install lands inside the one-second window every time. The snapshot now carries the repo-registration revision it was computed under and is only reused while that revision still holds. The counter is the one `bumpLocalWorktreeScanGeneration` already advances on every repo add, removal and update, so the check is O(1) and cannot drift from the mutation sites. * fix(worktrees): key the snapshot on repo mutations only, not on generation reads Two things the headless-reattach lane surfaced. The revision I keyed the snapshot on was `generationSequence`, which `getLocalWorktreeScanGeneration` also advances when it mints a key for a repo id nothing has scanned yet. That is a read, not a mutation, so a read path could discard a snapshot that was still perfectly valid -- the mirror image of the staleness this fixes, and a way to make a lookup fail that would otherwise have succeeded. The counter now advances only where the scan generation is actually bumped: repo add, removal, update, and scan-cache invalidation. Separately, `pty-restore-record-seeding.test.ts` primed the cache by writing its private `resolved` field with a literal spelling out `worktrees`, `platformByRepoId` and `expiresAt`. That literal is a second copy of the cache's freshness contract, so adding a field to the real entry left the fake one failing the check: the primed snapshot was rejected, resolution fell through to a real scan, and the headless fixture -- which has no git -- got `selector_not_found`. It now primes through `getSnapshot` so the cache stamps its own entry and the two cannot drift again. The revision never moved during that test (0 before and after), so nothing was being invalidated; the fake entry simply never satisfied the contract.	2026-09-02 18:13:08 -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