The badge that tells you a script won't survive PowerShell 7

The risky scripts in any shop are the ones nobody has tried on PowerShell 7 yet. They sit in a folder, they matter, and the assumption is they’ll port fine. Some of them won’t, and the traditional way to find out is in production.

DetentShell moves that discovery into the editor. As you type, a classifier reads the script’s syntax tree and grades it. Green: expected to run cleanly on PowerShell 7. Red: depends on something that needs Windows PowerShell 5.1. Yellow: something in between worth a look. The result shows as a colored badge at the right end of the toolbar, labeled with the engine it refers to, updating as you edit. There’s no scan to kick off and no report to read. The verdict is just present.

The badge only informs. The decision belongs to the picker next to it, which sets the engine per tab: Auto, pinned PowerShell 7, or pinned Windows PowerShell 5.1. Auto is where the classifier does its work. A green script runs on PowerShell 7 with no ceremony. A flagged script gets one question before anything executes: run this on Windows PowerShell 5.1? Yes routes the run to Windows PowerShell 5.1. No pins PowerShell 7 for the run. Cancel runs nothing.

Your answer sticks while the script stays unchanged, so pressing F5 five times in a row asks once. Editing the script re-arms the question, since edited text is a different script.

The reason the gate fires before execution, rather than letting the run fail naturally: a script that dies forty lines in has usually done forty lines of work. Half-completed cleanup jobs and half-migrated data are much worse than a dialog box. We took the dialog.

The pin exists for the times you know better. Maybe the flagged cmdlet is in a branch that never executes on this machine, or you’re deliberately testing behavior differences. Pin the engine and the gate stays quiet. Auto is a default, not a policy.

← All posts