You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/skills/fieldworks-installer-diagnostics/SKILL.md
+10Lines changed: 10 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -28,6 +28,16 @@ This skill is evidence-first. Installer problems are often ambiguous until Burn
28
28
5. If the UI exits silently, capture Event Viewer entries and crash dumps.
29
29
6. Summarize the first failing layer: Burn bootstrapper, chained package/MSI, custom action, Windows Installer engine, or environment.
30
30
31
+
## WinApp MCP Runtime Evidence
32
+
33
+
When the WinApp MCP server is available, use it to make UI diagnostics repeatable:
34
+
35
+
- Launch or attach to installer windows and wait for input idle before diagnosing UI state.
36
+
- If the app snapshot is empty, list visible desktop windows and use `get_focused_element` plus keyboard navigation to identify and exercise controls.
37
+
- Record the observed focus path and control names in the evidence notes, especially for silent/blank UI, MSI handoff, uninstall prompts, and ARP uninstall hangs.
38
+
- For safe UI-only smoke tests, stop after proving the license checkbox/Install/Cancel path; do not proceed into install unless the scenario requires machine changes.
39
+
- For hangs, combine WinApp focused-element/window evidence with bundle/MSI logs, before/after snapshots, Event Viewer entries, and process lists.
Copy file name to clipboardExpand all lines: .github/skills/fieldworks-wix6-migration-coordinator/SKILL.md
+9Lines changed: 9 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -39,6 +39,15 @@ Use this as the routing and guardrail skill for FieldWorks installer migration w
39
39
4. Make the smallest change that addresses the root cause.
40
40
5. Validate with the relevant build/test/evidence checklist, or clearly report why validation could not be run.
41
41
42
+
## WinApp MCP UI Automation
43
+
44
+
When the WinApp MCP server is installed, prefer it for Windows installer UI proof before falling back to raw screenshots or manual notes.
45
+
46
+
- Use WinApp app/window tools to launch or attach to `FieldWorksBundle.exe`, `FieldWorksOfflineBundle.exe`, or `msiexec.exe` and collect UI snapshots where available.
47
+
- WixStdBA may expose little or no UI Automation tree at the launcher PID. If the app snapshot is empty, inspect visible desktop windows, use the focused element, and drive the UI with keyboard navigation (`Tab`, `Shift+Tab`, `Space`, `Return`, `Esc`) or coordinates.
48
+
- For safe click-through smoke tests, prove focus and interaction by toggling the license checkbox, reaching the Install button, then canceling and confirming exit. Do not click Install unless the task explicitly calls for an install/upgrade/uninstall run on that machine.
49
+
- Always pair WinApp UI evidence with bundle/MSI logs in `Output/InstallerEvidence/<RunId>/` or the VM evidence folder.
Copy file name to clipboardExpand all lines: .github/skills/fieldworks-wix6-ui/SKILL.md
+15-1Lines changed: 15 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,7 +18,7 @@ This skill keeps FieldWorks installer UI work grounded in the actual Burn + MSI
18
18
2. Inspect `FLExInstaller/wix6/Shared/Base/Bundle.wxs`, `OfflineBundle.wxs`, `BundleTheme.xml`, `BundleTheme.wxl`, and `FieldWorks.Bundle.wixproj` for bundle UI behavior.
19
19
3. Inspect `Framework.wxs`, `WixUI_DialogFlow.wxs`, `GIInstallDirDlg.wxs`, and `GICustomizeDlg.wxs` for MSI UI behavior.
20
20
4. If custom actions affect UI, inspect `Shared/CustomActions/CustomActions/CustomAction.cs` and the custom action IDs in `Framework.wxs`.
21
-
5. Gather screenshots/logs before changing visual or sequencing behavior.
21
+
5. Gather screenshots/logs before changing visual or sequencing behavior. If WinApp MCP is available, use it to drive the visible installer UI and record the controls/states observed.
22
22
23
23
## Mental Model
24
24
@@ -55,9 +55,23 @@ This skill keeps FieldWorks installer UI work grounded in the actual Burn + MSI
55
55
4. Preserve localization: put translatable strings in existing `.wxl`/`.resx` patterns, not hardcoded source where localization is expected.
56
56
5. Validate full, passive, and quiet modes when changing `DisplayInternalUICondition` or dialog sequencing.
57
57
58
+
## WinApp MCP Click-Through Workflow
59
+
60
+
Use WinApp MCP for bundle/MSI UI smoke tests whenever the server is available.
61
+
62
+
1. Launch the bundle with an explicit log path, for example `FieldWorksBundle.exe /log Output\InstallerEvidence\<RunId>\bundle.log`.
63
+
2. Wait for input idle, then request a UI snapshot. If the app-root snapshot has no accessible elements, list desktop windows and use the focused element/keyboard navigation.
64
+
3. Safe bundle smoke test: focus Cancel, Tab/Shift+Tab through `license terms`, `I agree to the license terms.`, `Install`, and `Cancel`; press Space on the license checkbox; verify focus can reach `Install`; then Cancel and confirm exit.
65
+
4. For install-intent tests, click `Install` only when the machine/VM is prepared for an install run and evidence collection is in place.
66
+
5. If the MSI internal UI opens, attach to or inspect the visible `msiexec` window and capture the Destination Folders and feature-selection screens.
67
+
68
+
Known behavior: the Burn launcher PID may not own the visible WixStdBA window after startup. If `get_snapshot` returns no accessible elements, use desktop window discovery, `get_focused_element`, keyboard commands, or coordinate clicks rather than concluding the UI is untestable.
69
+
58
70
## Evidence Checklist
59
71
60
72
- Bundle command and UI level used.
73
+
- WinApp MCP app/window IDs or visible window title/PID used for automation.
74
+
- Focus/click path used to reach key controls when UI Automation does not expose a full element tree.
61
75
- Screenshot of bundle welcome/license screen.
62
76
- Screenshot of MSI destination folders dialog.
63
77
- Screenshot of feature selection dialog if touched.
Copy file name to clipboardExpand all lines: .github/skills/fieldworks-wix6-upgrade-patching/SKILL.md
+9Lines changed: 9 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -61,6 +61,15 @@ When Programs and Features shows duplicate or strange FieldWorks entries:
61
61
4. Use Windows Installer product inventory and registry snapshots to identify which product/package registered each ARP row.
62
62
5. Verify uninstall from ARP does not hang and removes the expected entry only.
63
63
64
+
## WinApp MCP For Upgrade/Uninstall Runs
65
+
66
+
Use WinApp MCP to observe and drive UI during upgrade, repair, and uninstall evidence runs:
67
+
68
+
- Attach to the visible bundle/MSI/ARP window and capture the title, PID, focused element, and any prompt text before clicking.
69
+
- For ARP uninstall hangs, use WinApp to identify whether focus is on a hidden prompt, MSI dialog, bundle confirmation, or UAC-adjacent window before changing authoring.
70
+
- During WiX 3 to WiX 6 upgrade tests, use WinApp screenshots/focus traces for the bundle welcome/license page, MSI destination folders page, feature tree, progress, completion, and any maintenance prompt.
71
+
- Do not use WinApp to bypass prompts silently. The point is to document and reproduce the user-visible path while bundle/MSI logs and snapshots capture the underlying state.
72
+
64
73
## MSP Patch Gate
65
74
66
75
Before creating a WiX 6 MSP path, classify the change:
0 commit comments