ci: isolate deployment from existing IIS sites

TESTING.md

@@ -147,17 +147,36 @@ Before a production release:
 1. Run the full ASPUnit suite in the isolated development IIS application.
 2. Parse every repository `web.config` as XML.
 3. Parse both deployment scripts with the Windows PowerShell parser on a Windows CI worker.
-4. From a clean standalone checkout of the approved branch, run:
+4. From a clean standalone checkout of the approved `master` branch, run the local/controller preflight:
 
    ```powershell
-   .\scripts\deploy-iis-git.ps1 -SiteName 'ttasp' -RemoteTarget 'webserver-1' -DryRun
+   .\scripts\deploy-iis-git.ps1 -LocalPreflightOnly
    ```
 
-   This validates and packages locally but makes no network connection.
-5. Run `-RemotePreflightOnly` as a separately approved step when host connectivity is permitted.
-6. After deployment, require the installer smoke test and then run any production-safe HTTP checks. Never expose the `tests/` IIS application in production.
+   This validates source provenance, required files, `public/web.config` XML, package creation/extraction, release layout, and package safety without SSH/SCP or host changes.
+5. When host connectivity is separately permitted, run the complete read-only preflight (the dedicated target need not exist):
 
-Linux can validate XML and inspect script structure, but cannot prove Windows PowerShell, WebAdministration, Classic ASP, IIS URL Rewrite, Access/ACE, SSH elevation, or live HTTP behavior. Those checks remain Windows/IIS gates.
+   ```powershell
+   .\scripts\deploy-iis-git.ps1 -PreflightOnly -RemoteTarget 'webserver-1'
+   ```
+
+   It repeats the local/package checks, streams the installer without writing remote files, and validates IIS/Classic ASP and URL Rewrite, binding and shared-pool conflicts, the deployment drive/path, names, and exact existing-target state without changing IIS or the deployment root.
+6. For an isolated Windows test deployment, override names/root/port together rather than reusing any existing site:
+
+   ```powershell
+   .\scripts\deploy-iis-git.ps1 `
+     -SiteName 'AspClassicUnifiedFramework-Test' `
+     -AppPoolName 'AspClassicUnifiedFramework-Test' `
+     -DeployRoot 'D:\Deployments\AspClassicUnifiedFramework-Test' `
+     -BindingIpAddress '100.97.39.23' `
+     -BindingPort 8185 `
+     -RemoteTarget 'webserver-1'
+   ```
+
+7. Require the installer smoke test. Also induce a smoke-test failure in the isolated test target and verify that only resources created by that invocation are removed, or that an existing valid target's prior path and parent-path value are restored. Verify unrelated sites, pools, and bindings are unchanged.
+8. Run production-safe HTTP checks and prove rollback to a prior immutable release. Never expose the `tests/` IIS application in production.
+
+Linux can validate XML and repository safety/source assertions, but cannot prove Windows PowerShell 5.1 parsing, WebAdministration behavior, installed IIS features/modules, binding behavior on the live host, elevation, app-pool identity/ACLs, Access/ACE, SSH transport, cleanup under real IIS failures, or live HTTP responses. Those remain Windows/IIS gates.
 
 ## Limitations