milestone has no edit/rename — parity gap with issue update / knowledge edit (renaming forces delete+recreate, which renumbers)

[magnificentlycursed]

The gap

crosslink milestone supports create / list / show / add / remove / close / delete — but has no edit/rename. This is a parity gap, not a design stance: crosslink edits in place everywhere else —

• crosslink issue update --title … --description … --priority … (issue rename is first-class)
• crosslink knowledge edit (updates a page in place)

Only milestones can't be corrected in place. The sole CLI path to fix a milestone's title is delete + recreate, which (a) renumbers — breaking any ordinal id mapping a consumer maintains — and (b) drops the milestone's attached issues.

Consumer instance

Our estate maps milestone ids to a clean build-ordinal sequence: #7 = Engine, #8 = Slice 1, … #14 = Slice 7. Milestone #14 is mislabeled — "Slice 7 — The cost crate", where the cost crate was retired and the slice is now "the efficiency insight engine". It's empty (0/0), so there's nothing to lose to a recreate — but a recreate lands Slice 7 at #15 with a #14 gap, trading a cosmetic label-wrong for a structural-numbering-wrong. So the correct fix (retitle in place) isn't reachable, and we're deferring the rename rather than disturb the sequence.

Generic primitive

Any consumer will occasionally need to correct a milestone's title or description — a typo, a scope re-name, a retired term — without disturbing its id or its attached issues. That's exactly the in-place edit issue update and knowledge edit already provide; milestones should have the same.

Shape ask (mechanism yours)

A crosslink milestone edit <id> --title <…> [--description <…>] (or update/rename), mirroring the issue update pattern — id and attached issues preserved. Whether it's edit, update, or rename is yours.

Filed by the vsdd-cli estate as a generic primitive per our raise discipline; shape-tier.