已合并
fix(api): remove third batch of dead api functions #612
aflyingto创建于 5 天前
fix(api): remove third batch of dead api functions #612
已合并
Pull Request已成功合入, 合并人@aflyingto
(感谢 aflyingto 的贡献)aflyingto
5 天前 评论:
5 天前 评论:
评审结论
- 评审主体类型: 四个独立评审 Agent(与作者及彼此互为不同执行主体,各自动手实验验证)
- 评审主体标识: review-code / review-security / review-test / review-docs(Claude Code 子会话);作者主体为 Claude Code 主会话(aflyingto 账号操作)
- 评审范围: PR !612(feature/issue-635,6afa8ed 初轮 + ff8c47d/caecd57 两轮修复,GitHub 镜像 PR 121)——api 死代码第三批:14 文件 +2/-543 纯删除(14 函数 + 修复轮连带孤儿对 UpdateRelease/UpdateReleaseOptions + 19 测试 + 2 孤儿 import + 注释去悬空 + 孤儿 mock PATCH 分支);risk/high 档(分类器关键词机械命中 release 文件,四角色加严复核"实际纯删除"定性成立)
- 发现: 初轮——code 1 项 P2(删 UpdateReleaseByTag 使 UpdateRelease 成自反性孤儿,连带 UpdateReleaseOptions)+ 流程沉淀建议;security / docs 零发现(docs 一条纳米);test approved 含 2 P3(PATCH 孤儿分支 + 记录范围偏差)。修复轮一(ff8c47d)——P2 闭合,四角色零发现。修复轮二(caecd57)——两项 P3 闭合,test 终判零发现、code 改判 PATCH 删除正确。证据要点:①14 符号 + 修复轮孤儿对全仓零引用(含 api 包内互调口径——本批 SetIssueLabels 误判教训的方法论修补);②缓删 2 项(DeleteIssueComment/DeleteRepoDiscussionComment)经 openapi 端点存在 + issue 543/565 原文认领双重支持;③误判纠正实证:SetIssueLabels/ClearIssueLabels 的包内消费者 RemoveIssueLabel(label.go:245)被编译器即红抓获、恢复原位;④删除工具两起事故均被门禁拦截并完全恢复(vet 语法拦截删残 + 断言拦截原始字符串不平衡括号),终态经 build/vet/全量/gofmt 四重验证;⑤测试函数 delta 按文件 1+2+1+6+3+2+4=19 精确对账
- blocker: 无——P2 以 -20 行最小 diff 随本批闭合(review-code 复核五项验证点逐一实测通过);纳米对账已由 issue 验证记录 edit 闭合
- 安全检查: approved——纯删除零新增路径;缓删 2 项惰性不可达、实现干净(共享认证中间件)、有存活测试防腐化;攻击面严格缩减
- 测试与证据检查: approved(初轮含 2 P3 → 两轮修复后零发现闭环)——复活变异零消费者双重证明(父图谱 13 文件闭集 + 干净复活)、逐文件计数精确对账(-19)、两起删除工具事故机理重放属实(vet 拦截删残 + raw-string 括号欺骗被断言拦截)、孤儿 import 独立确认、163 包全量 + gofmt 干净;两轮修复均测试函数中性(api 恒 290、全仓恒 1762)
- 文档同步检查: approved——14 符号 + 孤儿对零文档命中、四个命令族(issue label/milestone/release/actions plugin)文档行为全由存活函数支撑、记录与 diff 三方对齐、披露质量为三批最高
- 结论: 可以批准
附带登记
①删包装后对体内 callee 重跑零引用检查(SetIssueLabels 教训的镜像面,review-code 流程沉淀建议,本件已采纳执行);②缓删 2 项的跟踪:issue 543/565 落地时接线、关闭不实施时删除(review-security 建议,将落 issue 备注);③/milestones/1 PATCH 分支:初判保留、review-test 前提更正后经 review-code 改判删除正确(终态 caecd57 已删,与 !610 孤儿路由处置同构)——评审体系自我纠错案例。精确性澄清:SetIssueLabels/ClearIssueLabels 系经包内存活链(RemoveIssueLabel 消费)保留,非缓删——与缓删 2 项(DeleteIssueComment/DeleteRepoDiscussionComment,issue 543/565 认领)性质不同。


变更内容
api 死代码清理第三批(issue 635,源于 !610 评审第 N 扫;13 文件 +1/-519 纯删除零新增):
AddLabelsToIssue/RemoveLabelFromIssue(label 命令族走存活的AddIssueLabels/RemoveIssueLabel)、CloseMilestone/OpenMilestone(milestone/edit 走UpdateMilestone)、UpdateReleaseByTag/DeleteReleaseByTag(release 命令走 direct/Known 变体)、ResolveUserIDs、BuildURL+ 其私有 helperreplacePath、ParseActionsPluginsList/ParseActionsPluginsListRaw/CountPluginsEntries(plugin list 命令直接用ParseActionsPluginsPage,三个高层包装无人用)、NewDownloadHTTPClient/NewUploadHTTPClientDeleteIssueComment(issue 543 正文明言"API 均已就绪"点名认领)、DeleteRepoDiscussionComment(issue 565 api-only 已规划命令)——开放特性 issue 的预建管线,删除会被既定计划立即回加SetIssueLabels/ClearIssueLabels曾被纳入删除面(扫描完整性抽查的"漏网发现")——build 失败揭示存活的RemoveIssueLabel(issue/label/label.go:245 实调)在包内消费二者,已恢复;此前生产引用 grep 只扫 pkg/cmd/internal、漏了 api 包内互调DeleteReleaseByTagKnown的 doc 注释去悬空(原"like DeleteReleaseByTag"改为自含描述)过程如实披露(删除工具事故与恢复)
批量删除脚本出过两起事故、均被门禁当场拦截并完全恢复:①第二版脚本花括号匹配起点错误(从函数开括号之后找嵌套块开括号),
queries_release_test.go删残(vet 报语法错误)——git checkout全量重置后以修正版脚本(含"块恰含 1 个 func、以 } 结尾"完备性断言)重删;②TestParseActionsPluginsListInvalid的原始字符串含不平衡{(`{invalid json)骗过计数器——断言拦截,改用精确文本块删除。终态经 build/vet/全量 163 包/gofmt 四重验证。作者自检
/milestones/1mock 路由 PATCH 分支(服务存活UpdateMilestone、无既有测试——非死函数面具,保留待评审裁定)不动go test ./...163 包全过;删除符号全仓 grep 零残留(仅注释性假阳性 2 处已甄别);测试函数 delta 精确 -19go build ./...与go build -o ./gc ./cmd/gc通过;gofmt 干净risk/high(分类器关键词机械命中 release 文件——与前两批同型;实际为纯死代码删除,如实声明供评审与人工裁定)/milestones/1PATCH 分支保留裁定——均交评审Closes #635
🤖 Generated with Claude Code