4 Commits

Include renames

Author	SHA1	Message	Date
4 people	6aef5c569c	Phase 3.7: fix SSH/remote failures found by adversarial real-host testing (#26847) ... * fix(remote-terminal): keep a reconnected pane's size after an SSH outage (P1-4) (#26625) * fix(remote-terminal): keep a reconnected pane's grid when its stale stream is reaped (P1-4) The host's width floor only handed ownership to viewers that had claimed since subscribing. A reconnecting desktop pane re-subscribes without claiming, so when the heartbeat later reaped the dead socket that owned the floor, the host reclaimed the PTY to its spawn size (120x40) and held the pane there. The owner's same-client replacement stream now inherits the floor, and a pane whose stream was reaped before it reconnected resumes ownership on re-register unless the host or another viewer claimed since. * fix(remote-terminal): host typing during an outage revokes the reaped owner's resume Host input reaches the PTY without a renderer viewport claim once the host has reclaimed its grid, so the orphaned-owner entitlement survived and a passive reconnect resized the host pane back to the remote grid. The host write path now clears that entitlement on driving input (query replies, focus reports and launch writes excluded). * test(pty): stub the runtime's host-input note in write-path handler tests --------- Co-authored-by: m4air <m4air@Mac.localdomain> * fix(remote): an oversized RPC reply fails that request instead of closing the host connection (#26624) Expanding a folder with ~80k entries on a managed SSH host produced a files.readDir reply over the 4 MiB encrypted-reply cap. The channel treated that as a transport fault and closed the whole control socket (1013), and the explorer rendered the failed folder as empty. - The WebSocket RPC transport now answers an over-cap reply with a reply_too_large error for that request id, so the channel never sees it. - files.readDir checks remote listings against the request's content budget and names the entry count. - The explorer shows a subfolder's read error on its expanded row. Finding: HH-2 (Phase 3.7 hostile-host). Co-authored-by: m4air <m4air@Mac.localdomain> * fix(ssh): let a slow host finish installing the pinned Node runtime (HH-3) (#26631) * fix(ssh): let a slow host finish installing the pinned Node runtime The POSIX promote (extract, hash, self-test and publish the ~110 MiB node binary) ran under the 30 s default exec timeout. On slow home storage it timed out, the remote work kept running, and the runtime store lock it held stayed until the 20-minute stale rule, so relay rung A queued behind it past its own deploy bound. Give both platforms the 300 s promote bound and have the host release the store lock itself when the promote exits, with owner-checked releases so a late release never removes a lock someone else took. (HH-3) * fix(ssh): let the host release the store lock after a slow under-lock re-hash The under-lock re-check of a sibling-published runtime hashed the ~110 MiB executable as its own command under the 30 s exec default and outside the host-side lock release. On slow storage it timed out, the client correctly kept the lock, and nothing on the host freed it until the 20-minute stale rule, so later installers ran out their deploy bound. Run the re-hash and the conditional promote as one host command wrapped in the host release, and give every full-runtime hash, including the initial probe, the slow-storage bound. (HH-3) * test(ssh): count the combined under-lock re-probe and promote as one host command --------- Co-authored-by: m4air <m4air@Mac.localdomain> * fix(ssh): shell startup output on stdout no longer breaks SSH connect (HH-1) (#26617) * fix(ssh): fence captured exec stdout so shell rc output cannot break connect sshd runs the user's login shell before Orca's /bin/sh wrapper, so any startup-file stdout (fish/tcsh/zsh/bash echo, or a bare terminal-title escape) was glued onto every captured answer. The home probe read "banner\n/home/u" and connect failed with "Remote home is not a valid path". execCommand now wraps wrapped POSIX commands in a per-call nonce fence and returns only the payload between the markers; the SSH folder browser gets the same fence. The fence is the existing WSL captured-login-shell fence, moved to src/shared/posix-stdout-fence.ts so both transports share it. Finding: HH-1 (phase 3.7 hostile-host). Refs #8324. * fix(ssh): fence the login-shell Node probe and fall back from a noisy SFTP handshake The login-shell 'command -v node' probe ran unwrapped, so output from sshd's shell and the nested login profile became the Node path. It now prints a one-line fence every login shell parses, inside that shell. An external sftp-server is started through the user's shell, so startup output corrupts the SFTP handshake. ssh2 reports that parse failure only before the session is ready, so SshConnection.sftp tags it, and relay install transfers treat it as SFTP unavailable and stream over exec stdin. Finding: HH-1 follow-up (phase 3.7 hostile-host). Refs #8324. * fix(ssh): keep the stdout fence marker out of the command text The runtime-store inventory lists processes with ps, which prints its own script, so a literal marker in the script was read as the fence and the store GC skipped every pass. printf now joins the marker from two halves. --------- Co-authored-by: m4air <m4air@Mac.localdomain> * fix(orcad): finish an abandoned update on connect, and refresh renderers after a main-side re-pair (P1-A, P1-C) (#26635) * fix(orcad): finish an update or rollback its client abandoned, and tell renderers about main-side re-pairs P1-A: a wake that finds the activation fence now runs crash recovery, which takes only a stale, previous-boot or exited-own fence. Recovery of an activation interrupted after the candidate launched resumes it: the candidate commits if it passes the readiness gate, else the activation is undone as before. P1-C: invalidating a still-linked environment's transport restarts its status owner, and a renderer that sees status under a newer pairing revision re-reads the catalog before applying it. * fix(orcad): a resumed update keeps the app version that started it Recovery that commits an abandoned candidate stamped no activeAppVersion, so an older desktop read the host as pre-tracking and downgraded it over state the newer build had migrated. The activate journal now records the initiating app version; recovery stamps it, and a journal too old to carry it is undone instead of committed. * test(runtime-env): answer nothing for the status restart a re-pair now triggers * fix(orcad): recovery leaves running an update server a too-old journal cannot commit A journal without candidateAppVersion was sent to undo, which stopped a healthy candidate that had already migrated state and then refused to restart the incumbent, leaving the host serving nothing. Refuse instead, keeping the fence and the candidate, until the operator accepts Restore. --------- Co-authored-by: m4air <m4air@Mac.localdomain> * fix(terminal): a remote recovery never splices stale history above the new screen (P2-5, P2-7) (#26647) * fix(terminal): a remote recovery never splices stale history above the new screen A pushed remote snapshot (overflow recovery, seq-gap resync, first attach) is sent because the client's stream broke, so the pane's own history ends before that image. Since #26319 a screen-only image kept that history, splicing a stale block directly above the final screen with a silent gap of up to ~270k lines (P2-5), and a first attach to an older host left silent holes (P2-7). - Host: the ACK-overflow recovery serializes up to 1000 history rows. - Client: the seq-gap resync asks for the same 1000 rows. - Client: a pushed snapshot always replaces the pane's scrollback; the keep-local-scrollback path is removed. A screen-only image from an older host now shows only its screen, which is lossy but never misleading. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * fix(terminal): a pushed image replaces the normal buffer over a live alt screen too Over a pane already on the alternate screen, an image that also ended on alt repainted only its alt frame and kept the pane's normal buffer, inferring the two had frozen together. Inside the gap the TUI can exit, the shell print and a second TUI start, so once that TUI exited the pane showed its stale history where the host had the missed output. A pushed image now always rebuilds the normal buffer and history from the host before entering alt itself. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * fix(terminal): bound recovery history by link slack and keep pre-TUI scrollback under screen-only images A recovery that carries history now goes out only when the stream's ACK window has drained; under a sustained flood recoveries stay screen-only and the owed history follows once the client catches up, so snapshot bytes no longer outgrow the client's intake. A pushed image without history (scrollbackRows absent or 0) over a live alt screen repaints only the alt frame again, so a reconnect to an older host no longer wipes the pane's pre-TUI scrollback. --------- Co-authored-by: m4air <m4air@Mac.localdomain> Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * fix(source-control): Stage All stages every change when the listing hit the 1,000 cap (HH-4) (#26618) * fix(source-control): Stage All stages every change when the listing hit the 1,000 cap The status listing stops at 1,000 rows, but Stage All built its path list from those rows, so it staged 1,000 of 20,000 changes and the next commit was silently partial. When the listing is capped, Stage All (and the Changes header Stage all) now asks the host to stage the whole worktree via an optional scope on git.bulkStage; unresolved conflicts stay unstaged. Older hosts ignore the field and stage the listed paths. Fixes HH-4. * fix(source-control): whole-worktree Stage All needs a host receipt, skips shared links, and reaches mobile - Scoped stage sends no paths and requires a stagedScope receipt, so an older runtime or relay stages nothing and the client reports it instead of a silent partial stage. - Scoped 'all' skips Orca's shared symlinks (configured and really a link), matching the status listing. - The capped-listing banner offers Stage All, reachable when the visible prefix is entirely staged. - Mobile reads didHitLimit and uses the same scoped stage and receipt. * test(source-control): type the Stage All test stubs so lint and the mobile test typecheck pass * fix(source-control): match Shared Paths saved as ./name or name/ against git's spelling The Shared Paths setting keeps entries as typed, but git prints worktree paths without a leading ./ or trailing /. Stage All's conflict path compared the raw spelling to git's untracked list and staged the shared node_modules link, and an exclude pathspec ending in / made git refuse the add after tracked changes were already staged. Status listing had the same mismatch. getSafeRelativePath now returns git's spelling, so every caller gets it, including saved settings. --------- Co-authored-by: m4air <m4air@Mac.localdomain> * fix(ssh): redeploy a managed server another desktop stopped; forget one whose host is gone (P1-D, P1-E) (#26628) * fix(ssh): redeploy a server another desktop stopped; let a dead managed host be forgotten P1-D: a connect whose linked server the host reports as not activated (another desktop stopped it) now goes on to the update check, which redeploys it in place. P1-E: add Forget (managedServer.forget, orca environment forget, Settings row) that runs Stop's local unlink without contacting the host; the verdict stays unverifiable. * test(ssh): type the forget test's hoisted store without an assertion * fix(ssh): never downgrade a stopped host; redeploy it mid-session and retry after a failure A stop now keeps the stopped build's Orca version, so an older desktop's reconnect skips as host-newer instead of starting an older server on a store a newer build migrated. A stop recorded without that version is not guessed at. A stopped host retries the redeploy on each connect instead of the once-per-version failure suppression, and a runtime call that finds the server stopped mid-session redeploys it before the call. * fix(ssh): rebuild the managed forward after redeploying a stopped host A redeploy can bind a different port than the reused forward targets. * fix(ssh): keep stop journals readable by older desktops and recheck version policy under the fence - The stop journal's recordAfter is the core deactivated record older peers compute; the committed record keeps activeAppVersion (which released planners already honour) and rolledBackFrom, rebuilt from recordBefore on recovery. - Auto-update re-applies its version policy to the record read under the host fence, and a census counted against another incumbent is treated as unverifiable. * fix(ssh): file a dispatched stop where older desktops cannot commit it, so their recovery never drops the version guard * fix(ssh): refuse a fresh deploy of an older orcad onto a host a newer desktop stopped The unlinked deploy path never consulted the stopped record's activeAppVersion, so a desktop without a link to the host could activate its older build over state a newer build migrated. Both the auto-update planner and the fresh deploy now apply one downgrade rule under the fence. --------- Co-authored-by: m4air <m4air@Mac.localdomain> * fix(ssh): redeploy a managed server a pre-version Stop left; let a forced deploy run over a newer one (#26766) A stopped activation record without activeAppVersion is what every Stop on main writes, so refusing it stranded those hosts behind an unforceable policy refusal. Only a provably newer host is now refused; a forced fresh deploy runs this version anyway, and the refusal names both versions. Co-authored-by: m4air <m4air@m4airs-MacBook-Air.local> * fix(remote-terminal): no keystroke lost, duplicated or split across a silent outage (P1-1, P1-2, P1-3) (#26630) * fix(remote-terminal): no keystroke lost, duplicated or split across a silent outage Remote pane input was fire-and-forget: keys handed to a socket that had silently died were gone, keys still in the 8 ms debounce at detection were cleared, and held keys were discarded when the auto-recovery window ran out. - New negotiated `inputAck` capability: the client names an input session and sequences Input frames (existing frame header `seq`); the host records the last applied sequence per (PTY, session) across connections, writes each sequence once and acks it with new opcode InputAck (18), sent only to clients that advertised the capability. - The pane keeps sent-but-unacked input and replays it to the same terminal on reattach; the host dedupes. Old hosts keep current behavior. - Debounced and claim-queued input at detection is held, not cleared. - Held input survives the 'disconnected' phase; the hold coalesces keys so minutes of typing do not hit the per-entry cap. - Banner copy no longer claims a one-minute retry window. Fixes P1-1, P1-2, P1-3 (phase 3.7 network findings). * fix(remote-terminal): never replay into a restarted runtime; keep Ctrl+C and validating paste in order - Host publishes inputLedgerId with inputAck; the client drops unacknowledged input sent to a different ledger (runtime restart with the same PTY) instead of running it twice. - A replayed duplicate is acked only after the original write settles. - Accepted input (Ctrl+C, Escape, paste) rides the sequenced stream and resolves on the host ack. - Keys typed while held queue behind a paste still in size validation. * fix(remote-terminal): parse subscribed capabilities into a typed shape instead of Reflect.get * fix(remote-terminal): ack only applied input; withdraw writes their caller gave up on - Host ledger records each write's outcome: a refused write is rolled back and never acked, so the client's replay writes it; nothing queued behind it runs or is acked. A write that threw is acked as delivery-unknown, so the client reports it failed and never replays it. - Paste and file-drop timeouts abort their accepted write: a copy still held for an outage is withdrawn, and a journaled copy is left out of the replay. - A batch of sequenced input keeps one endpoint and ledger, so a send that retires the stream mid-batch no longer discards earlier unacked input. * fix(remote-terminal): host writes sequenced input strictly in order and asks the live stream to resend after a refusal - The ledger admits only the next sequence; a refusal or gap answers with an InputAck resend request instead of WriteUnavailable, so the pane keeps its journal and resends on the same stream (no remount, no carrier bookkeeping). - Sequenced input uses the provider's settled write; an unverifiable handoff is delivery-unknown, not refused. - Replays fill given-up slots with empty input so the host can continue; the client remounts only after every resend backoff is refused. - Typing batched ahead of a paste goes out as its own sequences, so cancelling the paste keeps it. * refactor(remote-terminal): deliver sequenced input with standard go-back-N Replace the hand-built "block on refusal" bookkeeping with go-back-N: - Host: per (PTY, input session) the ledger keeps only appliedSeq, the highest contiguous confirmed write. Frames run one at a time in arrival order: a duplicate is re-acked, the next sequence is written and acked on confirmed success, and a refusal or gap is answered with a resend request carrying appliedSeq. No blocked state; every stream is equal. A settlement that proves no byte left is a refusal; one that may have written advances as delivery-unknown and is never retried. - Client: one journal keeps unacked input in order and resends from appliedSeq + 1 on a resend request (with backoff), on a new stream, or when acks stall. Refusals never remount the pane. Withdrawn pastes, stale query replies and over-budget bytes resend as empty slots. - The recovery hold pauses (keeps the rest) when a release is cut short by another outage, and keeps delivering typing after an accepted write a sequenced stream withdrew or could not confirm. - Add a seeded model-based test that drives the real pane transport, multiplexer and journal against the real host dispatcher and ledger through 2,000 random fault schedules. * test(remote-terminal): cover the refusal remount on a stream without sequenced input A sequenced stream now resends refused input on the same stream instead of remounting, so the end-to-end remount check negotiates no inputAck, as an older peer does. * fix(remote-terminal): escalate persistent input refusals, drop input once recovery gives up, and never report a lost unknown ack as applied - The pane falls back to its remount path when the host keeps refusing input past the resend backoff ladder. - Held and journaled input is discarded when auto-recovery gives up, and input typed under the disconnected banner is not held. - The host ledger answers a duplicate for its own sequence and remembers delivery-unknown outcomes; the client settles a write as applied only from its own ack. - The input model now requires a write reported applied to have reached the PTY whole, and covers a refusal that never clears. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: m4air <m4air@Mac.localdomain> Co-authored-by: m4air <m4air@m4airs-MacBook-Air.local> Co-authored-by: Claude <noreply@anthropic.com> * fix(remote-terminal): keep input typed past the auto-recovery window for the same terminal, within a bounded grace (P1-3) (#26832) The last round of #26630 discarded held and journaled input as soon as auto-recovery gave up, and refused input under the disconnected banner. On a real host a 200 s outage lost 102 of 120 keystrokes, although the pane reattached the same terminal on its own seconds later. Input now stays held for the same handle and incarnation while the pane is disconnected, for up to 5 minutes after it gave up. Past that grace it is discarded, and typing into the dead pane is refused, so stale keys never run at an arbitrary later reconnect. The grace is a timestamp checked when input moves, so a latched pane stays free of timers. Co-authored-by: m4air <m4air@Mac.localdomain> Co-authored-by: Claude <noreply@anthropic.com> --------- Co-authored-by: m4air <m4air@Mac.localdomain> Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Co-authored-by: m4air <m4air@m4airs-MacBook-Air.local>	2026-10-09 04:58:48 -07:00
Neil	b4ba3e97ff	perf(worktree): defer fork-PR remote creation from create-time to first use (#17922) ... * perf(worktree): defer fork-PR remote creation from create-time to first use Fork-PR review worktrees eagerly ran `git remote add` + `git fetch` for the contributor's fork (and pinned branch.<x>.remote) at create time, even for a read-only review. That grows remote count unboundedly with review volume and pays a network fetch nobody asked for yet. Defer prepareWorktreePushTarget(Ssh) and the --set-upstream-to configure step at create time (local + SSH, IPC + runtime create paths); persist the pushTarget metadata untouched. Materialize the remote on demand the first time push/pull/fetch/fast-forward actually needs it, via two shared functions (materializeWorktreePushTargetRemote(Ssh)) reused across the legacy IPC handlers and the RPC runtime sync commands. A cheap `remote get-url <name>` probe keeps steady-state calls down to one extra subprocess once materialized, instead of repeating the O(remotes) scan. Add repo-local `remote.<name>.orca-created` config provenance, written when the remote is added, so cleanup can recognize ownership of a remote that was lazily materialized (and therefore never round-tripped through the store's `remoteCreated` flag). Refs #17828 * perf(worktree): materialize a deferred fork-PR remote on terminal spawn An agent running raw git in a freshly opened fork-PR review terminal has no usable upstream until an Orca-driven sync happens -- "sync through Orca first" isn't available mid-task, and git pull/log @{u}.. hard-fail without one (verified against real git). Fire the same on-demand materialization used by push/pull/fetch/fast-forward from the single terminal-spawn resolver (resolveTerminalWorkspaceLaunchTarget), fire-and-forget, so a newly opened terminal gets a working upstream without blocking spawn. * fix(worktree): retest deferred fork-remote CI failures, fix SSH provenance-marker RPC Rewrites the 5 CI failures on the deferred fork-remote change (#17828) as evidence, not fixtures: the SSH relay-upgrade/rollback/sibling-ownership tests move to materializeWorktreePushTargetRemoteSsh, where that unchanged logic now actually runs (create defers it to first sync). While writing a stricter test that routes its mock exec through the relay's real validateGitExecArgs, found that the SSH provenance-marker write (`git config remote.<name>.orca-created true`) was unconditionally rejected by the relay's generic git.exec (it blocks all non-read-only config writes) -- a real bug that would break every SSH fork-remote materialization against a live relay. Fixes it with a narrow git.markRemoteOrcaCreated RPC, mirroring renameCurrentBranch, with a graceful no-op fallback for relays that predate it. * fix(worktree): scope post-#17887 test assertions past narrow-refspec config calls Rebasing onto #17887's narrow-refspec `remote add` broke two broad `['config']` call-filters into false positives/negatives, and the local materialize test still asserted the pre-#17887 wide `remote add`/fetch-refspec forms. * fix(worktree): restructure upstream restore, persist provenance, widen short-circuit refspec (#17828 review) - Move upstream restoration to the materializer level so it runs on both the remoteAlreadyMatchesUrl short-circuit and the full-prepare path, not just buried inside prepare*. - Persist {remoteCreated, remoteName} to the store on materialize so #17842's orphan sweep can see a lazily-created remote, including via desktop IPC, terminal-spawn, and the RPC host-callback paths. - Widen the refspec on the local short-circuit path too (SSH's bare `remote add` refspec gap remains a documented, pre-existing limitation). - Fetch the branch's tracking ref before restoring upstream when the short-circuit widens onto a *new* branch on an already-existing remote -- a bare refspec-config widen never itself imports anything, so `branch --set-upstream-to` was hard-failing for a sibling worktree's first materialize (found via a real-git fixture, not just mocked unit tests). Skipped when the ref already exists so the common repeat-call case stays a local-only probe with no network round-trip. * fix(worktree): merge duplicate shared/worktree/types import oxlint --deny-warnings flags the split import as no-duplicates; full pnpm lint was failing on it after the #17828 review restructuring. * fix(worktree): scope the deferred fetch timeout to fetch calls, retarget stale create-time assertions CI on the previous push failed 3 shards, all argument-shape mismatches: - worktrees-wsl-runtime-routing.test.ts: the "restructure upstream restore" commit wrapped every call `prepareWorktreePushTarget` makes (remote, remote add, config, fetch) with DEFERRED_PUSH_TARGET_FETCH_TIMEOUT_MS, not just the network fetch. Local git subprocesses never need a timeout; scope it to `args[0] === 'fetch'` only, matching the short-circuit path's existing pattern. Updated the test to expect the timeout on the fetch call specifically (point 5 legitimately adds it there), while every other call stays untimed. - worktrees-create-metadata-persistence.test.ts (2 tests): stale from before this session -- create no longer mints a fork remote at all (#17828 deferred that to first sync), so asserting `remote add`/`fetch`/`remoteCreated: true` at create time no longer matches reality. Retargeted both tests to assert the deferred contract (no remote add at create, pushTarget persisted unmaterialized); minting itself stays covered by worktree-remote-push-target-materialization.test.ts and worktree-push-target-setup.test.ts. Re-verified all 5 fixture points (mint upstream, store persistence, single-flight, short-circuit refspec widen + fetch-missing-ref for local and SSH, finite timeout) against a real git fixture after this fix -- all still pass. * fix(worktree): hook pty:spawn into deferred push-target materialization (#17828) triggerTerminalSpawnPushTargetMaterialization only fired for agent/background/ mobile terminals; the desktop GUI's own pty:spawn path (new tab, split, reattach) never materialized a deferred fork-PR remote before raw git commands could run there. Add a small wrapper that resolves the worktree's push target and owning repo from args.worktreeId via the store, and fire-and-forget delegates to the existing materializer, wired as the first statement of runPtyIpcSpawn. Degrades silently (optional chaining + catch) so a partial/fake Store in existing spawn tests can't turn this into a spawn-blocking throw. * test(worktree): retarget stale editor-remote-branch assertions for worktreeId threading runtime-git-sync-client's local-path fetch/pull/fastForward/push calls now forward context.worktreeId (needed by the main-process handlers to key deferred push-target materialization). Update the 17 call-site mocks across 15 tests in editor-remote-branch-actions.test.ts to expect worktreeId: 'wt-1', matching the already-correct source behavior -- no assertion was loosened. * fix(worktree): give a materialize joiner its own branch wiring The materialize single flight is keyed on the remote, but everything after the remote add is per-branch. A sibling worktree joining an in-flight mint for a different branch received the minter's target and skipped its own refspec widen, tracking-ref fetch, and upstream link, so its branch ended with no upstream at all. Wait for the remote, then run the per-branch work against the joiner's own target -- the same path the already-exists short-circuit takes, now shared rather than duplicated. Adopting a remote a sibling minted also stamps ownership, so removing the minter cannot strand the survivor's metadata outside the orphan sweep's reach. * fix(worktree): stop a failed mint from leaving a config-only fork remote Review of the joiner fix found it made things worse in three ways. Swallowing the mint's rejection let a joiner adopt a remote the rollback had already removed, writing remote.<name>.fetch with no URL. Verified on real git: that ghost section breaks `git fetch --all`, forces every later mint to a `-2` name, and cannot be removed by `git remote remove`. Propagate instead; the in-flight map is already cleared, so a retry re-mints. The SSH twin still returned the minter's target to a joiner, so the original per-branch bug survived there. It now adopts against its own target through a twin helper. The ownership stamp was unreachable: it required both a store and a repo id, and no caller passes both. Derive the repo id from the worktree id. Adopters also write remote config, and concurrent `git config --add` has no lock retry -- 135 of 160 writes failed at 8-way concurrency, and equal values duplicate the refspec. Chain adoptions per remote.	2026-09-01 22:44:05 -07:00
Neil	401664298f	fix(preload): make a dropped bridge key a compile error ... The split silently dropped jira.searchUsers and runtimeEnvironments.retryControlConnection. Neither failed typecheck: the bridge modules carried no satisfies annotation and the composed api object was unannotated, so a missing key was only a runtime TypeError in the renderer. Annotates each module against PreloadApi, the type window.api is already declared as, so the contract supplies the shape rather than a parallel copy. Deleting jira.searchUsers now fails with TS2741 naming the key. Turning this on surfaced 106 places where a bridge locally annotated Promise<unknown> or unknown[] over a contract that declares concrete types -- the bridge was erasing types the renderer relied on. Those annotations are gone. Also exposes app.awaitBeforeUnloadCheckpoint, which was declared and called but never actually on the bridge, so the lazy-chunk recovery reload optional-chained to a no-op and navigated without joining the checkpoint. The missing key was caught by the new annotation rather than by hand.	2026-09-01 18:24:49 -07:00
Neil	d1abe28471	refactor(preload): split bridge API modules ... (cherry picked from commit b77e31873b)	2026-09-01 00:57:54 -07:00