oh-my-muse/docs/agent-specs/2026-06-11-P1RContentCompletedApproval审阅版.md

P1R Content Completed Approval 审阅版

日期：2026-06-11

结论

不建议把 Content 51 个 operation 一次性整域推进 completed。

推荐把 Content Completed Approval 拆成 operation-level 或证据切片推进。第一候选是用户端核心作品/章节/Block 读链路，加上已经在 P1R-7f 形成 source owner propagation evidence 的 saveBlock 与 getBlockSourceAttribution。第一批建议限定为 8 个 operation：

listWorks
getWork
listChapters
getChapter
listBlocks
getBlock
saveBlock
getBlockSourceAttribution

本审阅版只冻结 Content completed approval 的范围判断、证据缺口、推荐审批粒度和后续执行版要求。不修改 OpenAPI，不修改 scanner，不修改 coverage report，不修改业务实现，也不把 Content 或其它 domain 推进 completed。

flowchart TB
    Start["当前 coverage<br/>Content 51 dedicated / needs_verification"] --> Review["Content completed approval 审阅版<br/>冻结证据标准"]
    Review --> Split{"是否整域 51/51 completed?"}
    Split -->|否，推荐| OpLevel["按证据切片 operation-level approval"]
    Split -->|是，不推荐| Domain["domain-level approval<br/>需 CRUD / source / admin / import / export / parse / planning / meta 全闭环"]
    OpLevel --> First["第一候选 8 ops<br/>work/chapter/block read + saveBlock + attribution read"]
    First --> Contract{"是否触碰创建/更新/删除合同?"}
    Contract -->|否| Exec["执行版<br/>只写 operation allowlist + real HTTP/DB gate"]
    Contract -->|是| ContractFix["先单独审批 OpenAPI/report commandId 合同修正"]
    Exec --> FreshReview["fresh spec/scope review<br/>fresh quality/feasibility review"]
    FreshReview --> UserApproval{"用户明确批准<br/>Content 状态推进?"}
    UserApproval -->|否| Stay["保持 Content 51 needs_verification"]
    UserApproval -->|是| Change["最小修改 scanner/report/gates<br/>运行 focused + P1R + _test + XML 防空跑"]

当前事实状态

工作区：

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

当前分支与远端同步，HEAD 为：

0032774 test(p1r): 收口 Market 第一批 completed approval 门禁

当前 coverage summary：

total=233
completed=131
needsVerification=102
incomplete=0
genericPersistence=0
ssePlaceholder=0

当前按 domain 聚合：

account   total=33 completed=10 needsVerification=23
ai        total=41 completed=41 needsVerification=0
content   total=51 completed=0  needsVerification=51
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

Content 51 个 operation 当前全部为 dedicated / needs_verification：

operationId	Method	Path	当前状态
adminListExportTasks	GET	/admin-api/muse/content/export-tasks	dedicated / needs_verification
adminListImportTasks	GET	/admin-api/muse/content/import-tasks	dedicated / needs_verification
adminListWorks	GET	/admin-api/muse/content/works	dedicated / needs_verification
adminGetWork	GET	/admin-api/muse/content/works/{workId}	dedicated / needs_verification
adminListChapters	GET	/admin-api/muse/content/works/{workId}/chapters	dedicated / needs_verification
adminRiskAction	POST	/admin-api/muse/content/works/{workId}/risk-actions	dedicated / needs_verification
confirmChapterParseResult	POST	/app-api/muse/chapter-parse-results/{resultId}/confirm	dedicated / needs_verification
rejectChapterParseResult	POST	/app-api/muse/chapter-parse-results/{resultId}/reject	dedicated / needs_verification
downloadExportPackage	GET	/app-api/muse/downloads/{credentialId}	dedicated / needs_verification
getExportTask	GET	/app-api/muse/export-tasks/{taskId}	dedicated / needs_verification
getImportTask	GET	/app-api/muse/import-tasks/{taskId}	dedicated / needs_verification
getParseJob	GET	/app-api/muse/parse-jobs/{jobId}	dedicated / needs_verification
listParseJobChapters	GET	/app-api/muse/parse-jobs/{jobId}/chapters	dedicated / needs_verification
batchConfirmChapters	POST	/app-api/muse/parse-jobs/{jobId}/chapters/batch-confirm	dedicated / needs_verification
retryParseJob	POST	/app-api/muse/parse-jobs/{jobId}/retry	dedicated / needs_verification
listWorks	GET	/app-api/muse/works	dedicated / needs_verification
createWork	POST	/app-api/muse/works	dedicated / needs_verification
deleteWork	DELETE	/app-api/muse/works/{workId}	dedicated / needs_verification
getWork	GET	/app-api/muse/works/{workId}	dedicated / needs_verification
updateWork	PUT	/app-api/muse/works/{workId}	dedicated / needs_verification
deleteBlock	DELETE	/app-api/muse/works/{workId}/blocks/{blockId}	dedicated / needs_verification
getBlock	GET	/app-api/muse/works/{workId}/blocks/{blockId}	dedicated / needs_verification
saveBlock	PUT	/app-api/muse/works/{workId}/blocks/{blockId}	dedicated / needs_verification
mergeBlocks	POST	/app-api/muse/works/{workId}/blocks/{blockId}/merge	dedicated / needs_verification
getBlockSourceAttribution	GET	/app-api/muse/works/{workId}/blocks/{blockId}/source-attribution	dedicated / needs_verification
splitBlock	POST	/app-api/muse/works/{workId}/blocks/{blockId}/split	dedicated / needs_verification
mergeBlockSuggestion	POST	/app-api/muse/works/{workId}/blocks/{blockId}/suggestion-merges	dedicated / needs_verification
listChapters	GET	/app-api/muse/works/{workId}/chapters	dedicated / needs_verification
createChapter	POST	/app-api/muse/works/{workId}/chapters	dedicated / needs_verification
deleteChapter	DELETE	/app-api/muse/works/{workId}/chapters/{chapterId}	dedicated / needs_verification
getChapter	GET	/app-api/muse/works/{workId}/chapters/{chapterId}	dedicated / needs_verification
updateChapter	PUT	/app-api/muse/works/{workId}/chapters/{chapterId}	dedicated / needs_verification
listBlocks	GET	/app-api/muse/works/{workId}/chapters/{chapterId}/blocks	dedicated / needs_verification
createBlock	POST	/app-api/muse/works/{workId}/chapters/{chapterId}/blocks	dedicated / needs_verification
reorderChapters	PUT	/app-api/muse/works/{workId}/chapters/{chapterId}/reorder	dedicated / needs_verification
validateDynamicFields	POST	/app-api/muse/works/{workId}/dynamic-fields/validate	dedicated / needs_verification
exportWork	POST	/app-api/muse/works/{workId}/export	dedicated / needs_verification
createExportTask	POST	/app-api/muse/works/{workId}/export-tasks	dedicated / needs_verification
createImportTask	POST	/app-api/muse/works/{workId}/import-tasks	dedicated / needs_verification
listMetaProjections	GET	/app-api/muse/works/{workId}/meta-projections	dedicated / needs_verification
getMetaProjection	GET	/app-api/muse/works/{workId}/meta-projections/{projectionKey}	dedicated / needs_verification
createParseJob	POST	/app-api/muse/works/{workId}/parse-jobs	dedicated / needs_verification
getPlanning	GET	/app-api/muse/works/{workId}/planning	dedicated / needs_verification
listPlanningCandidates	GET	/app-api/muse/works/{workId}/planning/candidates	dedicated / needs_verification
createPlanningCandidate	POST	/app-api/muse/works/{workId}/planning/candidates	dedicated / needs_verification
getPlanningCandidate	GET	/app-api/muse/works/{workId}/planning/candidates/{candidateId}	dedicated / needs_verification
confirmPlanningCandidate	POST	/app-api/muse/works/{workId}/planning/candidates/{candidateId}/confirm	dedicated / needs_verification
discardPlanningCandidate	POST	/app-api/muse/works/{workId}/planning/candidates/{candidateId}/discard	dedicated / needs_verification
createStyleCheck	POST	/app-api/muse/works/{workId}/planning/style-checks	dedicated / needs_verification
getStyleCheckResult	GET	/app-api/muse/works/{workId}/planning/style-checks/{jobId}	dedicated / needs_verification
savePlanningItem	PUT	/app-api/muse/works/{workId}/planning/{sectionKey}	dedicated / needs_verification

已验证实现证据

子代理只读盘点结论

本轮并行只读复核得到两类结论：

• 核心 Content explorer 支持先做 owned work / chapter / block / source 小批量，并从实现证据角度把 createWork、updateWork、deleteWork、createChapter、updateChapter、deleteChapter、createBlock 等也列为强候选。
• 外部依赖 explorer 明确导入、导出、解析确认、Meta projection、AI planning candidate / style check / suggestion merge 都不应进入第一批；admin read、正式 planning section 可作为后续早批候选，但应独立切片。

本审阅版没有采纳 15-operation 首批方案。原因不是这些实现一定不可用，而是当前只读盘点已发现若干创建/更新/删除写命令存在 OpenAPI / coverage requiresCommandId 口径与服务端 VO 不一致的风险。第一批若纳入这些 operation，就会把合同修正夹带进 completed approval。更稳的路线是先审批 8 个不需要修改 OpenAPI 的核心读 + saveBlock + source attribution 闭环，把写命令合同修正放到后续单独审阅。

Content owner 与入口

Content owner 位于 muse-module-content/muse-module-content-server。

现有 dedicated Controller 覆盖 Content 51 个 operation：

• AppContentController
• AppContentStructureController
• AppContentSourceController
• AppContentExportController
• AppContentImportParseController
• AppContentPlanningController
• AppContentMetaProjectionController
• AdminContentController

P1rContentRealApiGateTest 当前明确要求 Content 51 个 operation 全部保持 dedicated / needs_verification。这证明 P1R-1 已退出 catch-all / generic persistence / SSE placeholder，不证明任何 Content operation 已达到 completed 口径。

Content 本域核心服务

用户端核心作品/章节/Block 链路由 ContentAppServiceImpl 承载：

• listWorks / getWork：读取 owner 下作品。
• listChapters / getChapter：先校验 work owner，再读取章节和 Block 摘要。
• listBlocks / getBlock：先校验 work / chapter / block 归属，再读取 Block。
• saveBlock：校验 commandId、owner、expectedRevision，更新 Block，写 muse_content_block_source_attribution(source_status=active)，创建 Content event publish outbox，并记录审计。

来源归因读链路由 ContentSourceServiceImpl.getBlockSourceAttribution 承载，基于当前 Block revision 查询 muse_content_block_source_attribution 并返回来源摘要。

P1R-7f saveBlock 证据

P1R-7f 已形成以下 needs_verification evidence：

ContentAppServiceImpl.saveBlock
-> muse_content_block_source_attribution(source_status=active)
-> muse_content_event_publish_outbox
-> ContentEventPublishWorker
-> EventsPublishApi
-> muse_unified_event
-> /app-api/muse/events 对 owner 可见

该证据覆盖 saveBlock 首次成功路径、command replay 不重复创建 outbox、revision conflict 不更新 Block / 不写 source attribution / 不创建 outbox、payload allowlist、worker retry/dead_letter、V21 Flyway _test 和 dependency tree gate。

但它仍只是 source owner propagation evidence，不等同于 saveBlock API operation completed。Content completed approval 仍必须补 fresh HTTP/API + 真实 PostgreSQL _test + scanner/report/gate 同步证据。

推荐第一候选

推荐第一批候选限定为 8 个 operation：

operationId	推荐原因	必补 completed-grade 证据
listWorks	本域读侧，依赖 owner 过滤和分页，不需要外部 owner	MockMvc HTTP + 真实 DB seed，验证 owner 可见/不可见、分页和响应 DTO
getWork	本域读侧，owner guard 明确	HTTP + DB 验证存在、跨 owner forbidden/not found、DTO 字段
listChapters	本域章节读侧，先校验 work owner	HTTP + DB 验证章节排序、blockCount/wordCount、跨 owner 拒绝
getChapter	本域章节详情，返回 blocks	HTTP + DB 验证章节详情、Block 列表、章节不属 work 拒绝
listBlocks	本域 Block 列表，先校验 chapter 从属	HTTP + DB 验证列表、排序、跨 work/chapter 拒绝
getBlock	本域 Block 详情，owner/work 归属明确	HTTP + DB 验证 DTO、跨 owner 拒绝
saveBlock	本域核心写路径，已有 P1R-7f source/event evidence	HTTP + DB 验证 commandId、revision CAS、source attribution、outbox、replay、conflict no-write
getBlockSourceAttribution	与 saveBlock 形成读后验证闭环	HTTP + DB 验证当前 revision 来源、空来源、跨 owner 拒绝

推荐理由：

• 范围只覆盖 Content 本域核心 owned work / chapter / block，不进入 AI / Knowledge / Meta / FileService 等外部 owner。
• 读链路可以用测试种子建立作品、章节、Block，避免把 createWork / createChapter / createBlock 的合同缺口带入第一批。
• saveBlock 是 Content 当前最强证据链路，已有 source attribution 和 Events outbox 真实链路基础，但仍需补 API operation completed 级别的 fresh HTTP/DB gate。
• getBlockSourceAttribution 与 saveBlock 组成可验证闭环：写入当前 revision 来源事实，再读取同一 revision 的来源摘要。

替代方案是扩大到 15 个用户端 work / chapter / block CRUD operation。该方案只有在用户明确批准“先修 Content 写命令 OpenAPI / coverage commandId 合同，再做 completed approval”时才应进入执行版；默认不采用。

如果执行版按 8 个 operation 推进，获批后的目标值只能是：

total=233
completed=139
needsVerification=94
content completed=8
content needsVerification=43

该目标值只是后续获批后的执行目标，不是本审阅版当前状态。

暂不推荐第一批的切片

create/update/delete 与结构编辑写命令

以下 operation 暂不纳入第一批：

• createWork
• updateWork
• deleteWork
• createChapter
• updateChapter
• deleteChapter
• createBlock
• reorderChapters
• splitBlock
• mergeBlocks
• deleteBlock

主要原因：

• 只读盘点已发现部分写接口的 OpenAPI / coverage requiresCommandId 口径与服务端 VO 不一致。例如 WorkCreateReqVO、WorkUpdateReqVO、ChapterCreateReqVO 服务端要求 commandId，但当前 coverage 对 createWork、updateWork、createChapter 仍显示 requiresCommandId=false，OpenAPI 对 createWork / updateWork / createChapter 的 request body 也没有把 commandId 和 expectedRevision 等写命令字段完整列入 required。
• deleteWork 当前 OpenAPI 路径缺写命令 request body，而服务端 controller 使用 RevisionCommandReqVO。
• 结构编辑写命令会影响 work/chapter/block revision、排序、sourceSnapshot、审计和幂等 replay，适合在合同修正审阅后单独切片。

执行版不得为了把这些 operation completed 而顺手改 OpenAPI 或 scanner。若用户希望第二批处理写命令，必须先做 Content 写命令合同一致性审阅版。

AI suggestion 合并

mergeBlockSuggestion 暂不推荐第一批。

它依赖 ContentAiSuggestionFacade 查询 AI owner 投影，当前默认 UnavailableContentAiSuggestionFacade 明确返回 unavailable。服务端要求 suggestion status、revision、quality result、source status、authorization snapshot 和 license restriction 全部可用，不能在 AI owner 未闭合时伪造成功。

导入 / 解析 / Knowledge 草稿

以下 operation 暂不推荐第一批：

• createImportTask
• getImportTask
• createParseJob
• getParseJob
• retryParseJob
• listParseJobChapters
• confirmChapterParseResult
• rejectChapterParseResult
• batchConfirmChapters
• adminListImportTasks

主要缺口：

• ContentFileFacade 默认 unavailable，导入文件扫描、存储引用和失败阶段归 FileService owner。
• ContentParseJobFacade 默认 unavailable，Parse Job、章节解析结果和重试事实归 AI owner。
• ContentKnowledgeDraftFacade 默认 unavailable，确认解析结果后创建知识草稿归 Knowledge owner。
• 确认/批量确认链路需要 Knowledge draft 创建与 AI parse decision record 双 owner 成功，不能只凭 Content 编排服务 completed。

导出 / 下载

以下 operation 暂不推荐第一批：

• exportWork
• createExportTask
• getExportTask
• downloadExportPackage
• adminListExportTasks

主要缺口：

• ContentFileFacade.createExportPackage 和 downloadExportPackage 默认 unavailable。
• 导出包、下载凭证、packageRef、字节内容和过期校验归 FileService owner，Content 当前只能 fail-closed。
• getExportTask / admin export read 可在后续通过 DB seed 单独审批，但不应与创建/下载闭环混为一批。

Meta projection 与动态字段

以下 operation 暂不推荐第一批：

• listMetaProjections
• getMetaProjection
• validateDynamicFields

主要缺口：

• ContentMetaFacade 默认 unavailable。
• MetaSchema 解释、字段校验和写入路由建议归 Meta owner，Content 服务明确不复制 Meta 规则、不写 Content 事实表。

Planning candidate / style check

以下 operation 暂不推荐第一批：

• createPlanningCandidate
• listPlanningCandidates
• getPlanningCandidate
• confirmPlanningCandidate
• discardPlanningCandidate
• createStyleCheck
• getStyleCheckResult

主要缺口：

• Candidate 生成、候选投影、丢弃决策和 style check 运行事实归 AI owner。
• ContentPlanningCandidateFacade 与 ContentStyleCheckFacade 默认 unavailable。
• confirmPlanningCandidate 会把 AI candidate 写入正式 planning，必须验证 candidate source、quality result、authorization snapshot 和 revision，不适合混入核心 Block 第一批。

Admin governance

以下 operation 可作为后续候选，但不推荐第一批：

• adminListWorks
• adminGetWork
• adminListChapters
• adminRiskAction

理由：

• admin read 是本域读侧，但包含 RBAC、治理摘要、risk flags、word count 汇总和 admin DTO，不应与用户端核心编辑首批混在一起。
• adminRiskAction 是治理写路径，涉及 expectedVersion、行锁、targetScope、targetIds 归属、幂等 envelope 和治理动作状态，适合单独做 Admin governance completed approval。

Planning 正式 section

以下 operation 可作为后续本域候选：

• getPlanning
• savePlanningItem

理由：

• 它们主要依赖 Content 本域 muse_content_planning_section，不是外部 AI candidate runtime。
• 但 planning section 有 schemaVersion、projectionVersion、sourceSnapshot、upsert CAS 与 command replay 语义，建议作为第二批本域 planning 切片，不混入 Block 第一批。

后续执行版硬条件

如用户批准进入执行版，执行版必须先通过 fresh spec/scope review 与 fresh quality/feasibility review，且至少满足以下硬条件。

允许的最小 diff

默认允许：

• 新增/修改 Content completed approval 执行版文档。
• 更新 docs/agent-specs/.agent 的阶段状态。
• 新增 Content 第一批 completed approval 的真实 _test gate。
• 在 scanner 中只追加用户批准的 content:<operationId> operation-level allowlist，不加入 content domain-level allowlist。
• 重新生成 coverage report。
• 同步 P1R gate tests 中的 summary / Content 状态断言，以及 Account / Market / Meta 等非目标域防回退断言。
• 增强既有 Content events publish gate 仅限测试证据安全边界，例如 P1rContentEventsPublishFlywayMigrationIT 的 p1r.flyway.url/user 保存恢复与组合顺序验证；不得改变业务断言口径来掩盖回退。
• 新增 docs/memorys/YYYY-MM-DD-P1RContent状态推进.md。

默认禁止：

• 修改 Content OpenAPI。
• 修改 Content 业务实现来掩盖 coverage 缺口。
• 修改 SQL migration。
• 把 content 加入 domain-level completed allowlist。
• 把 create/update/delete/import/export/parse/planning/meta/admin operation 顺手推进 completed。

如果执行中发现必须修改 OpenAPI、业务实现或 SQL，必须停下说明原因并取得用户明确批准。

必须同步的 gate 文件

执行版必须枚举所有读取全局 summary、Content 状态，或作为 saveBlock source/event 前置证据的 P1R gate。当前至少包括：

• P1rApiCoverageReportTest
• P1rContentRealApiGateTest
• P1rEventsRealApiGateTest
• P1rAiRealApiGateTest
• P1rKnowledgeRealApiGateTest
• P1rMarketRealApiGateTest
• P1rAccountRealApiGateTest
• P1rMetaRealApiGateTest
• P1rContentEventsPublishMigrationSqlTest
• P1rContentEventsPublishDependencyTest
• P1rContentEventsPublishEndToEndTest
• P1rContentEventsPublishFlywayMigrationIT

目标值必须公式化为：

completed = 131 + N
needsVerification = 102 - N
Content completed = N
Content needsVerification = 51 - N

其中 N 只能来自用户明确批准的 Content operation。按本审阅版推荐第一批，N=8。

必须新增或增强的 runtime evidence

执行版必须包含类似 P1rContentCoreCompletedApprovalIT 的真实运行证据：

• 使用 WebApplicationContext / MockMvc 走 HTTP controller 入口。
• 使用真实 PostgreSQL _test 数据库，执行 Flyway V1-V21。
• 明确断言 Flyway current=V21、成功 SQL migration 数量为 21、V21 Content event outbox 表/索引/约束/trigger 存在，并验证 invalid outbox insert 被拒绝。
• V9 planning schema 不属于本第一批 8 个 operation 的业务验收范围；执行版不得为了本批去扩 V9 planning 业务 schema 断言。
• 使用真实 mapper / service 写读 muse_content_work、muse_content_chapter、muse_content_block、muse_content_block_source_attribution 和 muse_content_event_publish_outbox。
• 覆盖 tenant 与 owner 双隔离：至少 seed 两个 tenant，验证同 owner 不同 tenant 不可见、跨 tenant saveBlock 不写 block/source/outbox，并验证本批写入行的 tenant_id 正确。
• 覆盖 saveBlock 首次成功、command replay、revision conflict、source attribution、outbox no-duplicate / conflict no-write。
• 覆盖 getBlockSourceAttribution 当前 revision 读模型。
• 为 8 个 operation 建立 shadow-path matrix，不能只测 happy path：
  • listWorks：有数据分页、空作品页、跨 tenant 同 owner 不可见。
  • getWork：存在、ID 不存在、跨 owner / 跨 tenant 拒绝。
  • listChapters：有章节、空章节列表、work 不存在或跨 owner / 跨 tenant 拒绝。
  • getChapter：存在并返回 blocks、chapter 不存在、chapter 不属于 path work、跨 owner / 跨 tenant 拒绝。
  • listBlocks：有 Block、空 Block 列表、chapter 不属于 path work、跨 owner / 跨 tenant 拒绝。
  • getBlock：存在、block 不存在、block 不属于 path work、跨 owner / 跨 tenant 拒绝。
  • saveBlock：happy、command replay、revision conflict、缺 commandId、缺 expectedRevision、缺 sourceSnapshot、block 属于同 owner 的另一个 work、跨 owner / 跨 tenant 拒绝；所有失败路径均断言 block/source/outbox/command no-write 或事务回滚后的行数不变。
  • getBlockSourceAttribution：当前 revision 有来源、当前 revision 空来源、block 不存在、block 属于同 owner 的另一个 work、跨 owner / 跨 tenant 拒绝，且 path mismatch 不泄露 attribution。
  • 每个路径必须断言 HTTP 状态、CommonResult 体、关键 DTO 字段和 DB 行数。
• 把 P1rContentEventsPublishMigrationSqlTest、P1rContentEventsPublishDependencyTest、P1rContentEventsPublishEndToEndTest、P1rContentEventsPublishFlywayMigrationIT 纳入必跑和 XML 防空跑，作为 saveBlock completed approval 的 source/event 前置证据。
• Content completed IT 与 Content events Flyway IT 如果读取并脱敏 p1r.flyway.url/user，必须保存原始 system property 并在 @AfterAll 恢复；执行版必须包含普通顺序与 -Dsurefire.runOrder=reversealphabetical 或等价反序组合验证，防止同一 Surefire JVM 内污染后续 Flyway IT。
• 读取并校验 fresh Surefire XML，要求 tests 数量大于 0，failures/errors/skipped 均为 0，且 XML mtime 在本轮运行窗口内。
• raw Surefire XML 只作为本地验证产物；若需要外发测试报告，必须先清洗 DB host/user，且密码只能来自环境变量，不能通过 JVM system property 或 JDBC URL query 传入。

必须保留的非目标断言

执行版和实现阶段必须继续证明：

• Account remaining 23 个 operation 仍保持 dedicated / needs_verification。
• Market remaining 28 个 operation 仍保持 dedicated / needs_verification。
• Content 未获批准的 43 个 operation 仍保持 dedicated / needs_verification。
• AI / Knowledge / Events / Meta 已有 completed 口径不回退。
• OpenAPI protected diff 为空，除非用户单独批准合同修正。

待确认项

1. 是否接受 Content 第一批只审批上述 8 个 operation，不做 Content 51/51。
2. 是否接受第一批不修改 OpenAPI；创建/更新/删除写命令的 commandId 合同缺口放到后续单独审阅。
3. 是否接受后续执行版目标值按 N=8 计算为 completed=139、needsVerification=94。
4. 是否允许执行版把 P1rApiCoverageReportTest、P1rContentRealApiGateTest、P1rEventsRealApiGateTest、P1rAiRealApiGateTest、P1rKnowledgeRealApiGateTest、P1rMarketRealApiGateTest、P1rAccountRealApiGateTest、P1rMetaRealApiGateTest 的 summary / Content / 非目标域状态防回退断言，以及 P1rContentEventsPublish* gate 的必跑与测试证据安全边界修正，列为后续获批 implementation 的 allowed diff。