task-pipeline

task-pipeline

自包含的编排器。让任务通过设有门禁的阶段，每个阶段都包含自己的内置准则；无需配套插件。只有通过门禁，才会进入下一阶段；整个运行只使用一个模型，并在开始前确认。

先按比例处理，再自主运行。 阶段 0 首先是差距检查，而非访谈：根据请求、文件和收集到的信息构建需求说明，仅当来源无法回答某个重大未知事项时才提问。完整的需求说明不会产生任何初始问题；请求或项目已经作出的决定都会被记录，不会重新协商。如果变更也很小（风险等级为 R1，涉及文件不超过五个，没有公开契约、没有面向用户的变更，也不涉及部署），运行会默认采用捷径，并用一句话说明：在运行记录中记录需求说明、构建并运行测试、进行一次验证、整理文档并交接，只有发现新经验时才记录复盘条目（references/stage-00-intake.md → 阶段 1d，其中也列出了让跳过的阶段重新启用的触发条件）。较大的任务则运行完整流程；对于仍然存在的差距，访谈会作为一批问题，预先解决阶段 1→10 中的事项：阶段 0 跳过的每个重大问题，之后都会作为中断再次提出。

配置契约：pipeline.schema.json。 管道是有序的阶段列表，每个阶段都包含 skills[] 和 gate {type, check}；该 schema 不限定阶段、技能或门禁分配。 pipeline.example.json 是本插件默认流程的复制并改写示例（阶段 0 加上以下阶段 1→10），并包含可选的 release 块。

两层，且只有一层可替换。 KERNEL（内核）是任意管道中的每个工作单元都包含的内容：其范围、证据、依赖项和一个恢复点。内核保持不变。**PROFILE（配置档案）**是阶段列表，项目会整体替换它。阶段编号属于所选配置档案，而非内核：最简三阶段配置档案没有“阶段 7”；以全局阶段编号为键的规则，针对的是默认配置档案。自定义配置档案可以删除阶段，但不能删除任何内核字段。每个门禁都有一个类型：auto（编排器验证 check）、judgment（由指定的评判者作出裁定，并记录为判断，绝不记录为测量；references/gates.md → 判断门禁）或 manual（明确放行）。**默认配置档案中的门禁均为 auto；只有当操作员的 pipeline.json 指定时，门禁才是 manual；授予操作员的常设授权若明确列出该行为，也算作放行。**在 skills[] 中，task-pipeline:<name> 表示此技能自身的准则（references/<name>.md），host:<name> 表示宿主项目自身的命令（references/conventions.md）。

前置条件：无

每个阶段的规范都随此技能一同提供，没有任何阶段会因安装而受阻： 阶段 1 会回退到网页搜索；wiki 和代码图谱是推荐项。 各参考文档负责哪些阶段： references/doctrine-map.md。优先级：使用 CUSTOM 配置时，以内核为准；references/stages.md 是默认配置的规范门槛集合；内核对所有配置均具有规范效力；阶段 2/4/5/6 的其他技能集合见 references/companion-skills.md。

super-ux 是任何面向用户任务的首选提供方，而且第 3 阶段的门槛检查的是产物，而不是软件包：由 super-ux、等效提供方或 references/companion-skills.md 中的内联回退方案提供的有效场景，只要覆盖了变更，就能通过检查。如果没有任何场景产物，门槛就无法通过；缺少工具时，应报告未执行的具名检查，而不是将任务报告为失败。

内置了 grill（references/grill.md），用于生成 REQ 主干：将请求整理为可寻址列表，每一行都注明验证方式、追踪到第 3–5 阶段的内容，以及第 10 阶段负责逐一核算的内容。先收集，再提问 （references/knowledge-sources.md）：阶段 0 提取项目已有的知识，编写来源台账，并据此核对每个答案；操作者的优先级高于文档，但必须明确说明。

**三个产物收尾一次运行，并彼此汇合：**阶段 9 同步文档、wiki 和代码图谱；如果存在图谱，图谱与文档的差异检查就是它们共同的门槛（references/knowledge-graph.md）。文档是有门槛要求的交付物（references/documentation.md）：docs/DOCMAP.md、任意阶段的 Doc Loop、第 9 阶段的传播矩阵，以及作为带退出码命令的“文档已同步”检查。

一次运行的经验会指导下一次运行，列表应保持简短 （references/retrospective.md）。第 10 阶段的最后操作，必须严格按此顺序，顺序至关重要：先为运行盖章，再精简，然后写入条目（references/learned.md 规则 21）。阶段 0 完整读取的基础内容（常设指令和运行印记）有字节预算：scripts/retro_budget.py check 会在阶段 0 输出字节数和字节数/4 的 Token 数；超出预算时，第 10 阶段的门槛检查会失败，直到 migrate 将叙述内容原样迁移至归档，并通过哈希验证。

运行方式

1. 用一行重述任务，从 0 开始跟踪每个阶段（使用主机任务工具或文字清单，以便恢复），然后只输出一次预检区块：模型决策（references/model-tiering.md：建议采用能力最强的模型作为建议，由操作者确认或覆盖，所选模型由计划、阶段和子 Agent 原样继承）、运行模式（pipeline.json → run.loop、references/continuity.md；若未设置则关闭，且该模式绝不会合并 manual 门禁），以及可选配套项：用于 UI 任务的 super-ux、context7、wiki-update、graphify（references/companion-skills.md）。
2. 运行阶段 0。 先收集，再进行缺口检查，最后按比例作出决策（references/stage-00-intake.md）。从 super-ux 进入（已存在经过验证的 docs/ux/ 链路或 docs/ux/plans/… 修复计划）？检查 /ux-lint 是否通过，用一行确认范围，然后跳到第一个有实际工作的阶段。
3. 按预检时确认的模型逐阶段推进；不要每个阶段都重新询问。所选配置文件只在预检时编译一次，且只运行其中声明的阶段和门禁：包含三个阶段的自定义配置文件就运行三个阶段，不会注入隐藏的阶段 0、7 或 10。自定义配置文件无法绕过的是内核：删减阶段不会删除证据门禁。如果某项未知的强制能力无法满足，编译就会被阻止：运行时缺少的 must_understand 能力将被拒绝，绝不会在悄然缺失该能力的情况下运行。这是平台而不是变更？ 阶段 2 将其拆分为模块（references/decomposition.md），阶段 3→10 按模块运行（references/stages.md → 程序循环）。要处理整个看板？ 使用 /task-pipeline waves（references/waves.md）。发布： 参阅 references/iteration.md；发现问题时立即分流，迭代在达到终点时停止：制品上的退出检查全部通过，且一轮检查未发现新的阻断性问题（R3 或旗舰节点需两轮），或者预算用尽（references/finish-line.md）。
4. 除非阶段门禁通过，否则不要推进（references/stages.md）。对于 auto，自行验证 check；对于 judgment，将裁定记录为判断；对于 manual，引用操作者的放行指示，或授权执行此操作的常设授权。循环会停止： R1 节点通过一次盲测分级即可认证，且一轮检查无新问题即结束节点，除非该节点为 R3 或旗舰节点；达到认证上限时，保留节点及其证据并继续推进；输入未变时不得重新运行任何分级；评审循环最多三轮（references/certification.md、references/loop-guard.md）。
5. 跨阶段规则在任何阶段均生效（文档循环、循环防护、审计退出条件、终点、冻结的 REQ 列表、结转台账，以及证据的认定标准）；每个门禁都会针对全部八类残留项输出 holds: N；只要本次运行的残留项仍未解决，阶段 10 就不会关闭（references/residue.md）。详情请参阅 references/gates.md → 跨阶段规则，适用于每个阶段。

阅读内容及其时机

开始时只阅读此文件；下方的阶段表就是阶段索引。每个阶段的详细内容应在该阶段开始时阅读（references/stages.md 会逐节指引；切勿预先加载所有详细内容）。其余内容在触发时加载：

参考资料	阅读时机
references/grill.md	差距检查发现存在重大未知项时
references/knowledge-sources.md	某个来源需要查阅其清单行以外的内容时：代码图谱、维基、经验库、传入的声明或过时的行
references/companion-skills.md	用户可见任务（提供方规则）、替换后的技能集或缺少配套项时
references/continuity.md	run.loop 已启用、收到上下文预算信号或运行恢复时
references/model-tiering.md	操作员覆盖模型或阶段映射不同时
references/gates.md	编写或更改检查、对关卡的判定存在争议或运行判定关卡时

阶段（references/stages.md 中的门槛与路线）

所有阶段均使用预检时确认的同一个模型。

#	阶段	门槛	类型
0	接收核查 — 必需	写好来源台账并包含其 Contradictions: 行；回答 docs/DOCMAP.md 中的问题，并根据实际构建情况核对意图；完整阅读回顾底线并打印其字节数；完成自主性检查；UI：记录 surface_class；锁定并确认简报	自动
1	文档研读	合约以获取的文档为依据	自动
2	头脑风暴与拆解	设计已获批准；记录 UI 判定；回答每项 REQ；队列是一项制品——工作图验证通过，且其覆盖范围中没有未满足的 REQ；平台：模块映射已获批准	自动
3	规格说明	已提交并评审；UI：链路已验证、检查器无错误、场景和 SCR- 均已追踪；COPY 和 VISUAL 是 UX 之后的并行层，若两者均已执行，则记录其收敛检查；VISUAL 由其主管记录进行检查	自动
4	计划	已具备并行执行条件，每项任务均有 DoD；每条边都注明其承载内容——运行伪边测试并计算其 Edges: 数量；scripts/plan_audit.py 检查无误——每个有效节点的任务包都能通过冷读者检验，且没有两个无顺序关系的节点编辑同一文件	自动
5	开发	任务均已完成（DONE），每项任务的 TDD 均通过，分支已按简报集成；扇出分组在首个工作树落地前，针对其所有差异共同进行一次收敛检查	自动
6	测试	完整测试套件通过；新增和变更代码均有覆盖；每项新增检查均双向探测，并断言其退出代码；Web 界面须在浏览器中检查，而非在差异中检查——仅在已连接浏览器通道时适用；若无浏览器通道，则记录较弱的声明；受门槛限制的界面通过接触表检查	自动
7	检查与部署	部署前检查无误且测试套件通过；部署须获准，或有简报中的特定长期授权	自动
8	部署后	干净启动，或如实报告降级情况；已部署的 Web 目标须打开查看，而非用 curl 请求——200 只能证明服务器已响应，不能证明其他任何内容；若未连接浏览器通道，则记录较弱的声明	自动
9	文档与 wiki	更新阶段 0 来源台账中的每一条过时记录；针对本次运行产生的每种变更类型，逐项检查传播矩阵；文档门槛通过，并打印其防回退阈值；文档、wiki 和代码图谱已同步，并相互核对	自动
10	验收	已执行阶梯检查，并将缺项记为 REQ 行；每项 REQ 均有来自曾经失败过的检查的证据；台账中没有未解决的记录；每个代码库均干净、已推送且已指明位置；已写好交接说明并归还环境；回顾最后撰写，遵循顺序且不超过字节预算	自动

上述每个门槛均为简版；完整版见 references/stages.md。CUSTOM 配置文件使用其自行声明的 规范；数字 ID 相同并不意味着采用默认细节。涉及多个代码库？ 子模块是否完成，以其父级的说明为准： references/acceptance.md → 多个代码库组成的项目。

模型：在预检时询问一次

建议使用当前可用的推理能力最强的模型，其层级在运行时确定， 绝不硬编码 ID（references/model-tiering.md → Mechanic）。将答案记入 简报；阶段 5 的子 Agent 固定使用该模型。

降级处理

• 没有 python3 → 工作图操作和预置门槛脚本无法运行：队列降级为文字计划，门槛降级为检查清单——必须明确说明，绝不可默默处理。
• 没有 git → 无法隔离工作树，也无法提供基于提交的证据：运行记录改为较弱的声明，而非假装达到了更强的声明。
• 没有浏览器通道 → 通过阅读差异来验证 Web 界面，并在收尾记录这属于较弱的声明。

自带技能

以上阶段是示例流程。宿主将 pipeline.example.json 复制为 pipeline.json，定义自己的阶段（数量不限），将每个 skills[] 指向其 环境解析到的位置，设置每个 gate.type（auto/judgment/manual），并切换 自己的 release 块。pipeline.schema.json 是唯一的契约。

参考资料

大多数参考资料按阶段从 references/doctrine-map.md 路由。其余参考资料通过 正文路由：stages.md、learned.md（在规则有约束力时引用）以及 probing.md（来自 gates.md）。本文件旁边还有配置契约，以及这套工具的 任务／上下文契约：execution-packet.schema.json 和 execution-result.schema.json 及其示例；scripts/packet.py 可在无依赖的情况下验证这些内容（未知的强制版本、 缺少摘要的引用，或未绑定的决策都会被拒绝；过期结果会触发重新规划，而不会直接落地）。 scripts/context_packets.py compile|verify 会将审计报告映射到父任务：ID 由发现项 ID 派生，绝不按位置生成；任何无法映射的行都会阻止编译。

触发条件

描述是简短形式。完整触发词列表在 1.98.0 之前都包含在其中，现逐字移至此处， 仍会路由到此技能：

"当工作会更改代码仓库时使用——功能、修复、错误、重构、迁移、集成、重写、采用或加固；фича、фикс、баг、рефактор、миграция、интеграция、доработать、починить、внедрить、перевести——或有发现项要落入其中时：审计/аудит、排查错误/проверь ошибки、生产环境检查/проверь прод、PR 评审/ревью PR——或用户说“run this through the pipeline”/“прогони по конвейеру”、“the full cycle”/“полный цикл”、/task-pipeline 时。通过设有门禁的阶段运行重要任务：接收筛查、文档、头脑风暴、规格说明、计划、构建、测试、部署、部署后检查、文档/wiki、验收。“waves”/“волнами”/“release iteration”/“итерация релиза”会关闭看板；“checkup”/“чекап”会列出未确认的发布；“setup”会审查文档。不适用于：回答问题、解释、修正错别字、单行编辑、重命名、不会落地任何内容的侦察——说“no pipeline”/“без пайплайна”即可选择不使用流水线。"