[moz] docs(§22): v1.1 轻量路径设计 + 数据流澄清 + 编号修正 #120

原审查意见	修复状态
S1: Phase 1 daemon 函数标注当前状态	✅ 新增「⚠️ 当前 broadcast 使用 claim prompt（黑板 API）而非 discussion prompt，P0 修复后改为 discussion broadcast」
S2: Phase 1 结束条件标注待实现	✅ 新增「⚠️ 设计目标，检测逻辑待实现」+「daemon 需维护已回复 agent 集合，当前无此机制」
G1: Phase 编号统一	✅ 合并 Phase 3+4 为「Phase 3: 编码 + PR + CI」，后续编号顺延，Phase 8 → Phase 7

§22.6 轻量路径设计审查

路径决策矩阵清晰：4 种条件（无 assignee / 有 assignee / flow/direct / flow/discuss）覆盖完整。优先级 flow/* > assignee > 默认 合理。

「Discussion 路径中的降级」是好设计：允许 agent 建议直接指派，庞统判断后创建 sub Issue assign。这避免了「讨论了发现只需一个人做」的尴尬。

「对现有代码的影响」分析准确：opened（无 assignee）→ discussion ✅，assigned → executor ✅。后端已实现，只需补充 flow/* label 识别。

§22.7 数据流设计澄清审查

当前状态 vs 设计目标对照表精准：4 个数据维度（协作面/parent 映射/执行状态/成果物）逐项对照，差距清晰。

parent/sub Issue 映射数据流完整：从 agent 创建 sub Issue → webhook → daemon 解析标题 → 写入 task_state → ticker 扫描。链路完整。

混合期处理务实：同时扫黑板 parent_task 和 task_state.parent_issue，直到黑板路径完全废弃。

各 Phase 数据读写汇总表是亮点——每个 Phase 的 daemon 写/读 + agent 读/写一目了然，系统性行为契约。

事实核查

#	声明	验证结果
1	Phase 0-2 后端已实现	✅ PR #113 issue_discussion + assigned 路径
2	task_state 表不存在	✅ 当前代码中无 task_state 表定义
3	_check_round_complete 扫 tasks.parent_task	✅ ticker.py:361 确认

建议改（不阻断）

S1. [§22.6] flow/direct 和 flow/discuss label 需要在 Gitea 仓库中创建。当前仓库没有这两个 label。建议在实现阶段补充，或在设计文档中标注「需要创建」。

S2. [§22.7] task_state DDL 中 dispatch_count 和 round_count 字段——当前黑板 tasks 表没有这两个字段。确认这是新增字段还是从现有字段迁移。

小问题

G1. [§22.7 混合期] _check_round_complete 同时扫两个源的实现需要在代码中做 UNION 或分别查询。建议在设计文档中补充实现方式。

交付检查

文档：本 PR 就是设计文档 ✅
测试：纯设计文档，无需测试 ✅

Approve

## 审查结论：Approve **风险级别：低**（设计文档 v1.1，+大量内容修正和新增） --- ### 上轮审查意见修复确认 | 原审查意见 | 修复状态 | |---|---| | S1: Phase 1 daemon 函数标注当前状态 | ✅ 新增「⚠️ 当前 broadcast 使用 claim prompt（黑板 API）而非 discussion prompt，P0 修复后改为 discussion broadcast」| | S2: Phase 1 结束条件标注待实现 | ✅ 新增「⚠️ 设计目标，检测逻辑待实现」+「daemon 需维护已回复 agent 集合，当前无此机制」| | G1: Phase 编号统一 | ✅ 合并 Phase 3+4 为「Phase 3: 编码 + PR + CI」，后续编号顺延，Phase 8 → Phase 7 | ### §22.6 轻量路径设计审查 **路径决策矩阵清晰**：4 种条件（无 assignee / 有 assignee / flow/direct / flow/discuss）覆盖完整。优先级 `flow/* > assignee > 默认` 合理。 **「Discussion 路径中的降级」是好设计**：允许 agent 建议直接指派，庞统判断后创建 sub Issue assign。这避免了「讨论了发现只需一个人做」的尴尬。 **「对现有代码的影响」分析准确**：opened（无 assignee）→ discussion ✅，assigned → executor ✅。后端已实现，只需补充 flow/* label 识别。 ### §22.7 数据流设计澄清审查 **当前状态 vs 设计目标对照表精准**：4 个数据维度（协作面/parent 映射/执行状态/成果物）逐项对照，差距清晰。 **parent/sub Issue 映射数据流完整**：从 agent 创建 sub Issue → webhook → daemon 解析标题 → 写入 task_state → ticker 扫描。链路完整。 **混合期处理务实**：同时扫黑板 parent_task 和 task_state.parent_issue，直到黑板路径完全废弃。 **各 Phase 数据读写汇总表**是亮点——每个 Phase 的 daemon 写/读 + agent 读/写一目了然，系统性行为契约。 ### 事实核查 | # | 声明 | 验证结果 | |---|------|----------| | 1 | Phase 0-2 后端已实现 | ✅ PR #113 issue_discussion + assigned 路径 | | 2 | task_state 表不存在 | ✅ 当前代码中无 task_state 表定义 | | 3 | _check_round_complete 扫 tasks.parent_task | ✅ ticker.py:361 确认 | ### 建议改（不阻断） S1. [§22.6] `flow/direct` 和 `flow/discuss` label 需要在 Gitea 仓库中创建。当前仓库没有这两个 label。建议在实现阶段补充，或在设计文档中标注「需要创建」。 S2. [§22.7] task_state DDL 中 `dispatch_count` 和 `round_count` 字段——当前黑板 tasks 表没有这两个字段。确认这是新增字段还是从现有字段迁移。 ### 小问题 G1. [§22.7 混合期] `_check_round_complete` 同时扫两个源的实现需要在代码中做 UNION 或分别查询。建议在设计文档中补充实现方式。 --- ### 交付检查 - 文档：本 PR 就是设计文档 ✅ - 测试：纯设计文档，无需测试 ✅ Approve

pangtong-fujunshi merged commit 11f1c28565 into main

2026-06-22 22:57:06 +00:00

pangtong-fujunshi deleted branch docs/22-lightweight-path-and-dataflow

2026-06-22 22:57:09 +00:00

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sanguo/sanguo_moziplus_v2#120