fix(ps1): replace null-conditional operator for PowerShell 5.1 compatibility

[mnriem]

Summary

Replaces the ?. (null-conditional member access) operator in scripts/powershell/common.ps1 with a PowerShell 5.1-compatible pattern.

Problem

The ?. operator requires PowerShell 7.1+, but Windows ships with PowerShell 5.1 by default. When AI agents (e.g., Cursor) invoke .ps1 scripts on Windows, they typically use the system-associated handler (Windows PowerShell 5.1), causing:

Unexpected token '?.Path' in expression or statement.

This breaks all spec-kit script execution on Windows for users without PowerShell 7+ installed, since common.ps1 is sourced by every other script.

Fix

Single-line change in scripts/powershell/common.ps1 line 11:

# Before (requires PS 7.1+)
$current = (Resolve-Path -LiteralPath $StartDir -ErrorAction SilentlyContinue)?.Path

# After (works on PS 5.1+)
$resolved = Resolve-Path -LiteralPath $StartDir -ErrorAction SilentlyContinue
$current = if ($resolved) { $resolved.Path } else { $null }

The replacement preserves identical null-safety behavior.

Audit

Performed a comprehensive scan of all 6 .ps1 files for PowerShell 7+ syntax features (?., ??, ??=, &&/|| pipeline chains, ternary operators, -Parallel, 7.0+ cmdlets). This was the only instance. The CI script (create-release-packages.ps1) intentionally requires 7.0 via #requires but only runs in GitHub Actions.

Fixes #1972

[Copilot]

Pull request overview

This PR restores Windows PowerShell 5.1 compatibility for spec-kit’s shared PowerShell helpers by removing the PowerShell 7+ null-conditional member access operator from common.ps1, fixing script execution failures reported in #1972.

Changes:

• Replaced ?.Path usage with a PowerShell 5.1-compatible null-safe pattern when resolving $StartDir.
• Preserved the prior behavior where an unresolved path yields $null.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.