Root cause found: winscp.net's download URL serves a human "please wait"
landing page (18KB HTML) instead of redirecting to the real file, unless
the User-Agent contains a known download-tool signature like curl or Wget.
PowerShell's own default UA always gets the landing page - confirmed by
reproducing locally with various UAs against the live URL. Not antivirus,
not TLS, not a network block; overriding -UserAgent to a curl string on
Invoke-WebRequest resolves it.
The 1MB size-check catches a bad download but gave no way to see why - on a
locked-down network something is very likely substituting a small HTML page
(proxy/AV block page) for the real zip. Print the first lines of whatever
was actually saved so the content is visible without another round trip.
Expand-Archive was failing with a cryptic "End of Central Directory record
could not be found" on Melissa's PC - the inline one-liner in setup.bat had
no error handling, so a blocked/truncated download (antivirus, firewall, or
an older TLS default) surfaced as a raw .NET exception instead of a useful
message. Moved the logic to Get-WinSCP.ps1: forces TLS 1.2, validates the
downloaded file size before unzipping, and reports what actually went wrong.
Windows PowerShell (5.1) reads .ps1 files without a UTF-8 BOM using the
system codepage, which mangles multi-byte UTF-8 characters like -> and --
into garbage that includes smart-quote characters PowerShell treats as
string terminators - this broke parsing on Melissa's PC (error at
engine.ps1:283, cascading missing-brace errors above it). Sticking to plain
ASCII avoids the whole encoding-dependent failure class.
Practice.json already supported overriding insurance_path/pdf_path/patient_path
via Merge-Config, but the README and example only mentioned login overrides —
document that practices can have different folder paths, not just credentials.
blance