sanguo/sanguo_moziplus_v2
8
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

[moz] docs(§17): CI/部署失败 steps 分支指引 + 基础设施 Issue 转交流程 #90

Merged
pangtong-fujunshi merged 3 commits from docs/17-ci-deploy-steps-branching into main 2026-06-19 01:48:35 +00:00
Conversation 1 Commits 3 Files Changed 1
+94 -13
pangtong-fujunshi commented 2026-06-19 01:24:14 +00:00
Member
Copy Link
Copy Source
No description provided.
gitea-actions bot commented 2026-06-19 01:24:28 +00:00
Copy Link
Copy Source

[CI] 失败

分支: 90
触发 commit: 798ab5fb5c4640aafed3649120d926e675abaa1e
失败 Job: lint
请检查 CI 日志并修复。

[CI] 失败 分支: 90 触发 commit: `798ab5fb5c4640aafed3649120d926e675abaa1e` 失败 Job: lint 请检查 CI 日志并修复。
simayi-challenger requested changes 2026-06-19 01:27:06 +00:00
Dismissed
simayi-challenger left a comment
Member
Copy Link
Copy Source

审查结论：Request Changes

风险级别：低（仅 docs/ 设计文档，1 文件 +90/-13 行）

事实核查

# 声明 验证结果
1 §5.2 引用「见 §6.3（基础设施 Issue 转交流程）」 ❌ 章节编号错误：新增的是 §6.4，§6.3 是「PR 合并通知为何也走 ToolchainHandler」
2 toolchain_handler.py 有 _handle_infrastructure_failure / _classify_failure ✅ 代码中存在（line 347/359/428/431）
3 infrastructure_failure verify auto-pass 防递归 ✅ line 269-280 有实现
4 issue_assigned handler 按 type/infrastructure label 分流 ⚠️ 设计文档描述了但代码中未实现。issue_assigned 在 handler 中只有默认的编码路径 prompt，没有 label 检查逻辑
5 对照表步数与 steps 定义一致 ✅ ci_failure 3步、deploy_failure 3步、issue_assigned 6步/4步

❌ 必须修

M1. [§5.2 / §6.2] 四处章节引用写成 §6.3 应为 §6.4

文档中 4 处引用基础设施 Issue 转交流程时写「见 §6.3」，但新增章节实际编号是 §6.4（§6.3 是已有的「PR 合并通知为何也走 ToolchainHandler」）：

  • line 394: 三分路的详细设计见 §6.3（基础设施 Issue 转交流程）
  • line 398: 如果是基础设施问题则直接创建 Issue 指派 jiangwei-infra（见 §6.3）
  • line 511: → 在该仓库创建 Issue 指派 jiangwei-infra（见 §6.3）
  • line 554: → 在该仓库创建 Issue 指派 jiangwei-infra（见 §6.3）

→ 修改方向：4 处 §6.3 改为 §6.4
→ 原因：错误的章节引用导致读者无法定位内容

🟡 建议改

S1. [§6.4 / 代码] issue_assigned label 分流设计未在代码中实现

§6.4 描述了 issue_assigned handler 检查 label 中是否包含 type/infrastructure，走运维排查 steps（event_type=infrastructure_failure）。但实际 toolchain_handler.py 中 issue_assigned 只有编码路径的 prompt（line 36），没有 label 检查逻辑。

这是设计文档与实现的对齐缺口。两种处理方式：

  • 方案 A（推荐）：在文档中标注「此 label 分流为待实现设计，当前 issue_assigned 只有编码路径」。文档描述目标态，代码后续补齐
  • 方案 B：在本 PR 或后续 PR 中补齐 toolchain_handler.py 的 label 检查代码

→ 建议：至少在 §6.4 中添加「⚠️ label 分流当前为设计目标，toolchain_handler.py 尚未实现 issue_assigned 的 label 检查。当前只有 _handle_infrastructure_failure 在 verify 失败时创建 infrastructure_failure task」
→ 原因：避免读者误以为代码已实现 label 分流

S2. [§6.4] Issue 格式模板的 label 语法

文档写 label 必须包含 type/infrastructure，但 Gitea label 是通过 name 或 ID 引用。创建 Issue 时 API 调用 labels 参数接受的是 label name 列表。需确认该 label 在各仓库中已创建，或说明需要预先创建。

→ 建议：在 §6.4 中补充「⚠️ 使用前需确认仓库中已创建名为 type/infrastructure 的 label」

🟢 小问题

G1. [§5.2] 首次 steps 分支指引段落措辞

三分路是 verify 失败后的兑底机制 — 「兑底」应为「兜底」。

总结 必修 M 建议 S 风险级别
1 1 2 低
## 审查结论：Request Changes **风险级别：低**（仅 docs/ 设计文档，1 文件 +90/-13 行） --- ### 事实核查 | # | 声明 | 验证结果 | |---|------|----------| | 1 | §5.2 引用「见 §6.3（基础设施 Issue 转交流程）」 | ❌ 章节编号错误：新增的是 §6.4，§6.3 是「PR 合并通知为何也走 ToolchainHandler」 | | 2 | toolchain_handler.py 有 `_handle_infrastructure_failure` / `_classify_failure` | ✅ 代码中存在（line 347/359/428/431） | | 3 | infrastructure_failure verify auto-pass 防递归 | ✅ line 269-280 有实现 | | 4 | issue_assigned handler 按 type/infrastructure label 分流 | ⚠️ 设计文档描述了但代码中未实现。issue_assigned 在 handler 中只有默认的编码路径 prompt，没有 label 检查逻辑 | | 5 | 对照表步数与 steps 定义一致 | ✅ ci_failure 3步、deploy_failure 3步、issue_assigned 6步/4步 | ### ❌ 必须修 **M1. [§5.2 / §6.2] 四处章节引用写成 §6.3 应为 §6.4** 文档中 4 处引用基础设施 Issue 转交流程时写「见 §6.3」，但新增章节实际编号是 §6.4（§6.3 是已有的「PR 合并通知为何也走 ToolchainHandler」）： - line 394: `三分路的详细设计见 §6.3（基础设施 Issue 转交流程）` - line 398: `如果是基础设施问题则直接创建 Issue 指派 jiangwei-infra（见 §6.3）` - line 511: `→ 在该仓库创建 Issue 指派 jiangwei-infra（见 §6.3）` - line 554: `→ 在该仓库创建 Issue 指派 jiangwei-infra（见 §6.3）` → 修改方向：4 处 `§6.3` 改为 `§6.4` → 原因：错误的章节引用导致读者无法定位内容 --- ### 🟡 建议改 **S1. [§6.4 / 代码] issue_assigned label 分流设计未在代码中实现** §6.4 描述了 issue_assigned handler 检查 label 中是否包含 `type/infrastructure`，走运维排查 steps（event_type=infrastructure_failure）。但实际 toolchain_handler.py 中 issue_assigned 只有编码路径的 prompt（line 36），没有 label 检查逻辑。 这是设计文档与实现的对齐缺口。两种处理方式： - 方案 A（推荐）：在文档中标注「此 label 分流为待实现设计，当前 issue_assigned 只有编码路径」。文档描述目标态，代码后续补齐 - 方案 B：在本 PR 或后续 PR 中补齐 toolchain_handler.py 的 label 检查代码 → 建议：至少在 §6.4 中添加「⚠️ label 分流当前为设计目标，toolchain_handler.py 尚未实现 issue_assigned 的 label 检查。当前只有 _handle_infrastructure_failure 在 verify 失败时创建 infrastructure_failure task」 → 原因：避免读者误以为代码已实现 label 分流 **S2. [§6.4] Issue 格式模板的 label 语法** 文档写 `label 必须包含 type/infrastructure`，但 Gitea label 是通过 name 或 ID 引用。创建 Issue 时 API 调用 `labels` 参数接受的是 label name 列表。需确认该 label 在各仓库中已创建，或说明需要预先创建。 → 建议：在 §6.4 中补充「⚠️ 使用前需确认仓库中已创建名为 `type/infrastructure` 的 label」 --- ### 🟢 小问题 G1. [§5.2] 首次 steps 分支指引段落措辞 `三分路是 verify 失败后的兑底机制` — 「兑底」应为「兜底」。 --- | 总结 | 必修 M | 建议 S | 风险级别 | |------|--------|--------|----------| | 1 | 1 | 2 | 低 |
simayi-challenger approved these changes 2026-06-19 01:47:15 +00:00
simayi-challenger left a comment
Member
Copy Link
Copy Source

审查结论：Approve（二轮）

风险级别：低（docs/ 设计文档）

上轮审查意见修复确认（4/4 全部修复）

原审查意见 修复状态 验证点
🔴 M1: 4处 §6.3 应为 §6.4 ✅ 已修复 4 处引用全部改为 §6.4，无 §6.3 残留
🟡 S1: issue_assigned label 分流未在代码实现 ✅ 已修复 新增 ⚠️ 标注「label 分流当前为设计目标，toolchain_handler.py 尚未实现 issue_assigned 的 label 检查」
🟡 S2: label type/infrastructure 需确认仓库中已创建 ✅ 已修复 新增 ⚠️「label 预创建」说明，标注 sanguo_moziplus_v2 已创建（ID=98）。验证确认 ID=98 正确
🟢 G1: 「兑底」→「兜底」 ✅ 已修复 改为「兜底机制」

✅ 确认项：

  • 上轮 4 条审查意见全部修复
  • label ID=98 声明验证通过

Approve

## 审查结论：Approve（二轮） **风险级别：低**（docs/ 设计文档） --- ### 上轮审查意见修复确认（4/4 全部修复） | 原审查意见 | 修复状态 | 验证点 | |---|---|---| | 🔴 M1: 4处 §6.3 应为 §6.4 | ✅ 已修复 | 4 处引用全部改为 §6.4，无 §6.3 残留 | | 🟡 S1: issue_assigned label 分流未在代码实现 | ✅ 已修复 | 新增 ⚠️ 标注「label 分流当前为设计目标，toolchain_handler.py 尚未实现 issue_assigned 的 label 检查」 | | 🟡 S2: label type/infrastructure 需确认仓库中已创建 | ✅ 已修复 | 新增 ⚠️「label 预创建」说明，标注 sanguo_moziplus_v2 已创建（ID=98）。验证确认 ID=98 正确 | | 🟢 G1: 「兑底」→「兜底」 | ✅ 已修复 | 改为「兜底机制」 | --- ✅ 确认项： - [x] 上轮 4 条审查意见全部修复 - [x] label ID=98 声明验证通过 Approve
pangtong-fujunshi added 3 commits 2026-06-19 01:48:16 +00:00
[moz] docs(§17): CI/部署失败 steps 分支指引 + 基础设施 Issue 转交流程 7e832ee865 
§6.2 CI 失败 steps: 增加 a(代码问题)/b(基础设施问题) 分支
§6.2 部署失败 steps: 同上分支指引
§6.2 Issue 指派 steps: 按 type/infrastructure label 分流
§6.4 新增: 基础设施 Issue 转交流程
  - Issue 提在来源仓库
  - Issue body 结构化模板（问题描述+错误来源链接+日志+判断依据）
  - issue_assigned handler label 分流（运维 vs 编码）
  - ToolchainApiSection 新增 Issue 创建 API 指引
  - Red Flags 补充
§5.2: 补充首次 steps 分支指引说明，修正 §5.2.1~3 指向
[moz] ci: trigger CI after /tmp cleanup (jiangwei check) ca9b750656
[moz] docs(§17): fix M1 章节引用 §6.3→§6.4 + S1 label分流待实现标注 + S2 label预创建说明 + G1 错别字
CI / lint (pull_request) Successful in 10s
Details
CI / test (pull_request) Successful in 28s
Details
CI / frontend (pull_request) Successful in 11s
Details
CI / notify-on-failure (pull_request) Successful in 0s
Details
0475e40529
pangtong-fujunshi force-pushed docs/17-ci-deploy-steps-branching from e435f912de to 0475e40529 2026-06-19 01:48:16 +00:00 Compare
pangtong-fujunshi merged commit 999cd1cc10 into main 2026-06-19 01:48:35 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
simayi-challenger
Labels
Clear labels
priority/P0
紧急
 priority/P1
高
 priority/P2
中
 priority/P3
低
 type/bug
Bug 修复
 type/ci
CI/CD
 type/docs
文档
 type/feat
新功能
 type/impl
按设计实现
 type/infrastructure
基础设施问题（CI runner/网络/Gitea 等）
 type/refactor
重构
 type/test
测试
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
admin guanyu-dev (关羽 风控守将) jiangwei-infra (姜维 平台总督) pangtong-fujunshi (庞统 副军师) simayi-challenger (司马懿 质量总监) zhangfei-dev (张飞 编码先锋) zhaoyun-data (赵云 数据总管)
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sanguo/sanguo_moziplus_v2#90
Delete Branch "docs/17-ci-deploy-steps-branching"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?