plan

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Implementation Planning Skill

实现规划Skill

Overview

概述

Author the
## Decomposition
section of the one unified
docs/specs/
artifact
— granular, parallelizable tasks tracing to the
DR-N
requirements in the same document's
## Design & Rationale
section. There is no second file: traceability resolves within one doc. Ensures complete coverage through explicit, internal traceability. The artifact shape is owned by
references/spec-template.md
— author against it.
For a complete worked example, see
references/worked-example.md
.
编写统一
docs/specs/
工件
## Decomposition
(分解)章节——细化的、可并行执行的任务,需追溯至同一文档
## Design & Rationale
(设计与原理)部分中的DR-N需求。无需第二个文件:可追溯性在单个文档内解决。通过明确的内部可追溯性确保覆盖完整。工件格式由
references/spec-template.md
定义——需据此编写。
完整示例请参阅
references/worked-example.md

Triggers

触发条件

Activate this skill when:
  • User runs
    plan
    command
  • User wants to break a spec into tasks
  • A unified
    docs/specs/
    artifact's Design & Rationale section needs decomposition
  • User says "plan the implementation" or similar
  • Auto-chained from
    ideate
    after the Design & Rationale section is written
  • Run directly (no prior
    ideate
    ): at thin/standard depth, author the whole unified spec — light/standard Design & Rationale section plus Decomposition — in one pass
  • Auto-chained from plan-review with
    --revise
    flag (gaps found)
在以下场景激活此技能:
  • 用户运行
    plan
    命令
  • 用户希望将规格分解为任务
  • 统一
    docs/specs/
    工件的设计与原理章节需要分解
  • 用户说出"plan the implementation"(规划实现)或类似表述
  • 在设计与原理章节编写完成后,从
    ideate
    自动链式调用
  • 直接运行(无需先执行
    ideate
    ):以精简/标准深度编写完整的统一规格文档——包含精简/标准的设计与原理章节以及分解内容——一步完成
  • 从带有
    --revise
    标志的plan-review自动链式调用(发现漏洞)

Revision Mode (--revise flag)

修订模式(--revise标志)

When invoked with
--revise
, plan-review found gaps. Read
.planReview.gaps
from state, re-read the design, add tasks to address each gap, update the plan file, then clear gaps via
exarchos:exarchos_workflow
action: "update"
.
当使用
--revise
调用时,说明plan-review发现了漏洞。读取状态中的
.planReview.gaps
,重新读取设计内容,添加任务以解决每个漏洞,更新规划文件,然后通过
exarchos:exarchos_workflow
action: "update"
清除漏洞。

Revision Loop Guard

修订循环限制

Max revisions: 3 per plan.
After 3 failed revisions:
  1. Set
    planReview.revisionsExhausted = true
  2. Output: "Plan revision failed after 3 attempts. Design may be incomplete."
  3. Escalate: Suggest
    ideate --redesign
    to revisit design
MANDATORY: Before accepting any rationalization for skipping tests, planning, or TDD steps, consult
references/rationalization-refutation.md
. Every common excuse is catalogued with a counter-argument and the correct action.
最大修订次数:每个规划最多3次。
3次修订失败后:
  1. 设置
    planReview.revisionsExhausted = true
  2. 输出:"规划修订已尝试3次仍失败。设计可能不完整。"
  3. 升级处理:建议执行
    ideate --redesign
    重新审视设计
强制要求: 在接受任何跳过测试、规划或TDD步骤的理由之前,请查阅
references/rationalization-refutation.md
。所有常见借口均已分类记录,并配有反驳论据和正确操作指引。

The Verification Ladder

验证阶梯

Verification depth matches blast radius. The deeper rungs add tests, an adequacy kill-probe, and integration coverage — judged by outcome, test-after, not by a universal failing-test-first law. Each task gets the cheapest verification that still captures its risk:
Risk tierWhat it addsWhy
lowStatic analysis (typecheck + lint) sufficesA docs/config/rename-only edit has near-zero blast radius; a test ceremony is pure overhead.
mediumScoped tests + the
check_test_adequacy
kill-probe
The kill-probe recaptures test-first's one real guarantee — that a test can actually fail — at lower cost, judged test-after instead of mandating a failing test first on every commit.
highThe integration suite (and mutation-adequacy at the boundary) on top of mediumSchema/type/API/shared-contract surfaces span the codebase; here adequacy-judged coverage plus real-collaborator integration across the seam earns its cost.
The planner stamps each task's
riskTier
(and
boundaryTouching
); the classifier derives it from blast radius when the planner does not override. The dispatched implementer prompt and the gate sequence both scale off that stamp — so the verification effort is data-driven, not a blanket rule.
For a high-tier task, the discipline is outcome-based (write the behavior and its tests in whatever order is natural — test-after is fine):
  1. Cover the new/changed behavior with scoped tests that pin its contract
  2. Let the
    check_test_adequacy
    kill-probe prove the tests can actually fail (it reverts your source and asserts at least one test goes red)
  3. Add real-collaborator integration coverage across the seam
Verify high-tier test adequacy after implementation — the keeper gate (the test-FIRST ordering gate
check_tdd_compliance
was retired):
typescript
exarchos_orchestrate({
  action: "check_test_adequacy",
  featureId: "<featureId>",
  taskId: "<taskId>",
  branch: "feature/<name>",
  riskTier: "high"
})
  • passed: true
    — Reverting the task's source makes at least one new/changed test fail: the tests are not vacuous
  • passed: false
    — A test still passes against the reverted source; strengthen it
验证深度与影响范围相匹配。更深的层级会增加测试、充分性kill-probe和集成覆盖——基于结果,测试后评估,而非通用的测试优先规则。每个任务采用成本最低但仍能覆盖其风险的验证方式:
风险层级新增内容原因
仅需静态分析(类型检查+代码扫描)即可仅涉及文档/配置/重命名的修改影响范围几乎为零;测试流程纯粹是额外开销。
限定范围测试 +
check_test_adequacy
kill-probe
kill-probe以更低成本重现了测试优先的核心保障——即测试确实可以失败——采用测试后评估,而非强制每次提交都先编写失败测试。
在中等风险验证基础上增加集成测试套件(以及边界处的变异充分性测试)Schema/类型/API/共享契约层面的修改会影响整个代码库;此处基于充分性评估的覆盖加上跨边界的真实协作方集成测试是值得投入成本的。
规划器会为每个任务标记
riskTier
(风险层级)和
boundaryTouching
(是否涉及边界);若规划器未覆盖,分类器会根据影响范围推导得出。调度的实现者提示和 gate 序列均会根据该标记调整——因此验证工作是数据驱动的,而非统一规则。
对于高风险层级任务,遵循基于结果的原则(以自然顺序编写行为及其测试——测试后编写也可):
  1. 用限定范围测试覆盖新增/修改的行为,固定其契约
  2. check_test_adequacy
    kill-probe证明测试确实可以失败(它会还原你的源代码,并断言至少一个测试会失败)
  3. 添加跨边界的真实协作方集成覆盖
在实现后验证高风险层级测试的充分性——原测试优先顺序的gate
check_tdd_compliance
已被弃用:
typescript
exarchos_orchestrate({
  action: "check_test_adequacy",
  featureId: "<featureId>",
  taskId: "<taskId>",
  branch: "feature/<name>",
  riskTier: "high"
})
  • passed: true
    —— 还原任务源代码后,至少一个新增/修改的测试会失败:测试并非无效
  • passed: false
    —— 还原源代码后测试仍通过;需强化测试

Planning Process

规划流程

Step 1: Analyze the Design & Rationale section

步骤1:分析设计与原理章节

Read the unified spec's
## Design & Rationale
section thoroughly (if
ideate
ran, it is already written; otherwise author it at thin/standard depth now, per
references/spec-template.md
). From it, extract:
  • Problem Statement — Context (no tasks, but informs scope)
  • Chosen Approach — Architectural decisions to implement
  • Requirements (DR-N) — the provenance anchors every task must trace to
  • Technical Design — Core implementation requirements
  • Integration Points — Integration and glue code tasks
  • Open Questions — Decisions to resolve or explicitly defer
仔细阅读统一规格文档的
## Design & Rationale
章节(若已执行
ideate
,则该章节已编写完成;否则需根据
references/spec-template.md
以精简/标准深度编写)。从中提取:
  • 问题陈述 —— 背景信息(不包含任务,但用于明确范围)
  • 选定方案 —— 需实现的架构决策
  • 需求(DR-N) —— 每个任务必须追溯的来源锚点
  • 技术设计 —— 核心实现需求
  • 集成点 —— 集成和粘合代码任务
  • 待解决问题 —— 需解决或明确推迟的决策

Step 1.5: Spec Tracing (Required)

步骤1.5:规格追溯(必填)

Create a traceability matrix mapping
DR-N
requirements to planned tasks within the unified document. Consult
references/spec-tracing-guide.md
for the methodology and template.
Pre-populate the matrix using the traceability generator — pass the unified
docs/specs/
artifact as both
designFile
and
planFile
(DR-N is parsed from its
## Design & Rationale
region, tasks from its
## Decomposition
region — one file):
typescript
exarchos_orchestrate({
  action: "generate_traceability",
  designFile: "docs/specs/<date>-<feature>.md",
  planFile: "docs/specs/<date>-<feature>.md",
  outputFile: "docs/specs/<date>-<feature>-traceability.md"
})
  • passed: true
    — Matrix generated; review and fill in "Key Requirements" column
  • passed: false
    — Parse error; the spec may lack expected
    ##
    /
    ###
    headers
创建可追溯性矩阵,在统一文档内将DR-N需求映射至规划任务。 查阅
references/spec-tracing-guide.md
获取方法和模板。
预填充矩阵:使用可追溯性生成器——将统一的
docs/specs/
工件同时作为
designFile
planFile
传入(DR-N从其
## Design & Rationale
区域解析,任务从其
## Decomposition
区域解析——单个文件):
typescript
exarchos_orchestrate({
  action: "generate_traceability",
  designFile: "docs/specs/<date>-<feature>.md",
  planFile: "docs/specs/<date>-<feature>.md",
  outputFile: "docs/specs/<date>-<feature>-traceability.md"
})
  • passed: true
    —— 矩阵已生成;审阅并填写"关键需求"列
  • passed: false
    —— 解析错误;规格文档可能缺少预期的
    ##
    /
    ###
    标题

Step 2: Decompose into Tasks

步骤2:分解为任务

Each task follows the TDD format in
references/task-template.md
.
Granularity Guidelines:
  • Each task: 2-5 minutes of focused work
  • One test = one behavior
  • Prefer many small tasks over few large ones
Assign a
testingStrategy
to each task using
references/testing-strategy-guide.md
to control which verification techniques agents apply. Auto-determine
propertyTests
and
benchmarks
flags by matching each task's description and file paths against the category tables — do not leave these for the implementer to decide.
Task Ordering:
  1. Foundation first (types, interfaces, data structures)
  2. Core behaviors second
  3. Edge cases and error handling third
  4. Integration and glue code last
每个任务遵循
references/task-template.md
中的TDD格式。
粒度指南
  • 每个任务:2-5分钟的专注工作
  • 一个测试对应一个行为
  • 优先拆分为多个小任务,而非少量大任务
使用
references/testing-strategy-guide.md
为每个任务分配
testingStrategy
,以控制代理应用的验证技术。通过将每个任务的描述和文件路径与类别表匹配,自动确定
propertyTests
benchmarks
标志——勿将这些决策留给实现者。
任务顺序
  1. 基础任务优先(类型、接口、数据结构)
  2. 核心行为次之
  3. 边缘情况和错误处理第三
  4. 集成和粘合代码最后

Step 3: Identify Parallelization

步骤3:识别并行化机会

Analyze dependencies to find sequential chains and parallel-safe groups that can run simultaneously in worktrees.
分析依赖关系,找出可在工作树中同时运行的顺序链和可并行分组。

Step 4: Author the Decomposition section

步骤4:编写分解章节

Write the
## Decomposition
section into the unified spec at
docs/specs/YYYY-MM-DD-<feature>.md
, using
references/spec-template.md
. Its
## Decomposition
carries the task breakdown, with traceability resolved within this single document against the
## Design & Rationale
DR-N source above it.
The legacy two-file split (
references/plan-document-template.md
docs/plans/
) is retained only for in-flight workflows already on the old path; new features author the one
docs/specs/
artifact.
## Decomposition
章节写入统一规格文档
docs/specs/YYYY-MM-DD-<feature>.md
,遵循
references/spec-template.md
。其
## Decomposition
部分包含任务拆分,可追溯性在单个文档内与上方
## Design & Rationale
中的DR-N来源关联。
遗留的双文件拆分(
references/plan-document-template.md
docs/plans/
)仅适用于已采用旧流程的进行中工作流;新功能需编写单个
docs/specs/
工件。

Step 5: Plan Verification

步骤5:规划验证

Run deterministic verification scripts instead of manual checklist review. Each takes the unified
docs/specs/
artifact
as both
designPath
and
planPath
— the handlers parse DR-N from its design region and tasks from its decomposition region.
5a. Coverage — verify every Design & Rationale requirement maps to a task (the folded design-completeness acceptance-criteria check rides here now):
typescript
exarchos_orchestrate({
  action: "check_plan_coverage",
  featureId: "<id>",
  designPath: "docs/specs/<date>-<feature>.md",
  planPath: "docs/specs/<date>-<feature>.md"
})
  • passed: true — All requirements covered; proceed to 5a-ii
  • passed: false — Gaps found; add tasks for uncovered requirements or defer with rationale
  • error — Usage error or empty spec; check arguments
5a-ii. Provenance chain verification — verify every DR-N requirement maps to a task via
Implements:
field:
typescript
exarchos_orchestrate({
  action: "check_provenance_chain",
  featureId: "<id>",
  designPath: "docs/specs/<date>-<feature>.md",
  planPath: "docs/specs/<date>-<feature>.md"
})
  • passed: true — All DR-N requirements traced; proceed to 5b
  • passed: falseBlock: gaps or orphan references found. Add
    **Implements:** DR-N
    to tasks for each uncovered requirement before proceeding. Every DR-N requirement MUST trace to at least one task.
  • error — No DR-N identifiers in design (exit 2); if design doesn't use DR-N identifiers, this check is skipped (exempt)
5a-iii. D5: Task decomposition quality (advisory) — verify each task has clear description, file targets, and test expectations; dependency graph is a valid DAG; parallelizable tasks don't modify the same files:
typescript
exarchos_orchestrate({
  action: "check_task_decomposition",
  featureId: "<id>",
  planPath: "docs/specs/<date>-<feature>.md"
})
  • passed: true — All tasks well-decomposed; proceed to 5b
  • passed: false — Findings recorded as D5 gate events for the ConvergenceView. Present findings to the user for awareness but do not block plan approval.
  • error — Input error (missing file, no task headers); check arguments
Advisory: This gate verifies task structure quality but does not block plan approval. Findings are recorded for convergence tracking.
5b. Spec coverage check — verify planned test files exist and pass:
typescript
exarchos_orchestrate({
  action: "spec_coverage_check",
  planFile: "docs/specs/<date>-<feature>.md",
  repoRoot: "."
})
  • passed: true
    — All planned tests found and passing; plan verification complete
  • passed: false
    — Missing test files or test failures; create missing tests or fix failures
For reference, consult
references/spec-tracing-guide.md
for the underlying methodology.
运行确定性验证脚本,而非手动检查清单。每个脚本均将统一
docs/specs/
工件
同时作为
designPath
planPath
传入——处理器从其设计区域解析DR-N,从分解区域解析任务。
5a. 覆盖验证 —— 验证每个设计与原理需求均映射至任务(折叠的设计完整性验收标准检查现在在此处执行):
typescript
exarchos_orchestrate({
  action: "check_plan_coverage",
  featureId: "<id>",
  designPath: "docs/specs/<date>-<feature>.md",
  planPath: "docs/specs/<date>-<feature>.md"
})
  • passed: true —— 所有需求均已覆盖;进入5a-ii
  • passed: false —— 发现漏洞;为未覆盖的需求添加任务,或提供推迟理由
  • error —— 使用错误或规格文档为空;检查参数
5a-ii. 来源链验证 —— 验证每个DR-N需求均通过
Implements:
字段映射至任务:
typescript
exarchos_orchestrate({
  action: "check_provenance_chain",
  featureId: "<id>",
  designPath: "docs/specs/<date>-<feature>.md",
  planPath: "docs/specs/<date>-<feature>.md"
})
  • passed: true —— 所有DR-N需求均已追溯;进入5b
  • passed: false —— 阻塞:发现漏洞或孤立引用。为每个未覆盖的需求在任务中添加
    **Implements:** DR-N
    后再继续。每个DR-N需求必须至少追溯至一个任务。
  • error —— 设计中无DR-N标识符(退出码2);若设计未使用DR-N标识符,则跳过此检查(豁免)
5a-iii. D5:任务分解质量(建议性) —— 验证每个任务有清晰的描述、文件目标和测试预期;依赖图为有效的DAG;可并行任务不修改同一文件:
typescript
exarchos_orchestrate({
  action: "check_task_decomposition",
  featureId: "<id>",
  planPath: "docs/specs/<date>-<feature>.md"
})
  • passed: true —— 所有任务分解良好;进入5b
  • passed: false —— 检查结果记录为ConvergenceView的D5 gate事件。向用户展示检查结果以提高认知,但不阻塞规划批准。
  • error —— 输入错误(文件缺失、无任务标题);检查参数
建议: 此gate验证任务结构质量,但不阻塞规划批准。检查结果会被记录以用于收敛跟踪。
5b. 规格覆盖检查 —— 验证规划的测试文件存在且通过:
typescript
exarchos_orchestrate({
  action: "spec_coverage_check",
  planFile: "docs/specs/<date>-<feature>.md",
  repoRoot: "."
})
  • passed: true
    —— 所有规划的测试均已找到且通过;规划验证完成
  • passed: false
    —— 测试文件缺失或测试失败;创建缺失的测试或修复失败的测试
如需参考,请查阅
references/spec-tracing-guide.md
获取底层方法。

Anti-Patterns

反模式

Don'tDo Instead
Ship medium/high-tier behavior with no testsCover it with adequacy-judged tests (test-after is fine)
Mandate red-green-refactor on every taskScale verification to the task's
riskTier
; RGR is a high-tier opt-in
Create large tasksBreak into 2-5 min chunks
Skip dependency analysisIdentify parallel opportunities
Vague test descriptionsSpecific: Method_Scenario_Outcome
Assume your tests can failLet
check_test_adequacy
prove they can (revert source, re-run, expect red)
Add "nice to have" codeOnly what the behavior requires
禁止行为正确做法
发布中/高风险层级的行为却不编写测试用基于充分性评估的测试覆盖(测试后编写也可)
强制每个任务都遵循红-绿-重构流程根据任务的
riskTier
调整验证强度;红-绿-重构是高风险层级的可选流程
创建大型任务拆分为2-5分钟的小任务
跳过依赖分析识别并行化机会
模糊的测试描述具体化:方法_场景_结果
假设测试可以失败
check_test_adequacy
证明测试可以失败(还原源代码,重新运行,预期失败)
添加"锦上添花"的代码仅添加行为所需的代码

Rationalization Debunking

理由反驳

The ladder already prices in genuinely low-risk work — so these excuses apply to medium/high-tier tasks, where they are rationalizations rather than reasonable tier choices:
ExcuseReality
"This is too simple for a test" (on a medium/high-tier task)If it touches a high-blast surface, its tier is not low. Test it at the tier the ladder assigns.
"I'll add tests after"You won't. Or they'll be weak — and
check_test_adequacy
will catch tests that can't fail.
"Tests slow me down"Debugging an untested medium/high-tier change is slower.
"The design is obvious"Obvious to you now. Not in 3 months.
验证阶梯已考虑到真正低风险的工作——因此以下借口适用于中/高风险层级任务,它们属于不合理的理由而非合理的层级选择:
借口事实
"这太简单了,不需要测试"(针对中/高风险层级任务)如果它涉及高影响范围,其风险层级就不是低风险。需按照阶梯分配的层级进行测试。
"我之后再添加测试"你不会的。或者测试会很薄弱——而
check_test_adequacy
会发现无法失败的测试。
"测试拖慢我的速度"调试未测试的中/高风险变更会更慢。
"设计很明显"现在对你来说明显。3个月后就不一定了。

State Management

状态管理

On spec save, record the artifact and transition phase based on
workflowType
: feature →
plan-review
, refactor →
overhaul-plan-review
. Set
artifacts.plan
to the unified
docs/specs/
path
— this is the key the
planArtifactExists
guard reads, and it points at the one unified doc (the same path
ideate
recorded as
artifacts.spec
). Artifacts and phase are two separate calls —
update
is non-phase mutation only; phase changes go through the HSM-guarded
transition
action:
text
action: "update", featureId: "<id>", updates: {
  "artifacts": { "plan": "docs/specs/<date>-<feature>.md" },
  "tasks": [{ "id": "001", "title": "...", "status": "pending", "branch": "...", "blockedBy": [] }, ...]
}
action: "transition", featureId: "<id>", target: "<plan-review-phase>"
保存规格文档时,记录工件并根据
workflowType
转换阶段:feature(功能)→
plan-review
,refactor(重构)→
overhaul-plan-review
。将
artifacts.plan
设置为统一
docs/specs/
路径
——这是
planArtifactExists
guard读取的键,指向单个统一文档(与
ideate
记录为
artifacts.spec
的路径相同)。工件和阶段是两个独立的调用——
update
仅用于非阶段变更;阶段变更需通过HSM保护的
transition
操作:
text
action: "update", featureId: "<id>", updates: {
  "artifacts": { "plan": "docs/specs/<date>-<feature>.md" },
  "tasks": [{ "id": "001", "title": "...", "status": "pending", "branch": "...", "blockedBy": [] }, ...]
}
action: "transition", featureId: "<id>", target: "<plan-review-phase>"

Phase Transitions and Guards

阶段转换与Guard

For the full transition table, consult
@skills/checkpoint/references/phase-transitions.md
.
Quick reference: The
plan
plan-review
transition requires guard
plan-artifact-exists
— set
artifacts.plan
to the unified
docs/specs/
path before the
transition
call.
完整的转换表请查阅
@skills/checkpoint/references/phase-transitions.md
快速参考:
plan
plan-review
转换需要
plan-artifact-exists
guard——在调用
transition
之前,需将
artifacts.plan
设置为统一
docs/specs/
路径。

Schema Discovery

模式发现

Use
exarchos_workflow({ action: "describe", actions: ["update", "init"] })
for parameter schemas and
exarchos_workflow({ action: "describe", playbook: "feature" })
(or
"debug"
,
"refactor"
) for phase transitions, guards, and playbook guidance. Use
exarchos_orchestrate({ action: "describe", actions: ["check_plan_coverage", "check_provenance_chain"] })
for orchestrate action schemas.
使用
exarchos_workflow({ action: "describe", actions: ["update", "init"] })
获取参数模式,使用
exarchos_workflow({ action: "describe", playbook: "feature" })
(或
"debug"
"refactor"
)获取阶段转换、guard和工作流指南。使用
exarchos_orchestrate({ action: "describe", actions: ["check_plan_coverage", "check_provenance_chain"] })
获取编排操作模式。

Completion Criteria

完成标准

  • Design document read and understood
  • Spec traceability table created (
    exarchos_orchestrate({ action: "generate_traceability" })
    )
  • Scope declared (full or partial with rationale)
  • Tasks decomposed to 2-5 min granularity
  • Each task carries a
    riskTier
    (and
    boundaryTouching
    ) stamp; medium/high-tier tasks carry adequacy-judged tests (test-after), high-tier adds the integration suite
  • Dependencies mapped
  • Parallel groups identified
  • Plan verification passed —
    exarchos_orchestrate({ action: "check_plan_coverage" })
    returns passed: true
  • Provenance chain checked —
    exarchos_orchestrate({ action: "check_provenance_chain" })
    passed (blocking; gaps must be resolved before proceeding)
  • Task decomposition checked —
    exarchos_orchestrate({ action: "check_task_decomposition" })
    run (advisory; findings presented but non-blocking)
  • Spec coverage check passed —
    exarchos_orchestrate({ action: "spec_coverage_check" })
    passed: true
  • Coverage thresholds met —
    exarchos_orchestrate({ action: "check_coverage_thresholds" })
    passed: true:
typescript
exarchos_orchestrate({
  action: "check_coverage_thresholds",
  coverageFile: "coverage/coverage-summary.json",
  lineThreshold: 80,
  branchThreshold: 70,
  functionThreshold: 100
})
  • Unified spec saved to
    docs/specs/
    (Design & Rationale + Decomposition in one doc)
  • State file updated with
    artifacts.plan
    = unified spec path and tasks
  • 已阅读并理解设计文档
  • 已创建规格可追溯性表(执行
    exarchos_orchestrate({ action: "generate_traceability" })
  • 已声明范围(完整范围或带有理由的部分范围)
  • 任务已分解为2-5分钟的粒度
  • 每个任务都带有
    riskTier
    (和
    boundaryTouching
    )标记;中/高风险层级任务带有基于充分性评估的测试(测试后编写),高风险层级额外添加集成测试套件
  • 已映射依赖关系
  • 已识别并行分组
  • 规划验证通过——
    exarchos_orchestrate({ action: "check_plan_coverage" })
    返回passed: true
  • 来源链已检查——
    exarchos_orchestrate({ action: "check_provenance_chain" })
    通过(阻塞;漏洞必须解决后才能继续)
  • 任务分解已检查——
    exarchos_orchestrate({ action: "check_task_decomposition" })
    已执行(建议性;展示结果但不阻塞)
  • 规格覆盖检查通过——
    exarchos_orchestrate({ action: "spec_coverage_check" })
    返回passed: true
  • 覆盖阈值已满足——
    exarchos_orchestrate({ action: "check_coverage_thresholds" })
    返回passed: true:
typescript
exarchos_orchestrate({
  action: "check_coverage_thresholds",
  coverageFile: "coverage/coverage-summary.json",
  lineThreshold: 80,
  branchThreshold: 70,
  functionThreshold: 100
})
  • 统一规格文档已保存至
    docs/specs/
    (设计与原理 + 分解内容在单个文档中)
  • 状态文件已更新,
    artifacts.plan
    = 统一规格文档路径,且包含任务信息

Transition

转换

After decomposition completes, auto-continue to plan-review. Transition to the appropriate review phase (feature:
plan-review
, refactor:
overhaul-plan-review
). Plan-review is no longer an inline plan-vs-design delta (one artifact now) — it is a dispatched, fresh-context, adversarial read-only pass over the unified artifact (DR-10): a clean reviewer provisioned with only {artifact + spec} (never this authoring transcript), prompted to refute the plan, its adversarial depth scaled by the frozen
designDepth
. Provision it via
exarchos_orchestrate({ action: "prepare_review", scope: "plan", artifact: "docs/specs/<...>", designDepth: "<frozen>" })
.
  • Refuted (gaps): set
    .planReview.gaps
    , auto-loop back to
    plan --revise
  • Survives: present to user for approval (the single human checkpoint)
  • On approval: set
    .planReview.approved = true
    , invoke
    delegate
REQUIRED: Run
exarchos_orchestrate({ action: "check_plan_coverage" })
over the unified artifact. If passed: false → auto-invoke
plan --revise
. If passed: true → transition to the plan-review phase and only invoke
delegate
after plan-review approval.
分解完成后,自动继续至plan-review。转换至相应的评审阶段(功能:
plan-review
,重构:
overhaul-plan-review
)。Plan-review不再是内联的规划与设计差异检查(现在是单个工件)——而是对统一工件的调度式、全新上下文、对抗性只读检查(DR-10):为评审者提供仅包含{工件 + 规格}的干净环境(绝不提供此编写记录),提示其反驳规划,对抗性深度由冻结的
designDepth
决定。通过
exarchos_orchestrate({ action: "prepare_review", scope: "plan", artifact: "docs/specs/<...>", designDepth: "<frozen>" })
准备环境。
  • 被反驳(发现漏洞):设置
    .planReview.gaps
    ,自动循环回
    plan --revise
  • 通过评审:提交给用户批准(唯一的人工检查点)
  • 批准后:设置
    .planReview.approved = true
    ,调用
    delegate
强制要求: 对统一工件运行
exarchos_orchestrate({ action: "check_plan_coverage" })
。若返回passed: false → 自动调用
plan --revise
。若返回passed: true → 转换至plan-review阶段,仅在plan-review批准后调用
delegate

Exarchos Integration

Exarchos集成

Phase transitions auto-emit
workflow.transition
events via
exarchos_workflow
set
. No manual
exarchos_event
append needed.
阶段转换会通过
exarchos_workflow
set
自动发送
workflow.transition
事件。无需手动添加
exarchos_event

Troubleshooting

故障排除

IssueCauseResolution
check_plan_coverage
returns passed: false
Design sections not mapped to tasksAdd tasks for uncovered sections or add explicit deferral rationale
spec_coverage_check
passed: false
Planned test files missing or failingCreate missing test stubs, verify file paths in plan match actual paths
generate_traceability
passed: false
Design doc missing expected
##
/
###
headers
Verify design uses standard Markdown headings
Revision loop (3+ attempts)Persistent gaps between design and planSet
planReview.revisionsExhausted = true
, suggest
ideate --redesign
问题原因解决方案
check_plan_coverage
返回passed: false
设计章节未映射至任务为未覆盖的章节添加任务,或添加明确的推迟理由
spec_coverage_check
返回passed: false
规划的测试文件缺失或失败创建缺失的测试桩,验证规划中的文件路径与实际路径匹配
generate_traceability
返回passed: false
设计文档缺少预期的
##
/
###
标题
验证设计使用标准Markdown标题
修订循环(3次以上尝试)设计与规划之间存在持续漏洞设置
planReview.revisionsExhausted = true
,建议执行
ideate --redesign

Performance Notes

性能说明

  • Complete each step fully before advancing — quality over speed
  • Do not skip validation checks even when the change appears trivial
  • Trace every design section to at least one task. Do not leave uncovered sections without explicit rationale.
  • 完成每个步骤后再推进——质量优先于速度
  • 即使变更看似微不足道,也不要跳过验证检查
  • 每个设计章节至少追溯至一个任务。未覆盖的章节必须有明确的理由。