Repository navigation
Conversation
common.ps1 passed project, preset and extension paths to Test-Path and Get-ChildItem through -Path, which reads [ and ] as wildcards. In a project whose path contains brackets, resolve-template, setup-plan, setup-tasks and check-prerequisites exited 1 while the Bash and Python scripts succeeded. A preset manifest whose declared file name has brackets was skipped, so the stock template was used instead. Use -LiteralPath, as github#4956 and github#4970 did for feature paths. Assisted-by: Codex CLI (model: gpt-6.1-sol, autonomous) Assisted-by: Claude Code (model: claude-opus-5-5, autonomous)
There was a problem hiding this comment.
🟡 Changes recommended
The parity test incorrectly compares Git Bash MSYS paths with native Windows paths, causing successful Bash invocations to fail assertions before PowerShell is tested.
1 open issue
What changed in this PR
Extends the earlier bracketed-feature-path fixes to project roots and preset templates, keeping PowerShell helpers aligned with Bash and Python.
Changes:
- Uses literal paths for feature state, template lookup, directory enumeration, and temporary-file cleanup.
- Adds template-resolution parity tests across override, preset, extension, and core layers.
- Adds task-setup regressions covering feature selection and preservation of existing files.
| File | Description |
|---|---|
tests/test_setup_tasks_python_parity.py |
Tests bracketed project paths, template selection, and file preservation. |
tests/test_resolve_template_python_parity.py |
Tests bracketed project and manifest paths, missing templates, and missing Python. |
scripts/powershell/common.ps1 |
Replaces wildcard-aware path operations with literal-path operations. |
Review effort: Balanced (auto)
Git Bash on Windows can print MSYS paths such as /c/Users/... for FEATURE_DIR and TASKS_TEMPLATE, which never equal the native paths the test built. For the Bash run, also accept the form _bash_posix_path() gives; Python and PowerShell output is still compared with the native path. Assisted-by: Claude Code (model: claude-opus-5-5, autonomous)
|
Round 1 (27247ff): Copilot's Git Bash path finding in
Drafted on behalf of @kartsan03 by Claude Code (model: claude-opus-5-5, autonomous). |
There was a problem hiding this comment.
🔵 Needs a closer look
Required Windows PowerShell 5.1 compatibility evidence is missing, so a maintainer needs to validate the affected bracketed-path success and failure cases on that runtime.
No open issues 🎉
1 resolved since last review
Review effort: Balanced (auto)
requires_bash skipped each whole test, PowerShell and Python runs included, wherever bash isn't detected. That covers windows-latest, where the WSL launcher is rejected, so the PowerShell fix had no Windows coverage. Run Python and PowerShell always, and Bash when tests/conftest.py's new HAS_BASH says it works. Assisted-by: Claude Code (model: claude-opus-5-5, autonomous)
… test The manifest cases make the Bash and PowerShell resolvers parse preset.yml with Python. On a Windows runner, PowerShell picked an ambient python3.exe without PyYAML and failed with yaml_missing. Set SPECKIT_PYTHON_EXECUTABLE to the test interpreter, as test_resolve_template_python_parity.py already does elsewhere. Assisted-by: Claude Code (model: claude-opus-5-5, autonomous)
|
Round 2 (d4ad7fd): Copilot's last pass asked for Windows PowerShell 5.1 evidence. I ran the 28 new cases with Windows PowerShell 5.1.26100 on a windows-latest runner in my fork: all pass on this branch, and 27 fail with The run needed two test changes, now pushed here:
Full suite on Linux with PowerShell 7.6.9 on PATH: 16580 passed, 252 skipped, plus the one failure that also fails on Drafted on behalf of @kartsan03 by Claude Code (model: claude-opus-5-5, autonomous). |
Description
In a project whose path contains
[or], the PowerShell helpers behind/speckit.specify,/speckit.plan,/speckit.tasksand the commands that callcheck-prerequisitesall exit 1, while the Bash and Python helpers work.scripts/powershell/common.ps1passes the project's paths toTest-PathandGet-ChildItemwith-Path, which reads brackets as wildcards. So.specify/feature.json, the template directories and the preset registry all look missing. #4956 and #4970 fixed this for bracketed feature directories. This PR does the same for the project root and the template stack.The same problem also hits a preset whose manifest declares a template file with brackets in its name (
file: templates/custom [v1].md), even when the project path has none.resolve-template.ps1skips that file and returns the stock template, and/speckit.specifywrites it tospec.md.The fix switches those calls to
-LiteralPathinGet-FeaturePathsEnv,Get-SortedExtensionIds,Resolve-TemplateandResolve-TemplateContent, along with the cleanup of the temporary stderr file inResolve-TemplateContent. The Bash and Python helpers already handle these paths and are unchanged.Repro with the real CLI: inside a directory named
work [2026], runspecify init demo --integration codex --script ps --ignore-agent-tools --non-interactive, addspecs/001-demo/spec.md, and point.specify/feature.jsonatspecs/001-demo. Then, from the project root:main(979b0a3)resolve-template.ps1 spec-template -JsonERROR: Could not resolve required spec-template from the template override stack for …setup-plan.ps1 -JsonERROR: Feature directory not found. Set SPECIFY_FEATURE_DIRECTORY or run the specify command to create .specify/feature.json.check-prerequisites.ps1 -Jsonsetup-tasks.ps1 -Json(after addingplan.md)Testing
uv run specify --helpuv sync && uv run pytestNew parity tests run the Python and PowerShell helpers on the same project, plus Bash where
tests/conftest.pyfinds a working one, and compare the results. They check the newHAS_BASHflag (the probe behindrequires_bash) instead of usingrequires_bash, which would skip them on windows-latest, PowerShell runs included:test_all_variants_resolve_templates_in_bracketed_project(tests/test_resolve_template_python_parity.py): a project underproject [v1], once for each template layer (core, override, preset with and without a registry, flat preset and extension layouts, preset manifest, missing template). One more case puts the bracketed manifest file name in a plain project path. The manifest cases parsepreset.ymlwith Python, so the test setsSPECKIT_PYTHON_EXECUTABLEto the test interpreter.test_powershell_bracketed_manifest_reports_missing_python: in a bracketed project, the PowerShell resolver still finds the preset manifest and asks for Python when none is on PATH.test_all_variants_setup_tasks_in_bracketed_project(tests/test_setup_tasks_python_parity.py): the feature comes from.specify/feature.jsonor fromSPECIFY_FEATURE_DIRECTORY. The test checksFEATURE_DIR,TASKS_TEMPLATEand its content, and that the existingspec.md,plan.mdandtasks.mdare left byte for byte as they were.With
common.ps1frommain, 27 of the 28 new cases fail. The missing-template case passes on both. The same holds on Windows PowerShell 5.1.26100, run on a windows-latest runner in my fork (run): 28 pass on this branch, and 27 fail withcommon.ps1frommain.Full suite on Linux, Python 3.13 (
pytest -n 3, 12 min, with the venv andpwshon PATH): 16580 passed, 252 skipped, 1 failed. The failure,test_version_execution.py::TestWindowsUvToolEnvironment::test_non_windows_uv_tool_dry_run_still_previews_installer, fails the same way onmainhere: Rich wraps the dry-run output and splits my checkout's long venv path. Ruff 0.15.0 (ruff check src tests) passes. PowerShell 7.6.9 on Linux, and Windows PowerShell 5.1 as above. I haven't run the full suite on Windows.AI Disclosure
AI disclosure: Codex CLI (model: gpt-6.1-sol, reasoning effort xhigh, autonomous, offline sandbox) found the failures by running the same inputs through the Bash, PowerShell and Python helpers, and wrote the fix and tests. Claude Code (model: claude-opus-5-5, autonomous) also made the temporary-file cleanup literal, reran the repro with the real CLI on
mainand the branch, ran the full suite and lint, and drafted this description. The commit carriesAssisted-by:trailers for both.