Installer Verification Embedded Script Reliability Automation: A Feature That Never Worked, Reassuringly

A defect that causes an obvious crash, error message, or clearly wrong result gets noticed and fixed quickly, almost by definition — someone sees it and reports it. A defect that instead causes a plausible, reasonable-sounding answer to be returned in place of the correct one can survive for the entire lifetime of a feature, because nothing about using the feature ever looks wrong. An empty list where a correct empty list is also a normal, expected outcome; an error message about a file being moved when a file legitimately being moved is also an unremarkable, common occurrence — both are indistinguishable from correct behavior to anyone not independently verifying the underlying facts.

Centriu Guardian's installer-verification feature runs a pair of embedded PowerShell scripts directly on a user's own computer: one lists files recently downloaded to common locations, and the other checks a specific file's digital signature and download history in detail. Both scripts had been broken since the feature first shipped, for two entirely unrelated reasons.

The first script builds a list of folders to search by writing an expression combining two folder-path lookups with a `+` operator, separated by a comma, without surrounding parentheses. In PowerShell specifically, a comma binds MORE tightly than `+` — the opposite of what a reader more familiar with common languages like JavaScript or Python would assume. Without the grouping parentheses, the expression is parsed not as "two separate folder paths, joined into a list" but as "one folder path, plus a two-item list, all converted to text and joined into a single string" — collapsing what were meant to be two distinct, real folder locations into one nonexistent, concatenated string that exists nowhere on any computer. Every check against that nonexistent path correctly returned nothing, and the resulting list was empty — which is precisely the CORRECT answer whenever nothing has genuinely been downloaded recently, meaning the broken version and the working version produced identical, unremarkable output in the overwhelmingly common case, and nobody had a reason to suspect the script was broken rather than simply reporting an ordinary, quiet day.

The second script's bug had a completely different root cause. The script opened with a `param()` declaration block — perfectly valid PowerShell, but valid specifically as the LITERAL FIRST statement of a script. The production code that executes these embedded scripts, however, always prepends a short setup instruction to the script text before running it, specifically to ensure that accented characters in file names and paths render correctly rather than as garbled text. That prepended instruction silently disqualified `param()` from being the script's first statement, which is a hard parsing error in PowerShell — the entire script failed before its first real line ever executed. The production wrapper responds to any script failure by returning an empty string, and the code reading that empty string interpreted it as a specific, plausible negative answer: "this file is no longer at the location provided." Reported about files that were, in every case checked, sitting exactly where specified — a confidently wrong answer that read as entirely reasonable on its own.

Both fixes are narrow. The first script now wraps the folder-path expression in explicit parentheses, forcing PowerShell to evaluate it as two separate values before the `+` and comma operators ever apply. The second script simply removes the invalid `param()` block, since the script did not actually need to declare external parameters through that mechanism. The more durable change is a new, dedicated test that compiles each embedded script through an actual PowerShell process, using the EXACT SAME setup-instruction prefix the production wrapper always adds — a detail that matters entirely: tested on its own, without that specific prefix, the second script's `param()` block is completely valid, and the bug would stay invisible to any test that did not replicate the real production wrapper precisely.

Before the fix, a person uses Guardian's installer-verification feature to confirm a downloaded Guardian installer is genuine and correctly signed. The feature reports that the file is no longer at the specified location — even though the file is sitting exactly there — because the verification script silently failed to parse under the real production wrapper and returned nothing, misread as a specific negative answer. Separately, checking for recently downloaded files returns an empty, reassuring list even on a day when files genuinely were downloaded, because the folder-search script's own path expression silently collapsed into a location that exists nowhere. After the fix, both scripts run and report correctly: a present file is confirmed present with its real signature details, and a genuinely empty download history is the only way an empty list is returned.

Centriu Guardian's installer-verification feature now correctly reports both recently downloaded files and a specific file's real presence and signature details, closing two independent scripting bugs that had produced plausible-looking but incorrect answers since the feature first shipped — verified by a new test that runs the real embedded scripts through the real production execution wrapper.

This automation governs the internal reliability of two specific embedded PowerShell scripts inside Centriu Guardian's own installer-verification feature — it does not change what the feature is designed to check, does not add a customer-facing setting, and does not affect any other Guardian feature; the two bugs described here are specific to these two scripts and were not found to recur elsewhere in the agent's other embedded scripts.

Testing an embedded script by running it directly — pasted into a script editor or terminal — is the natural first instinct, and it is exactly the approach that would have missed the second bug entirely, since the script is completely valid on its own and only fails once the real production wrapper's own setup-instruction prefix is added ahead of it. Testing through the literal execution path production uses, including every detail that path adds beyond the script's own text, is the only way to catch a defect that exists specifically in the interaction between a script and its own runtime wrapper, rather than in the script's text considered in isolation.