文档：完善阶段三产品边界与实施前置

智能创作构建系统产品方案.md

@@ -2,7 +2,7 @@
 
 > 文档范围：只讨论脚本创作阶段的系统能力、产品策略、业务流程、数据与工具使用，不讨论商业化、品牌、组织和底层工程实现。
 >
-> 事实基线：上一代 `script_build_refactor_0709@3b2db592079a` + 当前仓库 `main@eff9d8f` 的 `agent/` 与 `script_build_host/`，审查日期 2026-07-19。
+> 事实基线：上一代 `script_build_refactor_0709@3b2db592079a` + 当前仓库 `main@530b6a5` 的 `agent/` 与 `script_build_host/`，审查日期 2026-07-19。
 >
 > 实施状态：阶段一、阶段一审查后的 Host 加固以及阶段二功能里程碑已经完成并通过自动化测试；阶段三仍是待实现合同。阶段二当前交付的是可验证、可追溯的候选组合检查点，不是正式发布结果。
 
@@ -1098,6 +1098,8 @@ Task、Attempt、Validation、Decision 和 Trace 可用于解释这份脚本如
 
 阶段二已经实现结构化候选版本、`branch_id>0` 工作区、Paragraph/Element/Link 兼容写入、动态 TaskContract、显式 ACCEPT 导入、Active Frontier、替代/比较关系、运行预算、六类创作 Worker、四层 Candidate Validation、Compose 和唯一 CandidatePortfolio 边界。它只形成候选检查点，不写正式版本。
 
+阶段二已经按框架能力、Host 加固、领域合同与工作区、动态创作与验证、生命周期/API、真实 Runner E2E 和文档拆成 18 个细粒度提交，并推送为可回退、可比较的 `main@530b6a5` 基线。阶段三只能建立在该提交上；后续缺陷必须能明确归属于 V2 回归或 V3 新增能力，不能把未固化工作区当作阶段三起点。
+
 阶段三仍需实现 RootDeliveryManifest、Root Validator、正式 `branch_id=0` Publisher、旧详情 readback、最终 `success`、resume/recovery、跨进程 OwnerLease、统一 HTTP 幂等/错误合同和人工恢复入口。
 
 框架不会自动提供 Topic、Persona、Round、Branch、Paragraph、Element 或页面节点，也不会自动把旧 Branch 当成 Attempt。
@@ -1196,14 +1198,55 @@ build = partial
 
 ### 阶段三（待实现）：Root、正式发布与恢复
 
-1. **从检查点继续**：Host 对阶段二 Root 执行受控 UNBLOCK；Planner 只以被接受 Portfolio 和冻结输入进入最终交付，不重新扫描所有历史候选。
-2. **Root 交付清单与整体验收**：Root Worker 不改正文，只生成 RootDeliveryManifest；Root Validator 依据 Manifest 检查整稿叙事、事实证据、人设、策略、结构关系、占位表达和旧详情可读性；Planner ACCEPT 直接绑定该 frozen Manifest，再由 Manifest 不可变地绑定同一 StructuredScript。
-3. **确定性发布**：Publisher 以 Root ACCEPT Decision 为数据库幂等键，要求重试始终携带同一 RootDeliveryManifestRef，再从 Manifest 解析唯一 frozen StructuredScript，在事务中投影唯一 `branch_id=0` Paragraph/Element/Link，更新摘要/计数，执行旧详情 canonical readback 与 digest 对账。
-4. **状态门禁**：只有 Root ACCEPT、publication published、旧详情回读一致三者成立才投影 `success`；失败保持可恢复状态，绝不另生成一份未验证正文。
-5. **恢复与所有权**：实现 resume/recover、跨进程 OwnerLease/fencing token、遗留 RUNNING Attempt 分类、orphan Artifact reconcile、stop/publication 竞态保护和幂等 finalize。
-6. **完整兼容**：补齐旧详情辅助字段、正式结果 API、人工恢复入口和全链路 Decision→Attempt→Validation→Artifact→Publication→Trace 追溯。
+#### 15.3.0 阶段三实施前置固化
+
+阶段三开始写代码前，必须先锁定五项不会在开发中临时解释的合同：
+
+1. **V2 Git 基线**：以已推送的 `main@530b6a5` 为唯一阶段三起点，重跑 V2 全量门禁并保存结果；阶段三不重新设计阶段二 Task 树、候选工作区或 Portfolio。
+2. **旧 API 金标**：从上一版本真实 HTTP 响应保存 start/upload/list/detail/log/prefill/retry/delete/favorite/overview/stop/trace_messages 及旧错误响应 fixture，冻结 JSON 字段、null/空集合语义、ID 类型、排序、嵌套关系和状态码；新系统新增的 401、跨 build 隐藏 404 和 WebSocket 4404 单独作为安全叠加合同，不伪造成上一版响应。Run 454 的 5 Paragraph、11 Element、13 Link 只证明“能表达”，不能代替完整兼容金标。
+3. **稳定摘要规则**：Root dry-run 和正式发布回读都按稳定逻辑身份与业务内容计算 `legacy_projection_digest`，不把数据库自增 Paragraph/Element/Link ID、branch ID、时间戳等物理值放入摘要。正式 API 仍返回新插入的真实物理 ID，但它们不影响同一内容的验收结果。
+4. **原子发布边界**：`branch_id=0`、canonical readback、publication published、Artifact published、accepted Root 指针和 build=`success` 必须同成同败，任何中间失败对旧消费者都不可见。
+5. **所有权与崩溃状态表**：Mission owner/fencing token 必须有数据库持久化依据；Phase2→Phase3 从“策略尚未写”到“发布已完成”的每个崩溃点都必须规定唯一重入动作，禁止靠扫描 latest 或重复调用模型猜测恢复。
+
+只有这五项的 fixture、规则、迁移设计和测试骨架完成，才进入阶段三业务开发。它们不是额外阶段，也不是上线后补文档，而是阶段三第 0 步的准入门禁。
+
+#### 15.3.1 从阶段二检查点继续
+
+- Host 只接受 `PHASE_TWO_CANDIDATE_PORTFOLIO_READY`、唯一 Portfolio ACCEPT、唯一 adopted StructuredScript、无活动 Operation 的 build；其他状态拒绝推进。
+- 继续使用同一个 Root 和 Planner Trace，只追加一次受 Host 签名的 Phase3 policy 与 continuation message，再受控 UNBLOCK；不创建第二个 Root，不 rewind Trace。
+- Phase3 policy 已写但未 UNBLOCK 时补 UNBLOCK；已 UNBLOCK但尚未启动 Root 时从现有主路径继续；Root 已产生实际模型副作用后崩溃时进入恢复分类，不重跑同一 Attempt。
+- Planner 进入阶段三后只看到冻结输入、accepted Direction、accepted Portfolio 和唯一 StructuredScript，不重新扫描阶段二的未采用候选，也不再修改正文。
+
+#### 15.3.2 Root 交付清单与整体验收
+
+- 不新增另一个 Root 或 Root 子 Task，而是把同一个 Root 受控 REVISE 为 execution-ready Root Delivery 合同，再由 Root Worker 和独立 Root Validator 执行；这里只产生可独立验收的交付清单，不把 Root 当作第二次写稿。
+- Root Worker 对唯一 StructuredScript 做旧详情 dry-run，冻结 `RootDeliveryManifest`；Manifest 固定绑定 Direction、Portfolio、StructuredScript、输入闭包和稳定 legacy projection digest。
+- Root Validator 根据同一 Manifest 检查整稿叙事、事实证据、人设、策略、结构关系、占位表达、引用闭合和旧详情可读性。Validator 通过后仍由 Planner 决定 ACCEPT。
+- Root ACCEPT 只是“允许发布这一个 Manifest”，不会自动把另一份正文、latest 候选或可变数据库工作区带入发布。
+
+#### 15.3.3 确定性原子发布
+
+- Publisher 以 Root ACCEPT Decision 为幂等身份，每次重试必须携带同一 RootDeliveryManifestRef，并从 Manifest 解析同一 frozen StructuredScript。
+- 候选 `branch_id>0` 保持不可变；Publisher 在事务内为 `branch_id=0` 插入新的 Paragraph/Element/Link，并建立稳定逻辑身份到新物理 ID 的映射，不直接把候选行改成正式行。
+- 正式投影、摘要/计数、同 Session 旧详情回读、digest 对账、publication/Artifact published、accepted Root 指针和 build=`success` 全部属于同一个提交单元。
+- digest 不一致、停止请求、fencing 失效或任一步异常都整体回滚；重试同一 Manifest，不重新生成正文。
+
+#### 15.3.4 所有权、停止与恢复
+
+- 单机首版使用持续持有的进程文件锁保证只有一个运行 owner，同时用 binding 中持久化的 owner epoch、stop epoch 和 instance identity 作为数据库发布栅栏；单个 Operation 的 execution epoch 不能冒充整个 Mission 的 fencing token。
+- stop 与 finalize 以数据库锁的先后作为竞态裁决点：stop 先取得锁则发布必须退出；发布先取得锁并完成原子提交，则 stop 等待后看到 `success`，不得再把结果改成 `stopping`。
+- 对“策略已写未 UNBLOCK、已 UNBLOCK未启动、Operation 已建未启动、Worker 已启动、Root ACCEPT 未发布、publication pending/failed、publication 已完成”分别定义恢复动作。
+- `resume` 只继续同一个 build；旧 `retry` 的产品语义仍是创建一个新 build。上一版本通过回退/改写 Trace 消息来“重跑”的 unsafe resume 不作为兼容目标。
+
+#### 15.3.5 旧 API 完整兼容与观测
+
+- 旧 start/upload/list/detail/log/prefill/retry/delete/favorite/overview/stop/`trace_messages` 的成功与旧错误响应都以金标 fixture 验收；新安全错误单独验收；`post_datas`、`script_datas`、`linked_elements`、`sub_paragraphs` 和所有空值保持旧合同。
+- 正式详情返回 branch0 的真实物理 ID 和关系引用，并使用确定性排序；候选 Task、未采用版本和内部 Trace 字段不得混入旧详情。
+- 新观测面继续提供 Decision→Attempt→Validation→Manifest→StructuredScript→Publication→Trace 的因果链，并提供幂等 finalize、受控 resume 和人工恢复入口。
+
+#### 15.3.6 阶段三完成效果
 
-做完效果：旧下游继续读取唯一正式脚本；新系统同时提供动态规划、独立验证、可恢复发布和完整因果证据。阶段三结束才算整个产品合同完成。
+阶段三只有在唯一 Root Manifest ACCEPT、事务内 canonical 回读一致、原子 publication 已提交且旧详情金标兼容后才完成。提交后的独立 HTTP 健康回读用于发现数据库/缓存/序列化异常；若失败必须告警并进入一致性修复，但不能回滚已经原子提交的成功事实，也不能重新生成正文。做完后，旧下游仍像过去一样读取唯一正式脚本；新系统则能说明该脚本来自哪个冻结候选、经过哪些验证、如何安全发布以及中断后为什么从该位置继续。阶段三结束才算整个产品合同完成。
 
 ## 16. 系统验收标准