label-reviewlisted

review 把每条 finding 发布成 PR/MR 上的**锚点 comment**（带 `ccr:fp=` 指纹）；Codex/Claude 对这些 comment **逐条求证并在其线程内回复** `ccr:label=<verdict>`。后续统一通过 GitLab/GitHub API 采集「原 finding comment + 其 label 回复��产出 ground truth；真问题和误报一样有价值， 只标一侧数据就偏了。 指纹和判定都活在 comment body 里、锚在 forge 上——换机器、换 worktree、换 session 都能接着 标，不依赖任何本地文件。 ## 步骤 1. **取待标 finding**： `<PLUGIN_ROOT>` 必须展开为当前 devloop 插件根目录；不得简写成裸 `pr`， macOS 会将它解析为系统排版命令 `/usr/bin/pr`。 ```bash <PLUGIN_ROOT>/scripts/python <PLUGIN_ROOT>/scripts/pr.py findings <n|url> --pending # 只列还没有 verdict 的 <PLUGIN_ROOT>/scripts/python <PLUGIN_ROOT>/scripts/pr.py findings <n|url> # 全部，含已标的 verdict ``` 每行是 `<comment-id> [PENDING|verdict] <path>[:<line>] ccr:fp=<fp>`，`<comment-id>` 就是下一步的定位符。GitLab/GitHub 同一套写法，不用分别拼 `gh api` / `glab api`。 `.devloop/review.json` 只用于辅助求证；**仅存在本地、没发布成 comment 的 finding 不打标** ——它没有可回复的对象，采集侧也看不见。 2. **逐条求证**（判定纪律，不可省）： - 必须对照真实 diff/代码求证，**不能顺着 finding 文本信**——这是打标的头号失效模式： review 是模型写的，你也是模型，附和它会让 ground truth 退化成"模型认同模型"， 整个评测基准就白做了； - 论证扎实但在实际执行路径上不成立的判 wrong（"教科书事实错套"是最常见误报形态）； - pre-existing（diff 没碰的行为）不算本单有效 finding； - 拿不准判 debatable，不要硬判。 3. **打标**：回到该 finding 的线程里回复，一条一行： ```bash <PLUGIN_ROOT>/scripts/python <PLUGIN_ROOT>/scripts/pr.py reply <n> <comment-id> \ 'ccr:label=wrong — 该分支实际走不到，xxx.py:42 已早返回 #textbook' ``` 词表四档（**只有这四个词会被采集侧认**，拼错等于没标，`findings --pending` 会继续列它）： - `ccr:label=important — <理由>`（实质缺陷，采纳修复） - `ccr:label=m