zizi-al/oh-my-muse
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
oh-my-muse/docs/agent-specs/2026-06-07-P1R7CompletedApproval预检审阅版.md

12 KiB
Raw Blame History

P1R7 Completed Approval 预检审阅版

结论

推荐启动 P1R-7 completed approval 预检，但不推荐现在直接把 Events / P1R-7 写成 completed。

当前 AI、Knowledge、Market 三条 source owner propagation 真实链路已经分别收口到 needs_verification 证据层，并已提交推送到 origin/dev/1.0.0。但是按现有全局执行版，P1R-7 completed approval 至少还需要先回答两个问题：

  1. completed approval 的目标是否只覆盖 Events streamEvents GET /app-api/muse/events 这一项 operation。
  2. Account(Member) 与 Content 是否仍属于 P1R-7 completed approval 必须覆盖的 source owner。

如果答案是“Account / Content 仍必须覆盖”，下一阶段应进入 P1R-7e Account 和 P1R-7f Content，而不是 completed。
如果答案是“本轮 completed approval 只审批 Events streamEvents，且 AI / Knowledge / Market 三个 source owner 足够作为 evidence”，则需要先写执行版、跑最终验证、fresh 双 review，再由用户单独批准 coverage 状态推进。

本审阅版只做预检范围冻结，不实现代码，不修改 OpenAPI、scanner 或 coverage report，不推进 completed。

Review Gate

  • Fresh spec/scope review（Confucius）PASS，无 P0/P1/P2 blocker。
  • Fresh quality/feasibility review（Carver）PASS，无 P0/P1/P2 blocker。

两位 reviewer 均确认：本审阅版只通过“预检文档进入下一步”的门槛，不代表任何 coverage 状态可推进，也不代表 P1R-7 completed approval 已获批准。

非阻塞风险已经纳入后续执行要求：

  • 如果用户没有明确批准“只审批 Events streamEvents”，后续执行版应默认走 Account / Content 补证路径，否则会与全局门槛冲突。
  • 如果后续走 Events-only approval，执行版必须把 focused harness 与真实 HTTP/SSE live gap 转成明确 gate，或者写明用户批准的 waiver。
  • 后续仍必须只在 /tmp 隔离副本运行会写 coverage report 的 scanner，并在真实 worktree 前后复查 protected diff。
  • 最终验证顺序必须先 reactor build，再 focused/P1R tests，避免 clean 抹掉 surefire XML 证据。
flowchart TB
    Current["当前已验证 evidence<br/>P1R-7a Events SSE<br/>P1R-7b AI<br/>P1R-7c Knowledge<br/>P1R-7d Market"] --> Precheck["P1R-7 completed approval 预检"]
    Precheck --> ScopeDecision{"completed scope 决策"}
    ScopeDecision -->|Account/Content 必须覆盖| MoreOwners["继续 P1R-7e Account<br/>P1R-7f Content"]
    ScopeDecision -->|仅审批 Events streamEvents| FinalPlan["写 completed approval 执行版<br/>最终验证 + fresh review"]
    FinalPlan --> Approval{"用户单独批准?"}
    Approval -->|是| Coverage["更新 coverage completed"]
    Approval -->|否| Stay["保持 needs_verification"]

已验证事实

工作区与提交状态

  • 正确 worktree：/Users/qingse/.config/superpowers/worktrees/oh-my-muse/dev-1.0.0。
  • 当前分支：dev/1.0.0。
  • 当前分支已与 origin/dev/1.0.0 对齐到 e8ed7d7 test(p1r): 收口 Market 事件传播真实链路门禁。
  • P1R-7 source owner propagation 相关提交链：
    • fa29753 test(p1r): 收口 Events SSE 门禁
    • 3db5fbe feat(p1r): 接入 AI 事件传播真实链路
    • 230152c test(p1r): 收口 AI 事件传播真实链路门禁
    • cef686b feat(p1r): 接入 Knowledge 事件传播真实链路
    • e55618f test(p1r): 收口 Knowledge 事件传播真实链路门禁
    • b36b153 feat(p1r): 接入 Market 事件传播真实链路
    • e8ed7d7 test(p1r): 收口 Market 事件传播真实链路门禁

当前 coverage 边界

当前真实 worktree 的 coverage report 显示：

totalOperations=233
completedOperations=100
needsVerificationOperations=133
incompleteOperations=0
genericPersistenceOperations=0
ssePlaceholderOperations=0

按 domain 聚合：

ai dedicated/completed:41
knowledge dedicated/completed:59
events dedicated/needs_verification:1
market dedicated/needs_verification:32
account dedicated/needs_verification:33
content dedicated/needs_verification:51
meta dedicated/needs_verification:16

因此当前如果进入 completed approval，直接候选 operation 只能是 Events 的 streamEvents GET /app-api/muse/events。Market 32、Account 33、Content 51、Meta 16 仍不是本审阅版自动推进对象。

P1R-7a Events SSE evidence

  • P1R-7a 已把 streamEvents GET /app-api/muse/events 从 sse_placeholder / incomplete 推进到 dedicated / needs_verification。
  • P1R-7a 证据包括：
    • frontend SSE focused tests。
    • P1R Events API gate。
    • route ownership gate。
    • reactor build。
    • dependency tree。
    • V16 Flyway _test。
  • P1R-7a 明确没有接入 source owner propagation，不能作为 completed evidence。

P1R-7b AI source owner evidence

  • AI terminal event -> AI publish outbox -> AI worker -> EventsPublishApi -> muse_unified_event -> SSE visible 链路已收口到 needs_verification。
  • 已验证：
    • reactor build 47/47 success。
    • AI / Events focused tests 87 pass。
    • P1R mixed gates 37 pass。
    • V17 Flyway _test 4 pass。
    • AI server 有 events-api、无 events-server。
    • Events server 无 AI / Knowledge / Market / Member / Content server 反向依赖。
    • coverage scanner 只在 /tmp 隔离副本运行，summary 保持 completed=100 / needsVerification=133。
  • fresh Task 7 review：Mencius spec PASS，Hume quality PASS。

P1R-7c Knowledge source owner evidence

  • Knowledge source event -> Knowledge publish outbox -> Knowledge worker -> EventsPublishApi -> muse_unified_event -> SSE visible 链路已收口到 needs_verification。
  • 已验证：
    • reactor build 62/62 success。
    • Knowledge focused tests 15 pass。
    • P1R mixed gates 37 pass。
    • V18 Flyway _test 4 pass。
    • dependency gate 与 protected diff gate 通过。
    • coverage scanner 只在 /tmp 隔离副本运行，summary 保持 completed=100 / needsVerification=133。
  • fresh review：Rawls correctness/spec PASS，Boole data-integrity/testing PASS。

P1R-7d Market source owner evidence

  • Market governance terminal fact -> Market publish outbox -> Market worker -> EventsPublishApi -> muse_unified_event -> /app-api/muse/events 对资产发布者可见链路已收口到 needs_verification。
  • 已验证：
    • reactor build 62/62 success。
    • Market focused tests 28 pass。
    • P1R mixed gates 56 pass。
    • V19 Flyway _test 4 pass。
    • dependency tree gate 通过。
    • coverage scanner 只在 /tmp/p1r7d-final-coverage-scan.nhBVhM 隔离副本运行，summary 保持 completed=100 / needsVerification=133。
    • protected diff 与 git diff --check 通过。
  • fresh review：Pascal spec/correctness PASS，Mill quality/data-integrity/testing PASS。
  • P1R-7d 已拆分提交并 push 到 origin/dev/1.0.0。

推断

  • 当前证据足以证明 Events SSE 入口已从占位变成 dedicated，并且 AI、Knowledge、Market 三个 owner 的用户可见事件可以通过本域 outbox / worker 发布到 Events。
  • 当前证据还不足以自动证明 P1R-7 completed，因为全局执行版仍把 Account(Member) 与 Content 列为后续 source owner 候选，并且 completed approval 明确要求另起任务、单独审批。
  • 如果 completed approval 目标只针对 Events streamEvents，AI / Knowledge / Market 三个 owner 可以构成较强的 source owner propagation evidence，但仍需要最终执行版明确验证命令、fresh review 和用户批准。
  • 如果 completed approval 目标被解释为“所有 declared source owner 都必须覆盖”，当前缺 Account(Member) 与 Content source owner propagation，应该继续 P1R-7e / P1R-7f。

假设

  • docs/superpowers/reports/p1r-api-coverage.json 中 P1R-7 对应的可推进 operation 是 Events streamEvents。
  • P1R-7 completed approval 不自动包含 Market 32 operations、Account 33 operations、Content 51 operations 或 Meta 16 operations 的 completed 推进。
  • 用户仍要求 completed 状态必须明确批准，不能由 gate PASS 自动推出。

推荐路径

方案 A：继续补齐 Account / Content

适用条件：

  • 用户确认 P1R-7 completed approval 必须覆盖全局执行版列出的 Account(Member) 与 Content source owner。

下一步：

  1. 写 P1R-7e Account(Member) source owner propagation 审阅版。
  2. fresh spec review + fresh quality review。
  3. 双 PASS 后写执行版并实现。
  4. 再做 P1R-7f Content source owner propagation。

优点：

  • 最符合当前全局执行版。
  • completed approval 争议最小。

代价：

  • 周期更长。
  • Account / Content 的用户可见事件边界需要重新审阅，不能直接套 AI / Knowledge / Market 模板。

方案 B：先做 Events streamEvents completed approval 执行版

适用条件：

  • 用户确认本轮 completed approval 只审批 Events streamEvents，不把 Account / Content source owner propagation 作为硬前置。

下一步：

  1. 写 P1R7CompletedApproval执行版。
  2. 执行版必须包含最终验证命令、隔离 coverage scanner、protected diff、dependency tree、Flyway _test、fresh final overall review。
  3. 执行版 review 双 PASS 后，才允许运行最终验证。
  4. 最终验证和 review 均 PASS 后，再由用户单独批准是否修改 coverage completionStatus。

优点：

  • 可以尽快完成 Events streamEvents 的审批闭环。
  • 不会把 Market / Account / Content 其他 operation 混入本轮。

风险：

  • 需要显式修改或解释全局执行版中的 Account / Content owner 前置口径，否则 reviewer 可能判定 scope 不闭合。
  • 即使批准，也只能影响 Events streamEvents，不能把 Market / Account / Content / Meta 一并标 completed。

非目标

  • 不实现 Account / Content source owner。
  • 不运行最终 full verification。
  • 不修改 OpenAPI。
  • 不修改 muse-cloud/scripts/p1r-audit-api-coverage.py。
  • 不修改 docs/superpowers/reports/p1r-api-coverage.json 或 .md。
  • 不推进 completed。
  • 不把 Market 32 operations、Account 33 operations、Content 51 operations 或 Meta 16 operations 作为本审阅版自动 completed 对象。

风险

  • scope 风险：如果不先确认 Account / Content 是否是 completed 前置，直接写执行版会在 fresh review 中反复 FAIL。
  • 证据风险：当前 AI / Knowledge / Market 多数 E2E 是 focused harness，不等于真实浏览器 SSE 或全 source API HTTP live flow。
  • 状态风险：coverage 当前 completed=100 / needsVerification=133，任何 completed 推进都会改受保护报告，必须在用户明确批准后进行。
  • 回归风险：最终验证应先跑 reactor build，再跑会生成 surefire XML 的 tests，避免 clean 抹掉证据。

验收标准

本审阅版通过的标准：

  1. 明确当前 evidence 与 completed 的边界。
  2. 明确 P1R-7 completed approval 的候选对象只能是 Events streamEvents，除非用户另行扩大 scope。
  3. 明确 Account / Content 是否必须先补齐是待确认决策。
  4. 不修改受保护文件。
  5. fresh spec review + fresh quality review 双 PASS 后，才允许写执行版。

待确认项

  1. P1R-7 completed approval 是否只审批 Events streamEvents GET /app-api/muse/events？
  2. Account(Member) 与 Content 是否仍是 P1R-7 completed approval 的硬前置 source owner？
  3. 如果先走 Events streamEvents approval，是否允许在执行版中明确“Account / Content 作为后续 source owner，不阻塞本次 Events operation completed approval”？

下一步

  1. 对本审阅版派发 fresh spec compliance review。
  2. 对本审阅版派发 fresh quality / feasibility review。
  3. 双 PASS 后，根据用户对待确认项的答案，进入 P1R-7e/P1R-7f 或 P1R7CompletedApproval执行版。