e181669197
本会话三部分交付,均经 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>
205 lines
27 KiB
Markdown
205 lines
27 KiB
Markdown
# 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 拒绝宣称满分(低报方向)。
|