The roadmap's shape after the split: in-tree records, issues, or both

[calef]

Lane: maintainer/roadmap-after-the-split, written by an agent; calef's account is the author GitHub shows.

One proposal, no code, no mechanism changed: design/roadmap/proposals/the-roadmap-after-the-split.md, answering calef's question of 2026-09-19 ("We have a lot of machinery now for managing milestones. We could use issues... How will we manage this when we break up the repo and build packages?").

The shape. The roadmap is three layers with different answers. The argument (441 blocks, 66,304 lines) and the status word (read by 21 scripts) must stay in a versioned tree, because no gate here touches the network and a tracker has no past to ask about an old revision. The scheduling layer already left the tree: DECISIONS §90 made a draft pull request the claim on 2026-08-16. So "we could use issues" is not a proposal about the roadmap.

The citation answer, which is the part calef asked for. Two measurements decide it:

• 128 of 207 cited milestone numbers are cited from two or more of kernel/, crates/ and components/ (65 of 85 § sections likewise). Per-repository numbering cuts across the citation graph rather than decomposing it.
• 465 of the 560 glossed citations already resolve against the target's own title, although nothing requires a gloss. The tree is 83% of the way to a split-proof convention by habit.

Five options on the identifier with no winner, because 3,148 sites in 288 Rust files follow it and §194 records what renumbering costs. A recommendation only on the reversible half: a ratchet requiring a gloss on citations a commit adds (which answers notes/citations.md' standing 2,911-site objection, since that is about a sweep), and FreeBSD's MOVED file (old name|new name|date|reason) as the redirect ledger every option needs.

Two corrections this page owes. §90 records that issues are disabled on this repository; gh repo view says they are enabled, and gh issue list is empty. The experiment is already available with zero uptake, which is evidence about demand rather than design. And this lane's first research pass reported that LLVM's Bugzilla RFC discussed preserving PRxxxxx numbers baked into source comments; fetching the page found no such discussion, so the claim is withdrawn in the text rather than quietly dropped.

Prior art read rather than recalled, with URLs and quotes in the file: Rust RFC, Go proposals, Kubernetes KEPs, Fuchsia RFCs, Python PEPs, Debian BTS, FreeBSD ports, Homebrew taps. All eight keep the durable record in a versioned tree; the ones that lean on a tracker use it for the number and the state.

Gates: script/lint 0, script/names 0, script/citations --check 0, script/roadmap --check 0. No QEMU, no script/test, no script/verify, no --write.

🤖 Generated with Claude Code

https://claude.ai/code/session_01STu3VeDYnEHem3iKCbzBF2

[calef]

What I need from you

Lane: maintainer/roadmap-after-the-split, written by an agent; calef's account is the author GitHub shows.

Answerable without reading the diff. Three asks, separated because only the first blocks anything.

1. Blocking nothing today, but it is the expensive one: what is a milestone citation's identity after the split? 3,148 milestone N sites in 288 Rust files follow the current convention. Five options are priced in the file; the measurement that shapes them is that 128 of 207 cited milestones are cited from two or more of kernel/, crates/ and components/, so per-repository numbering does not decompose the citation graph. If you say nothing, the default is option E (one roadmap forever in basalt), which is the status quo and re-creates the single global namespace §151 exists to remove. Nothing breaks until the split, which is why this is a proposal and not a held merge.

2. Cheap and reversible, and it makes (1) cheaper the longer it waits: may a lane build a script/lint ratchet that requires a gloss on a milestone N or §N appearing on a line the commit adds? notes/citations.md argues against requiring glosses, and that argument is about a sweep of 2,911 sites, every one needing to be read. A ratchet reads nothing retroactively. If you say no, the tree stays at 83% glossed and drifts with whoever remembers; every option in (1) stays as expensive as it is today instead of converging.

3. Eventually yours, not blocking: do you want GitHub Issues used for the two things a tree cannot do (a stranger's bug on a released basalt artifact; a work item spanning two repositories)? They are enabled and empty right now, so this costs nothing to try and nothing to refuse. §90's argument against a second place for truth is about the same fact in two places, and neither of these facts is in the tree at all.

Not asked: whether the roadmap moves to issues. The file recommends against it and the prior art is unanimous (all eight projects checked keep the durable record in a versioned tree), so it is a finding rather than a fork.

🤖 Generated with Claude Code

https://claude.ai/code/session_01STu3VeDYnEHem3iKCbzBF2