Merge-Config assigned override values with '=', which throws
SetValueInvocationException when the property doesn't exist on the base
object - so a practice.json could only override fields already present in
entity.json. AJMATS's practice.json supplies insurance_path/pdf_path that
CAMBS's entity.json lacks entirely, which crashed the merge. Use Add-Member
-Force (handles both add and replace), copy whole sections missing from the
base, skip _comment keys, and replace scalar sections directly.
CAMBS's run showed host= blank, an empty upload path, and WinSCP's
"Password is set, but UserName is not" - i.e. entity.json's ftps section
had a readable password but host/username/insurance_path came up empty,
which points at misspelled or misplaced keys. Instead of letting WinSCP
throw a cryptic connect error per practice, check the merged config up
front and print exactly which entity.json fields are missing or blank.
Makes it obvious at a glance whether entity.json's insurance_file_type was
actually read (e.g. 'File type: .tif') instead of silently defaulting to pdf.
The Get-WinSCP.ps1 unblock-on-extract fix wasn't enough - if the WinSCP
folder is ever copied again afterward (network share, zip, sync tool),
Windows can reapply Mark-of-the-Web and silently re-block it. Unblock the
whole folder at the top of every engine.ps1 run instead of relying on
setup.bat timing. Also wrapped Add-Type in try/catch so a real load failure
now stops the run with a clear message instead of silently continuing into
a script that would only fail later once it actually tried to upload
something.
CAMBS, RMI, CONSENSIO, and INLAND always export TIFs into the daily date
folder instead of PDFs, so engine.ps1's hardcoded "*.pdf" filter silently
found nothing to upload (no error, just "No PDFs" for every practice).
Added optional entity.json field "insurance_file_type" (defaults to "pdf"
when omitted, so existing entities are unaffected); the PT STMT split logic
already worked on filename regardless of extension, so no other changes
needed.
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.
blance