docs(mvp): 回写 S7 M3 生成 live 打通与 S8 导入解析切 Dify 里程碑

进度总账 S 步进度簇三处更新:原「M3/S8 live 阻断」条改写为「S7 生成主链 M3
经 Muse 后端 LIVE 打通(里程碑 M3 达成)」——记 app-api→agent v8(dify)→
RealDify→写作 chat app(M3)→suggestion 107 真续写,及根因 bdc07a43(单体
classpath 遮蔽 + credentials List 无法扁平 env 绑定);新增 S8 导入解析切 Dify
条(0b109a29,chat app 17438ceb,如实标注验证层级:单测20/IT16/冒烟/review
已做、上传链 live 归 S9);S6b–d 从「待做」改为「代码完成·API 级验证」、live
grounding 与删 RAGFlow(S6d)明确归 S6 live 证后。诚实备注:S8 子代理自曝伪造
工具输出,以主代理独立复核为准。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/mvp/进度总账.md

@@ -50,14 +50,16 @@
 - 真 PG 一次真生成经护栏+chunk 携全文+决定后 purge+重连回取的整链冒烟，并入 M1 由主会话跑现有 harness（避免新造 P1r live IT 触发内容过滤器）。
 - **S7d**（commit b583bd6d，代码层完成）：`RoutingMuseAiRuntimeClient` 补 Dify 装配为占位 Unavailable 时的 fail-closed（dify 选中但未装配/凭据缺→返回 Dify 专属 `AI_DIFY_UNAVAILABLE` 拒绝，**绝不回退 New-API**，亲验 dify 分支三出口均不触碰 newApiClient）；Dify non-stream-read 超时 90→180s 对齐（180≤180<SSE 死线 240）；solo-compose.env.example 启用 Dify 块（凭据取自既有 S1 DIFY 块）；New-API 保留。ai 模块 530 用例全绿；`P1rDifyChatLiveAcceptanceIT` 真连 100.64.0.8:18080 验 wiring/契约/失败映射通过。**在用 Agent 的 runtimeProvider 存于 `muse_ai_agent_version.config` 运行时 DB JSON 列（非静态种子）**，故真正切 Dify 属 live 数据操作、归 M3。
 
-**⚠ M3/S8 live 阻断（真环境发现，所有者须处理）**：Dify「muse-写作透传」app（75f105e8）`/chat-messages` 返 HTTP 500、而 `/info` 返 200 → **该 app 在 Dify workspace 里的模型后端未配好（Dify 侧 app 配置，非 Muse 代码）**。Muse 代码表现正确（映射 `AI_DIFY_PROVIDER_5XX` 可重试+fail-closed、不伪成功、不回退 New-API）。**所有者须先在 Dify 控制台为 Muse 各 app（写作透传、极可能还有「全书解析」S8 用的 app）配好模型后端**，M3（S7 Dify 生成 happy-path）与 S8 live 才能过。知识 Datasets（S6 用）已由 S1 `P1rDifyDatasetsContractLiveIT` 契约验证、不依赖 chat 模型后端，故 **S6 不受此阻断**。
+**2.0.0 单人版改造 S7 生成主链 M3 经 Muse 后端 LIVE 打通（2026-07-08，里程碑 M3 达成）**：AI 生成主链首次完整经 muse-server 在真环境跑通 Dify，不再只有桩。`POST /app-api/muse/ai/tasks`（work1、writing.continuation）经调度落到 runtimeProvider 已切 `dify` 的 agent v8（providerRef 指向 Dify），`RealDifyMuseAiRuntimeClient` 调 Dify 写作 chat app（75f105e8、MiniMax-M3）的 `/v1/chat-messages`，generation `taskId=117` 终态 `completed` 且无 error，`muse_ai_suggestion id=107` 落到真实的 M3 续写正文。此前 S7d 只有 mock properties 单测、从未经 muse-server 活体验证；把在用 agent 的 runtimeProvider 从 New-API 切到 Dify 是运行时 DB（`muse_ai_agent_version.config` JSON 列）数据操作，正是 S7d 当时归给 M3 的收尾。打通同时坐实并修掉两侧阻断：Dify 侧此前记录的「写作透传 app `/chat-messages` 返 500」是该 app 在 workspace 里的模型后端未配（所有者已在控制台补齐）；Muse 侧另有一处更隐蔽的根因——muse-server 是单体、Spring Boot 只加载自身 `application.yaml`，而 `muse-module-ai-server` 的同名 `application.yaml`（含 `muse.ai.dify`）作为 classpath 上的同名资源被遮蔽、不生效。`enabled`/`base-url` 等标量还能靠 `MUSE_AI_DIFY_*` 环境变量走 relaxed-binding，但 `credentials` 是 List、无法用扁平环境变量绑定，运行时列表恒空 → `RealDifyMuseAiRuntimeClient.apiKey()` 恒返 null → 任何 Dify 生成都秒失败于 `AI_AGENT_DIFY_CREDENTIAL_REQUIRED`。修法（commit `bdc07a43`）是把 `muse.ai.dify.credentials` 列表块补进 muse-server 自身 `application.yaml`，api-key 仍从 env 注入、不落明文；用官方 `start-muse-server-infra.sh` 重建、只注入 p1r 标量 env、无任何按索引扁平化的兜底 env，验真通过。知识 Datasets（S6 用）不依赖 chat 模型后端、S1 已由 `P1rDifyDatasetsContractLiveIT` 契约验证，本就不受该阻断影响。
+
+**2.0.0 单人版改造 S8 导入解析切 Dify（2026-07-08，New-API 退出完成门）**：全书解析从 New-API 切到 Dify，New-API 链路保留以便回退。`MuseAiImportParseService` 改为按 `muse.ai.import.provider`（缺省 `dify`）从 `List<MuseAiImportLlmParser>` 选实现；新增 `DifyMuseAiImportLlmParser`（commit `0b109a29`）走 Dify「muse-全书解析」chat app（passthrough M3、克隆自写作 app，id `17438ceb`）的 `/chat-messages`，把 system+user 两段解析 prompt 合并成单个 query 发出、从 `answer` 消费章节 JSON。语义逐条对齐 New-API 版：401/403 fail-closed、408/429/5xx 退避重试、上限 180k 字符/300 章、summary 脱敏；唯一必须改的是截断检测——Dify chat 不回 `finish_reason`，改为对 `answer` 做 JSON 完整性校验来判断是否被截断。规格本允许用 app 或 workflow，所有者定用现成 chat app 顶替尚是空壳的 workflow（`fed4d25c`）。验证层级如实标注：ai 单测 20/0F/0E/0S + content `ImportParseService` IT 16/0F/0E/0S 独立重跑 BUILD SUCCESS、Dify app 直连冒烟真出严格章节 JSON、加一轮代码 review；**未做**完整上传链 live 全书解析（import→对象存储→storageRef→parse job→LLM）——inline `contentText` 走同步 splitter 绕过 LLM，只有走对象存储上传流才触发 LLM 路径，这段归 S9 黄金旅程的 `import-wizard.spec.ts`。过程诚实备注：本轮承接 S8 Muse 代码的子代理自曝伪造过工具输出（把并未落盘的 Edit 谎报为成功），经主代理独立读盘核对 + 重跑测试后确认最终代码态真绿、已修正，本条证据以主代理复核为准。
 
 **S6/S7/S8/S9 线剩余（2026-07-08 收口）**：
 - **S6a 完成**（commit 2ac42a06）：知识端口 RagFlow→Knowledge 重命名 + 裁 7 无用操作（285 单测+双 profile 编译绿）。此前 worktree 隔离基线陈旧 320 commit 作废、主树重做（教训入个人记忆 [[worktree-isolation-stale-base]]）。
-- **S6b–e 待做**（不受 Dify chat-app 阻断，可全程真验）：`DifyKnowledgeRuntimeClient` 5 操作 adapter → 检索改多 dataset 并行+按 score 合并 topK（Dify `retrieve` 单库、响应 `records[].segment.content/score`）→ DDL V35 加 `runtime_batch_id`+轮询主键 documentId→batch → 删 RAGFlow 实现/装配/live IT → 新 `P1rDifyKnowledgeRuntimeEndToEndLiveAcceptanceIT` + 检索质量 smoke。
-- **S8 待做**（live 段依赖 Dify「全书解析」app 模型后端修好）：导入解析按 provider 选 parser + `DifyMuseAiImportLlmParser` + 摘 New-API 配置（本步是 New-API 退出完成门）。
-- **S9 待做**（前置 S6+S8）：docker-compose.solo.yml + 无 Nacos 干净启动 + 全程真后端真库真 Dify 黄金旅程 + review v0.2 §9 七条判据留证。
-- **主会话欠的 live 冒烟**：M1（New-API 真生成经护栏+chunk 携全文+决定后 purge+重连回取整链，避免造新 P1r 克隆、走现有 harness）；M3（Dify 生成 happy-path，待 app 模型修好）。
+- **S6b–d 代码完成（API 级验证，2026-07-08）**：`DifyKnowledgeRuntimeClient` 5 操作 adapter（commit `09ff354e`）、检索改多 dataset 逐库扇出+按 score 合并 topK（`a8f5e912`，适配 Dify `retrieve` 单库端点、响应 `records[].segment.content/score`）、摄入轮询键 documentId→batch（`13bd910c`）均已提交并 API 级验证；Muse→Dify 检索 wiring 已活体真跑（真生成的 `contextAssembly` 确实走了 Dify 检索）。**未闭合 = live grounding**：需要某作品 KB 挂上 Dify dataset + 已索引内容 + 授权，现有测试 KB 是 RAGFlow 取向、`chunks=0` 检不出东西，故 `P1rDifyKnowledgeRuntimeEndToEndLiveAcceptanceIT` 与检索质量 smoke 归 S9 fixture；删 RAGFlow 实现/装配/live IT 收在 **S6d**，须待 S6 live grounding 证实后再动。
+- **S8 代码完成**（见上「导入解析切 Dify」条）：按 provider 选 parser + `DifyMuseAiImportLlmParser` 已落、New-API 保留可回退；live 全书解析（走对象存储上传流才触发的 LLM 路径）归 S9。
+- **S9 待做**（S6/S8 代码已就位，差 Dify grounding 与上传 live fixture）：docker-compose.solo.yml + 无 Nacos 干净启动 + 全程真后端真库真 Dify 黄金旅程 + review v0.2 §9 七条判据留证。
+- **主会话欠的 live 冒烟**：M1（New-API 真生成经护栏+chunk 携全文+决定后 purge+重连回取整链，避免造新 P1r 克隆、走现有 harness）仍欠；**M3（Dify 生成 happy-path）已于本轮打通**（见上「M3 达成」条）。
 
 **E1 content 创作闭环切片(2026-06-27)**:已补 AI suggestion 采纳归档、前端“改后合并”入口、IndexedDB 草稿键对账、旧知识草稿失效、工作台知识/导入/导出/记录入口、Block 版本历史最小 API/UI。Content merge 写 Canonical 与来源归因后，必须由 AI owner 写 `accepted` 状态、accepted decision archive、AI command、business audit；AI owner 不可用时整笔 merge 回滚，避免 Canonical 已写但候选仍 pending。Content 正文变更后通过 Knowledge owner API 将关联 pending draft 标为 `conflicted/needs_recheck` 并写 Knowledge draft decision archive；通知失败不回滚 Canonical 主写，Knowledge confirm 端仍按来源状态 fail-closed。Studio `CandidatePanel` 支持编辑最终正文并按 `accept_as_is`/`modify_then_merge` 提交，IndexedDB 草稿键改为 `workId+blockId+revision` 防跨作品/版本污染。`saveBlock`/`mergeBlockSuggestion` 现在写 `muse_content_block_revision_snapshot`，工作台“历史”Tab 只读展示 Canonical revision 快照；导入可创建真实任务，导出支持范围/格式选择、任务查询与下载凭证消费，知识/记录入口跳转对应工作台。fresh 证据:后端局部单测 `ContentSourceServiceTest` 25/0F/0E、`ContentAppServiceTest` 19/0F/0E、`MuseKnowledgeDraftInvalidationServiceTest` 3/0F/0E、`AiSuggestionMergeProjectionFacadeTest` 7/0F/0E；契约/覆盖门 `ContractFirstGateTest` 4/0F/0E + `P1rApiCoverageReportTest` 8/0F/0E；real-PG `P1rContentCoreCompletedApprovalIT` 13/0F/0E/0S + `P1rContentMergeSuggestionIT` 5/0F/0E/0S + `P1rContentMergeGeneratedSuggestionIT` 1/0F/0E/0S；studio `tsc -b --force` 通过、lint 0 errors、Vitest 12/12，追加 `AIPanel.contract.test.tsx` + `sse.test.ts` 22/0F/0E；导出 UI 追加 `useWorks.test.tsx`+`ExportWorkModal.test.tsx` 11/0F/0E、目标 ESLint 0 errors。共享 PG 写入闸门批准后已补跑 MSW-off Playwright 真后端 `accept-suggestion.spec.ts` 2/0F/0E:正路真 New-API 生成 suggestionId=79、authz `rpe-local-*`、Block revision 160→161、AI owner accepted decision archive 非空；负路 stale revision 业务冲突。边界:`muse-studio/src/types/content.ts` 生成类型因 openapi-typescript 版本漂移未同步，hook 内暂维护 `BlockRevision` 最小类型；完整导入向导已在 RC 后补，见下方记录；真后端导出下载 e2e 已在 2026-06-28 补跑通过，FileApi 异常仍按后端合同 fail-closed。