req-track

# 需求跟进（req-track） 需求不是做砸的，多数是没人问着慢慢沉掉的。这一步就是定期问一句，并且把「没人更新」本身当成一条要上报的信息。 ## 1. 约定节奏 在 intake 或 design 时和提出人约好：开发中默认每个工作日一次，排队中每周一次。写进文档「1. 文档信息」的「跟进节奏」。 ## 2. 拉状态 ```bash 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，不来自猜测： ```text 进展：自上次以来完成了什么（附链接） 阻塞：卡在哪、等谁、从哪天开始 下一步：谁、做什么、预计何时 ``` ## 4. 判定停滞 满足任一条就标 **停滞**： - 操作记录和评论在约定节奏的两倍时间内没有新内容； - 同一阻塞连续两次跟进没变化； - 计划时间已过但状态没动。 停滞不自动改状态、不自动催人。我们做的是：在给提出人的报告里置顶这一项，写清停了多久、最后一次动静是什么、建议找谁。提出人决定是否在工作项上评论或 @ 人： ```bash meegle comment add --project-key <PK> --work-item-id <ID> --content "<站会三行>" ``` ## 5. 记录 把每次的三行追加到文档「7. 进展记录」末尾，保持时间顺序： ```bash lark-cli docs +update --as user --doc <URL> --command append --doc-format markdown --content @standup.md ``` ## 输出 一张表：需求、状态、进展、阻塞、下一步、是否停滞。停滞项放最上面。只读汇总，不给人排名。 ## 用到的命令 先确认身份和空间（每个会话一次）： ```bash 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`。