fix(scripts): honor explicit -Number 0 in PowerShell create-new-feature (parity with bash)

[jawwad-ali]

Description

create-new-feature.ps1 could not honor an explicit -Number 0. The parameter used [long]$Number = 0 as both the default and the auto-detect sentinel:

if ($Number -eq 0) { $Number = (Get-HighestNumberFromSpecs ...) + 1 }

So -Number 0 was indistinguishable from not supplied and silently auto-incremented. The bash twin keys off whether the value is non-empty ([ -z "$BRANCH_NUMBER" ]), so --number 0 is honored and yields FEATURE_NUM=000.

Result — identical input, different output across platforms:

input	bash	PowerShell (before)
--number 0	000-feature	001-feature (auto)

Fix

Use $PSBoundParameters.ContainsKey('Number') to detect whether -Number was actually supplied, so an explicit value (including 0) is honored and only a missing -Number auto-detects — mirroring bash's empty-check. This also aligns the -Timestamp+-Number warning, which bash emits for --number 0 --timestamp (non-empty check) but PowerShell previously skipped.

Testing

• uvx ruff check clean; tests/test_ps1_encoding.py green (edited .ps1 stays ASCII / PowerShell 5.1-safe).
• New regression tests:
  • TestSequentialBranch::test_explicit_number_zero_is_honored (bash) — pins the canonical --number 0 -> 000 behavior.
  • TestSequentialBranchPowerShell::test_explicit_number_zero_is_honored_matching_bash — fails before this change (PS auto-detected), passes after.
• Verified end-to-end with Windows PowerShell 5.1: -Number 0 -> 000-zero (even with specs/003-* present), -Number 5 -> 005-zero, and no -Number still auto-detects (004-zero with specs/003-*). bash confirmed --number 0 -> 000-zero.

AI Disclosure

• I did use AI assistance (describe below)

Found and fixed with Claude Code (Claude Opus 4.8) under my direction. AI located the default-vs-sentinel ambiguity across the bash/PowerShell twins and drafted the ContainsKey fix plus regression tests; I reproduced the differing FEATURE_NUM under Windows PowerShell 5.1 and bash, confirmed auto-detect and explicit non-zero paths are unchanged, and reviewed the diff before submitting.

[jawwad-ali]

Note for reviewers: #2036 (open since March, currently conflicting + changes-requested) proposes a broader change to validate --number against existing branches/specs. This PR is intentionally orthogonal and minimal — it only fixes the PowerShell↔bash divergence where an explicit -Number 0 is silently ignored. Happy to coordinate/rebase if #2036 is revived, but the parity fix here stands on its own.

[Copilot]

Pull request overview

This pull request fixes a cross-platform parity bug in the PowerShell create-new-feature.ps1 script where an explicitly provided -Number 0 was previously indistinguishable from “not supplied,” causing unintended auto-detection. It updates the PowerShell logic to detect whether -Number was actually passed, matching the bash script’s behavior, and adds regression tests to lock in the 0 -> 000-* outcome.

Changes:

• Update PowerShell create-new-feature.ps1 to use $PSBoundParameters.ContainsKey('Number') so an explicit -Number 0 is honored and only an omitted -Number triggers auto-detect.
• Align the -Timestamp + -Number warning behavior so that -Number 0 is also treated as “provided” (and therefore warned/ignored), matching bash.
• Add bash + PowerShell regression tests validating --number/-Number 0 produces FEATURE_NUM=000 and BRANCH_NAME=000-… even when higher-numbered specs exist.

Show a summary per file

File	Description
tests/test_timestamp_branches.py	Adds regression tests pinning the canonical number=0 -> 000-* behavior in bash and ensuring PowerShell matches it.
scripts/powershell/create-new-feature.ps1	Fixes the default-vs-sentinel ambiguity by detecting whether -Number was actually supplied via PSBoundParameters.

Review details

Tip

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

• Files reviewed: 2/2 changed files
• Comments generated: 0
• Review effort level: Low

[mnriem]

Thank you!