@namewta/speculo 2.0.2 → 2.0.4

package/template/workflows/specdev/specdev-c-code-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: specdev-c-code-review
-description: "按用户指定文件或 PR、单 commit、区间、基线冻结真实审查范围，执行隔离的标准轴与规范轴审查；有效空差异诚实返回，不实施修复或发布。"
+description: "按用户指定文件或 PR、单 commit、区间、基线冻结真实审查范围，派遣未参与实现的 Agent 执行标准轴与规范轴审查；有效空差异诚实返回，不实施修复或发布。"
 metadata:
   speculo-kind: work-skill
   speculo-id: specdev/code-review
@@ -31,7 +31,7 @@ UI diff 按 <Path>{roots.workflows}/specdev/common/rules/design-contract.md</Pat
 1. **解析固定点**：先选择 baseline（共同祖先到 head）、range（两个指定端点）、commit（指定提交与其父）或 pr（远程 PR diff）。PR 先通过 <Path>{roots.workflows}/specdev/specdev-t-triage/references/remote-operations.md</Path> 的 pr-read 获得完整 base/head SHA。调用 <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> 的 `--review-scope --repo <project-root> --mode <mode>`；端点模式传 --base/--head，commit 传 --commit，多父提交明确 --parent。此只读工具冻结本地对象，不抓取、不写状态；根提交没有现有 CR 的 committed baseline 时明确报告限制，不编造父提交。
 2. **冻结输入**：保存工具返回的实际 diff argv、fixed_point/head、diff_sha256、路径与 commit log，不把单 commit 扩大到当前 HEAD。引用无效则失败；有效空 diff 返回 no-diff，不启动 reviewer、不造 CR、不声称 approved；正常结束本次 Work 并报告固定输入，change 完成仍按原终点规则判断。有差异才继续。
 3. **发现来源**：调用 `<Path>{roots.workflows}/specdev/common/skills/code-review/SKILL.md</Path>`；规范来源缺失时经确认跳过规范轴，标准轴继续。
-4. **隔离审查**：仅按公共 Skill 的完整输入复用门接受既有结果；需要执行的轴在平台支持时并行 reviewer，否则用两个独立完整输入包顺序执行。两轴不得读取对方 finding。
+4. **独立审查**：按公共 Skill 的完整输入与独立身份门复用已有结果；否则默认派遣一位未参与实现的 Agent 分别审两轴，需要并行时使用两位。保存真实工具凭据和原始输出，Lead 核验后记录 Independent Review；能力不足保持 blocked。
 5. **持久化（有 change 时）**：选择下一个未占用 `CR-###`，使用 `<Path>{roots.workflows}/specdev/specdev-c-code-review/assets/code-review-template.md</Path>` 写入 `<Path>{roots.state}/specdev/changes/{change}/reviews/CR-###.md</Path>`，原子重读。
 6. **验证与路由**：无 change 时核对实际报告与固定范围直接返回；有 change 时使用 `<Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path>` 的 `--stage review` 校验当前 change。无阻塞 finding 时返回完成或 I；局部修复生成/修订 Ticket；规范冲突返回 S/G；无法确定的 blocker 保持 C 可恢复状态。
 
@@ -39,7 +39,7 @@ UI diff 按 <Path>{roots.workflows}/specdev/common/rules/design-contract.md</Pat
 
 - 有差异分支的 fixed point/head 是本地不可变 SHA，diff 语义与用户选择一致；no-diff 独立返回，不运行要求 CR 的 review stage；
 - 规范和标准来源发现顺序有记录；
-- 两轴隔离、固定顺序、未合并排名；
+- 审查者与实现者不同、两轴分别判断、固定顺序、未合并排名；
 - 每个 finding 有路径、风险、依据和满足条件；
 - 报告、状态、验证结果和下一 Work 路径一致；
 - C 未修改项目代码或远程状态。
@@ -52,4 +52,4 @@ UI diff 按 <Path>{roots.workflows}/specdev/common/rules/design-contract.md</Pat
 
 `lead` 上下文维护原业务状态和 Evidence；`task` 上下文只处理 Lead 指定目标和阶段，执行同一方法并返回候选、findings、检查和未验证项，不修改正式 Ticket、Map、Goal、Evidence，不递归启动 Goal 或擅自跨 CLI 派单；宿主原生协作遵守原写集和单 writer 约束。未曝光到宿主列表不影响读取真实入口。
 
-P 在已授权 run/resume 中完成当前实现、审查、验证和同范围修复后继续下一 Ready 任务，不逐票询问“继续”。只读分析或 plan 不执行。独立审查 required 时不能以 Lead 自审替代。
+P 在已授权 run/resume 中完成当前实现、审查、验证和同范围修复后继续下一 Ready 任务，不逐票询问“继续”。只读分析或 plan 不执行。双轴审查必须由未参与本范围实现的 Agent 执行，默认派遣一位原生 subagent；已有编排选择沿用于 review，不能由实现者或参与实现的 Lead 自审替代。

package/template/workflows/specdev/specdev-c-code-review/assets/code-review-template.md

@@ -46,8 +46,12 @@ created_at: <ISO-8601>
 
 ## 审查证据复用（仅实际发生时填写）
 
-记录原 CR/Evidence locator、fixed/head/diff、规范/标准/指令与 Skill/reference 摘要、工具/环境相关证据、两轴隔离核对、复用或重跑的轴与原因。未发生时写“不适用”；本节不是通过声明，也不改变原始审查结果。
+记录原 CR/Evidence locator、fixed/head/diff、规范/标准/指令与 Skill/reference 摘要、工具/环境相关证据、审查者独立身份与派遣/返回核对、复用或重跑的轴与原因。未发生时写“不适用”；本节不是通过声明，也不改变原始审查结果。
 
 ## 比较语义与证据有效期
 
 记录 baseline/range/commit/pr、实际 diff argv/digest、原 base/head 与 fixed point、消费者和相关配置/规范版本。合法 no-diff 不创建本 CR；非法引用和根提交无 committed baseline 明确报告。head 或相关输入变更后，核对受影响审查与验证，不沿用旧通过。
+
+## 独立审查记录的填写
+
+按 <Path>{roots.workflows}/specdev/common/skills/code-review/references/review-evidence.md</Path> 在本文实际生成 `Independent Review`、固定输入、原始 reviewer 输出和 Lead 核验段。完成前必须有真实独立身份与两轴结果；不要预填通过或用模板段落替代证据。

package/template/workflows/specdev/specdev-c-code-review/references/source-files-review.md

@@ -3,8 +3,8 @@
 仅用于明确指定文件的只读请求，不替代用户要求的 PR、commit、range 或 baseline 比较，也不冒充 I 的最终 diff 审查。
 
 1. 用下列只读调用固定 projectRoot、用户指定路径和实际原始字节摘要，多个文件重复 `--file`。它不调用 Git、不创建状态，拒绝空范围、重复文件/别名、非文件及越界路径；内部符号链接保留所选路径和实际目标。读取必要直接调用方、测试与适用标准，并把扩展范围及理由列入输入。若文件在审查中变化，重验受影响结论，不沿用原快照结果。无 Git 时如实说明没有 commit/log，不能借外层仓库或伪造 SHA。
-2. 将 `review_mode: source-files`、`source_snapshot`（项目相对路径及 SHA256）、规范/标准来源、review_context 和实际可用隔离方式交给 <Path>{roots.workflows}/specdev/common/skills/code-review/SKILL.md</Path>。来源发现将 commit 引用步骤记为 not-applicable；其余来源与两轴隔离要求照常。
-3. 规范缺失只阻塞依赖规范的判断，标准轴独立进行；按原规则确认规范缺失后才标记 skipped:no-spec。工具或独立 reviewer 缺失如实报告，不用一次自审宣称两个隔离轴已完成。
+2. 将 `review_mode: source-files`、`source_snapshot`（项目相对路径及 SHA256）、规范/标准来源、review_context 和真实独立 reviewer 身份与派遣方式交给 <Path>{roots.workflows}/specdev/common/skills/code-review/SKILL.md</Path>。来源发现将 commit 引用步骤记为 not-applicable；其余来源与独立审查要求照常。
+3. 规范缺失只阻塞依赖规范的判断，标准轴独立进行；按原规则确认规范缺失后才标记 skipped:no-spec。工具或独立 reviewer 缺失如实报告，不得用实现者自审宣称双轴已完成。
 4. 返回固定文件/摘要、两轴结果、实际验证、限制和下一步。会话结果不创建 change、CR、配置或状态文件，不改源文件、永久知识或远程系统。若后来要求正式 diff 审查，转回 C 的真实固定点分支。
 
 本分支的文件摘要只证明输入未变，不证明语义审查质量、用户授权或整个 change 完成。

package/template/workflows/specdev/specdev-i-implement/SKILL.md

@@ -46,4 +46,4 @@ UI Ticket 或 Direct Spec 必须读取 <Path>{roots.workflows}/specdev/common/ru
 
 `lead` 上下文维护原业务状态和 Evidence；`task` 上下文只处理 Lead 指定目标和阶段，执行同一方法并返回候选、findings、检查和未验证项，不修改正式 Ticket、Map、Goal、Evidence，不递归启动 Goal 或擅自跨 CLI 派单；宿主原生协作遵守原写集和单 writer 约束。未曝光到宿主列表不影响读取真实入口。
 
-P 在已授权 run/resume 中完成当前实现、审查、验证和同范围修复后继续下一 Ready 任务，不逐票询问“继续”。只读分析或 plan 不执行。独立审查 required 时不能以 Lead 自审替代。
+P 在已授权 run/resume 中完成当前实现、审查、验证和同范围修复后继续下一 Ready 任务，不逐票询问“继续”。只读分析或 plan 不执行。双轴审查必须由未参与本范围实现的 Agent 执行，默认派遣一位原生 subagent；已有编排选择沿用于 review，不能由实现者或参与实现的 Lead 自审替代。

package/template/workflows/specdev/specdev-i-implement/assets/evidence-template.md

@@ -20,12 +20,13 @@
 - **执行选择与来源：** 当前宿主正常执行（mode: lead，App/CLI 等）/ 显式 CLI 交互或调用 / Herdr / 其他已选方式；current / required；实际用户选择或有效计划来源，无 Goal 时默认串行、集成尝试上限 3
 - **Implementation owner：** Lead / `<agent/provider>`
 - **Dispatch Packet/checkpoint：** Lead direct / `<locator + immutable checkpoint>`
+- **文件交接（实际外部派遣时）：** `<Path>{roots.state}/specdev/changes/{change}/sessions/{session}/{task}/TASK.md</Path>` 与 `<Path>{roots.state}/specdev/changes/{change}/sessions/{session}/{task}/REPORT.md</Path>`；绑定稳定 change 身份与 change 根相对 locator，修正交付引用新任务及旧报告；Lead direct 不创建空目录
 - **允许动作：** worktree changes / implementation commit / ...
 - **返回：** commit、dirty 状态、修改路径、非 E2E 命令、未验证项与恢复条件
 - **Lead 独立核对：** pass / fail；实际读取与命令摘要
 - **只读 Agent findings：** 无 / 固定输入、来源、结论、Lead 核对
 
-任务执行者 不写本 Evidence；以上内容由 Lead 从实际 workspace、Git 和返回事实整理。
+任务执行者 不写本 Evidence；以上内容由 Lead 从实际 workspace、Git 和返回事实整理。有文件交接时依 <Path>{roots.references}/coordination/session-files.md</Path> 只保存输入/报告指针和 Lead 独立核验，不复制正文；REPORT 的 completed 不是本 Evidence 的 done。先读报告聚焦交接，细节不足再检索其历史入口。突然中断无报告时记录未知事实与原工具查询结果，不补造成功回报。
 
 ## 3. 修改范围与路径所有权
 
@@ -70,10 +71,10 @@
 ### 规范轴
 
 - **固定输入与来源：** Spec / Ticket / Goal Plan / source
-- **结果：** pass / request-changes / skipped:no-spec
+- **结果：** pass / request-changes / blocked:missing-spec
 - **Findings 与修正：** 无 / ...
 
-两个轴隔离并按上述顺序记录。
+两个轴分别判断并按上述顺序记录；默认同一位未参与实现的 reviewer 完成两轴。
 
 ## 7. Integration Verification
 
@@ -135,7 +136,7 @@
 
 ## 审查证据复用（仅实际发生时填写）
 
-记录原 CR/Evidence locator、fixed/head/diff、规范/标准/指令与 Skill/reference 摘要、工具/环境相关证据、两轴隔离核对、复用或重跑的轴与原因。未发生时写“不适用”；本节不是通过声明，也不改变原始审查结果。
+记录原 CR/Evidence locator、fixed/head/diff、规范/标准/指令与 Skill/reference 摘要、工具/环境相关证据、审查者独立身份与派遣/返回核对、复用或重跑的轴与原因。未发生时写“不适用”；本节不是通过声明，也不改变原始审查结果。
 
 ## OPS 交付（仅用户请求时）
 
@@ -152,3 +153,7 @@
 ## Acceptance Verification
 
 仅独立 Spec 的无票 Direct Spec 完成时填写本节 JSON array，每个 Spec AC 恰一项。字段为 `id`（AC-N）、`result: passed`、`method`、`source`、`observed`；实际执行命令时增加 `command` 与 `exit: 0`。引用外部 `evidence` 文件时须提供真实匹配的 `sha256`；原 Evidence 内联实际观察不另造文件。没有执行的项不伪造 passed。普通 README 轻量模式仍用 README verification 表，二者不重复维护。
+
+## 独立审查记录的填写
+
+按 <Path>{roots.workflows}/specdev/common/skills/code-review/references/review-evidence.md</Path> 在本文实际生成 `Independent Review`、固定输入、原始 reviewer 输出和 Lead 核验段。完成前必须有真实独立身份与两轴结果；不要预填通过或用模板段落替代证据。

package/template/workflows/specdev/specdev-i-implement/references/implementation-procedure.md

@@ -65,7 +65,7 @@ Git 已处于 merge/rebase 冲突时，先加载 `<Path>{roots.workflows}/specde
 
 ### 2. Lead 决定自行实现或动态派单
 
-两种输入模式下，Lead 根据独立性、路径冲突、上下文、风险、用户选择和平台能力决定；原生 subagent/team 属于宿主能力。派单时读取 `<Path>{roots.references}/coordination/task-brief.md</Path>`。`current` 模式仍可派遣一个 实现执行者 写当前 workspace，但必须等待其返回、Lead 验收并形成 commit 后才进入下一个 Ticket；`required` 模式 实现执行者 绑定独立 Ticket worktree。Direct Spec 同样可以交接实现：提供获批 Spec、项目 Skill、当前工作区、路径和验收，current 只允许一个代码 writer，required 绑定本 change 的唯一 source worktree。
+两种输入模式下，Lead 根据独立性、路径冲突、上下文、风险、用户选择和平台能力决定；原生 subagent/team 属于宿主能力。派单时读取 `<Path>{roots.references}/coordination/task-brief.md</Path>`；外部 CLI/Herdr/Orca 派遣按 `<Path>{roots.references}/coordination/session-files.md</Path>` 保存 TASK、交回 REPORT，原 Evidence 只导航与验收。`current` 模式仍可派遣一个 实现执行者 写当前 workspace，但必须等待其返回、Lead 验收并形成 commit 后才进入下一个 Ticket；`required` 模式 实现执行者 绑定独立 Ticket worktree。Direct Spec 同样可以交接实现：提供获批 Spec、项目 Skill、当前工作区、路径和验收，current 只允许一个代码 writer，required 绑定本 change 的唯一 source worktree。
 
 - 实现执行者 同时取适用子 Goal Plan、父 Implementation Plan、实际存在的 config 和平台能力的共同上限；current 模式保持单 writer 串行安全不变量；Lead 参与实现时计入；
 - 父实现编排存在时，派单与返回都使用 `<member-change>::<ticket-id>`，并占用父 Plan 的 task/serialization/integration slot；
@@ -128,7 +128,9 @@ Direct Spec 的 implementation owner 在所选工作区运行规格要求的非
 
 标准轴同时复核 `<Path>{roots.workflows}/specdev/common/rules/code-commenting-rule.md</Path>`：公共 API 契约完整，内部注释只保留非显然的 Why、Invariant 和 Risk，且相关注释与当前行为一致。
 
-两个轴隔离并按标准轴、规范轴顺序返回 Lead。局部 finding 在当前模式的实现 workspace 修正、创建新 checkpoint 并重跑；改变上层契约则登记 deviation。Ticket 进入 `review` 或 Direct Spec 进入最终验证前，两轴必须通过。
+默认派遣一位未参与本范围实现的原生 subagent，分别判断标准轴、规范轴并按顺序返回 Lead；明确选择 Herdr/Orca/CLI 时沿该方式派遣。保存真实身份、原始报告和 Lead 工具核验，禁止实现者自审。局部 finding 在当前模式的实现 workspace 修正、创建新 checkpoint 并重跑；改变上层契约则登记 deviation。Ticket 进入 `review` 或 Direct Spec 进入最终验证前，两轴必须通过。
+
+Direct Spec current 未提交时按 <Path>{roots.workflows}/specdev/common/skills/code-review/references/working-tree-review.md</Path> 固定实际交付快照；HEAD 不能代表未提交内容，也不因审查而自动取得 commit 授权。
 
 ### 7. 最终集成与适用 E2E
 
@@ -140,6 +142,8 @@ E2E 是否需要由 Ticket/Goal Plan 的实际跨边界风险决定，不限于
 
 无论失败发生在 implementation、review、direct-parent 还是 parent-candidate，同一 Ticket 反复返回相同 blocker、下一轮没有产生新证据，或 integration attempts 达到有效 Plan 上限时，都停止自动退回原 implementation owner。Lead 保留当前 workspace/worktree、implementation/source commit、旧 candidate 和失败命令，在 Ticket Evidence 记录失败历史，并将 Ticket/worktree 标为 `blocked`。当前 change 属于父实现时返回父 O Lead；否则返回 Goal Plan Lead，或无 Goal Plan 时的当前 I Lead。Lead 按 lead-orchestration 完成最小复盘并形成有实质变化的新 Dispatch Packet 后，才可重置 attempts 和重新派发；契约已失效则返回真正 owner。
 
+最终候选与来源审查不同、发生冲突修正或多个单元组合时，Lead 按 <Path>{roots.workflows}/specdev/common/skills/code-review/references/review-evidence.md</Path> 对最终交付范围补充独立审查；原输入完全相同才复用。候选未获两轴通过不能推进父分支或声明完成。
+
 ### 8. Evidence、状态与完成
 
 Lead 使用 `<Path>{roots.workflows}/specdev/specdev-i-implement/assets/evidence-template.md</Path>` 写入 Ticket Evidence；Direct Spec 按该模板的 Direct Spec 适配说明写 `<Path>{roots.state}/specdev/changes/{change}/evidence/direct-spec.md</Path>`。Ticket Evidence 按策略记录 implementation/source、适用 candidate/result SHA、派单/返回、两层验证、双轴审查、E2E disposition、路径审计、失败历史与适用 Lead 复盘、偏差和残余风险；Direct Spec Evidence 使用实施前基线与所选 workspace 最终 checkpoint；required 追加真实 Workspace Execution Record 与 source/candidate/result 链，current 未发生集成不伪造这些字段，两者都不填 Ticket ID。

package/template/workflows/specdev/specdev-p-goal-plan/SKILL.md

@@ -68,4 +68,4 @@ node <Path>{roots.workflows}/specdev/common/tools/ticket-control.mjs</Path> --ma
 
 `lead` 上下文维护原业务状态和 Evidence；`task` 上下文只处理 Lead 指定目标和阶段，执行同一方法并返回候选、findings、检查和未验证项，不修改正式 Ticket、Map、Goal、Evidence，不递归启动 Goal 或擅自跨 CLI 派单；宿主原生协作遵守原写集和单 writer 约束。未曝光到宿主列表不影响读取真实入口。
 
-P 在已授权 run/resume 中完成当前实现、审查、验证和同范围修复后继续下一 Ready 任务，不逐票询问“继续”。只读分析或 plan 不执行。独立审查 required 时不能以 Lead 自审替代。
+P 在已授权 run/resume 中完成当前实现、审查、验证和同范围修复后继续下一 Ready 任务，不逐票询问“继续”。只读分析或 plan 不执行。双轴审查必须由未参与本范围实现的 Agent 执行，默认派遣一位原生 subagent；已有编排选择沿用于 review，不能由实现者或参与实现的 Lead 自审替代。

package/template/workflows/specdev/specdev-p-goal-plan/assets/goal-plan-template.md

@@ -77,6 +77,8 @@ ready_for_execution: false
 
 ## 4. Execution and Integration Protocol
 
+**执行入口：** 获得实现授权后，Lead 与实现执行者读取并执行 `<Path>{roots.workflows}/specdev/specdev-i-implement/SKILL.md</Path>`，再按当前输入实际调用适用项目 Skill。I 负责实现、独立双轴审查、验证与 Evidence；计划本身不授予实现或 Git 操作权限。
+
 ### Lead Orchestration
 
 执行方式独立于下方工作区策略：默认按当前宿主正常执行（mode: lead），App、CLI 等均可，subagent/team 属于宿主能力；明确指定 CLI 交互、Herdr 等方式才按共享编排合同接入。记录本次选择与来源，不逐任务重新询问。

package/template/workflows/specdev/specdev-p-goal-plan/assets/lightweight-goal-plan-template.md

@@ -14,6 +14,8 @@ lead: <actual-session-locator>
 
 ## Integration and Verification
 
+**执行入口：** 获得实现授权后，Lead 与实现执行者读取并执行 `<Path>{roots.workflows}/specdev/specdev-i-implement/SKILL.md</Path>`，再按当前输入实际调用适用项目 Skill。I 负责实现、独立双轴审查、验证与 Evidence；计划本身不授予实现或 Git 操作权限。
+
 <适用集成方式、README AC/verification 导航、实际验证与未验证边界；票或清单全勾不替代整体验收。>
 
 ## Next Steps

package/template/workflows/specdev/specdev-p-goal-plan/references/completion-control.md

@@ -2,6 +2,9 @@
 
 ## 1. 整体 Definition of Done
 
+实现型完成必须按 <Path>{roots.workflows}/specdev/common/skills/code-review/references/review-evidence.md</Path> 有覆盖实际最终交付的独立双轴通过证据。多单元组合使用整体审查；单单元固定输入相同可复用，未提交内容使用工作副本快照。非实现学习、复盘及取消沿各自等价验收，不制造代码审查。
+
+
 至少要求：
 
 - Spec 验收合同全部有通过 Evidence 或明确批准的 deferred；

package/template/workflows/specdev/specdev-s-spec/SKILL.md

@@ -16,9 +16,9 @@ metadata:
 
 1. **Grounding**：定位用户目标与当前代码、测试、接口、schema、配置和运行事实。按存在情况定位 change 的来源、分诊、诊断、LOG、CONTEXT、ADR 及相关永久领域词汇/决策；只回读命中原文，可选工件缺失静默跳过，不当作已确认事实。按 `<Path>{roots.workflows}/specdev/common/rules/planning-principles.md</Path>` 区分可发现事实、高影响偏好和可逆实现细节；冲突按 `<Path>{roots.workflows}/specdev/common/rules/artifact-contract.md</Path>` 返回权威 owner。
 2. **关闭必要决定**：只确认会改变外部行为、接口、数据、兼容、安全、迁移、发布或验收的高价值问题。广泛取舍未定时返回 `<Path>{roots.workflows}/specdev/specdev-g-grill-with-docs/SKILL.md</Path>`；陌生外部依赖或版本行为通过 `<Path>{roots.workflows}/specdev/common/skills/research/SKILL.md</Path>` 查证。不虚构错误码、性能阈值、法规或迁移政策。
-3. **写入合同**：先按下述轻量/完整边界选择唯一负责位置；轻量写 README 等价章节，完整模式以 `<Path>{roots.workflows}/specdev/specdev-s-spec/assets/spec-template.md</Path>` 写入 `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`。模板拥有问题/用户/成功、正常/边界/失败/角色/状态行为、IN/REUSE/OUT、保持项、接口数据与 NFR 的完整结构及 `US-### / AC-### / NFR-### / DEC-### / OOS-###` 稳定编号。实现约束仅锁定会影响公共合同、兼容、安全或验收的决定。
+3. **写入合同**：先按下述轻量/完整边界选择唯一负责位置；轻量写 README 等价章节，完整模式以 `<Path>{roots.workflows}/specdev/specdev-s-spec/assets/spec-template.md</Path>` 写入 `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`。必需正文为问题与目标、外部行为、验收合同、范围和验证策略；用户故事、接口数据、NFR、约束与风险按需展开。已使用的 `US-### / AC-### / NFR-### / DEC-### / OOS-###` 保持稳定，不为凑数量生成条目。实现约束仅锁定会影响公共合同、兼容、安全或验收的决定。
 4. **绑定验证接缝**：优先复用稳定接缝，通常从用户端到端行为、公共 API/CLI、事件/集成、稳定单元接缝选择；按实际风险与项目先例决定，不机械追求最高测试层级。每个接缝注明入口类型/位置、触发方式、可观察结果、覆盖 AC 和实际测试先例/命令。选择显著改变可测试性、事故半径或范围时聚焦确认；可由已有代码推导时记录依据即可。证据遵守 `<Path>{roots.workflows}/specdev/common/rules/evidence-and-verification.md</Path>`。
-5. **Readiness**：对照 <Path>{roots.workflows}/specdev/specdev-s-spec/references/spec-readiness.md</Path>；完整 Spec 再校验 <Path>{roots.workflows}/specdev/common/schemas/spec.schema.json</Path>。高影响未决问题使 `ready_for_tickets: false`；低影响、可逆默认值可作为带验证方式的显式假设。每个 AC 必须可观察、可判定、绑定接缝；不适用影响写明理由。
+5. **Readiness**：对照 <Path>{roots.workflows}/specdev/specdev-s-spec/references/spec-readiness.md</Path>；完整 Spec 再校验 <Path>{roots.workflows}/specdev/common/schemas/spec.schema.json</Path>。高影响未决问题使 `ready_for_tickets: false`；低影响、可逆默认值可作为带验证方式的显式假设。每个 AC 必须可观察、可判定、绑定接缝；只展开实际适用影响；已识别风险若不采取检查，说明依据。
 
 简单单 change 可使用 README 的 scope/acceptance/verification 等价章节承载规格，仍须通过同一行为/AC/Ready 语义；独立 <Path>{roots.state}/specdev/changes/{change}/spec.md</Path> 存在时默认使用它，双权威先裁决。用户明确要求 Spec 或存在复杂设计/Deep/并行/跨 change 时交付完整 Spec。迁出 README 规格改为导航。
 

package/template/workflows/specdev/specdev-s-spec/assets/spec-template.md

@@ -10,90 +10,40 @@ sources:
 
 # Spec: <标题>
 
-- **Spec：** `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`
-- **当前 ADR：** `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>`
-- **当前领域上下文：** `<Path>{roots.state}/specdev/changes/{change}/CONTEXT.md</Path>`
+## 问题与目标
 
-## 1. 问题与目标
+<目标用户或调用者、当前问题、预期收益与成功标准。只引用真实存在的来源、CONTEXT 和 ADR。>
 
-### 问题陈述
+## 解决方案与外部行为
 
-### 目标用户与场景
+<从入口到可观察结果描述正常流程、适用的角色/状态、边界与失败行为。需要用户故事时使用 US-###，不为凑数量重复 AC。>
 
-### 成功标准
-
-### 非目标
-
-## 2. 解决方案与外部行为
-
-### 解决方案摘要
-
-### 主要流程
-
-### 边界、失败与稳定错误行为
-
-### 状态转换与不变量
-
-## 3. 用户故事
-
-- **US-001**：作为 <角色>，我希望 <能力>，以便 <收益>。
-
-## 4. 验收合同
+## 验收合同
 
 | ID | 前置条件 | 动作或事件 | 可观察结果 | 验证接缝 |
 |---|---|---|---|---|
 | AC-001 | ... | ... | ... | ... |
 
-## 5. 范围
-
-### IN
-
-### REUSE
+## 范围
 
-### OUT
+- **IN：** <交付的行为>
+- **REUSE：** <沿用的能力和必须保持的行为>
+- **OUT：** <明确不做的内容及原因；需要引用时使用 OOS-###>
 
-- **OOS-001**：<不做什么及原因>。
-
-## 6. 已锁定实现约束
-
-- **DEC-001**：<只写影响公共接口、数据、不变量、兼容、安全或验证的决策>。来源：`ADR-###`。
-
-## 7. 数据、接口与兼容
-
-- **公共接口变化：** 无 / ...
-- **数据模型与持久化：** 无 / ...
-- **兼容要求：** 无 / ...
-- **迁移要求：** 无 / ...
-- **发布或运维影响：** 无 / ...
-
-## 8. 非功能要求
-
-- **NFR-001 安全与隐私：**
-- **NFR-002 性能与容量：**
-- **NFR-003 可用性与可靠性：**
-- **NFR-004 可观测性与运营：**
-
-不适用的维度写“不适用：原因”。
-
-## 9. 验证策略
+## 验证策略
 
 | 接缝 | 层级 | 覆盖合同 | 现有先例或命令 | Evidence 类型 |
 |---|---|---|---|---|
+| ... | ... | AC-001 | ... | ... |
 
-项目测试先例可引用项目相对路径，例如 `<Path>tests/example.test.ts</Path>`。
+优先复用真实测试接缝和项目先例；按风险选择验证层级。项目文件使用项目相对 Path，例如 `<Path>tests/example.test.ts</Path>`。
 
-## 10. 风险、假设与未决问题
+## 约束与风险（适用时）
 
-### 风险
+仅保留影响公共接口、数据、不变量、兼容、安全、迁移或验收的决定；引用原 ADR，必要时以 DEC-###/NFR-### 标识。取消、重复、部分成功、未知结果及恢复限制写入原 AC/NFR，不另抄一套失败合同。无关维度省略，不逐项填“不适用”。
 
-### 已采用的低影响假设
+低影响可逆假设写清适用范围和验证方法；高影响未决问题关闭前保持 `ready_for_tickets: false`。该字段也适用于 Direct Spec 的实现就绪判断。
 
 ### 未决问题
 
 无。
-
-存在高影响未决问题时，`ready_for_tickets` 必须为 `false`。
-
-## 失败与兼容补充（适用时）
-
-在原 AC/NFR 编号下记录取消/重复/乱序、未开始/部分提交/已提交/未知结果、可安全重试前提、状态 owner、可观察错误和旧数据迁移/恢复限制。这里只补充适用合同，不新增另一套验收编号或实现计划。

package/template/workflows/specdev/specdev-t-tickets/assets/ticket-template.md

@@ -28,130 +28,46 @@ shared_path_owners: []
 
 # Ticket T-01: <标题>
 
-- **Ticket 文件：** `<Path>{roots.state}/specdev/changes/{change}/ticket/01-<ticket-name>.md</Path>`
 - **总体 Map：** `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>`
 - **上游 Spec：** `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`
 - **完成 Evidence：** `<Path>{roots.state}/specdev/changes/{change}/evidence/T-01.md</Path>`
+- **执行入口：** 获得实现授权后读取并执行 `<Path>{roots.workflows}/specdev/specdev-i-implement/SKILL.md</Path>`；按 Map → 适用项目 Skill → 当前 Ticket 读取输入。项目 Skill 调用不能替代 I 的实现、独立双轴审查及完成流程。
 
-实现本 Ticket 时，Lead 与 实现执行者 必须按顺序完整读取总体 Map，读取项目 Skill 的 frontmatter 与入口并只展开适用于 `ALL`/`T-01` 的匹配项，再读取本 Ticket 与相关上游工件。Map 中的 Skill 是最低必读集合；新的匹配项先由 Lead 同步到 Map 并重新校验。
+## 目标与来源
 
-## 1. 战略与来源
+<本票交付的可观察产出、为何需要，以及上游 AC/用户决定/诊断来源；只补充相关现状与差距。>
 
-- **目标：** 做什么、为什么、基于什么现有能力。
-- **可观察产出：** 完成后用户、调用者或系统外部可以观察到什么。
-- **来源：** `US-###`、`AC-###`、`ADR-###`、`USER-DECISION`、`CODE`、`RESEARCH` 或 `DIAG-###`。
-- **当前事实：** 相关现状与目标差距；项目文件使用项目相对 Path 标签，例如 `<Path>src/example.ts</Path>`。
-- **Planning Depth 原因：** 说明为什么是 Lite、Standard 或 Deep。
+## 行为与范围
 
-## 2. 决策状态
+<描述入口、动作、结果与适用失败行为组成的完整垂直切片。引用 Spec，明确本票 IN/REUSE/OUT 和必要差异，不复制上游合同。>
 
-### 已锁定决策
+## 验收标准
 
-- ...
+- [ ] `AC-001`：<本票可独立验证的结果>。
 
-### 已采用的低影响假设
-
-- 无。
-
-### 未决问题
-
-无。
-
-存在会改变行为、接口、数据、兼容、安全、范围、迁移或验收的问题时，frontmatter 中 `ready` 必须为 `false`。
-
-## 3. 范围边界
-
-| IN（本 Ticket 构建） | REUSE（复用且不改变契约） | OUT（明确不做） |
-|---|---|---|
-| ... | ... | ... |
-
-## 4. 要构建什么
-
-从用户或调用者视角描述一条完整行为路径：入口、动作、可观察结果、失败行为和边界。不要按数据库、后端、前端、测试等技术层分段罗列。
-
-## 5. 实现契约
-
-<!-- Lite 可压缩为适用条目；Standard 和 Deep 必填。 -->
-
-- **入口或接缝：**
-- **输入与输出：**
-- **公共接口变化：** 无 / ...
-- **不变量：**
-- **状态或数据流：**
-- **错误与失败行为：**
-- **兼容要求：**
-- **安全与隐私要求：** 不适用：原因 / ...
-
-## 6. 执行路线
-
-<!-- Lite 通常 1–3 步；Standard 和 Deep 通常 3–7 步。描述行为顺序、安全落点和验证时机，不写逐行代码。 -->
-
-1. 建立或确认验证接缝，使目标行为或关键风险按预期失败。
-2. ...
-3. 形成保持仓库可验证的安全落点。
-4. 运行定向验证和适用回归。
-
-## 7. 路径访问契约
-
-- **预计修改点：** 与 `expected_changes` 对齐，仅作导航。
-- **可写范围：** 与 `writable_paths` 对齐；越界前必须停止。
-- **只读上下文：** 与 `read_only_paths` 对齐。
-- **共享路径：** 与 `shared_paths` 对齐；每项在 `shared_path_owners` 指定唯一 owner。
-- **保留或不动：** 无 / ...
-
-项目路径必须写成项目相对 Path 标签。SpecDev 工件必须使用完整根变量 Path 标签。
-
-## 8. 验证矩阵
+## 验证方法
 
 | 行为或风险 | 验证接缝 | 命令或步骤 | 预期结果 | Evidence |
 |---|---|---|---|---|
-| 正常路径 | ... | ... | ... | `<Path>{roots.state}/specdev/changes/{change}/evidence/T-01.md</Path>` |
-| 失败路径 | ... | ... | ... | `<Path>{roots.state}/specdev/changes/{change}/evidence/T-01.md</Path>` |
-| 回归 | ... | ... | ... | `<Path>{roots.state}/specdev/changes/{change}/evidence/T-01.md</Path>` |
+| ... | ... | ... | ... | `<Path>{roots.state}/specdev/changes/{change}/evidence/T-01.md</Path>` |
 
-不适用的关键风险类别必须写“不适用：原因”。
-
-- **Workspace checks：** 按有效计划或当前 I 执行合同 在 current workspace 或 source worktree 运行单元、组件、静态、类型、lint/build 等适用非 E2E 检查。
 - **E2E disposition：** required / not-required：原因。
-- **E2E owner/environment：** Lead / current-workspace 或 parent-candidate；required 时写明场景、接缝与预期。
-- **Integration evidence：** implementation/source commit、parent before、适用 candidate/result SHA 和父分支包含关系。
-
-E2E 由实际跨边界行为与风险决定，不限于 UI；required 模式不得在 Ticket source worktree 运行或声明通过。
-
-## 9. 发布、迁移与恢复
+- **运行环境：** 按有效执行合同选择 current-workspace 或 source-worktree；required E2E 由 Lead 在 current-workspace 或 parent-candidate 执行。
 
-<!-- Deep 必填；其他深度仅在适用时保留。 -->
+覆盖真实正常、失败和回归风险；不为无关风险制造测试或重复验收条目。
 
-- **迁移顺序：** 不适用：原因 / ...
-- **兼容窗口：** 不适用：原因 / ...
-- **监控信号：** 不适用：原因 / ...
-- **回滚或前向恢复：**
-- **不可逆操作与批准点：** 无 / ...
-- **收缩条件：** 不适用：原因 / 旧调用点、旧数据或旧协议使用量为零并有 Evidence。
+## 执行约束
 
-## 10. 验收标准
+依赖、深度及理由、路径所有权、资源声明和 Skill 调用绑定以 frontmatter 为准；`expected_changes` 仅作导航，实现前核对实际代码。必需项目 Skill 按 `<Path>{roots.workflows}/specdev/common/rules/skill-invocation.md</Path>` 实际调用并保留证据。
 
-- [ ] `AC-001`：<可判定结果>。
-- [ ] 实现开始前已完整读取 Tickets Map，已读取项目 Skill 入口并完整展开其中适用于 `ALL`/`T-01` 的匹配项；新发现的匹配 Skill 已由 Lead 同步回 Map。
-- [ ] 验证矩阵全部执行并记录到 `<Path>{roots.state}/specdev/changes/{change}/evidence/T-01.md</Path>`。
-- [ ] 实际项目修改未超出 `writable_paths`，shared path 由指定 owner 修改。
-- [ ] Ticket 已按有效计划或当前 I 执行合同 策略形成非空 implementation/source commit，direct-parent 或 candidate 验证通过且父分支 result 已记录。
-- [ ] E2E disposition 已执行；required 模式 E2E 在 parent-candidate、current 模式在 current workspace 由 Lead 完成。
-- [ ] 未发生未批准的范围、契约或发布偏差。
-- [ ] Ticket 状态有本票 Evidence 支撑；Tickets Map 的导航、依赖和合同覆盖仍有效，不复制本票进度。
+仅补充绑定字段未表达的本票约束：公共接口差异、不可交换的迁移/安全顺序、用户明确交付数量与必要批准点。局部实现由 I 决定，不要求固定步数。通用停止、检查点、集成和完成合同由执行入口负责。
 
-## 11. SKILL 调用计划
+## 未决事项与风险
 
-依据 `<Path>{roots.workflows}/specdev/common/rules/skill-invocation.md</Path>` 填写 frontmatter 绑定；正文解释每项调用为什么属于本票、具体何时调用、输入定位、输出如何用于下一步。不是仅给出技能名称或阅读列表。没有适用项目 Skill 时写明真实扫描证据；不要保留 unreviewed。
+<仅写适用风险、低影响假设及其验证方式；迁移、兼容、恢复、收缩条件和批准按实际风险展开。没有额外风险时写“无”。>
 
-## 12. 停止、检查点与交付
+存在改变行为、接口、数据、安全、兼容、范围或验收的高影响问题时保持 `ready: false`；记录解除条件与上游 owner。
 
-- **用户交付要求与数量：** 与 Map 的 requested_deliverables 对齐；不为压缩而减少。
-- **必需 Skill/引用/测试不可用：** 阻塞本票，报告缺口，不静默替换默认工具。
-- **归属与资源冲突：** 暂停本票和受影响下游，不接管他人状态；独立票由 map 继续。
-- **检查点：** 记录源版本、绑定摘要、已完成步骤、Evidence 和未闭合动作；恢复前回读。
-- **完成出口：** 全部适用验收及实际 Skill 证据通过，再将结果交回 Goal；未完成项明确列出。
-
-## 工程验收补充（适用时）
+### 未决问题
 
-列明真实消费者/入口、文档和升级说明、错误后的状态保证、恢复责任、旧测试的风险承接，以及代码/输入/配置/Skill 变化时需重验的证据。性能票引用用户操作与基线；documentation 票区分纯说明与模型/用户可见变化。无关项写不适用及理由，不逐项另造 Ticket。
+无。

package/template/workflows/specdev/specdev-t-tickets/assets/tickets-map-template.md

@@ -19,6 +19,8 @@ status: draft
 
 ## 1. 目标与拆分策略
 
+**执行入口：** 获得实现授权后，Lead 与实现执行者读取并执行 `<Path>{roots.workflows}/specdev/specdev-i-implement/SKILL.md</Path>`，再按当前输入实际调用适用项目 Skill。I 负责实现、独立双轴审查、验证与 Evidence；计划本身不授予实现或 Git 操作权限。
+
 引用主要用户故事、验收合同和架构决策，说明所有 Ticket 共同交付的目标、切片原则、prefactor 和 expand-contract 选择。不要复制整个 Spec。
 
 ### 总体实施背景

package/template/workflows/specdev/specdev-t-tickets/references/planning-procedure.md

@@ -1,7 +1,7 @@
 # 拆分 Tickets
 
 
-Ticket 是**决策完备的微型执行计划**：它消除执行者在目标、范围、公共契约、关键顺序和验收上的关键决策，但不展开逐行代码、局部变量或可从现有惯例自然推导的实现细节。
+Ticket 是**可独立验收的垂直行为切片**：它消除执行者在目标、范围、公共契约、关键顺序和验收上的关键决策，但不展开逐行代码、局部变量或可从现有惯例自然推导的实现细节。
 
 本 work 保留原有能力：代码库探索、prefactor 识别、曳光弹垂直切片、真实阻塞边、用户粒度核对、宽重构的 expand-contract 排序、Ticket 独立文件和总体 Tickets Map。
 
@@ -102,27 +102,13 @@ UI 范围同时读取 <Path>{roots.workflows}/specdev/common/rules/design-contra
 
 规划深度不是优先级，也不是 Gate。每个 Ticket 必须记录触发该深度的原因。
 
-### 5. 写成决策完备 Ticket
+### 5. 写成可交接的垂直切片 Ticket
 
 必须按 `<Path>{roots.workflows}/specdev/common/rules/skill-invocation.md</Path>` 填写本票真实调用绑定；Map 中的读取路由不能代替调用。
 
-使用 `<Path>{roots.workflows}/specdev/specdev-t-tickets/assets/ticket-template.md</Path>` 填写：
-
-- 战略目标、可观察产出与来源追踪；
-- 当前代码事实和需求差距；
-- 已锁定决策、低影响假设和未决问题；
-- IN / REUSE / OUT；
-- 用户或调用者视角的端到端行为；
-- Standard/Deep 的接口、输入输出、不变量、数据流、失败与兼容契约；
-- 有序执行路线和安全落点；
-- expected、writable、read-only、shared 路径；
-- 正常、失败和回归验证矩阵；
-- 每个 Ticket 按有效计划或当前 I 执行合同 的 workspace 策略定义 current-workspace/direct-parent 或 source-worktree/parent-candidate 检查，以及按实际跨边界风险判定的 E2E disposition；
-- 每个实现 Ticket 的 implementation commit 与对应父分支完成条件；仅 required 模式创建独立 worktree；
-- Deep 的迁移、兼容窗口、监控、回滚和不可逆批准点；
-- 可判定验收标准。
-
-路径所有权必须遵守 `<Path>{roots.workflows}/specdev/common/rules/path-ownership.md</Path>`，证据设计必须遵守 `<Path>{roots.workflows}/specdev/common/rules/evidence-and-verification.md</Path>`。
+使用 `<Path>{roots.workflows}/specdev/specdev-t-tickets/assets/ticket-template.md</Path>`：正文只写目标与来源、垂直行为与范围、验收和验证、本票执行约束及适用风险。依赖、路径、资源和项目 Skill 调用以原 frontmatter 为准；不在正文维护镜像。
+
+引用上游 AC/ADR，只补充本票差异。公共合同、关键安全顺序和验收必须确定；局部实现选择交给 I。Lite/Standard/Deep 决定需要展开的实际风险，不规定执行步数，也不要求无关栏目逐项填“不适用”。通用实现、独立审查、集成、停止与恢复沿 I 入口执行。
 
 ### 6. 构建依赖 DAG、合同覆盖与并发检查
 

package/template/workflows/specdev/specdev-t-tickets/references/ticket-readiness.md

@@ -21,21 +21,21 @@
 - [ ] 正常、失败和回归至少各有一条验证，或有可信的不适用原因。
 - [ ] 明确 `E2E disposition: required | not-required: reason`；required 场景、预期和接缝可执行。
 - [ ] 按有效计划或当前 I 执行合同 策略定义 current-workspace 或 source-worktree 的非 E2E 检查；E2E owner 固定为 Lead，运行环境分别为 current-workspace 或 parent-candidate。
-- [ ] Ticket 完成合同包含 implementation commit、direct-parent 或 candidate-merge、父分支 result SHA 和 Lead Evidence；仅 required 模式需要独立 worktree。
+- [ ] Ticket 已明确进入 I-implement，由该入口负责 implementation commit、direct-parent 或 candidate-merge、独立双轴审查、父分支 result SHA 和 Lead Evidence；正文不重复通用清单。
 - [ ] Evidence 位置明确为 `<Path>{roots.state}/specdev/changes/{change}/evidence/{ticket-id}.md</Path>`。
 - [ ] 单个全新上下文能够完成；否则已拆分。
 - [ ] 所有内部文件与目录引用使用完整根变量 Path 标签。
 
 ## Standard 门禁
 
-- [ ] 实现契约包含入口、输入输出、不变量、状态或数据流、失败行为和兼容。
-- [ ] 有 3–7 步有序执行路线。
+- [ ] 适用的接口、不变量、失败与兼容合同可由 Spec 和本票差异定位。
+- [ ] 影响安全或正确性的关键顺序已明确；不要求固定数量的执行步骤。
 - [ ] 路径所有权足以支持并发判断。
 - [ ] 验证矩阵可以证明外部行为，而非只检查内部调用。
 
 ## Deep 门禁
 
-- [ ] 迁移顺序、兼容窗口、监控、回滚或前向恢复、收缩条件和批准点完整。
+- [ ] 实际涉及的迁移、兼容、监控、恢复、收缩条件和批准点完整；无关项省略。
 - [ ] 安全、隐私、资金或数据完整性风险有缓解与验证。
 - [ ] 跨 implementation owner 的路径所有权和所选 direct-parent/parent-candidate 集成 Gate 明确。
 - [ ] expand-contract 的收缩条件可通过扫描、指标、查询或测试证明。