oh-my-muse/docs/archive/2026-06-14-P1RAccountRemaining21解锁执行版.md

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 只能在单独合同变更审批中修改。

当前目标：

先补真实闭环和可验证 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。

当前事实基线

工作区：

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

当前 coverage summary：

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

当前 Account 状态：

total=33
completed=12
needsVerification=21

剩余 21 个 operation：

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

总体拆分

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 固定为：

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

真实 PostgreSQL _test gate 模板：

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 模板：

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

XML 防空跑模板：

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 模板：

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 不能放开这些路径：

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：

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：

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：

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：

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 目标必须用公式表达，不能提前写死：

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：

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 混在一个未审批变更里。