* test(codex): pin Codex read-repair with a real-binary contract check
Orca's session index-heal depends on a Codex behavior: a `thread/read` of an
unindexed rollout performs a read-repair that inserts the `threads` row. All 55
existing heal tests drive a stub app-server and assert "healed" as "the call did
not error", so if Codex ever dropped the repair they would all stay green while
the subsystem went silently inert.
Adds a real-binary contract check built to the same shape as the Git binary
compatibility contract (src/shared/git-binary-compatibility.test.ts): env-gated
test file, version asserted against the binary, dedicated path-filtered PR job.
Pins only the four arms ablation established Orca relies on:
- a read of an unindexed rollout inserts the state row
- a session with no read inserts nothing (the negative control that makes the
insert causal rather than incidental)
- re-reading an indexed thread inserts nothing
- an archived thread stays archived rather than being resurrected
Written against codex-cli 0.150.1. The job sets ORCA_CODEX_CONTRACT_REQUIRED=1
so a missing or failed CLI install fails red instead of silently skipping.
Existing heal tests are unchanged.
* test(codex): register the contract job in the verify aggregate contract
`pr-workflow-parallelism.test.mjs` pins `verify.needs` exactly, so adding the
job to pr.yml without updating that list failed the shard. Adds the entry, and
adds a workflow contract test mirroring `git-binary-compatibility-workflow.test.mjs`:
- the pinned CODEX_CLI_VERSION is the single source for both the npm install
and the runtime version assertion, so the two cannot drift apart
- the install prefix and the binary path the test is pointed at are the same tree
- ORCA_CODEX_CONTRACT_REQUIRED=1 is set, so a failed install fails red rather
than turning the job into a green no-op
Removing the REQUIRED env from pr.yml reddens the new test, confirming it is live.
* test(codex): make binary version guard exact and bounded
* ci(codex): cover index-heal transport dependencies
* test(ci): pin Codex contract dependency coverage
* test(codex): align contract watchdog with child deadlines
* test(codex): cover three-session contract watchdog
* fix(codex): add sqlite sync-database to index-heal scope
---------
Co-authored-by: Merge Sim <sim@local>
A path-filtered PR still posts three green meta jobs — the path classifier,
the root-directory guard and the LoC counter — and the usability test was
"did any check run", so two of them counted as a full corroborating witness
pair. Real payloads from #17002 (docs-only) and #16917 (mobile-only), 2.2h
apart in two stacks, returned `clean` for a window in which no test,
typecheck or static-analysis lane had run at all.
A witness now has to have run a lane that would have gone red if `main` were
broken. That list is an allowlist, so an unrecognised name costs a witness and
degrades the verdict to `unknown` rather than buying one and pushing it to
`clean`; every unrecognised name is printed on each run.
Also groups two branches that share an unlisted parent as one stack. Grouping
only by listed parents counted them as two independent stacks, so the
corroboration the `broken` and `upstream` verdicts rest on was one witness
counted twice.
The doc claimed the first property the code did not have; corrected.
* ci: gate PRs on a real input method, and prove the lane engaged one
No job on the PR gate has ever run a real input method. pr.yml and e2e.yml are
ubuntu-latest with CDP `Input.imeSetComposition`, which is a synthetic
composition; the only job that drives ibus-hangul through xdotool is
terminal-ime-e2e.yml, and it is schedule + dispatch only. A PR could turn the
real-IME path red and merge green.
Route IME source to that lane from pr.yml through the existing
pr-e2e-source-routing mechanism, so it runs on IME-touching PRs and nothing
else. The lane stays out of verify.needs — advisory, like `e2e` — because its
reliability is known only from nightly main runs. Deliberately no
continue-on-error: that reports green and hides the signal.
The harness fails open in ways that all look like success: Playwright reports a
skipped test as a pass, so an unset ORCA_E2E_NATIVE_IBUS_HANGUL, a renamed test,
or a session with no engine all exit 0 having exercised nothing. The specs now
append an engagement receipt only after observing real composition events, and
the runner requires one per expected test before the lane may report success.
Also drop the native spec from changed-e2e: it was already routed there by its
own filename, where it self-skips for want of an ibus session and reported that
skip as coverage.
* ci: let the real-IME step report even when the synthetic step failed
An eleven-PR chain merged main during a window in which main itself was
broken; six nodes went red and the reds were diagnosed as merge damage.
They were not. The tell was already in the data: an identical failure set
on every node, including the root. Damage from a merge varies with what
each node changed, so identical failures across a chain are upstream.
main's own CI cannot answer this. pr.yml is `on: pull_request` only and
unit-tests.yml is `workflow_call` only, so no commit on main carries a
test result at all. The probe reconstructs main's health from the PRs
whose CI ran against it in a window, classifies each check by whether its
reds form one unbroken stretch in time (upstream) or interleave with
greens (branch-specific), and reports broken / clean / unknown.
It never reports clean without corroborating independent witnesses, and
it refuses evidence whose checks ran more than a day apart, since those
observed different mains. The roll-up `verify` job, the known-false reds
and third-party app checks are excluded and printed, never dropped
silently.
* fix(build): preserve Electron during binary repair
* refactor(build): split native dependency fixtures
* fix(build): resolve one Electron install target for child and check
runElectronPackageBinaryInstall forced ELECTRON_INSTALL_PLATFORM/ARCH to the
host-derived rebuild target, clobbering inherited installer env, while the
parent usability check still honored the inherited value. A bare
`node config/scripts/rebuild-native-deps.mjs` under ELECTRON_INSTALL_PLATFORM=win32
on Linux therefore installed the Linux binary and then rejected it as
unavailable. Resolve the target once (CLI, ELECTRON_INSTALL_*, npm config, host)
and use it for both the child env and getElectronPlatformPath.
* fix(build): keep Electron install transaction cleanup best-effort
The finally-block rmSync could throw after a fully successful publish (Windows
EPERM when another process still holds the discarded old electron.exe open),
turning a correct install into exit 1. On the rollback path it could also
replace the in-flight publishError with an unrelated temp-dir error. Retry the
removal and downgrade a persistent failure to a warning.
Provide the existing HTML canvas test double when happy-dom exposes an adapter-less OffscreenCanvas 2D context. This keeps xterm tests working across supported happy-dom versions without changing production rendering.
Patched windows-process-tree binding.gyp includes deps/node-addon-api, but
those headers were only copied by the later relay-addon script. Postinstall
electron-rebuild then failed CI Windows installs with C1083 napi.h.
pnpm 12's npm_execpath is a Mach-O/PE binary. build-native-for-platform.mjs
still launched it with `node $npm_execpath`, which throws SyntaxError on
the binary header and fails every signed macOS dev-channel build.
Three of the four Codex app-server teardown cases carry a 60s budget; the
forced-close case was left on the 30s default while driving the same 40
consecutive launches. All four measure 5.8-6.5s under contention here, so the
outlier was the one case with no headroom. Give it the sibling budget.
The other two are budgets that outgrew their tests: the runtime-electron
ratchet walks the real module graph in ~0.7s under 120s, and the issue-4631
hover-link repro asserts its own work finishes in under 100ms, so a 120s
budget can never fire before that assertion does.
Measured before changing anything: solo and under full worker parallelism
with 24 CPU hogs on 18 cores. No budget was lowered on an unmeasured test.
The parent commit pins the whole tree to LF and leaves one question open:
whether resources/win32/bin/orca.cmd should be an exception. Measured against
the shipped v1.4.192 installer, it should -- though for a narrower reason than
the open question assumed. See the finding below.
The release Windows runner pins nothing and sets no core.autocrlf, so it
converts this file on checkout. The committed blob is 644 bytes with 0 CR; the
copy inside orca-windows-setup.exe is 665 bytes with 21 CR, and is sha256-
identical to that blob with every LF doubled. 665 - 644 = 21, the file's line
count. The same installer carries its own control: the seven files under
resources/plugins/ were already pinned eol=lf and shipped unconverted, byte-
identical to their blobs. One artifact proves both that the conversion is live
and that a pin overrides it.
That reverses the framing. Pinning CRLF reproduces today's artifact exactly;
it is leaving the file to the blanket rule that flips a shipped byte. Verified
across every checkout config: with the pin the working tree is 665 B / 21 CR
under core.autocrlf=true, false and input alike; without it, 644 B / 0 CR under
all three, and a real windows-2022 runner confirms `i/lf w/crlf` with the pin
and `i/lf w/lf` without. The index blob is unchanged either way.
FINDING: LF is not broken. check-windows-launcher-line-endings.ps1 ran the shim
both ways on windows-2022 and both encodings passed both arms -- the goto-label
hazard did not reproduce. So this pin is a consistency choice, not a
correctness fix: it reproduces the bytes v1.4.192 shipped and stops them being
decided by a build-image default nobody controls. A uniform-LF decision would
now be defensible; what should survive either way is that something finally
executes this file. Until now nothing did -- smoke-packaged-cli.mjs resolves
the packaged CLI to resources/bin/orca.exe on win32, never the .cmd beside it.
The shim sits outside the parent gate's population (no shebang, mode 100644),
so the two rules cannot contradict each other; a test asserts that.
check-line-ending-policy.mjs now asserts the exception rather than merely
permitting it: the blob must still be LF and eol must resolve to crlf. An
exception nothing checks is how this file's encoding became a runner-image
accident in the first place.
check-windows-launcher-line-endings.ps1 adds the empirical half on the existing
package (windows) job, first step after checkout, one second. It confirms the
runner really wrote CRLF, then runs the shim's guard path and its fall-through
under a real cmd.exe, using a copy of cmd.exe as the orca.exe the shim requires
-- without one the shim exits 1 before reaching either arm. It reports the LF
verdict without ever failing the job on it. Both checks were watched failing
with the pin removed before this landed.
Git for Windows defaults to core.autocrlf=true, so a stock Windows clone
rewrote the working tree on checkout. That is not cosmetic: Orca ships
executable shell scripts straight out of this repo, and a \r on the shebang
line stops them running — `resources/linux/bin/orca-ide` dies with
`env: bash\r: No such file or directory` (exit 127) instead of executing.
The same reaches `resources/darwin/bin/orca`, the deb/rpm maintainer scripts
and .husky/pre-commit. 122 of the 130 tracked shebang files had no protection.
Replace the nine ad-hoc eol=lf pins with one repo-wide `* text=auto eol=lf`.
`text=auto` leaves the binary decision to Git and the index was already
LF-only, so this changes zero index blobs: `git add --renormalize .` across
all 20,050 tracked files stages nothing.
Add config/scripts/check-line-ending-policy.mjs to `pnpm lint`. For every
tracked file the OS has to exec (leading `#!` or the executable bit) it
asserts the committed blob has no CRLF and that `git check-attr eol` resolves
to `lf` — two independent failure modes, neither implying the other. The
population is derived from content rather than hand-listed, because a curated
list would have had to name 122 files today and would silently miss the 123rd.
Whether resources/win32/bin/orca.cmd should be pinned to CRLF is left
undecided; it changes a shipped byte. .gitattributes carries the one-line
follow-up as a comment.
Refs STA-4307
Oxlint writes configuration failures to stdout, and the slice from the first
brace to the last one takes a wrapper's own warning for the report, so the gate
died with "did not return Oxlint JSON output" and discarded the only
explanation of why.
The batch budget counted only the file list, but execve() charges argv, the
inherited environment and one pointer per entry against a single ceiling. A
256 KiB batch beside a large environment failed the spawn outright, so the
gate reported nothing instead of linting.
Compute the budget from everything the spawn carries: the Node binary, the
Oxlint entry point, the fixed flags and — on POSIX only, since Windows ships
it in a separate block — the environment. Budget against half of macOS'
kern.argmax rather than all of it: a Node child SIGSEGVs (24) or throws a
stack-overflow RangeError (26) near 970 KiB, well before E2BIG at 1,048 KiB.
Resolve the Oxlint launcher from its own manifest instead of assuming a flat
node_modules layout, and name the scan and batch when a spawn fails so it
reads as a launch failure rather than a crash in the gate.
Oxlint takes paths as positional arguments only, so `check:code-quality:changed`
spawned one process carrying every changed file. A lane's `.orca-task-*` scratch
tree holding seven nested repo checkouts put 39,079 untracked source files in
scope — 3.5 MB of argv against a 1 MiB ARG_MAX — and the gate died with E2BIG
before Oxlint ran.
Two fixes: ignore the per-task scratch trees so a foreign checkout is no longer
counted as your changed code, and batch the argument list under 256 KiB per
invocation, concatenating the diagnostics so every batch reaches the exit status.
- Translate Agent Dashboard column headers (Needs You / Working / Idle), board title, and total count.
- Translate empty-column placeholder, "You" message badge, terminal preview actions, and error-boundary copy.
- Resolves English fallback in the Agent Dashboard (dashboardPopout) under the Korean locale; only "Done" was previously translated.
* fix(ci): stop the Linux Electron probe step from starving its own probes
The package job's "Test Linux Electron lifecycle boundary" step ran five
Electron probe files under Vitest's default file parallelism, so four full
Electron stacks competed for a 4-vCPU runner. Each probe carries its own
in-process deadline (20s for WebRTC, 25s for H3), and every observed failure
was one of those deadlines expiring: exit code 2, "no result", with every
sibling file in the same run slower than its own green maximum.
Run the step with --no-file-parallelism so each probe owns the runner, and
stop each probe nesting a private `xvfb-run --auto-servernum` X server inside
the step's own xvfb-run: reuse an inherited DISPLAY, and only own one when
there is none (shards, local dev), which leaves those lanes unchanged.
Also set each Docker-SSH E2E step's Playwright output aside before the next
step starts, because Playwright empties test-results/ on every run and only
the last lane's traces survived to the artifact.
* fix(ci): route the persisted-worker probe through the same display resolver
The window-close guard selected local worktrees before probing, so every
direct-SSH pane was dropped unprobed and the window closed with no warning
over work still running on the remote host. A direct-SSH shell does not
survive the window, so "it runs elsewhere" was never a reason not to ask.
Drop the owning-host filter entirely rather than adding a parallel remote
branch: `inspectProcess` dispatches on the PTY id, so each pane is answered
by whichever host runs it (ssh-pty-provider's `pty.inspectProcess` request),
and the existing evidence read already carries the whole verdict vocabulary.
That also stops discarding a worktree whose repo has not hydrated yet, which
the `!== null` test read as remote.
Verdicts are unchanged and stay in window-close-running-process-evidence.ts:
`exited` is the only one that closes with no prompt. A relay too old to
answer `pty.inspectProcess` rejects with method-not-found and a dropped
connection rejects too — both are `unverifiable` and both ask. No missing
reply is ever spent as an observed absence. Runtime-environment panes stay
excluded: that host outlives this window by design.
The warning now speaks for remote panes too, so it no longer scopes itself
to local terminals; all five catalogs and the ja exact-match repair follow
the new English string. No new wire field and no new stream opcode.
* feat(native-chat): port structured Codex sessions from restructure-recovery
Rebuilds the desktop structured native-chat implementation from
brennanb2025/native-chat-restructure-recovery (tip 4e31c08db3) on top of
current main as a single commit, scoped to the local Codex path.
Ported:
- Structured agent-session core: durable record store + single-writer lease,
canonical journal, agent-session wire host/attach/eviction/subscribers,
`agentSession.*` RPC surface (registered via ALL_RPC_METHODS; host-side
mobile allowlist included for wire compat), pty write gate, transcript
additions, and the Codex app-server adapter/launch resolution.
- Renderer: NativeChatStructuredSession view/composer stack, structured
launch path with the single-flight guard, local structured session tabs
sync, activation gate + structured inventory (read-only
`agentSession.handoffStatus` probe), agent-session tabs in the tab strip,
AI-vault structured session activation, and the settings pane with the
parent Experimental Chat UI toggle plus the nested "Use updated structured
native chat" toggle. New sessions require both flags, agent codex, no
prompt, and a local non-WSL, non-Windows-host execution host
(structured-native-chat-availability).
- Fixes 72c013cea6 (verified Codex launch recovery), 8ddbaf5e3d (defer
native terminal view switching affordances), and 4e31c08db3 (release the
launch gate after a visibility retry) with their regression tests,
including the third-launch-after-retry guard case.
- Cross-version agent-session wire test + CI lane, packaging entries
(proper-lockfile, agent-tooling asar excludes), and the wire-compat doc
section.
Deliberately not ported: mobile/ changes, the Claude structured runtime
(only the claude-transcript-branch-proof and claude-structured-owner-identity
leaf modules remain, backing the kept TUI-recovery arms), the terminal↔chat
adoption/handoff flow (`agentSession.adoptTerminal`/`requestHandoff`, the
handoff request engine, TUI adoption machinery, orca-runtime adoption
methods), renderer switching affordances and their dead leftovers, the
hook/subagent-status refactor cluster, and unrelated branch changes. The
crash-during-acquisition recovery path (restart handoff adjudication,
restore/reverse re-acquire, lease schema handoff keys) is kept because every
plain direct launch depends on it; a trimmed handoff coordinator exposes
only status/restore/close.
Branch edits that targeted files main has since split (ipc/pty.ts,
worktrees.ts, rpc/methods/terminal.ts, useIpcEvents, pty-connection,
store/slices/terminals.ts, runtime-types, web preload) were re-applied to
the split modules, preserving main's newer logic (Windows CIM fallback,
browser tab close rework, cold-restore resume flow, dispatcher threading).
Known seam: the mobile clipboard image-provenance CONSUMER gate ships
(agentSession.send refuses unproven mobile image refs with
agent_session_image_untrusted) but the producer hunk in
rpc/methods/clipboard.ts stays with the unported mobile cluster, so mobile
image sends into structured chat fail closed until that side ports.
* fix(native-chat): trust only authenticated local image uploads
* fix(build): preserve Windows process-tree patch application
* test(windows): include process creation time in addon fixture
* fix(build): run windows-process-tree node-gyp from the physical package dir
gyp expands the node-addon-api dependency by probing node, whose cwd
resolves to the package's physical directory in the store, so the emitted
target is a store-relative ../../../../node-addon-api@... hop. gyp then
resolves that hop against the rebuild cwd; from the node_modules
symlink/junction it escapes the store and configure fails with
"node_addon_api.gyp not found" (run 32999886072).
Rebuild from realpath(package dir) so both bases agree, matching how the
package manager itself runs native install scripts. The regression test
replays gyp's expansion+resolution against the planned cwd and fails
without the fix.
* fix(native-chat): keep chat tabs visible through terminal closes and empty-worktree launches
Two proven blockers in the native Codex tab contract:
closeTerminalTab pre-empted the canonical unified close. With one terminal
left it deactivated the worktree on a terminal/editor/browser-only check,
blanking a workspace that still held a renderable agent-session tab; with
two or more it pre-picked a successor from terminal entities only,
re-stamping the group active before closeUnifiedTab's MRU/neighbor repair
could land on the chat tab. Successor choice now defers to the unified
contract whenever the terminal has a unified row, and deactivation is
gated on the unified renderable count (matching leaveWorktreeIfEmpty),
with the legacy pre-pick kept only for terminals without a unified row.
A structured session created on an empty worktree was published into the
host's headless group while preserveLocalLayout froze the local layout,
leaving the tab in store but permanently off screen. A preserveLocalLayout
owner now always takes client-owned placement — repairing a rendered
leaf whose group record is missing, or materializing a rendered group on a
truly empty worktree — and applies the client-derived layout repair while
still rejecting host-authored layout.
Regression tests drive the real store through closeTerminalTab (git
worktree and folder workspace) and the real snapshot applier for the
empty-worktree adoption states; all fail without the fixes.
* fix(native-chat): close stale turns and retry rejected sends
* fix(native-chat): retire hosted rows on structured tab activation
* fix(native-chat): preserve rpc defaults across main merge
* chore: format remote wire compatibility guide
* test(native-chat): cover retry after unconfirmed send
* fix(native-chat): reload outbox on session switch
* docs(settings): disclose structured chat platform limits
* fix(native-chat): await Codex launch-home preparation
* fix(codex): align child-process allowlist with async trust bridge
* test(identity): update inventory for tab surface refactor
* fix(windows): preserve process-tree CRLF patch sources
* fix(native-chat): anchor an unmatched chat echo where it was sent (#16117)
* fix(native-chat): anchor an unmatched chat echo where it was sent
The reported symptom was old user messages replaying below every new turn, so the
conversation read as scrambled. The cause was not that the echo failed to match a
transcript row. Claude consumes a mid-turn send through a `queued_command`
attachment and writes no `type:"user"` record for it, so some echoes can never
match, and no amount of matching will change that. The cause was WHERE an
unmatched echo rendered: buildMobileNativeChatTransientData appended every pending
item after the entire transcript, so it re-read below each turn that landed
afterwards.
Render each echo directly after the transcript row it was sent against, using the
baseline the send already captures. An unmatched echo is then at worst a duplicate
in the right position rather than a scrambled one, and it stays visible. Echoes
sharing an anchor keep send order; a send with no baseline, or one whose anchor
folding dropped, still falls back to the tail.
Deliberately NOT fixed by deleting the echo. Inferring from send ordering that an
echo can never match, then removing it, loses the user's own text for a message
the agent did receive, and it cannot fire in the common case anyway - measured
drain groups are 1,017 of size 1 against 55 larger. It also escalates an existing
gap: the count pass has no baseline-tail guard, unlike the glue pass, while
`messages` is a 40-row window that head-trims, resets on reconnect and grows at
the front on loadEarlier, so a false landing there would license deleting a
DIFFERENT outstanding message.
That count-pass gap is real and left for a separate change; anchoring makes its
worst case a duplicate in place rather than a scrambled conversation.
* fix(native-chat): preserve folded echo anchors
* fix(native-chat): preserve forward-folded echo anchors
* fix(native-chat): keep leading folded echoes in place
* fix(workspace-cleanup): show git status for every row (#16690)
* fix(native-chat): refuse structured chat on every Windows execution path
canUseStructuredNativeChat only refused win32 when a project runtime
resolved, so folder-workspace keys (and other keys with no project
runtime) failed open into structured chat on Windows. Fail closed on
win32 unconditionally after the host check, matching the settings copy:
local macOS/Linux only; Windows/WSL/SSH stay on terminal chat.
* fix(native-chat): restore runtime refusals behind the win32 gate
506d375de3 replaced the project-runtime checks with a bare platform test,
so a WSL or repair-required runtime resolution would no longer refuse
structured chat off-win32. Keep the unconditional win32 refusal and
re-run the runtime resolution after it, so the gate does not depend on
the resolver's own platform guard. Tests inject WSL and repair-required
resolutions on darwin/linux and fail against the regressed gate.
* fix structured session journal durability
* fix structured tab active pointer after restart
* fix(native-chat): await optional lease renewal callbacks
* refactor(skills): extract install error messages
* fix(agent-session): harden recovery ownership
* fix(native-chat): retain panes across tab activation
* fix(native-chat): address round-one review findings
* test(native-chat): align integration coverage after main merge
* fix(native-chat): harden round-two reliability
* fix(native-chat): harden round-three reliability
* fix(native-chat): close round-four recovery gaps
* fix(native-chat): separate bounded journal key forms
* fix(native-chat): reset outbox error in render on session switch
The switch effect adjusted error state after the sessionId prop changed,
tripping react-doctor's no-adjust-state-on-prop-change on the changed-code
gate and flashing the old session's banner for a frame. Reset it with the
render-time previous-value guard instead.
* fix(native-chat): invalidate stale outbox settlements
* test(native-chat): restore settled-error session-switch regression
a6e2379bd1 replaced this test with the in-flight settlement race test,
leaving the render-time error reset unpinned: deleting the reset block
still passed the whole native-chat suite. Keep both scenarios pinned;
they are distinct (settled error clears on switch vs stale settlement
invalidated in the commit-to-passive window).
* test(wire): make release checkouts race safe
* test(wire): pin cross-process checkout single-flight and importer specifier contract
* test(wire): harden release checkout lifecycle
* fix(build): drop CR-byte residue from windows-process-tree patch
The two trailing CR bytes on the patch's deletion lines are a proven
no-op: pnpm hashes patches CRLF-normalized (both forms hash to the
lockfile's 946ffb2b) and materializes this package without applying the
patch in either form, so the load-bearing build edits come solely from
applyWindowsProcessTreeBuildFixes() (#16947), which handles both source
EOL forms. Restore byte-identity with main and repin the contract test
to the post-#16947 reality: LF-only patch bytes plus lockfile hash sync.
* fix(native-chat): skip empty startup recovery
* style: format codebase
* style: format codebase
* refactor: extract skill install dialog footer and content
Extract footer and content sections from SkillInstallDialog and
SkillInstallManagementDialog into separate components for improved
maintainability and clarity of component responsibilities.
* feat(terminal): weight-layer forensics for the bold-collapse bug (STA-4042)
Field instrumentation to name the writer behind regular-text-renders-bold:
- metric-weight-change crumbs at the writePaneMetricOptions funnel
(prev/next/reason; weights never change in normal operation)
- terminal-weight-parity-mismatch audit on every visibility resume
- sentinel weightProbe capture fields: live options vs atlas captured
config vs renderer-buffer bold census
- Cmd/Ctrl+Shift+click unconditional capture (no divergence gate, no
recovery) for states the missing-ink detector cannot see
- patched addon-webgl ctx.font readback probe: detects failed font
assignments that rasterize glyphs at a stale weight
* fix(terminal): treat canvas weight-700-serializes-as-bold as a match in the atlas font probe
Found by live validation: Chromium's ctx.font getter normalizes numeric 700
to the keyword 'bold', which made every legitimate bold rasterization count
as a failed assignment (124 false positives in one session).
* chore: update patch hash for the font-probe normalization fix
* fix(terminal): bound bold glitch diagnostics
* fix(terminal): cover serialized WebGL probe state
* feat(settings): hidden staff toggle to arm terminal render diagnostics
Replaces the reserved hidden-experimental placeholder slot with a real
switch (Shift-click the Experimental sidebar entry to reveal). It arms
and disarms the render-desync capture sentinel live — no localStorage
incantation, no reload — for the bold-glitch investigation. The passive
probes stay always-on; only the capture gestures are gated.
* fix(settings): make render diagnostics disarm exact
* chore(settings): rename hidden group to 'Hidden experimental settings', drop its description
* feat(settings): unlock hidden experimental group via Option-click on the Experimental page title
Replaces the Shift-click-sidebar unlock with the Updates-header idiom:
Option-click the Experimental page title toggles the hidden group.
Removes the now-unused click-modifier plumbing from the settings sidebar.
An enterprise user: "Every day I open orca and it opens more tabs daily at a
linear scale." Three reports over a week, told on 08-19 that a PR had fixed it,
reported twice more after. STA-4658 (P0), GH #12447, #15136, #10342, #9585. One
install held 39 zombie tab records. The revived tab's sleeping-agent record still
holds the pre-close session id, so it boots `claude --resume <old id>` -- two
agents on one transcript.
## The chain, measured
Reproduced deterministically in `ssh-lost-kill-tab-resurrection.spec.ts`: close
an SSH tab, kill the relay daemon in the container so `pty.kill` rejects with a
transport-class error, reconnect.
drop 2 resurrected the closed tab <id>:
baseline=1 drop1=1 drop2=2 (closed tab returned) drop3=1
The trigger is narrow and had to be measured rather than assumed: killed relay
daemon reproduces **6 of 6 runs**; an orderly `ssh.disconnect` **passes**. Only
an ungraceful loss -- network partition, host reboot, relay crash, a laptop
sleeping mid-session -- strands the close with the RPC rejecting on a
transport-class error. Both variants live in the spec behind one
`runResurrectionCycles` parameterized solely by the disruption, so the difference
is attributable to that single variable.
What actually carries the tab back, from the pull path
(`workspace.get` -> `getRemoteSnapshot`, `remote-workspace-relay-sync.ts:29`):
pullSnapshot rev=3 tabs={repo:["16c4a3e1","06aba6b6"]}
pullSnapshot rev=4 tabs={repo:["16c4a3e1","ff72768e"]} <- ff72768e IS the resurrected tab
pullSnapshot rev=5 tabs={repo:["16c4a3e1","ff72768e","da21b76c"]}
The client uploaded the session containing the tab; the user closed it; the kill
RPC rejected so the close never reached the host; the host's snapshot still lists
it; the client pulls it back and the merge restores it -- **correctly, by its own
rule that the host is authoritative for what it knows.** A pane then mounts,
respawns, and takes the recycled pty id.
Client-side correlation from the same run, two controls and one positive in one
run differing in exactly one variable:
| Tab | Close events observed | Resurrected? |
|---|---|---|
| `6305cc07` | `user` + `pty-exit` | No |
| `ed56f66c` | `user` + `pty-exit` | No |
| `2036e760` | `user` only | **YES** |
## The fix
`src/shared/closed-terminal-tab-tombstones.ts` (99 lines). A client-recorded
close is first-party intent and must survive until the host acknowledges it. Per
`docs/reference/ssh-execution-boundary.md` the remote verdict is `unverifiable`
-- which may not authorise declaring the process dead, but equally must not
authorise resurrecting the tab. This is SSH-v3 principle P2, "durable tombstones
with a monotonic per-scope revision", reusing the existing
`RemoteWorkspaceSnapshot.revision` rather than adding a twelfth per-tab identity
field (the codebase carries eleven, 784 refs, that SSH-v3 Phase 3 deletes).
- **Recorded** only on `closeReason === 'user'` (`terminal-tab-close.ts:69`).
- **Suppresses** a host-sourced tab only when
`tabId in tombstones && !currentTabsById.has(tabId)` -- a live local tab always
wins, because deleting a live pane is the one outcome the merge exists to
avoid.
- **Retires** on positive acknowledgement:
`!hostKnownTabIds.has(tabId) && hostRevision > observed`. Strictly newer, so a
pull already in flight at close time cannot ack a close it predates.
- Three never-retire guards: no revision retires nothing; a worktree the snapshot
has no row for retires nothing; the first omitting snapshot only stamps the
watermark.
- TTL (30d) + cap (500) are **backstops** for a target the user never returns to,
not the mechanism.
- **Client-local only** -- never crosses the wire, so there is no mixed-version
exposure.
- Suppression is scoped to `replaceWorktreeIds`, which is what makes the
live-tab check meaningful. A final whole-map sweep over the assembled
`tabsByWorktree` would break that (a live tab is absent from `currentTabsById`
outside the scope and would look suppressible); it is deliberately not there,
and the comment at the top of the function says so.
## Evidence
The load-bearing evidence is an A/B control on one tree, not the oracle's
assertion. Flipping `isSuppressedByClose` to `false` -- one character --
reproduces the resurrection on demand:
--repeat-each=2:
1) drop 2 resurrected the closed tab ab0e305d-…: baseline=1 drop1=1 drop2=2
2) drop 2 resurrected the closed tab 51533e34-…: baseline=1 drop1=1 drop2=2
2 failed
With suppression on: **0 occurrences of "resurrected the closed tab" across five
runs plus one independent run by a second agent.** Provenance verified
positively, not by mtime: `closedTerminalTabTombstonesByTabId` appears 13x across
3 renderer chunks including `store-Do3KBvRE.js`; for every red control run
`mayCreate` appeared 0 times in `out/main/index.js`.
At the unit layer, disabling the same predicate: 3 failed | 39 passed. Restored:
42 passed; 287 across the workspace-session, terminal-store, remote-workspace,
shared-tombstone and profile suites; 24 in the four tombstone suites.
## The oracle spec: GREEN in the full lane
`ssh-lost-kill-tab-resurrection.spec.ts` passes both tests at this commit. Full
Docker-SSH lane, clean tree:
BUILD_SHA=49bb96e0b4c DIRTY=0
PROVENANCE tombstone=13 hasLocalTabsRow=2 hostAuthority=4 mayCreate=3
14 specs / 20 tests -> 17 passed, 2 failed, 1 skipped (10.7m)
[12/20] :178 does not resurrect tabs whose kill was lost to a killed relay
daemon PASSED
[13/20] :190 does not resurrect tabs closed while the host is
disconnected PASSED
grep -c "resurrected the closed tab" (whole lane) -> 0
It passes WITHOUT PR 7 in the build (`mayCreate` present,
`SshPtyAbsentFromRelayError` absent), so the bug-2 fix below is not required for
it.
Test 1 fails intermittently in ISOLATED single-spec runs, where a third defect
blocks its cycle-2 setup. The resurrection assertion itself has never failed with
this fix in place -- the intermittent failure is always a setup failure, never a
resurrected tab. A reviewer running the spec alone may see it red; that is not
this fix regressing.
Three defects sit under STA-3374 and should not be conflated:
- Bug 1 -- the closed tab resurrects. Fixed here.
- Bug 2 -- `ssh-pty-session-reattach.ts:227-231` rewrites the relay's
`PTY "pty-1" not found` into a bare `SSH_SESSION_EXPIRED`, so
`isPtyAlreadyGoneError`'s `/PTY ".+" not found/` cannot match and
`attachStablePaneOwner:242`'s already-correct fallback never runs. Owned by
PR 7 (`nwparker/ssh-07-absent-from-relay`). Not required for the oracle above.
- Bug 3 -- after the daemon is killed and the client launches a replacement, the
client's OWN SSH transport drops and does not reconnect within 60s: no
"delay step 2/9", no handshake failure, nothing. `ssh-connection.ts:1533` only
logs on an SSH-level close. Unfixed, its own ticket. This is what makes test 1
intermittent in isolation.
Discriminator for bug 3, measured in the isolated runs (the lane above ran
without `ORCA_E2E_FORWARD_APP_LOGS=1`, so it was not re-confirmed there):
`[ssh-relay] Socket probe result:` reads "DEAD" on every cycle of test 1 (daemon
killed, a NEW relay must be launched) and "ALIVE" on every cycle of test 2
(daemon survived). Whenever a new daemon must be launched, the SSH transport
drops afterwards and does not recover.
An earlier reading blamed `kill.ts:82-84` for skipping `finishPtyShutdown` on a
non-already-gone error. That was eliminated by direct test: the implied fix,
`markSshRemotePtyLease(…, 'expired')` in that branch, was implemented, changed
nothing, and was reverted rather than shipped unproven. Recorded so the path is
not re-walked. The `SSH_SESSION_EXPIRED` rejection is real but fires during cycle
1 for the baseline pane, after which cycle 1 completes; the 60s silence begins
only after `Relay channel lost ..., triggering reconnect`.
The spec is claimed by the Docker-SSH lane, and that lane does not gate merges
today.
## Persistence: the tombstone must survive a relaunch
`closedTerminalTabTombstonesByTabId` is declared on `WorkspaceSessionState` but was missing from
`workspaceSessionStateSchema` (`src/shared/workspace-session-schema.ts`), which is the load boundary
for BOTH partitions -- `normalize-loaded-state-collections.ts` for `local` and
`workspace-session-partitions.ts` for `ssh:<target>`. Zod strips unknown keys and the write side does
not validate, so the map reached disk and was discarded on the next launch. Measured with the repo's
own parser:
input : closedTerminalTabTombstonesByTabId: { 'tab-1': {...} }
ok = true
tombstones after parse = undefined
That made the fix ineffective in the exact reported scenario: close an SSH tab with the transport
down, QUIT, relaunch, reconnect -- the merge runs with an empty map, the host still lists the tab,
and it resurrects. "Every day I open orca and it opens more tabs" is a claim about restarts.
Neither the green oracle nor the A/B control could see it: both run entirely inside one app process.
It also made the 30-day TTL and the 500 cap unreachable.
Fixed by adding the field with a `salvagingRecord` matching its sibling
`terminalSurfaceTombstonesByPaneKey`, so one malformed entry drops that entry rather than the map.
`workspace-session-schema.ts` was one line under its 300-line max-lines limit, so adding the field
required room rather than a suppression (the project forbids max-lines disables and per-file bumps).
Two value schemas were extracted to modules named after what they contain:
`terminal-tab-id-schema.ts` and `terminal-surface-tombstone-schema.ts`. The closed-tab tombstone's
own schema is colocated with its type in `closed-terminal-tab-tombstones.ts`, which is where it
belongs -- omitting it from the session schema is exactly the drift that caused this bug.
`workspace-session-schema-field-coverage.test.ts` is the ratchet. Two sibling tables already pin
themselves with `satisfies Record<keyof WorkspaceSessionState, ...>`; this schema had no such guard
and is the one that fell behind. The new file adds both halves -- a `satisfies` list that makes a
forgotten field a compile error, and a runtime assertion that names it -- plus a
`parseWorkspaceSession` round-trip. Without the schema entry: 3 failed. With it: 3 passed.
## A host tab the user never closed could be deleted
`tabId in closedTerminalTabTombstonesByTabId` answers true for every `Object.prototype` key even on
an EMPTY map, because the map is a plain object from `Object.fromEntries`. A host tab whose id is
`toString` was filtered from the reconciled list, blocked from the host-unknown branch, and stripped
of its layout and session id. Tab ids are validated only as non-empty and colon-free, and `createTab`
honours caller-supplied id hints, so the id is reachable rather than theoretical. This was the only
path in either direction that could delete a tab the user never closed.
Now `Object.hasOwn`, as the same file already uses elsewhere.
Suppression is also scoped structurally: `isSuppressedByClose` compares the tombstone's stored
`worktreeId`, which it already carried, so it cannot reach another workspace's tab. The two sweeps
that have no worktree in scope (`terminalLayoutsByTabId`, `remoteSessionIdsByTabId`) now consult the
set of ids this merge actually suppressed rather than re-deriving a verdict without that scope.
The scope comment at the top of the function was also wrong and is corrected. It claimed every use of
suppression sits inside `replaceWorktreeIds`; it does not -- the tabs pass walks all of
`orderedWorktreeIds` and the two sweeps cover the whole remote maps. What actually makes it safe is
that `closeTab` strips the id from every worktree row before recording the tombstone, plus the
worktree match above, plus `closeReason === 'user'` being the only writer. Real guarantee, different
from the documented one.
## Divergences from open PR #16571#16571 implements the same concept. Three deliberate changes:
1. It never retires on acknowledgement -- TTL+cap only, so it never converges.
Ack retirement added.
2. It crosses the wire and lets a HOST-sourced tombstone delete a LOCAL tab in a
final whole-map sweep. After #14361 that is the wrong risk; dropped. This also
removes the mixed-version regression its own body flags.
3. Its hydration unions rather than replaces the map -- a union resurrects every
tombstone the merge just retired, so it never converges.
Its `activeTabId` nulling is also dropped as redundant:
`workspace-terminal-hydration.ts:99-105,126-138` already revalidates both
pointers against the tab rows it just built, and nulling twice would add a second
rule that has to stay in step with the first.
## Can a tab the user did NOT close disappear?
No, but the guarantee needs stating precisely. The only writer is
`recordClosedTerminalTabTombstone` (`terminal-tab-close.ts:69`), reachable only
on `closeReason === 'user'`; suppression additionally requires the tab not be live
locally. Reopen (`recently-closed-tabs.ts:122-166`) calls `createTab` and restores
cwd/shell/title/color/position, never the old id.
**Caveat, stated because the slogan is not literally true:** `createTab` honours a
caller-supplied id hint (`terminal-tab-creation.ts:53-65`, used by `useIpcEvents`
for host-admitted tabs), so "tab ids are uuids that never recur" does not hold in
this codebase. The guarantee rests on the `closeReason === 'user'` writer plus the
live-local-tab check, not on id uniqueness.
## Risk
Renderer-side, client-local, no wire change. The blast radius is
`mergeDirectSshRemoteWorkspaceSession` and the persisted session field. Worst case
if the ack logic were wrong in the retiring direction: a tombstone outlives its
usefulness and suppresses a host tab whose id the host re-issues -- bounded by the
live-local-tab check, the 30d TTL and the 500 cap. Worst case in the other
direction is today's behaviour. `profile-project-session-field-disposition.ts`
records the new field as `notRepoScoped` / `notTransferred` residue, bounded by
the same TTL and cap.
## Verify
pnpm test src/shared/closed-terminal-tab-tombstones.test.ts \
src/renderer/src/lib/workspace-session-closed-tab-tombstones.test.ts \
src/renderer/src/store/terminals/terminal-tab-close-tombstone.test.ts \
src/renderer/src/hooks/remote-workspace-session-merge-close-tombstones.test.ts
To reproduce the bug this fixes, set `isSuppressedByClose` to `() => false` in
`remote-workspace-session-merge.ts` and run
`pnpm test:e2e:ssh-docker -- tests/e2e/ssh-lost-kill-tab-resurrection.spec.ts --repeat-each=2`.
Two client behaviours read local tab rows as the verdict on what the execution
host is running. Before the host answers, "I hold no pane for this" is
`unverifiable`, not `exited` -- the collapse
`docs/reference/ssh-execution-boundary.md` forbids.
Symptom 1, seeding. `worktree-initial-terminal-seeding.ts:47,128` seeds a
terminal when `renderableTabCount === 0`. Its only bail-out (`:72-77`) covered
the paired-web-runtime flavor -- "while that session is live the host owns
terminal creation" -- with no equivalent for direct SSH. So a client that has
never held the workspace runs the predicate during the hydration gap and creates
a tab from nothing. The snapshot then arrives, the merge rightly keeps the tab it
was never told about, and the union uploads as the new host truth. Measured on a
fresh client against a host owning 3 tabs: **1 tab created from nothing, 0 of the
host's 3 adopted.** (A restart never reaches the predicate -- local state
restores the row first -- which is why restart-only repros came back flat.)
That guard was also the wrong question. It asked "am I a client of a live paired
session?", which a host desktop window answers "no" and a paired client answers
"yes", so both seeded -- #15556.
Symptom 2, sleeping-agent resume, and the data-corrupting half.
`Terminal.tsx:1554` calls `resumeSleepingAgentSessionsForWorktree` twenty lines
after the seeding call at `:1529-1534` -- same startup path, same pre-hydration
window, and not SSH-gated at all. Seeding produces a spare empty tab; the sweep
launches `claude --resume <id>` for a session still running on the remote and
still owned by a live pane. Two agent processes writing one transcript; STA-3498
observed five. STA-3500 files exactly this race. Failure is asymmetric: declining
to resume is user-recoverable, a duplicate resume corrupts a transcript
irreversibly.
`workspace-terminal-host-authority.ts` answers the one ownership question both
paths ask, in the three-verdict vocabulary the renderer already uses for host
terminal inventory (`HostLiveTerminalProbeVerdict`, aliased rather than restated
so the two cannot drift): `live` (a remote host owns creation here),
`unverifiable` (there is a remote host and it has not answered), `none` (local,
or the host answered and holds nothing). Seeding requires `none`; the sweep
declines on `unverifiable` without consuming its one-shot, so the agents are not
stranded for the session once the verdict lands.
Shape notes:
- An ownership question, not a client-liveness one -- that is what fixes#15556.
- Folder workspaces resolve to `none`: the snapshot replaces exactly
`DirectSshTargetScope.gitWorktreeIds`, so a folder's rows are never replaced by
the host and waiting for an answer that will never name them would leave it
terminal-less for good.
- A `conflict` sync phase is `unverifiable`, matching the pair
`use-app-session-persistence.ts` already gates uploads on.
- Explicit launch work (setup/issue commands) stays ungated -- that is a request
to create a terminal now.
- `Terminal.tsx` subscribes through a retained selector rather than reading in
the effect: the verdict flipping to `none` is what must re-run the passes, and
resolution walks the owner catalogs, so recomputing per store write would be
the STA-3363 render-path multiplier again.
The `unverifiable` verdict is BOUNDED, and must be. `remoteWorkspaceHydratedTargetIds` is add-only
in practice -- `markRemoteWorkspaceHydrated` has two production call sites, both on success paths,
and `clearRemoteWorkspaceHydrated` has NONE. Four paths return without marking: local-hydration
timeout (`remote-workspace-target-sync.ts:136-145`), a null `remoteWorkspace.get` (`:160-169`), a
falsy apply token (`:172-185`), and never connecting at all. Without a floor, any of them would
leave every git worktree on that target `unverifiable` for the rest of the app session: no initial
terminal, no sleeping-agent resume, escapable only by creating a tab by hand. That is strictly worse
than the behaviour it replaces -- on main the user got a terminal. So a sync that terminates in
`offline` or `error` without ever hydrating resolves `none`: declining to seed is meant to be a
wait, not a permanent refusal. `pulling` still declines, and a target that HAS hydrated stays `none`
even if a later sync errors.
Scope, stated because the doc comment previously overstated it: this gate is
first-hydration-per-target, not per-connection-generation. Since nothing clears the flag, a
disconnected target that hydrated once reads `none`. It does not cover mid-session reconnect or
sleep/resume.
The memo's input list is checked for COMPLETENESS, not just membership. `satisfies readonly
(keyof State)[]` only proves each listed key exists; a field added to the state and forgotten from
the list would type-check while making the memo return a stale verdict -- silent, and it looks like
"the gate did not fire". A conditional type now names the missing key at compile time. Deliberately
not `const x: Missing[] = []`, which passes regardless because an empty array literal is assignable
to every array type.
Known limitation, stated rather than hidden: the SEEDING half of this change has no measurable
end-to-end effect today, and the branch's own e2e spec says so.
`applyDirectSshRemoteWorkspaceSnapshot` calls `markRemoteWorkspaceHydrated` unconditionally AFTER
the hydrate calls -- including when they wrote nothing. So in the same tick adoption yields zero,
the verdict flips `unverifiable` -> `none`, `Terminal.tsx` re-runs the effect, and it seeds. The
gate cannot outlive the failure it guards against, because the same function that fails to adopt is
the one that lifts it.
`ssh-cold-hydration-gap-tab-seeding.spec.ts:218` is named for what it asserts -- one tab, adopted
none -- rather than for the behaviour we want. The fixme at `:293` pins the intended behaviour.
Making the seeding half effective needs hydration resolved PER WORKTREE (or a refusal to say `none`
when the completed apply's `replaceWorkspaceKeys` did not name this worktree) rather than a
per-target "some apply finished" flag. That is deliberately not in this commit.
The RESUME half is the valuable half and is unit-proven: it declines while the host is unanswered
and wakes the same session once the verdict lands, without consuming its one-shot. Preventing one
duplicate `claude --resume` on a live transcript is worth more than preventing one spare tab --
declining to resume is user-recoverable, a duplicate resume corrupts a transcript irreversibly.
Before: 7 failed | 3 passed. After: 10 passed; 103 across the seeding, resume,
authority and remote-workspace suites.
The Docker-SSH e2e lane only ran when a PR's changed specs happened to include
`ssh-startup-exec-readiness.spec.ts` or `paired-startup-exec-readiness.spec.ts`.
Editing SSH source itself did not trigger it, and pruning either spec from a
route's list would have silently retired the whole lane. Meanwhile the sharded
lanes set no `ORCA_E2E_SSH_DOCKER`, so every Docker-gated spec skipped itself
while the shard still reported green -- the exact silent-skip shape
`docs/reference/ssh-reconnect-source-recovery.md` blames for four regressions
that reached users.
Separately, the modules that actually own direct-SSH workspace and tab restore
carry no "ssh" in their names, so the `ssh-terminal-source` route never reached
them. Measured on the real script before this change:
printf '%s\n' src/renderer/src/hooks/remote-workspace-session-merge.ts \
src/main/ipc/remote-workspace-snapshot-normalization.ts \
src/renderer/src/lib/worktree-initial-terminal-seeding.ts \
src/shared/remote-workspace-session-projection.ts \
| node config/scripts/pr-e2e-source-routing.mjs
=> []
Three changes, all pinned by the executable gate contract:
- `hasSshSourceChange` derives an `ssh_source_changed` signal from the SSH
routes themselves, plumbed pr.yml -> e2e.yml, so the lane triggers on source
rather than on a spec name surviving in a list. One list, so the two cannot
drift.
- A sibling `ssh-workspace-session-restore` route names the restore seams
(`remote-workspace-*`, `worktree-initial-terminal-seeding`,
`worktree-default-terminal-tabs`, `initial-terminal`) and routes them to the
two restore specs -- a sibling rather than more paths on `ssh-terminal-source`
so a tab-tombstone edit does not run the whole SSH terminal list.
- A new `test:e2e:ssh-docker` runner claims the remaining Docker-gated specs on
the one VM that sets the flag, and the contract now fails by name when any
Docker-gated spec is claimed by no runner. `ssh-docker-relay-perf` and
`ssh-codex-display-artifacts-repro` are recorded exemptions (wall-clock
budgets; needs a real remote codex binary) and the contract asserts each
exemption still corresponds to a real gated spec, so a stale one cannot
quietly excuse a gap. Lane timeout raised 35 -> 60 minutes for the added
serial specs.
The lane's first act was to surface four latent bugs in a spec that had been
silently skipping. `ssh-docker-bulk-open-freeze-repro.spec.ts` is four call sites
out of date against `tests/e2e/helpers/terminal.ts`: `startDockerSshRelayTarget()`
is called with no argument though the helper dereferences `testInfo.workerIndex`
(a 100% failure, not a flake), `execInTerminal` gained a `ptyId` parameter, and
`splitActiveTerminalPane` gained a direction. It was invisible because it ran
nowhere and `typecheck:e2e` is red on main with 240 pre-existing errors, so four
more could not be seen.
The `testInfo` bug is fixed here -- correct on its own, and it removes one real
error from `typecheck:e2e` (240 -> 239). The other three are not, because they
are not argument plumbing: repairing them requires choosing which ptyId to
capture and which split direction to use, and both change what the repro
measures.
The spec is therefore added to the exemption list rather than repaired, for two
independent reasons recorded in the runner: it is a perf oracle, not a
correctness one (`SOFT_FREEZE_LAG_MS=2500` / `HARD_FREEZE_LAG_MS=5000` measured
under a deliberate 5-pane flood on a 420s budget -- the same rule already applied
to `ssh-docker-relay-perf.spec.ts`), and it is known-rotted. Repair is tracked in
stablyai/orca#16764. Applying an existing written rule to a sibling that plainly
meets it is consistency; inventing a new exemption to dodge a red would not be.
Three hardening fixes to the contract itself:
- Runner text is comment-stripped before the claimed-by-a-lane scan. A substring
scan over raw text lets a spec merely *discussed* in a runner comment count as
claimed -- the silent skip this assertion exists to catch, re-entering through
the documentation. Not live today only because the existing comments write the
spec names without their `tests/e2e/` prefix.
- An exempt spec must not be invoked by any runner. `unreachableSpecs`
short-circuits the unclaimed check, so a spec could be documented as exempt
while a runner still ran it -- an exemption that reads as coverage removal but
changes nothing, leaving the lane red for a reason the file says it excluded.
This is not hypothetical: adding the bulk-open exemption without removing it
from the runner's spec list produced exactly that state, and this assertion is
what caught it.
- The Docker-gate detector is now `/ORCA_E2E_SSH_DOCKER\s*[!=]==\s*['"]1['"]/`
rather than one fixed string, so a double-quoted or `!==` spelling can no
longer escape the contract.
`ssh-restart-tab-accumulation.spec.ts` is a new three-cycle restart fence
asserting tab-id set identity, not just the active pane's reclaimed ptyId as
`ssh-cold-activation-restore.spec.ts:241` did. It passes today; it was validated
by a negative control that injected one tab after cycle 1 and correctly failed.
* Speed up PR CI with per-job path skips and native caches
Skip git-compat, xterm, packaging, and shell jobs when their inputs are
unchanged, reuse the composite install action (including Windows node-pty
cache), skip compiling the Windows CLI launcher on a cache hit, and cut the
test matrix from 16x2 to 8x2 shards without dropping coverage.
* Widen PR job skip prefixes for orcad browser and live shells
Chrome session/tab modules and zsh/fish wrapper templates are inputs to
required jobs the classifier previously skipped. Include that implementation
graph so those jobs still run when the files they load change.
* Fix CI cache safety and required gates
* Build scriptless Windows addons explicitly
* Preserve node-pty Windows support prebuild
* Remove duplicated Windows launcher unit lane
* Suppress default quit on window-all-closed in DNS probe
Destroying the probe window awaits stopLogging, which yields to the event
loop long enough for the default window-all-closed exit (non-macOS) to
trigger before the result can be written. Preventing this default behavior
allows the result to complete and exit cleanly.
* Preserve Japanese Skills UI labels; fix test flakiness and deps
- Add skipKeyPrefixes filter to Japanese phrase fixes to prevent automatic
translation of UI labels (e.g., keep エージェント in Skills components)
- Wrap timing-dependent tests in vi.waitFor to eliminate race conditions during
reconciliation and scheduler boundary ticks
- Complete useEffect dependency arrays to resolve React hook warnings
* Fix updater startup scheduling test flakiness
Set last update check to 23h ago instead of null to make timing deterministic. The startup check arms its own 24h timer; by pre-setting the last check time, only the result handler's re-arm can produce the expected check 24h later, eliminating race conditions.
Merge Sim
Brennan Benson
Neil
OrcaWin
Merge Sim
Junhyeok Chae
Jinwoo Hong
Jinjing