From aeb89cc4143e08145061e3913218c3cf909b5002 Mon Sep 17 00:00:00 2001 From: Colin Neilens Date: Tue, 22 Sep 2026 17:41:57 -0700 Subject: [PATCH] Correct overclaimed Show in Graph parity evidence Row 112 was marked Validated and cited a "return-to-graph-card walkthrough" passing in the live gate. No such walkthrough exists: uia-live-gate.ps1 contains no graph-card assertion at all, and the workspace-show-graph element is only ever discovered and checked for non-null presence (:1156 discovery, :1188 Require). It is never retrieved via InvokePattern and never invoked, so the "stable invokable" claim is also unproven. Restate the row as Partial, describe exactly what the gate does prove (presence in the real shell build), and name the missing evidence. Signed-off-by: Colin Neilens Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --- investigation/ui-parity-matrix.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/investigation/ui-parity-matrix.md b/investigation/ui-parity-matrix.md index 3b2f6fa2..04c0d141 100644 --- a/investigation/ui-parity-matrix.md +++ b/investigation/ui-parity-matrix.md @@ -109,7 +109,7 @@ Statuses: | Pane headers | agent/shell identity, backend/shell detail, focused state | Product-owned pane headers distinguish agent and shell panes, label the zmx session detail, add truthful backend: agent/backend: shell detail, and retain the explicit focused-pane accent. Focused rendering unit coverage plus the live `windows-shell` CI run (real workspace/terminal panes, run https://github.com/scgopi/GraphCode/actions/runs/35415967793) provide the side-by-side live evidence that was previously blocked | Validated | | Mounted background tabs | Switching preserves live terminal surfaces | Workspace implementation tests still cover the topology, and the live UIA gate now creates a second mounted tab, switches between the original and background tab, and asserts both tab automation identities survive the round trip without shell exit/reconnection | Partial | | Right loop panel | Minimap, upstream/downstream, fired conditions, metric sparkline, branch/start/usage footer | The full workspace right rail includes the selected-loop map, upstream/downstream cards, fired-edge coloring, edge conditions, branch/worktree identity, metric/goal detail, model tier, a metric-history sparkline from decoded samples, start-time/usage/backend footer text, a collapse/expand control that no longer reserves rail width while hidden, and dedicated UIA children for sparkline/start/usage/toggle (`workspace-detail-sparkline-*`, start, usage, and toggle automation IDs). The live UIA gate asserts those children and toggles collapse/expand, and that gate passed on `windows-shell` (run https://github.com/scgopi/GraphCode/actions/runs/35638849754, merged as PR #399) | Validated | -| Show in Graph | Visible loop-bar and menu action | The restored Loop menu and native loop bar expose Show in Graph; the workspace UIA tree exposes a stable invokable Show in Graph child, and focused hit testing covers the visible action. The live gate's `workspace-show-graph-*` assertion and the return-to-graph-card walkthrough now run against the real shell build and pass on `windows-shell` (run https://github.com/scgopi/GraphCode/actions/runs/35415967793) | Validated | +| Show in Graph | Visible loop-bar and menu action | The restored Loop menu and native loop bar expose Show in Graph, and focused hit testing covers the visible action. The live gate asserts that a `workspace-show-graph-*` child named `Show in Graph` is present in the real shell build's workspace chrome (`uia-live-gate.ps1:1156` discovery, `:1188` `Require`), and that assertion passes on `windows-shell`. **Presence is all that is proven.** The gate never retrieves an `InvokePattern` for this element and never invokes it, so "invokable" is not established; there is also no return-to-graph-card walkthrough in the gate (no `graph-card` assertion exists anywhere in `uia-live-gate.ps1`), and the earlier claim of one was inaccurate. Invoking Show in Graph and observing the resulting navigation back to the graph still needs live evidence | Partial | **Live-gate infrastructure fix (this session):** the `windows-shell` CI job's `uia-live-gate.ps1` step was, until now, never actually exercising any of the workspace chrome above: `App.init()` unconditionally skipped `Workspace.init()` under `GRAPHCODE_UIA_GATE=1` regardless of whether a real `zmx` executable was supplied (a pre-existing guard predating this workstream), so every "Partial" row above had never been run against a real workspace at all. Fixed in `App.zig` to build the real workspace under the gate whenever `GRAPHCODE_ZMX` is present. That surfaced a second, genuine regression: the newly-real terminal surface competed for native Win32 keyboard focus with the rest of the UI after navigating away from the workspace (`App.openGlobalOverview()` and friends). Root-caused to `Workspace.poll()` (driven by the main window's 100ms `WM_TIMER`) unconditionally draining terminal output and calling `winghostty_surface_notify_accessibility_text()` regardless of workspace visibility, which kept re-asserting UI Automation focus on the terminal no matter what Win32-level focus fixes were made. Fixed by adding `Workspace.collapse()`/`Workspace.collapsed`, skipping `resize()`/`syncTopology()`'s pane refocus and terminal-output polling entirely while the workspace is hidden, plus a `WM_ACTIVATE` handler that reasserts the app's own focus policy after `DefWindowProc`'s default child-focus restoration on window reactivation. All of this is now covered by the passing `windows-shell` CI job (commits `a31813b`..`cba010f`, run https://github.com/scgopi/GraphCode/actions/runs/35415967793). Note: the separate `windows-spikes`/`windows-hardening` jobs (`validate.ps1 -Task all`) run the identical gate script but under much heavier CI load and still intermittently hit this same assertion's 15-second retry window; this has been confirmed as pre-existing, cross-branch flakiness unrelated to this workstream (an unrelated sibling branch, `coneilen-microsoft-repository-settings-parity`, shows both a pass and an unrelated failure on the same job across consecutive runs), not a regression introduced here.