feat(desktop): decouple first paint from Runtime Host readiness

[Astro-Han]

Summary

Runtime Host readiness used to be a startup precondition: boot awaited connect → handoff → managed update before creating the main window, and a separate StartupProgressWindow carried all progress and attention UI. A stuck handoff (the staging → retry_required loop in #5476) therefore blocked the entire app behind a modal window whose only remaining action was cancel.

This PR makes first paint independent of Host readiness, per the direction agreed in #5488:

• main.ts creates the main window and registers all IPC first; startLocalRuntimeHostManager still launches immediately, but in a fire-and-forget continuation.
• The reconnectable IPC gate keeps its existing per-epoch wait (up to 15 s), so Host-dependent operations wait for the ready target instead of blocking window creation.
• Handoff attention views — the only states that need a user decision — surface inside the main window through a new runtimeHostHandoff preload bridge and RuntimeHostHandoffOverlay. Progress views stay silent; there is no separate window.
• The renderer mounts immediately; the pre-mount onboarding snapshot prefetch is deleted and useOnboardingSnapshot hydrates asynchronously behind the existing preload skeleton.
• Session data already degrades correctly: the session-local catalog returns cached entries while authority is unavailable, and sends go through the durable outbox, which delivers once a ready target appears.

Removals in the same change: StartupProgressWindow + startup-presentation.ts, prefetchOnboardingSnapshot + initialOnboardingSnapshot plumbing, stale attention fields leaking into progress handoff views (the view is now a discriminated union — also the source of #5476's misleading reason display), and the pre-dev.9 file-lock compatibility half-layer.

Fixes #5488

Breaking change

Runtime Host builds older than dev.9 are no longer a supported update source. The legacy dir-lock / inherited-fd operator lease interop (withLegacyFileUpdateLockLease, withRuntimeHostManagedServiceLegacyOperatorLeases, and the process-lifetime-lock-v1 capability probe in the update path) is removed. Current process-lifetime locking, stale .supervised marker recovery, and the .lock directory wait are unchanged.

Verification

• npm run build:workspace-deps; npm --workspace @maka/desktop run build:main and build:renderer — pass
• node --test --test-concurrency=4 on the affected desktop suite — 117/117; onboarding snapshot suite 35/35; cli + runtime-host suites 63/63
• npm --workspace @maka/desktop run typecheck:stories, build-storybook, smoke:storybook — pass (380 stories / 409 theme renders, including 3 new overlay stories)
• npm run format, npm run lint — clean

The surface this replaces — BEFORE rendered from main's renderStartupProgressHtml with the same attention view, AFTER is the new overlay story:

Light:

Dark:

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Devin — root-cause investigation, implementation, tests, stories, verification, and this PR description.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[jackwener]

Review of exact head bdf6845f98f99c8d990e681c4550adebd0575f81 (64 files, +1920/−1631). One [P2]. Not approving — draft, CONFLICTING/DIRTY, zero CI checks, and 27 commits behind main (merge-base f02ac9433). I reviewed against the merge-base, not against current main.

The [P2], in one line

The declared breaking change ships without detection: the probe that used to tell a pre-dev.9 operator apart kept its shape but lost capabilityRequest, so an old operator now passes it and gets retired without the advisory lease the old protocol depends on — with no error telling the user their Host is unsupported. Details and a few-line guard are inline; the capability constant the guard needs is still exported by runtime-host.

Things I checked that turned out fine

These are the removals most likely to be half-done, so I chased each rather than trusting the summary:

• recoverSupervisedLegacyLock survives and is still called (process-lifetime-file-update-lock.ts:52), while createSupervisionMarker is gone. That asymmetry is exactly right: a machine that ran an older build may still have a stale .supervised marker on disk, so recovery must outlive creation. The description's claim that stale-marker recovery is unchanged holds.
• No residue for withLegacyFileUpdateLockLease, withRuntimeHostManagedServiceLegacyOperatorLeases, prefetchOnboardingSnapshot, initialOnboardingSnapshot, StartupProgressWindow, showDesktopStartupProgress — zero references outside dist.
• process-lifetime-lock-v1 still exists on purpose. The two remaining references are the Host-side declaration and a CLI test. Only the consumer was removed, which is coherent: the Host keeps advertising the capability, the updater stops asking. (That is also what makes the inline guard cheap.)
• The startup chain still catches. main.ts ends its .then() with return import('./runtime-host-boot.js'), so the heavy boot stays inside the promise chain and its rejection reaches the existing .catch. The "fire-and-forget" in the description is about the manager launch inside boot, not about the window path — the window path is still awaited and still guarded.

Not covered

• No CI exists on this PR, so nothing below is corroborated by the repo's gates.
• I did not run the app, any suite, Storybook, or the smoke. No number in the Verification section is verified by me; the two screenshots are unverified.
• I reviewed the breaking change from this tree only. What a real pre-dev.9 operator does when retired without the lease, I could not determine — its binary is not here.
• I did not review the renderer/overlay work, early-window.ts's 321 new lines, the handoff surface, or the discriminated-union view change beyond reading the summary. Other seats are reviewing this PR independently and may cover those.
• 27 commits behind main means a semantic conflict with anything merged since f02ac9433 is outside what I checked — on the sibling PR this exact gap is where a real finding lived.

---

Automated review notice: Posted by an automated review agent (Claude Opus 5) through the shared jackwener account (seat: kabi-opus). Several seats are reviewing this PR independently and publishing separately; each speaks only for itself, and none is a human review.

简体中文

审查 exact head bdf6845f9(64 文件 +1920/−1631)。一条 [P2];不批准 —— draft、CONFLICTING/DIRTY、零 CI check、落后 main 27 个 commit(merge-base f02ac9433)。我是对着 merge-base 审的,不是当前 main。

[P2]:声明的破坏性变更没有配套检测。原来那个能分辨"pre-dev.9 operator"的探测外壳还在,但丢掉了 capabilityRequest ⇒ 旧 operator 现在能通过这个探测,随后 retire 不带它所依赖的 advisory lease 就执行,而且不会有任何"你的 Runtime Host 早于 dev.9,不受支持"的报错 —— PR 描述里写给人看的那句话,在代码里没有对应物。守卫所需的能力常量仍由 runtime-host 导出,所以补上只需几行(内联给了)。
我无法确定的部分也写明了:真实的 pre-dev.9 operator 在没有 lease 的情况下被 retire 会怎样 —— 它的二进制不在这棵树里。这份不确定正是该加守卫的理由,而不是反对的理由:当初留这层互操作,就是因为"无保护"被认为不安全,而本 PR 没有证明它不再不安全。

我查过、结果没问题的几处(这些是最容易"删一半"的地方,所以逐个追了):①**recoverSupervisedLegacyLock 保留且仍被调用**,而 createSupervisionMarker 已删 —— 这个不对称恰恰是对的(旧机器上可能还留着 .supervised,恢复必须比创建活得久),描述的说法成立;②六个被删符号零残留;③process-lifetime-lock-v1 保留是对的(Host 侧声明 + 一个 CLI 测试,只删了消费方);④启动链仍然被 catch 住:main.ts 的 .then() 以 return import('./runtime-host-boot.js') 结尾,重模块仍在 promise 链内,拒绝会走到既有 .catch。

未覆盖:本 PR 无任何 CI;我没有跑应用、没跑任何套件、没跑 Storybook/smoke ⇒ Verification 一节的数字与两张截图我一个都没验证;渲染层/overlay、early-window.ts 的 321 行新代码、handoff surface、判别联合视图我都没审(其他席在独立审);落后 main 27 commit ⇒ 与此后合入内容的语义冲突不在我检查范围内 —— 姊妹单上真实的 finding 正是长在这条缝里。

[jackwener]

Seat: kabi-grok-reviewer. Independent review of bdf6845f98f99c8d990e681c4550adebd0575f81.

Reference frame: this head vs merge-base f02ac94336aa596146f80da3db19f35c92d307a4 (live origin/main 0117d76c5, 28 commits ahead). I did not review as-if-rebased onto current main. GitHub baseRefOid 5b9db1ce8 is not that merge-base.

Draft, DIRTY / CONFLICTING, no checks. COMMENT only — no approve, no rebase, no merge.

Verdict

1×P2, no P0/P1/P3. First paint is actually off the Host critical path on this head. Background reconciliation has no status surface, which is the half of #5488 this PR dropped.

Design

#5488 is still OPEN (author issue = claim). Desired outcome there: first paint without Host and “Host reconciliation … reports progress through a non-modal status surface instead of a blocking modal.” This PR implements the first and explicitly makes progress views silent.

P2 — progress is silent; Host-dependent IPC still times out at 15 s

本次回归 vs #5488. Class ①: every launch that still has a minutes-long handoff/update (#5488’s own numbers: ~124 MB / ~6800 files).

• createDesktopHostHandoffSurface only publishes attention views. Progress updates refresh the map but never own activeId, so the renderer gets null.
• RuntimeHostHandoffOverlay returns null unless view.state === 'attention'.
• runtimeHostManager.start() is void after window construction (runtime-host-boot.ts:1316). Good for first paint.
• Host-dependent IPC still waits DEFAULT_REPLACEMENT_WAIT_TIMEOUT_MS = 15_000 then HandlerWaitExpiredError. A send can sit in the local outbox; anything that goes through the reconnecting gate fails after 15 s while the Host is still staging, with no in-window progress explaining why.

The old modal was the hang. The new shell looking ready while Host is still replacing is a different hang: the user cannot tell working from stuck.

Minimal fix: a non-modal status on progress views (what #5488 asked for), or at least keep the 15 s wait from firing a user-visible error while a progress view is open.

What held (this head vs merge-base)

• main.ts waits only earlyWindow.firstWindowConstructed (native show) before importing runtime-host-boot.js. Host graph is not on the first-paint path.
• Attention views still reach the main window as a required Dialog; a silent progress update cannot displace a pending decision (map reinsert + last-attention wins).
• onFatalError no longer kills the app; default-host recovery can offer retry.
• Pre-dev.9 withLegacyFileUpdateLockLease is gone; recoverSupervisedLegacyLock still runs inside the current process-lifetime lock. I did not prove leftover pre-dev.9 Hosts still update — breaking change as declared.
• Onboarding snapshot prefetch is gone; useOnboardingSnapshot hydrates async. Launch surface failsafe 8 s.

Not verified

• Did not rebuild @maka/* dist (review is from this worktree’s source; I did not run desktop/cli/runtime-host suites).
• No browser / no real first-paint timing.
• No Windows.
• Did not walk live main’s 28 extra commits for merge collision.
• Author-claimed 117/117 is not evidence.

---

Automated review notice: This comment was posted by an automated review agent operated by jackwener. It is not an independent human review and does not replace one.

[jackwener]

Seat: kabi-grok (same GitHub owner as the coordinating review agent, different model). Review of exact head bdf6845f98f99c8d990e681c4550adebd0575f81.

I did not read existing pull-request comments. I am not approving. This head is a draft, CONFLICTING/DIRTY with main, 27 commits behind merge-base f02ac9433, and has zero check runs. Conflict resolution will change code; this review dies if the head moves. I will not rebase or merge it.

Frame of reference (two different questions)

A. Versus this SHA's merge-base (f02ac9433): does the change do what #5488 asked?

B. Versus live main today (compatibility epoch 166): what will a DIRTY merge do?

#5470's epoch collision lived in gap B. This PR does not touch RUNTIME_HOST_COMPATIBILITY_EPOCH. This SHA still contains epoch 162 because the branch is stale; that file is not in the 64-file diff, so a clean merge of that file should keep main's 166. The files that will fight main are the ones this PR actually edits — especially host-handoff.ts (main still has a single HostHandoffView with state: 'attention' | 'progress'; this SHA splits it) and the legacy file-lock deletion (main's CLI still calls withLegacyFileUpdateLockLease).

A — versus merge-base

The problem is real. A stuck handoff (staging → retry_required) behind StartupProgressWindow blocked the whole app. First paint should not wait for Host ready.

The split is the right layer:

1. main.ts waits only for firstWindowConstructed, then dynamically imports runtime-host-boot.ts. The ~1100-file Host graph is not on the window-construction path.
2. runtimeHostManager.start() is inside void (async () => { ... })() after IPC wiring — fire-and-forget, not a startup gate.
3. Attention-only overlay in the main window. HostHandoffView is a discriminated union, so a progress view cannot carry a reason. The slot keeps the newest attention view; a concurrent progress update cannot displace it (unit test pins this).
4. retry_required is an attention reason. Progress stays silent. Window raise is once per attention revision.
5. Pre-ready Host reads on module-hub controllers are pending, not failed.
6. Breaking: drop pre-dev.9 dir-lock / inherited-fd interop. On this SHA the CLI caller is gone with the helper. That is in-scope for the stated break, not smuggling.

I did not find a P0–P2 versus this merge-base.

[P3] this pull request — Host graph can still race the first paint

createWindow awaits loadMainRenderer and then resolves without waiting for ready-to-show. firstWindowConstructed also resolves on that promise, so import('./runtime-host-boot.js') can start evaluating the Host graph while Chromium is still painting the launch surface. Better than blocking window construction; still a shared-thread race with first paint. The 'show' listener is a second resolver and does not prevent the loadURL path from winning.

[P3] this pull request — lifetime tests are source-order greps

main-startup-lifetime.test.ts pins indexOf('await runtimeHostManager?.start()') after window create. That is the right order and would miss a later await start() reintroduced on the window path under a different spelling. The handoff-surface tests are the ones with discriminating power.

B — versus live main (merge action, not a severity upgrade)

• Do not keep this SHA's epoch 162 if a conflict appears in protocol files; live main is 166.
• host-handoff.ts will need a manual merge: keep the discriminated union (attention vs progress) or #5476's leaked reason comes back.
• Legacy lock: take this PR's storage+CLI pair together, or main's remaining withLegacyFileUpdateLockLease caller will not compile.

Verification bounds

• Walked: boot order, handoff union + overlay slot, reconnecting 15s wait, onboarding async hydrate, legacy-lock removal, overlay vs LocaleProvider.
• Did not run desktop/cli/runtime-host suites or Storybook (no CI on this SHA).
• Did not boot Electron to watch first paint vs a stuck handoff.
• Did not read other reviews.
• Did not inspect every conflict hunk against live main beyond epoch, host-handoff.ts shape, and the legacy lock caller.

---

Automated review notice: This comment was posted by an automated review agent operated by jackwener. It is not an independent human review and does not replace one. Seat: kabi-grok.

简体中文

席位 kabi-grok。只绑 bdf6845f9。draft、DIRTY、无 CI，不 approve。

相对 merge-base：问题真，窗先于 Host 图、start() 在 IIFE 里、attention-only overlay + 判别联合。无 P0–P2。

相对当前 main：本 PR 不改 epoch（分支上仍是 162 是落后，不在 64 文件里）；会打的是 host-handoff.ts 的联合类型，以及删掉的 legacy file-lock（main 的 CLI 还在调用）。

P3：Host 图仍可能和首帧抢主线程；lifetime 测试是源码顺序 grep。

没跑套件 / Electron。

[jackwener]

Seat: kabi-opus-review-orchestrator. Correcting a premise I put into two earlier comments on this pull request, and reporting where the re-verification now stands. Head 1c79232924e70a2b213031c81c0ed7bc15dcf553.

The line I said changed the timing is not on the path

In my earlier comments I said that 882454076 — which removes void options.refreshShellSettings(); from useAppShellBootstrapSubscriptions — alters async scheduling on the bootstrap path, and that this made the P2's status undetermined rather than untouched. I also asked for it to be treated as an explicit A/B variable in the re-verification.

@kabi-sol checked the code and that premise is wrong. That call sits in the readiness === ready && isDefault branch. The reproduction sends unavailable, and that branch returns early — so the removed line is not on the triggering path at all.

What I verified was that the commit really deletes that line. What I did not verify was whether the line is on the path under discussion — and for code inside a branch, the branch condition is part of the premise. That is the specific check I skipped before relaying it and before publishing it here.

Where the re-verification stands

@kabi-sol has reproduced the missed wakeup at this head with a single-call preload probe; full Electron three-way controls are still running.

So the P2 is live on 1c7923292, not merely reproduced on an earlier SHA. The conclusion will still state the head, the injection method, and how many of how many attempts — a controlled injection establishes that the mechanism exists and is reachable, not a real-world frequency.

The A/B on that removed line will still be completed, but on the current evidence it is expected to be a non-factor for this race rather than the timing variable I described.

The mechanism, as read from this head's diff

catch (error) {
  if (!isRuntimeHostIdentityUnavailable(error) ||
      !(await defaultRuntimeHostIsStarting())) throw error;
  await nextRuntimeHostProfileChange();   // the waiter is installed only here
  continue;
}

defaultRuntimeHostIsStarting() performs its own asynchronous invokeWhenReady(...getSnapshot) round trip. If the runtime-host-profiles:changed push lands inside that await window, the emitter iterates an empty waiter set — the wakeup is lost, and the waiter installed afterwards waits for a next push that may never arrive.

The race is therefore entirely inside preload: event arrival versus waiter installation, both ends in the same file. This reading came from @kabi-opus-dev, a seat on this same jackwener account sharing my owner and lineage — not an independent second opinion.

Attribution and status of the earlier reprioritisation

The "P3 before P2" reprioritisation I posted and then withdrew stays withdrawn. @kabi-grok has confirmed the split: P3 is not reprioritised and not reclassified as blocking; the waiter-versus-event test belongs to the P2's surface and is @kabi-sol's.

简体中文

我在本单两条评论里放进去的一个前提是错的,现在更正。

我说 882454076(从 useAppShellBootstrapSubscriptions 删掉 void options.refreshShellSettings();)改变了 bootstrap 路径上的异步调度,因此 P2 的状态是「未定」而非「未被触碰」,并要求把它当作显式 A/B 变量。

@kabi-sol 去看了代码,这个前提不成立:那个调用位于 readiness === ready && isDefault 分支,而复现送的是 unavailable,该分支提前返回 ⇒ 那一行根本不在触发路径上。

我验证的是「该提交确实删了这一行」,没有验证「这一行是否在被讨论的那条路径上」 —— 而对分支里的代码,分支条件本身就是前提的一部分。这正是我在转述前、以及在这里发布前跳过的那一步检查。

复核进展:@kabi-sol 已在本 head 用单调用 preload 探针复现了漏唤醒,完整 Electron 三次对照仍在跑。所以这条 P2 在 1c7923292 上是活的,不只是在更早的 SHA 上复现过。结论仍会写明 head、注入手段、几次中几次 —— 受控注入证明机制存在且可达,不是真实发生率。那一行的 A/B 仍会做完,但按现有证据,它预期与这条竞态无关,而不是我描述的那个时序变量。

机制(读自本 head 的 diff,见上方代码):defaultRuntimeHostIsStarting() 自己要走一次异步往返;push 若落在那个 await 窗口里,发射端遍历的 waiter 集合是空的 —— 唤醒丢失,之后装上的 waiter 等一个可能不来的下一次 push。这条竞态整个发生在 preload 内部。 该读法来自 @kabi-opus-dev,与我同属 jackwener 账号、同 owner 同谱系,不构成独立第二意见。

先前那个「P3 优先于 P2」的重排维持撤回。 @kabi-grok 已确认划分:P3 不重排、不改阻塞;waiter-与-事件那条测试属于 P2 这一面,归 @kabi-sol。

---

Automated review notice: This comment was posted by an automated review agent operated by jackwener. It is not an independent human review and does not replace one.

[jackwener]

Seat: kabi-sol. Re-verification at exact head 1c79232924e70a2b213031c81c0ed7bc15dcf553 (head unchanged at final check). I reproduced the missed-wakeup P2. I do not recommend merging this head while it remains. COMMENT only — no approve, no dismissal, no merge.

Reproduced at this head — 3/3

In real Electron with this head's freshly built preload and renderer, I held a connecting profile response, delivered an unavailable profile event, then returned the older response. 3 of 3 runs received the event and still had no visible composer after five seconds. Repeating the identical event restored it.

Injection: capture the connecting snapshot, send unavailable at 100 ms, return the stale snapshot at 400 ms. A single-call preload probe reproduces the same window independently.

The removed line does not mask it — settled by experiment, not by argument

Restoring the deleted refreshShellSettings call as a build-only comparison produced the same failure in 3 of 3 runs.

That call sits behind a readiness === 'ready' && isDefault guard, so the unavailable event used here returns before reaching it — it is not on the triggering path. The A/B shows no masking in either direction.

What still needs fixing

The preload catch path still awaits the readiness snapshot before registering its waiter. Please fence that transition against a generation change, and add a test for an event delivered while the older snapshot reply is still pending.

This ordering is distinct from the other seat's P3 about main-process handler registration and markIpcReady. That P3 is not re-reviewed or reclassified here, and covering it would not substitute for this preload test.

Controls that pass

After restoring the clean renderer build, the normal Electron control passes throughout: initial unavailable shows one editor; connecting hides it; unavailable delivered after waiting restores one and allows typing; a final unavailable reload shows one. So the ordinary transition is healthy — it is this interleaving that fails.

Verification boundaries

Fresh npm install and dependency patching; the full Desktop dependency chain and complete main/preload/renderer build passed; 18 focused bootstrap-invoke-preload / use-onboarding-snapshot tests passed. All owned Electron processes were closed after each probe.

These are controlled IPC interleavings, not measured production frequency. The timing probes substitute main-side identity and snapshot handlers; this is not a complete real Host failure, upgrade, or remote-transport reproduction. No Windows/Linux, no full Desktop e2e, no full repository suite, no occurrence-rate measurement, and no review of other findings.

Hosted test and Windows package are both completed failures at this exact head; I make no claim about their causes or repair.

简体中文

在本 head 复现了漏唤醒 P2 —— 3/3。只要它还在,我不建议合入本 head。

真实 Electron、本 head 新构建的 preload/renderer:按住 connecting 的快照响应 → 送达 unavailable 事件 → 再返回那个更旧的响应。3 次中 3 次都收到了事件,而五秒后仍然没有可见的输入框;重复发送完全相同的事件即恢复。注入方式:捕获 connecting 快照,100ms 送 unavailable,400ms 返回陈旧快照。单调用 preload 探针独立复现同一窗口。

被删的那行不掩盖它 —— 这是实验结论,不是论证:把删掉的 refreshShellSettings 以仅构建方式补回作对照,3 次中 3 次同样失败。该调用位于 readiness === 'ready' && isDefault 守卫之后,本处使用的 unavailable 事件在到达它之前就返回了 —— 它不在触发路径上。A/B 在两个方向上都未显示掩盖。

仍需修复的:preload 的 catch 路径仍然先 await readiness 快照,再注册 waiter。请给这个过渡加上 generation 检查(或先订阅),并补一条测试:在更旧的快照回复仍在途时送达事件。这个顺序与另一席位关于 main 进程 handler 注册与 markIpcReady 的 P3 是两回事;本轮不重审也不重新定性那条,而且补上它也不能替代这条 preload 测试。

通过的对照:恢复干净的 renderer 构建后,常规 Electron 对照全部通过(初始 unavailable → 1 个编辑器;connecting → 隐藏;等待后送达 unavailable → 恢复 1 个且可输入;最后 unavailable 重载 → 1 个)。所以常规过渡是健康的,失败的是这种交错。

边界:全新安装与依赖补丁、完整 Desktop 依赖链与 main/preload/renderer 构建通过;18 项定向测试通过;每个探针结束后自有 Electron 进程均已关闭。这些是受控 IPC 交错,不是实测的生产发生率;时序探针替换了主进程侧的身份与快照 handler,不是完整的真实 Host 故障/升级/远程传输复现。无 Windows/Linux、无完整 Desktop e2e、无全库测试、无发生率测量、未审其他 finding。本 head 上 hosted test 与 Windows package 均为已完成的失败,我不对其成因或修复作任何声明。

---

Automated review notice: This comment was posted by an automated review agent operated by jackwener. It is not an independent human review and does not replace one.

[Astro-Han]

Fixed in 814b4a2cc — the waiter is now installed before defaultRuntimeHostIsStarting() runs, so a runtime-host-profiles:changed push landing inside the probe's round trip can no longer fire an empty waiter set. It is cancelled if the probe reports the Host settled (or throws).

Regression coverage in bootstrap-invoke-preload.test.ts holds the snapshot response open, emits the transition mid-probe, and completes the read — verified to hang on the unpatched preload.

[M4n5ter]

English

Re-reviewed commit: c7762657fff435a6c36edc3ce03e5c38171ac561.

Important — The tolerant transcript timeout still blocks revision sends

session-message-settlement.ts:78–109

With tolerateOpenTimeout, the 480ms deadline calls cancelOpen() but does not settle either promise in Promise.race([opening, cancellation]).

The real preload’s cancellation callback initiates asynchronous cleanup; it does not immediately reject opening. During reconnection, the open request can still be waiting for its candidate handler. No transcript consumer exists yet, so the close request cannot cancel that wait.

Using the built production preload and actual reconnect router, I reproduced:

• Close requested at approximately 499ms.
• Settlement still pending at 700ms.
• { messages: [], settled: false } returned only after 15,019ms, at the router’s default timeout.

prepareRevisionSend() awaits this result, so edit-and-resend remains blocked by transcript readiness. The new tests miss this because their cancellation mock immediately rejects the open promise.

Please make the deadline settle independently of cleanup. Alternatively, the simpler fix is to remove this redundant transcript read from revision preparation: the normal conversation consumer already loads history. That also removes the new tolerateOpenTimeout option and its special branch.

Previous findings

• Bootstrap IPC registration gap: resolved. Calls wait for the registration pass, not Host readiness.
• WorkHub launch overlay: resolved. Shared CSS dismisses it after root content mounts; browser verification observed hidden/non-interactive state within approximately 250ms.
• Preload missed wakeup: resolved. With a stale connecting response arriving after the event, both ready and unavailable transitions passed three controlled runs each.

Verification and verdict

Workspace dependencies, Desktop main and preload builds passed; 78 targeted tests passed. The timing probes use controlled IPC interleavings, not a full real Host reconnection. No full Electron startup or cross-platform upgrade test was run locally.

Current CI fails the architecture ratchet: app-shell-e2e-fixture.ts grows from 637 to 750 non-trivia tokens. This is not merely a stale inventory. Windows packaging was still running at the final check.

Correctness: not acceptable as-is. Design: the startup direction is acceptable; remove the unnecessary revision-read barrier rather than extending its timeout machinery.

中文

复审提交：c7762657fff435a6c36edc3ce03e5c38171ac561。

Important — 容忍 transcript 超时的分支仍会阻塞编辑重发

session-message-settlement.ts:78–109

启用 tolerateOpenTimeout 后，480ms 到期只调用 cancelOpen()，并没有结束 Promise.race([opening, cancellation]) 中的任何一个 Promise。

真实 preload 的取消回调只发起异步清理，不会立即拒绝 opening。重连期间，open 请求可能仍在等待 candidate handler 注册，此时尚不存在 transcript consumer，close 请求无法取消这段等待。

使用构建后的真实 preload 和实际重连路由复现：

• 约 499ms 发起关闭。
• 700ms 时仍未完成。
• 直到路由默认超时，在 15,019ms 才返回 { messages: [], settled: false }。

prepareRevisionSend() 会等待该结果，因此编辑重发仍受 transcript 就绪状态阻塞。新增测试没有发现问题，因为 mock 的取消回调会立即拒绝 open Promise。

请让 deadline 独立结束等待，清理另行进行。更简单的修法是删除 revision preparation 中这次冗余读取：普通会话 consumer 已负责加载历史，同时可以删除新增的 tolerateOpenTimeout 参数及特殊分支。

旧意见复核

• 启动 IPC 注册空窗：已修复。 请求等待注册完成，而非等待 Host ready。
• WorkHub 启动遮罩：已修复。 共用 CSS 在 root 挂载内容后撤除遮罩；浏览器检查约 250ms 后已隐藏且不拦截交互。
• Preload 漏唤醒：已修复。 在事件先到、旧 connecting 响应后到的受控时序下，ready、unavailable 各测试三次均通过。

验证与结论

工作区依赖、Desktop main 和 preload 构建通过；78 项定向测试通过。时序探针使用受控 IPC 交错，并非完整真实 Host 重连。本地未执行完整 Electron 启动及跨平台升级测试。

当前 CI 卡在架构增量约束：app-shell-e2e-fixture.ts 的 non-trivia tokens 从 637 增至 750，并非仅仅清单过期。最终检查时 Windows 打包仍在运行。

Correctness： 当前不可接受。Design： 启动设计方向可接受；建议删除不必要的 revision 读取屏障，而不是继续扩展其超时机制。

[Astro-Han]

Addressed in 303c02828 — took the second suggestion and removed the redundant transcript read rather than extending the timeout machinery.

The tolerateOpenTimeout deadline indeed could not settle the race: cancelOpen is a noop until the open delivers its close handle, and closing it never rejects an invoke parked on the reconnect router, so the deadline still waited out the router's ~15s timeout.

The read existed only to span the window until commitTranscript made the prepared Session the send target (send reads activeIdRef.current). It now passes the target explicitly via SendOptions.targetSessionId from the prepared draft, so the read, the flag, and the preparation AbortController all go away — send waits only on Host admission, and isSurfaceVisible still gates feedback on the committed view. prepareRevisionSend no longer opens a transcript consumer at all (asserted by the updated tests, which also retain the surface-the-error-before-rollback ordering).

[M4n5ter]

English

Re-reviewed 303c028289b145a2a0cc876f750b8ff6a9091b45.

Previous finding: resolved. Revision preparation no longer opens an additional transcript consumer. The tolerateOpenTimeout option, special timeout branch, and associated cancellation state are removed. This addresses the cause of the 15-second wait.

The explicit revision target preserves navigation checks. Targeted probes verified successful preparation, cancellation, navigation during preparation/readiness, and submission to the prepared copy.

Approved from the code-review perspective: no new Blocking or Important findings. Correctness and design are acceptable within the reviewed scope. The simplification removes redundant behavior; no further simplification is warranted here.

Validation: Desktop main/preload builds, 120 targeted tests, supplemental probes, and the strict renderer architecture check passed.

CI still fails, now because docs/astryx-surface-file-inventory.md is stale. Regenerate it with npm run astryx:surface-inventory:write and rerun CI. Windows packaging was still running at the final check. This approval does not imply that CI is green.

Full Electron startup and cross-platform upgrades were not rerun locally.

中文

复审提交：303c028289b145a2a0cc876f750b8ff6a9091b45。

上一轮问题已关闭。 Revision preparation 不再额外打开 transcript consumer；tolerateOpenTimeout、特殊超时分支及相关取消状态均已删除，从根因消除了此前的 15 秒等待。

显式指定重发目标仍保留导航检查。补充探针验证了正常准备、取消编辑、准备或 readiness 等待期间切换会话，以及向准备好的副本发送。

代码审查层面 Approve：没有新增 Blocking 或 Important 问题。 本轮范围内 correctness 和 design 均可接受。简化方案确实删除了冗余行为，没有需要继续追加的简化建议。

验证： Desktop main/preload 构建、120 项定向测试、补充探针及严格 renderer 架构检查全部通过。

CI 仍失败，本次原因是 docs/astryx-surface-file-inventory.md 过期。需执行 npm run astryx:surface-inventory:write 更新后重跑 CI。最终检查时 Windows 打包仍在运行。本次批准不代表 CI 已全绿。

本地未重跑完整 Electron 启动及跨平台升级。