8616839cab
CHANGELOG promotion was a manual operator step that was never run, so 463 fragments for work already shipped in <=1.3.1 accumulated in .changeset/. Their notes were already hand-curated into the dated [1.2.0]/[1.3.0]/[1.3.1] CHANGELOG sections (#690 backfill, PR #694). Rendering them now would duplicate and mis-attribute shipped work. Move them to .changeset/archived/ (read non-recursively by all changeset tooling, so never rendered), keeping only the 3 genuinely-unreleased fragments at the top level. Prep for wiring `render` into the release finalize job (#690 follow-up). Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
6 lines
906 B
Markdown
6 lines
906 B
Markdown
---
|
|
type: Fixed
|
|
pr: 3527
|
|
---
|
|
**Top-level `branching_strategy` in `.planning/config.json` no longer triggers a false "unknown config key" warning** — `loadConfig` in `core.cjs` actively read the key via its nested fallback (`git.branching_strategy`) but the `KNOWN_TOP_LEVEL` allowlist was built from dot-notation paths via `.split('.')[0]`, turning `'git.branching_strategy'` into `'git'` instead of `'branching_strategy'`. The fix adds a self-healing on-disk migration (mirroring the existing `multiRepo → planning.sub_repos` precedent): on first `loadConfig`, the top-level key is grafted into `git.branching_strategy` and the stale top-level entry is removed. A module-level deduplication Set also prevents the same unknown-key warning from appearing twice when `loadConfig` is invoked multiple times in a single CLI call. A contract test asserts CJS and SDK agree on legacy-shape fixtures. (#3523)
|