psadt-deploy-skill 0.44.0 → 0.47.0

package/README.md

@@ -73,7 +73,7 @@ Thirteen phases, each owned by a script rather than by prose, so a step either p
 | **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-MsiPackage` · `New-ExePackage` · `New-BrowserExtensionPackage` · `New-WindowsFeaturePackage` · `New-DriverPackage` |
 | **4** Customize | all three hooks filled from the research, helpers in the Extensions module | agent |
-| **5** Pre-flight | 11 checks (encoding, AST parse, v3 cmdlets, structure, detection contract, manifest, log name, driver trust …) → GREEN/RED | `Invoke-PsadtPreflight.ps1` |
+| **5** Pre-flight | 14 checks (encoding, AST parse, v3 cmdlets, structure, detection contract, manifest, log name, driver trust …) → GREEN/RED | `Invoke-PsadtPreflight.ps1` |
 | **6** SYSTEM test | the whole loop in a throwaway Windows Sandbox, every action as **SYSTEM** like the IME does - no elevation, host untouched. **Binding before any upload** | `Invoke-PsadtSandboxTest.ps1` |
 | **7** Package | one command → verified `.intunewin`, named after the app | `Invoke-PsadtPackage.ps1` |
 | **8** Dossier | always, uploaded or not: bilingual self-contained HTML | `New-PsadtReport.ps1` |
@@ -103,7 +103,7 @@ the same app from disagreeing about their own version.
 - **A dossier is produced every time**, uploaded or not: one self-contained bilingual HTML file with the
   return-code map, the detection rule, the hooks, the test results - and a ready-to-paste Company-Portal
   description.
-- **757 Pester tests**, including drift guards that fail when the documentation and the code disagree -
+- **921 Pester tests**, including drift guards that fail when the documentation and the code disagree -
   one of them reads the published landing page and compares its figures against this repository.
 
 ## Go deeper
@@ -115,13 +115,13 @@ the same app from disagreeing about their own version.
 | [`docs/features.md`](docs/features.md) | the complete feature list, package type by package type |
 | [`docs/setup-and-structure.md`](docs/setup-and-structure.md) | first-run setup, config home, full project structure |
 | [`SKILL.md`](SKILL.md) | the control plane the agent actually reads |
-| [`references/README.md`](references/README.md) | the reference map: phases 0-12 and appendices A-Q |
+| [`references/README.md`](references/README.md) | the reference map: phases 0-12 and appendices A-R |
 | [`SECURITY.md`](SECURITY.md) | the risk surface and the control covering each part of it |
 
 ## Status
 
 In active use for the full build → package → test → dossier workflow, with the direct Graph upload
-verified against a live tenant. The helper scripts are covered by 757 Pester tests.
+verified against a live tenant. The helper scripts are covered by 921 Pester tests.
 
 One open point, honestly: **the driver `pnputil` exit-code semantics are documented, not verified here.**
 `0` / `259` / `3010` and the two `0xE...` failures come from Microsoft's documentation; confirming them
@@ -170,11 +170,20 @@ installed.
 **[CHANGELOG.md](CHANGELOG.md)** carries the complete history, every release since 0.1.0, and nothing is
 ever removed from it.
 
-Latest: **0.44.0 - A GREEN package that would have looped in production.** Google Chrome ships a new MSI
-ProductCode with every build and updates itself in place, so the MSI generator's ProductCode-keyed package
-passed every gate and would still have been re-installed by Intune every day once GoogleUpdater moved a
-device on. `New-MsiPackage.ps1 -SelfUpdatingBinary` now generates a version-floor detection, an install
-that skips an equal or newer build, and uninstall/repair by the registered ARP name - verified in the full
-sandbox gate on Chrome 154. Every other lesson of that run became a gate too: pre-flight stays RED while
-research is unanswered, packing and the sandbox refuse a RED or stale pre-flight, and the upload and the
-dossier take the description, logo and detection script from the manifest instead of asking again.
+Latest: **0.47.0 - The supersedence this skill has been wiring may never have been wired.** The upload has
+POSTed a supersedence relationship since 0.8.x, on a route that is reported not to exist, catching the
+failure and printing a yellow line - so a chain that never took looked like a normal run. No test touched
+any of it. The write now uses the `updateRelationships` action the admin center uses, merges onto the
+existing relationships instead of replacing them, and reads the chain back before claiming it. The mode is
+no longer hardcoded to `replace`, which uninstalled the previous version from every device first; `update`
+is the default and the MSI's own Upgrade table decides. Two new scripts make the predecessor's id
+something you can read rather than retype, and Appendix R covers the lifecycle - including that Intune has
+no retire state at all.
+
+Previously: **0.46.0 - Sixteen findings, and the two the live run had already proved.** The last sixteen
+findings from the deep analysis. A full run on 0.45.0 had shown two of them for real: the dossier
+existed on disk while the manifest said nothing about it, and the package finished with no logo and no
+warning. The manifest now records what was produced, the three JSON stores are replaced atomically, the
+packaging tool and the four MSAL packages are verified before anything executes, the host re-checks the
+verdict the sandbox hands it, a generator no longer discards a hand-filled package without -Force, and
+an ampersand in a path no longer produces a sandbox that silently starts without its mapped folders.

package/bin/install.mjs

@@ -222,8 +222,12 @@ async function main() {
         // The ref is recorded next to the sha because Update-PsadtSkill.ps1 cannot otherwise tell a
         // release-pinned installation from one tracking main, and would report a pinned machine as
         // permanently "behind" every time main moved.
-        // -Command, not -File: -File passes every argument as a string and -Updates wants a hashtable.
-        run(psExe, [...psBase, '-Command', `& '${setCfg}' -Updates @{'tooling.skillCommit'='${sha}'; 'tooling.skillRef'='${ref}'}`]);
+        // -Command, not -File: -File stringifies every argument and -Updates wants a hashtable. The
+        // VALUES travel as environment variables, never interpolated into the source: a ref or a home
+        // directory containing an apostrophe would otherwise close the literal and run what follows.
+        run(psExe, [...psBase, '-Command',
+          "& $env:PSADT_SETCFG -Updates @{'tooling.skillCommit'=$env:PSADT_SHA; 'tooling.skillRef'=$env:PSADT_REF}"],
+          { env: { ...process.env, PSADT_SETCFG: setCfg, PSADT_SHA: sha, PSADT_REF: ref } });
         console.log(`  OK  recorded commit ${sha.slice(0, 7)} at ref ${ref}`);
       }
     } else if (res.status === 404) {
@@ -254,7 +258,8 @@ async function main() {
   // -Command with Out-Null rather than -File: the doctor also RETURNS its result object, and with inherited
   // stdout that object gets dumped underneath its own table. Out-Null drops the object; Write-Host output
   // (the table) is unaffected.
-  const d = run(psExe, [...psBase, '-Command', `& '${doctor}' -Fix -JsonPath '${jsonPath}' | Out-Null`]);
+  const d = run(psExe, [...psBase, '-Command', '& $env:PSADT_DOCTOR -Fix -JsonPath $env:PSADT_JSON | Out-Null'],
+    { env: { ...process.env, PSADT_DOCTOR: doctor, PSADT_JSON: jsonPath } });
 
   let verdict = null;
   try {

package/package.json

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