Separate milestones from triage in the contributing guide

.claude/specs/contributing-guide/design.md

@@ -14,7 +14,7 @@ flowchart LR
     TC -->|a form| I["Issue<br/>label triage, Issue_Type set"]
     TC -->|question or idea| D["Discussions<br/>Q&A, Ideas"]
     TC -->|vulnerability| S["Report a vulnerability<br/>security policy page"]
-    I --> T["Weekly triage<br/>type confirmed, priority and areas or question,<br/>milestone or not planned, triage removed"]
+    I --> T["Weekly triage<br/>type confirmed, priority and areas or question,<br/>kept or not planned, milestone only when a goal has one, triage removed"]
     T --> B["Branch n-short-slug"]
     B --> PR["/freethinking:pr<br/>ticket #n in the title and Why,<br/>Closes #n when the merge finishes it"]
     PT["PR_Template<br/>.github/pull_request_template.md"] -.used by.-> PR

.claude/specs/contributing-guide/requirements.md

@@ -48,7 +48,7 @@ The contributing guide is the one document that tells a contributor how to devel
 2. WHEN an Issue_Form is submitted, THE repository SHALL apply the Triage_Label and set the Issue_Type through the form's own settings, `Bug` for a misbehaving skill or agent, `Feature` for a proposal and `Task` for a new eval case, and SHALL apply no Area_Label, since the area is a triage decision.
 3. THE Issue_Form SHALL mark every field a Maintainer cannot triage without as required, and SHALL use a dropdown or checkboxes wherever the answer set is known, so that an incomplete or free-form report cannot be submitted.
 4. THE Template_Chooser SHALL disable blank issues and SHALL offer three links: questions to Discussions Q&A, ideas to Discussions Ideas, and security reports to the repository's security policy page, which shows `SECURITY.md` with GitHub's Report a vulnerability button, so that a report started in the wrong place still lands in the right one.
-5. THE Guide SHALL define triage as: at least weekly, a Maintainer reviews every issue carrying the Triage_Label, confirms or corrects its Issue_Type, sets one Priority_Label and the Area_Labels that apply, none, one or both, applies the Info_Label instead when the issue cannot be classified without more from its author, assigns a Milestone or closes the issue as not planned, and removes the Triage_Label.
+5. THE Guide SHALL define triage as: at least weekly, a Maintainer reviews every issue carrying the Triage_Label, confirms or corrects its Issue_Type, sets one Priority_Label and the Area_Labels that apply, none, one or both, applies the Info_Label instead when the issue cannot be classified without more from its author, closes the issue as not planned or keeps it, puts a kept issue into a Milestone only when it serves a goal that already has one and otherwise leaves it in the backlog, and removes the Triage_Label.
 6. IF an issue is opened without an Issue_Form, THEN THE Guide SHALL say that a Maintainer applies the Triage_Label by hand at the next triage, so that no issue escapes classification.
 
 ### Requirement 3: Labels and milestones
@@ -59,7 +59,7 @@ The contributing guide is the one document that tells a contributor how to devel
 
 1. THE repository SHALL carry exactly nine labels: the three Priority_Labels, the Area_Labels `quality` and `compatibility`, the Triage_Label, the Info_Label, `good first issue` and `help wanted`; every other label SHALL be removed: GitHub's `bug`, `enhancement` and `documentation` because the Issue_Types carry kind, `duplicate`, `invalid` and `wontfix` because close reasons cover them, and the `effort:` and `area:` labels created earlier, whose values move into this set.
 2. THE Guide SHALL say that every issue has one Issue_Type, SHALL define each label group in one sentence, and SHALL say that an issue carries at most one Priority_Label and the Area_Labels that apply, so that an issue with no Area_Label is normal.
-3. THE Guide SHALL say that a Milestone names a goal and that the open Milestones are the repository's roadmap.
+3. THE Guide SHALL say that a Milestone names a goal, that the open Milestones are the repository's roadmap, and that Milestones are made in a planning pass separate from triage, pulling issues in from the backlog.
 4. IF a label or an Area_Label outside these seems needed, THEN THE Guide SHALL say to propose it in an issue rather than create it, so that the vocabulary stays small.
 5. THE Guide SHALL say that `good first issue` is the one label with behaviour on GitHub, feeding the repository's contribute page and GitHub's surfacing of approachable issues, and that `help wanted` marks work a Maintainer would merge but will not write.
 6. THE label names SHALL be lowercase throughout, in the repository, the Guide and the Issue_Forms, and the Issue_Types SHALL be written as GitHub names them, `Bug`, `Feature` and `Task`, in the forms' `type` keys and in the Guide.

.github/CONTRIBUTING.md

@@ -78,7 +78,9 @@ At least weekly, a maintainer triages:
 3. Sets one priority label and the area labels that apply, none, one or both.
 4. Applies `question` instead when the issue cannot be classified without more
    from its author.
-5. Assigns a milestone, or closes the issue as not planned.
+5. Closes the issue as not planned, or keeps it. A kept issue goes into a
+   milestone only when it serves a goal that already has one; otherwise it
+   waits in the backlog, the open issues with no milestone.
 6. Removes `triage`.
 
 An issue opened without a form gets `triage` by hand at the next triage. A
@@ -107,7 +109,9 @@ in an issue rather than create it.
 repository's contribute page and GitHub's surfacing of approachable issues.
 `help wanted` marks work a maintainer would merge but will not write.
 
-A milestone names a goal. The open milestones are the roadmap.
+A milestone names a goal. The open milestones are the roadmap. Milestones
+are made in a planning pass, separate from triage: when a goal is chosen, it
+gets a milestone and the issues that serve it are pulled in from the backlog.
 
 ## Compatibility