# 执行编排与分层读取

适用于多职责、存在依赖或需要续接的规格。合同指必须遵守的完整行为与接口约定；宿主指实际运行会话的工具。在[必要前置](../SKILL.md#0-必要前置完成后才编写-spec)完成后，按本参考将产品方案组织为可承接的执行输入。

## 1. 先确定每类信息放在哪里

如果规格短小、只有单一职责、无需跨会话交接，而且宿主能够可靠处理全部必要材料，就保持单文件。多个领域的完整合同使某个职责必须读入大量无关内容时，按完整业务能力与共享接口拆分，不按固定字数或目录数量拆分。

- **根规格**须完整说明本轮全部行为变化、保留保证、共同边界、来源版本、能力采用及全部验收总览，不得仅保留链接。详细条件在唯一权威正文中完整维护；根文件与必要正文共同构成完整规格，仅根文件承载规格身份与生命周期。
- **公共执行计划**保存任务索引、依赖关系、共享资源、验证批次、唯一产品状态与恢复位置；各职责的完整说明放在任务文件中，属于同一计划。实际宿主配置与当次工作方式记录在计划中。规格保留合同级验证要求，计划通过引用方式使用，不复制测试集合。
- **独立启动单**提供可直接复制的提示，明确产品目标、职责范围、首个动作、相关操作边界与完成条件，并依次指向根规格与公共计划。历史记录、编写过程与选型理由不混入启动正文。

优先引用已评审的需求、场景与设计。若现有正文夹带大量无关内容，无法通过整文件读取满足职责需求，方可按完整语义在原文位置进行拆分，并同步更新现行引用、身份标识与历史去向；禁止同时维护一份摘录合同。

上述多文件交付方式适用于主技能第4节规定的整体生成或重构。沿用项目原有文件名，每个确需独立承接的职责对应一份任务文件，不按命令、字段或每次重试拆分文件。任务表不能替代任务文件，角色说明不能替代启动提示；启动单与计划不将全部任务与领域正文列为首次必读内容。

只读请求仅报告缺口。用户明确限定单文件时，在允许范围内保留完整启动、公共计划与任务章节，说明物理分层尚未完成，不私自新建附件。局部修改仅处理相关内容，不声称整体重构完成；“最小改动”、已有未提交修改或草稿状态本身不构成例外依据。

合同、状态、能力采用与测试清单各自保持唯一来源。产品约束写入规格，当次操作授权与工作选择沿用用户及项目约定。

## 2. 任务说明要能直接委派

每份任务文件必须包含以下内容，可以用短段或列表表达，不强制八列表格。覆盖计划中所有需要独立承接的职责，包括已有的前置事实核实、实现、审阅、发布和真实消费验证；不要为本来没有的阶段新造任务：

1. **结果与归属**：对应哪个用户结果或验收，谁是下游消费者；源文件与必要派生物分别由谁负责。
2. **启动条件**：前置合同、输入、运行环境及共享资源何时满足。按依赖结果判断，不按编号或估计时间自动启动。
3. **执行配置**：职责所需的高／中／低强度、选择依据及允许调整范围。未指定宿主时不写具体模型、别名或 API 推理参数；用户指定宿主或模型后再据其有效配置细化，委派前记录实际映射。
4. **输入与披露**：启动必读、执行前必读、条件读取、默认不加载的材料；安全边界与必要合同不能降为可选。
5. **产品工作与边界**：依据需求和设计说明本次实现涉及的源文件、派生物、外部对象和已选公共入口。对与本次工作确有关系、但不在修改范围内的对象，说明具体边界及依据。
6. **输出与交接**：实际产物、关键证据位置、交给哪个既有任务；不能只返回总结或模型自报通过。
7. **验证安排**：既有聚焦入口、直接业务场景、生成前提、共享资源和批末门禁。沿用测试性能技能，不为任务说明另造 runner。
8. **回交条件**：何种缺口由原职责纠正，何种变化须主会话裁决或用户确认。

职责强度按任务歧义和失败代价选择，不按文件数：高强度用于复杂语义、合同或安全裁决；中强度用于边界明确的实现和集成；低强度用于机械检查、小改稿及定位。它表示所需的综合能力与推理投入，不是某个宿主的 `effort` 参数；不能把较弱模型的高推理参数直接等同于高强度职责。主会话负责范围裁决；实现职责不能同时改变验收并给自己最终批准。独立审阅的能力按适用规则确定，不把多模型投票作为默认步骤。

根据实际承接方式落实执行配置。已有用户选择时沿用其宿主与模型；未指定时只写职责能力要求，在派发前将实际可见配置记入同一计划。实现与独立审阅由不同职责承担。

### 2.1 启动提示与任务交接

启动单先说明本次产品结果、首个动作、职责和完成条件。执行范围以本次用户要求及当前适用的用户、项目约定为依据，写清相关对象、动作和适用阶段。产品需要保证的行为与接口写入规格；本轮选择的工作方式和操作范围写入公共计划。启动单只摘录影响当前启动与执行的内容。

按本轮实际分工说明主会话、实现者和独立审阅者分别负责什么；主会话直接实现或委派时，均有不同职责的独立审阅。任务说明覆盖完整实现、必要自测、集中返工及回交，不按每条命令分派。

输入或共享资源尚不满足时，写明具体缺口及受影响任务。命令、参数和环境错误由当前职责修正后继续执行；范围或业务决定发生变化时回到对应规格裁决。

启动检查只是执行的首步。完成条件对应产品结果与验收，暂停位置对应真实缺口。产品执行跨会话接续时，在唯一计划保留当前产品任务、来源版本、未完成项及下一动作。

## 3. 规定读取时机，不扩大上下文

每份任务明确区分启动必读、执行前必读、条件读取和默认不加载的材料，无条件材料时写“无”。读取范围覆盖当前决策所需的完整合同，不强制要求启动时加载全部领域与历史。

### 3.1 作者逐段核实并组织完整规格

作者首先依据原始要求与最新裁决确定全部范围，再按完整业务单元核实必要正文、关系和适用评审。在四项判断未完成或前置条件不足时，不得命名或交付 SPEC，仍须遵循[必要前置](../SKILL.md#0-必要前置完成后才编写-spec)流程；一个单元完成不代表全部前置完成。

先明确共同边界与跨领域接口，再依次处理各单元。表达模型每次获取当前原始材料、审核后的整体结构、必要合同及已接受前文中的相关定义。更早内容的摘要仅用于导航与衔接，判断依赖或冲突时必须回读原文；候选内容经主控接受后方可传递给后续环节。固定表达资源的完整覆盖与全文核对仍需满足，不因分段而更改资源或另建调用器。

### 3.2 主会话与实现职责按阶段补读

主会话启动时掌握适用纪律、整项目标、全部验收总览、项目与授权边界、能力采用、依赖关系及当前状态。进入具体任务、裁决接口或最终核收前，再读取相关完整领域条件与原始证据。

实现者完整读取自身任务、直接验收项、适用边界、上下游接口、所选Skill及其必读引用，再读待改实现、直接调用方和最近测试。不默认继承主会话全部历史或其他实现任务材料。决定跨领域行为前，必须补读双方必要原文；类型、安全、兼容与失败语义不得等到出错后才读。

### 3.3 独立审阅逐段覆盖，最后检查跨段关系

独立审阅者从原始要求重新确认范围，主动查找作者遗漏的必要来源，在同一稳定、可核对的正文版本上逐段读取全部现行内容及必要来源和证据。已有审阅报告记录实际覆盖位置、来源版本、发现与未读内容，不另建账本。摘要、作者索引、前置专业评审和根文件标记通过均不能代替完整审阅；仅读部分时只给出局部结论。

分段完成后，集中核对跨段接口、依赖、共享写入、正常与异常流程、兼容要求、删除与重命名，以及全部验收的承接位置。删除与重命名分别按[规格修改与审阅方法](openspec-methods.md)检查。审阅期间正文发生变化时，复核受影响段落与跨段约束；输入未变的有效观察方可沿用。版本依据复用现有Git引用、工作树基线和评审快照，不另建冻结系统。

### 3.4 沿必读引用检查实际读集

索引仅用于定位，列出文件不自动要求整份加载；被选合同依赖的类型、兼容、安全与失败语义仍须完整读取。沿必读引用继续展开，识别短入口仍引入无关源码、其他领域全文或全部报告的情况，修正至具体任务入口，不将筛选责任留给执行者猜测。图工具输出也仅选取当前判断所需内容；所选Skill的完整指令与必读引用保持有效。

章节链接不保证局部加载。未指定宿主时，须确保各职责能通过整文件读取取得完整必要合同。只有用户限定单文件，或已确认所选宿主支持范围读取时，才保留长文中的局部合同：提供文件、标题起止及必要关联，先定位标题，再读至同级或更高层标题之前，不凭旧行号截取。这不替代常规多职责交付的独立启动单、计划和任务文件。

历史与现行指令混放时，仅迁移本轮受影响输入，将历史移至独立文件，现行入口保留定位。正文按完整语义组织，不把字段、异常或单个验收拆成失去上下文的碎片。共享合同保持一份正文，任务不复制合同或进度；迁移后更新链接，明确保留基线的适用章节和读取时机，不顺手重排无关历史。

改稿前后分别顺读主会话启动、代表实现、作者和独立审阅四类路径，列明当阶段选中内容及传递引用，去重比较。行数、字符数或已有词元统计仅用于注明范围的观察；未计入的纪律、Skill和源码须说明。无真实测量不声称词元、速度或指令遵循改善，独立审阅的累计读量也不必减少。无关历史、全量日志、其他批次研究和缓存默认不加载，出现具体定位需要时再读。

### 3.5 接续与能力不足时保留真实缺口

分次读取仍在同一会话中累积材料。必要内容无法可靠处理时，使用宿主已有接续、压缩或委派方式，在唯一计划中保留授权、共同边界、当前单元、来源版本、未决项与下一动作。接续者回读相应权威正文，核对变化并复验受影响观察。实际继承全部历史时说明负载限制，不能宣称已完成隔离；文档分层本身不控制读写权限。

分别说明三类真实缺口：

- 用户限定单文件而宿主无法可靠局部读取时，说明物理分层与读取限制；
- 必要附件缺失时，指出路径、未覆盖要求与受影响任务；
- 一个不可再拆的完整合同仍超出能力时，仅暂停依赖它的判断，报告实际限制，不截断后报通过。

根文件标记只校验根文件，不能证明附件或全文已就绪。固定表达资源无法处理必要完整输入时，向上游报告具体限制，不修改固定资源或自建调用器。

## 4. 主路径固定，例外按条件发生

固定任务依赖和汇合点、互斥写集、共享资源串行边界、必要生成责任、底层能力采用、测试策略与验收。互不依赖的只读观察可以提前，不把“最多若干执行者”当作应始终填满的配额。

允许执行者在写集和合同内调整函数实现、补读直接证据、修正编排错误。重试不要求预建节点，但必须按适用纪律处理连续失败，并保留受影响的必要复验。

追加评审只在已定义风险或用户要求出现时启动；范围、合同、安全、共享机制或权限变化回到对应权威位置裁决。相同事实不重复评审，不把动态节点扩成第二套任务树。

## 5. 整理完成后的检查

先逐项核对实际交付物：独立启动单有可直接复制的正文，公共计划有唯一状态和全量任务索引，每个独立委派职责都有任务文件及第 2 节要求的内容。现有文件满足时直接复用；缺项则补齐，受用户明确范围限制时报告缺口。未决事实可以阻断任务就绪，但不能把缺失文档包装成“等待实施再补”。

检查每项原验收仍有人负责，任务输出能成为下游输入，没有依赖环或共享写冲突；公共计划中的当前任务、进度和恢复位置对应产品实施，启动单指向首项产品工作。影响实现方式的能力事实尚不明确时，先补足事实并确定实现决定，再委派相关产品任务。

从实际入口完整走查一次：从启动单进入首项产品任务，沿必要引用核对实现与独立审阅是否各自取得完整输入、明确输出和完成条件。输入有缺口时给出对应位置；输入已具备时能继续推进产品工作。

最终答复列出实际启动入口、公共计划和任务文件索引，并简述一条实现路径与一条审阅路径的实际必读文件及补读条件。全量任务覆盖核对与代表性路径冷读在同一批次完成，不逐任务另开评审。风格、链接、制品关系或版本锁检查通过，都不能代替这项交付核对；不新建检查系统或产品测试。

生成或优化 SPEC 时，再按[上游能力正向匹配](capability-matching.md)第 6 节完成双向语义覆盖核对，并采用该节唯一的处置表。

交付核对关注本次任务是否能够被独立承接；冷读结论与真实宿主执行结果分别记录。