oh-my-muse/docs/archive/2026-06-14-P1RAccountRemaining21解锁审阅版.md
lili 0c119d7c6f docs: 归档已完成阶段过程文档至 docs/archive(git mv 保历史)
9 篇工作已完成的过程文档(P1R解锁3篇+agent基建交付+superpowers报告2篇+P1R任务memory+已合并object-storage计划+已折入总览的completion brainstorm)移至 docs/archive/。保留:design-docs(SSOT)、主台账、现状基线、对抗复盘/P0冻结令(知识网根基,被AGENTS/.agents/台账引用)、meta-schema当前2篇、p1r-api-coverage.json(被引数据)、memorys/README。归档非删除,git 可恢复。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-20 02:50:00 -07:00

357 lines
14 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# P1R Account Remaining 21 解锁审阅版
日期2026-06-14
## 结论
不建议继续把 Account 剩余 21 个 `dedicated / needs_verification` operation 当作“只补 approval 证据”的任务推进。
当前剩余 21 个 operation 已经不是简单缺 HTTP+DB `_test` 或 mixed gate 的问题,而是集中落在五类真实闭环缺口:
- New-API runtime / quota request / integration correlation。
- FileService / export task / download bytes。
- call attribution source / usage source fact。
- Market purchase / license / publish projection。
- security event acknowledge 的 session revoke 合同。
推荐把下一阶段定义为:
```text
P1R Account Remaining 21 Unlock
```
该阶段应先补真实 owner 边界、外部 runtime 或明确可验收替代合同,再回到 operation-level completed approval。不得用 dedicated controller、unit test、fail-closed 行为或文档结论直接把剩余 21 个 operation 推进 `completed`
```mermaid
flowchart TB
Current["当前 Account<br/>12 completed / 21 needs_verification"] --> Split["剩余 21 分组"]
Split --> NewApi["New-API / quota / integration<br/>9 ops"]
Split --> Export["FileService / export / download<br/>3 ops"]
Split --> Usage["usage / attribution<br/>4 ops"]
Split --> Market["Market projection<br/>4 ops"]
Split --> Security["security ack / session revoke<br/>1 op"]
NewApi --> Unlock["先补真实闭环或验收替代"]
Export --> Unlock
Usage --> Unlock
Market --> Unlock
Security --> Unlock
Unlock --> Approval["再写切片执行版 + fresh 双 review<br/>用户批准后才改 coverage"]
```
## 当前事实状态
工作区:
```text
/Users/qingse/.config/superpowers/worktrees/oh-my-muse/dev-1.0.0
```
当前 HEAD
```text
3a27e7e test(p1r): 收口 Account Security Events completed approval 门禁
```
当前 coverage summary
```text
233 147 86 0 0 0
```
当前按 domain 聚合:
```text
account total=33 completed=12 needsVerification=21
ai total=41 completed=41 needsVerification=0
content total=51 completed=14 needsVerification=37
events total=1 completed=1 needsVerification=0
knowledge total=59 completed=59 needsVerification=0
market total=32 completed=4 needsVerification=28
meta total=16 completed=16 needsVerification=0
```
Account 已 completed 的 12 个 operation
```text
account:getCurrentUser
account:getProfile
account:updateProfile
account:adminListAccountUsers
account:adminGetUserEntitlements
account:getAppEntitlements
account:adminGetBalanceSnapshots
account:getAppBalanceSnapshots
account:adminCreateQuotaAdjustment
account:adminListQuotaAdjustments
account:appListSecurityEvents
account:appGetSecurityEvent
```
Account 剩余 21 个 operation
```text
account:adminCreateCallAttributionJob
account:adminGetCallAttributionJob
account:adminGetIntegrationCallByCorrelation
account:adminListNewApiBindings
account:adminListPurchaseRecords
account:adminListUsageRecords
account:adminCreateNewApiBinding
account:adminCreateQuotaRequest
account:appDownloadExport
account:appCreateExportTask
account:appGetExportTask
account:appGetIntegrationCallByCorrelation
account:appListLicenses
account:getAppNewApiBinding
account:appRecheckNewApiBinding
account:appListPublishRecords
account:appListPurchases
account:appCreateQuotaRequest
account:appGetQuotaRequest
account:appAcknowledgeSecurityEvent
account:getAppUsage
```
## 非目标
本审阅版不做以下事情:
- 不修改 OpenAPI。
- 不修改 scanner 或 coverage report。
- 不修改 Account 业务实现、SQL migration 或测试代码。
- 不把 Account 加入 domain-level completed allowlist。
- 不推进 Account 33/33 completed。
- 不推进 Market、Content 或总 P1R completed。
- 不把 fail-closed、dedicated gate PASS、unit test PASS 或历史 review PASS 当作 completed 证据。
## 剩余 21 分组与阻塞
### 1. New-API / quota request / integration correlation
覆盖 9 个 operation
```text
account:adminListNewApiBindings
account:adminCreateNewApiBinding
account:getAppNewApiBinding
account:appRecheckNewApiBinding
account:adminCreateQuotaRequest
account:appCreateQuotaRequest
account:appGetQuotaRequest
account:adminGetIntegrationCallByCorrelation
account:appGetIntegrationCallByCorrelation
```
已验证事实:
- `AccountNewApiBindingServiceImpl` 使用 `NewApiAccountFacade` 作为外部 New-API 边界。
- 默认 `UnavailableNewApiAccountFacade` fail-closed不能伪造 binding / recheck 成功。
- create/recheck 路径已有 command、requestHash、integration call、success/unavailable 事实。
- `AccountQuotaServiceImpl` 的 quota request create 会写 `muse_account_quota_request``muse_account_integration_call`,状态为 `queued` / `pending_attribution`
阻塞点:
- 没有真实 New-API runtime 或可验收替代 runtime 证明 binding / recheck / quota request 的成功闭环。
- quota request 目前只是 queued fact不等于额度配置、订阅同步或余额同步完成。
- integration correlation 读侧依赖上述 integration call 事实质量;不能脱离 create/recheck/quota request 闭环单独 completed。
推荐解锁条件:
- 定义并实现真实 New-API Account facade或写明可验收替代 runtime。
- 覆盖 success、unavailable、timeout、retry、idempotent replay、correlation 查询、owner/tenant 隔离。
- 对 admin/app integration detail 做敏感字段 allowlist 与 no-write HTTP+DB `_test`
### 2. FileService / export / download
覆盖 3 个 operation
```text
account:appCreateExportTask
account:appGetExportTask
account:appDownloadExport
```
已验证事实:
- `AccountExportServiceImpl` 通过 `AccountFileServiceFacade` 调用文件 owner。
- 默认 FileService 不可用时 create export 只返回 queued 或 fail-closed。
- download 路径要求 credential hash、一次性消费、task completed、fileRef 和真实 bytes。
- 高敏 `usage` / `security_events` export 因缺 step-up proof 会 fail-closed。
阻塞点:
- 没有真实 FileService / 对象存储 / 文件字节下载闭环。
- create task queued 不等于 export completed。
- appDownloadExport 不能用 mock bytes 或空 bytes 当 completed。
- step-up proof 仍未形成可信服务端合同。
推荐解锁条件:
- 接入真实 FileService facade 或可验收替代文件 runtime。
- HTTP+DB `_test` 覆盖 task create、completed detail、credential 可见性、credential 一次性消费、download bytes、audit、过期/撤销/并发消费失败。
- 明确高敏 export 的 step-up proof 来源;否则高敏类型继续保持 fail-closed 与 needs_verification。
### 3. usage / call attribution
覆盖 4 个 operation
```text
account:adminListUsageRecords
account:getAppUsage
account:adminCreateCallAttributionJob
account:adminGetCallAttributionJob
```
已验证事实:
- `AccountUsageServiceImpl``MemberUsageRecordMapper``AccountIntegrationCallMapper` 聚合 usage / attribution 状态。
- `AccountAttributionServiceImpl.adminCreateCallAttributionJob` 当前只创建 queued job fact。
- 真实归因 source 由 `AccountAttributionSourceFacade` 代表,当前没有 completed-grade source owner 证据。
阻塞点:
- usage record 的上游来源、归因状态、token 计量与 attribution source 没有形成端到端事实链。
- create attribution job 只是排队真实归因执行、terminal transition、补偿建议和 item result 还不能证明。
- adminGetCallAttributionJob 读侧依赖 job/item terminal fact 质量,不能只凭 detail mapper completed。
推荐解锁条件:
- 明确 usage source ownerAI/Content/Market/New-API 调用如何写入 `MemberUsageRecordDO`
- 建立 attribution job worker 或明确同步归因替代路径。
- HTTP+DB `_test` 覆盖 queued、processing、completed、failed、partially_completed、revision conflict、call whitelist、owner/tenant 隔离和 no-write detail。
### 4. Market purchase / license / publish projection
覆盖 4 个 operation
```text
account:adminListPurchaseRecords
account:appListPurchases
account:appListLicenses
account:appListPublishRecords
```
已验证事实:
- `AccountMarketRecordServiceImpl` 通过 `MarketAccountProjectionFacade.requireProjectionAvailable(recordType)` 检查 Market 投影是否可用。
- 读侧使用 `muse_account_record_projection`,并按 `record_type` 隔离 purchase / license / publish。
- 当前 Market 仍只有 4 个 completedpurchase / install / publish / projection 相关 Market operation 仍为 `needs_verification`
阻塞点:
- Account projection 读模型依赖 Market owner 写入投影事实。
- Market purchase/license/publish 本身尚未 completed不能在 Account 侧单独宣称 projection completed。
- 需要证明跨 owner 一致性Market 源事实、Account projection、用户可见记录、状态枚举和排序分页一致。
推荐解锁条件:
- 先完成或至少审阅 Market purchase/install/publish/projection 的真实闭环。
- 建立 Market -> Account projection E2E `_test`Market source fact 写入后 Account 读侧可见,跨 owner/tenant 不可见projection stale/缺失 fail-closed。
- 在 Market 仍未 completed 前Account 这 4 个 operation 继续保持 `needs_verification`
### 5. security event acknowledge / session revoke
覆盖 1 个 operation
```text
account:appAcknowledgeSecurityEvent
```
已验证事实:
- `appListSecurityEvents``appGetSecurityEvent` 已在 2026-06-13 推进 completed。
- `appAcknowledgeSecurityEvent` 仍为 `dedicated / needs_verification / requiresCommandId=true`
- 既有审阅已确认:`session_revoked` OpenAPI 合同承诺真实 session revoke但当前实现只返回“未接入 session 管理服务”的 fail-closed 文案。
阻塞点:
- ack 写入本身不够;`session_revoked` 必须有真实 session revoke owner 或合同降级。
- 不能把 fail-closed 文案当 completed。
- 如果修改 OpenAPI 降级合同,必须单独审批;不能作为掩盖实现缺口的 scanner/report 修改。
推荐解锁条件:
- 接入真实 session management / token revoke owner或单独评审并批准 OpenAPI 合同变更。
- HTTP+DB `_test` 覆盖 commandId、ack row、replay、conflict、owner/tenant 隔离、session revoke success/fail-closed、audit/outbox/no-write rollback。
## 推荐路线
### 路线 AAccount unlock implementation 优先
先写 Account Remaining 21 执行版,把五类缺口拆成独立 implementation stage。每个 stage 先补真实闭环,再回到 completed approval。
优点:
- 直接推进 Account 33/33 的真实完成。
- 不把缺口留给 Market / Content 后续阶段。
代价:
- 会进入真实业务实现,不再只是 scanner/report/gate 的 completed approval。
- 需要用户确认外部 runtime 边界New-API、FileService、Market projection、attribution source、session management。
### 路线 B暂缓 Account继续 Market / Content 独立切片
Account 剩余 21 保持 `needs_verification`,转向 Market 或 Content 中已有较强闭环证据的 operation-level completed approval。
优点:
- 可以继续增加 completed 总量。
- 避免在 Account 外部 owner 未明确时硬做实现。
代价:
- 总 P1R 仍会被 Account remaining 21 阻塞。
- Market projection 最终仍会反向影响 Account 4 个 Market projection operation。
### 推荐选择
推荐路线 A但先只写 Account Remaining 21 执行版,不直接实现。执行版应先明确:
1. 哪些 runtime 由现有模块 owner 承担。
2. 哪些 facade 允许接入真实实现,哪些只能保持 fail-closed。
3. 哪些 OpenAPI 合同需要修订,哪些必须坚持实现兑现。
4. 每个 stage 的 HTTP+DB `_test`、focused test、P1R gate、XML 防空跑、protected diff。
5. 哪些 operation 可以在 stage 完成后进入 operation-level completed approval。
## Fresh 审阅结果
本审阅版已完成 fresh 双 review
- Spec/scope reviewPASS无 P0/P1/P2 阻塞。
- Feasibility/testing reviewPASS无 P0/P1 阻塞。
审阅结论确认本审阅版可以进入执行版编写,但不代表 Account remaining 21 已完成,也不授权实现、提交或推进 coverage。
执行版必须吸收以下 reviewer 约束:
1. New-API 与 attribution 的真实 facade wiring 不能停留在“接入真实 facade”一句话必须明确 `Unavailable*Facade` 默认实现与真实实现的 bean 选择策略,例如 `@Primary``@ConditionalOnMissingBean`、profile 排除或自动配置拆分,避免多 bean 冲突或继续选中 fail-closed 默认实现。
2. `adminCreateQuotaRequest``appCreateQuotaRequest``adminCreateCallAttributionJob` 等写命令必须明确 command、audit、job/outbox 的边界;若某 stage 不需要 outbox也必须写明“不需要”的原因和验证方式。
3. export/download stage 必须把 `muse.account.download-credential-secret` 作为 completed 前置校验FileService completed 证据必须包含 `fileRef`、过期时间、credential secret 与非空 bytes。
4. 新增 HTTP+DB `_test` 必须以 V1-V21 clean migrate 为基线;历史 V20 Account outbox 证据只能作为既有迁移回归,不能替代新 stage 主证据。
5. Market projection stage 必须独立覆盖 source fact、Account projection、stale/missing projection fail-closed、read-only no-write snapshot 与 owner/tenant 隔离。
6. rollback 不能只写 scanner/report 回滚;真实 unlock stage 必须包含 runtime switch、facade fallback 或配置级回退策略。
## 验收标准
本审阅版自身的验收标准:
- 文件写入 `docs/agent-specs/2026-06-14-P1RAccountRemaining21解锁审阅版.md`
- 不产生 scanner/report/OpenAPI/业务实现 diff。
- 明确 Account remaining 21 的分组、阻塞、解锁条件和推荐路线。
- 不宣称任何新增 operation completed。
后续执行版的最低验收标准:
- fresh spec/scope review PASS。
- fresh quality/feasibility/testing review PASS。
- 用户明确批准 execution scope 后才允许实现。
- 每个 implementation stage 都必须有真实 HTTP+DB `_test`、focused tests、P1R mixed gates、XML 防空跑、protected diff 和 rollback 策略。
## 待确认
1. 是否确认下一阶段命名为 `P1R Account Remaining 21 Unlock`
2. 是否确认路线 A先写 Account Remaining 21 执行版,进入真实闭环解锁,而不是继续做纯 approval。
3. 是否确认外部 owner 边界优先级New-API、FileService、Market projection、attribution source、session management。