Bug Description
Bug Description
On Windows PowerShell 5.1 (system ANSI = GBK/CP936), Save-FeatureJson writes .specify/feature.json as UTF-8 with no BOM, but Get-FeaturePathsEnv reads it with Get-Content -Raw (no -Encoding utf8).
Non-ASCII feature_directory values (e.g. Chinese specs/YYYY-MM-DD-主题/) are decoded as the system ANSI code page. /speckit.plan then runs setup-plan.ps1, which does New-Item -Force on that wrong path and creates a second directory whose name is mojibake (UTF-8 bytes interpreted as GBK).
The same common.ps1 already reads the preset .registry via [System.IO.File]::ReadAllText(..., UTF8). feature.json / integration.json do not.
This is not the same as:
Steps to Reproduce
- Windows 10/11, Windows PowerShell 5.1 (
powershell.exe, not pwsh). Locale whose ANSI code page is GBK (e.g. zh-CN).
specify init with --script ps.
/speckit.specify with a Chinese (or other non-ASCII) short name so .specify/feature.json contains e.g. "feature_directory":"specs/2026-08-26-后台信息架构" (UTF-8, no BOM). Confirm the real folder exists and contains spec.md.
- Run
/speckit.plan (agent runs .specify/scripts/powershell/setup-plan.ps1 -Json).
- Observe a sibling folder under
specs/ whose name is GBK mojibake of the same UTF-8 bytes (for 后台信息架构 this is 鍚庡彴淇℃伅鏋舵瀯). -Json stdout may also show a corrupted SPECS_DIR.
Expected Behavior
Path resolution uses the same UTF-8 as the writer. setup-plan.ps1 must not create a second directory.
Actual Behavior
Correct dir + garbled dir. Agents that trust SPECS_DIR from JSON may write plan artifacts into the garbled path.
Environment
- OS: Windows 10 19045, zh-CN
- Shell: Windows PowerShell 5.1
- Agent: Cursor
- Scripts: project-local
.specify/scripts/powershell/common.ps1 (Get-Content at Save-FeatureJson ~138 and Get-FeaturePathsEnv ~190; write at ~155–157)
Suggested fix (small)
Read feature.json the same way as .registry:
[System.IO.File]::ReadAllText($featureJson, [System.Text.Encoding]::UTF8)
### Steps to Reproduce
### Steps to Reproduce
1. Use **Windows 10/11** with a **GBK/CP936** ANSI code page (e.g. `zh-CN`). Use **Windows PowerShell 5.1** (`powershell.exe`), not PowerShell 7 (`pwsh`).
2. Initialize Spec Kit with PowerShell scripts (`specify init` with `--script ps` if you choose the script flavor).
3. Run `/speckit.specify` with a **non-ASCII** feature short name so the spec directory is like `specs/2026-08-26-后台信息架构/`. `.specify/feature.json` is UTF-8 **without BOM**, for example:
`{"feature_directory":"specs/2026-08-26-后台信息架构"}`
Confirm that this folder exists and contains `spec.md`. Opening `feature.json` in an editor that assumes UTF-8 shows the Chinese correctly.
4. From the repo root, run the same command `/speckit.plan` runs:
`.\.specify\scripts\powershell\setup-plan.ps1 -Json`
(Cursor/other agents capture this stdout as JSON and parse `SPECS_DIR`.)
5. List `specs/`.
Minimal isolation (same encoding bug, no agent) in Windows PowerShell 5.1:
$json = '{"feature_directory":"specs/2026-08-26-后台信息架构"}'
$utf8 = New-Object System.Text.UTF8Encoding $false
[System.IO.File]::WriteAllText("$pwd\.specify\feature.json", $json, $utf8)
Get-Content -LiteralPath .specify\feature.json -Raw
`Get-Content` prints mojibake (`鍚庡彴淇℃伅鏋舵瀯`) instead of `后台信息架构`. `setup-plan.ps1` then `New-Item -Force` that wrong path.
### Expected Behavior
### Expected Behavior
- `Get-FeaturePathsEnv` resolves `FEATURE_DIR` to the same Unicode path that `Save-FeatureJson` wrote, e.g. `…\specs\2026-08-26-后台信息架构`.
- `setup-plan.ps1` does **not** create another directory.
- `-Json` `SPECS_DIR` / `FEATURE_SPEC` / `IMPL_PLAN` match that real folder so the agent writes `plan.md`, `research.md`, `contracts/` there.
Only one folders appear under `specs/`:
- `specs/2026-08-26-后台信息架构/` — created by specify; has `spec.md`
### Actual Behavior
### Actual Behavior
Two folders appear under `specs/`:
- `specs/2026-08-26-后台信息架构/` — created by specify; has `spec.md`
- `specs/2026-08-26-鍚庡彴淇℃伅鏋舵瀯/` — created by `setup-plan.ps1` `New-Item -Force` after `Get-Content` decoded UTF-8 as GBK
`鍚庡彴淇℃伅鏋舵瀯` is the GBK reading of the UTF-8 bytes of `后台信息架构`.
`setup-plan.ps1 -Json` stdout often shows the garbled path in `SPECS_DIR` (console code page can corrupt it a second time). The agent then writes plan files into the wrong directory.
`pwsh` 7 on the same machine often does **not** reproduce the `Get-Content` mis-decode (default UTF-8 for BOM-less files). The bug is **Windows PowerShell 5.1 + UTF-8 no BOM + non-ASCII `feature_directory`**.
### Specify CLI Version
specify 1.0.2.dev0
### AI Agent
Alquimia AI
### Operating System
windows 10
### Python Version
Python 3.12.10
### Error Logs
```shell
Additional Context

Bug Description
Bug Description
On Windows PowerShell 5.1 (system ANSI = GBK/CP936),
Save-FeatureJsonwrites.specify/feature.jsonas UTF-8 with no BOM, butGet-FeaturePathsEnvreads it withGet-Content -Raw(no-Encoding utf8).Non-ASCII
feature_directoryvalues (e.g. Chinesespecs/YYYY-MM-DD-主题/) are decoded as the system ANSI code page./speckit.planthen runssetup-plan.ps1, which doesNew-Item -Forceon that wrong path and creates a second directory whose name is mojibake (UTF-8 bytes interpreted as GBK).The same
common.ps1already reads the preset.registryvia[System.IO.File]::ReadAllText(..., UTF8).feature.json/integration.jsondo not.This is not the same as:
gbkwhen reading extension YAML)Steps to Reproduce
powershell.exe, notpwsh). Locale whose ANSI code page is GBK (e.g. zh-CN).specify initwith--script ps./speckit.specifywith a Chinese (or other non-ASCII) short name so.specify/feature.jsoncontains e.g."feature_directory":"specs/2026-08-26-后台信息架构"(UTF-8, no BOM). Confirm the real folder exists and containsspec.md./speckit.plan(agent runs.specify/scripts/powershell/setup-plan.ps1 -Json).specs/whose name is GBK mojibake of the same UTF-8 bytes (for 后台信息架构 this is鍚庡彴淇℃伅鏋舵瀯).-Jsonstdout may also show a corruptedSPECS_DIR.Expected Behavior
Path resolution uses the same UTF-8 as the writer.
setup-plan.ps1must not create a second directory.Actual Behavior
Correct dir + garbled dir. Agents that trust
SPECS_DIRfrom JSON may write plan artifacts into the garbled path.Environment
.specify/scripts/powershell/common.ps1(Get-Content at Save-FeatureJson ~138 and Get-FeaturePathsEnv ~190; write at ~155–157)Suggested fix (small)
Read
feature.jsonthe same way as.registry:Additional Context