docs(p1r): 记录 completed approval 预检边界

This commit is contained in:
zizi 2026-06-08 02:48:45 +08:00
parent e8ed7d7ae0
commit 0f498026bb

View File

@ -0,0 +1,234 @@
# 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 reviewConfuciusPASS无 P0/P1/P2 blocker。
- Fresh quality/feasibility reviewCarverPASS无 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 证据。
```mermaid
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 显示:
```text
totalOperations=233
completedOperations=100
needsVerificationOperations=133
incompleteOperations=0
genericPersistenceOperations=0
ssePlaceholderOperations=0
```
按 domain 聚合:
```text
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 reviewMencius spec PASSHume 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 reviewRawls correctness/spec PASSBoole 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 reviewPascal spec/correctness PASSMill 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执行版。