oh-my-muse/docs/agent-specs/2026-06-13-项目目标与模块现状基线.md
lili e181669197 chore(agent-infra): 建立 agent 开发基建、清理历史 churn 并以 BC 违例整改验证
本会话三部分交付,均经 JDK21 真实构建验证(非退出码,读 BUILD SUCCESS + Tests run):

1) Agent 开发基建(机械门禁优先)
- 入口与中枢:AGENTS.md、.agents/{knowledge,rules,skills,workflows}、CLAUDE.md 订正
- 订正 .gitignore:移除对 .agent/.agents 的忽略——它们是版本化 agent 基建,须入库(此前被忽略致克隆即缺)
- 机械门禁:CI 真跑测试(maven.yml JDK21、去 -Dmaven.test.skip)、覆盖台账去硬编码、
  BC 边界 ArchUnit 门(BcBoundaryArchTest)、契约先行门(ContractFirstGateTest:Flyway 卫生 + OpenAPI 结构)
- 单一进度源 docs/mvp/进度总账.md + 7 个 BC per-module .agent + mise.toml(锁 JDK21)
- P1 增量:AiSuggestionMergeProjectionFacade(Gap A)、ContentSourceServiceImpl 事务化 outbox 回流(Gap B)

2) 过期历史文档清理(97 份 churn,git 可恢复)
- 删 docs/memorys(34)、agent-specs 审阅/执行版+迁移review(34)、superpowers/plans+specs(25)、
  design-docs/临时+memorys(4);保留 superpowers/reports/coverage(门禁依赖)
- 唯一干货蒸馏入 .agents/knowledge/external-deps-and-gotchas.md;订正大纲/映射表/基线悬空引用

3) P1 harness 验证:消除已登记 BC 违例 ContentMuseWorkOwnerFacade
- content-api 新增只读端口 MuseContentWorkOwnerApi + content-server 实现(读自有 DAL);
  AI 适配器改消费该端口、移除全部 content.dal 依赖,AI 业务规则与 4 消费者不变
- 删除 ArchUnit 豁免 → 门禁收紧(反向红 31 例 / 正向绿;适配器单测 13/0F、端口实现 7/0F)

注:muse-studio/src(SSE 相关 4 文件)与 muse-module-ai/pom.xml(移除孤儿 contract-server)
为本会话之前已存在的未提交改动,非本次工作,未纳入本提交。

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

52 KiB
Raw Blame History

Muse(oh-my-muse)项目目标与模块现状基线

版本 v1.0
日期 2026-06-13
读者 决策与执行(管理者 / 工程执行 / 后续 Agent)
性质 项目现状基线 SSOT(单一事实源)
用途 后续工作据此进行,避免重复探索;凡与本文冲突,以经核实的代码与覆盖率台账为准
边界 只汇编"目标设计 + 模块当前真实现状";不重新设计、不下达任务。模块完成度为只读判断(未实跑 mvn/npm),已逐项标注证据

⚠️ 引用说明(2026-06-14 补):本文内联引用的 docs/memorys/*docs/agent-specs/*审阅版/执行版 过程文档已作为 churn 清理;唯一操作干货已蒸馏入 .agents/knowledge/external-deps-and-gotchas.md,完整原文见 git 历史。本文作为现状基线快照保留,内联引用路径仅供 git 追溯。

结论先行(TL;DR)

  1. 后端不是空壳,而是一套真实、较高质量的纵向实现。 9 个领域 BC 的后端代码普遍是真实业务逻辑(幂等、乐观锁、审计、Shadow→Canonical 硬闸门、真实 HTTP 外部集成),覆盖率台账 233 operation 中 147 completed / 86 needs_verification,且 catch_all / generic_persistence / sse_placeholder / missing / blocked 均为 0
  2. 历史"完成"声称是低报而非高报。 大量 CompletedApproval / 状态推进 / 收口 文档经核实异常诚实、自我设限:"completed" 是覆盖率门禁批准状态(需 HTTP 入口 + 真实 PostgreSQL + Flyway + 证据),不等于"功能端到端可用"。文档反复拒绝宣称 33/33、32/32。churn(过程文档反复重开)真实存在(34 memorys + 33 agent-specs,被项目自我诊断),但反映的是"接口未锁 + 无单一进度源"的治理问题,不是虚假交付量
  3. 三类最危险缺口(详见第六节):
    • 前端用户端(muse-studio)严重滞后:AI 候选闭环断链(后端齐全、studio 未接 suggestion-merges)、知识库工作台核心交互(草稿确认/绑定/发布/图谱)完全缺失、市场生产侧(发布/上架/申诉)无 UI、个人中心仅约 21% 端面且跑在 MSW mock 上。这是 objective"AI 先审后入"在用户可见层的落点,当前不可用。
    • 跨 BC facade 多为 Unavailable 默认实现:meta 的 impact-preview、account 的 New-API/FileService/Market 投影等 facade 仅有 fail-closed 占位,导致大量 operation 运行期返回 *_UNAVAILABLE(meta 写链路、account 21/33 端面运行期阻断)。代码诚实留白,但端到端不可用。
    • 设计承诺与机械门禁缺口:ADR 级"AI 授权包级隔离 + ArchUnit"全仓 0 依赖 0 规则(被显式后置第二期);gateway 路由未接任何 Muse BC 且保留已停用模块死路由;若误以网关为真实入口部署,Muse BC 全部 404。
  4. 真实整体完成度评估:约 76%(后端实现高、内部验证门禁中、前端用户端低、跨 BC 集成与机械门禁低)。

一、项目目标与产品意图

1.1 目标(objective)

把 Muse 从"会提取设定的文档助手 + 提示词面板",升级为面向长篇小说的多角色 AI 创作与资产流通系统:

  • 管理员治理系统能力:MetaSchema、系统级智能体、全局知识、质量门控、市场秩序、权限。
  • 普通用户在低认知负担的作品工作台里完成:写作 / 规划 / 生成 / 知识治理 / 质量感知 / 导入 / 导出;并通过智能体工作台、知识库工作台、市场来管理与流通作品 / 智能体 / 知识库资产。
  • 核心硬规则——双轨主权: AI、外部知识、市场资产一律先进 Shadow(待审层),只有用户确认或用户保存才进 Canonical(规范数据);正文保存不等于知识入库
  • 工程底座: 以 yudao-cloud fork 为底座,按 9 个领域 BC(逻辑 owner) 落地;逻辑 owner 优先于物理表 / 页面入口
  • 本仓定位: muse-design-docs(即 oh-my-muse)是设计 SSOT,只定义目标设计与 owner 归属,不承载运行时代码

1.2 意图(intent)

让长篇创作者获得"可控、可解释、越用越懂当前作品"的 AI 协作:

价值 含义
用户主权 AI 不黑盒改稿,先审后入
长期知识与叙事闭环 人物/关系/事件/世界规则沉淀为可确认可检索资产,已确认知识真正回流到下一次生成上下文
不止守一致性 还推进弧线/悬念/节奏/张力(质量门控 + 创作健康度)
资产飞轮 作品/智能体/知识库变成可复用、可授权、可流通的资产
管理员价值 系统能力可配置、可回滚、可审计,不散落进创作流程

非目标(明确排除): 一键全自动黑盒写作机;通用智能体平台 / 通用 RAG SaaS / 阅读分发社区;市场本阶段不做完整电商支付结算 DRM。


二、总体计划(overallPlan)

两条线并存:

2.1 技术依赖线 S0S5

S0 基础设施补齐 → S1 RAGFlow 集成与知识检索基座 → … → AI 编排/质量评测闭合(见 doc/dev/01-09,本次未深读,来源为映射表与 ADR 引用)。

2.2 产品形态 / 信息架构门禁线 IA-0..IA-3

不重排 S0S5,是产品与文档对齐门禁:

门禁 内容
IA-0 角色边界与信息架构重构(管理员/普通用户/个人中心入口与权限边界)
IA-1 普通用户作品工作台(我的作品 + 作品工作台 + 单作品深层流程)
IA-2 管理员控制台(配置能力/权限/审计/接口归属)
IA-3 作品规划台与高质量小说维度(规划维度进入 AI 辅助/上下文/检查链路)

2.3 工程承接节点("阶段 7")

fork yudao-cloud:保留 system/infra/framework/gateway/member/pay/bpm/report/mp,补 content/knowledge/ai/market/meta 五个 Muse 业务模块。

作品资产能力默认全部 Feature Gate 关闭(template/reference/ai_context=false),开启前必须先补:ADR + 产品-02C owner + Schema/API + 使用预检 + 来源 lineage + 授权快照 + 导出限制 + 状态机承接。


三、系统架构

3.1 四仓协作

角色 技术栈
muse-cloud 后端主仓(SSOT 落地为代码);fork YunaiV/yudao-cloud,继承网关/权限/基础设施/文件/任务,补 content/knowledge/ai/market/meta 五业务模块,account 由 member 承载 Java 21 + Spring Boot 3 + PostgreSQL(JSONB,ADR-003)+ Yudao Cloud + Sa-Token(ADR-013)
muse-admin 管理端;只调 /admin-api/**,复用 Vben,承载系统治理/MetaSchema/Prompt-Agent/全局知识/市场治理/用户权限/审计/质量观察 Vue 3 + Vben Admin + TS;fork yudao-ui-admin-vben
muse-studio 用户端;只调 /app-api/**,承载我的作品/作品工作台/写作台/规划台/智能体工作台/知识库工作台/市场/个人中心;不暴露系统 Prompt/Pipeline/后台配置 React + Vite(或 Next.js)+ TS;编辑器 Block 级 schema(ADR-004),Block 用 UUID(ADR-007)
muse-design-docs(本仓 oh-my-muse) 产品/架构/流程/前端/后端/专题设计的单一事实源;只定义目标设计与 owner 归属,不承载运行时代码/CI/部署 Markdown + SQL

最高级别不变式: Shadow→Canonical 双轨主权——AI/市场/外部知识默认不可信,只能产生候选/草稿/快照/任务结果;正式作品事实只能由用户确认、用户保存或目标 owner 显式规则写入;正文保存不等于知识入库。横切契约 Source/Authorization 采用事件驱动 + 各模块自治(来源 owner 发 Source Status Event,消费方直接决策 active/disabled,无 needs_recheck 中间态)。逻辑 owner 优先于物理表/代码模块/页面入口(ADR-015)。

3.2 业务域(9 BC)

key 名称 物理 owner 核心职责(摘要)
ai AI Orchestration BC yudao-module-ai(二开,grant vs runtime 包级隔离 + ArchUnit) 链路编排/上下文组装/生成/分析/全书解析/质量门控/AI 候选(Suggestion)/规划候选/风险标记/Quality Result/运行记录;承载 Protection Node(grant)与 Quality Policy。只产 Shadow,绝不直写 Canonical;只消费服务端签发的 Runtime Permission Envelope,不能自授权
content Work/Content BC yudao-module-content Work/Chapter/Block/正文版本/Block Source Attribution/Import-Export/Planning Canonical/Narrative State。正文 Canonical 唯一写入方;Block 写入须带 expectedRevision 且 revision 单调递增。Accept Suggestion 是候选进正文的唯一合法入口,只写正文 + 候选归档 + 来源归因,不写 Local KB
knowledge Knowledge BC yudao-module-knowledge Local KB / User KB / 全局知识处理 / Knowledge Draft / Knowledge Source Binding / 投影与索引状态。进 Local KB 唯一入口是用户显式确认草稿或手动修正;全书解析章节确认只产/推 Draft,不写正式知识。来源优先级:Local KB > 用户绑定知识 > 市场/全局知识
market Marketplace/Asset BC yudao-module-market 市场资产(Work/Agent/KB Asset)/Publish Draft/Publish Check Snapshot/Review/Listing/License/Purchase/Install/Handoff Token/授权摘要/跳转审计/Governance Action/Source Status Event。授权≠所有权转移;市场不是源事实 owner;目标事实回目标 owner。作品资产当前仅阅读/收藏/授权记录,模板化/参考写入/AI 上下文受 Feature Gate 默认关闭
meta MetaSchema BC yudao-module-meta(独立模块) 元结构定义:字段类型/校验/枚举/引用/领域/范围/目标类型/可见性/AI 上下文/导出语义;控制 uiVisible/aiContext/userEditable/userSearchable/exportable。admin 写全局定义,用户作品级覆盖扩展字段,业务模块经 facade-api 只读消费投影。ADR-016 已将其从 Admin/Governance 拆出独立;后端-03 §3 仍残留旧表述,属文档内部待统一点
events Source/Authorization 横切上下文(事件驱动) 来源对象 owner + outbox 协作(source_snapshot DDL 归 infra) 贯穿 content/knowledge/agent/ai/market/account/导出/个人中心的横切契约,非独立 source 模块(ADR-017)。Source Snapshot/Authorization Snapshot/Source Status Event/Source Propagation Target。各消费模块自治监听并直接决策 active/disabled;传播失败 fail-default 禁用新使用;不自动回滚已确认 Canonical
account Account/Usage/Audit BC yudao-module-member(已决策承载,不新增 account 模块) Profile/Entitlement-Quota/Usage Record/Personal Center Summary/记录总览/Security Event/New-API Binding/Audit Log/Download Credential。是用户可见权益的聚合读模型与跳转入口,不是消费账本事实源,不能反写作品/知识/智能体/市场事实。高危审计 append-only + WORM/哈希链,读取与导出本身也被审计
platform 平台底座(Identity/Auth + Admin/Governance + Integration + Yudao 基座) yudao-module-system/infra/ai.grant/meta + Integration facade + gateway/framework/server Sa-Token 认证授权;系统功能链路/开放槽位/系统 Prompt/保护节点注册表;Integration(New-API/RAGFlow/GraphRAG/文件/通知外部适配,只存绑定引用/correlationId/idempotencyKey,不复制供应商路由与底层成本日志 authority)。Yudao 基座绝不承载 Muse 创作业务事实;系统任务必须用明确服务身份,不复用用户权限绕过 Shadow→Canonical

3.3 已确认决策(ADR 摘要)

决策 结论
模块化单体优先(ADR-001) 默认模块化单体,清晰边界/本地事务/低成本;痛点可量化时才拆服务,但业务事实源与用户确认边界必须回 Muse
Shadow→Canonical 数据主权(ADR-003/架构-02) AI 只产 Shadow;正文保存≠知识入库;非谈判项,不能被实现绕过
AI 能力经外部受信 Agent 服务(ADR-002) Muse 负责权限/上下文组装/调用/结果消费/Shadow 写入;Agent 服务不得直接写库
向量检索用 RAGFlow 替代 pgvector;图查询依赖 RAGFlow GraphRAG 不自建图存储(ADR-005/006) PG 不存 embedding 作主检索;不引入 Neo4j;需降级与投影重建路径
管理员控制台独立入口(ADR-008/原则1.2) 前端 IA/权限/审计按角色分离;管理员配置经配置快照影响生成链路;治理权分层无单一超级权限
Sa-Token 作认证授权基座(ADR-013) 承担登录/RBAC/鉴权/会话/基础审计;但不决定作品事实是否进 Canonical,业务规则仍由 Muse 控
阶段7 fork yudao-cloud,逻辑 owner 优先(ADR-014/015) yudao-cloud 作工程基座与过渡物理落点;逻辑 owner/facade/状态机/写入边界以 BC 为准;跨 BC 写入走 owner facade
Governance 按消费者拆散,MetaSchema 独立(ADR-016) MetaSchema→独立 BC;Protection Node + Quality Policy→AI grant 包;市场治理→Marketplace admin 包
Source 传播=事件驱动各模块自治;去 needs_recheck(ADR-017/018) 无独立 source 模块与 Candidate Decision Envelope;候选接受时实时对比来源版本 + 同步质量/合规/静态检查;source_snapshot 独立表 DDL 归 infra
AI 授权包级隔离(grant vs runtime)+ ArchUnit runtime 包禁调 grant 写入;工具调用/上下文读取/外发须经服务端 tool broker 校验不可变 envelope。⚠ 现状:全仓 0 ArchUnit,被显式后置第二期,当前仅软约束
Account 物理落 member,不新增 account 模块 member = 端侧用户 = Account BC 物理承载,扩 Entitlement/Quota/Usage/Security/Binding;唯一写入 authority
New-API 职责边界(ADR-009) New-API 保供应商路由/限流/成本/原始日志 authority;Muse 只保绑定引用/任务摘要/归属/correlationId/幂等;凭据禁入日志/Prompt/候选/导出/用户错误
作品资产能力 Feature Gate 默认全关 template/reference/ai_context_enabled=false;开启前须补 ADR + owner + Schema/API + 预检 + lineage + 授权快照 + 导出限制 + 状态机

3.4 核心数据模型

双轨三层模型(架构-02 为权威):

含义 内容
Canonical 规范数据(正式事实) 正文 / 正式规划项 / Local KB / User KB 资料 / 智能体版本 / 市场授权记录
Shadow 待审层(默认不可信) AI 候选 / 规划候选 / 知识草稿 / 解析结果 / 风险标记 / 质量结果
Archive 归档层(终态历史) 先同表 + status 过滤,后续按量分离

进入 Canonical 的合法入口仅 7 类: 用户保存正文 / 接受候选 / 确认规划候选 / 确认知识草稿 / 维护 User KB / 管理员发布系统配置 / 市场授权安装。且接受候选不自动确认知识草稿。

  • 内容骨架: Work > Chapter > Block(UUID,场景/小节级粒度,expectedRevision 乐观锁);不为 Scene 单独建一级模型(ADR-012);规划维度复用 MetaSchema/Narrative State/Work/Chapter/Block(ADR-011)。
  • 三类知识库: Global KB(管理员)/ User KB(用户跨作品复用)/ Local KB(单作品正式事实)。
  • 横切 value object: Source Lineage / Source Snapshot(独立 source_snapshot 表)/ Authorization Snapshot(消费方须存快照 id 或不可变指纹,不能只存布尔)/ Block Source Attribution / Agent Runtime Permission Envelope(服务端签发不可变,前端/智能体/AI runtime 自报无效)。
  • 动态属性用 JSONB + 属性级变更日志而非 EAV(ADR-003)。

四、模块现状总表

实现层: 已落地 / 缺失 / ⚠ 受限或薄层。完成度为只读判断,口径见各模块详情。

模块(BC) server api contract 前端 DB迁移 测试 真实完成度 构建 契约一致性 置信度 最关键风险
AI 编排 (muse-module-ai) 72% 未实跑/可编译 较好有偏差 high ADR 级包隔离+ArchUnit 缺失(软约束);前端全 MSW,SSE 疑漂移;真实 New-API 未端到端验收
作品/编辑器 (muse-module-content) 82% 未实跑/可编译 高度一致 high 前端 Accept Suggestion 断链:后端齐全但 studio 未接 suggestion-merges,AI 候选进正文用户端不可用
知识库 (muse-module-knowledge) 72% 未实跑/可编译 高度一致 high 前端 2/3 面缺失(草稿确认/绑定/发布/图谱无 hook);Task4 跨 BC owner 未实现;recheck/worker 默认未生效
市场 (muse-module-market) 82% 未实跑/可编译 高度一致 high studio 仅消费侧(浏览/授权/安装);生产侧发布/上架/申诉无 UI,飞轮 UI 层断裂
元治理/MetaSchema (muse-module-meta) 82% 未实跑/可编译 高度一致 high impact-preview facade 仅 Unavailable→写链路运行期端到端阻断;facade-api 缺失,跨 BC 投影消费契约未建立
事件/SSE (muse-module-events) 88% 未实跑/可编译 后端一致/前端漂移 high 前端 connectAIStream 契约漂移(被 mock 掩盖,真实联调会失败);统一事件客户端为孤儿无 UI 消费
账户/个人中心 (muse-module-member) 68% 未实跑/可编译 端点齐/约2/3运行期降级 high 跨 BC facade 全 Unavailable→21/33 端面运行期 *_UNAVAILABLE;前端仅约 21% 面且跑 MSW
平台底座 (gateway/system/infra/pay/bpm/mp/report + 两前端接线) (设计如此) (沿用 yudao) 80% 未实跑/可编译 无契约(符合设计) high gateway 路由未接任何 Muse BC + 保留死路由;pay/bpm/mp/report 显式停用 0 运行覆盖;底座 schema 未 Flyway 化

说明:api ❌ 表示该 BC 的 -api 子模块仅 package-info / ErrorCode(meta、account 无对外 facade-api DTO,knowledge 的 api 仅 ErrorCode,market 的 api 刻意薄属 yudao 风格,均非"缺失业务"而是"对外 RPC 契约未建立或无需");contract ❌ 平台底座属设计上不为 yudao 基座单独定契约。

覆盖率台账(盘中实读 docs/superpowers/reports/p1r-api-coverage.json):

指标
totalOperations 233
completedOperations 147
needsVerificationOperations 86
incomplete / catchAll / genericPersistence / ssePlaceholder / missing / blocked 全部 0

逐域 operation 计数(契约口径,与台账逐项吻合): account 33 / ai 41 / content 51 / events 1 / knowledge 59 / market 32 / meta 16。台账 domain 仅含这 7 个 BC,平台底座无"完成"声称(它是被继承的 yudao 基座)。


五、逐模块详情

5.1 AI 编排(muse-module-ai)— 完成度 72%

实现摘要: 后端 muse-module-ai-server 是真实较高质量实现(364 个 Muse java 文件 / 35 DO / 35 Mapper / 14 admin + 6 app Controller / ~30 service+facade,无 TODO/FIXME/stub)。核心链路:AppMuseAiTaskController(create/get/SSE/试用 Agent,带 X-API-Version guard + getLoginUserId)→ MuseAiTaskServiceImpl(712 行:幂等命令回放 reserveCommand、@Transactional、SourceSnapshot 构建、Agent 解析、Runtime Permission Envelope 签发 + Guard 校验、写 muse_ai_generation/job)→ MuseAiRuntimeServiceImpl(22 行薄壳,故意只稳定 contract)→ RealNewApiMuseAiRuntimeClient(419 行,Java21 HttpClient 真打 New-API /v1/chat/completions,超时/异常分类/token 脱敏/retryable)与 UnavailableMuseAiRuntimeClient(fail-closed),由 AiAutoConfiguration @Conditional 装配。SSE:MuseAiTaskStreamServiceImpl(377 行)已脱离占位,轮询持久化事件 + replay + keepalive + 终态互斥。Suggestion:MuseSuggestionServiceImpl 只做 list/get/reject(accept 正确不在 AI 域,归 content BC)。DB:V4 + V12/V13/V17,22 张表。测试 ~25 个 Muse 测试。契约 38 path / 41 operation 与后端基本对位。

桩与缺口:

  • muse-module-ai-contract-server 整模块空壳(仅 pom,0 java),且 muse-server 已改依赖 -server,成为孤儿 submodule
  • ArchUnit + grant/runtime 包级隔离:全仓 0 依赖 0 规则 0 包目录,实为类命名约定 + 运行时 Guard 软约束。
  • 真实 New-API 端到端未验收(P1R4 smoke qwen3.5/doubao 超时);本地无配置即 fail-closed 全失败。
  • Evaluation run 起 job 但同步评分/LLM-judge 闭环深度未见(疑 job 异步延迟)。
  • 前端 agent 特性 DEV 全程 MSW(8 端点全 mock),真实连通未验证;AgentPageWORK_ID_FOR_SLOT_PREVIEW 硬编码;AI-stream SSE 与契约疑 drift(有独立待办 chip)。

设计 vs 现实差异: ADR/CLAUDE.md 反复声称"AI 授权包级隔离 + ArchUnit",现实为软约束(被 2026-06-13 评审文档明确"列入第二期不实施")——有意后置而非偷工,但设计承诺的硬隔离未达成

"完成"声称 vs 现实: AI 域是文档低报而非高报。 2026-05-30-P1R4AI真实API规格计划.md 全程坚持 completedOperations=0、明确 streamAiTask 曾是 sse_placeholder、记录 New-API smoke 超时拒写"已完成"。代码现实强于其保守声称。唯一名实不符是 ArchUnit/包隔离承诺(被显式后置)。

证据(file:line):

  • muse-cloud/muse-module-ai/muse-module-ai-contract-server/pom.xml:1(整模块仅此,0 java)
  • .../application/muse/MuseAiTaskServiceImpl.java:98-128(幂等+事务+envelope guard)
  • .../application/muse/facade/RealNewApiMuseAiRuntimeClient.java:43-74(真实 HttpClient + 异常分类)
  • .../application/muse/facade/UnavailableMuseAiRuntimeClient.java:13-18(fail-closed)
  • .../framework/ai/config/AiAutoConfiguration.java:317-329(@Conditional 装配)
  • .../application/muse/MuseSuggestionServiceImpl.java:66-127(reject,无 accept,符合 content owner)
  • .../application/muse/MuseAiTaskStreamServiceImpl.java:57-95,144(SSE 真实)
  • muse-server/pom.xml:114(依赖 -server 非 contract-server,证孤儿)
  • 全仓 grep archunit/ArchRule = 0 命中
  • docs/memorys/2026-05-30-P1R4AI真实API规格计划.md:49,115,448(拒写 completed;smoke 超时)
  • muse-studio/src/main.tsx:9-11 + src/api/mocks/handlers/ai.ts:130-305(DEV MSW 全拦截)

5.2 作品/编辑器(muse-module-content)— 完成度 82%

实现摘要: 后端 159 java 文件,51 个端点(app 44 + admin 6)精确等于契约 51 个 HTTP method,全部委派到 Application Service 含真实逻辑:乐观锁(expectedRevision/revision 单调递增 CAS)、commandId 幂等、owner/租户 guard、审计、Shadow→Canonical 硬闸门。核心:split/merge/reorder(临时负序号重排避唯一键 + 双 Block 来源归因)、Accept Suggestion(mergeBlockSuggestion)严格前置校验(来源版本/授权快照/许可/合规/静态检查/质量结果版本逐项,外部 owner 不可用即 blocked 不伪造)、Planning 候选确认写 Canonical、Import/Parse Job 状态机、Export + download credential 校验、Meta 投影/动态字段、事件 outbox。DB:V1(7 表)+ V9 + V21。测试 21 类,断言密度高(53-95/类),7 个 app controller MockMvc 测试。前端 WorkspacePage 真实消费 + MuseEditor 真实自动保存(2s 防抖 + IndexedDB)。

桩与缺口:

  • 前端 Accept Suggestion 断链: studio 无 suggestion-merges 调用,EditorPage.handleAcceptDiff 仅本地 setContent,纯前端文本替换,不落库、不写来源归因、不带 suggestionId/expectedRevision。
  • EditorPage 是演示壳: chapters 硬编码、workId='demo-work'blockId='b-${id}'、revision=1 硬编码。
  • AIPanel 候选不携带 suggestionId,无法走后端校验闸门。
  • 真实编辑路径(WorkspacePage)未挂 AIPanel/CandidatePanel,真实路径与 AI 候选路径 UI 未合流。
  • 字数统计 P1R-1 用字符 length 占位;useChapterDelete 前端 expectedRevision=1 为 mock。
  • 域级 content 43/51 operation 自评仍 needs_verification(验收门禁滞后于代码,非代码缺口)。
  • authorization_snapshot_id 表为 BIGINT,非数值外部授权快照被静默丢弃(已知表能力限制)。

设计 vs 现实差异: 后端与设计高度一致;差异集中在前端 AI 候选闭环未对齐专题-01。存在两套编辑器(真实 WorkspacePage 无 AI 面板 / 演示 EditorPage 有面板但全硬编码),易误判已打通。

"完成"声称 vs 现实: 历史文档属实且异常诚实2026-05-27-P1R1内容真实API收口.md 明确"完成口径不是标 completed";2026-06-12-P1RContent状态推进.md 自述"本轮未修改 OpenAPI/业务实现/SQL",仅把 8 个 operation 推 completed、列其余 43 仍 needs_verification。churn 是门禁审批 bookkeeping 反复刷,非反复声称写完代码;声称比现实更谦虚。

证据(file:line):

  • ContentStructureServiceImpl.java:77-214(split/merge:CAS + 临时负序号 + 双 Block 归因)
  • ContentSourceServiceImpl.java:73-204(mergeBlockSuggestion 逐项前置校验,外部不可用 throw EXTERNAL_OWNER_UNAVAILABLE)
  • ContentExportServiceImpl.java:102-163(download credential 校验)
  • ContentPlanningServiceImpl.java:148-179(confirmPlanningCandidate 写 Canonical)
  • sql/muse/V1__init_content_schema.sql:13-180(7 表 + 约束 + 触发器)
  • muse-studio/src/pages/EditorPage.tsx:17-21,114-117,47-55(演示壳硬编码 + handleAcceptDiff 仅 setContent)
  • muse-studio grep suggestion-merges 仅命中 types/content.ts:358(生成类型),无实际调用
  • muse-studio/src/pages/WorkspacePage.tsx:31-36(真实消费,但无 AI 面板)
  • docs/memorys/2026-06-12-P1RContent状态推进.md(completed=8 needs_verification=43)

5.3 知识库(muse-module-knowledge)— 完成度 72%

实现摘要: 本仓最完整业务模块之一。59 端点(app 36 + admin 23)与契约 48 path/59 method 精确对齐;service 共 6443 行(DocumentService 1068/KnowledgeBaseService 951/DraftService 646)。confirmKnowledgeDraft 真把 Shadow 草稿物化为 Canonical 实体/关系(entityMapper/relationMapper.insert),带冲突检测、决策审计、commandId 幂等、sourceVersion 追踪。RAGFlow 是真 HTTP:HttpRagFlowKnowledgeRuntimeClient(621 行)调 /api/v1/datasets/api/v1/retrieval/run_graphrag/knowledge_graph,Bearer + SSRF 防护 + 超时 + 18 类 FailureClass,并有 Unavailable* 优雅降级(ADR-006)。绑定预检存 sourceSnapshotId/authorizationSnapshotId/handoffHash;发布 readiness/snapshot;source-event 传播;outbox worker。DB:V5(7 表)+ V14(18 表)+ V18 ≈ 26 张。测试 38 文件 209 @Test,含真实 RAGFlow 验收 IT。前端 useKnowledge.ts(405 行)真调 /knowledge-bases/installed-knowledge-bases/documents,但仅覆盖约 1/3 面。

桩与缺口:

  • 跨 BC owner 计数未实现(Task 4): installed KB owner / document owner count / export_task_owner 以 'unsupported'/'not implemented in Task 4' 占位返回。
  • recheck 仅记状态,未做外部来源真实重校验('external source validation is not configured')。
  • linkUrl 材料化 fail-closed(无 SSRF allowlist/隔离抓取前一律拒绝),功能未通。
  • outbox 发布 worker 默认关闭,启用需运维配置。
  • 前端缺失核心 Shadow→Canonical 用户面: 无 drafts confirm/ignore/recheck、无 bindings、无 publish、无 entities/relations、无 graph 的 hook 与页面(约 2/3 前端面缺)。
  • 用户面 /graph/local-knowledge 服务的是 Canonical 实体/关系投影,非 RAGFlow GraphRAG 实时图(架构自洽,但与"图查询依赖 RAGFlow"直觉读法有差异,需对齐确认)。
  • admin 端知识库视图存在但本次未深核接通度。

设计 vs 现实差异: 后端与设计高度吻合(Shadow→Canonical/RAGFlow 替代 pgvector/不自建图/事件驱动);若干 scoped 落差多为已注释而非隐藏空壳。最大落差在前端:草稿确认/绑定/发布/图谱用户面完全缺失。

"完成"声称 vs 现实: 非典型 churn,历史 memory 异常克制。06-01 P1R5"只完成规格/计划不进代码";06-06 P1R7c"不能推断已完成、不能推进 completed";06-09 P1R7CompletedApproval 才标 knowledge 59 dedicated/completed 并纳入 APPROVED_COMPLETED_DOMAINS={ai,knowledge}关键校正:该 completed 是 backend operation-level 覆盖门禁口径,未声称前端完整或外部依赖闭合;读作"知识库工作台端到端完成"会高估。

证据(file:line):

  • MuseKnowledgeDraftService.java:105-145(confirmKnowledgeDraft 真物化 Canonical entityMapper.insert@302/relationMapper.insert@330)
  • MuseKnowledgeDraftService.java:194(recheck 'external source validation is not configured')
  • HttpRagFlowKnowledgeRuntimeClient.java:1-621(真 HttpClient 调四端点 + Bearer)
  • UnavailableRagFlowKnowledgeRuntimeClient.java:9-60(ADR-006 降级)
  • MuseKnowledgeBaseService.java:221-248(Task 4 scoped 缺口占位)
  • MuseKnowledgeGraphQueryService.java:41-69(读 Canonical 投影非实时图)
  • sql/muse/V5/V14/V18(7+18+outbox 表)
  • muse-studio/src/pages/KnowledgePage.tsx:18,53,266(仅 KB list + MaterialManager + CreateKBModal;drafts/bindings/publish/graph 无 hook)
  • docs/memorys/2026-06-09-P1R7CompletedApproval状态推进.md:53,94(knowledge 59 completed;DOMAINS={ai,knowledge})

5.4 市场(muse-module-market)— 完成度 82%

实现摘要: 后端成熟真实。32 方法级端点(app 21 + admin 11)与契约 32 operation 完全对齐。13 service 约 5537 行(AdminMarketReviewServiceImpl 840/MarketPublishServiceImpl 819/AdminMarketGovernanceServiceImpl 805/MarketAppealServiceImpl 770)。覆盖:资产发现/详情/分类/推荐、收藏、授权、安装、bind-precheck、handoff、发布(草稿/检查/提交/撤回)、管理端审核(真实状态机 pending→submitted→reviewing→approved/rejected/listed)、治理(下架/召回/影响预览)、申诉、Account 投影 outbox、Events outbox+worker。DAL 真实 MyBatis-Plus(insertIgnore 幂等、updateByExpectedStatus 乐观锁)。23 张表(V6 + V8/V15/V19)。横切契约真实落地。前端:muse-admin 治理台真实(index.vue 1166 行 + 22 API 函数);muse-studio 仅 MarketBrowse 一个组件(浏览/分类/授权/安装)。测试 209 @Test、1271 assert、6781 行。

桩与缺口:

  • studio 用户端仅消费侧: 发布(publish-drafts/requests)、handoff 跳转、申诉(appeals)、授权记录/license 详情在 studio 无 UI(仅后端 + 契约 + admin 就绪)。
  • 32 op 中 28 仍 needs_verification(非空壳,缺 MockMvc/真实 DB 正式验收证据);listMarketplaceAssets 缺分页边界证据,recommendations 个性化语义待澄清。
  • muse_market_favorite 的 status 无 DB 级 CHECK,asset_id/user_id 无 FK(schema hardening 待办)。
  • recommendations 为可解释 fallback 排序而非真实个性化(有意降级非桩)。

设计 vs 现实差异: 核心不变式已被代码强制:install/handoff targetFactsWritten=false、work 资产强制 read-only 且排除出 install(INSTALLABLE_ASSET_TYPES=Set.of(agent,knowledge_base))、授权≠安装≠绑定、事件驱动各模块自治。差距=studio 仅"浏览/授权/安装"闭环,发布/handoff/申诉无前端。

"完成"声称 vs 现实: 无虚报,代码比文档声称更完整。 2026-06-11-P1RMarket状态推进.md 明确 Market 仅 4 completed/28 needs_verification,显式禁止宣称 32/32。盘中校验磁盘 coverage json:market 4 completed + 28 needs_verification,与 memory 完全吻合未被篡改。真正风险是闸门状态让人"低估"完成度,而非高估。

证据(file:line):

  • MarketInstallServiceImpl.java:41,62-65,96(INSTALLABLE_ASSET_TYPES;work 抛 NOT_BINDABLE;targetFactsWritten=false)
  • MarketPublishServiceImpl.java:671-682(work 强制 read-only)
  • AdminMarketReviewServiceImpl.java:53-62,99-120(状态机 + approve 幂等回放)
  • sql/muse/V6 + V8/V15/V19(23 表)
  • MarketEventPublishWorker.java:6-46(EventsPublishApi + 重试)
  • muse-server/pom.xml:74 + muse-cloud/pom.xml:23(已装配)
  • muse-studio/src/features/market(仅 MarketBrowse.tsx + useMarket.ts,无 publish/handoff/appeal/license)
  • muse-admin/.../views/muse/market/index.vue(1166 行真实治理台)
  • docs/memorys/2026-06-11-P1RMarket状态推进.md(completed=4/needs_verification=28,禁止宣称 32/32)

5.5 元治理/MetaSchema(muse-module-meta)— 完成度 82%

实现摘要: 本次核查完成度最高最扎实之一。后端 16 admin 端点(3 controller)与契约 16 operation、前端 16 API 函数 1:1 对齐MetaSchemaServiceImpl(1217 行)实现 list/detail/version/saveDraft/publish/activate/rollback/deprecate/gray-rules 完整状态机,含 expectedVersion 乐观锁、validationResultId + impactPreviewId 双引用门禁、快照、灰度、全程审计;MetaSchemaValidationServiceImpl(386 行)字段/枚举/relation/保护节点边界(replaceable=false 不可解绑)/兼容性 breaking 真实校验;FunctionChainServiceImpl(804 行);MetaCommandServiceImpl 真实幂等引擎(SHA-256 + insertIgnore reserve/replay)。DB:V3(6 表)+ V10(8 表 + ALTER)= 14 张。前端 admin 真实接 API(meta-schema.ts 757 行 + detail.vue 1123 行)+ vitest。测试 165 @Test/592 断言/~5449 行,含 route ownership 与 wildcard 退役断言。

桩与缺口:

  • MetaImpactFacade 唯一实现 UnavailableMetaImpactFacade 直接抛 META_EXTERNAL_OWNER_UNAVAILABLE。 因 publish/activate/rollback/deprecate 均经 requireImpactPreview 硬性要求一条 succeeded 的 impact-preview,而 impact-preview 在 Content/Knowledge/AI 真实 facade 接入前必失败——MetaSchema 治理写链路结构完整但运行期端到端被阻断(诚实留白,但"可发布"目标当前运行期不可达)。
  • facade-api 层缺失: muse-module-meta-api 仅 package-info;content/knowledge/ai 0 处引用 meta,投影消费契约尚未建立(crippled/orphan 风险)。
  • muse-studio 用户端元引擎/动态表单(前端-03)未实现: 仅自动生成的 admin 治理类型(types/meta.ts 1560 行),无消费 MetaField 渲染动态表单的组件(与"用户作品级覆盖扩展字段"目标有差距)。
  • 投影 rebuild/invalidate 仅返回 pending job id,不真正驱动 Content/Knowledge 投影执行。
  • FunctionChain impact-preview 的 affectedAgentSlotBindings/affectedAIRuntimeTasks 固定 0(AI runtime 无真实 owner)。
  • AdminMetaSchemaController 类级 Javadoc 过时(称写接口"留给后续实现",实际已全实现)。

设计 vs 现实差异: 三处实质差异均如上(impact-preview 阻断、facade-api 缺失、用户端元引擎缺失),均为"本地逻辑完整、外部依赖/用户侧待接"的透明降级。

"完成"声称 vs 现实: 是 churn 怀疑的反例,git 仅 4 次提交触及。memos 高度诚实:05-28"没有把 Meta 标为 completed";06-10 两份是 coverage 簿记"未修改业务实现""APPROVED_COMPLETED_DOMAINS 仍只有 ai/knowledge"(用 operation 级 approval,未把 meta 整域列白名单)+ 新增真实 PG Flyway IT。唯一名实落差:completed 覆盖含义≠运行期可端到端跑通(因 impact-preview facade 不可用)。memos 本身未声称运行期闭环,不构成虚假完成。

证据(file:line):

  • AdminMetaSchemaController.java:64-176(11 端点全实现);:45-50(过时 Javadoc)
  • MetaSchemaServiceImpl.java:199-486(状态机);:634-646(requireImpactPreview 硬门禁);:909-915(projectionJobId 仅 pending)
  • facade/UnavailableMetaImpactFacade.java:15-24(唯一实现抛 unavailable)
  • MetaSchemaValidationServiceImpl.java:127-224(字段/保护节点/兼容性真实校验)
  • MetaCommandServiceImpl.java:36-135,248(SHA-256 幂等)
  • sql/muse/V3:4-118(6 表);V10:4-239(8 表 + ALTER)
  • muse-module-meta-api/.../package-info.java(无 facade-api)
  • muse-admin/.../governance/meta-schema/detail.vue(1123 行)
  • muse-studio/src/types/meta.ts:1-7(auto-generated,非元引擎组件)
  • docs/memorys/2026-06-10-P1RMetaRemaining5状态推进.md(未改业务实现;DOMAINS 仅 ai/knowledge)

5.6 事件/SSE(muse-module-events)— 完成度 88%

实现摘要: 后端产线级,无空壳/桩/TODO。垂直链路完整:AppMuseEventsController(GET /app-api/muse/events SSE)→ EventsStreamServiceImpl(游标解析/首连冻结不 replay 历史/心跳/线程池后台轮询/lifecycle 取消/租户+owner 隔离/payload 脱敏/版本与游标 fail-closed 错误事件)→ UnifiedEventMapper(可见性查询 + 原生 insertIgnore ON CONFLICT,sequenceNo 由 PG sequence)→ UnifiedEventDO(JSONB)→ V16 DDL(sequence + 4 唯一约束 + 2 CHECK + owner 索引 + 触发器)。内部 RPC EventsPublishApi.publish:双重幂等(commandId/source tuple)、OpenAPI schema 逐字段校验、secret 检测拒绝。跨模块集成真实广泛:ai/knowledge/market/member/content 五个 owner 各有 EventPublishWorker + outbox 表(V17-V21),88 处引用 EventsPublishApi,逐域端到端测试。前端 connectEventStream 按 SSE event/id 字段正确解析、含重连退避 + token 注入,契约保真。

桩与缺口:

  • 前端 connectAIStream 契约漂移:data.type 派发(应为 SSE event: 字段)且 onDone 用 generationId/candidateId(契约为 taskId/suggestionId);MSW mock 照搬错误 shape 致测试假绿、与真实后端无法对接
  • 契约保真的统一事件客户端 connectEventStream 为孤儿: 仅自身测试 import,无任何 UI 组件接入消费(仅 connectAIStream 被 AIPanel 接入)。
  • 后端缺真实 SSE HTTP 集成测试覆盖 controller getLoginUserId() 鉴权端到端路径(仅单测/静态/迁移 IT)。
  • 管理端 muse-admin 无任何 SSE/EventSource 消费(可能有意,契约仅定义 app-api)。

设计 vs 现实差异: 设计("AI stream 独立 + 事件统一")后端已落地双端点分离。差异集中在前端 AI-stream(非 events 本体):data.type 派发与 done 字段名错误。

"完成"声称 vs 现实: 非 churn,是本项目最克制、最有证据纪律的一组完成文档。 06-05 把 streamEvents 仅推到 needs_verification;06-09 仅将单一 operation events:streamEvents 推 completed(coverage 100→101/132),附 TDD RED→GREEN、真实 PG/Flyway、118 测试 gate、双 fresh review PASS、空 OpenAPI diff,并显式列"不代表其他域/总 P1R completed"边界。声称未注水。

证据(file:line):

  • AppMuseEventsController.java:37(唯一公开 SSE 端点)
  • EventsStreamServiceImpl.java:71-117(首连冻结/游标/fail-closed);:282-339(heartbeat + 轮询 + 脱敏 error)
  • EventsPublishServiceImpl.java:66-96(双重幂等);:147-164(逐字段校验)
  • UnifiedEventMapper.java:36-78(可见性查询 + insertIgnore ON CONFLICT)
  • sql/muse/V16:4-52(sequence + 约束 + 触发器);V17..V21(五域 outbox)
  • MuseKnowledgeEventPublishWorker.java:100(真实调用,跨模块 outbox→统一事件)
  • muse-studio/src/lib/sse.ts:10,25-38(onDone 错误形状 + data.type 派发,偏离契约);:316-475(connectEventStream 保真但孤儿)
  • docs/api-contracts/ai/openapi.yaml:3159-3182(SSEDoneEvent.data required [taskId,suggestionId])
  • docs/memorys/2026-06-09-P1R7CompletedApproval状态推进.md:1-204(仅 events:streamEvents→completed,双 review PASS,非 churn)

5.7 账户/个人中心(muse-module-member / Account BC)— 完成度 68%

实现摘要: 后端真实成熟,account 主代码 9877 LOC、0 TODO、约 291 @Test(34 文件)。10 controller(admin 4 + app 6),去重约 32 逻辑端点(app 侧每端点拆 X-API-Version 两变体);约 16 应用服务全有真实 Impl;19 DO + 22 Mapper;5 domain guard(Owner/Quota/Download/ApiVersion/UserIdResolver,真实属主等值/配额/下载凭证 expiry-consumed-revoked-sourceBlocked 校验)。核心机制全落地:命令幂等、乐观锁(revision + DuplicateKey→VERSION_CONFLICT)、审计(before/after 快照)、事务性 outbox + @Scheduled worker(claim 租约/重试退避/dead_letter/幂等发布,带 sourceOwner/sourceRevision,符合 ADR-017)。DDL:V2(6 表)+ V11(368 行)+ V20。15 个 ACCOUNT_ 错误码。前端 useAccount.ts 真调 /profile(带 commandId/expectedVersion)、/account/entitlements/account/usage,但运行在 MSW mock 上,仅覆盖 4/约19 app 端点。

桩与缺口:

  • 跨 BC 集成边界全部 Unavailable 默认实现(@ConditionalOnMissingBean): NewApiAccountFacade / AccountFileServiceFacade / MarketAccountProjectionFacade / AccountAttributionSourceFacade——本地逻辑完整但外部交付未接,运行时抛 *_UNAVAILABLE
  • New-API 绑定/recheck/quota-request 无真实 runtime;导出文件下载持久化齐备但真实字节/对象存储未接(高敏导出 step-up 抛 invalidParam);市场记录(purchases/licenses/publish-records)投影未接;call-attribution 外部来源未接。
  • Profile 摘要诚实占位: emailVerified/mfaEnabled 硬编码 false、securityRiskCount=0、defaultEntry/productSpaces 静态默认;admin 用户列表 restricted 返回空集;session_revoked 未接入 session 管理服务。
  • 前端薄层: 仅 4 app 端点(profile/entitlements/usage)有 UI 且跑 MSW;security-events/export-tasks/downloads/licenses/purchases/publish-records/new-api-binding/balance-snapshots/quota-requests 共约 15 个 app 端点无前端
  • member-api 未暴露任何 account DTO/Enum(当前 Account 为自包含 BC,无外部读模型集成)。

设计 vs 现实差异: 与设计高度对齐(只读聚合 + 记录入口,不反写他域;New-API 只存绑定引用/correlationId 符合 ADR-009)。主要差异是"跨 BC 集成边界尚未接通"和"前端仅起步"——均为透明降级非伪造。

"完成"声称 vs 现实: 诚实准确,未发现夸大式 churn。 completed 是有严格定义的覆盖率门禁批准状态(需 MockMvc + 真实 PG _test + Flyway V1-V21 + row_to_json no-write 证据)。06-13/06-11 明确 Account 33 op,仅 12 completed-approved、21 needs_verification,反复拒绝宣称 33/33。21 个未通过原因(New-API/FileService/call attribution/Market 投影/security event 缺真实上游)与代码 Unavailable facade 边界完全一致。实现骨架对 33 op 全部存在,21 个因上游 facade 未接通无法通过门禁,故诚实标 needs_verification。

证据(file:line):

  • AccountQuotaServiceImpl.java:95-181(adminCreateQuotaAdjustment:幂等+乐观锁+审计+同事务 outbox)
  • AccountEventPublishWorker.java:64-132(事务性 outbox:claim/退避/dead_letter/幂等,ADR-017)
  • facade/UnavailableNewApiAccountFacade.java:14-23(仅 Unavailable,抛 ACCOUNT_NEW_API_UNAVAILABLE)
  • autoconfigure/.../MarketAccountProjectionFacadeAutoConfiguration.java:13-22(@ConditionalOnMissingBean 注册 Unavailable)
  • AccountExportServiceImpl.java:177,199-211(持久化齐备但文件交付降级 ACCOUNT_FILE_SERVICE_UNAVAILABLE)
  • AccountProfileServiceImpl.java:95-99(诚实占位 emailVerified/mfaEnabled=false)
  • sql/muse/V2:4,31,57,79,104,124(6 表);V11 368 行;V20 outbox
  • muse-studio/src/features/account/hooks/useAccount.ts:8-48(真实 react-query,仅 4 端点)
  • muse-studio/src/api/mocks/handlers/account.ts:95-128(跑在 MSW 上)
  • docs/memorys/2026-06-13-P1RAccountSecurityEvents状态推进.md:44-51(total=33/completed=12/needs_verification=21,拒绝宣称 33/33)

5.8 平台底座(gateway/system/infra/pay/bpm/mp/report + 两前端接线)— 完成度 80%

实现摘要: 平台底座 = 对 yudao-cloud 的干净 fork,8 个核查模块全部真实完整(非空壳):system 32 admin controller/36 Impl/39 测试;infra 13/13/21;pay 19/12(PayOrderServiceImpl 610 行 18 方法);bpm 11/12/18;mp 12/9;report 4 Impl。gateway 17 java(CorsFilter/TokenAuthenticationFilter/GrayLoadBalancer/AccessLogFilter/GlobalExceptionHandler 等真实组件)。muse-server 是聚合启动入口,实际装配 system/infra/content/meta/events/knowledge/market/member/ai;pay/bpm/mp/report 在 pom 中显式注释停用(故意"默认隐藏",符合后端-02)。包名已整体 fork cn.iocoder.yudaocn.iocoder.muse 无残留。前端两仓均真实接线:muse-studio 212 处 /app-api 引用 + 真实 client.ts/sse.ts/indexed-db.ts/typed openapi.ts;muse-admin web-antd 真实 src/api/muse/{ai,knowledge,market,account,governance,audit,newapi,jobs}/admin-api/muse/** 且各带 __tests__

桩与缺口:

  • gateway/application.yaml 未为任何 Muse BC 配置路由;Muse 业务 API 当前不经网关,走 muse-server 单体——网关对 Muse 业务实际未接线(设计写应承接 /admin-api + /app-api 路由)。
  • gateway 保留 bpm/pay/mp/report 死路由(/admin-api/bpm 等),而这些模块已从装配注释停用,路由指向不存在的服务。
  • pay/bpm/mp/report 代码完整但被显式注释,0 运行覆盖(设计内"默认隐藏",但意味当前无运行/测试保活,有上游漂移腐化风险)。
  • 平台底座 8 模块无 Muse 自有 Flyway 迁移(sql/muse V1-V21 全是 BC schema),其 schema 仍依赖 yudao 遗留静态 SQL dump,未纳入 Flyway 受控迁移。
  • mp 模块测试 0、report 仅 2(继承 yudao 现状)。MockPayClientUnsupportedOperationException(yudao 原生 mock 设计,非 Muse 业务桩)。

设计 vs 现实差异: 高度吻合(pay/bpm/report/mp"保留默认隐藏不删依赖"逐条对应),但 1 处真实缺口=gateway 路由未对齐 Muse:既保留已停用模块死路由,又完全没有 content/ai/knowledge/market/meta/events 真正 Muse BC 路由。设计写"承接路由",实际未承接 BC。

"完成"声称 vs 现实: 平台底座根本没有"完成"声称,它是被继承的 yudao 基座;海量 P1R 文档与 24244 行 P1r* 测试全部针对 BC,与底座无关。对 BC 层这套机制经核查真实且反 churn:P1rApiCoverageReportTest 把 catch_all/generic_persistence/sse_placeholder/missing 列为不可标 completed 并断言 completed 恰为 147/233(其余 86 needs_verification,incomplete/blocked/placeholder 均 0);P1rContentCoreCompletedApprovalIT 真跑 Flyway(断言 21 迁移)+ 真实 PG 种子 + MockMvc 打真实控制器,断言分页/owner/租户隔离(跨租户 404 vs 跨 owner 403)/读路径不写 outbox;重 IT 用 assumeTrue 门控无 DB 时跳过而非伪绿。

证据(file:line):

  • muse-server/muse-module-server/pom.xml(显式注释停用 report/bpm/pay/mp,启用其余)
  • muse-cloud/pom.xml:1-20(groupId=cn.iocoder.cloud,modules 含全部)
  • muse-module-pay/.../PayOrderServiceImpl.java:1-610(真实 18 方法非空壳)
  • muse-gateway/src/main/resources/application.yaml:34-(routes 仅 system/infra/member/bpm/report/pay/mp;无 content/ai/knowledge/market/meta/events;bpm/report/pay/mp 死路由)
  • docs/api-contracts/openapi-base.yaml(paths:{} 为空,仅共享组件)
  • docs/superpowers/reports/p1r-api-coverage.json(totalOperations=233 completed=147 needsVerification=86,catchAll/genericPersistence/ssePlaceholder/missing/blocked=0;domain 无平台底座)
  • muse-server/.../P1rApiCoverageReportTest.java:42-48,287(NON_REAL 状态不可标 completed;assertEquals(147))
  • muse-server/.../P1rContentCoreCompletedApprovalIT.java:163,200-243(真跑 Flyway 21 迁移;MockMvc 断言分页/owner/租户/读不写 outbox)
  • design-docs/后端-02-工程结构与模块职责.md:32,40-61(gateway"承接路由";pay/bpm/report/mp"默认隐藏不删依赖")

六、全局结论

6.1 真实整体完成度

约 76%。 分层看:

维度 评估 说明
后端业务实现 高(~80%+) 9 BC 真实纵向实现,幂等/乐观锁/审计/Shadow→Canonical 硬闸门/真实外部 HTTP 普遍落地,无散落 TODO/stub
内部验证门禁(coverage) 中(147/233≈63%) completed 是严格门禁口径(HTTP+真实 PG+Flyway+证据);其余 86 needs_verification 多为"已实现未走完验证"非"未做"
跨 BC 集成 meta/account/部分链路的对端 facade 多为 Unavailable 占位,运行期端到端被阻断
前端用户端(studio) 低(~30%) AI 候选断链、知识库工作台 2/3 面缺、市场生产侧无 UI、个人中心约 21% 且跑 MSW;管理端(admin)反而较真实
机械门禁/底座接线 ArchUnit 0 落地(后置);gateway 对 Muse BC 未接线 + 死路由;底座 schema 未 Flyway 化

6.2 churn 声称 vs 现实差距

维度 结论
过程文档 churn 是否真实 真实存在(34 memorys + 33 agent-specs,被 2026-06-13-agent开发基建迁移-review.md 自我诊断为"接口未锁 + 无单一进度源导致的过程文档 churn,不是真实交付量")
"完成"声称是否注水 否,系统性低报。 所有核查域的 memos 一致区分"covered/completed(门禁口径)"与"端到端可用",反复拒绝宣称 33/33、32/32;coverage json 盘中复核未被篡改
名实不符点 仅一处: ADR 级"AI 包级隔离 + ArchUnit"承诺未兑现(被显式后置第二期)。其余皆为代码强于声称,或诚实标注的 scoped 缺口
治理风险 churn 反映"接口未锁、无单一进度源",本基线文档即是收敛此风险的单一进度源起点

6.3 最危险缺口 Top 6

# 缺口 严重度 影响
1 前端 AI 候选闭环断链(content):后端 mergeBlockSuggestion 齐全,studio 未接 suggestion-merges,EditorPage 仅本地 setContent objective"AI 不黑盒改稿先审后入"在用户可见层不可用;演示壳本地替换反而绕过双轨主权(虽未落库无脏数据)
2 跨 BC facade 多为 Unavailable(meta impact-preview / account New-API·File·Market 投影):运行期抛 *_UNAVAILABLE MetaSchema 治理写链路端到端阻断(发布跑不通);account 21/33 端面运行期不可用;"completed"被误读为"可用"风险高
3 前端用户端整体严重滞后:知识库工作台 2/3 面缺、市场生产侧(发布/上架/申诉)无 UI、个人中心约 21% 且跑 MSW 产品-02 多数用户旅程无前端实现;市场飞轮在 UI 层断裂,创作者无法自助上架
4 gateway 对 Muse BC 未接线 + 死路由:无 content/ai/knowledge/market/meta/events 路由,保留已停用 bpm/pay/mp/report 路由 若误以网关为真实入口部署,Muse BC 全部 404,且死路由打向不存在服务
5 ADR 级 ArchUnit + grant/runtime 包隔离缺失:全仓 0 依赖 0 规则 0 包目录,仅类命名 + 运行时 Guard 软约束 中-高 高价值安全边界(grant 写入 vs runtime 只读强隔离)无机械保证;被有意后置但仍是安全缺口
6 前端 connectAIStream 契约漂移(events):data.type 派发 + done 字段名错误,被 MSW mock 掩盖致测试假绿 真实前后端联调时 done/quality_check 不触发回调,AI 流联调阻断;统一事件客户端 connectEventStream 为孤儿无 UI 消费

横切观察: 后端"completed"(门禁口径)与"端到端可用"是双关语,对外汇报必须明确区分"代码实现完成度(高)"与"内部验证门禁通过度(中)"与"端到端运行可用(受跨 BC facade + 前端拖累偏低)",否则极易高估。多数运行期阻断点已被后端正确 fail-safe(不伪造成功),属"功能不可用"而非"产生脏数据"。


附:本次来源

A. synthesis.sourcesRead(目标锁定阶段已读)

  • /Users/lili/Project/oh-my-muse/CLAUDE.md
  • design-docs/00-文档大纲.mddesign-docs/内容映射表.md
  • design-docs/产品-01-产品定位与核心价值.mddesign-docs/产品-02-核心功能与交互边界.md
  • design-docs/架构-01-系统全貌与边界上下文.md架构-02-核心数据结构与双轨模型.md架构-03-关键决策与原则(ADR).md架构-04-状态机与约束清单.md
  • design-docs/后端-01-领域模型与聚合设计.md后端-02-工程结构与模块职责.md后端-03-关键流程实现与接口契约.md

B. 模块核实证据索引(各模块 evidence 见第五节 file:line;关键交叉验证点)

  • 覆盖率台账(盘中实读): docs/superpowers/reports/p1r-api-coverage.json → totalOperations=233 / completed=147 / needsVerification=86 / 其余指标全 0(本文 §四、§6.1、§5.8 引用)
  • 门禁口径定义: muse-server/.../P1rApiCoverageReportTest.java:42-48,287;P1rContentCoreCompletedApprovalIT.java:163,200-243
  • 各 BC 契约: docs/api-contracts/{account,ai,content,events,knowledge,market,meta}/openapi.yaml;docs/api-contracts/openapi-base.yaml(paths 为空)
  • 各 BC DB 迁移: muse-cloud/sql/muse/V1-V21(全为 BC schema)
  • 自我诊断 churn: docs/agent-specs/2026-06-13-agent开发基建迁移-review.md(34 memorys + 33 agent-specs = 过程文档 churn;ArchUnit/CI 后置第二期)
  • 置信度: 7 个 BC 模块核实均为 high(基于只读代码 + 契约 + 迁移 + 测试 + memos 交叉验证;未实跑 mvn/npm)