User indicated they want tier 1 to investigate ('something feels
architecturally wrong'). Investigation summary:
ROOT CAUSE: imgui.set_window_focus('Response') called on the same
frame as the response render, when _trigger_blink is set by
_handle_ai_response. The native call exhausts the main thread's
1.94MB stack.
VERIFIED: disabling _trigger_blink and _autofocus_response_tab makes
the test PASS. The process survives, the response event arrives with
correct error text.
HISTORY CHECK (git log -S):
- _trigger_blink: pre-existing since March 2026 (c88330cc feat(hot-
reload) Exhaustive region grouping for module-level render funcs)
- _autofocus_response_tab: pre-existing since March 6 2026 (0e9f84f0
'fixing')
- set_window_focus in render_response_panel: pre-existing since
96a013c3 'fixes and possible wip gui_2/theme_2 for multi-viewport'
- response event flow: pre-existing since 68861c07 feat(mma):
Decouple UI from API calls using UserRequestEvent and AsyncEventQueue
- FR1 (send_result error routing): commit 24ba2499 (Jun 15 2026) in
public_api_migration_and_ui_polish_20260615 track
The jank is OLDER than the user thinks. The most likely explanation:
the test was never run as part of the regular tier-3 batch, so the
crash was masked by the Isolated-Pass Verification Fallacy.
QUESTIONS FOR TIER 1:
1. Is _trigger_blink a sound design?
2. Should imgui focus changes be deferred to next frame's idle phase?
3. Is there a general principle that no native imgui call should be
made during the same frame as a draw call?
PROPOSED MINIMAL FIX: defer set_window_focus to next frame's idle
phase via a _pending_focus_response flag handled in
_process_pending_gui_tasks (which runs before the render).
ed
4b5d5caa8b