psadt-deploy-skill 0.31.0 → 0.34.0

package/README.md

@@ -52,7 +52,7 @@ Twelve phases, each owned by a script rather than by prose, so a step either pas
 | Phase | What happens | Owner |
 |---|---|---|
 | **0** Setup | 13 prerequisite checks, GREEN/YELLOW/RED, `-Fix` provisions | `Initialize-PsadtSkill.ps1` |
-| **1–2** Intake + research | blocker questions as clickable options; parallel research of version, silent switches, Intune pitfalls | agent (gates 1–2) |
+| **1–2** Intake + research | blocker questions as clickable options; a local-evidence ladder (installed here? binary here? already written down?) answers what it can, and a research agent is dispatched only per question it leaves open | agent (gates 1–2) |
 | **3** Scaffold | a generator writes launcher + detection + per-run log name + manifest; `New-ADTTemplate` only when none fits | `New-MsiPackage` · `New-BrowserExtensionPackage` · `New-WindowsFeaturePackage` · `New-DriverPackage` |
 | **4** Customize | all three hooks filled from the research, helpers in the Extensions module | agent |
 | **5** Pre-flight | 10 checks (encoding, AST parse, v3 cmdlets, structure, detection contract, manifest, log name, driver trust …) → GREEN/RED | `Invoke-PsadtPreflight.ps1` |
@@ -196,7 +196,7 @@ The app's **native installer is always the default**. Everything else is opt-in
   matrix and the manual portal route: `references/app-registration.md`.
 - For **Pester tests**: Pester 5+ (`Install-Module Pester -MinimumVersion 5.0 -Scope CurrentUser`)
 - **Optional (recommended): the [superpowers](https://github.com/obra/superpowers) plugin** — if installed,
-  the research fan-out and the reviewer gate use it. Not required: without it the skill falls back to the
+  the gated research fan-out and the reviewer gate use it. Not required: without it the skill falls back to the
   native Agent tool and `/code-review`, and nothing in the workflow depends on the plugin.
 
 ## Installation
@@ -434,31 +434,44 @@ The two most recent releases are below. **[CHANGELOG.md](CHANGELOG.md)** carries
 every release since 0.1.0, and nothing is ever removed from it - this section is a window onto it, not a
 second copy to keep in sync.
 
-### 0.31.0 - 2026-09-14
-- **Added: the guest window shows every phase of the run at once.** Until now it showed one line, the step
-  running right now, so a run three phases in looked like one stuck on its first and a failed phase left
-  nothing to read. It is a WPF master/detail window now: tick, cross or live marker per phase, and for the
-  selected one its exit code, duration, start and end, timeout, detection result and its own transcript.
-  Still a separate process polling a file, still passive - it never drives the run and closing it stops
-  nothing.
-- **Added: `progress.json` carries a `phases[]` plan derived from `-Scenarios`.** The hardcoded `total = 14`
-  it published before was wrong for every partial run, and wrong for the full gate too, which has 15 steps.
-  The older top-level fields are unchanged.
-- **Measured in the guest before the port, not after:** WPF loads there under Windows PowerShell 5.1,
-  the real XAML parses, and the window paints at render tier 0 with no vGPU - a PNG of it came back out of
-  the VM as the proof. New guards in `tests/SandboxProgressUi.Tests.ps1` cover ASCII, parsing, XAML loading
-  and the phase plan. Suite 554 -> 569.
-
-### 0.30.2 - 2026-09-14
-- **Changed: a vendor-specific success code has to be in BOTH lists.** A sandbox step is judged twice, by
-  two independent lists that share a parameter name: PSADT's `-SuccessExitCodes` in the launcher decides
-  whether the deployment throws, `Invoke-PsadtSandboxTest.ps1 -SuccessExitCodes` decides whether the step
-  is painted green. Citrix Workspace Repair returns the documented success code 40032; it went into the
-  launcher, the run still came back RED, and three further runs were spent re-editing a launcher that had
-  been correct all along. Guide 6.1, Appendix B and Appendix G now say so, and a drift guard keeps the
-  documented default equal to the actual one.
-- **Changed: four silent PowerShell traps** added to Appendix B, each of which cost a run here: `@(...)`
-  around an EMPTY `Generic.List` throws in 5.1 and 7 alike; `-WindowStyle Hidden` is inherited by the
-  child's first window, so a progress GUI runs windowless and looks like a hang; two variables differing
-  only in case are the same variable; `-like` against a literal containing `*` matches too much.
-- All 12 applications packaged with 0.30.x are GREEN, Citrix Workspace included. Suite 552 -> 554.
+### 0.34.0 - 2026-09-16
+- **Added: `-TrustedPublisherCert` on `Invoke-PsadtSandboxTest.ps1`.** An installer that stages a
+  third-party driver raises the Windows "install device software?" prompt unless the signer is already in
+  `TrustedPublisher` - and in the guest that prompt is **invisible**, because every action runs as SYSTEM
+  through a scheduled task and draws nothing on the desktop. The installer waits for an answer nobody can
+  give and the phase burns its whole timeout, looking exactly like a slow installer. Pass the `.cer` and
+  the harness imports it during GuestPrepare, the same thing an Intune `RootCATrustedCertificates` profile
+  does on the fleet. Measured on Time-Access 3010 / EDIsecure: **25 minutes of timeout versus 43 seconds**.
+  The import uses `certutil` (`Import-Certificate` returns `E_ACCESSDENIED` in the guest even when
+  elevated) and is **verified by reading the store back** - a failed import is indistinguishable from a
+  successful one when only the return value is logged, and that cost a full run.
+- **Fixed: the elapsed timer in the guest window stopped counting.** It rendered `progress.json` verbatim,
+  but `Update-Ui` returns early when that file has not changed - right for the phase list, fatal for a
+  clock, and phases that are not an action wait loop never rewrite the file at all (GuestPrepare alone can
+  sit there for 90 seconds). The one element whose job is to prove the run is alive was frozen exactly
+  when that gets asked. It now ticks on the window's own 1s timer and re-syncs on every file value.
+- **Fixed: the heartbeat was up to 20 seconds stale** - the guest wrote every 10s and the host read every
+  10s, and the two stacked. Both are 1s now; the console line and transcript keep the coarser beat so
+  phase boundaries stay legible.
+- Phase 6.1 now documents cancelling with `STOP.txt` (killing the process orphans `vmmemWindowsSandbox`
+  and blocks every further run) and scoping with `-Scenarios` while iterating. Suite 624, unchanged by this release - the new behaviour is guarded by the existing sandbox-harness and progress-UI tests.
+### 0.33.0 - 2026-09-16
+- **Fixed: the Phase 2 research fan-out is gated.** `SKILL.md` ordered it in the imperative - *"Dispatch
+  the three Researcher roles concurrently"* - one line above the two probe sentences, and rule 1 routed
+  every unknown into it because asking is forbidden. Three agents ran whether or not anyone needed them;
+  on an app already installed on the packaging machine, one such run cost 400k tokens to rediscover a
+  `QuietUninstallString` the Uninstall registry had been holding all along.
+- **Added: `scripts/Get-PsadtLocalEvidence.ps1`**, the ladder that decides whether an agent is warranted.
+  Four rungs, deterministic and offline: the installed PSADT module's manifest (retiring the
+  version/command-drift research topic outright), the Uninstall registry, the existing MSI and
+  switch-candidate probes composed rather than reimplemented, and this skill's own corpus plus a vendor
+  doc URL it **names but never fetches**. It reports `OpenQuestions[]` and `AgentBudget`, and that number
+  is the dispatch cap: zero open questions, zero sub-agents.
+- **Capped by family, so the cap is structural.** Questions one vendor deployment page answers fold into
+  a single agent. Three families can ever dispatch, so the budget cannot exceed three however the
+  question set grows - measured at **2 for an MSI or an app installed locally, 3 at worst**.
+- **Honest about its limits.** The external runtime prerequisite and known Intune pitfalls are marked
+  `CanCloseLocally = $false` - a statement about other people's fleets does not follow from this machine -
+  so the realistic floor is two agents, not zero. Everything open but not worth an agent lands in
+  `Deferred[]` with a reason, and `repair-strategy` is now a first-class question because
+  `rule:all-three-deployment-types` makes Repair a deliverable.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "psadt-deploy-skill",
-  "version": "0.31.0",
+  "version": "0.34.0",
   "description": "Installer for the psadt-deploy Claude Code skill: build, test and deploy PSADT v4.x Intune Win32 packages.",
   "keywords": [
     "psadt",