需求跟进（req-track）

需求不是做砸的，多数是没人问着慢慢沉掉的。这一步就是定期问一句，并且把「没人更新」本身当成一条要上报的信息。

1. 约定节奏

在 intake 或 design 时和提出人约好：开发中默认每个工作日一次，排队中每周一次。写进文档「1. 文档信息」的「跟进节奏」。

2. 拉状态

meegle workitem get --project-key <PK> --work-item-id <ID> --format json
meegle workitem list-op-records --project-key <PK> --work-item-id <ID> --format json
meegle comment list --project-key <PK> --work-item-id <ID> --format json

多个需求时用 workitem query 按提出人或标签筛，见 meegle skill 的 mql-people-roles.md。

3. 站会三问

对每个需求只写三行，事实来自上面的记录和关联的 PR/CI，不来自猜测：

进展：自上次以来完成了什么（附链接）
阻塞：卡在哪、等谁、从哪天开始
下一步：谁、做什么、预计何时

4. 判定停滞

满足任一条就标 停滞：

• 操作记录和评论在约定节奏的两倍时间内没有新内容；
• 同一阻塞连续两次跟进没变化；
• 计划时间已过但状态没动。

停滞不自动改状态、不自动催人。我们做的是：在给提出人的报告里置顶这一项，写清停了多久、最后一次动静是什么、建议找谁。提出人决定是否在工作项上评论或 @ 人：

meegle comment add --project-key <PK> --work-item-id <ID> --content "<站会三行>"

5. 记录

把每次的三行追加到文档「7. 进展记录」末尾，保持时间顺序：

lark-cli docs +update --as user --doc <URL> --command append --doc-format markdown --content @standup.md

输出

一张表：需求、状态、进展、阻塞、下一步、是否停滞。停滞项放最上面。只读汇总，不给人排名。

用到的命令

先确认身份和空间（每个会话一次）：

meegle project search --project-key "<空间名或 key>" --format json
meegle workitem meta-types --project-key <PK> --format json
lark-cli docs +fetch --as user --doc <需求文档 URL> --scope outline

字段 key、状态 key、transition_id 一律现查，不要凭记忆填，见 templates/meegle-field-mapping.md。