# P1R Account Remaining 21 Unlock 执行版

日期：2026-06-14

## 结论

本执行版用于把 Account 剩余 21 个 `dedicated / needs_verification` operation 从“无法继续纯 approval”的状态，拆成可落地的真实闭环解锁计划。

本执行版不是 completed approval 实施授权。执行版通过 review 后，仍必须由用户明确批准具体 stage，才能修改该 stage 的业务实现、SQL 或测试。scanner、coverage report、completed allowlist 只能在另起 completed approval 中修改；OpenAPI 只能在单独合同变更审批中修改。

当前目标：

```text
先补真实闭环和可验证 owner 边界，再回到 operation-level completed approval。
```

当前不做：

- 不修改 OpenAPI。
- 不修改 scanner 或 coverage report。
- 不修改 Account 业务实现、SQL migration 或测试代码。
- 不把 Account 加入 domain-level completed allowlist。
- 不推进 Account 33/33 completed、Market completed、Content completed 或总 P1R completed。

## 当前事实基线

工作区：

```text
/Users/qingse/.config/superpowers/worktrees/oh-my-muse/dev-1.0.0
```

当前 coverage summary：

```text
total=233
completed=147
needsVerification=86
incomplete=0
genericPersistence=0
ssePlaceholder=0
```

当前 Account 状态：

```text
total=33
completed=12
needsVerification=21
```

剩余 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
```

## 总体拆分

```mermaid
flowchart TB
    Base["Account 12 completed / 21 remaining"] --> A["Stage A<br/>New-API / quota / integration<br/>9 ops"]
    Base --> B["Stage B<br/>FileService / export / download<br/>3 ops"]
    Base --> C["Stage C<br/>usage / attribution<br/>4 ops"]
    Base --> D["Stage D<br/>Market projection<br/>4 ops"]
    Base --> E["Stage E<br/>security ack / session revoke<br/>1 op"]
    A --> Gate["真实 HTTP+DB + focused + mixed gates"]
    B --> Gate
    C --> Gate
    D --> Gate
    E --> Gate
    Gate --> Approval["另起 operation-level completed approval<br/>用户批准后才改 coverage"]
```

## 通用执行规则

每个 stage 必须遵守以下规则：

1. 先写 stage-level implementation plan 或审阅版，列明 owner、runtime、合同、allowed diff、验证命令和回滚策略。
2. fresh spec/scope review 与 fresh quality/feasibility/testing review 双 PASS 后，进入用户批准点。
3. 用户明确批准后才允许 implementation。
4. implementation 必须先做 TDD RED，再做最小实现，最后跑 focused gates、P1R mixed gates、XML 防空跑、`git diff --check` 与 protected diff。
5. implementation 完成后必须 fresh implementation 双 review；双 PASS 前不得提交、push 或宣称 completed。
6. unlock implementation 完成只代表“真实闭环已补齐”。是否推进 operation-level completed，仍需要单独 completed approval 或用户明确批准把该 stage 纳入 completed approval。

## 默认架构冻结

本执行版不是只给方向的路线图。后续 stage-level plan 可以细化类名、测试类名和属性名，但不能重新决定以下基础边界；如需改变，必须先回到用户批准点。

默认边界：

- Account API、Account 本地 command、audit、integration call、export task、usage view 和 attribution job 仍由 `muse-module-member` 的 Account 子域持有。
- New-API、FileService、Market projection、attribution source、session revoke 都必须通过显式 facade / owner API 接入，不能跨 owner 直接写对方 canonical fact。
- unavailable facade 的默认注册方式统一向现有 `AccountFileServiceFacadeAutoConfiguration`、`MarketAccountProjectionFacadeAutoConfiguration` 看齐：`@AutoConfiguration` + `@Bean` + `@ConditionalOnMissingBean(...)`。不得继续让 `Unavailable*Facade` 以 `@Component` 形式和真实 facade 同时进入容器。
- 真实 facade 必须有 runtime switch。关闭 switch 后应回到 fail-closed 或 queued-only，不得伪造成功。
- 默认不新增 Events outbox。只有当 stage 明确需要向统一 Events 发布用户可见事件时，才允许新增或复用 outbox；否则写命令以 Account command / audit / job / integration call fact 作为可审计边界。
- unlock stage 默认不改 scanner、coverage report 或 completed allowlist；这些只属于后续 completed approval。

## 通用验证模板

每个 stage-level plan 必须填充以下模板，不能只写原则。

Maven reactor root 固定为：

```bash
cd /Users/qingse/.config/superpowers/worktrees/oh-my-muse/dev-1.0.0/muse-cloud
```

真实 PostgreSQL `_test` gate 模板：

```bash
export P1R_STAGE_DB_NAME="muse_p1r_account_<stage>_test"
export P1R_STAGE_JDBC_URL="jdbc:postgresql://127.0.0.1:5432/${P1R_STAGE_DB_NAME}"
export P1R_STAGE_DB_USER="<test-user>"
export P1R_STAGE_DB_PASSWORD="<test-password>"

mvn -pl muse-server -am -Dtest=<StageHttpDbIT> \
  -Dsurefire.failIfNoSpecifiedTests=false test \
  -Dp1r.flyway.locations=filesystem:sql/muse \
  -Dp1r.flyway.url="${P1R_STAGE_JDBC_URL}" \
  -Dp1r.flyway.user="${P1R_STAGE_DB_USER}" \
  -Dp1r.<stage>.jdbc-url="${P1R_STAGE_JDBC_URL}" \
  -Dp1r.<stage>.jdbc-user="${P1R_STAGE_DB_USER}"
```

stage plan 必须指定真实密码来源，禁止把密码写进文档、代码、测试报告或 git diff。所有新 HTTP+DB IT 必须验证数据库名包含 `_test`，并以 V1-V21 clean migrate 为主证据。

P1R mixed gates 模板：

```bash
mvn -pl muse-server -am \
  -Dtest=P1rApiCoverageReportTest,P1rAccountRealApiGateTest,P1rEventsRealApiGateTest,P1rAiRealApiGateTest,P1rKnowledgeRealApiGateTest,P1rMarketRealApiGateTest,P1rContentRealApiGateTest,P1rMetaRealApiGateTest \
  -Dsurefire.failIfNoSpecifiedTests=false test
```

XML 防空跑模板：

```bash
python3 - <<'PY'
from pathlib import Path
import sys
import xml.etree.ElementTree as ET

targets = [
    # stage plan must fill exact TEST-*.xml filenames here
]
for target in targets:
    path = Path(target)
    if not path.exists():
        raise SystemExit(f"missing surefire xml: {path}")
    root = ET.parse(path).getroot()
    tests = int(root.attrib.get("tests", "0"))
    failures = int(root.attrib.get("failures", "0"))
    errors = int(root.attrib.get("errors", "0"))
    skipped = int(root.attrib.get("skipped", "0"))
    if tests <= 0 or failures or errors or skipped:
        raise SystemExit(f"invalid surefire xml: {path} tests={tests} failures={failures} errors={errors} skipped={skipped}")
print("xml_gate=pass")
PY
```

allowed diff 模板：

```bash
git diff --check
{
  git -c core.quotePath=false diff --name-only
  git -c core.quotePath=false diff --cached --name-only
  git -c core.quotePath=false ls-files --others --exclude-standard
} | sort -u > /tmp/p1r-account-stage.diff-files
```

stage plan 必须列出 allowed diff path 清单，并用脚本拒绝清单外文件。unlock implementation 始终保护以下路径；stage plan 不能放开这些路径：

```text
docs/api-contracts/**
muse-cloud/scripts/p1r-audit-api-coverage.py
docs/superpowers/reports/**
```

如确需修改上述路径，必须退出当前 unlock stage，另起 OpenAPI 合同变更审批或 completed approval 审批，并重新通过对应 fresh review。

## Stage A：New-API / quota / integration

### 范围

覆盖 9 个 operation：

```text
account:adminListNewApiBindings
account:adminCreateNewApiBinding
account:getAppNewApiBinding
account:appRecheckNewApiBinding
account:adminCreateQuotaRequest
account:appCreateQuotaRequest
account:appGetQuotaRequest
account:adminGetIntegrationCallByCorrelation
account:appGetIntegrationCallByCorrelation
```

### 默认 owner 与 runtime

Stage A 默认架构如下：

- Account 子域持有 `MemberNewApiBindingDO`、quota request、integration call、Account command/audit 和 HTTP API。
- New-API 真实 runtime 只能通过 `NewApiAccountFacade` 接入；默认实现类名由 stage plan 冻结，推荐命名为 `HttpNewApiAccountFacade` 或 `ConfiguredNewApiAccountFacade`，位于 `cn.iocoder.muse.module.member.application.account.facade` 或明确的 New-API adapter 包。
- quota request 默认由 Account 接收和审计，由 New-API facade 或 Account quota worker 负责提交外部 runtime。没有外部 runtime 成功回执前，quota request 只能停在 queued / pending / failed，不得宣称 completed。
- integration call correlation 的 source fact 只允许由 binding create/recheck、quota request worker 或 New-API callback 写入；admin/app detail 只能返回 allowlist 字段。
- Stage A 默认不新增 Events outbox；如 stage plan 需要向 Events 发布 quota/binding 事件，必须单独列出 outbox 表、状态机、投递 worker 和可见性 gate。

### facade wiring 策略

当前 `UnavailableNewApiAccountFacade` 是 fail-closed 默认实现。真实实现不能只新增一个同类型 bean 后依赖 Spring 自动选择。

Stage A 选定策略：

- 移除 `UnavailableNewApiAccountFacade` 的 `@Component` 默认注册。
- 新增 `NewApiAccountFacadeAutoConfiguration`，通过 `@Bean @ConditionalOnMissingBean(NewApiAccountFacade.class)` 注册 `UnavailableNewApiAccountFacade`。
- 真实 New-API facade 由 stage plan 指定配置开关，例如 `muse.account.new-api.enabled=true`，并作为普通 bean 注册。
- wiring test 必须仿照既有 `AccountFileServiceFacadeConfigurationTest` / `MarketAccountProjectionFacadeConfigurationTest`：无真实 bean 时只有 unavailable bean；有真实 bean 时 unavailable bean 不注册，`context.getBean(NewApiAccountFacade.class)` 返回真实实现。

任何策略都必须覆盖：

- 真实 runtime 可用时不会选中 fail-closed facade。
- runtime 不可用时明确 fail-closed，且不会伪造成功事实。
- 多 bean 场景不会产生启动歧义或静默选错实现。

### 写命令与审计边界

`adminCreateNewApiBinding`、`appRecheckNewApiBinding`、`adminCreateQuotaRequest`、`appCreateQuotaRequest` 必须明确：

- `commandId` 或 request hash 的幂等边界。
- command log 成功、失败、重放、冲突的记录方式。
- integration call fact 的 `correlationId`、request/response allowlist、status、errorCode。
- 是否需要 outbox。如果不需要，必须说明原因；如果需要，必须验证 outbox row 与投递/补偿边界。
- audit snapshot 必须包含 owner、actor、target、command、old/new state 或不可用原因。

### 验证门禁

Stage A implementation 至少需要：

- HTTP+DB `_test`：V1-V21 clean migrate，数据库名必须包含 `_test`，禁止连接非测试库。
- binding create/list/get/recheck success 与 unavailable/timeout/retry/fail-closed。
- quota request create/get success、replay、conflict、unauthorized、cross tenant、runtime unavailable。
- admin/app integration detail no-write snapshot，敏感字段 allowlist。
- facade wiring test，证明真实 facade 和 unavailable facade 的选择策略。
- P1R mixed gates 同步 Account 仍只推进获批 operation，Market/Content 不被误推进。
- XML 防空跑，所有目标 surefire XML tests > 0 且 failures/errors/skipped = 0。

### 回滚策略

Stage A 必须有 runtime switch：

- 关闭真实 New-API facade 后回落 fail-closed。
- 已写入 queued command / integration call 不被物理删除。
- scanner/report 回滚只用于 completed approval 阶段，不能替代 runtime 回滚。

### 默认 allowed diff

Stage A implementation 默认只允许以下类别，具体文件由 stage plan 展开：

- `muse-module-member` Account facade、service、worker、configuration、properties。
- `muse-module-member` Account focused tests 与 facade wiring tests。
- `muse-server` 下新增 Stage A HTTP+DB `_test`。
- `docs/agent-specs/.agent` 与 stage 文档。

OpenAPI、scanner、coverage report 仍禁止修改，除非另起 completed approval 或合同变更审批。

## Stage B：FileService / export / download

### 范围

覆盖 3 个 operation：

```text
account:appCreateExportTask
account:appGetExportTask
account:appDownloadExport
```

### 默认 owner 与 runtime

Stage B 默认架构如下：

- Account 子域持有 export task、download credential、command/audit 和 HTTP API。
- FileService 通过既有 `AccountFileServiceFacadeAutoConfiguration` 接入；默认 unavailable facade 已是 `@ConditionalOnMissingBean(AccountFileServiceFacade.class)` 模式，不需要改成 `@Component`。
- 真实 FileService owner 优先由现有文件模块或对象存储 adapter 提供 `AccountFileServiceFacade` bean。
- 若没有可用 FileService owner，stage plan 可以申请 test-local runtime，但必须是可审计的真实 byte store，不允许 mock service 或 hard-coded bytes。test-local fileRef 推荐使用 `account-export://<tenantId>/<taskId>/<sha256>` scheme，bytes 来源必须由 export payload 生成并校验 sha256。
- export worker 默认采用同步完成或显式 Account export worker 二选一；stage plan 必须冻结一种。queued-only 不能作为 completed 证据。
- 高敏 export 的 step-up proof 默认没有 owner，`usage` / `security_events` 类型继续 fail-closed；如要 completed，必须先确定 step-up proof 的服务端 owner。

### FileService completed 前置条件

`appDownloadExport` 不能用空 bytes 或 mock bytes 当 completed。Stage B 必须证明：

- export task 进入 `completed` 时有真实 `fileRef`。
- `fileRef` 能解析到非空 bytes。
- download credential 由 `muse.account.download-credential-secret` 签发或校验。
- credential 有过期时间、一次性消费或等价防重放机制。
- `usage` / `security_events` 等高敏 export 在缺 step-up proof 时继续 fail-closed。

### 写命令与审计边界

`appCreateExportTask` 必须明确：

- task command/request hash 的幂等边界。
- task 状态机：queued、processing、completed、failed、expired、revoked。
- FileService 调用失败、重试、补偿与 audit 记录。
- 是否需要 outbox；如不需要，必须说明 export task 的驱动方式。

### 验证门禁

Stage B implementation 至少需要：

- HTTP+DB `_test`：V1-V21 clean migrate。
- create task、get task detail、download bytes、credential 一次性消费、过期、撤销、并发消费失败。
- FileService unavailable、empty bytes、missing fileRef、wrong credential secret、cross tenant、missing step-up proof。
- `muse.account.download-credential-secret` 通过测试属性或环境注入，测试必须证明空 secret / 错 secret fail-closed。
- `fileRef` scheme、sha256、expiresAt、consumedAt / revokedAt 或等价字段必须在 DB fact 中可验证。
- no-write snapshot 覆盖失败路径。
- focused tests、P1R mixed gates、XML 防空跑、protected diff。

### 回滚策略

Stage B 必须能通过配置关闭真实 FileService / export worker，回到 fail-closed 或 queued-only 状态，并保证已生成 credential 不再可用。

### 默认 allowed diff

Stage B implementation 默认只允许以下类别，具体文件由 stage plan 展开：

- `muse-module-member` Account export service、facade adapter、configuration、properties。
- `muse-module-member` Account export focused tests 与 facade wiring tests。
- `muse-server` 下新增 Stage B HTTP+DB `_test`。
- `docs/agent-specs/.agent` 与 stage 文档。

OpenAPI、scanner、coverage report 仍禁止修改，除非另起 completed approval 或合同变更审批。

## Stage C：usage / attribution

### 范围

覆盖 4 个 operation：

```text
account:adminListUsageRecords
account:getAppUsage
account:adminCreateCallAttributionJob
account:adminGetCallAttributionJob
```

### 默认 owner、source fact 与 worker

Stage C 默认架构如下：

- Account 子域持有 usage 聚合 read model、attribution job、job item、command/audit 和 HTTP API。
- usage source owner 仍是 AI / Content / Market / New-API 等调用发生方；Account 只能读取 owner 写入的 usage fact 或通过 owner facade 获取归因上下文，不能跨 owner 伪造 canonical fact。
- attribution source 通过 `AccountAttributionSourceFacade` 接入。真实实现默认是一个组合 adapter：读取 Account integration call / usage fact，并通过 source owner facade 校验 user/work/agent/asset/license 归属。
- attribution job 默认需要 `AccountAttributionWorker` 或等价同步执行路径。若采用同步执行，stage plan 必须证明 job 不会只停留 queued；若采用 worker，必须证明 claim、retry、terminal transition 和恢复策略。
- Stage C 默认不新增 Events outbox；job/item fact 与 audit 是主审计边界。若需要向 Events 发布 attribution result，必须单独审批 outbox。

### facade wiring 策略

当前 `UnavailableAccountAttributionSourceFacade` 是 `@Component` fail-closed 默认实现。Stage C 选定策略与 Stage A 一致：

- 移除 `UnavailableAccountAttributionSourceFacade` 的 `@Component` 默认注册。
- 新增 `AccountAttributionSourceFacadeAutoConfiguration`，通过 `@Bean @ConditionalOnMissingBean(AccountAttributionSourceFacade.class)` 注册 unavailable facade。
- 真实 attribution facade 由 stage plan 指定配置开关并作为普通 bean 注册。
- wiring test 必须证明无真实 bean 时 fail-closed，有真实 bean 时 unavailable bean 不注册且注入真实实现。

### 写命令与审计边界

`adminCreateCallAttributionJob` 必须明确：

- commandId / request hash 幂等。
- job fact、job item fact、terminal transition 的写入边界。
- audit snapshot 包含 actor、tenant、call scope、source count、result summary。
- 是否需要 outbox；如不需要，必须说明 worker 如何被调度和恢复。

### 验证门禁

Stage C implementation 至少需要：

- HTTP+DB `_test`：V1-V21 clean migrate。
- usage list/get summary 有真实 usage source fact，不从 mock 或空聚合推导。
- attribution job queued、processing、completed、failed、partially_completed。
- call whitelist、revision conflict、runtime unavailable、retry、owner/tenant 隔离。
- admin detail no-write snapshot。
- focused tests、P1R mixed gates、XML 防空跑、protected diff。

### 回滚策略

Stage C 必须能关闭真实 attribution facade / worker，回到 fail-closed 或 queued-only；已生成 job fact 保留，后续可重试或人工处理。

### 默认 allowed diff

Stage C implementation 默认只允许以下类别，具体文件由 stage plan 展开：

- `muse-module-member` Account usage / attribution service、worker、facade adapter、configuration、properties。
- `muse-module-member` Account usage / attribution focused tests 与 facade wiring tests。
- `muse-server` 下新增 Stage C HTTP+DB `_test`。
- `docs/agent-specs/.agent` 与 stage 文档。

OpenAPI、scanner、coverage report 仍禁止修改，除非另起 completed approval 或合同变更审批。

## Stage D：Market projection

### 范围

覆盖 4 个 operation：

```text
account:adminListPurchaseRecords
account:appListPurchases
account:appListLicenses
account:appListPublishRecords
```

### 依赖边界

Stage D 当前是硬阻塞，不能作为 Account-only implementation 启动。当前 Market 状态为 `32 total / 4 completed / 28 needs_verification`，而 Account 的 purchase/license/publish projection 读侧依赖 Market source fact。

Stage D 只有在以下 Market 前置条件满足后才能进入 stage plan：

- `market:purchaseAsset` 达到 completed-grade，能证明 purchase source fact、授权/支付替代合同、Account projection 输入事实。
- `market:installMarketplaceAsset` 达到 completed-grade，能证明 license / install source fact 和目标 owner 消费或明确替代合同。
- publish 相关 operation 至少完成 publish record source fact 闭环：`market:listMyPublishRecords`、`market:savePublishDraft`、`market:runPublishCheck`、`market:submitPublishRequest`、`market:withdrawPublishRequest`、`market:adminListPublishRequests`、`market:adminApprovePublishRequest`、`market:adminRejectPublishRequest`，或有单独审批的等价 Market projection source 合同。
- `MarketAccountProjectionProvider` / Market -> Account projection E2E 已通过 fresh HTTP+DB 或等价集成 gate。

满足前置条件后，Stage D 仍必须确定：

- Market purchase / install / publish 的 source fact 是否已达到 completed-grade。
- Market -> Account projection 的写入 owner、触发方式、重试方式。
- Account 读模型 `muse_account_record_projection` 与 Market source fact 的一致性合同。

coverage 目标必须用公式表达，不能提前写死：

```text
Market target = currentMarketCompleted + approvedMarketSourceProjectionOps
Account target = currentAccountCompleted + 4
Global completed target = currentCompleted + approvedMarketSourceProjectionOps + 4
```

Stage D mixed gate 必须同时断言 Account 与 Market 两个 domain 的目标值，并证明未获批 Market operation 仍为 `needs_verification`。

### 验证门禁

Stage D implementation 至少需要：

- HTTP+DB `_test`：V1-V21 clean migrate。
- Market source fact 写入后，Account projection 可见。
- purchase、license、publish 三类 `record_type` 隔离。
- stale projection、missing projection、Market projection disabled 时 fail-closed 或明确 degraded response。
- Account list read no-write snapshot。
- owner/tenant 隔离、分页排序、状态枚举。
- P1R mixed gates 必须证明 Account 和 Market 目标值只推进获批 operation。

### 回滚策略

Stage D 必须有 projection runtime switch：

- 关闭 Market projection 后 Account read fail-closed 或保持已有 snapshot，不产生新错误事实。
- projection 重放必须幂等。
- scanner/report 回滚只能在 completed approval 阶段使用。

### 默认 allowed diff

Stage D implementation 默认只能在 Market 前置条件完成后由单独 stage plan 批准。默认允许类别包括：

- Market source/projection owner 相关实现与测试。
- Account projection read gate / no-write HTTP+DB `_test`。
- P1R Account + Market mixed gate 同步。
- `docs/agent-specs/.agent` 与 stage 文档。

未满足 Market 前置条件前，Stage D 只允许写文档和只读审查，不允许实现。

## Stage E：security ack / session revoke

### 范围

覆盖 1 个 operation：

```text
account:appAcknowledgeSecurityEvent
```

### 必须先定的合同

OpenAPI 当前对 `session_revoked` action 的语义要求是真实 session revoke。当前实现返回“相关 session 撤销待人工处理，未接入 session 管理服务”，这是 fail-closed，不是 completed。

Stage E 必须二选一：

1. 接入真实 session management / token revoke owner，并验证 revoke 成功、失败、补偿。
2. 单独审阅并批准 OpenAPI 合同降级，把 `session_revoked` 改为人工处理或弱语义。

没有完成上述任一项前，`appAcknowledgeSecurityEvent` 必须保持 `needs_verification`。

只读候选入口：

- `muse-module-system` 已存在 `OAuth2TokenService.removeAccessToken(String)` 和 `removeAccessToken(Long userId, Integer userType)`。
- `muse-module-member` 的 `MemberAuthServiceImpl` 已通过 `OAuth2TokenCommonApi.removeAccessToken` 处理 logout。
- Stage E plan 必须先确认是否复用 System OAuth2 token owner 作为 session revoke owner；如拒绝复用，必须单独设计 session management owner。

### 写命令与审计边界

Stage E 必须明确：

- `commandId` 幂等、重放、冲突。
- ack row 与 security event 状态如何关联。
- session revoke command、audit、outbox 是否需要。
- revoke 失败时 ack 是否允许成功，还是必须 fail-closed。

### 验证门禁

Stage E implementation 至少需要：

- HTTP+DB `_test`：V1-V21 clean migrate。
- acknowledge success、replay、command conflict、cross tenant、missing event、expected action mismatch。
- session revoke success/fail-closed。
- audit/outbox/no-write snapshot。
- focused tests、P1R mixed gates、XML 防空跑、protected diff。

### 回滚策略

Stage E 必须能关闭 session revoke runtime 并回到 fail-closed，不能把 revoke 失败伪装为 completed ack。

### 默认 allowed diff

Stage E implementation 默认只允许以下类别，具体文件由 stage plan 展开：

- Account security ack service / facade adapter / configuration。
- System OAuth2 token owner facade 或明确的新 session owner adapter。
- Account security focused tests 与 Stage E HTTP+DB `_test`。
- `docs/agent-specs/.agent` 与 stage 文档。

OpenAPI 合同降级、scanner、coverage report 仍必须另起审批。

## 推荐执行顺序

推荐顺序：

1. Stage A：New-API / quota / integration。
2. Stage B：FileService / export / download。
3. Stage C：usage / attribution。
4. Stage D：Market projection（当前 blocked until Market source/projection 前置条件完成）。
5. Stage E：security ack / session revoke。

理由：

- Stage A 会产出 integration call 与 quota request source fact，后续 usage/attribution 可能复用。
- Stage B 独立性较强，但涉及 FileService 与 credential secret，应在 Account 外部 owner 明确后推进。
- Stage C 依赖真实 usage source 与 attribution source，不宜早于 Stage A。
- Stage D 依赖 Market owner completed-grade source fact，应等 Market projection 合同明确。
- Stage E 需要 session owner 或 OpenAPI 合同变更，风险最高，最后推进。

## 当前执行版验收标准

本执行版自身完成条件：

- 写入 `docs/agent-specs/2026-06-14-P1RAccountRemaining21解锁执行版.md`。
- 更新 `docs/agent-specs/.agent` 记录当前状态。
- 不产生 scanner/report/OpenAPI/业务实现/SQL migration diff。
- fresh spec/scope review PASS。
- fresh quality/feasibility/testing review PASS。

执行版通过后的下一步：

1. 用户选择并批准第一个 implementation stage。
2. 为该 stage 写 stage-level implementation plan。
3. stage plan fresh 双 review。
4. 用户批准后实施。
5. stage implementation fresh 双 review。
6. 再决定是否进入该 stage 的 operation-level completed approval。

## 明确禁止

以下行为不允许：

- 用本执行版直接修改 scanner/report。
- 用 fail-closed、unit test、MockMvc mock service 或历史 review 直接把剩余 21 个 operation 改为 `completed`。
- 修改 OpenAPI 来绕过真实 runtime 缺口，除非单独审阅并由用户批准。
- 把 Market projection 读侧在 Account 内孤立伪造为 completed。
- 把 Account unlock implementation 和 completed approval 混在一个未审批变更里。