# 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 证据。

```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 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执行版。