Add wix6 skills

.github/skills/fieldworks-installer-diagnostics/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: fieldworks-installer-diagnostics
+description: Use this skill for FieldWorks installer logging, diagnostics, evidence collection, and failure triage: double-click does nothing, bundle exits or hangs, uninstall hangs, ARP issues, prerequisite failures, custom action failures, MSI Return value 3, Burn detect/plan/apply analysis, Event Viewer/crash dumps, VM evidence folders, and before/after installer snapshots. Trigger for any FieldWorks installer debugging or diagnostic request.
+---
+
+# FieldWorks Installer Diagnostics
+
+This skill is evidence-first. Installer problems are often ambiguous until Burn logs, MSI logs, and machine state snapshots are collected.
+
+## Load References When Needed
+
+- Read `references/evidence-and-commands.md` for exact commands and evidence locations.
+- Read `references/log-triage.md` for Burn/MSI/custom action triage recipes.
+
+## First Moves
+
+1. Read `.github/instructions/installer.instructions.md` and `.github/instructions/debugging.instructions.md`.
+2. Read `scripts/Agent/Invoke-Installer.ps1`, `Invoke-InstallerCheck.ps1`, `Collect-InstallerSnapshot.ps1`, and `Compare-InstallerSnapshots.ps1` if changing or using diagnostics scripts.
+3. Read `specs/001-wix-v6-migration/verification-matrix.md`, `golden-install-checklist.md`, and `REMAINING_WIX6_ISSUES.md` for the expected evidence shape.
+4. Identify which artifact is under test: WiX 3 fallback/current default or WiX 6 migration path. Do not assume helper defaults point at WiX 6.
+
+## Evidence-First Workflow
+
+1. Create or choose an evidence folder. Repo convention: `Output/InstallerEvidence/<RunId>/` for agent scripts, or `C:\Temp\FwInstallerEvidence\YYYY-MM-DD\` for VM/manual runs.
+2. Capture the command, artifact path, version, SHA256 if relevant, and machine snapshot/VM state.
+3. Run the bundle or MSI with logging. For WiX 6 artifacts, pass explicit `-InstallerPath` when using helper scripts.
+4. Include temp logs when chained packages or Burn package logs may be separate.
+5. If the UI exits silently, capture Event Viewer entries and crash dumps.
+6. Summarize the first failing layer: Burn bootstrapper, chained package/MSI, custom action, Windows Installer engine, or environment.
+
+## WinApp MCP Runtime Evidence
+
+When the WinApp MCP server is available, use it to make UI diagnostics repeatable:
+
+- Launch or attach to installer windows and wait for input idle before diagnosing UI state.
+- If the app snapshot is empty, list visible desktop windows and use `get_focused_element` plus keyboard navigation to identify and exercise controls.
+- 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.
+- 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.
+- For hangs, combine WinApp focused-element/window evidence with bundle/MSI logs, before/after snapshots, Event Viewer entries, and process lists.
+- If the bundle reaches elevated MSI internal UI, a non-elevated WinApp host may be limited to observation. Treat visible-but-non-clickable MSI controls as an automation integrity boundary until proven otherwise; capture the focused element, MSI log action, screenshots, process integrity/window ownership evidence, and rerun elevated for full manual UI control.
+
+## Commands
+
+Prefer the repo helper for repeatable runs:
+
+```powershell
+./scripts/Agent/Invoke-Installer.ps1 -InstallerType Bundle -InstallerPath '.\FLExInstaller\wix6\bin\x64\Debug\FieldWorksBundle.exe' -IncludeTempLogs
+./scripts/Agent/Invoke-Installer.ps1 -InstallerType Msi -InstallerPath '.\FLExInstaller\wix6\bin\x64\Debug\en-US\FieldWorks.msi' -IncludeTempLogs
+```
+
+Use explicit manual commands when needed:
+
+```powershell
+.\FLExInstaller\wix6\bin\x64\Debug\FieldWorksBundle.exe /log C:\Temp\FwInstallerEvidence\bundle.log
+msiexec /i .\FLExInstaller\wix6\bin\x64\Debug\en-US\FieldWorks.msi /l*v C:\Temp\FwInstallerEvidence\msi-install.log
+msiexec /x {PRODUCT-CODE} /l*v C:\Temp\FwInstallerEvidence\msi-uninstall.log
+```
+
+For before/after evidence:
+
+```powershell
+./scripts/Agent/Collect-InstallerSnapshot.ps1 -OutputPath C:\Temp\FwInstallerEvidence\before.json -Name before
+./scripts/Agent/Collect-InstallerSnapshot.ps1 -OutputPath C:\Temp\FwInstallerEvidence\after.json -Name after
+./scripts/Agent/Compare-InstallerSnapshots.ps1 -BeforeSnapshotPath C:\Temp\FwInstallerEvidence\before.json -AfterSnapshotPath C:\Temp\FwInstallerEvidence\after.json
+```
+
+## Triage Priorities
+
+- Bundle log first for Burn detection, prerequisite planning, cache/download failures, related bundle handling, and package log paths.
+- MSI verbose log first for directory properties, feature states, standard action sequencing, and custom action failures.
+- Search MSI logs for `Return value 3`, then walk upward to the failing action and property context.
+- Search bundle logs for `Detected package`, `Planned package`, `Applying execute package`, `Error 0x`, and final result code.
+- For custom actions, find the WiX action ID in `Framework.wxs`, then map it to the DllEntry in `CustomAction.cs`.
+- For hangs, identify the last completed phase/action and whether a UI prompt, process-close prompt, files-in-use dialog, or elevation prompt is waiting.
+
+## Report Format
+
+When reporting diagnostics, include:
+
+- Artifact tested and command used.
+- Evidence folder and primary logs.
+- Failure layer and first meaningful error.
+- Relevant Burn/MSI action/package names.
+- Machine state: clean, prereqs present, old FieldWorks installed, offline, upgrade, repair, or uninstall.
+- Next smallest fix or next evidence needed.

.github/skills/fieldworks-installer-diagnostics/references/evidence-and-commands.md

@@ -0,0 +1,55 @@
+# FieldWorks Installer Evidence And Commands
+
+## Artifact Paths
+
+WiX 3 fallback/current default:
+
+- `FLExInstaller/bin/x64/Debug/en-US/FieldWorks.msi`
+- `FLExInstaller/bin/x64/Debug/FieldWorksBundle.exe`
+
+WiX 6 migration path:
+
+- `FLExInstaller/wix6/bin/x64/Debug/en-US/FieldWorks.msi`
+- `FLExInstaller/wix6/bin/x64/Debug/FieldWorksBundle.exe`
+- `FLExInstaller/wix6/bin/x64/Debug/FieldWorksOfflineBundle.exe`
+
+Adjust `Debug` to `Release` as needed.
+
+## Helper Script Notes
+
+- `scripts/Agent/Invoke-Installer.ps1` creates `Output/InstallerEvidence/<RunId>/` by default.
+- The helper's default artifact resolver historically points at `FLExInstaller/bin/...`; pass `-InstallerPath` explicitly for WiX 6 artifacts.
+- Use `-IncludeTempLogs` for Burn package logs and chained package logs.
+- Use `-SummarizeMsiFileAccess` when validating installed file payloads from MSI logs.
+
+## Common Runs
+
+Interactive WiX 6 bundle:
+
+```powershell
+./scripts/Agent/Invoke-Installer.ps1 -InstallerType Bundle -InstallerPath '.\FLExInstaller\wix6\bin\x64\Debug\FieldWorksBundle.exe' -IncludeTempLogs
+```
+
+Passive WiX 6 bundle:
+
+```powershell
+./scripts/Agent/Invoke-Installer.ps1 -InstallerType Bundle -InstallerPath '.\FLExInstaller\wix6\bin\x64\Debug\FieldWorksBundle.exe' -Arguments @('/passive') -IncludeTempLogs
+```
+
+Direct MSI full UI:
+
+```powershell
+msiexec /i .\FLExInstaller\wix6\bin\x64\Debug\en-US\FieldWorks.msi /qf /l*v C:\Temp\FwInstallerEvidence\msi-ui.log
+```
+
+Uninstall by product code:
+
+```powershell
+msiexec /x {PRODUCT-CODE} /l*v C:\Temp\FwInstallerEvidence\msi-uninstall.log
+```
+
+## Crash Evidence
+
+- Event Viewer -> Windows Logs -> Application: `.NET Runtime`, `Application Error`, and `MsiInstaller`.
+- Crash dumps: `%LOCALAPPDATA%\CrashDumps\` for bundle, custom BA, or `msiexec.exe` crashes.
+- FieldWorks debug traces can be enabled with `FieldWorks.Diagnostics.config` as described in `.github/instructions/debugging.instructions.md`.

.github/skills/fieldworks-installer-diagnostics/references/log-triage.md

@@ -0,0 +1,69 @@
+# Installer Log Triage
+
+## Burn Bundle Log
+
+Read in phase order:
+
+1. Header/version/command line.
+2. Detect phase: `Detected package`, related bundle detection, registry searches, prerequisite state.
+3. Plan phase: `Planned package`, requested action, cache strategy, dependency registration, feature states.
+4. Cache/download phase: URL, payload hash/signature, cache path.
+5. Apply phase: `Applying execute package`, package arguments, package-specific log path.
+6. Completion: package result, restart state, final HRESULT.
+
+Useful strings:
+
+- `WixBundleLog`
+- `WixBundleLog_AppMsiPackage`
+- `Detected package:`
+- `Planned package:`
+- `Applying execute package:`
+- `Error 0x`
+- `restart:`
+- `Will not uninstall package`
+- `found dependents`
+
+## MSI Verbose Log
+
+Read around the first real failure, not the final summary only.
+
+Useful strings:
+
+- `Return value 3`
+- `CustomAction`
+- `Action start`
+- `Action ended`
+- `APPFOLDER`
+- `DATAFOLDER`
+- `WIX_UPGRADE_DETECTED`
+- `FindRelatedProducts`
+- `RemoveExistingProducts`
+- `InstallValidate`
+- `PATCH`
+- `PATCHNEWSUMMARYSUBJECT`
+
+When `Return value 3` appears, walk upward to find the custom action or standard action that failed, then inspect properties and command line immediately before it.
+
+## Custom Actions
+
+Map WiX action ID to DLL entry:
+
+- `CheckApplicationPath` -> `CheckAppPath`
+- `VerifyDataPath` -> `VerifyDataDirPath`
+- `CloseApplications` -> `ClosePrompt`
+- `DeleteRegistryVersionNumber` -> `DeleteVersionNumberFromRegistry`
+
+Common causes:
+
+- Required session properties not initialized before UI sequence.
+- Deferred action needs `CustomActionData` but reads session properties directly.
+- Missing `CustomActions.CA.dll` or runtime config in the Binary payload.
+- Process-close prompt waiting for user action.
+
+## Symptom Shortcuts
+
+- Double-click does nothing: run with `/log`; check Burn condition failures, BA/theme load failure, Event Viewer, crash dumps.
+- Bundle waits after detect: interactive bundle may be waiting for user action. Use `/passive` or full UI intentionally.
+- MSI UI missing from bundle: inspect `bal:DisplayInternalUICondition`, UI level, and package log.
+- Uninstall hangs: find whether Burn, MSI, files-in-use, CloseApplications, or ARP invocation is waiting.
+- Duplicate ARP entries: inventory bundle vs MSI registrations and check package visibility/ARP properties.

.github/skills/fieldworks-wix6-build-migration/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: fieldworks-wix6-build-migration
+description: Use this skill for FieldWorks WiX Toolset build migration work: moving PatchableInstaller/genericinstaller behavior into WiX 6, fixing Build/Installer*.targets, SDK-style .wixproj files, InstallerToolset selection, prerequisite download/staging, CI installer builds, signing knobs, artifact paths, and local developer build failures. Trigger whenever the user mentions FieldWorks WiX build, Wix3/Wix6 toolset selection, PatchableInstaller migration, genericinstaller removal, or installer artifacts.
+---
+
+# FieldWorks WiX 6 Build Migration
+
+This skill handles build infrastructure and migration mechanics. Keep it separate from UI behavior, runtime diagnostics, and patch/upgrade validation unless those areas are the cause of a build failure.
+
+## Load References When Needed
+
+- Read `references/repo-build-map.md` for FieldWorks-specific targets, projects, commands, and artifact paths.
+- Read `references/official-wix-build-notes.md` for WiX Toolset v4/v6 migration and MSBuild facts.
+
+## First Moves
+
+1. Confirm current branch/worktree and whether the task is about the WiX 3 fallback, the WiX 6 migration path, or the switch to WiX 6 as default.
+2. Read `FLExInstaller/AGENTS.md`, `.github/instructions/installer.instructions.md`, and `.github/instructions/build.instructions.md`.
+3. Inspect `Build/InstallerBuild.proj` to confirm which target file is imported for `InstallerToolset=Wix3|Wix6`.
+4. Inspect `Build/Installer.targets`, `Build/Installer.Wix3.targets`, and relevant `.wixproj` files before editing.
+5. Search for active references to `PatchableInstaller`, `genericinstaller`, `candle.exe`, `light.exe`, `insignia.exe`, and `heat.exe`; classify each as WiX 3 legacy, WiX 6 active, or documentation/reference.
+
+## FieldWorks Build Rules
+
+- Current default installer build is WiX 3 fallback: `./build.ps1 -BuildInstaller`.
+- WiX 6 is currently selected explicitly: `./build.ps1 -BuildInstaller -InstallerToolset Wix6`; treat that path as the migration target.
+- Do not make WiX 6 schema changes in `FLExInstaller/` root files. Keep WiX 6 authoring under `FLExInstaller/wix6/`.
+- Do not reintroduce a `genericinstaller` submodule. If old behavior is needed, migrate the specific source/config into the repo and document why.
+- Do not remove or break the WiX 3 path during the transition.
+- Use pinned repo package versions, not whatever WiX happens to be globally installed.
+- WiX 6 projects should be SDK-style and use WiX extension `PackageReference`s such as Bal, Util, NetFx, UI, and Heat as appropriate.
+- WiX v6 source uses `http://wixtoolset.org/schemas/v4/wxs`; there is no v6 schema namespace.
+
+## PatchableInstaller Migration Workflow
+
+When moving behavior out of the old generic installer/PatchableInstaller model:
+
+1. Identify the old source of behavior in `PatchableInstaller/`, `Build/Installer.legacy.targets`, or WiX 3 includes.
+2. Find the WiX 6 destination: `FLExInstaller/wix6/Shared/Base`, `Shared/Common`, `Shared/CustomActions`, `Shared/ProcRunner`, or a `.wixproj` target.
+3. Port only the needed behavior. Avoid copying whole legacy scripts or batch-driven assumptions into the WiX 6 path.
+4. Convert old command-line parameters into MSBuild properties and `DefineConstants` rather than batch variables.
+5. Add validation that fails loudly when required payloads or prerequisites are missing.
+6. Update specs/docs only when behavior or build commands change.
+
+## Build Failure Workflow
+
+1. Run or ask for the exact command and configuration, including `InstallerToolset`.
+2. Validate prerequisites with `./Build/Agent/Setup-InstallerBuild.ps1 -ValidateOnly` when the failure smells environmental.
+3. If WiX 6 fails, inspect `FieldWorks.Installer.wixproj`, `FieldWorks.Bundle.wixproj`, and `FieldWorks.OfflineBundle.wixproj` before touching MSBuild targets.
+4. For WiX errors, map the error to authoring/project/tooling. Do not hide warnings by suppression unless the repo already documents that suppression.
+5. Preserve `.wixpdb` outputs; they are useful for diagnostics and future patch baselines.
+
+## Validation
+
+Prefer these checks, scaled to the change:
+
+- `./Build/Agent/Setup-InstallerBuild.ps1 -ValidateOnly`
+- `./build.ps1 -BuildInstaller -InstallerToolset Wix6 -Configuration Debug`
+- `./build.ps1 -BuildInstaller -InstallerToolset Wix6 -Configuration Release` for release-path changes
+- Confirm artifacts under `FLExInstaller/wix6/bin/x64/<Configuration>/` and `en-US/`.
+- For CI or pre-commit work, use the repo VS Code task `CI: Full local check` when appropriate.
+
+## Output Expectations
+
+When reporting a build migration result, include:
+
+- The active toolset and entry point.
+- The target/project files touched.
+- The legacy behavior replaced or isolated.
+- The artifacts expected and where they land.
+- The validation run and remaining risk.

.github/skills/fieldworks-wix6-build-migration/references/official-wix-build-notes.md

@@ -0,0 +1,32 @@
+# Official WiX Build And Migration Notes
+
+Use these notes for WiX Toolset, not the Wix website builder.
+
+## Official Sources
+
+- WiX source: https://github.com/wixtoolset/wix
+- FireGiant docs: https://docs.firegiant.com/wix/
+- v3 to v4 migration WIP: https://docs.firegiant.com/wix/development/wips/4561-migrate-v3-source-code-to-v4/
+- MSBuild SDK docs: https://docs.firegiant.com/wix/tools/msbuild/
+- Preprocessor docs: https://docs.firegiant.com/wix/tools/preprocessor/
+- Extension docs: https://docs.firegiant.com/wix/tools/wixext/
+
+## Migration Facts To Remember
+
+- WiX v6 authoring still uses the v4 XML namespace.
+- v3 `candle.exe` and `light.exe` thinking maps to `wix build` or SDK-style MSBuild.
+- SDK-style `.wixproj` files can use `ProjectReference`s; WiX creates bind paths and preprocessor variables for referenced projects.
+- Extensions are NuGet packages in modern WiX, not only `-ext` paths to globally installed DLLs.
+- Useful MSBuild properties include `DefineConstants`, `BindPath`, `InstallerPlatform`, `OutputType`, `VerboseOutput`, `SuppressIces`, `SuppressValidation`, and `*AdditionalOptions`.
+- `Product` became `Package`; old `Package` metadata moved/reorganized.
+- `Component/@Win64` became `Bitness`; default bitness follows `InstallerPlatform`/`-arch`.
+- `RemotePayload` became package-specific payload elements such as `ExePackagePayload`, `MsiPackagePayload`, and `MspPackagePayload`.
+- `ExePackage` command attributes became `InstallArguments`, `RepairArguments`, and `UninstallArguments`.
+- `DisplayInternalUI` moved out of core Burn package authoring; use Bal `DisplayInternalUICondition` when appropriate.
+
+## Build Quality Rules
+
+- Do not suppress validation to get past real authoring problems.
+- Keep warnings visible unless the repo has an intentional suppression with a reason.
+- Preserve `.wixpdb` outputs for diagnostics and patch baselines.
+- Treat Heat as technical debt. If using generated fragments, guard component/file identity carefully.