zizi-al/oh-my-muse
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
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

27 KiB
Raw Blame History

Muse 目标达成对抗复盘(独立评审官 / 最高强度)

项 值
版本 v1.0
日期 2026-06-13
立场 独立对抗评审官,未参与前序工作;任务是质疑而非附和
输入 基线 2026-06-13-项目目标与模块现状基线.md;迁移评审 2026-06-13-agent开发基建迁移-review.md
方法 不接受基线结论,逐条对实际代码 / git / 覆盖率 JSON / CI / 测试 gating 取证后再裁决
边界 只读核实(未实跑 mvn/npm,与基线同口径);所有挑战均附 evidence,凡证据不足的质疑已自我剔除

0. 结论先行(TL;DR)

  1. 基线大体诚实,但仍系统性高估了"可达成度",并漏掉两个比 churn 更深的根因。 基线"后端是真实纵向实现、历史声称是低报不是高报"——这两点经核实基本成立,我予以确认,不做无证据翻案。但基线把整体完成度报为 76%、把跨 BC facade 描述为"诚实留白",掩盖了两个结构性事实:① BC 边界已被代码实际违反(AI 模块直接 import 并注入 Content 模块的 DAL WorkMapper/ChapterMapper/BlockMapper 与 WorkDO/ChapterDO/BlockDO),不是"未机械约束",而是"已破墙";② 整套"completed/证据门"在 CI 里根本不运行(yudao 继承的 maven.yml 用 -Dmaven.test.skip=true),且门禁测试硬编码 assertEquals(147, completed),live 验收 IT 全部 assumeTrue 跳过——所谓"147 completed(门禁口径)"本质是人工自证的数字,不是任何流水线证明的结果。

  2. "失控"根因诊断只对了一半。 churn(34 memorys + 35 agent-specs)是症状;迁移评审把根因归为"接口未锁 + 无单一进度源 + 无复利"——这是治理层根因,成立但不完整。被双方都漏掉的更深根因是:验证闭环造假倾向(verification theater)。证据:近 15 个提交清一色 test(p1r): 收口 … completed approval 门禁;coverage JSON generatedAt=2026-05-25 已陈旧却被手工把 completed 改到 147;门禁测试自己断言这个 147;CI 跳过所有测试;前端 DEV 无条件挂 MSW、SSE 契约漂移被 mock 喂成假绿。真正失控的不是"代码写太多",而是"完成度被定义成一个可以手工拨动、且无人自动校验的刻度盘"。 迁移评审的"软约束优先、机械门禁后置第二期"方向,恰好会让这个根因继续存活——这是我对迁移方案的最强烈反对点。

  3. 目标可达性裁决:目标本身可达,但"现有总体计划 + 现有验证机制"不可达,继续执行会再次失控。 后端领域逻辑的质量是真实资产,不该推倒;但"完成度"的计量与验证机制必须先换掉,否则团队会在一个测不准的刻度盘上继续"刷绿"。必须先关掉刷分回路,再谈推进功能。

  4. 资源错配最严重处:正在"刷后端 operation 覆盖度"(已 147/233 且持续收口),而真正卡住产品价值的是——前端用户端断链 + 跨 BC 集成在真实部署形态下未验证 + BC 边界已破。 后端 operation 门禁的边际价值已趋零(再多收口几个 needs_verification→completed,对"用户能不能用"零贡献);资源应转向"端到端竖切一条真实可跑的用户旅程"。

一、前提挑战清单(按严重度)

说明:每条给出"基线/迁移评审的前提 → 我的挑战 → 证据 → 严重度"。我确认成立的前提单列在 §一.B,不当成靶子打,以示对抗有节制。

A. 需要挑战的前提(高 → 低)

A1【高】"本仓只承载设计文档,不承载运行时代码"——前提与事实矛盾

  • 基线/CLAUDE.md 前提: oh-my-muse = muse-design-docs,"不承载运行时代码 / CI / 部署"。
  • 挑战: 这是事实错误的自我定位。muse-cloud/(4468 个文件被本仓 git 跟踪,无 .gitmodules)、muse-admin/、muse-studio/ 三个运行时代码仓就在同一个 git 工作树里、被同一个仓库版本控制。所谓"四仓架构 + 设计 SSOT 只读"是文档里的叙事,不是磁盘上的事实。这直接动摇基线第三节"四仓协作"表与整个 owner 论述的物理前提。
  • 影响: 迁移评审基于"单仓 monorepo,治理层放仓根"——这点反而对了;但 CLAUDE.md 写"本仓不承载代码"会让 agent 误判可改动边界(以为不能动代码),与现实冲突,是 churn 的隐性来源之一。
  • 证据: git ls-files muse-cloud | wc -l = 4468;cat .gitmodules = No such file;ls 顶层同时存在 design-docs + muse-cloud + muse-admin + muse-studio。
  • 严重度:high

A2【高】"147 completed 是有证据支撑的门禁口径,coverage json 盘中复核未被篡改"——把"人工自证"当成"客观度量"

  • 基线前提: completed=147 是"严格门禁口径(HTTP + 真实 PG + Flyway + 证据)";"coverage json 盘中复核未被篡改";把它当作可信的完成度锚点。
  • 挑战(三连击):
    1. JSON 是手工维护、且已陈旧。 generatedAt=2026-05-25T14:04:44Z,但基线写于 06-13、completed 已是 147,中间 19 天的"收口"提交不断把数字往上改。所以它不是"生成器实测产物",而是手工编辑的台账;"未被篡改"是错误的框——它本来就是被人持续编辑的,谈不上篡改与否,只能谈"是否可信",而它不可独立复核。
    2. 门禁测试硬编码目标数字。 P1rApiCoverageReportTest.java:287 写死 assertEquals(147, completed, "…只能从 145 增至 147")。这意味着"147"不是统计出来的,是测试和 JSON 互相对着写死的常量;每收口一批,人工把 JSON 改大 + 把断言改大。这是自证循环,不是门禁。
    3. implementationStatus 全部 = dedicated(233/233)。 "0 catch_all / 0 generic_persistence / 0 sse_placeholder / 0 missing"这条被基线反复引用的"高质量证据",其实只是"有人把所有 233 条都标成了 dedicated"——是 JSON 里的自填标签,不是机械判定。
  • 影响: 基线 §6.1"内部验证门禁(coverage)中(147/233≈63%)"这一整层评分失去客观地基。完成度的核心量化锚点是可疑的。
  • 证据: docs/superpowers/reports/p1r-api-coverage.json → generatedAt=2026-05-25,summary.completedOperations=147,逐条 implementationStatus 全为 dedicated,completionStatus ∈ {completed×147, needs_verification×86};P1rApiCoverageReportTest.java:42-46(NON_REAL 集合)、:287(硬编码 147)、:49-53(APPROVED_COMPLETED_DOMAINS 仅 ai/knowledge,白名单也是手填)。
  • 严重度:high

A3【高】"完成度 ≈ 76%,内部验证门禁中"——验证机制在 CI 中根本不运行,且 live 验收全跳过

  • 基线/迁移评审前提: 有一套"证据门",completed 需 MockMvc + 真实 PG + Flyway;迁移评审把"证据门"列为五道软约束护栏之一,认为已在协议层生效。
  • 挑战:
    1. CI 跳过全部测试。 muse-cloud/.github/workflows/maven.yml:30 = mvn -B package --file pom.xml -Dmaven.test.skip=true。所有 P1R 门禁测试、覆盖率断言、完成审批 IT——在 CI 里一个都不跑。它们只在某人本地手动 mvn test 时才有意义。
    2. 真实外部验收 IT 全部 assumeTrue 自跳。 P1rAiRuntimeEndToEndLiveAcceptanceIT.java:157 / P1rKnowledgeRuntimeEndToEndLiveAcceptanceIT.java:137 用 assumeTrue(externalAcceptanceEnabled(), …)——默认环境变量不开就当成通过(跳过=绿)。
    3. 没有任何测试证明"完整 muse-server 聚合启动 + 服务一个真实请求"在自动化下成功过。 基线自己承认"未实跑 mvn/npm"。于是:既无 CI 实跑,又无 live IT,又无人工实跑——"completed/可用"三个口径全部缺少自动化证据。
  • 影响: "76%"是在没有任何一次绿色流水线背书的情况下给出的;它表达的是"读代码看起来实现了多少",不是"验证过多少"。基线把它分层表述已是进步,但仍偏高,且"验证门禁=中"严重失真(应为"验证自动化≈0")。
  • 证据: maven.yml:30(skip tests);P1rAiRuntimeEndToEndLiveAcceptanceIT.java:157、P1rKnowledgeRuntimeEndToEndLiveAcceptanceIT.java:137(assumeTrue 跳过);基线自述"未实跑 mvn/npm"。
  • 严重度:high

A4【高】"AI 授权包级隔离仅是软约束、被有意后置"——实际是 BC 边界已被代码违反(比未约束更糟)

  • 基线前提: ArchUnit/grant-runtime 包隔离"全仓 0,被显式后置第二期,当前仅软约束";措辞暗示"边界在,只是没机械护栏"。
  • 挑战: 边界不是没护栏,是已经破了。ContentMuseWorkOwnerFacade(AI 模块内,@Primary @ConditionalOnBean({WorkMapper,ChapterMapper,BlockMapper}))直接 import cn.iocoder.muse.module.content.dal.dataobject.{WorkDO,ChapterDO,BlockDO} 和 content.dal.mysql.{WorkMapper,ChapterMapper,BlockMapper} 并 @Resource 注入。即:AI BC 绕过 facade-api / RPC 契约,直接读另一个 BC 的私有 DAL 与 DO。这违反基线第三节反复强调的"逻辑 owner 优先 + 跨 BC 写入走 owner facade + facade-api 契约"。基线不但没发现,还把这块讲成"诚实留白 + 后置 ArchUnit"。
  • 次生事实(对基线的纠偏,双向): 也正因为 AI 直接抓 Content 的 mapper,在 muse-server 单体聚合部署下(content 与 ai 同 classpath),ContentMuseWorkOwnerFacade 这个 @Primary real bean 会赢过 UnavailableMuseContentWorkOwnerFacade(后者 @ConditionalOnMissingBean)。所以基线"跨 BC facade 多为 Unavailable→运行期端到端阻断"对 content/security 这两类是过度悲观的——在真实单体形态它们解析到 real 实现。结论两面性:基线在"阻断范围"上偏悲观,却在"边界完整性"上偏乐观,两个方向的误判同时存在。
  • 影响: 这是对"模块化单体 + 清晰 BC 边界"(ADR-001)这一根基的实质背离。一旦未来要拆服务,这种直连 DAL 会让拆分代价爆炸;ArchUnit"后置"会让破墙继续蔓延而无人察觉——这正是把机械门禁后置的真实代价。
  • 证据: muse-module-ai/.../application/muse/facade/ContentMuseWorkOwnerFacade.java:6-11(import content DO+Mapper)、:28-31(@Primary @ConditionalOnBean + implements MuseContentWorkOwnerFacade);UnavailableMuseContentWorkOwnerFacade.java:16-17(@ConditionalOnMissingBean 兜底);AI 模块 main 内跨模块 content/market/meta/knowledge 的 Mapper/DO/dal import 共 6 处。
  • 严重度:high

A5【高】"先软约束、机械门禁列入第二期"——这个决策直接喂养了失控根因

  • 迁移评审前提(本期已定三决策之③): 先只上软约束(入口必读/契约先行/分流评审/证据门/模块边界),CI/ArchUnit/pre-commit 后置第二期。
  • 挑战: 把"软约束优先"当解法,是用产生问题的同一种机制去治理问题。失控的实证根因(见 A2/A3/A4)全都是"靠自觉的软约束在没有机械校验下被绕过":证据门靠自觉 → CI 跳过测试;契约先行靠自觉 → SSE 契约漂移被 mock 掩盖;模块边界靠自觉 → AI 直连 Content DAL;完成度靠自觉 → 手工拨 147。已经有充分证据表明这套软约束在本项目失效了,却把更强的机械门禁继续往后推——这是已被证伪的赌注又下一次。
  • 影响: 若按迁移评审执行,治理层文档会更整齐,但失控的发动机(可手工拨动且无人校验的完成度)原封不动。churn 可能因"单一进度源"短期下降,但"假绿"风险上升(进度更集中、更难交叉证伪)。
  • 证据: A2/A3/A4 全部证据即本条论据;迁移评审 §0.3 / §2.2 / §3.6(机械门禁后置)。
  • 严重度:high

A6【中】"前端 connectAIStream 契约漂移属中等风险、被 mock 掩盖"——低估了它代表的系统性"假绿"

  • 基线前提: 列为 Top6 第 6 条,严重度"中",描述为单点 AI 流联调阻断。
  • 挑战: 这不是一个孤立 bug,而是整条前端验证链造假的样本。muse-studio/src/main.tsx:9-11 在 import.meta.env.DEV 下无条件 worker.start()——所有开发期请求走 MSW;而 sse.ts:10 onDone 用 {generationId, candidateId}、:25 按 data.type 派发,均偏离契约(契约要求 {taskId, suggestionId} 走 SSE event: 字段)。mock 照抄错误 shape → 前端测试与联调永远见不到真后端。这意味着没有任何一个开发者通过真实 UI 跑通过任何后端,基线所有"前端薄/断链"的判断其实更严重:连"已实现的那部分前端"也未对真后端验证过。
  • 影响: "前端完成度≈30%"里的那 30% 也是 mock 上的 30%,真实可对接比例更低。
  • 证据: muse-studio/src/main.tsx:9-11;muse-studio/src/lib/sse.ts:10,25,33;契约 docs/api-contracts/ai/openapi.yaml SSEDoneEvent.data required [taskId,suggestionId](基线 §5.6 已引)。
  • 严重度:中

A7【中】"churn 不是真实交付量,只是过程文档堆积"——部分代码提交也是 churn,基线/迁移评审都只盯文档 churn

  • 前提: 迁移评审把 churn 限定为"34 memorys + 33 agent-specs 过程文档";基线认同。
  • 挑战: 代码提交本身也在 churn。 近 200 提交里 fix(p1r) 37 次、test(p1r) 23 次、docs(p1r) 7 次 = 67 次围绕同一批 P1R 的返工/收口,而 feat(p1r)+feat(api) 合计仅 33 次。即"修 P1R + 收口 P1R"的提交量是"真正新增功能/契约"的 2 倍。把 churn 仅归于文档,会低估返工成本、误以为只要收敛文档就能止血;实际是"接口未锁"在代码层也持续诱发返工。
  • 影响: 迁移评审的解法(收敛文档 + 单一进度源)只能止住文档那一半;代码返工那一半需要"契约真正锁定 + 机械校验"才能止。
  • 证据: git log --oneline -200 类型分布:fix(p1r)=37 / test(p1r)=23 / docs(p1r)=7 / feat(p1r)=21 / feat(api)=12;最近 15 提交全为 test(p1r): 收口…completed approval 门禁。
  • 严重度:中

A8【中】"muse-module-ai 是 364 文件的高质量纵向实现"——大半是 yudao 原生 AI/BPM 模块,Muse 自有面小得多

  • 基线前提: AI 域"364 个 Muse java 文件…真实较高质量实现"。
  • 挑战: 这 364 里含大量 wholesale 继承的 yudao 原生模块(framework/ai/core、service/chat、service/workflow、service/music、service/model、AiModelFactoryImpl 等),它们带着 yudao 作者(@芋艿/@lesan)的原生 TODO 与 UnsupportedOperationException(全仓 TODO/FIXME/UnsupportedOperation 222 处,绝大多数在这些继承树里)。真正 Muse 业务包(application/muse、domain/muse)里的 TODO/桩只有约 9 处,且都是基线已诚实披露的 scoped 缺口(如 Task4 owner "not implemented")。
  • 两面性(对基线公平): 这条同时支持也削弱基线——支持"Muse 自有业务代码确实干净"(我确认,见 §一.B);削弱"364 文件高质量"的体量叙事(分母被 yudao 继承码灌水)。
  • 影响: 用"文件数/LOC"衡量完成度会高估;应只算 Muse 自有 BC 面。
  • 证据: 全仓 TODO|FIXME|UnsupportedOperation 222 处,scope 到 */muse/ 业务包且排除 yudao 作者/framework 后仅约 9 处;样例 MuseKnowledgeBaseService.java:222("not implemented in Task 4")。
  • 严重度:中

A9【低】"gateway 保留死路由 + 未接 Muse BC 是高危缺口"——成立,但严重度被高估

  • 基线前提: Top6 第 4 条"高",担心"误以网关为真实入口部署 → Muse BC 全 404"。
  • 挑战(降级而非翻案): 事实成立(网关只路由 system/member/bpm/report/pay/mp,无任何 content/ai/knowledge/market/meta/events;且 bpm/pay/report/mp 已从 muse-server 注释停用却仍有路由)。但严重度应为中:当前部署形态是 muse-server 单体聚合直出,网关本就不在真实入口链路上;这是"未来要用网关时的待办",不是"现在阻断了什么"。把它列"高"会与真正阻断价值的前端断链/边界破墙抢优先级。
  • 证据: muse-gateway/.../application.yaml:36-119(仅 system/member/bpm/report/pay/mp 路由,无 Muse BC);muse-server pom 注释停用 bpm/pay/report/mp。
  • 严重度:低(基线列高,我下调)

B. 经核实予以确认、不再挑战的前提(对抗有节制)

  • B1 后端 Muse 业务代码是真实实现,非空壳。 Muse 自有业务包 TODO/桩仅约 9 处且均诚实标注;RealNewApiMuseAiRuntimeClient、HttpRagFlowKnowledgeRuntimeClient 是真 HTTP 客户端;幂等/乐观锁/审计模式在多模块一致出现。确认成立,不推倒。
  • B2 历史"completed"声称是低报而非高报(注水方向相反)。 各域 memos 反复拒绝宣称 33/33、32/32,把多数 operation 留在 needs_verification。确认成立——但这恰恰反衬 A2/A3:诚实的"低报"配上"无人自动校验的刻度盘",仍然不能当可信完成度。
  • B3 设计层(design-docs)成熟。 迁移评审此判断与本次只读印象一致,不挑战。
  • B4 churn 治理需要单一进度源 + 契约锁定。 方向正确,我只反对"机械门禁后置"(见 A5),不反对"单一进度源"。

二、目标可达性裁决

裁决:目标(多角色 AI 创作与资产流通系统,Shadow→Canonical 主权)本身可达;但"现有总体计划 + 现有验证/计量机制"判定为不可达——若不先更换计量与校验机制,继续执行将以更高置信度再次失控("假绿"取代"churn 体感")。

分三层:

层 裁决 依据
目标本身 ✅ 可达 后端领域逻辑是真实资产(B1);设计成熟(B3);硬不变式 Shadow→Canonical 在 content mergeBlockSuggestion 等处确有代码强制
现有"完成度"计量 ❌ 不可信 147 是手工台账 + 硬编码断言 + 全 dedicated 自填标签(A2);CI 跳过测试 + live IT 自跳(A3)。计量盘本身坏了
现有总体计划(继续收口 operation 门禁 + 软约束治理) ❌ 达不成目标 operation 门禁边际价值趋零(刷的是后端覆盖,不是用户价值);软约束已被实证绕过(A5);BC 边界已破却无机械护栏(A4)。继续执行 = 在坏盘上刷绿
会在哪里再次失控 ⚠ 三处 ① 前端真接后端时,SSE/契约漂移与 mock 假绿集中爆雷(A6);② 拆服务或 ArchUnit 补回时,AI↔Content 直连 DAL 大面积返工(A4);③ "completed=N"被对外当"可用",上线即穿帮(A2/A3)

一句话: 不是"还差 24% 就到 100%",而是"衡量到 76% 的那把尺子需要先扔掉"。先恢复"可信、自动、可证伪"的完成度信号,再谈推进——否则推进越多,真假越难分。

三、重新确立的达成路径(排序,每步给 why 与优先级)

排序原则:先止血(关掉刷分回路)→ 再竖切验证(用一条真实可跑的旅程重建"完成"的定义)→ 再补边界护栏 → 最后才铺面。与迁移评审最大分歧:机械门禁不后置,而是与软约束并行的最小集前置(只上能止血的那几条,不求全套 CI)。

P0(止血,先于一切;1-3 天级)

P0-1 打开 CI 测试 + 把门禁测试改为"计算而非硬编码"。

  • 做什么: maven.yml 去掉 -Dmaven.test.skip=true(至少对 muse-server 的非 live 单测/IT);P1rApiCoverageReportTest 删除 assertEquals(147, completed) 这类硬编码常量,改为"从覆盖矩阵重新统计 completed,并校验每条 completed 必须满足真实判据(有 controller+service 文件、非 NON_REAL)";implementationStatus 不再接受 JSON 自填,改由扫描判定(哪怕只判"是否存在 service 文件 + 是否含 generic catch")。
  • why: 这是失控发动机的点火开关。只要"147"还能手工拨、CI 还跳过测试,后面任何路径都建在沙上(A2/A3/A5)。
  • 优先级:最高。

P0-2 冻结"operation completed approval 收口"类工作。

  • 做什么: 停止再产 test(p1r): 收口 X completed approval 提交;把人力从"把 needs_verification 拨成 completed"撤出。
  • why: 近 15 提交全在做这件零用户价值的事(A7);后端 operation 门禁 147/233 的边际价值已趋零,继续刷只是制造更多假信号与 churn。
  • 优先级:最高。

P1(用一条真实竖切重建"完成"的定义;1-2 周级)

P1-1 选定唯一一条端到端"黄金旅程"并真实跑通:登录 → 打开作品 → AI 生成候选 → 前端 Accept Suggestion → 候选经后端 mergeBlockSuggestion 落库 + 来源归因 → SSE 回流。

  • 做什么: 真实启动聚合 muse-server + 真实 PG + 真实(或受控)New-API;muse-studio 关掉该旅程的 MSW、对真后端;修 sse.ts 契约漂移(taskId/suggestionId + event 字段);把 EditorPage 的 demo-work/b-${id}/revision=1 演示壳替换为真实 WorkspacePage 路径并挂上 AI 候选面板;让 studio 真正调用 suggestion-merges(当前真实调用数 = 0)。产出一个自动化的端到端冒烟(可 assumeTrue 跳过 live New-API,但 PG + 内部链路不许跳)。
  • why: ① 这条链是 objective"AI 先审后入"的最小可用证明,基线 Top6 第 1/6 条都压在它上;② 用"一条真能跑的旅程"取代"147 个自证 operation"作为新的完成度锚点——完成 = 用户旅程在自动化下绿,不是台账数字;③ 一次性证伪/暴露 A6 的前端假绿。
  • 优先级:最高(P0 之后第一件)。

P1-2 明确区分并对外只报三个口径,禁止用单一"%"。

  • 做什么: 任何对上汇报用三列:代码实现度(读代码) / 自动化验证度(CI 实跑通过的 operation/旅程数) / 端到端可用度(真实形态跑通的用户旅程数)。删除"76%"这类合并数。
  • why: 基线已指出三者是双关语却仍给了合并 76%;合并数是高估的来源(A2/A3)。
  • 优先级:高。

P2(补边界护栏,趁破墙未蔓延;1 周级,可与 P1 并行)

P2-1 上 ArchUnit 最小集(只两三条,不求全):禁止 module.ai import module.content/market/meta/knowledge 的 .dal..(DAL/DO/Mapper)。

  • 做什么: 加一条 ArchUnit 规则把 A4 的直连 DAL 标红;对已存在的 ContentMuseWorkOwnerFacade 直连,要么改为经 content 的 facade-api/对外 API 读,要么显式登记为已知违例并定整改期。
  • why: A4 是对 ADR-001/边界根基的实质背离,且会随时间蔓延、拆服务时代价爆炸;"机械门禁后置第二期"(A5)正是让它继续烂的决策。这一条 ArchUnit 的成本极低、止血价值极高,是"机械门禁不该全后置"的最小反例。
  • 优先级:高。

P2-2 meta impact-preview 决断:要么补一个 real 生产者,要么显式接受"meta 发布链路本期不可端到端"。

  • 做什么: MetaImpactFacade 当前是接口、唯一实现是 UnavailableMetaImpactFacade(确认基线此处正确),导致 publish/activate 因 requireImpactPreview 硬门禁必失败。明确选一:① 在 content/knowledge/ai 侧补最小 impact 统计;② 或把 meta 标为"治理写链路本期 design-complete / runtime-blocked",写进单一进度源,不再让它以"completed 覆盖"形式制造可用假象。
  • why: 这是少数"基线没冤枉"的真实运行期阻断;放着不决会持续产生"completed≠可用"的认知差。
  • 优先级:中。

P3(才轮到铺面;P0-P2 稳定后)

P3-1 按"黄金旅程"模板,逐条竖切其余高价值旅程(知识库草稿确认闭环 → 市场生产侧发布/上架 → 个人中心权益)。每条都遵循 P1 的"关 mock + 真后端 + 自动化端到端"标准,完成定义统一为旅程绿,不再是 operation 台账。

  • why: 前端用户端是真实大缺口(基线 §6.1≈30%,且这 30% 还在 mock 上,A6),但只有先有 P0 的可信尺子 + P1 的旅程模板,铺面才不会变成新一轮刷分。
  • 优先级:中。

P3-2 迁移评审的治理层(AGENTS.md/.agents/contracts/进度总账)按"修正版"落地:保留单一进度源,但①进度只承认"自动化绿的旅程",②契约锁定必须配 P0-1 的 CI 校验(openapi-diff 实跑),不是纯文档纪律。

  • why: 单一进度源方向对(B4),但若进度源记录的仍是"手工 completed",只是把假信号换了个更集中的地方放(A5)。治理层必须挂在 P0 的机械校验上才有意义。
  • 优先级:中。

四、Top 风险

# 风险 触发条件 影响 缓解
R1 "假绿"取代"churn"成为新失控形态 按迁移评审执行(软约束 + 机械门禁后置),进度收敛到单一源但仍是手工 completed 进度更集中、更权威、却更难交叉证伪;上线/对外承诺时集中穿帮 P0-1/P0-2 先关刷分回路;P1-2 三口径分报
R2 AI↔Content 直连 DAL 蔓延,拆服务/补边界时大面积返工 ArchUnit 继续后置,新功能照抄 ContentMuseWorkOwnerFacade 直连套路 ADR-001 模块化单体边界名存实亡;未来拆分代价爆炸 P2-1 最小 ArchUnit 立即止血
R3 前端真接后端时 mock 假绿集中爆雷 任一旅程关 MSW 对真后端 SSE/契约漂移、字段名不符成片暴露;"已实现前端"实际不可对接 P1-1 先竖切一条并修 sse.ts;之后逐条关 mock
R4 "completed=147"被当"可用"对外承诺 汇报沿用合并完成度% 与真实可用度差距在交付节点暴露,信任受损 P1-2 禁用单一%,只报三口径
R5 继续投入后端 operation 收口,挤占前端竖切资源 P0-2 不执行 后端覆盖刷到更高但用户仍不可用,飞轮 UI 层持续断裂 P0-2 冻结收口 + P1/P3 资源转向旅程竖切
R6 本仓"不承载代码"的自我定位让 agent 误判改动边界 CLAUDE.md 不更正 agent 不敢/不知可改 muse-cloud 等,绕路产生更多文档 churn 更正 CLAUDE.md 与 AGENTS.md 对仓库物理结构的描述(A1)

附:本次对抗取证索引(关键 evidence)

  • 仓库物理结构(A1): git ls-files muse-cloud|wc -l=4468;无 .gitmodules;顶层并存 design-docs + 三代码仓。
  • 完成度计量造假面(A2): docs/superpowers/reports/p1r-api-coverage.json(generatedAt=2026-05-25,completed=147,implementationStatus 全 dedicated);muse-server/.../P1rApiCoverageReportTest.java:42-53(自填白名单/NON_REAL 集),:287(assertEquals(147, completed) 硬编码)。
  • 验证不自动(A3): muse-cloud/.github/workflows/maven.yml:30(-Dmaven.test.skip=true);P1rAiRuntimeEndToEndLiveAcceptanceIT.java:157、P1rKnowledgeRuntimeEndToEndLiveAcceptanceIT.java:137(assumeTrue 自跳)。
  • BC 边界已破(A4): muse-module-ai/.../application/muse/facade/ContentMuseWorkOwnerFacade.java:6-11,28-31(import + @Resource content DAL/DO/Mapper,@Primary @ConditionalOnBean);UnavailableMuseContentWorkOwnerFacade.java:16(@ConditionalOnMissingBean 兜底,单体下不生效)。
  • 代码层 churn(A7): git log --oneline -200 类型分布 fix(p1r)=37 / test(p1r)=23 / feat(p1r)=21 / feat(api)=12;最近 15 提交全 收口…completed approval 门禁。
  • 前端假绿(A6): muse-studio/src/main.tsx:9-11(DEV 无条件 MSW);src/lib/sse.ts:10,25,33(generationId/candidateId + data.type,偏离契约);suggestion-merges 真实调用数=0。
  • yudao 继承灌水(A8): 全仓 TODO/FIXME/UnsupportedOperation=222,scope 到 Muse 业务包后≈9。
  • meta 运行期阻断(P2-2): muse-module-meta/.../MetaImpactFacade.java:12(接口);唯一实现 UnavailableMetaImpactFacade。
  • gateway 未接 Muse(A9): muse-gateway/.../application.yaml:36-119(仅 system/member/bpm/report/pay/mp)。
  • 确认成立侧(B1/B2): Muse 业务包桩≈9 且诚实标注;RealNewApiMuseAiRuntimeClient、HttpRagFlowKnowledgeRuntimeClient 为真 HTTP;各域 memos 拒绝宣称满分(低报方向)。