chore(ci): cap effort/XL at 2500 readable lines and add effort/XXL

[Astro-Han]

Summary

effort/XL has no upper bound. Measured with the label's own readable-line rule (lockfiles, generated files and binaries excluded), it currently holds 75 of the last 300 merged pull requests and 57 of the 157 open ones, ranging from 1000 to over 10000 lines under one label. That is the largest tier by count and the only one whose members are handled differently from each other: up to roughly 2500 lines a change is still read as one unit; past that, the first review question is whether it splits.

This caps effort/XL at 2500 readable lines and adds effort/XXL above it. On the same data the split is 45 XL / 30 XXL for merged and 31 / 26 for open, so both halves stay populated. Nothing else in the ladder moves.

Refs #3949

Verification

• node --test --test-concurrency=1 scripts/pr-effort.test.mjs: 13 pass, including the new 2500 / 2501 boundary cases
• biome check on both files: clean

Not run: the labeling workflow itself. It reads scripts/pr-effort.mjs from main on pull_request_target, so this branch cannot exercise it before merge.

Rollout

The effort/XXL label needs to exist in the repository before the workflow first assigns it, and the effort/XL description should read "Under 2500 readable lines". I will create and update the labels when this merges; the next scheduled or triggered run then relabels the open pull requests above 2500.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code measured the current tier distribution, made the change and wrote the tests. The commit carries a Generated-by: Claude Code trailer.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes: pull requests above 2500 readable lines receive effort/XXL instead of effort/XL
• No

[jackwener]

Approving at exact head 9df51531c21b6c95973202d015e4997e1dd121dc. No findings.

The tier change is mechanical and the boundaries are right: maxLines is an inclusive upper bound, so 2500 lands on effort/XL and 2501 on effort/XXL, and the new cases pin exactly that pair.

Worth naming, because it is the line that would have caused a real bug if it had been left out: adding effort/XXL to EFFORT_LABELS is not bookkeeping. That array drives removeLabels at pr-effort.mjs:88 — it is how the previous tier's label gets cleared when a pull request moves. Without it, a PR that shrank from XXL to XL would keep both labels, and the new top tier would be the one tier that never comes off. It is there, so this works.

On the rollout note: creating the label first is worth doing for its colour and description, but the workflow does not depend on it. github.rest.issues.addLabels creates a missing label on use, so a run that lands before the manual step will apply effort/XXL with GitHub's default styling rather than failing.

label and test are green on this head.

Evidence boundary: the labeling workflow reads pr-effort.mjs from main on pull_request_target and cannot be exercised from this branch, so its end-to-end behaviour here rests on reading the workflow and the documented API, not on a run. The distribution figures in the description (75 of 300 merged, 57 of 157 open, and the resulting splits) are the author's; I did not recompute them.

简体中文

在 9df51531c21b6c95973202d015e4997e1dd121dc 上批准。没有发现。

分档改动是机械的,边界也是对的:maxLines 是包含式上界,所以 2500 落在 effort/XL、2501 落在 effort/XXL,新增的用例钉的正是这一对。

有一处值得点名,因为它要是漏了就会造成真实缺陷:把 effort/XXL 加进 EFFORT_LABELS 并不是登记流水账。那个数组驱动着 pr-effort.mjs:88 的 removeLabels——PR 换档时,上一档的标签正是靠它被清掉的。如果漏了这一行,一个从 XXL 缩小到 XL 的 PR 会同时挂着两个标签,而新的最高档会成为唯一永远摘不掉的那一档。这一行在,所以是好的。

关于 rollout 那条说明:先建标签值得做,是为了它的颜色和描述,但工作流并不依赖它。github.rest.issues.addLabels 在使用时会创建缺失的标签,所以即使某次运行赶在手动步骤之前,它也只是用 GitHub 的默认样式打上 effort/XXL,而不会失败。

这个 head 上 label 和 test 都是绿的。

证据边界:打标签的工作流在 pull_request_target 上从 main 读取 pr-effort.mjs,无法从本分支触发,所以这里对它端到端行为的判断依据的是阅读工作流与 API 文档,而不是一次实际运行。描述中的分布数字(近 300 个已合并里的 75 个、157 个开启中的 57 个,以及拆分后的结果)是作者的,我没有重算。

---

Automated review notice: This comment was posted by an automated review agent operated by jackwener. It is not an independent human review and does not replace one.