psadt-deploy-skill 0.32.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,35 +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.32.0 - 2026-09-15
-- **Fixed: the dossier now reads the sandbox verdict instead of asking for it.** `New-PsadtReport.ps1`
-  took identity, artefacts and return codes from the manifest but not the test result, so without a
-  hand-built `-Metadata SystemTest` it printed "the SYSTEM test was not run (no evidence)" on packages
-  whose gate was GREEN. It reads `results.sandboxTest.resultPath` now and **judges** the rows: an action
-  that exits 0 while the detection rule disagrees is a fail, not a pass - that combination is the
-  signature of a per-user install. A caller-supplied `SystemTest` still wins, and an unreadable
-  result.json keeps the honest "not run" default.
-- **Fixed: the guest progress window hung off the right edge** of the sandbox desktop, taking the TIMEOUT
-  and DETECTION columns with it. Sized against the work area and positioned explicitly now; verified in
-  the guest.
-- **Changed: a fourth BINDING trap in App. L.7** - re-running the installer over an existing install is
-  not a safe repair. Measured on JetBrains PyCharm 2026.2.2 as SYSTEM: `/S` over an existing install of
-  the same version never returned (killed at 603 s, no child process, no error), while Install and
-  Reinstall on a clean machine both exited 0. Repair is an explicit uninstall followed by an install.
-- PyCharm 2026.2.2 (908 MB, the largest package built with this skill) then passed the full gate GREEN.
-  Suite 572 -> 576.
-
-### 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.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.32.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",