文档：补充阶段二动态创作能力与产品验收边界

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

@@ -2,7 +2,9 @@
 
 > 文档范围：只讨论脚本创作阶段的系统能力、产品策略、业务流程、数据与工具使用，不讨论商业化、品牌、组织和底层工程实现。
 >
-> 事实基线：上一代 ScriptBuild 真实代码 + 本项目现有 Agent 框架，审查日期 2026-07-18。
+> 事实基线：上一代 `script_build_refactor_0709@3b2db592079a` + 当前仓库 `main@eff9d8f` 的 `agent/` 与 `script_build_host/`，审查日期 2026-07-19。
+>
+> 实施状态：阶段一、阶段一审查后的 Host 加固以及阶段二功能里程碑已经完成并通过自动化测试；阶段三仍是待实现合同。阶段二当前交付的是可验证、可追溯的候选组合检查点，不是正式发布结果。
 
 ## 0. 产品定义与硬约束
 
@@ -32,6 +34,18 @@
 
 代码证据：`prompts/script/script_build_system_v2.md:3-19`、`models.py:480-499,528-598`。
 
+### 0.4 三阶段交付边界
+
+| 阶段 | 交付物 | Root/构建状态 | 是否正式发布脚本 |
+|---|---|---|---|
+| 阶段一（已实现） | 冻结输入、已验证 Evidence、已验证 Direction、完整任务/验证/追踪记录 | Root `BLOCK(PHASE_ONE_CAPABILITY_BOUNDARY)`；build=`partial` | 否，只幂等投影当前方向 |
+| 阶段二（已实现） | 一份正式采用的完整结构化候选、可选对照候选及 `CandidatePortfolio` | Root `BLOCK(PHASE_TWO_CANDIDATE_PORTFOLIO_READY)`；build=`partial` | 否，不写 `branch_id=0` |
+| 阶段三（待实现） | 通过整稿验证并发布、回读一致的唯一正式脚本 | Root ACCEPT；发布成功后 build=`success` | 是，Host 幂等发布到旧正式读取合同 |
+
+动态规划不是阶段三结束后的“高级模式”，而是三个阶段共同使用的控制方式。阶段边界只限制当期可生产的业务 Artifact，不把 Planner 退化成固定步骤执行器。
+
+这三段首先是研发和上线检查点，不是最终要求用户手工点击三次的业务 Workflow。后续能力启用后，Host 可在每个 durable checkpoint 后用幂等内部命令自动前向继续；现有 `partial` 构建也可显式升级。最终系统仍是一笔旧 start 请求朝同一个 Root 目标收敛。
+
 ## 1. 新旧系统的变化边界
 
 ### 1.1 保持不变的部分
@@ -53,7 +67,7 @@
 |---|---|
 | 开始创作后固定进入 Round | 主 Agent 先判断当前最重要缺口，再创建必要任务 |
 | 每轮必须登记 multipath plan | 只有方向不确定且并行探索有价值时才建立多个候选任务 |
-| 实现 Agent 再嵌套调用取数 Agent | 复杂取数成为主 Agent 直接派发的专业任务；简单查询仍可作为只读工具使用 |
+| 实现 Agent 再嵌套调用取数 Agent | 复杂取数成为主 Agent 直接派发的专业任务；创作 Worker 只可做冻结输入内的局部只读查询，Validator 不临时取新数 |
 | 固定“实现→多路评估→合并→整稿评估” | 每次任务提交后独立核验，主 Agent 按结果选择下一动作 |
 | 最多 15 个 Round | 没有业务轮次上限；由任务价值、完成条件和运行约束共同收束 |
 | 有段落/元素即可兜底成功 | 必须验证同一份完整正式脚本，Root 通过并被主 Agent 接受才完成 |
@@ -82,7 +96,7 @@
 | `topic_id` | 是 | 指定要转成脚本的选题 | 本次脚本 Mission 的核心内容对象 |
 | `agent_type` | 兼容 | 老版执行器类型，固定为 `AigcAgent` | 兼容入口可继续接受，新系统内部不依赖它决定流程 |
 | `agent_config` | 可选，有默认 | 主模型、创作/评估/四类取数模型、温度、迭代限制 | 保留缺省补全语义，再转换为各专业角色的运行配置 |
-| `data_source_url` | 可选，有默认 | 资料库、Pattern 等数据访问根地址 | 保留默认源，并提供给只读取数能力 |
+| `data_source_url` | 可选，有默认 | 上一代请求中的资料源提示 | 阶段一仅校验并存入旧 build；生产 Pattern/Decode/External 实际使用 Host 配置的 allowlisted endpoint，调用方不能改写出站目标 |
 | `strategies_always_on` | 可选 | 全程必须遵守的脚本策略 ID | 任务启动时全文装配为强约束 |
 | `strategies_on_demand` | 可选 | 按需加载的脚本策略 ID | 先提供名称和说明，必要时读取全文 |
 
@@ -230,7 +244,8 @@
 | 用户停止且不再执行 | `stopped` | 已有候选仍保留，但不是正式成功 |
 | 暂时缺资料、权限或人工决定 | `running` 或显式阻塞说明 | 旧枚举没有 blocked；不得误报 success |
 | 运行失败且没有可交付正式版本 | `failed` | 保留失败原因和已发生的尝试 |
-| 达到护栏，只能交付明确标注的不完整正式版本 | `partial` | 必须经过整体验证，并明确缺口；不能只因有段落就 partial |
+| 阶段一 Direction 检查点或阶段二 CandidatePortfolio 检查点已闭合 | `partial` | 这是明确能力边界，不表示已有正式脚本；不得让旧消费者误读为 success |
+| 阶段三达到护栏，只能保留明确标注的不完整候选 | `partial` 或 `failed` | 必须记录整体验证和缺口；是否允许对外展示由独立产品策略决定，不能只因有段落就 partial |
 | Root 已接受，且同一业务版本已发布、读回一致 | `success` | 唯一成功条件 |
 
 Host 对“已验证版本→旧正式读取”的发布必须幂等，并绑定 Root 接受的同一版本。发布或读回失败时，对旧消费者不得返回 `success`，应进入可重试的交付恢复状态；不能创建另一份正文偷偷替换被验证版本。
@@ -286,7 +301,7 @@ Host 对“已验证版本→旧正式读取”的发布必须幂等，并绑定
 #### 在新系统中的两种使用方式
 
 - **复杂取数**：主 Agent 创建一个独立取数任务，由对应专业 Agent 执行并由 Validator 验证；当它是后续创作任务的直接子任务时，被接受的结果会在父 Attempt 创建时成为固定输入；其他关系必须由 Host 显式提供不可变结果引用。
-- **简单查询**：创作 Worker 或 Validator 可以直接调用已授权的只读查询工具，不必为一次小查询机械创建任务。
+- **冻结范围内的简单查询**：创作 Worker 可直接读已授权的 InputSnapshot、已 ACCEPT Evidence 或候选工作区，不必为一次局部读取机械创建任务。Validator 只读同一冻结快照、已接受证据和本地确定性检查；一旦发现需要新数据，必须报告 Evidence gap，由 Planner 新建 Retrieval Task。
 
 新系统不允许创作 Worker 私自生成新的业务 Agent 或修改任务树。需要多步检索、独立验收或会影响后续多个任务的取数，必须回到主 Agent 建立专业任务。
 
@@ -312,6 +327,8 @@ Host 对“已验证版本→旧正式读取”的发布必须幂等，并绑定
 - 图片观察结论必须与图片来源一同进入证据；
 - Validator 可只读复核，不允许改写脚本。
 
+阶段一完成安全下载、MIME/数量/大小校验和 raw Artifact 存档，不向模型透传 URL。阶段二已经增加 `view_frozen_images`：只从当前 accepted bundle/Validator snapshot 读取同一冻结字节，复核 MIME、大小和 digest，再通过 durable Trace 附件交给 Worker/Validator；缺少附件持久化能力的生产 Runtime 不得启用图片理解。
+
 ### 4.6 结构化脚本写入能力
 
 创作 Worker 必须继续能够写出旧版结构，而不是只提交 Markdown：
@@ -322,22 +339,18 @@ Host 对“已验证版本→旧正式读取”的发布必须幂等，并绑定
 | 追加四列原子点 | `append_paragraph_atoms` | 向主题/形式/作用/感受追加原子元素 |
 | 删除错误原子点 | `delete_paragraph_atom` | 做局部、可解释的删除 |
 | 创建脚本元素 | `create_script_element` | 建立实质/形式元素 |
-| 更新脚本元素 | `update_script_element` | 修订元素名称、一级/二级维度或 active 状态 |
+| 更新脚本元素 | `update_script_element` | 修订元素名称、一级/二级维度、分析字段或 active 状态 |
 | 建立段落—元素关系 | `batch_link_paragraph_elements` | 形成结构化关联 |
 | 删除错误关系 | `delete_paragraph_element_links` | 解除错误支撑关系 |
 | 批量更新段落 | `batch_update_script_paragraphs` | 做局部结构和文本修订 |
 
-同时保留：
-
-- `save_domain_info`：追加已核实领域事实；
-- `record_data_decision`：记录采用/舍弃哪些资料及其理由；
-- 当前脚本快照与候选读取：保证 Worker 修改的是明确版本。
+领域事实不再通过不存在的旧日志工具写入：核实结果进入 Evidence Artifact，采用/舍弃理由进入 Planner Decision、Comparison 与 CandidatePortfolio。Worker 仍可读取当前 Attempt workspace 和合同钉死的候选快照，不能扫描 latest。
 
-需要注意一个真实能力缺口：老版 Element 数据模型虽然包含 `commonality_analysis`、`topic_support`、`weight_score`、`support_elements`，但当前 `create_script_element` / `update_script_element` 工具只允许写名称、一级/二级维度以及 active 状态。新系统第一阶段必须保持这些输出字段可读和兼容，不能声称旧 Worker 已能填满它们；若业务要求非空，应把“补齐元素分析字段的受控写入”列为业务能力增强，并纳入 Validator 验收。
+老版 Element 工具只覆盖名称、维度和 active 的缺口已经由阶段二 Host Adapter 补齐：`create_script_element` / `update_script_element` 可写 `commonality_analysis`、`topic_support`、`weight_score`、`support_elements`，freeze/readback 和 Validator 对这些字段执行结构校验。
 
-还要保留一个兼容门禁：老版实现 Worker 在 `branch_id>0` 的候选分支首次调用 `create_script_paragraph` 或 `create_script_element` 前，要求存在 `record_task_plan`；base、调试和主 Agent 场景有放行。新系统不能让这份旧计划变成第二套规划真源。推荐由 Host 把当前框架 Task 自动映射为最小兼容执行清单，并同步必要的 step 状态；长期可改造旧写工具直接以框架 Task 作为门禁。无论采用哪种方式，验收都必须证明 Creative Worker 不需要人工再维护一套旧 Workflow 才能写稿。
+还保留一个兼容门禁：老版实现 Worker 在 `branch_id>0` 的候选分支首次调用 `create_script_paragraph` 或 `create_script_element` 前，要求存在 `record_task_plan`。当前 Host 已在首次候选写入前自动幂等创建 `step_key=1`、`round_index=NULL` 的最小 TaskPlan 投影，并在 freeze/discard 时写“完成/受阻”；模型不拥有 `record_task_plan`，旧计划不成为第二套规划真源。
 
-代码证据：`script_build_tool_schemas.json` 中的 `create_script_element/update_script_element` 合同；写入门禁见 `script_build_agent_tools.py:2454,2991-2995,3106`。
+旧基线证据：`script_build_tool_schemas.json` 与 `script_build_agent_tools.py:2454,2991-2995,3106`。当前实现证据：`script_build_host/repositories/workspace.py` 的 Element create/update、write-scope、TaskPlan 与 freeze 路径，以及 `tests/test_phase_two_workspace.py`。
 
 ### 4.7 评估能力
 
@@ -419,15 +432,15 @@ Host 对“已验证版本→旧正式读取”的发布必须幂等，并绑定
 
 ### 5.4 创作 Worker
 
-创作 Worker 只处理明确边界的任务，例如：
+Structure、Paragraph、Element、Compare、Compose 只是不同的专业能力，不代表固定工序。创作 Worker 只处理有冻结输入、明确作用范围并可独立验收的创作增量，例如：
 
 - 形成创作方向候选；
-- 设计开场结构；
-- 写一个一级段落及其二级段落；
+- 为开场的两个转折点补出局部结构；
+- 写一个一级段落，或只替换其中一段无效论证；
 - 补主题/形式/作用/感受原子点；
-- 创建并关联脚本元素；
+- 为已写段落寻找、替换并关联一组脚本元素；
 - 修正 Validator 指定的局部缺陷；
-- 汇总已接受的子任务结果，形成完整正式候选。
+- 组合一组明确采用的结果，形成完整候选。
 
 创作 Worker 可以使用简单只读工具，但不能自行更改全局目标、创建新业务任务或宣布自己的结果合格。
 
@@ -451,23 +464,25 @@ Validator 不改脚本、不创建任务、不派发 Agent、不把任务直接
 老版兼容输入
   选题表 + 人设/账号画像 + 策略 + 资料源
                   ↓
-Host 装配一次脚本 Mission 与整稿验收条件
+Host 冻结 InputSnapshot，装配一次 Mission 与 Root 验收条件
                   ↓
 主 Agent 读取当前事实，识别最重要缺口
                   ↓
-按需创建取数 / 方向 / 结构 / 局部创作 / 修复 / 比较任务
+按需创建“明确范围 × 冻结输入 × 可独立验收增量”的 Task
                   ↓
 专业 Worker 执行并提交候选版本与证据
                   ↓
 独立 Validator 核验同一候选版本
                   ↓
-主 Agent 接受 / 返修 / 重试 / 修订 / 拆分 / 阻塞 / 替代
+主 Agent 接受 / 返修 / 重试 / 修订 / 拆分 / 阻塞，或新建替代任务
+                  ↓
+Planner 继续探索、比较、替换或 Compose；探索顺序不等于采用顺序
                   ↓
-Root Worker 消费已接受结果，写出完整正式候选版本
+阶段二：冻结并接受 CandidatePortfolio，Root 在能力边界 BLOCK
                   ↓
-Root Validator 核验完整脚本表，主 Agent 最终接受
+阶段三：整稿 Validator → Root ACCEPT → Host 幂等发布与旧详情回读
                   ↓
-输出老版兼容 ScriptBuildRecord + Paragraph + Element + Link
+输出老版兼容 ScriptBuildRecord + Paragraph + Element + Link，状态 success
 ```
 
 ### 6.2 启动：把旧输入装配成一次 Mission
@@ -487,7 +502,7 @@ Root Validator 核验完整脚本表，主 Agent 最终接受
 
 - 完整选题点、元素、关系和来源；
 - 账号创作人设点与段落模式；
-- always-on 策略和 on-demand 策略摘要；
+- always-on 和 on-demand 策略；快照冻结两者全文，但默认读取只返回 always-on 全文与 on-demand 摘要/digest，合同钉死同一 Snapshot 后才能用 `load_frozen_strategy` 按需加载并记录 Trace；
 - 当前脚本快照、方向、统计和领域事实；
 - 已经完成、失败或被接受的任务。
 
@@ -503,7 +518,25 @@ Root Validator 核验完整脚本表，主 Agent 最终接受
 | Validator 指出一个关系错误 | 只修关系，不机械再跑全流程 |
 | 选题前提本身被证据推翻 | 修订 Root/相关任务，必要时等待人工确认 |
 
-### 6.4 专业任务执行与独立验证
+这里的 Task 不等于“脉络模块”“段落模块”或“元素模块”。统一产品定义是：
+
+> **Task 是：在一组冻结输入上，对一个明确范围产生一个可独立验收的创作增量。**
+
+因此同一种能力可以出现多次、每次作用范围不同：第一次只找开场到冲突的局部脉络，第二次补中段论证，第三次用新证据替换其中一个转折；元素也可以先为某段探索，再因脉络变化局部换掉。是否拆 Task 看“失败能否独立处理、结果能否独立验证、是否值得并行探索”，而不是看代码里有几个业务模块。
+
+### 6.4 探索顺序与正式采用顺序
+
+系统允许根据当前信息选择探索顺序：
+
+- 结构优先：方向明确但叙事职责不清，先探索局部或整体脉络；
+- 元素优先：一个高价值案例、画面或心理学概念可能反向决定结构；
+- 段落优先：开场原型先写出来，再从真实表达中抽取脉络和元素；
+- 检索插入：任何阶段发现事实、账号模式或素材缺口，都可新增 Retrieval Task；
+- 并行探索：只在候选差异真实、收益可能覆盖成本时并行。
+
+探索过什么、先后如何，不直接决定最终稿采用什么。正式采用必须由显式输入引用、Validator 报告、Planner ACCEPT 和 Compose 选择共同确定；禁止按任务创建时间、数据库“latest”或最后一次模型输出静默覆盖。
+
+### 6.5 专业任务执行与独立验证
 
 每个任务在执行前要明确：
 
@@ -517,7 +550,7 @@ Root Validator 核验完整脚本表，主 Agent 最终接受
 
 Worker 完成后提交候选版本、摘要和证据。Validator 必须核验提交时冻结的同一版本，不能在内容变更后沿用旧报告。
 
-### 6.5 主 Agent 重规划动作
+### 6.6 主 Agent 重规划动作
 
 | 动作 | 适用条件 | 产品行为 |
 |---|---|---|
@@ -527,24 +560,37 @@ Worker 完成后提交候选版本、摘要和证据。Validator 必须核验提
 | 修订 | 目标、验收条件或上下文本身不正确 | 形成新版本任务再执行 |
 | 拆分 | 问题过大或多个失败原因耦合 | 拆成更小、可独立验证的子任务 |
 | 阻塞 | 缺权限、缺关键资料或需人工决定 | 保存原因和解除条件，等待外部输入 |
-| 替代 | 新证据使旧方向失效 | 保留旧历史，用新任务取代 |
+| 替代 | 已接受结果因新证据或新组合不再适用 | 保留旧 ACCEPT，创建引用旧结果与新输入的替代 Task；新结果的业务合同显式声明 supersedes |
 | 取消 | 任务不再推进 Root 目标 | 停止继续投入 |
 
 这组动作替代固定 Round 自增。
 
-### 6.6 Root 整合与最终收口
+### 6.7 候选组合、Root 整合与最终收口
 
-当所有后代都已收束为 completed、cancelled 或 superseded，且 Root 所需的直接子任务均已接受后：
+阶段二先由一个或多个 Compose Task 在明确候选闭包内形成完整结构化候选，再由独立 CandidatePortfolio Task 选择正式候选集合。阶段三 Root 不重写正文，只形成交付清单并完成正式发布：
 
-1. 创建 Root Attempt 时，框架按直接子任务 `display_path` 顺序冻结它们的 ACCEPT Decision；Root Worker 只消费这组绑定结果；
-2. 更深层的取数、方向和局部结果必须先由其直接父任务吸收，不能让 Root 扫描任意后代；
-3. Root Worker 使用旧结构化写入能力，把方向、段落、四列、元素和关系整合成一份完整、可重读的业务候选版本；
-4. Host 先把该版本写入隔离的 staging/候选工作区，并用旧正式读取规则做兼容预检；未通过 Root Validation 前不得进入 `branch_id=0` 正式结果；Root Validator 核验的必须是这同一 staging 版本；
-5. 主 Agent ACCEPT Root 只确认该版本满足 Mission，不会自动 merge 或发布业务数据；Host 必须以该 ACCEPT 绑定版本为键做幂等发布；
+```text
+Root
+├── Direction Task（阶段一 completed，不重开）
+└── CandidatePortfolio Task（阶段二 Root 直接子）
+    ├── Compose Task A
+    │   └── 动态 Structure/Paragraph/ElementSet/Retrieval/Replacement 子树
+    ├── Compose Task B（只有确有第二个整稿候选时才建）
+    ├── 整稿 Compare Task（可选）
+    └── 自身 Attempt：选择已接受 Compose，冻结 Portfolio
+```
+
+这样 Root 创建最终 Attempt 时，框架自动绑定的直接子结果只有不可变 Direction 与被接受 Portfolio，而不是所有局部探索。阶段二局部结果先在 Portfolio Task 内收束。
+
+1. 框架自动冻结父 Attempt 的直接子 ACCEPT；Host 还必须把 Planner 明确导入的其他历史 ACCEPT Decision、Artifact version 和 digest 钉死在 Task 上；
+2. Compose 只读取这个闭包，扣除闭包内被显式 supersede 的结果，拒绝扫描任意后代或“最新版本”；
+3. Compose 使用旧结构化写入能力，把方向、段落、四列、元素和关系整合成一份完整、可重读的 StructuredScript；Portfolio Worker 只选择已接受 StructuredScript，记录采用项、淘汰项、替代关系和未解决缺陷，不改正文；
+4. Host 先把 StructuredScript 写入隔离的 staging/候选工作区，并用旧正式读取规则做兼容预检；未通过 Root Validation 前不得进入 `branch_id=0` 正式结果；
+5. 阶段三 Root Worker 只提交指向 accepted Portfolio/StructuredScript 与 dry-run digest 的 RootDeliveryManifest；Root Validator 核验同一正文，主 Agent ACCEPT Root 后 Host 才以该 ACCEPT Decision 为数据库幂等键、以其绑定 Manifest 为不可变校验项发布；
 6. 只有发布成功、旧详情读回一致、Root 已接受三者同时成立，业务状态才投影为 `success`；发布失败进入交付恢复，不生成另一份正文；
 7. 已接受版本不可修改。发布后如需改正文，应启动新的 Mission 或独立修订运行，不能重开已 completed 的 Root 或沿用旧 Validation。
 
-### 6.7 全局收敛护栏
+### 6.8 全局收敛护栏
 
 取消固定 15 Round 不等于无限执行。每次 Mission 启动时必须设置产品级运行护栏：
 
@@ -560,26 +606,92 @@ Worker 完成后提交候选版本、摘要和证据。Validator 必须核验提
 
 ## 7. 动态任务库：可选能力，不是固定 Workflow
 
-以下是主 Agent 可选择的任务类型。它们是“工具箱”，不是每篇脚本都必须执行的阶段。
+### 7.1 一个 Task 的完整产品合同
 
-| 任务类型 | 解决的问题 | 常用输入 | 产出 |
-|---|---|---|---|
-| 输入一致性检查 | 选题、人设、策略是否齐全、互不冲突 | Topic/Persona/Strategy | 缺失项或可执行上下文 |
-| 事实补证 | 核心说法是否可信 | Topic Sources、Pattern、External、Knowledge | 带来源的事实包 |
-| 账号模式研究 | 账号常用结构与表达是什么 | Persona、Section Pattern、Decode | 账号模式摘要与适用边界 |
-| 创作方向 | 这份选题应如何转成脚本 | 选题、账号、策略、事实 | `script_direction` 候选 |
-| 结构设计 | 一级/二级段落如何组织 | 方向、案例、账号模式 | 段落骨架候选 |
-| 局部段落创作 | 完成特定段落 | 骨架、证据、已接受子结果 | Paragraph 候选 |
-| 四列补全 | 主题/形式/作用/感受缺口 | 段落、Pattern、Decode | 四列文本和原子点 |
-| 元素与关联 | 哪些实质/形式元素支撑哪些段落 | Topic items、段落 | Element 与 Link 候选 |
-| 局部修复 | 修复 Validator 指定问题 | 原候选、失败报告 | 新候选版本 |
-| 候选比较 | 多个高价值候选如何选或组合 | 已验证候选 | 比较 Worker 产出差异/风险/采用建议，Validator 再核验 |
-| 整稿组合 | 把接受的子结果形成完整脚本 | 已接受 Decision/Artifact | 完整正式候选 |
-| 整稿验收 | 完整脚本是否可交付 | 正式候选、全部输入和证据 | Root Validation |
-
-主 Agent 可以跳过、重复、拆分或合并这些任务，只要每个动作能说明其对 Root 交付的价值。
-
-任务树设计必须服从直接子结果规则：父 Attempt 自动绑定的只是其直接子任务的 ACCEPT Decision；更深层结果要先由直接父任务吸收。Root 的直接子任务应是少量可组合的最终贡献，不应把所有检索和局部任务平铺到 Root 下。已经接受但后来失效的结果不会消失，应由新的综合任务显式解释新旧关系，并只把统一后的结果交给上层。
+每个 Task 至少要回答以下合同问题：
+
+| 合同项 | 必须说明什么 | 示例 |
+|---|---|---|
+| `task_kind` | 使用哪一种专业能力，不代表阶段顺序 | `structure`、`element-set`、`paragraph`、`compose` |
+| `scope_ref` | 本次只负责哪一段、哪条关系或哪个缺口 | `paragraphs/opening`、`gap/placeholder-ending` |
+| `intent_class` | 这次动作属于哪类受控意图 | `explore`、`expand`、`replace`、`repair`、`compare`、`compose` |
+| `objective` | 为什么现在值得做，要交付什么局部结果 | “用真实案例替换第 3 段空洞概括” |
+| `input_decisions` | 明确采用哪些不可变 ACCEPT | Direction d7、Evidence d11、Paragraph d18 |
+| `base_artifact` | 基于哪个候选版本改 | candidate v23 + digest |
+| `write_scope` | 可以改什么、不能碰什么 | 只改 p3 正文和 p3→element links |
+| `gap_ref` | 来自哪个缺口或 Validator defect | `REALIZATION_PLACEHOLDER:p3.body` |
+| `output_schema` | 必须产出什么结构 | ParagraphPatchV1、ElementSetV1 |
+| `criteria/budget` | 如何验收、最多投入多少 | 三条硬条件；最多 2 Attempt/8k token |
+| `candidate_closure` | Compose/Portfolio 本次只能在哪些候选 Decision 内选 | d18、d21、d26，每项都绑定 Artifact version/digest |
+| `adopted/held/rejected/order` | 哪些正式采用、暂缓、淘汰，以什么顺序组稿 | 采用 d18+d26，暂缓 d21，顺序 p1→p2→p3 |
+
+这套合同让 Planner 可以反复使用同一种 Worker，却不会让“再找一次脉络”“再换一次元素”变成不可解释的自由重写。
+
+Task 合同的 objective、criteria 和 gap 是短的控制元数据，不是藏正文的容器。候选正文、验证原文片段和证据只通过有 owner/version/digest 的 Artifact 读取；被替代的文本不能藏在 TaskSpec 再进入 Compose。
+
+Compose/Portfolio 父 Task 创建时，子候选的 Decision ID 还没有产生，所以它可以先持有“开放探索合同”来建子 Task，但不能直接执行 Compose/Portfolio Worker。待子任务收束、父 Task 进入可重规划状态后，Planner 必须产生新的 TaskSpec/不可变合同版本，钉死闭包、采用集、搁置/淘汰集和组稿顺序后才能派发。旧合同保留用于审计，不在原文上补写未来结果。
+
+### 7.2 专业能力库
+
+以下是 Planner 可调用的能力，不是每篇脚本必须经过的步骤。
+
+| 专业能力 | 可大可小的任务范围 | 产出 |
+|---|---|---|
+| 输入/事实检查 | 一个前提、一个来源冲突或整个输入摘要 | 缺口或 Evidence |
+| 账号模式研究 | 开场节奏、段落职责、某类元素搭配 | Evidence/Pattern 摘要 |
+| Direction | 整体方向或因新证据产生的方向替代提案 | Direction Artifact |
+| Structure | 全局骨架、两段间脉络、一个转折或顺序替换 | Structure Artifact/Patch |
+| Paragraph | 一个段落、一小段正文或特定句群 | Paragraph Artifact/Patch |
+| ElementSet | 某段的一组元素、替代元素或关系修复 | ElementSet Artifact/Patch |
+| Compare | 两个及以上明确候选的成对比较 | Comparison Artifact |
+| Compose | 在候选闭包中选择、组装并检查冲突 | 一份 StructuredScript |
+| CandidatePortfolio | 在已接受的整稿中固定正式采用项和对照项 | 一份 CandidatePortfolio，不改正文 |
+
+### 7.3 什么时候拆、什么时候不拆
+
+应拆成独立 Task：失败能独立修复、验收标准不同、可并行降低风险、写范围不重叠，或 Validator 已定位到明确局部缺陷。
+
+应保留为一个 Task：结构与表达必须一起判断才有意义、拆开会造成两边都无法独立验收、共享写范围无法安全并行，或成本不足以支持多个候选。
+
+因此“找脉络”可以只找一部分，也可以在新元素出现后创建替代脉络 Task；“找元素”可以早于结构，也可以针对已接受段落局部补做。系统优化的是可验证增量，不是模块调用次数。
+
+### 7.4 不改历史的替代与 Active Frontier
+
+已 ACCEPT 的结果是历史事实，当前 `agent/` 不允许把 completed Task 原地 REVISE 或 SUPERSEDE。正确过程是：
+
+```text
+旧 ACCEPT Decision d-old（不可变）
+        + 新 Evidence / 新元素 / Validator defect
+                         ↓
+创建新的局部替代 Task，显式导入 d-old 和新增输入
+                         ↓
+新 Attempt → Validation passed → ACCEPT d-new
+                         ↓
+被 d-new 接受的 TaskContract/Artifact 声明 supersedes_decision_ids=[d-old]
+                         ↓
+Compose 在当前候选闭包内采用 d-new，保留 d-old 的审计历史
+```
+
+Active Frontier 不是全局“最新结果”指针，而是某次 Compose 的封闭候选集：闭包内有效 ACCEPT，减去被闭包内其他 ACCEPT 显式替代的 Decision。替代关系必须同 build、同或兼容 scope、不可成环；写范围重叠而没有显式替代/比较结论时，Compose 必须拒绝静默合并。
+
+### 7.5 探索可以乱序，正式采用必须满足类型条件
+
+动态不是无条件采用。Planner 可以先探索任意能力，但进入 Active Frontier/Portfolio 前必须满足：
+
+| 结果类型 | 可以何时探索 | 正式采用前置条件 |
+|---|---|---|
+| Evidence | 发现事实/素材缺口时随时 | 来源可重读、digest 固定、Validator passed、limitations 明示 |
+| Direction | 阶段一按需取证后 | InputSnapshot 固定，引用的 Evidence 已接受，Direction Validator passed |
+| Structure | 可先做全局或局部，也可在段落原型后补做 | 引用 accepted Direction；覆盖明确 scope；与被采用 Paragraph/ElementSet 无职责冲突 |
+| Paragraph | 可在完整结构前写原型 | 要么引用覆盖其 scope 的 accepted Structure；要么后续 Structure 明确吸收该原型并通过一致性验证 |
+| ElementSet | 可早于 Structure/Paragraph 探索 | 每个 adopted Element 必须落到 adopted Paragraph/scope，Link 闭合；未落位元素只能 held/rejected |
+| Replacement | 原结果已接受但新证据使其失效时 | 导入被替代 Decision 和新输入；scope 兼容；supersedes 无环；自身 Validator passed |
+| Comparison | 两个以上真实候选值得比较时 | 候选均 frozen/passed、scope 与输出类型可比、证据披露对称 |
+| StructuredScript | 局部闭包足以组稿时 | accepted Direction；全部 adopted refs frozen/passed；frontier 无冲突；完整渲染预检通过 |
+| CandidatePortfolio | 一个或多个整稿候选完成后 | 只引用 accepted StructuredScript/Compare；唯一 adopted StructuredScript；采用、搁置、淘汰完整；无 hard/critical unresolved defect |
+| RootDeliveryManifest | 阶段三正式交付前 | accepted Portfolio；同一 StructuredScript；旧详情 dry-run digest；无 blocking defect |
+
+例如 Paragraph-first 只代表先探索表达，不代表它自动成为正式段落；它必须在后续被某个 Structure/Compose 明确吸收并重新通过完整稿验证。这样既允许动态换顺序，又不会变成任意乱序。
 
 ## 8. 取数与证据策略
 
@@ -620,7 +732,9 @@ Worker 完成后提交候选版本、摘要和证据。Validator 必须核验提
 
 ### 8.4 被接受的子结果如何进入上层任务
 
-复杂取数、方向或候选任务被接受后，后续父任务使用的是明确的接受决定及其对应版本，而不是“扫描当前最新结果”。这样可避免：
+框架会自动把父 Attempt 创建时已完成的直接子 Task ACCEPT Decision 按 `display_path` 冻结。阶段二 Host 已通过 `AcceptedDecisionRef` 支持显式导入其他已接受结果：每项同时钉死 Decision ID、Artifact version 和 digest，并在 Attempt 创建前重新校验 build、scope、Snapshot、Validation、owner、kind 与 Artifact digest；模型不能只传一个可漂移的业务 ID。
+
+复杂取数、方向或候选任务被接受后，后续任务使用的是这组明确的接受决定及其对应版本，而不是“扫描当前最新结果”。这样可避免：
 
 - 子任务在父任务执行中途变化；
 - 父任务错误使用尚未验证的候选；
@@ -671,7 +785,21 @@ Worker 完成后提交候选版本、摘要和证据。Validator 必须核验提
 - 组合会产生哪些冲突；
 - 推荐采用、返修、淘汰或保留的理由。
 
-Validator 只核验该比较结果是否完整、证据是否成立、是否公平覆盖各候选；主 Agent 决定采用哪些结果；Root Worker 才负责形成完整脚本版本。
+Validator 只核验该比较结果是否完整、证据是否成立、是否公平覆盖各候选；主 Agent 决定采用哪些结果；阶段二由 Compose Worker 形成完整候选，阶段三 Root 只对被接受 Portfolio 做最终交付收口。
+
+### 9.4 Compose 是唯一串行整合点
+
+局部 Worker 不应一边探索一边改全稿。Compose Task 接收一个显式候选闭包，按下列顺序工作：
+
+1. 解析所有固定 Decision/Artifact/digest；
+2. 计算闭包内 Active Frontier；
+3. 检查 scope 与 write scope 冲突；
+4. 只通过 `read_active_frontier` 读取正文；任务清单中的历史子结果摘要只能显示 kind/scope/digest/状态，不带正文或长片段，被替代历史即使仍在清单中也不能被重新读入；
+5. 只根据不可变 Task 合同中的 adopted/held/rejected/order 和被接受的 Compare 引用选择结果，不把 objective 里的自然语言当授权；
+6. 串行应用到一个新的候选工作区；
+7. 重新渲染完整脚本，只冻结一个 StructuredScript；
+8. 交给全局 Candidate Validator，不能把“所有局部都 passed”当作整稿自然 passed；
+9. CandidatePortfolio Task 在一个独立 Attempt 中选择已接受的 StructuredScript 并冻结一个 Portfolio，从而保持“一次 Attempt 一个业务 Artifact”的现有数据库约束。
 
 ## 10. 验证与质量门禁
 
@@ -686,14 +814,16 @@ Validator 只核验该比较结果是否完整、证据是否成立、是否公
 | “有事实支撑” | 每个领域事实有来源引用；无法核实的说法已删除、降级或标为未知 |
 | “结构完整” | 一级/二级关系有效；四列与原子点齐全；元素与段落关系无孤立或跨版本引用 |
 
-### 10.2 局部 Validator 的核验顺序
+### 10.2 四层验证
 
-1. 身份与版本：是否是当前任务要求的同一候选；
-2. 结构完整：提交结果是否能读取、字段是否齐全；
-3. 证据闭合：结果是否引用允许且真实存在的资料；
-4. 逐条验收：每条条件分别通过、失败或无法判断；
-5. 越界检查：是否修改了任务之外的正式内容；
-6. 风险说明：未核实说法、冲突、遗漏和建议动作。
+| 层 | 检查对象 | 必须发现的问题 |
+|---|---|---|
+| 确定性预检 | schema、digest、归属、Link、base revision、write scope | 跨 build/Attempt、悬空引用、越界写、stale base、占位符和“后续应产出”等未落地内容 |
+| 局部 Candidate Validator | 当前 scope 的真实内容 | 当前增量是否完成；必须指出字段路径和候选原文片段，不能只给模糊总分 |
+| Compare Validator | 成对候选与比较报告 | 比较是否公平、证据是否对称、差异是否真实、组合是否冲突 |
+| Compose 全局 Candidate Validator | 阶段二的完整渲染稿 | 叙事、重复、冲突、节奏、证据、人设和内容是否真正落到正文 |
+
+Validator 缺陷报告至少包含：`defect_code`、`criterion_id`、`scope_ref`、`observed_excerpt`、`evidence_refs`、`severity`、`invalidated_inputs`、`recommended_action_class`。Validator 只报告事实和建议动作类别，仍由 Planner 决定 repair、split、补取数、替换、比较或 block。
 
 ### 10.3 Root 整稿验收
 
@@ -707,6 +837,7 @@ Root Validator 必须针对完整正式候选，而不是最后一个局部结
 - Element 字段完整且与选题相关；
 - Paragraph—Element 关系有效；
 - 正式版本中不存在未接受候选的隐式内容；
+- 不存在占位符、元描述、“这里需要补充”“此处描述其存在”等看似完整但正文未实现的内容；
 - 构建摘要和计数与正式版本一致；
 - 下游可以按老版合同读取。
 
@@ -727,13 +858,13 @@ Validator 报告通过不自动结束 Mission；主 Agent 仍需确认该结果
 | Root 接受后要求修改正文 | 原 Mission 已完成且版本不可变 | 启动新 Mission 或独立业务修订运行 |
 | Root 已接受但旧输出发布/读回失败 | 框架完成不等于业务交付成功 | 不返回 success；按同一版本幂等重试发布并对账 |
 | 权限、资料或人工决定缺失 | 当前不可继续 | block 并记录解除条件 |
-| 用户停止 | 停止新增执行，不删除历史 | 保留候选、证据、验证和决定，允许续跑 |
+| 用户停止 | 停止新增执行，不删除历史 | 保留候选、证据、验证和决定；阶段一不支持 resume，阶段三完成 OwnerLease/recovery 后才受控续跑 |
 
 系统恢复时以当前任务状态、被接受结果和正式业务版本为依据，不通过猜测“最新子任务”或改写旧 Trace 恢复。已提交的 Attempt 从 Validation/Decision 继续；已开始但未提交的 Attempt 不续跑其模型上下文，而是按失败后重规划；升级前遗留的 RUNNING Attempt 若没有子结果绑定记录，按协议失败处理，绝不猜测输入。
 
-## 12. 一个完整、代码忠实的业务示例
+## 12. 一个三阶段业务示例与真实旧案例纠偏
 
-以下 ID 和文本为说明性示例，字段和能力形状来自老版代码；不声称是生产数据库记录。
+12.1–12.7 是说明性执行轨迹，字段和能力形状来自老版代码，不表示固定顺序；12.8 用真实 Run 454 暴露的旧流程问题说明新系统为何需要动态局部替代。
 
 ### 12.1 输入
 
@@ -783,7 +914,7 @@ Validator 报告通过不自动结束 Mission；主 Agent 仍需确认该结果
 3. 账号A的开场节奏需要账号历史模式证据；
 4. 两项证据通过后才能确定方向和开场结构。
 
-它不创建固定 Round，而是先创建“方向综合任务”，再把两个取数任务建成它的直接子任务：
+在阶段一能力边界内，它不创建固定 Round，而是先创建“方向综合任务”，再把本次确有必要的两个取数任务建成它的直接子任务：
 
 - 方向综合 Task：吸收被验证的研究结果，产出 `script_direction` 候选；
   - Task A：用 Decode Case 找账号A真实脚本中“预期—反转”的开场结构；
@@ -817,7 +948,7 @@ Creative Worker 形成方向候选：
 
 Validator 检查它是否覆盖选题关键点、是否符合账号模式、是否只采用已证实事实。通过后主 Agent 只作 ACCEPT Decision；Host 根据该决定，把同一 direction artifact 幂等提升为当前 `script_direction`，Planner 本身不调用业务写工具。
 
-随后主 Agent 创建结构任务，而不是再强制发散多路。Creative Worker 产出：
+进入阶段二后，主 Agent 不必固定先做完整结构。此例中外部案例已经给出强反差画面，因此它先创建“开场元素集”Task，同时只创建“开场→方法段”的局部 Structure Task；其余结构暂不展开。两个结果通过后再形成以下候选骨架：
 
 1. 一级段落：错误预期；
 2. 一级段落：现场反差；
@@ -883,7 +1014,7 @@ Validator 检查它是否覆盖选题关键点、是否符合账号模式、是
 
 ### 12.7 Root 整稿与最终输出
 
-在任务树中，更深层的证据已被方向/段落任务吸收，段落与元素结果又由一个 Root 直接子“整稿准备任务”统一组合。Root Worker 只消费这个已接受的直接子结果，形成一份完整正式候选。Root Validator 检查整张表后，主 Agent接受 Root；Host 随后只发布该 ACCEPT 绑定的同一版本，并以旧详情读回一致作为业务 `success` 门禁。
+在任务树中，更深层的证据已由 Compose 子树吸收，CandidatePortfolio Task 选择了通过全局验证的 StructuredScript。阶段三 Root Worker 不再改稿，只提交 RootDeliveryManifest，绑定 Direction、Portfolio、StructuredScript、输入闭包和旧详情 dry-run digest。Root Validator 检查 Manifest 指向的同一整张表后，主 Agent接受 Root；Host 随后只发布该 ACCEPT 直接绑定的 Manifest 所指向的 StructuredScript，并以旧详情读回一致作为业务 `success` 门禁。
 
 对业务消费者，输出仍是：
 
@@ -908,6 +1039,21 @@ Validator 检查它是否覆盖选题关键点、是否符合账号模式、是
 
 Task、Attempt、Validation、Decision 和 Trace 可用于解释这份脚本如何产生，但不要求下游拿它们拼装正式脚本。
 
+### 12.8 用真实 Run 454 说明动态局部替代
+
+上一代 Run 454 最终有 5 个 Paragraph、11 个 Element、13 条 Link，但过程先做两条整稿候选，再按固定第二轮补第 2–3、4–5 段；最终还出现了“此处描述其存在”这类未真正落地的占位表达。新系统对同类选题的预期轨迹是：
+
+1. 阶段一接受 Direction 与“毛驴效应/隐性亏损”定义证据，但不把方向当正式脚本；
+2. Planner 发现“心理学概念是否适合该账号”风险最高，先派 ElementSet/Decode 任务，不先画全稿；
+3. 命中案例后，只规划“概念冲突→个人经历”的局部 Structure Task；另一个 Worker 并行试写开场 Paragraph 原型；
+4. Validator 认为开场真实、但概念转折生硬，Planner 不重跑整稿，而是创建一个只改转折、输入钉死为旧开场 ACCEPT + 新概念证据的 Replacement Task；
+5. 中段写完后，Planner 才发现行动指引缺口，插入 Retrieval，再创建第 4–5 段的局部 Structure/Paragraph Task；
+6. Compose 渲染完整稿，确定性预检命中占位表达，返回 `REALIZATION_PLACEHOLDER` 和原文字段路径；因当前 Compose 已等待 Decision，Planner 通过受控 `SPLIT` 原子建立只改结尾的 Replacement Task（或先 REVISE 再规划），而不是接受一个“结构看似齐全”的空壳；
+7. 新结尾被 ACCEPT 的业务合同显式 supersede 旧结尾 Decision，Compose v2 在闭包内采用新结果；CandidatePortfolio 记录采用、淘汰和未解决项；
+8. 阶段二在 Portfolio 检查点保持 `partial`；阶段三才做 Root 整体验证、发布、旧详情回读与 `success`。
+
+这个案例中，探索顺序实际是“元素证据 → 局部脉络与开场并行 → 转折替代 → 中段 → 临时补取数 → 结尾修复”，正式采用顺序则由 Portfolio 显式记录。二者既不相同，也不由模块名称决定。
+
 ## 13. 业务团队如何基于现有框架构建
 
 ### 13.1 业务团队需要提供的五类装配
@@ -929,21 +1075,30 @@ Task、Attempt、Validation、Decision 和 Trace 可用于解释这份脚本如
 - 父任务只消费明确接受的直接子结果；
 - Validator 独立核验同一候选版本；
 - Validator 通过不自动完成，仍由主 Agent 决定；
-- 业务 Host 可以通过通用装配入口按需注入验证策略、确定性 Validator 和只读 Evidence Provider；全部注入项可选，旧框架调用保持兼容；
+- 业务 Host 可以通过通用装配入口按需注入验证策略、确定性 Validator、只读 Evidence Provider、角色运行配置和冻结角色 Prompt；全部注入项可选，旧框架调用保持兼容；
+- Planner 的框架合同只要求使用 preset 实际暴露的计划、检查、派发和决策工具，不再硬编码旧工具名；Level 2 压缩会保留当前有效的阶段 system policy；Trace 附件通过公开持久化协议读写，不依赖 FileStore 私有路径；
 - 整个 Mission 的任务、尝试、验证、决定和运行事件可以统一观察；
 - 可以按角色、任务、尝试、验证和操作关联实际运行过程。
 
-### 13.3 业务团队仍需完成的产品能力
+当前框架还有三个必须尊重的真实边界：一是只自动冻结直接子 Task 的 ACCEPT Decision；二是 completed Task 不能原地 REVISE、SPLIT 或 SUPERSEDE；三是同一个 Task 不能并行跑多个 Attempt，并行探索必须创建多个 Task。阶段二不需要把 Coordinator 改成任意 DAG，也没有修改 ACCEPT 冻结语义；但为冻结角色 Prompt、压缩后保留阶段 policy 和持久化多模态附件，`agent/` 已增加三个业务无关、全部可选的运行时接口。跨兄弟/历史 ACCEPT 和替代关系仍由 Host 的受控 Task 合同解决。
+
+### 13.3 阶段一及加固已经完成的业务能力
+
+- 三个旧输入入口：标准 start 与 from-topic-json 创建 ScriptBuildRecord；parse-topic-json 只解析预览；随后执行旧表关系校验和冻结 InputSnapshot；
+- Topic/Points/Composition/Relations/Sources、人设、Section Pattern、策略、实际 DB-first/file-fallback Prompt、模型与数据源 manifest 冻结；历史 partial 可只追加 InputSnapshot v2 补齐 Phase2 Prompt，并保留 v1→v2 lineage；
+- Planner、Direction Worker、四个 Retrieval Worker、两个 Validator preset 及严格工具白名单；
+- Pattern、Decode、External、Knowledge 与图片受控 Adapter；
+- Evidence/Direction Artifact 的 canonical JSON、digest、归属校验和不可变读取；
+- ValidationPolicy、确定性预检、EvidenceProvider、RoleRunConfigResolver 的真实装配；
+- Decode v1 fail→revise→v2 pass→ACCEPT、Direction ACCEPT、active direction 幂等投影；
+- Root `PHASE_ONE_CAPABILITY_BOUNDARY`、build=`partial`，且不写 Paragraph/Element/Link、Round/Branch/PlanStep、`branch_id=0` 或 `success`；
+- build-scoped Mission/Task/Artifact/Trace 安全 DTO、跨 build 隐藏 404、同进程 cooperative stop、Direction 崩溃重入 reconciler 和 durable TraceStore 自检。
+
+### 13.4 阶段二已经完成、阶段三仍需完成的产品能力
+
+阶段二已经实现结构化候选版本、`branch_id>0` 工作区、Paragraph/Element/Link 兼容写入、动态 TaskContract、显式 ACCEPT 导入、Active Frontier、替代/比较关系、运行预算、六类创作 Worker、四层 Candidate Validation、Compose 和唯一 CandidatePortfolio 边界。它只形成候选检查点，不写正式版本。
 
-- 老版输入适配与挂载关系校验；
-- 四类取数 Agent 和其他数据工具接入；
-- ScriptBuild 领域 ValidationPolicy、DeterministicValidator 和 EvidenceProvider 的实现与注入；
-- 结构化脚本候选版本与正式版本管理；
-- 旧写入工具的候选隔离与冲突规则；
-- ScriptBuildRecord、Paragraph、Element、Link 兼容输出；
-- 领域验收规则和账号/策略校验；
-- 被接受版本到正式读取结果的业务一致性；
-- 业务启动、停止、人工干预和结果查询入口。
+阶段三仍需实现 RootDeliveryManifest、Root Validator、正式 `branch_id=0` Publisher、旧详情 readback、最终 `success`、resume/recovery、跨进程 OwnerLease、统一 HTTP 幂等/错误合同和人工恢复入口。
 
 框架不会自动提供 Topic、Persona、Round、Branch、Paragraph、Element 或页面节点，也不会自动把旧 Branch 当成 Attempt。
 
@@ -967,42 +1122,88 @@ Task、Attempt、Validation、Decision 和 Trace 可用于解释这份脚本如
 
 ## 15. 分阶段产品落地
 
-### 阶段 0：冻结兼容合同
+### 阶段一（已完成）：输入、Root、方向和取数闭环
 
-- 用真实老版字段形成输入、输出和工具清单；
-- 明确 `branch_id=0` 正式读取语义；
-- 校正 base 计数、最终验收、候选冲突等旧缺陷；
-- 建立同一输入在新旧系统间的对照样本。
+阶段一已经把旧业务入口真正接到新 Agent 框架，而不是只做接口骨架：
 
-### 阶段 1：接入只读数据与取数 Agent
+1. **输入与身份**：标准 start 与 from-topic-json 创建 ScriptBuildRecord，parse-topic-json 只解析预览；校验 execution/topic build/topic/active/软删除关系；从 `personal_config.account_name` 解析账号。
+2. **不可变快照**：冻结 Topic、Points、Composition、Relations、Sources、人设点、Section Pattern、策略、标准 start 实际解析到的 DB-first/file-fallback preset Prompt、模型和数据源 manifest；相同 build+hash 幂等。历史 Phase1 partial 若缺 Phase2 Prompt，只追加合法 lineage 的 InputSnapshot v2，不改写 v1。
+3. **Agent 闭环**：`script_planner` 动态创建 Direction 与其直接 Retrieval 子任务；四类 Worker 只拥有对应取数工具；独立 Validator 对同一 Snapshot 报告；Planner 再作决定。
+4. **真实失败重规划**：测试覆盖 Decode v1 fail、Planner revise、v2 pass、ACCEPT；重放同一派发不产生第二个 Operation。
+5. **Direction 因果与投影**：Direction Attempt 只读创建时冻结的直接子 ACCEPT；Direction 只有 Validation passed 且 Planner ACCEPT 后才幂等写 publication、active direction 指针和旧 `script_direction`。
+6. **安全边界**：生产必须注入 Principal/Authorizer；读写数据库配置分离；外部请求执行 HTTPS allowlist、DNS/redirect 重验、私网拒绝和响应字节/图片限制；冻结图片通过受控附件通道向 Worker/Validator 提供同源字节并复核 MIME、大小和 digest；系统执行脱敏并禁止主动保存凭据。
+7. **可观察与停止**：提供 build-scoped Mission/Event/Task/Artifact/Trace REST 与 Trace WebSocket；对外只返回 bounded DTO，不泄漏 protected context、Operation request 或幂等缓存；stop 先持久化 `stopping`，再停 Operation/Trace，超时保持 stopping 并记录活动 Operation。
+8. **阶段收口**：Direction 闭环后 Root 只能 `BLOCK(PHASE_ONE_CAPABILITY_BOUNDARY)`，build=`partial`。阶段一没有 Paragraph/Element/Link、正文候选、`branch_id=0`、resume/recovery 或 `success`。
 
-- 接入 Topic、Persona、Strategy、脚本快照；
-- 接入四类专业取数能力和图片理解；
-- 通过框架通用装配入口注入 ScriptBuild 验证策略、确定性规则和只读证据 Provider；
-- 用独立取数任务验证“查询—证据—接受—后续消费”链路；
-- 不改变正式脚本输出。
+当前代码的实际持久化顺序是：Retrieval ACCEPT → Direction ACCEPT → Planner BLOCK Root → Runner 返回 → DirectionReconciler 幂等投影方向 → build=`partial`。因此 Root BLOCK 是阶段运行退出信号，`partial` 只有在方向投影成功后才写入；只有 durable `stopping` 已先写入时才禁止后续方向投影，若 Reconciler 先取得进程内 gate，则允许先完成投影再进入 stopping。
 
-### 阶段 2：接入结构化创作 Worker
+做完效果：业务可以用旧输入真实启动一条可审计的“输入→取数→验证→方向”链，方向可供后续阶段继续；`partial` 同步保存 checkpoint code、summary、trace ID 和结束时间，进入下一阶段时清除旧 checkpoint 并恢复 `running`。
 
-- 创作 Worker 使用旧段落、四列、元素和关系写入能力；
-- Host 自动从框架 Task 生成旧写工具所需的最小 `record_task_plan` 兼容清单，或先移除该旧门禁；不得让人工维护第二套计划；
-- 每次任务写候选版本，不直接污染正式结果；
-- Validator 可重读并核验同一候选；
-- 局部 repair/retry/revise 可保留旧版本。
+以下 Host 加固已经作为阶段二第 0 步完成，不需要业务方维护第二套框架：
 
-### 阶段 3：Root 整稿与兼容输出
+- Mission/snapshot/Task 改为稳定 DTO，隐藏 request fingerprint、command/idempotency 记录、工具参数和 protected context；
+- `partial` 持久化阶段 checkpoint，InputSnapshot 每次读取重算 canonical digest；
+- Decode 标记 `external_send`，on-demand 策略默认摘要并由合同钉死的 Snapshot 授权按需读取；
+- 图片由 raw Artifact 受控进入 Worker/Validator 的 durable Trace 附件，不传网络 URL；
+- Direction projection 支持 pending/failed/published 崩溃重入，stop 覆盖 running/partial/stopping/stopped/failed/success/缺 binding/timeout；
+- 标准 start 接入 DB-first/file-fallback Prompt 解析，历史 partial 通过只追加 Snapshot v2 补齐 Phase2 Prompt。
 
-- Root Worker 组合已接受结果；
-- Root Validator 覆盖完整正式候选；
-- 被验证的同一 staging 版本已通过旧读取规则预检，Root 接受后 Host 才幂等激活为 `branch_id=0` 的 ScriptBuildRecord + Paragraph + Element + Link，并用旧详情读回对账；
-- 下游不改接口即可读取新系统产物。
+HTTP 全局 `Idempotency-Key`、统一 stable-error middleware 和 WebSocket 长连接权限续验仍留在阶段三，不能由上述加固推导为已经完成。
 
-### 阶段 4：切换动态编排
+### 阶段二（已完成）：动态候选结构化创作
 
-- 取消固定 Round 和每轮强制 multipath；
-- 按缺口动态创建任务；
-- 只在有价值时发散候选；
-- 停止、恢复、阻塞和人工修订均以任务状态为依据。
+阶段二没有实现为“依次调用 Structure、Paragraph、Element”的流水线。Planner 持续生产、验证、比较和替换可组合的局部增量，最终冻结一份完整候选组合。
+
+#### 15.2.1 动态计划控制面
+
+- 引入第 7.1 节 Task 合同和受控 `plan_script_tasks`、`decide_script_task`、`inspect_script_plan`；
+- 阶段二不再向 Planner 开放可绕过业务合同的通用计划/决策工具；所有创建、替代、拆分和阶段 BLOCK 都经过 Host 门禁；
+- 新 Mission 从开始使用不写死阶段一终点的 Planner 角色合同；升级已有 Phase1 `partial` 时，Host 必须留下受信的新阶段策略版本与工具集时代，不能只靠一条普通消息让旧 Planner 忽略原边界；
+- 在 Root 下建立唯一 CandidatePortfolio 父 Task；其下建立一个或多个 Compose Task，局部探索位于 Compose 子树；Portfolio 自身只选择被接受整稿，不改正文；
+- 允许 Structure/Paragraph/ElementSet/Compare/Compose 按缺口任意先后、重复或局部化；
+- 显式导入历史/兄弟 ACCEPT，钉死 Decision ID、Artifact version、digest；
+- 新结果在被 ACCEPT 的 TaskContract/Artifact 中通过 `supersedes_decision_ids` 替代旧结果，不给通用 PlannerDecision 增加业务字段，也不修改历史 ACCEPT；
+- 计算候选闭包内 Active Frontier，检查替代环、scope 兼容、stale base、写范围重叠；
+- 设置总 Task、深度、候选数、Attempt、token、时间与无改善预算。
+- 阶段二边界只在唯一 Portfolio 已通过、已 ACCEPT、子树全部终态、无活动 Operation 且无 hard/critical 缺陷时允许；过早 BLOCK 必须被拒绝。
+
+#### 15.2.2 候选工作区和旧写能力
+
+- 仅对会写 Paragraph/Element/Link 候选正文的 Creative Attempt 分配独立 business version/`branch_id>0` 工作区，不能使用 `MAX(branch)+1`；Evidence、Compare、Portfolio、Validator 不伪造 branch；
+- 接入 Paragraph、四列/原子点、Element、Link 的旧写 Adapter，身份只来自 protected context；
+- `record_task_plan` 由 Host 根据当前 Task 幂等生成最小兼容投影，不成为第二套计划真相；
+- 限制 Adapter 只能改 Task 的 `write_scope`，并检查 base revision 与并发冲突；
+- repair、retry、revise、replacement 都产生新 Attempt 与新业务版本，旧版本不可覆盖。
+
+#### 15.2.3 Artifact 与验证
+
+- 增加不可变 ScriptTaskContract，以及 Structure、Paragraph、ElementSet、Comparison、StructuredScript、CandidatePortfolio Artifact schema；TaskContract 是执行前控制合同，不伪装成 Attempt 产物；
+- freeze 后 canonical JSON、digest、内部引用和 ArtifactRef 不可变；
+- Validator 采用“确定性预检→局部 Candidate→成对 Compare→Compose 全局验证”四层结构；
+- 缺陷必须返回字段路径、原文片段、证据与建议动作类别；占位符和元描述属于硬失败；
+- 每个 Compose 是一个候选的串行整合点，局部 passed 不自动推导全局 passed；Portfolio 与 Compose 分属不同 Attempt/Artifact。
+
+#### 15.2.4 阶段二收口
+
+一个或多个 StructuredScript 通过全局 Candidate Validator 后，独立 Portfolio Worker 产生 CandidatePortfolio，Planner 再 ACCEPT 该 Portfolio。Portfolio 必须指定唯一 `adopted_structured_script_ref`，可另存对照候选；同时记录采用 Decision 集、superseded/暂缓/淘汰项、输入闭包、digest 和未解决缺陷。`hard|critical` 缺陷必须为零，只能保留可解释的非阻断 warning。随后 Root：
+
+```text
+BLOCK(PHASE_TWO_CANDIDATE_PORTFOLIO_READY)
+build = partial
+```
+
+做完效果：系统已经能动态产生和验证整稿候选，选定一份正式 adopted StructuredScript，并保留必要的对照候选与替代轨迹。局部可以多次换脉络、换段落、换元素且全程可追溯；但仍不写 `branch_id=0`、不返回 `success`。
+
+### 阶段三（待实现）：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 追溯。
+
+做完效果：旧下游继续读取唯一正式脚本；新系统同时提供动态规划、独立验证、可恢复发布和完整因果证据。阶段三结束才算整个产品合同完成。
 
 ## 16. 系统验收标准
 
@@ -1019,7 +1220,7 @@ Task、Attempt、Validation、Decision 和 Trace 可用于解释这份脚本如
 
 - 四类功能性取数 Agent 均有真实用例；
 - 简单只读查询和复杂专业取数两种模式均可用；
-- 图片需要时可被模型实际查看；
+- 阶段一图片可安全抓取并形成 raw Artifact；阶段二已补齐受控多模态输入，模型和 Validator 只能查看同一冻结图片字节；
 - 结构化段落、四列原子点、元素和关系均可创建、更新和删除；
 - Validator 能使用相同只读事实独立核验；
 - 旧评估维度已转成可检查的任务/整稿条件。
@@ -1038,6 +1239,8 @@ Task、Attempt、Validation、Decision 和 Trace 可用于解释这份脚本如
 - 没有固定 Round 门禁；
 - 没有每轮必须多路的门禁；
 - 每个任务都能说明当前缺口和验收条件；
+- Task 粒度由 scope、输入、增量和验收决定，不由 Structure/Paragraph/Element 模块名决定；
+- 探索允许元素优先、段落优先、局部结构优先或中途补取数，正式采用只看显式 Decision/Artifact 闭包；
 - 失败后能区分 repair、retry、revise、split、block 和 supersede；
 - 同一 TaskSpec 最多一次 repair，达到全局尝试/时长/无改善护栏时能确定性收口；
 - 父任务使用的是明确被接受、固定版本的子结果；
@@ -1046,18 +1249,29 @@ Task、Attempt、Validation、Decision 和 Trace 可用于解释这份脚本如
 
 ### 16.5 必测黑盒场景
 
+阶段一现有门禁：
+
 1. 使用同一老版选题、人设和策略输入启动 Mission；
-2. Decode 取数 v1 证据不足，Validator 不通过；
-3. 主 Agent 修订取数任务，v2 通过并接受；
-4. 创作方向在接受前因新证据发生修订；若已接受，则建立新的纠偏/综合任务；
-5. 局部 Worker 使用固定的已接受取数结果写候选；
-6. Validator 发现一个无来源元素，只返修该局部；
-7. Root 更深层结果先由直接父任务吸收，Root Worker 只按冻结的直接子 ACCEPT 结果写出完整脚本；
-8. Root Validator 核验同一版本，主 Agent 接受；
-9. Host 对同一版本幂等发布；模拟首次发布失败时不得返回 success，恢复后读回一致；
-10. 消费方只通过业务入口读取旧格式正式输出及兼容辅助字段；
-11. 能从正式 Paragraph/Element 追溯到采用决定、执行、验证和证据；
-12. 新的 Mission 观测响应与正式脚本对象不新增 Round、Branch、Workflow 或页面节点；旧详情的 `build_workflow` 兼容字段仍按第 3.6 节保留。
+2. Decode v1 证据不足，Validator failed；Planner revise 后 v2 passed 并 ACCEPT；
+3. Direction 只读取创建 Attempt 时冻结的直接子 ACCEPT；通过并接受后幂等投影；
+4. Root objective revise 后只在 `PHASE_ONE_CAPABILITY_BOUNDARY` BLOCK，build=`partial`；全程没有正文写入、branch0 或 success；
+5. stop 成功、超时、重复 stop 与 stopping 后禁止 Direction publication；现有测试覆盖 build 授权、Repository 跨 build Artifact、WS 未认证/Origin，完整 API 层跨 build Artifact/child Trace/WS 矩阵列入加固门禁。
+
+阶段二新增门禁：
+
+6. 参数化真实 Runner/MissionService 分别覆盖 Element-first、Paragraph-first、局部 Structure-first，三种轨迹都经过真实 Worker、受控工具、业务 Artifact 和独立 Validator，且探索顺序、完成顺序与正式 `compose_order` 相互独立；另一条真实全流程覆盖 Compose v1 placeholder failed→SPLIT replacement→replacement 直系 Retrieval/Evidence→A/B Compare→Compose v2→Portfolio；历史 partial 还通过真实 SQL/FileStore 与 HTTP advance 验证 Snapshot v1→v2、同 Root 和崩溃安全重入；
+7. 同一种 Structure/ElementSet Task 可针对不同 scope 多次创建，且总预算、深度和写范围生效；
+8. 已 ACCEPT 结果不被重开；Replacement Task 显式导入旧 Decision 与新证据，被接受的业务合同声明 supersedes，环和跨 build 引用被拒绝；
+9. 两个并行 Task 写范围重叠时 Compose 拒绝静默覆盖；有显式 Compare/替代关系时可确定性组合；
+10. Validator 发现无来源元素、stale base、悬空 Link 和“此处描述其存在”占位符，只返回精确 defect；Planner 分别选择补证、replacement、repair 或 block；
+11. CandidatePortfolio 重放幂等，记录完整采用闭包；Root 只在 `PHASE_TWO_CANDIDATE_PORTFOLIO_READY` BLOCK，仍无 branch0/success。
+
+阶段三新增门禁：
+
+12. Root 只消费已接受 Portfolio，Root Validator 核验同一 RootDeliveryManifest 及其绑定的 frozen StructuredScript；
+13. 首次发布失败不得 success；恢复后只重试同一 Root ACCEPT 绑定的同一 Manifest/StructuredScript，旧详情回读 digest 一致后才 success；
+14. 消费方通过旧业务入口读取 Paragraph/Element/Link 和兼容辅助字段，并能反向追溯采用 Decision、Attempt、Validation、Artifact 和 Evidence；
+15. 进程重启、OwnerLease 竞争、遗留 RUNNING Attempt、stop/finalize 竞态均不猜测“latest”、不重复模型执行、不发布未验证内容。
 
 ## 17. 明确不做
 
@@ -1080,7 +1294,7 @@ Task、Attempt、Validation、Decision 和 Trace 可用于解释这份脚本如
 1. 老版输入进，新版仍产出老版脚本表。
 2. 旧能力可复用，旧固定编排不照搬。
 3. 下一步由主 Agent 根据缺口和验证结果决定。
-4. 复杂取数是可独立验收的专业任务，简单查询是只读工具。
+4. 复杂取数是可独立验收的专业任务；创作 Worker 只做冻结范围内的局部只读，Validator 需要新数据时返回缺口由 Planner 建 Retrieval Task。
 5. Worker 产候选，Validator 验同一版本，主 Agent 作决定。
 6. 候选必须隔离，正式结果必须唯一。
 7. 先证据后创作；事实正确与表达质量分开验证。
@@ -1200,7 +1414,7 @@ Task、Attempt、Validation、Decision 和 Trace 可用于解释这份脚本如
 - 老运行时允许两者通过通用 `agent` 委派四类 `retrieve_data_*` 做补充核验；
 - 两者都不拥有正式写稿和最终接纳权。
 
-新系统保留这四类检索能力，但不照搬“Implementer/Evaluator 自行递归派生业务 Agent”的控制结构：复杂检索由主 Agent 建立一层专业任务，简单查询以只读工具提供。
+新系统保留这四类检索能力，但不照搬“Implementer/Evaluator 自行递归派生业务 Agent”的控制结构：复杂检索由主 Agent 建立一层专业任务；创作 Worker 的简单查询只限已冻结范围，Validator 发现新数据缺口时必须返回 Planner 新建 Retrieval Task。
 
 角色白名单证据：`script_build_tool_runtime.py:24-140`。