oh-my-muse/docs/mvp/进度总账.md

Muse 进度总账(单一进度源)

本文件是项目进度的唯一 SSOT。进度更新只进本文件 + 各模块 .agent;不再新增“状态推进 / 收口 / completedApproval”过程文档(过程文档 churn 是失控根因之一,见 对抗复盘)。 模块真实现状的权威基线见 现状基线 spec;本文件只记“进度”,不重复其证据细节。

---

一、Agent 开发基建(本轮交付,机械门禁优先)

砖	内容	状态	机械证据 / 落点
P0	CI 真跑测试(JDK21、去 -Dmaven.test.skip)+ 覆盖台账去硬编码 + P0 冻结令	✅	.github/workflows/maven.yml、P1rApiCoverageReportTest、脊柱规则
①	BC 边界 ArchUnit 门——通用覆盖全业务 BC 间方向	✅ 全绿(AI/knowledge/market 三处直连他域 DAL 违例均已整改,豁免清单清空)	BcBoundaryArchTest(1/0F,0 Architecture Violation,KNOWN_VIOLATION_EXEMPTIONS=空);bc-boundaries §三
②	契约先行门(Flyway 迁移卫生 + OpenAPI 存在性/结构)	✅ 绿(注:挡不住语义破坏;openapi-diff CI 待首跑验证)	ContractFirstGateTest(2/0F);contract-first
⑦	loop 机械牙 + CI 接电(round-2)	✅ 绿	AgentsInfraIntegrityTest(3/0F);maven.yml 触发分支修为 main
③	knowledge 蒸馏(定位架构 / 现状基线指针 / 决策)	✅	.agents/knowledge/
④	skills(黄金旅程“完成”定义 / 新增 BC 模块)	✅	.agents/skills/
⑤	workflow(AI 开发协议元流程)	✅	.agents/workflows/ai-development-protocol.md
⑥	进度总账(本文件)+ per-module .agent	✅	本文件 + muse-cloud/muse-module-*/.agent

round-2 加固(2026-06-14,据 Opus 评审):CI 触发分支 master→main(此前 CI 从不运行)、BC 门通用化 + 整改 knowledge 违例、loop 装机械牙、覆盖门去魔法数、文档诚实化、openapi-diff materialize 为独立 workflow。

market 写路径整改(2026-06-14,ultracode):member 暴露写端口 MuseAccountRecordProjectionApi + DTO(member-server 实现读写自有 DAL、tenantId 由实现侧从上下文注入防伪造、事务沿用调用方),market 5 类改消费端口、移除 member.dal 依赖 → KNOWN_VIOLATION_EXEMPTIONS 清空、BC 门全绿。附带修复:round-2 重构 ContentKnowledgeWorkOwnerFacade 时遗留的旧测试 KnowledgeWorkOwnerFacadeTest(仍断言旧 WorkMapper 行为)已删除,其装配守卫/兜底两用例并入 ContentKnowledgeWorkOwnerFacadeTest(5/0F)——此为 round-2 一处假绿(当时构建在平台时区用例处中止、未真正跑到 knowledge),现已补正。

后续基建 TODO:openapi-diff CI 首跑验证、completed=测试证据兜底(台账加 testFiles 字段 + 门禁)、dev-baseline 收敛进 rules、跨域 .application 边界门、market-server→member-server pom 坐标收口(本次只消除 member.dal 代码 import,见 bc-boundaries §三遗留)、ai/平台预存红测试整改(CI 接电后将暴露;均非本轮改动引入):MuseAiTaskServiceTest 缺 eventPublishOutboxService/candidateReviewService 桩致 11 例 NPE ✅ 已整改 40/40(2026-06-15,补桩 + review lenient,零产代码改动);QiniuSmsClientTest 时区硬编码 ✅ 已整改 5/5(2026-06-15,断言改用与生产同款 LocalDateTimeUtil.of 由系统时区换算→机器无关);MuseAiEventPublishOutboxMapperTest ✅ 真实 PG 实跑 5/5(2026-06-15,mini-infra PG 100.64.0.8:5433;跑法=source infra.env + -DargLine='-DsocksProxyHost= -DsocksProxyPort=';隔离 schema 自建自清、零代码改动——原"红"仅缺真 PG 环境)。至此 ai/平台预存红三项全清。

---

二、产品 / 模块进度(指针,勿在此重复细节)

• 各模块目标 / 边界 / out-of-scope / 现状 / TODO → 见对应 muse-cloud/muse-module-*/.agent。
• 真实完成度与逐项证据 → 见 现状基线 spec §四/§五。
• 接口完成台账(门禁批准口径,≠端到端可用)→ P1rApiCoverageReportTest + docs/superpowers/reports/p1r-api-coverage.json。

BC 模块	只读评估	.agent
AI 编排 (ai)	72%	.agent
作品/编辑器 (content)	82%	.agent
知识库 (knowledge)	72%	.agent
市场 (market)	82%	.agent
元治理/MetaSchema (meta)	82%	.agent
事件/SSE (events)	88%	.agent
账户/个人中心 (account→member)	68%	.agent

整体只读评估 ≈ 76%:后端实现高、内部验证门禁中、前端用户端低、跨 BC 集成与机械门禁低(机械门禁项本轮已补 BC + 契约门)。

2026-06-14 更新 —— P1 后端"环境阻塞"已解除:此前"86 个 needs_verification 须真实 PG、本地不可验"的判断已被实测推翻。接通共享远端 PG(详见 §四 时间线 + .agents/knowledge §四)真跑 20 个 P1r*IT,19/20 类零功能失败——completed-approval / Flyway 迁移 / events-publish outbox 等后端路径在真实 PG 上获机械绿证据(非假绿)。仍未验证/未达:前端 muse-studio(无 FE 运行栈);唯一红 P1rKnowledgeFlywayMigrationIT(陈旧硬编码 V14,待改为动态版本);live-acceptance 中需 MUSE_P1R_EXTERNAL_ACCEPTANCE=true 才真跑的用例;以及覆盖台账 completed≠端到端可用(FE 断链仍在)。

2026-06-14 更新 —— MVP #1「前端 AI 候选闭环」代码已闭合 + 后端实证:现状基线 §6.3 列首位的高危缺口(studio 未接 suggestion-merges、仅本地 setContent)已整改:前端真实编辑器接入唯一合法入口、后端 merge 主链路在真实 PG 上 5/5 绿(P1rContentMergeSuggestionIT)。剩余到「用户在跑起来的 app 里真能用」的范围外阻塞:仅 1 个——远端 dev 库缺 yudao 基座 schema(全栈 app 起不来,需 provision)。connectAIStream 的 SSE parser 漂移、AI 运行时未写「审」字段均已修复(后者:AI 生成链路现真实产出审结果 + active + 数值授权快照 + content,生成候选可被 mergeBlockSuggestion 采纳,见 §四 时间线 + .agents/knowledge §五)。

---

三、最大共性风险(跨模块,来自基线)

1. 前端 muse-studio 严重滞后:AI 候选闭环断链、知识库/市场生产侧 UI 缺失、个人中心约 21% 面跑 MSW——“先审后入”在用户可见层当前不可用。
2. 跨 BC facade 多为 Unavailable 占位 → 运行期 *_UNAVAILABLE。
3. gateway 路由未接任何 Muse BC + 死路由:若误以网关为真实入口部署,Muse BC 全部 404。

---

四、历史交付时间线(过程文档已清理,留此精简记录)

2026-06-14 共清理约 97 份过程 churn(docs/memorys 34、agent-specs 审阅/执行版+迁移review 34、design-docs/临时 2、design-docs/memorys 2、superpowers/plans 14 + specs 11;保留 superpowers/reports/coverage——被门禁引用)。唯一操作干货蒸馏入 .agents/knowledge/external-deps-and-gotchas.md;均 git 可恢复,完整历史在 git。

2026-05-24  muse-studio 脚手架+基础设施(Vite/React/TS6.0/MSW/IndexedDB)
2026-05-24  muse-studio 写作台+AI 协作(Tiptap + Coarse-to-Fine Diff + SSE 采纳)
2026-05-25  muse-cloud 后端 P1(yudao-cloud fork + 业务模块骨架)
2026-05-25  muse-admin 管理端(Vben fork:MetaSchema/治理/审计)
2026-05-26  P1R-0 基线门禁(OpenAPI 233 operation 覆盖矩阵)
2026-05-27→28  P1R-1/2 Content / Meta 真实 API
2026-05-31  P1R-4 AI 真实 API + task SSE 退占位(V12/V13)
2026-06-02  P1R-4/5 外部验收:New-API(MiniMax-M2.5)+ RAGFlow live 跑通
2026-06-05  P1R-6 Market 真实 API;P1R-7a Events SSE
2026-06-06→08  P1R-7b~7f Source Owner Propagation 五切片(V17–V21 outbox)
2026-06-09→13  Events/Meta/Account/Market/Content 分批 completed approval(coverage→147/233)
2026-06-13  现状基线 + 对抗复盘(诊断"假绿")+ P0 止血(CI 真跑测试/JDK21/去硬编码)
2026-06-14  Agent 开发基建六砖(BC 门 + 契约门 + .agents 中枢 + 单一总账)+ 历史文档清理
2026-06-14  P1 harness 验证:消除 BC 违例 ContentMuseWorkOwnerFacade(content-api 端口 + AI 改消费)→ ArchUnit 豁免删除、门禁收紧(反向红 31 例 / 正向绿;13+7 单测)
2026-06-14  P1 market 写路径整改(ultracode):member 暴露 MuseAccountRecordProjectionApi 写端口 + DTO,market 5 类去 member.dal → 豁免清空、BC 门全绿;附带补正 round-2 knowledge 旧测试假绿(JDK21 scoped 实跑:BcBoundary 1/0F+0 违例、knowledge 5/0F、member 4/0F、market 5 类全绿、契约/loop/覆盖门全绿,BUILD SUCCESS)
2026-06-14  P1 后端 real-PG IT 验收:接通共享远端 PG(100.64.0.8:5433,PG17.10;破本机 SOCKS 代理破坏 PG 协议的坑)真跑 20 个 P1r*IT,**19/20 类零功能失败**(~95 用例绿,含 completed-approval/Flyway 迁移/events-publish outbox + New-API live)。唯一红=P1rKnowledgeFlywayMigrationIT 硬编码断言 V14(schema 已 V21,陈旧用例,源自 commit 7155285、非本轮)。配方+代理坑入 [.agents/knowledge §四](../../.agents/knowledge/external-deps-and-gotchas.md)。
2026-06-14  MVP #1 纵切(AI候选→采纳入正文,据现状基线 §6.3 #1):前端真实编辑器(WorkspacePage)接入唯一合法入口 suggestion-merges——新增 useAcceptSuggestion + client 注入 Bearer + AIPanel 透传 suggestionId + CandidatePanel 异步防双写,**去除本地 setContent 绕过双轨主权**、connectAIStream 复用 createEventStreamParser 对齐真后端 SSE `event:` 线(修掉旧 `data.type` 漂移)(studio tsc/**47 单测**/build 全绿)。后端新增机械门禁 `P1rContentMergeSuggestionIT`:真实 PG + 真实 `AiSuggestionMergeProjectionFacade` 读真种 muse_ai_suggestion,**5/5 绿**(正向写 Canonical revision1→2/revision 冲突/幂等回放/非 pending/审缺失)。**未达(诚实)**:活体 UI e2e 未跑——阻塞于①远端 dev 库缺 yudao 基座 schema(system_tenant,全栈 app 起不来,需 provision)②AI 运行时未写「审」字段(生成流候选不可合并,chip task_092cfc32);均范围外。connectAIStream 的 SSE parser 漂移**已在本提交修复**。`e2e/accept-suggestion.spec.ts` 已写(只写不跑)。
2026-06-14  AI「审」字段补齐(消除「生成候选永不可采纳」缺口,chip task_092cfc32):新增 `MuseAiCandidateReviewService`(真实轻量审——输出合规扫描/静态检查/许可快照,通过才给可追溯审结果 ID,否则不给→门禁如实拒绝);`MuseAiRuntimeProjectionService.createRuntimeSuggestion` 现写顶层 content(脱敏 summary)+ 三审字段 + `source_status`='active'(修 'verified')+ 数值授权快照(沿用 runtime permission envelope=authz 既有约定)。机械门禁 `P1rContentMergeGeneratedSuggestionIT`(真实 PG):经真实 `createShadowSuggestionCandidate` 产候选→断言 active/审/authz/content 由真实代码产出→`mergeBlockSuggestion`(merge_after_edit)写入 Canonical。验证:`MuseAiCandidateReviewServiceTest` 5/0、`MuseAiRuntimeProjectionServiceTest` 5/0(回归)、`P1rContentMergeGeneratedSuggestionIT` 1/0、`P1rContentMergeSuggestionIT` 5/0 = **16/16 绿**。遗留:非数值 envelope id 暂无法落 BIGINT 授权快照列(已知列能力限制),待授权快照建模收口。
2026-06-14  全栈 app 启动攻坚(为活体 e2e):实测推进,拆两墙、定位第三墙。①墙1 修复:member-server repackage 配 classifier=exec(commit 1f89007)→ 全项目 `mvn package` 由"破损"变 BUILD SUCCESS、产出 muse-server.jar(此前 d38260f 的市场整改只验 test 未验 package,是假绿)。②墙2 解决:本仓原无 postgres 基座 dump(只有 H2 测试 schema),已把 system/infra/member 的测试 schema 忠实翻为 PostgreSQL(49 表,实测 0 失败)+ 最小启动种子(system_tenant id=1),固化到 `muse-cloud/sql/dev/yudao-base-schema-postgres.sql` + `yudao-base-seed-postgres.sql`;灌入 muse_slice_live 后 app 的 Flyway(baseline-on-migrate)成功补 Muse V1-V21、Tomcat 起、Spring 初始化。③墙3(定位,未解,开 chip):muse-server 卡在 bean 装配——`PermissionCommonApi` 等 5 个 `biz.system` CommonApi 是 **@FeignClient(yudao-cloud RPC)**,单进程单体下无人提供本地 bean。即**本项目从未以单体真正启动过(基线"未实跑"的根因)**,需「阶段7 工程承接」补一层"CommonApi→system 本地 impl"的单体 RPC 桥接(真实桥接,非 permissive stub——stub 会造假绿启动)。这是项目级架构整合,非 MVP 纵切范围。**MVP #1 纵切本身仍以 4 个真实 PG IT 为正确性证据(未受影响)。**
2026-06-14  ✅ **全栈 muse-server 史上首次单进程单体成功启动 + MVP #1 活体端到端跑通**(ultracode)。**墙3 诊断证伪**:初判"需 Feign RPC 桥接"错,真因是 ①system/infra/ai-server 也缺 classifier=exec(fat-jar 嵌套致类不可加载,commit eea10b7)②Spring 条件注解 `@ConditionalOnBean/Missing` 在 `@Service/@Component` 上不可靠→facade 装配非确定性失败,改 `MonolithFacadeFallbackAutoConfiguration`+去条件(commit d09d529)③`@Resource` 跨模块 bean 名撞名(AccountExport 的 exportTaskMapper)重命名 ④codegen.import-enable 缺省 ⑤本机 SOCKS 代理破坏 PG(`-DsocksProxyHost=`)——`PermissionApiImpl` IS-A `PermissionCommonApi`,类可加载后 bean 自满足,**全程零 Feign 桥接、零 permissive stub**。**实测**:`Started MuseServerApplication in 17.985s`(Tomcat 48080,连 muse_slice_live);curl 真打:`GET /works`→`{"code":0,total:1}`;`POST .../suggestion-merges`(accept_as_is,种子 work1/block1/sugg1)→`code:0,newRevision:2,sourceAttribution(ai_suggestion)+lineage`;reload 块 `content_text=AI候选正文、revision=2`;负路径陈旧 revision=99→`code 1041000002 乐观锁拒`(反假绿)。**MVP #1 纵切(AI候选→采纳入正文)在真实 HTTP+mock鉴权+租户过滤+真实 PG 上活体闭环**。全栈起法+活体命令固化入 [.agents/knowledge §六](../../.agents/knowledge/external-deps-and-gotchas.md)。**遗留**:studio 渲染层 UI e2e(Playwright,`accept-suggestion.spec.ts`)依赖 vite dev + 联调生成流,后端活体已 curl 证;非阻塞。
2026-06-15  ✅ **studio 整套活体 e2e 单次全绿 8/8**(承 MVP#1 长板):关 MSW(VITE_API_MOCK=false,固化进 playwright.config webServer env + .env.local)、vite 代理→真实单体 48080、chromium 真跑——accept-suggestion 正+负(DB 实证 block3 rev1→2 + AI摘要正文 + ai_suggestion 归因落库)、knowledge-confirm(种 pending 草稿→确认→draft confirmed + 新建 Canonical entity)、live-read 4 读旅程、workspace 壳。修红:workspace.spec.ts 原 mock 假绿(断言「星海迷途」)MSW-off 下必红→改不依赖 mock 壳冒烟。读 ContentSourceServiceImpl 证 merge 校验序 requireRevision 先于 pending(正负可并行)。诚实遗留:e2e 暂依赖 /tmp 助手手动 reseed,待补 playwright global-setup 自播种。
2026-06-15  ✅ **studio 市场生产侧发布草稿纵切活体绿 + 修真实潜伏后端 bug**(承前端长板,goal 主攻):新增 `MarketPublish`(/market/publish)生产侧表单 + `useMarketPublish` hook;保存发布草稿(POST /marketplace/publish-drafts)→ my-publish-records 真实回读,`market-publish.spec.ts` chromium MSW-off 正+负绿,DB 证 muse_market_publish_draft 落库(status=draft);整套 e2e 10/10 + vitest 47/47 无回归。**修真实 bug**:publish draft/check/request 的 (tenant_id,command_id) 部分唯一索引(V15)与 mapper 无谓词 `ON CONFLICT` 不匹配→PG 报 no unique constraint matching→savePublishDraft 500(链路从未活体跑过、潜伏至本切片);修=部分→完整唯一索引(V22 迁移 + muse_slice_live 已应用)。遗留:其余 market 表(handoff/appeal 等)同类部分索引待收口。
2026-06-15  🔎 **account facade 活体订正(无净代码改动,反假绿)**:user 据 §五A"account 21 端 UNAVAILABLE"选"account 后端 facade 真实化"。Explore 静态分析判 MarketAccountProjectionFacade 阻塞 purchases/licenses/publish-records;**实测推翻**——单体内 market `MarketAccountProjectionProvider`(@Service)本身 implements MarketAccountProjectionFacade、对三类型放行,`@ConditionalOnMissingBean` 使其压过 member 的 Unavailable 兜底 → 三端在单体本就可用。curl 真返投影(含 market-publish e2e 写入的 publish-records 5 条=market→account 端到端)。曾据 Explore 加 member-local `RealMarketAccountProjectionFacade`+改 autoconfig、rebuild+restart 验证;**可逆翻转测试(全局 purchase=0 仍返回空而非 UNAVAILABLE)证实活跃 facade 是 Provider 而非我的 count-gating facade → 单体 no-op 且违背原设计,已回退**(member 模块工作树干净)。顺带:restart 时 Flyway 真实应用 `V22`(market 索引修复)"Successfully applied 1 migration ... v22"。结论:单体无 account facade 接线缺口待补;export/new-api 为正确 fail-closed 外部依赖。教训:跨 BC facade 判定必须以单体实跑为准,静态分析会漏 monolith 跨模块 bean 绑定。
2026-06-15  ✅ **market 残余 partial-index 系统性收口 + 真实 PG IT(V23)**:续 V22,修 handoff_event/appeal_material/authorization_summary/appeal_event/appeal 5 表 (tenant_id,command_id) 部分→完整唯一索引(grep 实证其 mapper 发无谓词 ON CONFLICT,潜伏同 publish 链路 bug)。新增 `P1rMarketCommandIndexFlywayMigrationIT`:真实 PG clean→迁移 V1→V23(Flyway "Successfully applied 23 migrations ... v23")→断言 V22/V23 修复的 9 个命令索引均完整唯一(可作 ON CONFLICT 仲裁器),**Tests run 1, Failures 0, Errors 0, Skipped 0**(与 target=V15 的 `P1rMarketFlywayMigrationIT`「断言历史 partial 态」互补)。V23 已应用 muse_slice_live + 全新 `muse_p1r_cmdidx_test` 库迁移验证。其余 market 部分 command 索引未被当 arbiter,保持不变。
2026-06-15  ✅ **知识库工作台知识图谱视图 + 修 confirm 重名潜伏 500(承前端长板,goal 主攻)**:①前端新增 `KnowledgeGraphPanel`(/knowledge/:workId)经 GET /works/{id}/graph 读真实 muse_knowledge_entity/relation,渲染已入库 Canonical 实体(节点)+关系(边),与草稿面板成"候选→确认→正式图谱可见"双轨闭环;`knowledge-graph.spec.ts` chromium MSW-off 绿 + curl 证 code:0/节点 huotituopusuqing+huoti_related 边。②**修真实潜伏后端 bug(反假绿,task_497da70f)**:confirm 重名实体(同 work+类型+规范名+范围)原触发 uk_muse_knowledge_entity 唯一冲突→未捕获 DuplicateKeyException 冒泡 HTTP 500;改 `writeCanonicalEntity` 前置 `selectByIdentity` 预检(镜像约束列、不滤 deleted)→`markConflicted`(REQUIRES_NEW)+`KNOWLEDGE_ENTITY_DUPLICATE`(1043002004);必须前置预检——PG 约束冲突使当前事务 aborted,catch 后任何写必失败。活体证:colliding 草稿 confirm→code 1043002004(非 500)、DB 草稿转 conflicted+实体数不变(无伪造重复);正路径 knowledge-confirm e2e 回归绿;tsc -b 干净 + vitest 47/47。

---

五、master plan(P1R-7 端到端验收)收口清单 —— 活 backlog(2026-06-14 起,goal: master plan complete)

master plan = P1R(总 spec→阶段 spec/plan,P1R-0…P1R-7,见 p1r-stages)。P1R-0~6 各 BC Real API 门禁口径基本就位;收口主体 = P1R-7 端到端验收,其阻塞 = 现状基线 §6.3 最危险缺口 Top 6。本清单为该 goal 的唯一驱动 backlog,就地更新、勿另起过程文档。状态:✅完成 / 🔧进行 / ⬜未起 / ⏸判定范围外。

goal 主攻 = 活体纵切·每 BC 一条端到端用户旅程,在跑起来的单体(48080)上 curl 实证(正+负路径),验收=achieve the product goal。 per-BC 活体度量:

• content+ai(AI 候选→采纳入正文):✅ 活体证(MVP#1;正:newRevision=2+正文写入;负:乐观锁 1041000002)+ ✅ 前端 rendered UI e2e(chromium,关 MSW 直连活体:生成→采纳→真合并 happy + 乐观锁 negative,见 §五C)
• knowledge(确认草稿 Shadow→Canonical 实体):✅ 活体证(2026-06-14;正:GET pending→POST confirm→muse_knowledge_entity 落库+草稿 confirmed;负:revision 1043002001 / source-stale 1043002002→草稿 conflicted)+ ✅ 前端 rendered UI(确认入库 e2e chromium,见 §五C)+ ✅ 知识图谱视图(graph rendered-UI 活体证,2026-06-15)+ ✅ 修 confirm 重名 500→干净冲突 1043002004
• market(资产采纳/安装):✅ 活体证(2026-06-14;正:GET listed 资产→purchase licenseId:1/active→install installationId:1/installed;DB:授权快照+购买事实 completed+安装 installed 三落库;purchase 经 MarketAccountProjectionProvider 投影 account) + ✅ 生产侧发布草稿 rendered-UI e2e(2026-06-15;/market/publish→publish-drafts→my-publish-records,DB 证 publish_draft 落库;附带修 publish 部分索引 ON CONFLICT bug→V22,见 §五C)
• account/member(个人中心:profile/purchases/licenses/entitlements/usage 读):✅ 活体证(2026-06-14;profile 返回脱敏 PII;purchases/licenses 含上一步 market 购买+安装的投影=market→account 跨 BC 端到端通;entitlements/usage 干净空数据)。重要订正:此前 account 读 500 真因是基座 schema 漏 member_user.register_terminal 列 + 缺 infra_api_error_log_seq(非 facade 缺口),已补基座文件 yudao-base-schema-postgres.sql(可复现);baseline "21/33 阻于 facade" 部分被推翻——投影通、卡在基座。
• agent(ai)(创建/列表):✅ 活体证(2026-06-14;POST /muse/agents→agentId:1→GET 列表含之 active;试用 New-API 外部,非阻)
• events(SSE 事件流):✅ 间接证(AI 候选生成走 connectAIStream SSE;events BC streamEvents 已双评审真实 PG IT,coverage completed)
• meta(admin 治理发布):⏸ 阻于 MetaImpact 用量投影特征(见 A;admin 侧、非核心用户旅程)

总评(2026-06-14):后端产品目标已实质达成——核心用户旅程("AI 先审后入"创作 + 知识确认 + 市场采纳 + 个人中心 + 智能体)在跑起来的单体(48080)上端到端活体证毕(正+负路径,反假绿),含 market→account 跨 BC 投影。仍缺:前端 studio 渲染层(仅 ~14% 真连,B3 大长板)→"用户在 UI 里点"未全达;meta admin 治理(特征缺口);market 生产侧发布 UI。下一主攻=前端逐旅程接活体 + playwright。

A. 后端跨 BC facade 真实化(B2,非 stub,真实委派)

• ✅ MuseContentWorkOwnerFacade(content→ai)/ ContentKnowledgeWorkOwnerFacade(content→knowledge):@Primary 真实委派 content-api,缺口已闭(B2 勘察曾误判为未做)。
• ⏸ MetaImpactFacade(meta 发布链,重新判定:缺特征非接线,降优先级):现仅 UnavailableMetaImpactFacade 抛 META_EXTERNAL_OWNER_UNAVAILABLE,阻断 publish/activate/rollback/deprecate。2026-06-14 勘察发现:content/ai/knowledge DAL 均未持久化 schemaKey 用量引用(content 的 "MetaSchema 版本" 仅在请求/响应 VO 作传参,非存储的"作品 X 用 schema Y"关系),无独立 export 模块。故无数据可真实计数,Unavailable 抛错实为诚实 fail-closed(拒绝伪造)。真实化 = 先建"meta-schema 用量投影"数据模型(各 owner 新表 + 写时落库 + 计数 API),是多模块特征工程而非 facade 接线;且 meta 治理属 admin 侧、用户价值低。判定:置后,待用量投影建模专项。service 层 MetaSchemaImpactPreviewServiceImpl 已就绪等真实 facade。
• ✅ MarketAccountProjectionFacade(account purchases/licenses/publish-records 读)——2026-06-15 活体订正(反假绿):单体内由 market MarketAccountProjectionProvider(@Service,本身 implements MarketAccountProjectionFacade、对 purchase/license/publish 放行)跨模块提供,@ConditionalOnMissingBean 使其压过 member 的 Unavailable 兜底(后者仅 member-alone 才用)。这三端在单体本就可用——curl 真返投影:purchase(活体市场资产·测试/completed)、license(installed)、publish-records 5 条含 market-publish e2e 的 submitted/draft = market→account 端到端。原"21 端 *_UNAVAILABLE"是静态误判(同 handoff 被推翻判定类)。单体内真正 fail-closed 的 account 端 = export/download(AccountFileServiceFacade)+ new-api recheck(NewApiAccountFacade),均正确 fail-closed(未配置外部服务:对象存储/New-API),非接线缺口。结论:单体内无可真实化的 account facade 接线缺口(member-local 真实 facade 仅 microservices 部署需要,范围外;本轮曾试做 RealMarketAccountProjectionFacade,翻转测试证实单体 no-op 后已回退)。
• ⬜ AccountAttributionSourceFacade(account 归因,中):属"源传播事件驱动"副路径(同下条 source-owner),不阻核心读旅程;各 owner BC 出归因出站 API 后接通。
• ⬜ 4× Unavailable*SourceOwnerFacade(AI←Account/Meta/Market/Knowledge 源属主校验,中):返回 owner_missing。属"源传播事件驱动"副路径,不阻 MVP#1 核心切片;各 owner BC 出 source-owner 出站 API。
• ⏸ 正确 fail-closed(非缺口):UnavailableNewApiAccountFacade/UnavailableAccountFileServiceFacade/UnavailableSecurityToolGrantApprovalFacade——依赖未配置的外部服务(New-API/对象存储/治理审批),保持 fail-closed。

B. 验收债:86 个 needs_verification operation(B-debt,门禁口径→真实证据)

• 🔧 验收债真实 IT 战役(2026-06-15 起,goal=验收债·真实 IT)。实际 needs_verification(台账 docs/superpowers/reports/p1r-api-coverage.json)= content 37 / market 28 / account 21 = 86(均已 dedicated;completed 仅缺真实证据 + 人工批)。范式:P1rContentCoreCompletedApprovalIT / 本批新 IT;跑法见 §四(_test 库 + argLine + -DreuseForks=false)。
  • 批1 ✅ 已交付(content work/chapter/block 生命周期 11 op):P1rContentWorkLifecycleCompletedApprovalIT(commit 2499c24,1/1 绿 mini-infra PG,独立复跑+逐 assert 反假绿复核)覆盖 createWork/updateWork/deleteWork、createChapter/updateChapter/deleteChapter/reorderChapters、createBlock/deleteBlock/mergeBlocks/splitBlock;每 op 断言 HTTP+真实 muse_content_* 持久化事实 + command_log。产出=Codex 起草 + Opus fork 落地纠偏双代理。证据就绪,completed 待人工批(把这 11 op 加入 P1rApiCoverageReportTest.APPROVED_COMPLETED_OPERATIONS + 台账翻 completionStatus;agent 不自批=反假绿)。
  • 剩余:content 26(约 15 为 FileService/New-API/SSE fail-closed → 只能验"失败关闭"真实证据)+ market 28 + account 21,按批续推。
• ✅ P1r*IT 真实 PG 基线(2026-06-15,mini-infra PG)= 23/23 IT 类全绿(99 用例 0F/0E;2 例 external-acceptance 因未设 MUSE_P1R_EXTERNAL_ACCEPTANCE 跳过)。P1rKnowledgeFlywayMigrationIT 版本断言由硬编码(V14→V21→V23 复发两次)改为 MigrateResult 动态自适应(commit 4d46d7a,Codex+Opus 双代理合并)。完整跑法见 .agents/knowledge §四:_test 后缀隔离库 + source infra.env(密码仅 env)+ argLine(SOCKS 清 + p1r.flyway.url/user/locations)+ -DreuseForks=false(批量必加,避 Market IT 属性脱敏污染复用 fork)。
• 🔧 ai/平台预存红测试整改(CI 接电将暴露):MuseAiTaskServiceTest 桩缺失 11 例 NPE ✅ 已整改(补 eventPublishOutboxService/candidateReviewService 桩 + review lenient,40/40,2026-06-15);QiniuSmsClientTest 时区硬编码 ✅ 已整改(5/5,机器无关);MuseAiEventPublishOutboxMapperTest ✅ 真实 PG 实跑 5/5(mini-infra PG,harness=infra.env+argLine SOCKS 清;隔离 schema 自建自清)。ai/平台预存红三项全清。

C. 前端 muse-studio(B3,体量最大,最长的长板)

• ✅ 2026-06-15:整套 studio e2e 单次全绿 8/8(chromium,MSW off 直连单体 48080)——accept-suggestion 正+负 / knowledge-confirm / live-read ×4(content·market·account·ai) / workspace 壳;MSW-off 已固化进 playwright.config.ts webServer env(CI 自起 vite 生效)+ .env.local(本地);workspace.spec.ts 原 mock 假绿(断言「星海迷途」,MSW 关后必红)已改写为不依赖 mock 的活体壳冒烟,消除最后一处 MSW 互斥红。下列各 ✅ 切片即构成此 8/8。(套件此后随切片增长:live-read ×4→×6 增「购买/授权」「安全事件」深页 + market-publish ×3→×8 增上架生命周期徽标 + 申诉提交·撤回·补充材料写路 + appealStatus 回显 + account-security-ack ×1 写路,playwright test --list 当前共 20 例(+knowledge-graph);每轮按改动旅程实跑验证——accept-suggestion/knowledge-confirm/security-ack/market 上架徽标·申诉 依赖手工重种子。2026-06-15 reseed 全部每轮种子依赖后 --workers=1 串行整套 20/20 单次全绿(真实后端 MSW-off;2026-06-15 已落地可入库种子:e2e/global-setup.ts(pg 直连真实 PG、凭据从 infra.env 读不入库)+ playwright globalSetup/workers:1,每轮自动复位 graph/confirm-draft/accept(block3→rev1)/security-ack/appeal fixture;source infra.env && pnpm test:e2e 即 20/20 单次全绿、零手工 /tmp 种子(消费态下实证 globalSetup 复位后整套绿)。)
• 现状:其余旅程仍 ~14% 真连、dev 默认 MSW;但 MVP#1 已打通"关 MSW→直连活体→playwright e2e"模式(见下),可复用到后续旅程。
• ✅ AI 候选采纳(rendered UI 活体证,2026-06-14):main.tsx 加 VITE_API_MOCK=false 开关关 MSW、前端直连活体单体;accept-suggestion.spec.ts 在 chromium 实跑——happy-path(生成经 page.route stub 发真实 suggestionId→点"采纳替换"→真合并)隔离跑绿 + DB 证(block rev1→2、正文=候选);negative-path(陈旧 revision)绿(乐观锁 1041000002)。连带真实修复 client.ts 注入 tenant-id(活体集成缺口,dev MSW 不校验故没暴露)。遗留:happy-path 受种子状态依赖(合并后 block rev 变 + RQ 缓存,需 fresh 种子复跑);workspace.spec.ts 已改活体壳冒烟(2026-06-15,MSW 互斥红消除、整套 8/8 全绿);suggestion 合并后留 pending=merge 不在同事务回写 AI 域状态(靠 outbox→AI 异步翻,本机 dispatcher 节流故 DB 仍 pending,读 ContentSourceServiceImpl 确认,非产品 bug)。
• ✅ content/market/account/ai-agent 读旅程(rendered UI 活体证,2026-06-14):live-read.spec.ts 4/4 绿(MSW off,chromium:作品列表/市场浏览/个人中心/智能体列表均渲染真实后端数据)——证 tenant-id 修复后 studio 直连活体单体跨 BC 取数、真实数据形态与页面渲染契约对齐。
• 🔧 知识库工作台:✅ 确认草稿(先审后入)rendered-UI 活体证(2026-06-14)——KnowledgeDraftPanel(/knowledge/:workId)列待确认草稿+「确认入库」→ 真 confirm 物化 Canonical 实体(knowledge-confirm.spec.ts chromium MSW-off 绿,DB 证 draft confirmed+entity_id);后端补 SummaryRespVO 暴露 confirm 并发/源令牌。✅ graph(知识图谱视图)rendered-UI 活体证(2026-06-15):KnowledgeGraphPanel 经 GET /works/{id}/graph 读真实 muse_knowledge_entity/relation,渲染已入库 Canonical 实体(节点)+关系(边),与草稿面板成"候选→确认→正式图谱可见"闭环(knowledge-graph.spec.ts chromium MSW-off 绿 + curl 证 code:0/节点+huoti_related 边)。✅ 修真实潜伏 bug(反假绿,task_497da70f 已闭):confirm 重名实体原冒泡 HTTP 500→改 writeCanonicalEntity 前置 selectByIdentity 预检→markConflicted(REQUIRES_NEW)+KNOWLEDGE_ENTITY_DUPLICATE(1043002004)干净拒绝(curl 证 1043002004 非 500、DB 草稿 conflicted 且无伪造重复)。🔎 bindings 活体勘察(2026-06-15,反假绿):precheck→bind 写路真实+绿(curl 证 user_kb:POST .../prechecks→code:0/allowedPurposes[search,generate]/active、POST .../knowledge-bindings→code:0/bindingId=1 写 muse_knowledge_binding;KB 经 POST /knowledge-bases 真建)。但读回 gap——GET /local-knowledge.sourceBindings 读独立投影表(MuseKnowledgeSourceBindingProjectionMapper,事件驱动填充),bind 不同步写该投影,故刚绑定的来源在 UI 不可见;controller 亦无 GET bindings 端点。bindings 因此非干净端到端旅程(写成功但无诚实读回),与 account 归因/source-owner 同属"事件驱动副路径待投影接线"(见 §五A),不建一侧写 UI(反一侧设计)。🔎 publish 活体勘察(2026-06-15):publish-prechecks 恒 blocked(EXTERNAL_RIGHTS_PRIVACY_VALIDATOR_NOT_CONFIGURED 无条件加 + readiness status=blocked;snapshot 步拒 blocked readiness)→ 知识发布正确 fail-closed(外部权利/隐私校验器未配置,同 exports/New-API),非可建绿旅程。dup-fix 补单测回归守护:MuseKnowledgeDraftServiceTest 新增 should_failClosedWithDuplicateCodeWhenCanonicalEntityIdentityExists(预检命中既有实体→KNOWLEDGE_ENTITY_DUPLICATE+markConflicted+绝不 insert),18/0 绿。结论:knowledge 前端可建旅程已尽(confirm+graph ✅);bindings(事件驱动投影读回)/publish(外部校验器)均正确受阻→后置,待投影接线/外部依赖配置。
• 🔧 市场生产侧:✅ 发布草稿 + 提交审核全链(创作者飞轮)rendered-UI 活体证(2026-06-15)——MarketPublish(/market/publish):①「保存发布草稿」(POST /marketplace/publish-drafts)→my-publish-records 真实回读;②「提交审核」做 save→运行检查(POST .../checks)→检查通过提交申请(POST /publish-requests)全链(licenseType+权利声明为检查硬门槛)。market-publish.spec.ts chromium MSW-off 8/8 绿(草稿正 / 缺标题负 / 提交全链 / 上架生命周期徽标 / 申诉提交·撤回·补充材料写路 / appealStatus 回显),DB 证:muse_market_publish_draft=draft、muse_market_publish_request=submitted、muse_market_review_event=submitted 落库;草稿测幂等自包含、全链测唯一名可重复跑。MarketBrowse 加「我要发布资产」入口。附带修真实潜伏后端 bug:publish draft/check/request/review_event 的 (tenant_id,command_id) 为部分唯一索引(V15 WHERE command_id IS NOT NULL),mapper insertIgnore 却发无谓词 ON CONFLICT (tenant_id,command_id)→PG 无法用部分索引作仲裁器→save/check/submit 500(链路从未活体跑过故潜伏);修=部分→完整唯一索引对齐 command/purchase 约定(V22__fix_market_publish_command_unique_index.sql 4 表 + muse_slice_live 已应用,零 Java 改动/零重启)。✅ 上架状态可视化(读,2026-06-15):「上架=审核通过自动 markListed」(AdminMarketReviewServiceImpl,非生产者动作),生产者侧 MarketPublish「我的发布记录」新增发布生命周期中文徽标(草稿/已提交/审核中/已通过/已上架/已驳回/需补充…)+ nextAction/appealStatus 副文本,使创作者看到 publish→review→list 进度反馈(market-publish.spec.ts 第 4 例断言 listed→「已上架」、rejected→「已驳回」渲染;种子 /tmp/SetReqStatus.java 置 req#2→listed、#3→rejected)。申诉(appeal):后端已验证 real+fail-closed(2026-06-15)——curl:对自有已驳回资产 POST /marketplace/appeals(review_rejection)→appealId/pending;负路 他人资产→1044000024 无权访问、不存在资产→1044000003 资产不存在(fixture=asset(pub=1)+rejected request,见 /tmp/SeedAppeal.java)。✅ 申诉(appeal)写路 UI——gap 已解(2026-06-15):根因=my-publish-records 的 assetId 是 publish-record id,非 submitAppeal.requireAsset 所需的物化 muse_market_asset.id(资产仅 admin 审核通过 markListed 物化)。后端最小契约改动:PublishRecordItem/MarketPublishRecordItemRespVO 加 marketAssetId(=request.asset_id 命中真实 muse_market_asset 且归属当前发布者才给,否则 null=fail-closed 不放开入口),MarketPublishServiceImpl.resolveMarketAssetId 解析(已重建 jar + 重启单体 26483)。前端:仅 marketAssetId 非空 + 状态∈{rejected/compliance_blocked→review_rejection、delisted→delist、recalled→recall} 的记录放开「发起申诉」→ 面板填理由 → useSubmitAppeal(新 commandId 幂等)真打 POST /marketplace/appeals→申诉已提交(pending)(market-publish.spec.ts 第 5 例 chromium MSW-off 绿)。DB 证(反假绿):muse_market_appeal 追加行 status=pending、commandId=前端 UUID(e2e 点击产 appealId=3);curl 正负路(自有已驳回→appealId/pending;他人→无权访问;不存在→资产不存在);后端 MarketPublishServiceTest 回归通过。种子 /tmp/SeedAppeal.java(asset(pub=1)+rejected request,asset_id=物化资产)。✅ 申诉补充/撤回 UI(2026-06-15):同类 gap——生产者本无自己申诉的列表端点,故新增 app-api GET /marketplace/appeals(appListMyAppeals+MuseMarketAppealMapper.selectListByUser+MarketMyAppealItemRespVO,带 canSupplement/canWithdraw 派生)。MarketPublish「我的申诉」区列申诉 + 中文状态徽标(待处理/审核中/待补充材料/维持原判/已恢复/已关闭…);canWithdraw(非终态)放开「撤回」→useWithdrawAppeal→POST .../withdraw(expectedStatus 乐观锁)→closed;canSupplement(supplementing 态)放开「补充材料」→useSupplementAppeal→POST .../supplements(privacyConfirmed)→reviewing。market-publish.spec.ts 第 6/7 例 chromium MSW-off 绿(撤回→已撤回、补充→材料已补充),DB 证(反假绿):withdraw→muse_market_appeal status=closed、supplement→muse_market_appeal_material 追加行(e2e 点击产 material#2);后端 MarketAppealServiceTest 15/15 + AppMuseMarketAppealControllerTest 6/6 回归通过。种子 /tmp/SetAppealSup.java(置 supplementing;提交后→reviewing 故每轮重置)。✅ appealStatus 记录回显(2026-06-15):my-publish-records 经 MuseMarketAppealMapper.selectLatestByAssetIdAndUser + resolveAppealStatus 回填该物化资产被当前发布者发起的最新申诉态到记录 appealStatus(无物化资产/无申诉则 null,marketAssetId 与 appealStatus 两路共用各只查一次);MarketPublish 发布记录副文本以中文徽标渲染「申诉：<待处理/审核中/已关闭…>」。market-publish.spec.ts 第 8 例 chromium 绿(recId=5/marketAssetId=2 回显 appealStatus=closed→「申诉：已关闭」);后端 MarketPublishServiceTest 14/14 回归通过。至此市场生产者飞轮端到端完整:发布(草稿→检查→提交)→上架状态可视化→申诉(提交/补充材料/撤回)全生命周期 + 申诉态回显。遗留已收口(2026-06-15):handoff_event/appeal_material/authorization_summary/appeal_event/appeal 5 表(其 mapper 确发无谓词 ON CONFLICT)经 V23 系统性修(部分→完整唯一索引)+ 新增 P1rMarketCommandIndexFlywayMigrationIT 真实 PG 验证(clean→迁移 V1→V23→断言 V22/V23 的 9 个命令索引均完整、可作 ON CONFLICT 仲裁器,Tests run 1/0F;与 V15-pinned P1rMarketFlywayMigrationIT 互补)。其余 market 部分 command 索引(favorite/auth_snapshot/installation/asset/governance_*/handoff/source_status_event/account_projection)未被当 command-arbiter,保持不变。
• 🔧 个人中心:✅ profile/用量/权益 + 我的购买/我的授权 + 安全事件(读+确认写路)(rendered-UI 活体证,2026-06-15)——PersonalCenter 新增「我的购买/我的授权」渲染 market→account 投影真实记录(useAccountPurchases/useAccountLicenses→/account/{purchases,licenses};live-read.spec.ts 第 5 例 chromium MSW-off 绿,断言真实资产「活体市场资产·测试」渲染——证后端 account 读端在单体可用即被 UI 消费,见 §五A 活体订正);新增「安全事件」区渲染 GET /account/security-events 真实摘要(useAccountSecurityEvents→AccountPageResult<SecurityEventSummaryRespVO>;eventType/severity 徽标 + 已确认/待确认状态;live-read.spec.ts 第 6 例 chromium MSW-off 绿,断言种子事件「活体安全事件·异地登录提醒」渲染)。确认写路:未确认事件展示「确认」按钮→useAcknowledgeSecurityEvent(每次发新 commandId,后端按 commandId 幂等)真打 POST /account/security-events/{id}/acknowledge(action=acknowledged)→列表失活重取翻「已确认」、按钮消失(构成 acked→无动作 UI 不变量;account-security-ack.spec.ts chromium MSW-off 绿,种子事件 B「待确认演练」)。后端正负路 curl 实证(反假绿):正路 acknowledge 真实事件→code:0+列表 acknowledged 翻 true;负路 acknowledge 不存在 eventId→404 安全事件不存在、非法 action→400 参数校验,均 fail-closed 非许可桩。写入 DB 双证:muse_member_security_event.acknowledged 翻 true + muse_account_security_event_ack 追加 1 行(action=acknowledged、commandId 为前端 UUID=权威处理历史,非覆盖)。种子幂等可重置(/tmp/SeedSec.java:事件A读锚点幂等插入 + 事件B写锚点每轮重置为未确认)。本轮实跑:account-security-ack 1/1 + live-read 6/6 + vitest 47/47 + tsc 干净。仍 ⬜:exports / downloads / new-api-binding 深页(后端均为正确 fail-closed 外部依赖:对象存储 / New-API 未配置,非接线缺口,见 §五A)。
• 收口口径:每切片"关 MSW→真连活体单体→playwright e2e 绿"才算完成(反假绿)。

D. gateway 接线(B4,判定:单体部署范围外)

• ⏸ 单体 muse-server 直服 48080 /app-api,网关不在单体部署关键路径。muse-gateway 现 0 条 Muse BC 路由 + 4 条死路由(bpm/pay/report/mp)。收口动作:要么清理死路由 + 加 /app-api/muse/**→muse-server 单体路由,要么文档明确"网关仅微服务拆分期启用"。不阻 P1R-7 单体验收。

E. ADR 级 ArchUnit grant/runtime 包隔离(B5,判定:项目显式后置二期)

• ⏸ BC 边界门 BcBoundaryArchTest 已存在且强制(豁免空)。grant/runtime 包级隔离被项目显式后置二期,严格说不在 P1 范围;当前类命名 + 运行时 Guard 软约束。收口:补 ArchRule 强约束 runtime 不得 import grant,或文档确认后置。

收口顺序(价值/可验证性优先)

1. ✅ 红测试修复(本轮) 2. ⬜ MetaImpact 真实化(解 meta 发布链,多模块) 3. ⬜ account 投影/归因(解 21 端) 4. ⬜ 验收债按 BC 补真实 PG IT 5. ⬜ 前端逐切片 + playwright 活体 e2e 6. ⏸ gateway/ArchUnit 判定收尾。