Quick Fix previews everything before it touches your script
Automated code fixers have earned their reputation. Most people have watched one “clean up” a working script into a broken one, or rewrite a file in place and leave them reconstructing what changed from memory.
DetentShell’s Quick Fix applies five hardening transforms: wrap risky calls in try/catch, add strict mode, add parameter validation, guard dangerous commands like Invoke-Expression, and stop catch blocks from leaking sensitive detail in error messages. Useful changes, the kind a security review requests in bulk. The design constraint was that it must be impossible to be surprised by it.
Open it from the Edit menu or a right-click. All five fixes dry-run against the function your caret is in; strict mode considers the whole file since that’s a file-level concern. You get a list where each fix is either applicable or refused, and refusals come with sentences. Actual strings from the shipping app:
Add strict mode — This script explicitly turns strict mode off; that looks deliberate, so this won’t override it.
Guard dangerous commands — No dangerous cmdlet calls (Invoke-Expression, a dynamic Invoke-Command, or Add-Type -TypeDefinition) were found here.
A refusal with a reason treats your code as possibly intentional, which it usually is. Where overriding makes sense, the refusal row is followed by a “do it anyway” entry, and that choice is explicit.
Picking a fix opens a before-and-after preview, side by side in monospace. The transform marks its work in a comment (# wrapped by Add-MWTryCatch with the version number), so whoever reads the file next month can tell what happened. Apply replaces exactly the enclosing function’s text and nothing else. Cancel leaves the buffer identical, and our UI test for that scenario compares the buffer byte for byte afterward.
The transforms come from the ModuleWorkshop.Transforms module and operate on the syntax tree, which is why the refusals can be that specific. An AST knows the call is already inside a try block; a regex guesses. The dry-runs execute on a dedicated background runspace so the analysis never touches your session state. If the module isn’t installed, the feature says so and stays out of the way.
Nothing changes without an explicit Apply. That rule has no exceptions in the codebase, and the UI tests would catch one if it appeared.