psadt-deploy-skill 0.43.0 → 0.46.0

package/README.md

@@ -1,4 +1,4 @@
-<h1 align="center">PSADT v4 → Intune Deployment Skill</h1>
+<h1 align="center">PSADT v4 → Intune Deployment Skill</h1>
 
 <p align="center">
   <em>A Claude Code skill that drives the full lifecycle of a PowerShell App Deployment Toolkit (PSADT) v4.x Intune Win32 package - from first conversation to a tested, upload-ready <code>.intunewin</code>.</em>
@@ -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 -
+- **859 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
@@ -121,7 +121,7 @@ the same app from disagreeing about their own version.
 ## 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 859 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,12 +170,10 @@ installed.
 **[CHANGELOG.md](CHANGELOG.md)** carries the complete history, every release since 0.1.0, and nothing is
 ever removed from it.
 
-Latest: **0.43.0 - The command that writes to the tenant could not bind.** A deep analysis of 0.42.0 read
-every control `SECURITY.md` claims, packaged an app end to end and ran the suite; its five stop-ship
-findings are fixed here. The Phase 9 upload command shown in `SKILL.md` could not bind, because
-`-IntuneWinPath` was mandatory while the artifact had been in the manifest since Phase 7 - and a new guard
-now binds every invocation the control plane shows against the real parameter sets. The third-party WinGet
-module that ships inside the `.intunewin` is pinned by SHA256 instead of a two-byte header. Three operator
-values that reached scripts running as SYSTEM are escaped or validated. A legacy config can no longer be
-written to, so the secret cannot be created inside the skill folder. The dossier template no longer names a
-customer.
+Latest: **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.43.0",
+  "version": "0.46.0",
   "description": "Installer for the psadt-deploy Claude Code skill: build, test and deploy PSADT v4.x Intune Win32 packages.",
   "keywords": [
     "psadt",