TASK.md

AI 长篇成书当前执行计划（小白用户导向）

更新时间：2026-04-26 适用范围：当前 AI-Novel-Writing-Assistant2 代码库现状
目标用户：完全不懂写作、希望通过 AI 引导或全自动规划完成整本小说创作的用户
当前定位：强辅助型 AI 小说工作台
目标定位：可稳定带小白完成整本中长篇小说的 AI 导演系统

P2-A-1 Desktop 实施清单（浏览器主体 + desktop 宿主层）

详细方案见：

• docs/plans/desktop-plan.md

当前执行原则：

• 浏览器端继续作为产品主体，桌面版只新增分发入口。
• desktop/ 只承担宿主职责，不重写 client / server / shared 核心业务。
• 业务继续走统一 HTTP API，不把现有主链改造成 Electron-only IPC。
• 桌面化不得反向打断当前 P0 主链稳定性验收。

当前阶段拆分：

1. Phase 0: desktop-ready core
2. Phase 1: desktop shell dev
3. Phase 2: first package MVP
4. Phase 3: hardening

当前进度同步：

• Phase 0 已基本完成：前端运行时已支持 web | desktop 来源切换，桌面模式下 API 基址可由宿主注入；数据库、日志、生成图片等核心路径已开始按应用目录抽象，不再只绑定 repo 相对路径。
• Phase 1 已跑通开发闭环：desktop/ 宿主骨架已落地 main.ts / preload.ts / runtime/server.ts / runtime/paths.ts，pnpm dev:desktop 已可拉起 shared、server、client 与 Electron 桌面壳，并已在本机成功显示桌面窗口。
• 桌面开发环境的原生依赖补齐链已收口：better-sqlite3 缺失绑定时可在开发准备阶段自动修复，electron 已纳入 pnpm.onlyBuiltDependencies，避免再次出现半安装状态。
• 当前尚未进入可分发打包阶段：Windows 安装包、前端构建产物随包集成、打包态 server 入口、首启向导与桌面端模型配置仍未完成，因此 Phase 2 继续保持未开始验收。

当前阻塞与未完成：

• P2-A-1f 首启向导 MVP 尚未开始，桌面版仍依赖开发环境下已有配置，未形成“安装后图形化配置模型”的新手路径。
• P2-A-1g Windows 首个安装包尚未开始，仓库当前也没有正式的 Electron 打包器配置与产物校验链。
• 打包态资源组织仍未收口：前端 client/dist 与服务端启动入口目前仍偏向 workspace / 源码运行方式，尚未转为随桌面包分发的独立运行模型。

当前 backlog：

• P2-A-1a 运行时配置抽象：已完成首轮落地；后续只补桌面打包态的配置注入与校验。
• P2-A-1b 数据目录抽象：已完成首轮落地；后续补齐打包态全路径验证与更多桌面专属目录能力。
• P2-A-1c server 生命周期抽象：已完成开发态启动 / 探活 / 停止主链；后续补齐打包态入口与失败诊断。
• P2-A-1d 新增 desktop/ 宿主骨架：已完成最小骨架与运行时路径层。
• P2-A-1e 桌面开发命令：已完成，pnpm dev:desktop 可用。
• P2-A-1f 首启向导 MVP：只暴露模型提供商选择、API Key 输入、基础模型选择和默认资源补齐。
• P2-A-1g Windows 首个安装包：完成可安装、可启动、可开书的最小桌面版，不把 RAG / Qdrant 作为首发阻塞项。

当前验收标准：

• 非开发用户无需安装 Node、pnpm、Prisma 即可启动桌面版。
• 用户首次打开后，可在 3-5 分钟内完成配置并开始第一本书。
• 主流程可跑通 安装 -> 首启向导 -> 默认资源补齐 -> AI 自动导演开书。
• Web / 源码运行路径继续可用，桌面化不破坏浏览器主体。

当前明确不做：

• 不为桌面版重写核心业务逻辑。
• 不把现有 API 改造成 Electron-only IPC。
• 不把 Qdrant、Embedding、知识库索引抬成桌面版一期硬依赖。
• 不把桌面化误解成“打包开发脚本后继续让用户自己配环境”。

---

1. 当前判断

当前系统已经完成了两轮底座整合，不再处于“缺功能”的阶段，而处于“缺默认长链路稳定闭环”的阶段。

已经具备的关键能力包括：

• 小说项目、章节、角色、世界观、知识库、拆书等基础资产
• 书级 framing、故事宏观规划 / 约束引擎、动态角色系统
• 卷战略、卷骨架、卷内节奏板、当前卷拆章、章节细化
• 统一 Prompt Registry、统一章节写作上下文、Planner、Runtime、审阅、修复
• 状态快照、开放冲突、审计问题、重规划、任务中心、Creative Hub、模型路由
• 伏笔 / 回收底座已经从散落字段推进到持久化账本阶段：卷级 openPayoffs、章节 payoffRefs、状态层 foreshadowStates、基础冲突检测与新的 PayoffLedgerItem 账本开始进入同一条消费链

当前最重要的问题已经不是“还能再补什么写作按钮”，而是：

• 默认链路是否真的能稳定跑通
• 已落地资产是否真的被后续消费
• 状态、审计、重规划是否真的形成闭环
• 新项目和旧项目是否都能稳定完成同一条整书推进链

本轮同步结论：

• 任务状态可解释性的基础合同已进入主链：displayStatus / blockingReason / resumeAction / lastHealthyStage 已接入自动导演任务摘要、任务中心、首页与小说列表，后续重点转为补齐 pendingReviewCount / nextAction 这类更细粒度状态
• auto_to_ready 单检查点语义已基本成立，且当前系统已超出旧方案进入 auto_to_execution；不再把“只跑到 front10_ready”本身当作新的主待办
• 当前最值得优先推进的稳定性收口集中在：章节细化可用性门禁、轻量 taskSheet 执行摘要与非阻塞 artifactHealth、阶段级模型路由与 fallback、默认 patch_first 修复，以及 统一状态源 + 状态驱动生成 + 手动/导演共线 向书级前半段和真实数据链路继续收口

当前唯一主线仍然是 P0：

让一个完全不会写作的用户，输入一句模糊灵感后，系统可以在低认知负担下持续推进整本小说，而不是只会局部生成单章。

---

2. 已归档完成项

以下模块已完成主建设，后续只做局部补强，不再作为当前主视野待办展开：

• P0-0a 基本信息 / 世界切片 / 写法确认升级
• P0-0b 角色准备升级为动态角色系统
• P0-0c 故事主线升级为卷级工作台
• P0-0d 结构化大纲升级为卷纲 / 章纲联动工作台
• P0-2 统一整本生成主链

最近一轮已可归档的落地成果：

• 卷级版本、diff、impact、sync、旧数据迁移的服务端合同与路由回归已补齐
• 章节规划默认结构源已切到 书级 framing + story macro + current volume window + 卷级工作台
• 旧 outline / structuredOutline 已降级为兼容性迁移参考，不再是默认主结构源
• runtime package 与统一章节 contextPackage 已接入 planner / runtime / review / audit / repair 主入口
• 动态角色系统已进入 planner 结构化上下文，不再只停留在 digest / package 展示层
• 自动导演工作流已补上服务重启恢复链，并已超出原 v1 计划落到 auto_to_execution 与现有项目接管
• 统一状态主干的章节后半段已落地：CanonicalStateService / StateCommitService / GenerationDecisionEngine / NovelProductionOrchestrator 已接入 chapter_preparation / chapter_execution / quality_repair
• 任务状态可解释性已接入任务中心、首页、小说列表与恢复弹窗，不再只停留在后台状态字段
• 当前卷章节标题/摘要已改为按 beat 分块生成，并支持 single_beat 局部重生与章节 beatKey 绑定
• 章节正文默认主链已回退为整章一次性生成；场景字数提示和多轮审校重试止损已同步收口

归档规则：

• 已完成模块只保留“状态结论”和“影响范围”
• 旧版细节说明统一通过 Git 历史追溯
• 当前正文不再为已完成模块保留大段设计展开

---

3. P0 唯一主线

P0 的目标不变：

把系统重心从“文本生产”转向“长篇叙事控制”，优先保证整本成书率，而不是局部功能密度。

P0 的默认主链统一为：

1. 书级 framing
2. 故事宏观规划 / 约束引擎
3. 动态角色系统
4. 卷战略建议
5. 卷战略 critique
6. 卷骨架
7. 卷内节奏板
8. 当前卷章节列表
9. 章节细化 bundle
10. 章节执行 / runtime
11. state sync
12. narrative audit / replan

如果后续新增能力无法自然接入这条主链，就不应挤进当前 P0。

当前工程约束同步如下：

• AI-first：意图识别、任务分类、规划、路由、结构判断等产品核心行为，优先通过 AI 结构化输出实现，不能靠关键词表、硬编码规则或伪 AI fallback 兜底
• 新手优先：优先降低认知负担、减少前置决策、提供默认推荐，目标是让用户完成整本书，而不是让用户手动修补流程
• Prompt 治理：新增产品级 prompt 只能进入 server/src/prompting/，并按 PromptAsset 与 registry 治理，不在业务服务中继续内联扩写

---

4. 当前活跃计划（P0）

当前未完成待做清单（按优先级）

• P0-E1 / P0-A：在真实 Prisma 链路完成 migration -> 章节写入 -> 候选变更 -> 状态版本 抽样回归，覆盖旧项目、批量执行、自动导演恢复链
• P0-E1：继续把 story_macro / book_contract / character_prep / volume_planning / takeover_start 收口到 NovelProductionOrchestrator
• P0-E1 / P0-E：把 PlannerService.replan 的窗口决策、触发理由、章节选择正式切到 canonical/state-driven 主判断
• P0-B：为 purpose / boundary / taskSheet 增加 schema + 语义可用性双门禁，拦截坏细化产物进入同步和执行链
• P0-B：把 taskSheet 收口为轻量执行摘要，并补 artifactHealth / artifactHealthSummary 诊断合同，但保持非阻塞
• P0-B：补章节 repair 的 patch_first 默认策略，并把动态角色系统继续推进到执行期角色筛选、修复边界与 replan 判断
• P0-B：把模型路由从 planner / writer / review / repair 粗粒度推进到小说生产阶段级路由与 fallback
• P0-C / P0-D：继续把 critique / rebalance / uncertainty / canonical payoff ledger 接成卷级工作台默认消费链，并让卷级账本视图成为主视图
• P0-F：把首页、创建页、空状态统一收敛为“AI 自动导演推荐入口 + 手动高级入口”，并在关键节点只保留一个推荐下一步
• P0-G：为拆书任务补齐 scope / pause / resume / coverage 合同，形成“前 N 片段试跑 -> 扩范围继续”的渐进式流程
• task-3b8c9c2f4a：落实 LLM JSON 修复链路优化，包括预修复、错误分类、失败提示与定向回归测试

P0-A 真实 Prisma 数据端到端验收（暂缓单列）

当前判断：

• 这项仍然重要，但当前很难脱离仍在变化的主链单独成立为一个独立里程碑
• 现阶段先不再把它当作当前第一优先级，也不再要求单独抽一轮完整专项验收
• 后续改为跟随 P0-B / P0-F / P0-1 的阶段性交付做穿插抽查，等默认主链进一步收口后再恢复集中验收

当前重点：

• 保留高风险链路的最小烟测，而不是追求一轮完整大验收
• 新旧项目迁移、自动导演交接、章节执行链在每轮关键交付后做抽样回归
• 重点防止“产品已经往前推进，但真实数据链路长期无人回看”的情况

最小抽查链：

• 旧项目迁移 -> 卷级编辑 -> 同步章节 -> 章节规划 -> runtime

恢复为独立验收项的条件：

• P0-B 的资产消费与默认数据流进一步收口
• P0-1 的自动导演与章节执行交接闭环更稳定
• P0-F 的新手开书主链不再频繁改入口与前置资产形态

P0-B 已落地资产的更深消费

当前状态：

• 已从“统一接线”进入“开始落地消费与收口”的阶段

已落地进展：

• 系统内置资源 bootstrap 已落地，题材基底、推进模式、写法模板和反 AI 规则开始统一成默认创作底座
• 创建页与自动导演入口已接入 AI 资源推荐链，题材基底、主推进模式和副推进模式开始进入同一条创建与导演链路
• 自动导演创建 / 接管弹窗已改为展示可读名称而不是内部 ID，减少用户理解成本，也减少资产消费层与界面层之间的断裂
• 写法引擎已经从“空库 + 平铺表单”开始收口为“预置 starter + 模板起步 + 一句话 AI 生成”的新手路径
• planner / replan 已开始消费同一批前置资产，题材基底、书级 framing 与写法引擎约束不再只停留在创建期，而是进入全书规划、阶段规划、章节规划和重规划上下文
• 自动导演在 chapter_batch_ready 之后已开始消费同一批结构化资产与剩余章节状态，暂停恢复、失败重试与质量修复后恢复不再只靠“重跑一遍”的粗粒度逻辑
• 已用真实数据库副本完成一轮旧项目接管回归，确认自动导演在 chapter_batch_ready 之后可以按剩余章节数恢复，并在全部章节修复后自动收口为 workflow_completed
• 持久化 PayoffLedgerItem 已落地，major_payoffs / openPayoffs / payoffRefs / foreshadowStates / openConflicts 开始通过 AI 结构化对账进入统一伏笔账本，而不是继续只散落在卷字段、章节字段和状态快照里
• payoffLedgerSyncPrompt + PayoffLedgerSyncService 已接入卷工作台写入、状态快照落库、章节审计完成后三个同步触发点，旧账本项会保留历史并标记 stale，而不是静默删除
• chapter runtime、review、repair、planner / replan 已开始消费统一账本视角，能够显式读到 待兑现 / 紧急 / 逾期 / 已兑现，并把 payoff 专项风险进一步推进到 OpenConflict、runtime package 和 replanRecommendation
• 卷战略中的“伏笔回收概览”已开始复用 canonical 账本摘要与主列表，同时保留原始 openPayoffs / payoffRefs / foreshadowStates 作为来源参考视图
• 已完成针对 payoff ledger 共享逻辑、章节写审修上下文与章节规划上下文的回归测试，并通过 server/client build 验证

当前剩余问题：

• 虽然 runtime / review / repair / planner / replan 已开始接入统一账本视角，但真实 Prisma 迁移链路下围绕 payoff ledger 的持续抽样回归仍不够，当前主要完成了构建验证和 targeted test
• 真实 Prisma 链路、新旧项目迁移链路、自动导演交接链路里，planner / runtime / review / repair / replan 的一致性仍缺持续抽样回归；当前只补齐了自动导演后半段的一轮真实验证，以及 payoff ledger 的服务级 / 上下文级测试
• 章节细化虽然已有结构校验与字段别名兼容，但 purpose / taskSheet 仍偏“非空即过”，坏文本和低可用产物仍可能进入同步与后续消费
• taskSheet 仍是单文本字段，当前更适合继续收口为“轻量执行摘要”而不是重型分段合同；artifactHealth 也更适合作为诊断与提醒，而不是新的正文生成阻塞点
• 模型路由仍以 planner / writer / review / repair 为粗粒度，尚未升级到小说生产阶段级主路由与 fallback 链
• 章节 repair 已共用统一上下文，但默认仍缺 patch_first 策略与“局部修补优先、整章重写升级触发”的明确合同
• 动态角色系统虽然已进入 planner，但在执行期角色筛选、repair 边界、缺席风险提示和 replan 判断中的行为驱动仍不够深
• 批量执行、异常恢复、旧资产兼容路径下，书级 / 卷级 / 角色 / payoff ledger 资产仍可能出现残余分叉
• 章节正文默认已经回退为整章一次性生成；sceneCards 与执行合同刷新不再适合作为正文热路径的默认硬依赖，但仍可保留为细化、诊断、局部修复和可解释性辅助资产

当前重点：

• 把已经进入创建页、自动导演入口、planner / replan 和写法引擎入口的默认资产，继续往 chapter runtime、review、repair、audit 与自动导演恢复链深消费
• 收掉手动创建、自动导演创建、现有项目接管三条入口在资产消费上的剩余差异
• 继续减少 planner、runtime、审阅、repair、replan 在特殊入口和异常分支下的残余分叉，重点盯旧项目、批量执行、chapter_batch_ready 之后的继续执行 / 失败重试 / 质量修复恢复
• 为 purpose / boundary / taskSheet 增加 schema + 语义可用性双门禁，优先拦截纯数字、标题回显、缺少推进目标、缺少结尾要求等坏细化产物
• 把 taskSheet 收口为“轻量执行摘要”，优先稳定 推进目标 / 必保事项 / 结尾要求 / 风险提示 这类高价值字段；sceneCards 退回辅助资产，不再把分段合同刷新与按场景正文生成放进默认热路径
• 给章节细化补 artifactHealth / artifactHealthSummary，但默认只用于诊断、提醒与任务可解释性，不把它抬成新的正文生成阻塞链；front10_ready 继续以“细化可用且健康基本通过”为目标，而不是追求重型合同完备
• 将模型路由从粗粒度任务类型推进到小说阶段级路由与 fallback，优先覆盖 chapter_purpose / chapter_boundary / chapter_task_sheet / chapter_write / chapter_review / chapter_patch
• 把章节 repair 的默认策略收口为 patch_first，只在跨段大面积损坏或用户明确要求时升级为整章重写
• 为自动导演和任务中心补齐 displayStatus / blockingReason / resumeAction / lastHealthyStage 这类可解释状态合同，减少“看得到进度但不知道为什么停”的黑盒感
• 让动态角色系统进一步进入执行期行为判断，尤其是参与角色筛选、结构 obligations、修复边界和后续 replan 决策
• 把卷级工作台、章节细化 bundle、动态角色系统和新的 payoff ledger 继续压成同一套默认数据流，收掉剩余断点

完成标志：

• 规划、审阅、修复、重规划、运行时上下文在真实链路中稳定共享同一套书级 / 卷级 / 角色资产，而不再只是在服务代码层接通
• 手动审阅、runtime 审计、repair、replan 对同一章的判断依据在新旧项目与自动导演交接链路中保持一致
• 坏章节细化产物不会再误入章节同步、front10_ready 或后续章节执行
• 任务中心、任务详情和编辑页能明确展示“为什么停、如何继续、上一个健康阶段在哪里”
• 模型命中与 fallback 结果对排查可见，不再只能看到泛化的 planner / writer / review / repair
• 动态角色系统稳定进入后续规划与执行判断，而不再主要靠 digest、角色页和 package 展示承担存在感
• 卷级主线、卷纲 / 章纲联动、动态角色系统与 payoff ledger 形成同一套默认数据流

P0-C P0-0e 卷战略与节奏工作台二期收尾

当前重点：

• 把已落地的 卷战略建议 -> 卷骨架 -> 卷内节奏板 -> 当前卷拆章 继续做实
• 明确前 2-3 卷默认硬规划、后续卷默认软规划
• 把 hard / soft planning、uncertainty、critique -> rebalance -> 后续消费 真正接成默认链路
• 保持“没有节奏板就不直接拆章”的强约束

完成标志：

• 卷级工作台不再只是“全书卷骨架生成器”，而是真正承担整书连载节奏控制
• critique / rebalance / uncertainty 不再只生成文档，而会显式驱动后续决策、UI 提示和运行时消费
• 单卷重生、相邻卷再平衡、章节同步三者形成联动验收链

P0-D 结构化规划资产前移

当前重点：

• 把 圣经 / 拍点 从后置质检区前移为结构化规划资产
• 并入卷级工作台旁边统一维护，而不是继续散落在旧兼容字段和后置工具中
• 补齐按整卷生成、重排、同步的批处理能力
• 继续把已落地的 PayoffLedgerItem 与 AI 对账链往卷级工作台主视图深化，而不是只在服务层和基础卡片里存在
• 在卷级工作台把 canonical 账本视图继续收口为默认主视图，优先展示 待兑现 / 紧急 / 逾期 / 已兑现 / 失效，让新手不用手动翻章节
• 伏笔节点和回收节点优先由 AI 结构化提取、归并和去重，人工只做确认和少量修正，不把维护成本转嫁给用户

完成标志：

• 用户在章节生成前就能看清卷级承诺、拍点、圣经与兑现缺口
• 圣经 / 拍点 不再主要是后置检查材料，而成为前置规划资产
• 新链路默认优先消费卷级资产，旧 outline / structuredOutline / StoryPlan 只保留兼容作用
• 同一条伏笔不再散落在不同字段里重复维护，系统能把卷级承诺、章节兑现关联和状态快照归到同一条可编辑资产上
• 当前卷章节细化时，系统能显式带出“本章必须触碰或兑现的事项”，而不是只给原始文本让用户自己比对
• 小白用户不需要翻历史章节手动排查未回收铺垫，就能看懂当前结构承诺和待处理回收点

P0-E 状态、审计、Replan 默认闭环

当前重点：

• 把 P0-4 强记忆底座 v1 与 P0-5 叙事审计闭环 v1 从“有底座和局部接线”推进到“默认闭环”
• 让 StoryStateSnapshot、OpenConflict、AuditIssue、replanRecommendation 共同驱动续章生成
• 补齐多章趋势验证，避免系统只会记录问题，不会主动纠偏
• 让 foreshadowStates、openPayoffs / payoffRefs 与新的 payoff ledger 在 runtime、审阅、repair、audit、replan 中共享同一套判断，能识别 已铺未收 / 无铺硬收 / 回收延迟 / 状态倒退
• 在续章前默认给出“当前最该回收的事项、可以继续压后的理由、继续拖延的风险”，而不是只沉淀原始状态

完成标志：

• 状态变化会稳定影响审计判断、规划调整和下章执行
• 系统可以在偏航场景下自动给出可执行的后续窗口重规划
• 长篇连续写作的纠偏从“人工兜底”转为“系统闭环”
• 系统会主动标出当前最该回收的事项、已超期未回收事项和疑似误回收事项，而不是只在底层状态中被动记录
• 审计和 replan 能对伏笔 / 回收给出可执行建议，例如 前移 / 后移 / 拆分 / 合并 / 作废，而不只是指出“有问题”；当前已开始支持 payoff 专项问题码与 blockingLedgerKeys

P0-E1 统一状态源、状态驱动生成与手动/导演共线

需求背景：

• 当前系统已经不是单 prompt 写作工具，而是 书级 framing -> story macro -> character -> volume -> chapter mission -> writer -> audit -> replan 的多层系统
• 当前最危险的问题不是单次生成差，而是同一本书在不同模块眼里已经不是同一本书：角色、世界、冲突、伏笔、已公开信息、当前任务目标会发生状态分叉
• 自动导演与手动主链当前仍有残余分叉，尤其体现在前半段资产模型、知识消费方式、状态理解和章节执行前置依据上
• 因此需要同时推进三件事：
  • 建立统一状态源，避免 planner / writer / audit / repair 各自维护一份“事实”
  • 把章节推进改成状态驱动，而不是简单堆资料驱动
  • 把手动起步、自动导演起步、现有项目接管收口到同一主生产线

统一方案：

• 保留 手动起步、自动导演起步、接管现有项目 三种入口，但三者都收口到同一条 NovelProductionOrchestrator
• 不做一个新的“大 JSON 真源”，继续复用现有正式资产表作为分域真源，在其上建立统一读取层与受控写回层
• 统一状态主干至少覆盖五层：
  • Book Contract State
  • World State
  • Character Runtime State
  • Narrative State
  • Timeline / Event State
• 所有长期有效的新事实一律走同一条链：
  • 章节/阶段执行 -> 提取候选变更 -> 校验 -> 保守提交 -> 记录版本 -> 刷新下游上下文
• 章节生成改成三层状态驱动：
  • 任务状态驱动：先判断当前正确动作是写、修、重规划还是等待审核
  • 上下文状态驱动：只给当前任务必要的局部状态
  • 输出目标状态驱动：每次生成前先声明这一步应该推动哪些状态变化

本轮实施计划：

• P0：先落地状态主干，不推翻旧表结构
  • 新增 CanonicalStateService、StateCommitService、StateVersionLog
  • 章节完成后接入 ChapterFactExtractor -> StateCommitService
  • runtime / review / repair 开始共享 canonicalState
• P1：把章节主链改成状态驱动
  • 落 GenerationDecisionEngine
  • 让 chapter mission / writer / audit / repair / replan 共享 StateGoal / ChapterStateGoal
• P2：收口手动 / 导演 / 接管三条入口
  • 新增 NovelProductionOrchestrator
  • 让三种入口只在 controlPolicy 上不同，不再各跑一套主链
• P3：收口前端解释性
  • 明确展示 当前阶段 / 当前状态 / 当前下一动作 / 为什么停

已归档进展：

• 统一状态合同、状态持久化模型、CanonicalStateService / ChapterFactExtractor / StateCommitService / StateVersionLog 已落地
• 章节后台同步、runtime 上下文、planner 上下文已经开始优先消费 canonical state
• GenerationDecisionEngine / ContextAssemblyService / NovelProductionOrchestrator 已把章节后半段主链接入最小状态驱动闭环
• 手动单章生成、批量章节执行、手动章节规划、手动重规划已经开始通过统一编排器共线
• 定向 build / prisma generate / server 测试已覆盖最小状态驱动闭环；更细的真实链路验证转入下面的未完成项继续推进

当前未完成：

• 真实数据库尚未正式执行这轮 migration；当前只完成了 schema、migration 文件与 prisma generate
• NovelProductionOrchestrator 目前已接通 chapter_preparation / chapter_execution / quality_repair，但书级前半段阶段（story_macro / book_contract / character_prep / volume_planning）和接管入口还没有正式并线
• GenerationDecisionEngine、ContextAssemblyService 已落地，且 chapter mission / writer / audit / repair 已开始消费 ChapterStateGoal，但 replan 和更前面的规划阶段还没有全量切过去
• replanNovel 虽然已走统一编排器入口，且内部会复用新的 generateChapterPlan，但 PlannerService.replan 的窗口决策、触发理由整形、章节选择策略仍未完全改成 canonical/state-driven 主判断
• StateCommitService 当前采取保守提交：
  • 低风险的 character_state_update / event_record / payoff_progression / conflict_update 已能提交与版本落账
  • relation_state_update / information_disclosure / world_rule_change / book_contract_change 仍停留在 pending_review
• 自动导演前半段还没有完全复用 canonical state 与同一组参考知识消费链，导演链与手动主链仍有剩余分叉
• 前端还没有把 当前阶段 / 当前状态 / 当前下一动作 / pending_review 显式展示出来

下一步重点：

• 优先做真实 Prisma 链路抽样回归，确认 migration -> 章节写入 -> 候选变更 -> 状态版本 在旧项目、批量执行、自动导演恢复链上稳定
• 继续把 PlannerService.replan 的窗口决策与触发理由正式接到 ContextAssemblyService / CanonicalStateService / ChapterStateGoal，让“为什么要重规划、该改哪几章”也走统一状态判断
• 继续把书级阶段与入口收口到 NovelProductionOrchestrator：
  • 先收 story_macro / book_contract
  • 再收 character_prep / volume_planning
  • 最后处理 takeover_start
• 让自动导演前半段开始复用 canonical state 与统一参考知识消费，先收掉“导演规划依据”和“手动规划依据”的分叉
• 在任务中心与编辑页补 displayStatus / blockingReason / resumeAction / lastHealthyStage / pendingReviewCount

完成标志：

• planner / writer / audit / repair / replan 对同一章读取到同一份正式状态，不再各自拼一套事实
• 章节里出现长期有效新事实后，系统能稳定区分：
  • 可以自动提交的正式变化
  • 需要人工/审校确认的高风险变化
  • 明确拒绝写回的脏状态
• “写下一章”前，系统能先判断应该 write / repair / replan / hold_for_review，而不是无条件直接写
• 手动起步、自动导演起步、接管现有项目三条入口进入章节执行时共享同一套状态与上下文依据
• 用户能在界面上看懂当前为什么停、现在依据什么状态、继续后会推进什么

P0-F 新用户首启与快速开书入口收敛

当前状态：

• 已进入落地收口阶段，不再只是停留在产品讨论

已落地进展：

• 首页、小说列表和空状态已把 AI 自动导演 前置为新手推荐入口，并保留手动创建路径
• 创建页与自动导演首轮已经可以直接消费 AI 推荐的题材基底和推进模式组合，而不是完全从空表单开始
• 首次运行默认资源补齐机制已落地，题材基底、推进模式、写法模板、反 AI 规则不再要求用户先手动准备
• 写法引擎的新建流程已改成弹窗式起步，并支持预置 starter、模板起步和一句话 AI 生成
• 小说编辑页的导演退出交互已开始收口，避免新手在接管态里误触后直接失去方向

当前剩余问题：

• GitHub 新访客和首次进入产品的用户，仍然不清楚“现在该点哪里开始第一本书”
• 创建页仍然更像“项目配置表单”，而不是“AI 带我开书”的起步流程
• 新手在真正得到第一版可用方案前，就会先看到较多字段、模式和状态概念，认知负担偏高
• 自动导演虽然已具备受控推进能力，但入口曝光仍不足，很多用户不知道它才是更适合自己的起步方式
• 创建完成后，“下一步做什么”仍然不够单一明确，容易让新手在项目页和编辑页之间失去方向
• 题材基底库、推进模式库、写法模板虽然已经有部分 seed 或内置默认值，但仍未统一成“首次可用的默认创作底座”
• 题材基底和推进模式当前更接近 db seed 语义，写法引擎则是按服务懒加载补齐，用户视角下的首次体验仍不一致
• 新手仍可能在“资源库为空 / 不知道要不要先建资源 / 不理解这些库怎么选”之间卡住

当前重点：

• 把首页、小说列表、空状态、创建页首屏统一收敛为两条入口：
  • 我只有一个想法（推荐） -> AI 自动导演
  • 我已经准备好详细设定 -> 手动创建
• 让自动导演在产品层成为“新手推荐入口”，但不变成唯一入口；继续保留手动创建和专家路径
• 把首启开书流程压缩成低认知负担的短链路，优先做到“一句灵感 -> 方向候选 -> 选择方案 -> 继续推进”
• 让 AI 先给出书名、定位、主线冲突、前 10 章承诺等结构化初稿，用户优先做选择与确认，而不是先手填完整表单
• 在创建成功、导演审核点、章节执行前等关键节点，只保留一个最显眼的“当前推荐下一步”
• 逐步把 项目模式 / 状态字段 / 资源分数 / 高级配置 收进高级区或 AI 默认补齐，不让新手在首屏先理解系统内部概念
• 把 题材基底库 / 推进模式库 / 写法模板 / 反AI规则 定义为系统内置资源，而不是要求新手先从零建设的后台配置
• 建立首次运行幂等 bootstrap：
  • genre
  • story mode
  • style template
  • anti-AI rule 在数据库为空或缺少内置资源时自动补齐，而不是要求手动执行额外初始化命令
• 统一“默认资源已就绪”的体验，不再让题材基底、推进模式、写法模板分别走三套不同的首次填充语义
• 默认资源优先走“小而强 starter pack”，先保证新手能快速开始，再保留后台扩展与 AI 生成能力
• 让 AI 负责从默认资源中做结构化推荐与组合，用户优先看到“系统已为你推荐”，而不是先浏览资源库自己挑
• 创建页与自动导演首轮优先消费 AI 推荐结果，例如：
  • 推荐题材基底
  • 推荐主推进模式
  • 推荐副推进模式
  • 推荐默认写法模板 而不是把这些选择都前置为必填动作

完成标志：

• 新用户进入首页后，能在 5-10 秒内理解“先点 AI 自动导演开书”
• 用户可以在不理解完整小说规划术语的前提下，用极少输入启动第一本书
• 首轮开书默认由 AI 产出 方向候选 / 标题候选 / 主线钩子 / 前 10 章承诺，用户主要做确认与微调
• 创建成功后，系统始终能给出单一明确的下一步，而不是把用户直接暴露给复杂工作台
• 自动导演成为新手推荐入口，但手动创建仍保留为可见的高级路径
• 首次启动后，题材基底库、推进模式库、写法模板和反 AI 规则默认可用，不需要新手先理解后台资源管理
• 默认资源的填充机制对用户透明、对开发幂等、对后续升级可维护，不会因为重复启动或版本升级产生脏数据
• 新手在创建第一本书时，默认看到的是“AI 已推荐的资源组合”，而不是“空库 + 手动选择”
• 资源库页面从“开书前必做准备”降级为“可选查看与高级调整区”

P0-G 拆书工作台与渐进式拆书收口

当前状态：

• 已具备 知识文档 -> 分段笔记 -> section 分析 -> 证据面板 -> 发布到小说知识库 / 生成写法资产 的基本链路
• 拆书后台已经有真实的 source segment、currentStage / currentItemLabel、服务重启恢复与超时恢复，但这些能力仍主要停留在后台实现层
• 当前产品语义仍更接近“一次性整本拆书”，还不是“先试跑、再加深、可暂停继续”的新手友好流程

当前剩余问题：

• 创建入口当前只暴露 文档 / 版本 / 模型 / 是否生成时间线，没有 整本 / 前 N 片段 / 指定片段范围 这类范围控制，用户无法低成本先判断资料值不值得继续拆
• cancelled 目前同时承担“我不做了”和“我先停一下”两种含义，缺少真正的 paused -> resume 语义；想继续时只能 rebuild / retry
• 任务中心和拆书详情虽然能显示当前阶段，但仍看不到 目标范围 / 已完成范围 / 剩余范围 / 恢复起点，长任务对用户仍偏黑盒
• 一旦支持部分范围拆书，若没有明确 coverage 合同，局部结果很容易被误当成“整书结论”，并继续被发布到知识库、续写引用或写法资产
• 当前分段笔记主要作为后台缓存存在，用户还看不到“前几段值不值得继续拆、哪些片段证据最关键、当前结论覆盖到哪一段”这类中间判断
• 当前拆书更像“产出最终报告”，还缺少“快速预览 -> 决定是否扩范围 -> 再深拆”的渐进式工作流

当前重点：

• 为拆书任务补齐显式 scope 合同，优先支持 full_document / first_n_segments / segment_range，并把 scopeLabel / totalSegmentCount / completedSegmentCount / effectiveSegmentRange 变成列表、详情和任务中心都可见的统一字段
• 把拆书收口成“先快后深”的默认流程：先允许用户跑 前 N 片段 得到低成本试跑结果，再决定 继续全文 / 扩到更大范围 / 暂停稍后继续
• 增加真正的 pause / resume 语义，并要求暂停落在 片段笔记 或 section 边界；恢复时优先复用已有 notes 与已完成 section，而不是一律整单重跑
• 让任务中心、拆书详情和列表明确显示 当前跑到第几段 / 总共几段 / 当前 section / 为什么停 / 如何继续，把长耗时任务从后台状态改成用户可操作流程
• 为部分范围拆书补 coverage 与可信度语义：所有结论都要明确标注“当前仅覆盖前 N 段”或“当前覆盖第 X-Y 段”，避免局部结果伪装成整书结论
• 把分段笔记从纯缓存提升为可用中间产物，优先支持“关键片段证据”“片段热区”“适合继续深拆的 section 建议”，让“细化拆书”不只等于重写最终报告
• 让 发布到小说知识库 / 从拆书生成写法 / 续写引用 都感知拆书 coverage；局部拆书默认要么带风险提示，要么要求用户明确确认，不静默冒充完整上游资产
• 范围控制、暂停恢复与 coverage 约束都保持 deterministic；真正的结论生成、热点归纳和 section 深化仍由 AI 结构化输出负责，不为命中率添加关键词式伪 fallback

完成标志：

• 用户创建拆书时可以直接选择 整本 / 前 N 片段 / 指定片段范围，且列表、详情、任务中心显示一致
• 用户可以把拆书任务暂停后继续，并从最近已完成的 片段笔记 / section 边界恢复，不需要整单重来
• 前 N 片段试跑 -> 扩大全文继续 能复用同一批 notes / cache / 进度信息，而不是重复花费一遍
• 局部拆书结果在详情、导出、发布、写法资产和续写引用里都带明确 coverage 标识，不再被误读为整书分析
• 用户除了最终 section 报告，还能看懂当前拆书覆盖了哪里、关键证据来自哪些片段、接下来最值得继续拆什么
• 拆书长任务从“只能取消或重跑”升级为“可试跑、可暂停、可恢复、可扩范围”的渐进式流程

---

5. 当前执行顺序与里程碑

第一阶段：先收口已经开始落地的资产消费与新手主链

• P0-B 已落地资产的更深消费
• 章节细化可用性门禁 / 轻量 taskSheet / 非阻塞 artifactHealth
• 阶段级模型路由与 fallback
• P0-F 新用户首启与快速开书入口收敛
• P0-G 拆书工作台与渐进式拆书收口
• P0-1 自动导演模式受控推进与状态可解释性补强
• 每轮关键交付后穿插最小真实数据烟测，不再把 P0-A 单独拆成独立先行阶段

完成标志：

• 创建、自动导演、接管、章节规划与章节执行开始更稳定地消费同一批默认资产
• 坏章节细化产物不会误进 front10_ready、章节同步或后续章节执行
• 新手用户在首页到创建页之间能明确知道“先怎么开始”
• 拆书支持 前 N 片段试跑 / 暂停后继续 / 扩范围继续，且局部结果不会被误当成整书结论
• 用户在暂停 / 失败 / 可继续三类状态下，能看懂为什么停、怎么继续
• 自动导演与章节执行交接、暂停恢复、退出导演模式等主交互继续收口，而不是入口前进、后段状态落后

并行 UX 轨道：

• 新用户首启入口收敛与自动导演推荐入口前置可以并行推进
• 但入口收敛优先解决“用户知道怎么开始”，不允许为了首屏转化新增更多复杂前置配置

受控产品化预研轨道：

• 面向非开发用户的桌面化接入可以提前做方案设计、目录预留和壳层验证
• 但不得为了桌面版提前重写当前 client / server / shared 主体，不得反向打断 P0 主链稳定性验收
• 桌面化一期默认只解决“安装即可开书”，不提前把知识库、Qdrant、复杂部署链路抬成首发硬要求

第二阶段：持续穿插真实链路抽查并做实跨入口消费

• 书级 framing
• story macro
• current volume window
• 动态角色系统
• 卷级工作台资产
• 新旧项目迁移链路与自动导演交接链路的最小真实数据抽查

完成标志：

• 这些资产在 planner、runtime、审阅、repair、replan 之间不再因入口不同继续分叉
• 不再只是“已经接线”，而是“在真实链路里稳定驱动行为”

第三阶段：收尾卷战略与节奏工作台二期

• 稳定 卷战略建议 -> critique -> 卷骨架 -> 节奏板 -> 当前卷拆章
• 把 hard / soft planning、uncertainty、rebalance 接入默认消费链

完成标志：

• 当前卷拆章前必须有 beat sheet
• 后半段卷级规划开始保留真实弹性，而不是伪硬规划
• 跨卷节奏和兑现梯度开始可见、可校验、可重平衡

第四阶段：前移结构化规划资产

• 圣经 / 拍点 进入卷级工作台主视野
• 补齐整卷生成、重排、同步能力
• 把 openPayoffs / payoffRefs / foreshadowStates 收敛为统一的 payoff ledger 与默认视图

完成标志：

• 规划资产不再散落
• 用户能在开写前看到清晰的结构承诺和兑现缺口
• 用户能在卷级工作台中直接看到 已埋设 / 待回收 / 本卷需触碰 / 已回收 / 失效 的统一列表

第五阶段：闭合状态、审计、重规划回路

• 状态对象、开放冲突、审计问题、replan 共同驱动续章
• 形成多章连续纠偏能力
• 伏笔状态、未兑现事项、章节兑现关联与 payoff ledger 共同驱动“下一章应该收什么、是否允许继续压后、偏航后如何重排”

完成标志：

• 长篇连续写作不再主要依赖人工盯盘
• 系统能更早发现偏航并推动后续修正
• 系统能主动识别 已铺未收 / 无铺硬收 / 回收延迟 / 状态倒退，并推动后续窗口重规划

并行边界：

• 允许并行：P0-B 资产消费深化、P0-F 新手入口收口、P0-1 自动导演闭环收口、P0-A 的最小真实数据抽查、圣经 / 拍点 结构化资产设计
• 不建议并行：在资产消费与新手主链未收口前再次大改首页入口；在 P0 闭环未补齐前大规模扩展更多新入口；在 P0 未稳前提前推进 P1

---

6. 当前验收标准

端到端验收

• 新项目和旧项目都能跑通 卷级规划 -> 章节同步 -> 章节规划 -> runtime
• 旧数据迁移后不会因为旧字段残留而阻断新主链
• Planner、Runtime、审阅、修复对同一批核心资产的消费结果一致

结构链验收

• 章节规划默认结构源稳定来自 书级 framing + story macro + current volume window + 卷级工作台
• 旧 outline / structuredOutline 只保留兼容性参考地位
• purpose / boundary / taskSheet 不仅结构合法，而且通过可用性门禁；坏细化产物不会误入 front10_ready
• 正文默认走整章一次性生成；sceneCards 与执行合同刷新只作为辅助资产、诊断或局部修复能力存在，不再作为默认写作前硬依赖
• 圣经 / 拍点 开始以前置规划资产而不是后置质检资产的身份参与链路
• 伏笔 / 回收不再只是散落字段，系统能通过 payoff ledger 在章节生成前清晰展示结构承诺、兑现缺口和当前卷必须处理的 payoff obligations

拆书链验收

• 用户能在同一份文档上完成 前 N 片段试跑 -> 暂停 -> 恢复 -> 扩全文，且不丢失已完成 notes / section
• 任务中心、拆书详情和列表能一致展示 目标范围 / 已完成范围 / 当前片段 / 当前 section / 可继续动作
• 暂停 与 取消 语义明确分离；暂停后恢复不依赖整单 rebuild
• 局部拆书的导出、发布、写法生成和续写引用都能显式带 coverage，不把局部结果静默当整书资产
• 分段笔记、证据面板和最终 section 报告之间能对齐，用户可以追溯“这个结论来自哪些片段”

卷级工作台验收

• 系统能明确哪些卷是 hard planned，哪些卷是 soft planned
• 每卷都有 opening hook / pressure source / selling point / payoff type / next hook 级别的追读设计
• 当前卷未生成 beat sheet 时，默认不能直接拆章节列表
• 单卷重生后，系统能给出相邻卷再平衡建议
• critique 能指出卷间重复、中段塌陷风险、卷尾钩子过弱、主角弧线断裂、后半本过度硬规划
• 当前卷工作台能默认展示本卷 未兑现事项 / 本章兑现关联 / 已回收事项 / 失效事项，且不要求用户翻历史文本手动核对

状态闭环验收

• StoryStateSnapshot、OpenConflict、AuditIssue、ReplanDecision 能稳定进入默认消费链
• 章节偏航后系统能自动给出后续窗口重规划
• 连续写作多章后，系统不会只沉淀状态而不消费状态
• 任务中心、任务详情和编辑页能一致展示“为什么停、如何继续、最后健康阶段”，而不是只给原始状态码
• 系统能稳定识别 setup -> pending_payoff -> paid_off / failed 的状态迁移，并对 已铺未收 / 无铺硬收 / 回收延迟 / 状态倒退 给出明确处理建议；当前 payoff ledger 已开始进入这条默认链

用户结果验收

写作小白输入一句题材想法后，系统应能够：

• 自动给出可继续消费的全书方案
• 连续推进前 10 章而不明显丢失主角目标、核心设定和主线冲突
• 在出现偏航时，优先由系统给出修正，而不是要求用户手动修补结构

文档与治理验收

• TASK.md 必须只保留当前活跃计划与归档摘要
• 后续 backlog 拆分必须以本文件为唯一主依据
• 新增产品级 prompt 必须继续遵守 server/src/prompting/ 治理

---

7. 受控推进项

P0-1 自动导演模式 v1

当前状态：

• 已从“受控恢复中”推进到“受控推进中”
• 当前仍不计入 P0 已完成验收
• 当前仍不作为唯一创建入口，但可以作为新手推荐入口受控前置展示
• chapter_batch_ready 之后的剩余章节对账、继续执行与质量修复后恢复已开始形成默认闭环
• 任务详情、任务中心与小说编辑页读取旧自动导演任务时，已能在读取阶段自动对账 chapter_batch_ready 检查点，避免不同入口看到不一致状态
• 已用真实数据库副本完成旧项目接管场景回归，确认“部分修复后从首个未完成章节继续”和“全部修复后自动完成”两条路径成立
• waiting_approval 在 UI 层的基础 live / checkpoint 识别已落地，不再把“暂停显示成失败”作为独立主待办

已归档结论：

• 原 v1 计划内的候选三段式交互、book framing 补齐、story macro -> book contract、角色准备、卷战略到前 10 章细化、任务恢复链与模型覆写，已不再在本节展开
• 超出原 v1 计划的 auto_to_execution 与现有项目接管也已落地，统一按“已超出原计划范围的已完成项”处理，不再在活跃计划中保留长展开
• auto_to_ready 单检查点语义已并入现行导演流，不再按独立功能待办维护
• 旧的“front10 only”边界已被 auto_to_execution 超出，不再作为当前 roadmap 的默认约束

当前剩余问题：

• 三种运行模式与现有项目接管虽然都已接上，但真实 Prisma 数据下的完整端到端稳定性仍缺持续回归
• chapter_batch_ready 之后的剩余章节对账、继续执行与修复后自动收口已完成一轮真实数据验证，但暂停恢复 / 失败重试仍需继续做穿插回归
• 自动导演产物虽然已进入章节执行，但与默认 P0 主链之间仍有残余分叉
• 当前任务摘要仍缺 displayStatus / blockingReason / resumeAction / lastHealthyStage / artifactHealthSummary 等更强可解释字段
• 当前仍没有形成跨多卷、跨长周期的完整自动推进闭环
• 在默认主链稳定前，自动导演仍不应抬为唯一创建入口，但可以承担新手推荐入口角色

当前重点：

• 继续补齐 stage_review / auto_to_ready / auto_to_execution / 现有项目接管 四类路径的真实数据端到端验收，但不再把 auto_to_ready 单检查点本身当作独立功能待办
• 把 chapter_batch_ready 之后的暂停恢复、失败重试、质量修复与继续执行继续做穿插回归，尤其补足真实 Prisma 数据与旧项目接管场景下的非理想状态
• 继续减少导演链与当前 P0 默认主链之间的分叉，确保 story macro / book contract / volume assets / chapter detail bundle 被后续默认消费
• 继续补失败恢复、重试、模型覆写和任务可观测性，避免自动导演一旦失败就变成不可维护的黑盒
• 补齐导演任务的 displayStatus / blockingReason / resumeAction / lastHealthyStage / artifactHealthSummary，让暂停、失败、自动恢复与继续执行更可解释

完成标志：

• 自动导演在真实 Prisma 数据下可稳定完成 auto_to_ready / stage_review / auto_to_execution / 现有项目接管 四类主路径
• chapter_batch_ready 之后的暂停恢复、失败重试、质量修复与继续执行形成默认闭环
• 任务中心、任务详情和编辑页对暂停 / 失败 / 自动恢复 / 可继续状态的语义一致且可操作
• 在默认主链稳定前，自动导演只作为受控并行项推进，不直接抬为唯一创建入口；但首页、列表和空状态可将其作为新手推荐入口前置

---

8. P1 / P2 摘要

P1：从“能写完整本”到“能稳定写好”

P1 重点解决：

• 角色弧光与关系演化引擎
• 节奏与篇幅控制系统
• 整本文风稳定器
• 结构化记忆升级
• 长篇质量趋势评分体系

说明：

• 写法引擎细化优化、风格检测 / 重写联动、多层写法控制，更适合放在 P1 质量深化阶段，不进入当前 P0 主线

P2：从“有引擎”到“成熟产品化”

P2 重点解决：

• 面向小白的全流程作品工厂
• 多模式创作策略
• 题材与写法模板化
• 可视化长篇控制台
• 完结前全书巡检与修复计划

P2-A 非开发用户桌面化接入（Electron 优先）

目标：

• 让不会安装 Node、pnpm、Prisma，也不理解前后端启动链路的普通创作者，可以通过桌面安装包直接进入产品
• 把当前“开发者源码运行路径”收敛为“开发模式”，同时新增“普通用户安装即用路径”
• 首先解决 安装 -> 配置 -> 开书 的基础可用性，而不是一上来追求完整部署、知识库和高级运维能力

架构原则：

• 桌面版优先采用 Electron 外壳层，而不是提前重写核心业务逻辑
• 保留现有 client / server / shared 作为核心业务主体，桌面版通过新增 desktop/ 工程接入
• 现有 pnpm dev / pnpm build、Web 运行方式、源码开发方式必须继续可用，桌面版不能反向破坏原有开发路径
• 一期不把现有 REST / HTTP 业务接口整体改造成 Electron IPC；优先保留本地 Node 服务 + 本地前端窗口的最小改造路径
• Electron 负责：
  • 窗口与应用生命周期
  • 本地配置与安全存储
  • 本地服务启动
  • 数据目录与日志目录管理
  • 安装包与自动更新
• 业务层继续通过统一服务端入口承载，避免为桌面版复制一套平行业务实现

一期范围（最小可用桌面版）：

• 新增 desktop/ 壳层工程，能启动现有前端构建产物并自动拉起本地服务
• 默认使用本地 SQLite，并把数据库、日志、设置迁移到用户应用目录，而不是项目工作区
• 首启引导改为图形化向导，优先只暴露：
  • 模型提供商选择
  • API Key 填写
  • 基础模型选择
• 默认关闭 RAG / Qdrant，不把知识库链路作为桌面版首发阻塞项
• 首次启动自动补齐系统内置资源，确保用户安装后可直接进入 AI 自动导演开书
• 桌面版用户不要求手动复制 .env、运行 Prisma 命令或理解 workspace 启动顺序

二期范围（在最小可用后追加）：

• Windows / macOS 安装包完善
• 桌面版设置页接管模型配置，而不是继续依赖 .env
• API Key 进入系统安全存储，而不是明文文件
• 自动更新、版本检查与错误日志采集
• 在不破坏首启简单性的前提下，再逐步恢复知识库 / RAG 的桌面化接入能力

明确不做：

• 不为了桌面版提前把所有 API 改成 Electron-only IPC
• 不把 Qdrant、Embedding、知识库索引作为桌面版一期的必填配置
• 不把桌面化理解成“打包当前开发脚本然后让用户自己继续配 Node”
• 不允许桌面版需求反向迫使当前 Web / 源码运行方式失效

完成标志：

• 非开发用户无需安装 Node、pnpm、Prisma，即可通过安装包启动产品
• 用户首次打开桌面版后，可以在 3-5 分钟内完成模型配置并开始第一本书
• 默认主流程能在桌面版中完成 安装 -> 首启向导 -> 默认资源补齐 -> AI 自动导演开书
• 当前 Web / 源码路径仍保持可用，桌面版只是新增分发入口而不是替代入口
• 桌面版一期上线时，即便不启用知识库，也能稳定跑通主创作链

---

9. 当前不优先做的事

以下事项当前不应抢在 P0 前：

• 在 P0 默认主链未稳前，把自动导演做成唯一创建入口并隐藏手动路径
• 复杂专家编辑器
• 低价值界面重构
• 只优化单章、不优化整本稳定性的局部体验
• 高自由度但高认知负担的专家配置项
• 与长篇主链弱相关的多入口花式生成按钮
• 没有底层结构模型支撑的炫目可视化
• 让新手在首屏先理解过多系统内部字段、状态和模式，再决定是否开书
• 把写法引擎细化优化提前抬到当前主线之前
• 为了桌面版提前把 client / server / shared 大规模改造成 Electron 专用结构
• 把 Qdrant / RAG / 向量检索链路抬成桌面版一期的首发硬要求

统一判断标准：

这个能力，能不能显著提升一个完全不会写作的人把整本小说写到完结的成功率？

如果答案不是“能明显提升”，优先级就不该高于当前 P0 主线。

---

10. 默认决策

• TASK.md 只保留“当前活跃计划 + 已归档完成项摘要”两层结构
• 已完成模块不再在正文中保留长篇设计说明
• 旧路线图、旧设计稿、旧分阶段细节统一通过 Git 历史追溯
• 当前实施者不依赖本次对话，只看本文件就应能直接拆出当前 backlog
• 后续如有新完成项，默认先归档，再更新活跃计划，不再叠加历史正文

---

P0-G Chapter Editor V2（正文中心的章节内闭环）

本轮范围：

• 仅实现 Phase 1 + Phase 2 MVP。
• 不进入 Phase 3/4，暂不做问题修复 preview、光标续写、语义 diff、局部接受。

当前状态：

• 已完成首版“正文中心的局部 AI 精修编辑器”主闭环。
• 章节编辑能力已经迁移到独立 NovelChapterEdit，工作台页 ChapterManagementTab 只保留“打开章节编辑器”入口和原章节执行逻辑。
• 后端已补齐章节编辑专用 preview contract、PromptAsset 与 route，接受候选时会先创建 novel snapshot 再落正文。

最近更新：

• 2026-04-10：完成 rewrite-preview 后端链路、共享章节编辑器壳层、Plate 正文编辑、选区浮动工具条、候选 diff 抽屉、接受前自动快照，并同步计划进度。

已完成：

• 共享编辑器壳层：新增 ChapterEditorShell，统一承接顶部轻控制条、左侧轻上下文、中央正文编辑、右侧按需 diff 面板，实际落点在独立 NovelChapterEdit。
• 双入口关系：NovelEdit -> ChapterManagementTab 继续作为工作台入口，NovelChapterEdit 作为独立正文编辑页承载本轮精修闭环。
• Plate 底座：正文编辑从旧 textarea 切到 Plate，支持正文编辑、选区监听、保存状态、字数统计。
• 选区 AI 改写闭环：首版支持 优化表达 / 扩写 / 精简 / 强化情绪 / 强化冲突 / 自定义指令 六类意图。
• 候选与 diff：新接口固定返回 2-3 个候选版本，前端支持 inline diff、候选切换、拒绝、再生成、接受。
• 安全回退：接受候选时先调用现有 createNovelSnapshot，label 采用 chapter-editor:{chapterOrder}:{operation}:{timestamp}，再调用 updateNovelChapter。
• Prompt 治理：新增 novel.chapter_editor.rewrite_candidates@v1，已注册到 server/src/prompting/registry.ts，未在 service 内内联业务 prompt。
• 验证：已通过 pnpm typecheck、pnpm --filter @ai-novel/client build、server/tests/chapterEditorPreview.test.js、server/tests/prompting-governance.test.js。

下一步：

• Phase 3：把章节问题列表升级为“定位 -> 建议 -> diff -> 接受 -> 关闭”的问题修复闭环，并补章节内版本抽屉。
• Phase 4：补光标续写、块级 diff / 语义 diff、局部接受和更细粒度回滚。
• 前端测试：当前仓库还没有独立的 client test runner，本轮先以 typecheck/build 为准；后续需要补章节编辑器交互测试基座。
• 详细方案与进度记录：docs/plans/chapter-editor-v2-plan.md、docs/checkpoints/chapter-editor-v2-progress.md

11. 最终结论

当前版本最重要的架构转向，不是继续堆叠更多写作工具，而是完成下面这条身份升级：

从：
强辅助型 AI 小说工作台

转向：
可稳定带小白完成整本中长篇小说的 AI 导演系统

TASK.md 的作用，不是记录所有历史讨论，而是约束后续每一轮研发都围绕这条主线推进。

---

Codex 开发同步（自动维护）

本区块由 $task-md-sync 自动维护，用于同步开发计划与实现进度。 使用约定：

• 已完成项以第 2 节归档摘要为准，不再把本区块里的完成任务当作当前 backlog。
• 当前直接待做事项以第 4 节“当前未完成待做清单”为准；本区块主要保留开发流水记录与仍未完成的任务条目。

节奏拆章恢复粒度收细

• 标识：task-bd8822d224
• 状态：已完成
• 最近更新：2026-04-18 09:23
• 概要：已实现 structured_outline 按卷 / beat / detail mode 的恢复游标，自动导演与手动拆章页都能从最近已完成边界继续，不再默认从 0 重跑。

计划清单：

• 抽 structured_outline 恢复游标，按卷 / beat / detail mode 判断下一步
• 让 chapter_list full_volume 支持从首个未完成 beat 继续
• 让自动导演恢复与换模型重试跳过已完成卷、已完成 beat、已完成细化项
• 让手动拆章页失败后回填已自动保存进度，并让批量细化从缺失 mode 继续
• 补后端回归测试并验证恢复链

进度记录：

• 2026-04-18 09:03 [开发中] 已进入实现，开始收细节奏拆章恢复粒度。
• 2026-04-18 09:23 [已完成] 已完成后端恢复游标、chapter_list 续跑、前端失败回填与批量细化续跑，并补齐相关测试与构建验证。

按卷节奏分块生成章节标题

• 标识：task-2f4c88b71e
• 状态：已完成
• 最近更新：2026-04-17 01:12
• 概要：将当前整卷一次性章节标题/摘要生成改为按卷节奏 beat 分块生成，并支持节奏段局部重生与章节 beatKey 显式绑定。

计划清单：

• 扩展章节列表生成合同，新增 generationMode、targetBeatKey 和章节 beatKey 显式绑定
• 重构 chapter_list 编排为按 beat 分块生成、块级校验与整卷合并
• 在节奏 / 拆章工作区增加节奏段局部重生入口，并优先按 beatKey 归组章节
• 补充服务端、prompt、前端与工作流回归测试

进度记录：

• 2026-04-16 23:55 [开发中] 已确认实现范围仅覆盖章节标题/摘要链路，准备开始落地 shared contract、server orchestrator 与工作区局部重生入口。
• 2026-04-17 01:12 [已完成] 已落地 beat-by-beat 章节块生成、single_beat 局部重生、章节 beatKey canonical 写回、前端 beat-aware 分组与局部重生按钮，并通过 pnpm --filter @ai-novel/server build、pnpm --filter @ai-novel/client build 与定向服务端测试。

章节正文恢复整章生成

• 标识：task-7c41b2e0d3
• 状态：已完成
• 最近更新：2026-04-14 23:22
• 概要：回退章节正文主链路，不再按 sceneCards 拆场景生成，也不在生成前自动刷新章节执行合同，让“重写本章”和普通正文生成统一恢复为整章一次性写作。

计划清单：

• 确认重写本章与普通生成的统一入口，定位场景驱动接入点
• 回退正文主生成到整章一次性写作，并移除生成前自动执行合同刷新
• 更新最小回归测试，确认 createChapterStream 不再触发执行合同刷新

进度记录：

• 2026-04-14 23:12 [开发中] 已确认重写本章仍走统一 /generate 入口，当前额外耗时主要来自场景驱动与生成前执行合同刷新。
• 2026-04-14 23:22 [已完成] 已回退正文主链路到整章一次性写作，并通过 @ai-novel/shared build、@ai-novel/server build 与 chapterRuntimeCoordinator.test.js 定向验证。

场景写作去字数提示

• 标识：task-4f8a2d7c11
• 状态：已完成
• 最近更新：2026-04-14 21:36
• 概要：移除场景正文写作阶段直接传给 LLM 的场景/章节字数预算提示，保留场景职责、进入/退出状态与内部流式执行机制，降低场景被统一预算话术牵引成同质节奏的风险。

计划清单：

• 梳理场景写作 prompt、场景合同块和续写摘录里的长度提示入口
• 移除场景 prompt 中的场景预算、章节预算和分轮新增/硬上限提示
• 补充回归测试，确认场景 prompt 与场景合同块不再暴露直接长度预算

进度记录：

• 2026-04-14 21:24 [开发中] 已确认场景流会把场景预算、章节预算和轮次预算同时暴露给 LLM，上下文语气容易重复。
• 2026-04-14 21:31 [开发中] 已移除场景 prompt、场景合同块和场景续写摘录中的直接长度提示，保留场景职责与轮次状态语义。
• 2026-04-14 21:36 [已完成] 已通过 @ai-novel/server build 与 prompting、sceneBudgetRuntime 定向测试。

章节审校单次修复止损

• 标识：task-1d9c5b7e21
• 状态：已完成
• 最近更新：2026-04-14 21:10
• 概要：将章节流水线的默认审校重试收敛为“初审失败后最多修一次，再复审一次，失败即停”，减少章节在审校/修复阶段反复循环。

计划清单：

• 梳理当前章节审校与修复重试链路
• 将默认重试预算从 2 调整为 1，覆盖自动导演、批量流水线和编辑页默认值
• 补充最小回归测试，确认不会进入第三轮审校

进度记录：

• 2026-04-14 21:04 [开发中] 已确认当前重复来自默认 maxRetries=2，导致“审校 -> 修复 -> 审校 -> 修复 -> 审校”。
• 2026-04-14 21:08 [开发中] 已将自动导演、章节流水线和编辑页默认重试预算统一收敛为 1。
• 2026-04-14 21:10 [已完成] 已通过 @ai-novel/server build、@ai-novel/client typecheck 与 chapterRuntimePipeline、novelDirectorAutoExecution 定向测试。

正文场景合同主链路接通

• 标识：task-6e2c3f1b9a
• 状态：开发中
• 最近更新：2026-04-14 20:34
• 概要：该任务曾尝试让正文生成主链路在写作前自动刷新章节执行合同，并优先消费 canonical sceneCards 按场景写作；后续已确认这条路径会显著拖慢正文生成，因此已被“恢复整章一次性生成”替代，不再作为当前默认主链。

计划清单：

• 检查正文生成、planner 持久化与节奏板细化链路，确认 sceneCards 在进入正文前的丢失点
• 调整 planner 持久化格式，仅在可形成 canonical 场景合同时写入 sceneCards
• 让正文生成主入口在组装上下文前自动刷新章节执行合同
• 将正文主写作链路切到已有的按场景流式生成实现，并回传章节长度控制结果
• 补充最小回归测试，覆盖 canonical sceneCards、执行合同刷新与失败降级

进度记录：

• 2026-04-14 19:58 [开发中] 已确认重复放大点不在节奏板本身，而在 planner 覆写 sceneCards 与正文主链路未接场景流。
• 2026-04-14 20:16 [开发中] 已接入执行合同预刷新与按场景写作主路径，同时把 planner 的 sceneCards 持久化改为 canonical JSON。
• 2026-04-14 20:34 [已完成] 已通过 @ai-novel/shared build、@ai-novel/server build、@ai-novel/server typecheck 与 chapterLengthControl、plannerPersistence、chapterRuntimeCoordinator 定向测试。

自动导演候选阶段恢复卡死修复

• 标识：task-8f0fdf4e01
• 状态：已完成
• 最近更新：2026-04-09 23:20
• 概要：修复自动导演候选阶段在 retry/continue 与服务重启恢复后被错误标记为 running 但未真正恢复执行的问题。

计划清单：

• 确认候选阶段任务卡死的复现链与状态修正逻辑冲突点
• 调整自动导演 continue 读取逻辑，避免被读取时修正提前改写状态
• 补最小回归验证，确认 retry/continue 与恢复链可重新拉起候选生成

进度记录：

• 2026-04-09 23:19 [开发中] 已定位到 queued 候选任务在读取时被提升为 running，导致 continue 提前返回。
• 2026-04-09 23:20 [已完成] 已定位并修复 queued 候选任务在读取时被提升为 running，导致 continue 提前返回的回归。
• 2026-04-09 23:20 [已完成] 已通过 @ai-novel/server typecheck、novelDirectorRetry.test.js、novelWorkflowRuntime.test.js。

世界观删除入口

• 标识：task-9029968563
• 状态：已完成
• 最近更新：2026-04-09 22:20
• 概要：为世界观列表页与工作台补充删除入口、确认提示、删除中状态与删除后跳转。

计划清单：

• 检查世界观现有列表页与工作台结构，确认删除接口与交互模式
• 在世界观列表页补删除按钮与删除中状态
• 在世界工作台页头补删除入口与删除后返回列表
• 完成最小回归验证并同步 TASK.md 进度

进度记录：

• 2026-04-09 22:19 [开发中] 已确认后端已有删除接口，准备补齐前端入口。
• 2026-04-09 22:20 [已完成] 已为世界观列表卡片和工作台页头补齐删除入口，删除后会刷新列表并回到世界观列表页。
• 2026-04-09 22:20 [已完成] 已通过 @ai-novel/client typecheck，确认本轮前端改动未引入类型错误。

LLM JSON 修复链路优化

• 标识：task-3b8c9c2f4a
• 状态：开发中
• 最近更新：2026-04-24 10:51
• 概要：优化结构化 JSON 修复链路，在进入 AI 修复前先尝试处理常见格式错误，并在修复失败时返回明确失败原因与操作建议。

计划清单：

• 梳理当前 JSON 修复入口、AI 修复触发条件和现有失败路径，明确哪些错误应在 AI 修复前优先本地兜底
• 增加常见格式错误预修复步骤，例如清理 ````json` / ``` 包裹、去掉明显噪音前后缀、补做安全的基础标准化
• 为 JSON 修复失败建立明确分类，至少区分 JSON 不完整、JSON 数据缺失 / 字段缺失、结构不合法但可定位 等结果
• 当判断为 JSON 不完整 时，补充高概率原因提示，优先提示可能是模型输出被截断或 token 上限不足，并建议用户切换更强模型或重试
• 为修复结果补齐可消费的错误原因与提示文案合同，避免上层只能拿到笼统失败
• 补充最小回归测试，覆盖 markdown fenced JSON、截断 JSON、字段缺失 JSON 与 AI 修复失败场景

进度记录：

• 2026-04-10 00:45 [已计划] 已记录后续优化方向：先做常见错误预修复，再增强 AI 修复失败原因分类与模型切换提示。
• 2026-04-24 10:51 [开发中] 已吸收 PR #22 中可安全并入主线的部分：对“对象 schema + 单元素数组包裹”增加 schema-aware 本地解包，对中转站 / Relay 返回的 HTML 错页改判为 transport_error，并补充 markdown fenced JSON、字段缺失、AI 修复后仍缺字段、HTML 错页与单元素数组包裹的 targeted regression tests；更细粒度的字段缺失提示合同仍待继续收口。

角色资源账本与背包系统

• 标识：task-65a7562c11
• 状态：已完成
• 最近更新：2026-04-25 08:41
• 概要：完成角色背包剩余闭环：任务抽屉待确认入口、卷级资源承诺视图、旧项目最近章节资源回填，以及资源复查/回填的独立提交路径。

计划清单：

• 小说任务抽屉展示资源变更待确认，并支持来源跳转、确认、忽略
• 卷战略页展示本卷关键资源承诺，帮助规划本卷行动边界和后续兑现
• 角色准备页提供最近章节资源回填入口，用于已有正文或旧项目轻量补账
• 资源复查/回填跳过通用章节事实提取，只提交角色资源 proposal
• 完成 shared/server/client build 与 targeted tests 验证

进度记录：

• 2026-04-25 08:41 [已完成] 2026-04-25: 完成角色背包剩余闭环；待确认资源进入小说任务抽屉，卷战略可查看本卷资源承诺，旧项目可手动回填最近章节资源。

预发 beta 分支发布流程规则

• 标识：task-a9206e4ae1
• 状态：已完成
• 最近更新：2026-04-25 00:35
• 概要：已在 AGENTS.md 写入 beta 预发分支规则，并将已完成的 desktop-dev 调整为收尾验证、合入 beta/main、退休分支的流程。

计划清单：

• 确认 AGENTS.md 现有开发分支、desktop-dev、打包发布规则之间的关系
• 新增 beta 预发分支工作流，明确功能分支、自测、预发集成、发布回 main 的顺序
• 将 desktop-dev 从长期集成分支调整为已完成功能的收尾验证、合入 beta/main、退休流程
• 补充发布与桌面打包前必须基于 beta 验证稳定的约束

进度记录：

• 2026-04-25 00:35 [已完成] 已完成 AGENTS.md 分支规则更新：功能分支先入 beta 预发验证，desktop-dev 作为完成候选进入 beta/main 后退休。

角色库与小说角色同步系统

• 标识：task-3ae84511d6
• 状态：开发中
• 最近更新：2026-04-26 14:27
• 概要：首轮后端闭环已落地，并补充角色系统长期升级文档：后续围绕角色叙事岗位、关系张力和章节角色上下文包继续推进。

计划清单：

• 第一期开发角色叙事岗位 MVP：为小说角色生成本书职责、读者收益、剧情发动方式和红线
• 第一期开发章节角色上下文包 MVP：让章节生成、审稿、修复消费角色任务而不是只读角色列表
• 第一期接入关系张力摘要：输出本章需要推进或避免写崩的核心关系变化
• 为角色同步工作台接入前端入口：角色库引入、保存到角色库、同步建议列表
• 扩展端到端测试，覆盖同一角色被多本小说引用时的应用、忽略、分叉路径

进度记录：

• 2026-04-26 14:27 [开发中] 已新增角色系统升级长期方案文档和第一期开发方案，并与角色资源账本文档建立互链