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>
906 B
type, pr
| type | pr |
|---|---|
| Fixed | 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)