[UncertaintyDeterminesYou4ndMe]

At startup the desktop workbench is drawn in the top half of the window, above a spinner, for about half a second before it fills the window.

The root column in App.tsx holds the workbench and, after it, the preview overlays view and the settings view. Both of those render only dialogs, which are window layers, but while their plugin loads RuntimeView shows its placeholder in the column. Since #6536 that placeholder is LoadingState (flex: 1, 16px vertical padding) instead of a line of text, so it shares the height with the workbench: in a 640px window the workbench gets 304px and the spinner 336px until the settings plugin activates. This change puts both views in a zero-height container with hidden overflow. The settings dialog and the terminal settings pages still open from it.

The jump is also why desktop_recovers_an_unavailable_remembered_folder fails now and then (most recently in run 42067249582: "no single control labelled Choose another folder…"). After restarting the desktop, the test presses the workspace picker as soon as it appears. In 2 of 5 local runs the picker first appeared at y=126 and moved to y=294 about half a second later, so a press measured before the move hit empty space and the menu never opened. With this change the picker appeared at y=294 in all 15 runs. The test is left as it is.

One trade-off: if either of these two plugins fails to load, the container also clips its error and Retry button, which today show as a row at the bottom of the window. If that row should stay, the alternative is an option on renderView that drops only the loading placeholder. I kept the change in App.tsx rather than add an SDK option for one caller.

AI use

• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code diagnosed the flaky test, wrote the change and this description; the commit carries Generated-by: Claude Code.

[UncertaintyDeterminesYou4ndMe]

The two root-tests (native) failures are in maka-agent-native owner::tests::executor::external* (native_external_cancelled_instruction_ack_does_not_advance_confirmed_digest, and native_external_attachments_stop_retains_images_until_disposal_and_root_exit with a NotFound). This PR only changes App.tsx; the first test also failed on rust-preview a61a85d (run 42146620228).

[Astro-Han]

I reviewed the complete one-file change, the RuntimeView loading/error branches, and the registry's failed-load and retry handling. The loading placeholder really is an ordinary flex child (LoadingState has flex: 1 and minHeight: 48), so keeping it out of the root column addresses a concrete layout cause.

P2 — keep plugin failures and Retry reachable (products/maka/workbench/app/App.tsx:347). The new zero-height, clipped parent contains the entire settings and preview runtime views, including their failure UI. RuntimeView renders PluginError as a normal View/Text/Button subtree, not a window-layer dialog. The registry leaves a failed entry failed until retry(entry) resets it. A temporary settings module load or activation failure therefore hides both its explanation and its Retry button; reopening settings does not reset that state. The PR description acknowledges the clipping, but it also removes an existing recovery path.

I executed the actual RuntimeView and extracted App wrapper with controlled JSX/plugin adapters: both failure Retry buttons are under the zero-height/hidden parent after this change, while the previous direct-child structure leaves them exposed; the original Retry handler invokes the registry retry. This is a source/render-tree check, not native layout or a real failed Host/plugin session. Please suppress only the loading placeholder or surface failures outside the clipped container.

The change merges cleanly with rust-preview@72162299. CI 42154502528 has the inherited #6655 native7 fixture failure and a native8 attachment-retention ENOENT at external_attachments.rs:128; I read both logs and have not attributed the latter to this UI change. I did not run the native desktop, terminal settings dialogs, or the author's repeated picker-position measurements. No protocol or database migration changes.

---

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

[Astro-Han]

P2: Preserve the error and Retry UI when a view fails. RuntimeView also renders PluginError (ordinary View, error text and a Retry Button) for failed module loading/activation and render errors. This wrapper clips that recovery UI along with the spinner. The registry's load() rejects an already-failed entry, and only retry(entry) resets it; setting settingsOpened again does not recover it. I confirmed the actual failed-view render tree with controlled adapters: the Retry nodes move from normal root children to this zero-height/hidden ancestor. Hide only the loading placeholder, or give failed views a visible recovery surface.

---

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

[Astro-Han]

I reviewed the complete final ten-file diff at fd1ba37, including the expanded SDK option, both App overlay call sites, SessionSurface, runtime rendering, documentation and the new real-Host overlay test.

The earlier P2 about hiding the error and Retry control is fixed in the checked production path. The final version removes the zero-height clipping wrapper and passes { loading: false } through renderView/the registry to RuntimeView; only the idle/loading placeholder is suppressed. The failed state still renders its ordinary error and Retry button. SessionSurface also selects this option only for the overlays surface, while normal view loading retains its default behavior.

I executed the actual RuntimeView implementation and both App call-site fragments with controlled JSX/plugin adapters. Idle/loading/loaded states contained no loading placeholder; the failed state exposed both Retry controls without a clipping ancestor, and invoking the actual retry handler called the loader. An ordinary view still rendered its loading placeholder. These checks establish the relevant render branches and handler wiring; they do not measure native layout or exercise a real Host. I read the new blocked-module/activation-failure test and its real Retry interaction, but did not run that Rust test locally.

Final-head CI 42202199652 and the merged d77b0ff CI 42202273130 succeeded. The final head merges without conflicts into the fetched rust-preview 42ea54a. I found no confirmed new P0–P2 issue in this review. No protocol/database changes or independent native GUI acceptance; no approval or merge performed.

---

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