docs(tracker): the milestone naming this template teaches truncates on the card

forgejo-issue.py warns that a milestone title starting with a version token has
everything after it dropped from the dashboard phase -- `0.2 Payments` displays
as `0.2`. README.md was teaching exactly that form, and two adopted repos
followed it: Closer-Couples and fruit-fall both carry version-first titles and
lose their batch names on the card. PrivacyLLC-Web uses `Batch 05 — ...` and
displays whole.

The guidance now names the working form, and carries the comma rule the script
also enforces: a comma breaks the `milestones=` filter and the card shows the
wrong next action.

WORK_CYCLE.md gains the trap the same script documents and no document did: the
dashboard's next action is the NEWEST open issue in the current milestone, not
the most severe -- severity labels have no influence at all. Filing a routine P2
into the active batch silently replaces what the project card shows.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
null 2026-08-17 22:49:23 -05:00
parent 912c470bbb
commit 8b2e4121dd
2 changed files with 16 additions and 3 deletions

View File

@ -191,9 +191,14 @@ nothing.
### The rules ### The rules
- **Milestone = batch.** Name it `0.2 Payments`. The description says what the - **Milestone = batch.** Name it `Batch 02 — Payments`, and **start it with a
batch is for and how anybody will know it landed. A due date means a word rather than a version number**: the dashboard reads a leading version
commitment — leave it empty rather than inventing one. token as the whole phase and drops the rest, so `0.2 Payments` displays as
`0.2` and the batch loses its name on the project card. No comma either — a
comma breaks the `milestones=` filter and the card shows the wrong next
action. The description says what the batch is for and how anybody will know
it landed. A due date means a commitment — leave it empty rather than
inventing one.
- **Issue = deliverable.** One per item, in its milestone, ending with a - **Issue = deliverable.** One per item, in its milestone, ending with a
`Verify:` line stating the acceptance check. `Verify:` line stating the acceptance check.
- **Labels:** `P0` ships broken or loses data · `P1` materially wrong but - **Labels:** `P0` ships broken or loses data · `P1` materially wrong but

View File

@ -76,6 +76,14 @@ Monday, specific enough to begin without asking a question. "Continue the work"
is not one. If the honest answer is that you do not know, that is a real answer — is not one. If the honest answer is that you do not know, that is a real answer —
say what has to be decided and by whom. say what has to be decided and by whom.
**Filing an issue can change what the project card says next, without anyone
choosing that.** The dashboard's next action is the *newest open issue in the
current milestone* — not the most severe one; severity labels have no influence
on it at all. So a routine `P2` filed into the batch you are working in replaces
whatever the card was showing, and it will keep showing that until something
newer arrives. The `nextAction` field is the only way to say something different
on purpose, which is most of why step 7 exists.
`currentSummary`, `nextAction` and `description` are **write-only**: they are `currentSummary`, `nextAction` and `description` are **write-only**: they are
deliberately absent from every API response, because free text can name a deliberately absent from every API response, because free text can name a
customer or an unannounced product. Only the admin screen shows them back. Never customer or an unannounced product. Only the admin screen shows them back. Never