功能许愿池运营 SOP
许愿池的对外页面在 docs/zhHans/guide/light-weight-work/feature-wishlist/。本文是内部运营流程。
机制前提
站点的 giscus 评论挂在 doc-after 插槽上全站生效，映射方式是 pathname，评论仓库是 atomeocean/logbook-comment 的 Announcements 分类。
这意味着一个页面对应一条 GitHub Discussion，主楼的 👍 数就是该页面对应功能的票数。整套许愿池就建立在这一条上，下面所有规则都是它的推论。
两个门槛（对外硬承诺）
| 门槛 | 计票对象 | 达成后必须做什么 |
|---|---|---|
| 7 票 | submit-idea.md 评论区里某一条提议评论自身的 👍 | 建成 candidates/<slug>.md，加入总览清单，开放投票 |
| 19 票 | 候选功能页面主楼的 👍 | 状态改为「已排期」 |
这两个数字已经公开写在对外页面上，是承诺而不是参考值。相应的约束：
- 满票必须执行，不能因为实现成本高而搁置。 如果一个满 19 票的功能确实做不了，走「暂不做」并在该功能页面公开写出原因，不允许让它无声地停在「已排期」或「投票中」。
- 票数不结转。 提议阶段的 7 票不带进候选阶段的 19 票，新页面从 0 开始。建页时必须在原提议评论下回复新页面链接，并提示投过票的人重新投一次，否则等于把已有支持者丢掉。
- 门槛是下限不是唯一入口。 影响面明显或有合规要求的需求，可以不等满票直接建页或直接排期。
- 内部账号一律不投票，两个门槛只统计客户的票。内部只在候选页面发首楼评论、在提议评论下回复。
- 提议人自己的 👍 计入那 7 票，这一条已对外公开，不要另立标准。
计票口径
- 只数 👍，其他表情不计入任何门槛。
- 一个 GitHub 账号在一个计票对象上只算一票，取消点赞则票数减少——门槛按当前实时票数判断，不按历史峰值。一条提议曾经到过 7 票又掉回 6 票，在还没建页的情况下不触发升级。
- 候选功能页面只认主楼，楼下回复的 👍 不计票。
submit-idea.md的主楼是内部说明帖，它自身的 👍 不代表支持任何具体提议，不计入任何门槛。
定期分诊
按周查看提一个新需求页面的评论区。对每条新评论选一个处理路径，并在该评论下回复结果，不要静默处理：
| 情况 | 处理 |
|---|---|
| 该提议评论已满 7 票 | 必须建候选页面，回复新页面链接并提示重新投票 |
| 未满 7 票但影响面明显或有合规要求 | 可以提前建候选页面，同样回复链接 |
| 未满 7 票且无特殊理由 | 不动，留在评论区继续累积票数，不要删除 |
| 与已有候选重复 | 回复已有候选的链接，请对方去那里投票 |
| 是故障或个人事务 | 回复引导到工单系统 |
| 描述不足以判断 | 回复追问缺失的信息，等补充后再分诊 |
| 明确不做 | 回复原因，同时在已上线与已关闭登记 |
建一个候选功能页面
- 复制
candidates/_template.md到candidates/<slug>.md。slug 用 kebab-case、动宾结构、不带日期，例如payroll-pdf-export。 - 填写 frontmatter 与正文各节。
order控制侧边栏顺序，默认 50，需要置顶的候选调小。 - 保留
tags: [功能许愿池]，专题页聚合依赖这个标签。 - 在
index.md的候选功能表格加一行：功能名（链接到新页面）、一句话说明、当前状态。 - 合并上线。
上线后必须「开池」
候选页面上线后，必须由内部人在该页面评论区发一条首楼评论，例如「本候选功能已开放投票，支持请给本楼点 👍」。
原因：giscus 只在第一次有人互动时才创建对应的 Discussion，而主楼的 👍 按钮在 Discussion 不存在时根本不会渲染。不发这条首楼评论，客户打开页面看不到任何投票入口，只能看到一个空评论框。
状态流转
正文第二行的 **当前状态：xxx** 是唯一的状态来源。改状态时同步做三件事：改候选页面这一行、改 index.md 表格对应那一列、在候选页面的「进展记录」表格加一行。
状态取值只用这五个：投票中、已排期、开发中、已上线、暂不做。
「投票中 → 已排期」这一步由 19 票门槛触发，看到满票就改，不需要额外审批。改状态时在「进展记录」里记明达成日期和当时票数。
进入「已上线」或「暂不做」时，从 index.md 的候选表格移除该行，改为在 shipped.md 对应的表格登记，候选页面本身保留不删。
禁止事项
- 不要改已发布候选页面的文件名或目录位置。 pathname 是 Discussion 的映射键，改路径等于换成一条新的空 Discussion，已有票数和讨论全部变成孤儿。slug 一次定死。
- 不要把候选页面镜像到
docs/en/。/en/...是另一个 pathname，会开出第二条 Discussion 把票数分流到两处。需要英文就在同一个页面里写双语。 - 不要给
index.md、how-to-vote.md、shipped.md打开评论。 这三个页面的 frontmatter 里有comment: false，目的是把提需求的流量全部收敛到submit-idea.md，不要形成第二个入口。 - 不要用内部账号给候选功能投票。 首楼评论由内部发，👍 留给客户。
- 不要把重复提议各自建页。 相似需求必须合并到一条提议或一个候选页面上，票数分散会让两边都到不了门槛。
- 不要改这两个数字。 7 和 19 写在对外页面上，调整门槛等于改对外承诺，需要先决定怎么处理已经在按旧门槛累积票数的提议和候选。
已知限制
总览页表格里的状态是人工维护的，票数不在总览页展示。要在总览页显示实时票数，需要一个组件走 GitHub GraphQL 查 Discussion 的 reaction 计数，而这需要 token，得挂在 Worker 后面转发。当前版本不做，先跑纯 markdown 加 giscus 的流程。
因此两个门槛都靠人工巡检发现：没有任何自动提醒会告诉我们某条提议满了 7 票、某个候选满了 19 票。既然门槛已经对外承诺，周巡检不能漏——每周需要过一遍 submit-idea.md 的评论区票数，以及全部「投票中」候选页面的主楼票数。这是当前设计里最脆的一环，也是后续做票数组件时优先要解决的问题。