Add planning-cldk-work: the mode upstream of design

[rahlk]

Adds planning-cldk-work, a new mode upstream of design mode, for work that cannot yet be stated as a single contract decision. Also syncs two out-of-sync doc blocks and adds a CHANGELOG that declares 0.3.0's undeclared breaking change.

Motivation and Context

Every routing row in the ladder was singular — "New language", "a language", "a facade surface" — and assumed the change had already been chosen. sprint, prioriti*, capacity, portfolio appear zero times across the skills. A team shaping a quarter, or anyone holding a theme like "microservice static analysis", had no entry point and would run design mode repeatedly, producing N unrelated specs with nothing expressing order, dependency, or deliberate exclusion.

The entry test is "can this be stated as a single contract decision?" — not a count of features named, which gets both directions wrong:

• Go L3/L4 is two levels of one decision on one repo. Order is forced, nothing to exclude. → design mode.
• "Microservice static analysis" is one theme containing boundary-edge vocabulary, service topology, per-framework entrypoints and cross-service reachability — which compete for order and can be deferred. → planning mode.

The mode earns its place through the contract-collision sweep: microservice analysis and polyglot analysis both need boundary-edge vocabulary (http/rpc/queue), so that is ONE design decision. Designed separately they produce two vocabularies for one concept, and the parity clause forbids renaming either afterwards. Nothing else in the ladder can see this — every other mode is single-change scoped.

Output is a committed roadmap plus an epic for the one decision actually starting. Not one epic per candidate: that is the July issue flood with a nicer name.

How Has This Been Tested?

Not tested by execution. This is the honest answer and worth stating plainly:

• tests/scenarios/planning-cldk-work/s1–s3 are scenario specifications — prose describing what a subagent run should conclude. They were written alongside the skill and have not been run.
• tests/consistency/check-readme-dispatcher-sync.sh was run and now passes. It failed on first run against this branch, catching two real defects (below) that would otherwise have shipped.
• No dry-run subagent walk was performed against the new mode, so its entry preconditions are unvalidated in practice. Entry preconditions have historically been this plugin's weak point.

Breaking Changes

No for this PR — planning-cldk-work is additive, and the dispatcher gains a routing row without altering any existing route.

Yes for 0.3.0, which this PR documents for the first time in the new CHANGELOG.md. That release changed <HARD-GATE> semantics, removed two Red Flags rows forbidding smaller tracking shapes, moved epics to codellm-devkit/.github, retired Part of #N trailers and CHILDREN checklists in favour of sub-issues, relocated specs to docs/design/, and made every ladder transition stop for the user. #34's body never filled in this section, so it went undeclared.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the Codellm-Devkit Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally — consistency check passes; scenario specs are not executable and were not run
• I have added appropriate error handling — n/a for skill content; entry preconditions and scope guard serve this role
• I have added or updated documentation as needed

Additional context

Also in this PR

check-readme-dispatcher-sync.sh failed on first run, on two blocks:

1. The dispatcher's ladder diagram still read "spec + GitHub epic" after 0.3.0 renamed it to "spec + tracking record" — stale since Make issue decomposition proportional and user-decided #34 merged, which this check would have caught at the time had it been run.
2. The README's routing row for the new mode disagreed word-for-word with the dispatcher's.

Both fixed; the check passes.

Design decisions worth reviewing

• The dispatcher routes here automatically. A judgement call, easily reversed by deleting one routing row. Made so a new user discovers the mode; the entry test and two scope-guard red flags carry the load against false firing.
• One living roadmap, amended in place rather than one per quarter — git history becomes the record of how thinking changed. The alternative is dated roadmaps; this one can't drift into six stale files.
• Throughput/capacity checking was deliberately cut. The mode reasons about contracts, dependencies and release trains — not estimation or velocity. The scope guard also states it records and challenges rather than facilitating, since a planning session between people is a meeting an agent cannot run.

Known gaps

• The entry test leans on an agent correctly judging "one contract decision", which is a judgement, not a mechanical check.
• The collision sweep only works if themes are decomposed to decision altitude first — a theme left as one roadmap row makes the collision invisible. This is a red flag and an S1 failure condition, but nothing enforces it.
• This PR has no tracking issue, which the conventions it extends would require. Filing one retroactively would be the "write it up after it ships" pattern its own red-flag table calls out; the next plugin change gets a work item first.