@namewta/speculo 1.0.18 → 1.0.20

package/template/workflows/person/S-steelman-deliberation/references/state-and-publication.md

@@ -0,0 +1,86 @@
+# Steelman 状态与候选发布合同
+
+新建、恢复或写入状态前读取状态合同；发布 dossier 时只读取回答前分支，发布 decision 时只读取回答后分支。所有路径、schema 和字段沿用原版，禁止另建状态源。
+
+## 状态合同
+
+### Workflow 状态
+
+`<Path>{roots.state}/person/status.json</Path>` 保持 `schema_version: 1`，本 work 只管理 `active` 数组中的如下条目：
+
+```json
+{
+  "change": "2026-08-18-steelman-company-anniversary",
+  "work_id": "person/steelman-deliberation",
+  "phase": "awaiting-answer",
+  "updated_at": "2026-08-18T00:00:00.000Z"
+}
+```
+
+读取—合并—写入时保留未知顶层字段、未知 entry 字段和其他 work 的全部条目。写临时文件、重读 JSON、再原子替换。
+
+### Change 状态
+
+`<Path>{roots.state}/person/changes/{change}/.status.json</Path>` 至少包含：
+
+```json
+{
+  "schema_version": 1,
+  "artifact": "person-work-status",
+  "workflow": "person",
+  "change": "2026-08-18-steelman-company-anniversary",
+  "work_id": "person/steelman-deliberation",
+  "status": "active",
+  "phase": "awaiting-answer",
+  "key_question": "[唯一关键问题]",
+  "key_question_asked": true,
+  "question_disposition": "asked",
+  "answer_received": false,
+  "user_answer": null,
+  "created_at": "2026-08-18T00:00:00.000Z",
+  "updated_at": "2026-08-18T00:00:00.000Z",
+  "completed_at": null,
+  "blockers": []
+}
+```
+
+允许转换：
+
+```text
+intake → deliberating → awaiting-answer → judging → completed
+任一活动阶段 → blocked
+awaiting-answer → reframe-required
+```
+
+`question_disposition` 只能是 `asked | already-answered`；前者要求 `key_question_asked: true`，后者要求 `key_question_asked: false`。工件先验证，change 状态后更新，workflow active 最后更新。状态只是工件的索引，不替代工件本身。
+
+
+## 回答前：发布 dossier
+
+使用 `<Path>{roots.workflows}/person/S-steelman-deliberation/_templates/steelman-dossier-template.md</Path>` 在 change 目录下的唯一临时子目录中写入候选 dossier 与候选 `.status.json`，重读后运行：
+
+```bash
+node <Path>{roots.workflows}/person/S-steelman-deliberation/tools/validate-steelman-change.mjs</Path> \
+  --phase awaiting-answer \
+  --change-dir <Path>{roots.state}/person/changes/{change}</Path> \
+  --dossier-file <Path>{roots.state}/person/changes/{change}/.steelman-stage/steelman-dossier.md</Path> \
+  --status-file <Path>{roots.state}/person/changes/{change}/.steelman-stage/.status.json</Path>
+```
+
+临时目录名在并发时追加唯一后缀。校验通过后，先原子替换正式 dossier，再原子替换 change `.status.json`；workflow active 只在入口的等待回答阶段 确认需要等待用户时更新。校验失败时删除临时目录并保持正式工件和旧状态不变。
+
+
+## 回答后：发布 decision
+
+使用 `<Path>{roots.workflows}/person/S-steelman-deliberation/_templates/decision-template.md</Path>` 在唯一临时目录中写入候选 decision 与候选完成态 `.status.json`，随后运行：
+
+```bash
+node <Path>{roots.workflows}/person/S-steelman-deliberation/tools/validate-steelman-change.mjs</Path> \
+  --phase completed \
+  --change-dir <Path>{roots.state}/person/changes/{change}</Path> \
+  --decision-file <Path>{roots.state}/person/changes/{change}/.steelman-stage/decision.md</Path> \
+  --status-file <Path>{roots.state}/person/changes/{change}/.steelman-stage/.status.json</Path>
+```
+
+校验通过后才原子替换正式 decision 和 change 状态，并只从 workflow `status.json.active` 删除匹配当前 `change` 且属于本 work 的条目。校验失败时删除临时目录、返回 `validation-failed`，保留可恢复的 `judging` 状态。
+

package/template/workflows/specdev/A-archive-and-consolidate/A-archive-and-consolidate.md

@@ -13,12 +13,7 @@ keywords: [归档, consolidation, ADR, context, research, knowledge, 代码库
 
 A 是 SpecDev 的归档 wrapper：它拥有模式选择、SpecDev 完成门和代码访谈；机械扫描、dry-run、知识毕业、合并、清理、移动与重读由 `<Path>{roots.skills}/archive-and-consolidate/SKILL.md</Path>` 单一维护。
 
-## 读取范围
-
-1. 先读取 `<Path>{roots.workflows}/specdev/README.md</Path>` 与当前 Work 的状态入口。
-2. 再读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前分支、状态和关键词定位最小相关工件。
-3. 只在本 Work 明确要求恢复、冲突、执行安全或归档证据时扩展为全量读取；缺少匹配证据或 owner/gateway 时停止受影响分支。
-
+激活时读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前步骤定位输入和证据。
 
 ## 模式
 
@@ -38,11 +33,7 @@ A 是 SpecDev 的归档 wrapper：它拥有模式选择、SpecDev 完成门和
 
 ## Consolidate-from-code 模式
 
-1. 创建 `<Path>{roots.state}/specdev/changes/{change}/</Path>`、change 状态、LOG、CONTEXT 和 ADR，并登记 `current_work`。
-2. 加载 `<Path>{roots.workflows}/specdev/A-archive-and-consolidate/consolidation-interview.md</Path>`，每轮先探索代码/配置/测试并陈述证据，再一次只问一个真正影响长期理解的问题。
-3. 按 LOG → CONTEXT → ADR 顺序写入：CONTEXT 只保存项目规范术语；ADR 只有同时满足难逆转、令人意外和真实权衡时才创建。
-4. 用户结论必须由当前代码或实际行为验证；未验证内容留在 LOG，不提升。
-5. 按 change completion 规则由本 Work 关闭该非实现型 change，再进入 Archive 模式的 dry-run/确认流程。
+读取 `<Path>{roots.workflows}/specdev/A-archive-and-consolidate/consolidation-interview.md</Path>`，由本 Work 创建知识 change、按代码证据访谈并验证后关闭，再回到 Archive 模式。LOG/CONTEXT/ADR 先在该 change 内形成；未验证结论留在 LOG，不直接提升永久知识。
 
 ## 副作用
 
@@ -57,9 +48,3 @@ Dry-run 不修改文件。归档移动、知识 merge/rewrite/delete、Git 动
 - 源不存在、目标完整、active/archived 无重叠、归档状态正确；
 - 永久知识只包含当前、跨 change 有用且有实现证据的结论；
 - 无未批准移动、删除、改写或 Git 副作用。
-
-## 子文件引用
-
-- 全局归档 Skill：`<Path>{roots.skills}/archive-and-consolidate/SKILL.md</Path>`
-- Change 完成：`<Path>{roots.workflows}/specdev/common/rules/change-completion.md</Path>`
-- 代码访谈：`<Path>{roots.workflows}/specdev/A-archive-and-consolidate/consolidation-interview.md</Path>`

package/template/workflows/specdev/A-archive-and-consolidate/consolidation-interview.md

@@ -38,9 +38,9 @@
 change 内三份文档复用 grill 的既有格式，避免重复发明：
 
 - 设计日志：`<Path>{roots.workflows}/specdev/G-grill-with-docs/log-format.md</Path>`；
-- 领域上下文：`<Path>{roots.workflows}/specdev/G-grill-with-docs/context-format.md</Path>`；
-- 架构决策：`<Path>{roots.workflows}/specdev/G-grill-with-docs/adr-format.md</Path>`；
-- 领域建模规则：`<Path>{roots.workflows}/specdev/G-grill-with-docs/domain-modeling-rules.md</Path>`。
+- 领域上下文：`<Path>{roots.workflows}/specdev/common/rules/context-format.md</Path>`；
+- 架构决策：`<Path>{roots.workflows}/specdev/common/rules/adr-format.md</Path>`；
+- 领域建模规则：`<Path>{roots.workflows}/specdev/common/rules/domain-modeling.md</Path>`。
 
 同步顺序固定：先 LOG，再 CONTEXT，最后 ADR。CONTEXT 只描述当前真相，历史轨迹留在 LOG；未确认的解读不得写成已接受 ADR；与现有永久 ADR 冲突时建立 supersedes 链，不重写历史。高影响条目带来源标识（`USER-DECISION`、`CODE:`、`RESEARCH:`、`ADR-###`）。
 
@@ -51,4 +51,13 @@ change 内三份文档复用 grill 的既有格式，避免重复发明：
 - 缺少必要外部信息或权限，change 标 blocked；或
 - 继续提问只会产生低影响或纯实现细节，交给对应实现阶段决定。
 
-停止后交回入口 §3，进入知识提升评估。未获代码或实际行为验证的结论一律不提升，只留在 change 内。
+停止后返回 A 的 Archive 模式，进入知识提升评估。未获代码或实际行为验证的结论一律不提升，只留在 change 内。
+
+
+## Consolidate-from-code 模式
+
+1. 创建 `<Path>{roots.state}/specdev/changes/{change}/</Path>`、change 状态、LOG、CONTEXT 和 ADR，并登记 `current_work`。
+2. 按上述访谈过程，每轮先探索代码/配置/测试并陈述证据，再一次只问一个真正影响长期理解的问题。
+3. 按 LOG → CONTEXT → ADR 顺序写入：CONTEXT 只保存项目规范术语；ADR 只有同时满足难逆转、令人意外和真实权衡时才创建。
+4. 用户结论必须由当前代码或实际行为验证；未验证内容留在 LOG，不提升。
+5. 按 change completion 规则由本 Work 关闭该非实现型 change，再进入 Archive 模式的 dry-run/确认流程。

package/template/workflows/specdev/C-code-review/C-code-review.md

@@ -13,12 +13,7 @@ keywords: [code-review, review, diff, fixed-point, PR, 标准, 规范]
 
 C 是独立 review 入口，不实施修复。它拥有 `<Path>{roots.state}/specdev/changes/{change}/reviews/</Path>`；I 的最终审查由 I 写入 Evidence，不写本目录。
 
-## 读取范围
-
-1. 先读取 `<Path>{roots.workflows}/specdev/README.md</Path>` 与当前 Work 的状态入口。
-2. 再读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前分支、状态和关键词定位最小相关工件。
-3. 只在本 Work 明确要求恢复、冲突、执行安全或归档证据时扩展为全量读取；缺少匹配证据或 owner/gateway 时停止受影响分支。
-
+激活时读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前步骤定位输入和证据。
 
 ## 输入
 
@@ -28,11 +23,11 @@ C 是独立 review 入口，不实施修复。它拥有 `<Path>{roots.state}/spe
 
 ## 流程
 
-1. **解析固定点**：使用 `git rev-parse` 把固定点和 HEAD 固定为 SHA；PR 先通过 `<Path>{roots.skills}/github-npm-ops/SKILL.md</Path>` 的 `pr-read` 获得 base/head SHA，并确保对应对象可在本地解析。
+1. **解析固定点**：使用 `git rev-parse` 把固定点和 HEAD 固定为 SHA；PR 先通过 `<Path>{roots.workflows}/specdev/T-triage/remote-operations.md</Path>` 的 `pr-read` 获得 base/head SHA，并确保对应对象可在本地解析。
 2. **冻结输入**：记录 `git diff <fixed>...<head>` 和 `git log <fixed>..<head> --oneline`。引用无效或 diff 为空时失败，不创建报告。
 3. **发现来源**：调用 `<Path>{roots.workflows}/specdev/common/skills/code-review/SKILL.md</Path>`；规范来源缺失时经确认跳过规范轴，标准轴继续。
-4. **隔离审查**：平台支持时并行 reviewer，否则用两个独立完整输入包顺序执行。两轴不得读取对方 finding。
-5. **持久化**：选择下一个未占用 `CR-###`，使用模板写入 `<Path>{roots.state}/specdev/changes/{change}/reviews/CR-###.md</Path>`，原子重读。
+4. **隔离审查**：仅按公共 Skill 的完整输入复用门接受既有结果；需要执行的轴在平台支持时并行 reviewer，否则用两个独立完整输入包顺序执行。两轴不得读取对方 finding。
+5. **持久化**：选择下一个未占用 `CR-###`，使用 `<Path>{roots.workflows}/specdev/C-code-review/code-review-template.md</Path>` 写入 `<Path>{roots.state}/specdev/changes/{change}/reviews/CR-###.md</Path>`，原子重读。
 6. **验证与路由**：使用 `<Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path>` 的 `--stage review` 校验当前 change。无阻塞 finding 时返回完成或 I；局部修复生成/修订 Ticket；规范冲突返回 S/G；无法确定的 blocker 保持 C 可恢复状态。
 
 ## 完成标准
@@ -43,9 +38,3 @@ C 是独立 review 入口，不实施修复。它拥有 `<Path>{roots.state}/spe
 - 每个 finding 有路径、风险、依据和满足条件；
 - 报告、状态、验证结果和下一 Work 路径一致；
 - C 未修改项目代码或远程状态。
-
-## 子文件引用
-
-- 公共审查 Skill：`<Path>{roots.workflows}/specdev/common/skills/code-review/SKILL.md</Path>`
-- 报告模板：`<Path>{roots.workflows}/specdev/C-code-review/code-review-template.md</Path>`
-- 报告 Schema：`<Path>{roots.workflows}/specdev/common/schemas/code-review.schema.json</Path>`

package/template/workflows/specdev/C-code-review/code-review-template.md

@@ -40,3 +40,7 @@ created_at: <ISO-8601>
 - **Most severe standards finding:** none / ...
 - **Most severe specification finding:** none / ...
 - **Next Work:** completed / `<Path>{roots.workflows}/specdev/T-tickets/T-tickets.md</Path>` / `<Path>{roots.workflows}/specdev/S-spec/S-spec.md</Path>`
+
+## 审查证据复用（仅实际发生时填写）
+
+记录原 CR/Evidence locator、fixed/head/diff、规范/标准/指令与 Skill/reference 摘要、工具/环境相关证据、两轴隔离核对、复用或重跑的轴与原因。未发生时写“不适用”；本节不是通过声明，也不改变原始审查结果。

package/template/workflows/specdev/D-diagnose-bugs/D-diagnose-bugs.md

@@ -13,12 +13,7 @@ keywords: [bug, 诊断, 红灯, tight-loop, 根因, 复现, 假设]
 
 D 的主导词是**红灯**：没有一条已执行且能在此 bug 上变红的紧凑命令，就没有可进入的假设阶段。D 默认只读项目代码，可以创建 change 诊断工件和经授权的临时可撤销探针；生产修复由 Implement 拥有。
 
-## 读取范围
-
-1. 先读取 `<Path>{roots.workflows}/specdev/README.md</Path>` 与当前 Work 的状态入口。
-2. 再读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前分支、状态和关键词定位最小相关工件。
-3. 只在本 Work 明确要求恢复、冲突、执行安全或归档证据时扩展为全量读取；缺少匹配证据或 owner/gateway 时停止受影响分支。
-
+激活时读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前步骤定位输入和证据。
 
 ## 输入与所有权
 
@@ -75,19 +70,8 @@ node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
 
 根因确认后将本 Work 加入 `works_run` 并清空 `current_work`，返回 diagnosis 和下一 Work：局部修复进入 Tickets/I，公共行为或高风险进入 S/Tickets，缺 seam 进入 R，仍无根因则保持 blocked 或进入 W。
 
-## 完成标准
-
-- 红灯回路硬门有已执行证据；
-- 最小复现的剩余元素都有负载作用；
-- 假设有排名、预测和反证；
-- 根因解释触发、机制、漏检和影响；
-- 修复契约决策完备但未夹带生产修复；
-- debug 插桩已清理或有明确 owner；
-- diagnosis、状态、验证证据和下一 Work 路径一致。
+## 脱敏与强制变异证据
 
-## 子文件引用
+在日志、报告和重现材料中移除 token、Cookie、认证头、秘密配置、个人数据及机器绝对路径；保留项目相对定位和必要错误形态。原始敏感数据不进入长期工件。
 
-- 反馈回路：`<Path>{roots.workflows}/specdev/D-diagnose-bugs/feedback-loop.md</Path>`
-- 假设与插桩：`<Path>{roots.workflows}/specdev/D-diagnose-bugs/hypothesis-and-instrumentation.md</Path>`
-- 诊断模板：`<Path>{roots.workflows}/specdev/D-diagnose-bugs/diagnosis-template.md</Path>`
-- HITL 模板：`<Path>{roots.workflows}/specdev/D-diagnose-bugs/scripts/hitl-loop.template.sh</Path>`
+如果使用强制变异检验测试敏感性，先记录未变异文件的 hash/diff，实际修改目标后读取 git diff 与运行路径，证明变异已落到执行文件。只有测试因预期行为断言失败才算有效 red；编译错误、未选中测试、变异未落地均为无效证据。恢复原内容，复跑基线并核对 diff。D 输出诊断及修复不变量，正式修复仍交 I。

package/template/workflows/specdev/G-grill-with-docs/G-grill-with-docs.md

@@ -15,9 +15,9 @@ keywords: [grill, 设计树, 领域, 决策, 共识]
 
 读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`；定位当前 change 的 `<Path>{roots.state}/specdev/changes/{change}/design-tree.json</Path>`、`<Path>{roots.state}/specdev/changes/{change}/LOG.md</Path>`、`<Path>{roots.state}/specdev/changes/{change}/CONTEXT.md</Path>`、`<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>` 和相关 initiative 决策。先找到相关条目再回读必要原文，不默认整读永久 ADR 或索引。
 
-## 过程与边界
+## 当前 change 的访谈与共识
 
-进入访谈必须读取 `<Path>{roots.workflows}/specdev/G-grill-with-docs/references/interview-procedure.md</Path>`，再按触发分支读取 grilling、领域建模、日志格式或 stakeholder questionnaire。保留完整 frontier、推荐答案和逐轮共识检查，但不替用户回答高影响取舍。
+进入访谈必须读取 `<Path>{roots.workflows}/specdev/G-grill-with-docs/references/interview-procedure.md</Path>`，由该过程在出现设计取舍、术语变化、日志写入或外部 stakeholder 缺口时分别读取 grilling、领域建模、日志格式或 questionnaire；不默认加载所有参考。保留完整 frontier、推荐答案和逐轮共识检查，但不替用户回答高影响取舍。
 
 - 先查仓库可发现事实，只询问会改变行为、架构、风险、范围、迁移或验收的决定。
 - W 的每个 materialized change 在自己的目录拥有设计树和文档；共享答案以来源指针引用，不能共用一棵可写设计树。

package/template/workflows/specdev/G-grill-with-docs/references/interview-procedure.md

@@ -40,9 +40,9 @@
 
 分别使用：
 
-- `<Path>{roots.workflows}/specdev/G-grill-with-docs/adr-format.md</Path>`
+- `<Path>{roots.workflows}/specdev/common/rules/adr-format.md</Path>`
 - `<Path>{roots.workflows}/specdev/G-grill-with-docs/log-format.md</Path>`
-- `<Path>{roots.workflows}/specdev/G-grill-with-docs/context-format.md</Path>`
+- `<Path>{roots.workflows}/specdev/common/rules/context-format.md</Path>`
 - `<Path>{roots.workflows}/specdev/common/schemas/design-tree.schema.json</Path>`
 
 恢复时先读取四份工件，按 design tree 的节点状态恢复，避免重复询问已关闭问题。
@@ -90,7 +90,7 @@
 
 ### 5. 同步 change-local 领域模型
 
-加载 `<Path>{roots.workflows}/specdev/G-grill-with-docs/domain-modeling-rules.md</Path>`。每轮先写 LOG，再把已确认且本 change 下游必须使用的项目规范术语同步到 change CONTEXT，最后把同时满足三个准入条件、已成为本 change 合同的架构决定写入 change ADR。
+加载 `<Path>{roots.workflows}/specdev/common/rules/domain-modeling.md</Path>`。每轮先写 LOG，再把已确认且本 change 下游必须使用的项目规范术语同步到 change CONTEXT，最后把同时满足三个准入条件、已成为本 change 合同的架构决定写入 change ADR。
 
 历史轨迹只留在 LOG；未确认选项不写成已接受 ADR；已有 change ADR 被替代时建立 supersedes 链。同步只更新本 change 工件，不创建、合并或改写永久 `context/`、`adr/`；它记录共识生长过程，不授权产品实现。
 
@@ -127,8 +127,8 @@ frontier 为空时，向用户确认设计树的每个分支均已走过且已
 
 - 质询协议：`<Path>{roots.workflows}/specdev/G-grill-with-docs/grilling-protocol.md</Path>`
 - 设计树模板：`<Path>{roots.workflows}/specdev/G-grill-with-docs/design-tree-template.json</Path>`
-- 领域建模：`<Path>{roots.workflows}/specdev/G-grill-with-docs/domain-modeling-rules.md</Path>`
-- ADR 格式：`<Path>{roots.workflows}/specdev/G-grill-with-docs/adr-format.md</Path>`
-- CONTEXT 格式：`<Path>{roots.workflows}/specdev/G-grill-with-docs/context-format.md</Path>`
+- 领域建模：`<Path>{roots.workflows}/specdev/common/rules/domain-modeling.md</Path>`
+- ADR 格式：`<Path>{roots.workflows}/specdev/common/rules/adr-format.md</Path>`
+- CONTEXT 格式：`<Path>{roots.workflows}/specdev/common/rules/context-format.md</Path>`
 - LOG 格式：`<Path>{roots.workflows}/specdev/G-grill-with-docs/log-format.md</Path>`
 - Stakeholder 问卷：`<Path>{roots.workflows}/specdev/G-grill-with-docs/stakeholder-questionnaire.md</Path>`

package/template/workflows/specdev/I-implement/I-implement.md

@@ -15,9 +15,9 @@ keywords: [implement, Ticket, TDD, Evidence, integration]
 
 先读 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`；从当前 tickets-map 或父 map 定位本票、上游约束、项目 Skill 与执行策略。仅展开当前 Ticket 的正文、直接依赖、适用 Skill 和必要恢复证据，不整读知识库。
 
-## 执行入口
+## 当前票的执行入口
 
-执行必须读取 `<Path>{roots.workflows}/specdev/I-implement/references/implementation-procedure.md</Path>` 和 `<Path>{roots.workflows}/specdev/I-implement/execution-preflight.md</Path>`；这两份合同持有原有 Direct Spec/Ticket、TDD、双轴审查、Git、workspace 与 Evidence 全流程，不得跳过。
+执行必须读取 `<Path>{roots.workflows}/specdev/I-implement/references/implementation-procedure.md</Path>` 和 `<Path>{roots.workflows}/specdev/I-implement/execution-preflight.md</Path>`；执行过程按当前阶段路由设计、TDD、双轴审查和 Evidence；预检单独拥有 Git、workspace、Ready 与授权检查。两者必读，分支参考只在对应 workspace/风险/阶段进入时加载。
 
 1. 核验 Ready、授权、owner、真实源与 map 基线；新增计划型票按 `<Path>{roots.workflows}/specdev/common/rules/skill-invocation.md</Path>` 实际调用绑定能力并记录证据。旧票缺调用契约时先由 Lead 补齐，不猜测。
 2. 保持 codebase-design、design-it-twice 和 TDD 的适用门禁；进入对应实现步骤再读其 reference。派单时调用 subagent-delivery；Lead 是唯一 SpecDev 状态写入者。

package/template/workflows/specdev/I-implement/evidence-template.md

@@ -131,3 +131,11 @@ subagent 不写本 Evidence；以上内容由 Lead 从实际 workspace、Git 和
 ## 用户交付与源回读
 
 记录用户要求的实际数量、交付位置、源/链接/必要元数据回读、行为差异、备份和未完成项。Goal 有显式数量时在 `<Path>{roots.state}/specdev/changes/{change}/evidence/goal-delivery.md</Path>` 写 Delivery Records，与 map 合同逐项核对。字符统计包含移动后的参考文件，不等同于 Token 或套餐用量。
+
+## 审查证据复用（仅实际发生时填写）
+
+记录原 CR/Evidence locator、fixed/head/diff、规范/标准/指令与 Skill/reference 摘要、工具/环境相关证据、两轴隔离核对、复用或重跑的轴与原因。未发生时写“不适用”；本节不是通过声明，也不改变原始审查结果。
+
+## OPS 交付（仅用户请求时）
+
+交付前读取 `<Path>{roots.workflows}/specdev/common/rules/deployment-handoff.md</Path>`，记录当前 change/Ticket、代码 revision、实际构件 digest、AC/Evidence、目标与部署约束；回传时只追加经核对的 Run/Release/receipt 指针。未请求写“不适用”，不为填表创建 OPS 任务。

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

@@ -10,7 +10,7 @@
 
 ### Ticket 模式（默认）
 
-先读取 Tickets Map 的总体实施背景与项目 Skill 读取矩阵，再读取适用于 `ALL` 或当前 Ticket 的项目 Skill，随后读取 Ready Ticket、可选子 Goal Plan 和可选父 Implementation Plan。存在父 Plan 时使用其 Lead、workspace/integration 策略和全局门，即使子 Goal Plan 不存在也可以执行；两者都存在时必须策略一致。没有父 Plan 时沿用子 Goal Plan；两者都不存在时，当前主会话作为该 Ticket 的 Lead，并按 Direct Spec 规则执行，不推断 worktree 策略。`required` 模式每个 Ticket 建立独立 worktree；`current` 模式所有受同一计划约束的 Ticket 严格串行，使用当前分支和当前 workspace。
+使用下节规定的输入顺序。父 Implementation Plan 存在时采用其 Lead、workspace/integration 与全局 Gate，即使子 Goal Plan 不存在；两者都有时必须一致。没有父计划沿用子计划；两者都没有时当前主会话作为 Lead，按 Direct Spec 的轻量边界执行，不猜测 worktree 策略。
 
 ### Direct Spec 模式
 
@@ -51,17 +51,11 @@ Git 已处于 merge/rebase 冲突时，先加载 `<Path>{roots.workflows}/specde
 
 加载 `<Path>{roots.workflows}/specdev/I-implement/execution-preflight.md</Path>`。
 
-Ticket 模式：
+预检参考拥有 Ready、依赖证据、真实 Skill、计划版本、owner、权限、Git 状态与 workspace 的完整检查，不在此复写。
 
-1. 验证 Ready、依赖 Evidence、Spec/ADR/Goal Plan、一致性、路径 owner 和验证接缝；确认 Tickets Map 的总体实施背景、项目 Skill 矩阵、当前 Ticket 覆盖与实际文件均有效，并完成规定读取顺序；
-2. 确认子 Goal Plan schema v6（若存在）与父 Implementation Plan schema v1（若存在）、唯一 Lead、workspace 策略、动态 implementation/integration 上限与授权；
-3. `required` 模式以 `purpose=ticket, operation=create|restore` 调用 `<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>`；`current` 模式读取当前 branch、HEAD、dirty 状态并确认没有其他 Ticket implementation writer；
-4. Lead 把 Ticket 设为 `in_progress`；`required` 模式将 change worktree 记录设为 `active`，`current` 模式建立 current workspace 执行记录；
-5. 当前代码使合同失效时停止并返回对应上游 owner。
+通过预检后：`required` Ticket 以 `purpose=ticket, operation=create|restore` 调用 `<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>`；`current` Ticket 确认当前 branch/HEAD/dirty 状态和单 writer。Lead 设置 Ticket 为 `in_progress` 并按策略登记 active worktree 或 current workspace 记录。Direct Spec 不创建虚假 Ticket/worktree 状态。
 
-Direct Spec 模式验证用户批准、轻量合同和 current workspace 唯一写入 owner；不创建虚假 Ticket/worktree 状态。
-
-**完成标准**：按策略完成 workspace、基线、owners、权限与实际 Git 一致；current 模式只有一个 implementation writer 且 Ticket 串行可恢复。
+**完成标准**：真实 workspace、基线、唯一 owners 和授权与预检一致；代码使合同失效时停止并返回上游 owner，current Ticket 严格串行。
 
 ### 2. Lead 决定自行实现或动态派单
 
@@ -80,13 +74,13 @@ Ticket 模式下，Lead 根据 Ticket 独立性、路径冲突、上下文、风
 
 加载 `<Path>{roots.workflows}/specdev/common/rules/codebase-design.md</Path>`，检查模块、接口、类型、不变量、顺序/错误/性能语义、接缝、适配器、依赖分类、测试观察点和既有公共合同。
 
-存在多个不改变上层契约的局部设计时，可运行 `<Path>{roots.workflows}/specdev/I-implement/design-it-twice.md</Path>`。超出 Ticket 或改变产品/公共合同/数据/兼容/安全时，返回架构审查、Grill、Spec 或 Ticket owner。陌生外部依赖使用 research Skill。
+存在多个不改变上层契约的局部设计时，可运行 `<Path>{roots.workflows}/specdev/common/rules/design-it-twice.md</Path>`。超出 Ticket 或改变产品/公共合同/数据/兼容/安全时，返回架构审查、Grill、Spec 或 Ticket owner。陌生外部依赖使用 research Skill。
 
 **完成标准**：局部设计与上层契约一致，稳定接缝和依赖策略明确。
 
 ### 4. TDD 红→绿垂直循环
 
-加载 `<Path>{roots.workflows}/specdev/I-implement/tdd-rules.md</Path>`、`<Path>{roots.workflows}/specdev/I-implement/tdd-test-design.md</Path>`、`<Path>{roots.workflows}/specdev/I-implement/tdd-mocking.md</Path>` 和 `<Path>{roots.workflows}/specdev/common/rules/code-commenting-rule.md</Path>`。对每个验收行为或关键风险：
+加载 `<Path>{roots.workflows}/specdev/I-implement/tdd-rules.md</Path>`、`<Path>{roots.workflows}/specdev/I-implement/tdd-test-design.md</Path>` 和 `<Path>{roots.workflows}/specdev/common/rules/code-commenting-rule.md</Path>`。对每个验收行为或关键风险：
 
 1. 选择公共接口或稳定接缝；
 2. 编写因目标行为缺失而失败的测试/验证并确认失败原因；
@@ -94,6 +88,8 @@ Ticket 模式下，Lead 根据 Ticket 独立性、路径冲突、上下文、风
 4. 运行定向非 E2E 验证；
 5. 保存 red/green 事实并进入下一条窄切片。
 
+涉及外部依赖、隔离策略或已有 Mock 时，先读取 `<Path>{roots.workflows}/specdev/I-implement/tdd-mocking.md</Path>`，再决定是否复用真实接缝或替身。
+
 不得删除测试、放宽断言、吞错、永久跳过或只验证 Mock 调用次数来制造绿色。
 
 新增或修改代码注释时，先判断信息能否由命名、类型或结构表达，并同步维护受行为变化影响的既有注释。
@@ -126,14 +122,7 @@ Direct Spec 模式由 Lead 在 current workspace 运行轻量合同要求的定
 
 ### 7. 最终集成与适用 E2E
 
-`required` Ticket 模式中，Lead 以 `purpose=ticket, operation=finalize` 调用 dev-worktree：
-
-1. 在最新父分支的 Lead-owned candidate checkout 组合 source commit；
-2. 运行受影响集成/回归、项目父状态检查和 Ticket 标记 required 的 E2E；
-3. candidate 失败时父分支不动，Ticket 回 `in_progress`/`blocked`；
-4. 父 HEAD 漂移时废弃本轮 candidate，基于最新父分支重建并重跑；
-5. 全部通过后父分支 fast-forward 到 candidate/result SHA；
-6. 重读父 HEAD/tree 和 ancestor 关系后，才允许 Ticket Done。
+`required` Ticket 模式中，Lead 以 `purpose=ticket, operation=finalize` 调用 dev-worktree，并读取 `<Path>{roots.workflows}/specdev/common/skills/dev-worktree/references/finalize.md</Path>`。该参考唯一维护最新父分支 candidate 的组合、检查、失败/漂移、重建、fast-forward、回读与尝试上限过程。验证失败或父 HEAD 漂移，父分支不推进；不能凭来源检查通过标记 Done。
 
 E2E 是否需要由 Ticket/Goal Plan 的实际跨边界风险决定，不限于 UI；不适用必须记录原因。
 
@@ -164,29 +153,6 @@ node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
 
 Ticket 模式返回 Ticket/change 状态、Evidence 完整路径、workspace locator、implementation/source、适用 candidate/result SHA、父分支、E2E disposition、适用 Lead 复盘决定、未验证项和下一路由。Direct Spec 返回 change 状态、`<Path>{roots.state}/specdev/changes/{change}/evidence/direct-spec.md</Path>`、current workspace、实施前/最终 checkpoint、适用 E2E 和下一路由。push、PR、remote merge、deploy、migration、生产动作及来源 branch/worktree cleanup 只在独立授权时执行。
 
-## 完成标准
-
-- Ticket 模式按策略完成 current workspace/direct-parent 或 worktree/implementation commit/candidate gate；Direct Spec 的轻量合同、current workspace checkpoint、双轴审查和最终验证完整；
-- current Ticket 的适用 E2E 由 Lead 在 current workspace 运行；required Ticket 的适用 E2E 由 Lead 在 parent-candidate 运行；Direct Spec 适用 E2E 由 Lead 在 current workspace 运行；
-- Lead 独立核对并写全部 SpecDev 工件；
-- Lead 与任何 implementation subagent 都已先读 Tickets Map、再读当前 Ticket 适用的项目 Skill；实现中发现的新匹配 Skill 已同步回 Map 并通过校验；
-- 重复失败或 integration attempt 上限只触发 Lead 复盘；没有 Evidence 中的原因、改变和 owner 决定，不得重置 attempts 或重复派发；
-- current Ticket 父分支只推进到通过的 direct-parent 验证 commit；required Ticket 父分支只推进到通过的 candidate；两者 Ticket Done 都必须与实际 Git 一致；Direct Spec 的完成状态与 current workspace 最终 checkpoint 一致；
-- 实际路径、验证、偏差和状态可由 Evidence 恢复；
-- validator 无 error。
-
-## 子文件引用
-
-- 执行前预检：`<Path>{roots.workflows}/specdev/I-implement/execution-preflight.md</Path>`
-- 代码库设计：`<Path>{roots.workflows}/specdev/common/rules/codebase-design.md</Path>`
-- Design It Twice：`<Path>{roots.workflows}/specdev/I-implement/design-it-twice.md</Path>`
-- TDD：`<Path>{roots.workflows}/specdev/I-implement/tdd-rules.md</Path>`、`<Path>{roots.workflows}/specdev/I-implement/tdd-test-design.md</Path>`、`<Path>{roots.workflows}/specdev/I-implement/tdd-mocking.md</Path>`
-- 代码注释：`<Path>{roots.workflows}/specdev/common/rules/code-commenting-rule.md</Path>`
-- Evidence：`<Path>{roots.workflows}/specdev/I-implement/evidence-template.md</Path>`
-- Agent 交付：`<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>`
-- Worktree：`<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>`
-- 冲突处理：`<Path>{roots.workflows}/specdev/I-implement/merge-conflict-protocol.md</Path>`
-
 ## 计划型票扩展
 
 实施前按 `<Path>{roots.workflows}/specdev/common/rules/skill-invocation.md</Path>` 执行绑定；恢复或上游变化按 `<Path>{roots.workflows}/specdev/P-goal-plan/references/replan-and-recovery.md</Path>` 核验。不以读取替代调用，不因他人任务冲突暂停独立已授权工作。

package/template/workflows/specdev/I-implement/tdd-rules.md

@@ -15,3 +15,7 @@
 - 一个循环只有一个 seam、一个测试和一个最小实现；
 - 测试没有通过删除、跳过、吞错或放宽断言制造绿色；
 - review 前没有以“顺手重构”扩大切片。
+
+## 强制变异验证
+
+使用强制变异时，先保存基线 hash/diff，修改后核对实际执行文件的 diff 与测试选择。只有预期行为断言 red 才有效；编译错误、错测或变异未落地均不计。恢复原内容、复跑基线并核对 diff，把全过程记入 Evidence。诊断协议见 <Path>{roots.workflows}/specdev/D-diagnose-bugs/D-diagnose-bugs.md</Path>。

package/template/workflows/specdev/I-init-setup/I-init-setup.md

@@ -9,134 +9,33 @@ keywords: [初始化, 配置, status, tracking, 验证命令]
 
 # 初始化设置
 
-> 激活本 Work 后，先读取 `<Path>{roots.workflows}/specdev/README.md</Path>`，再执行本入口。
+激活后读取 `<Path>{roots.workflows}/specdev/README.md</Path>`、`<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>` 与 `<Path>{roots.workflows}/specdev/common/rules/path-reference-contract.md</Path>`。本 Work 只配置 SpecDev，不修改业务代码或迁移旧状态。
 
-首次使用 SpecDev、状态根不存在或治理契约发生变化后运行。此 work 只初始化 SpecDev 的状态与配置，不修改项目业务代码。
+## 定位与探测
 
-## 读取范围
+创建任何目录前，从 cwd 向上定位并打开 `<Path>{roots.state}/workspace.json</Path>`，验证 `path_base` 与 roots。只写声明的 `<Path>{roots.state}/specdev/</Path>`；不得把状态根默认展开成项目根 `.speculo`，嵌套安装的项目根 `.speculo/specdev` 非法。根目录未解析或未获授权时停止写入；持久化引用使用根变量，不把机器绝对路径写回模板。
 
-1. 先读取 `<Path>{roots.workflows}/specdev/README.md</Path>` 与当前 Work 的状态入口。
-2. 再读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前分支、状态和关键词定位最小相关工件。
-3. 只在本 Work 明确要求恢复、冲突、执行安全或归档证据时扩展为全量读取；缺少匹配证据或 owner/gateway 时停止受影响分支。
+只读探测包管理、多工作区、构建/测试/类型/lint/CI、默认父分支、worktree、项目 Agent 指令及分支/提交/发布先例；记录根依赖清单、锁文件、共享 schema、迁移索引、全局导出/路由等高冲突资源。能从仓库发现的事实不重复问用户。
 
+确认项目根 `.gitignore` 已含 `specdev-worktree/` 或 `/specdev-worktree/`；该条目由 `speculo init` 唯一维护，缺失时停止并提示重新运行当前版本 CLI，不由 Work 补写。
 
-## 规范输入
+## 选择初始化分支
 
-- 工作流运行合同：`<Path>{roots.workflows}/specdev/README.md</Path>`
-- 路径引用契约：`<Path>{roots.workflows}/specdev/common/rules/path-reference-contract.md</Path>`
-- 配置模板：`<Path>{roots.workflows}/specdev/I-init-setup/config-template.json</Path>`
-- 配置 Schema：`<Path>{roots.workflows}/specdev/common/schemas/config.schema.json</Path>`
-- 全局状态模板：`<Path>{roots.workflows}/specdev/I-init-setup/status-template.json</Path>`
-- 全局状态 Schema：`<Path>{roots.workflows}/specdev/common/schemas/status.schema.json</Path>`
-- Change 状态模板：`<Path>{roots.workflows}/specdev/I-init-setup/change-status-template.json</Path>`
-- Change 状态 Schema：`<Path>{roots.workflows}/specdev/common/schemas/change-status.schema.json</Path>`
+| 当前事实 | 执行 |
+|---|---|
+| 配置或状态不存在 | 读取 `<Path>{roots.workflows}/specdev/I-init-setup/references/first-setup.md</Path>`，仅在首次创建对应文件时读取 `<Path>{roots.workflows}/specdev/I-init-setup/config-template.json</Path>`、`<Path>{roots.workflows}/specdev/I-init-setup/tracking-template.md</Path>`、`<Path>{roots.workflows}/specdev/I-init-setup/domain-layout-template.md</Path>`；只创建缺失骨架；语言、并发、UI 数量与人工批准偏好仅补问尚未知项 |
+| 已有有效配置和状态 | 对照 `<Path>{roots.workflows}/specdev/common/schemas/config.schema.json</Path>`、`<Path>{roots.workflows}/specdev/common/schemas/status.schema.json</Path>` 验证并复用；保留 active、历史、永久知识和用户配置 |
+| 用户要求修改既有配置 | 先验证并展示差异，再按授权更新；不存全局自动提交/集成开关 |
+| JSON 无效、版本未知或契约冲突 | 保留原文件并报告 blocker；迁移只由 `speculo init` 使用 `<Path>{roots.workflows}/specdev/runtime-contract.json</Path>` 中登记的显式 migrator 完成 |
 
-## 流程
+## 验收与返回
 
-### 1. 解析根目录
+配置/全局状态必须可解析且满足 schema；状态、changes、永久 ADR/context/research、archive 与配置目录齐全，tracking/domain-layout 两份配置文档有效。验证命令必须有仓库或用户来源，未知值保留 `null`，不保存秘密。
 
-创建任何状态目录之前，先从 cwd 向上定位并打开 `<Path>{roots.state}/workspace.json</Path>`，校验 `path_base` 与 `roots.*`。只在解析后的状态根下创建 specdev 目录；禁止在声明的状态根之外新建 `.speculo`。
-
-确认：
-
-- 工作流根可解析为 `<Path>{roots.workflows}/specdev/</Path>`；
-- 状态根可解析为 `<Path>{roots.state}/specdev/</Path>`，且必须来自已打开的 `<Path>{roots.state}/workspace.json</Path>`；
-- 当前用户允许在状态根创建目录和工件。
-
-嵌套安装反例：不得把状态根默认展开成项目根 `.speculo`。项目根 `.speculo/specdev` 非法；init 与 Grill 只写入声明的 `<Path>{roots.state}/specdev/</Path>`。
-
-不得把真实绝对路径写回模板或治理文档；持久化引用继续使用根变量。
-
-### 2. 探测项目事实
-
-只读检查仓库根、包管理方式、构建脚本、测试脚本、静态检查、CI、默认分支、项目级 Agent 指令与 worktree 约定。能从仓库发现的事实直接记录，不询问用户。
-
-至少探测：
-
-- 项目测试、类型检查、lint 和构建命令；
-- 是否存在多包或多工作区结构；
-- 默认父分支、Git worktree 支持和项目已有分支/提交约定；
-- 共享高冲突路径的类型，例如根依赖清单、锁文件、全局导出、共享 schema、迁移索引和全局路由；
-- 项目中已有的提交、分支和发布约定。
-
-同时确认项目根 `.gitignore` 存在且包含 `specdev-worktree/`（`/specdev-worktree/` 视为等价）。该条目由 `speculo init` 单一维护；缺失时停止并提示用户以当前 Speculo 版本重新运行 `speculo init`，本 Work 不作为第二写入者修改它。
-
-### 3. 询问不可发现偏好
-
-仅在上下文未提供时询问：
-
-- 交互语言与持久化工件语言；
-- implementation subagent、集成尝试次数和 UI 设计候选上限（初始化时写入 config，Lead 不计入）；
-- Deep Ticket 的迁移、发布和不可逆操作是否必须人工批准；
-
-不询问可由仓库事实回答的文件位置、脚本名或默认分支。
-
-### 4. 写入配置
-
-以 `<Path>{roots.workflows}/specdev/I-init-setup/config-template.json</Path>` 为模板写入 `<Path>{roots.state}/specdev/config.json</Path>`。
-
-要求：
-
-- 字段满足 `<Path>{roots.workflows}/specdev/common/schemas/config.schema.json</Path>`；
-- 验证命令来自仓库事实或显式用户决定；
-- 未确认命令写 `null`，不得虚构；
-- 不写入令牌、凭据、Cookie、个人隐私或敏感环境变量值；
-- Ticket 的实现 commit 与本地 candidate integration 仍由具体 Goal Plan/I-implement 取得授权，不存为全局自动副作用开关。
-
-### 5. 初始化目录与状态
-
-创建或确认以下目录和文件：
-
-- 以 `<Path>{roots.workflows}/specdev/I-init-setup/status-template.json</Path>` 生成 `<Path>{roots.state}/specdev/status.json</Path>`
-- `<Path>{roots.state}/specdev/.config/</Path>`
-- `<Path>{roots.state}/specdev/changes/</Path>`
-- `<Path>{roots.state}/specdev/adr/</Path>`
-- `<Path>{roots.state}/specdev/context/</Path>`
-- `<Path>{roots.state}/specdev/research/</Path>`
-- `<Path>{roots.state}/specdev/archive/</Path>`
-
-若全局状态或 config 已存在，先检查各自 `schema_version`。版本未知、JSON 不可解析或状态与当前 workflow 契约不一致时，停止当前 Work；不得在 Work 内迁移、兼容或猜测旧状态。`speculo init` 只会对 `<Path>{roots.workflows}/specdev/runtime-contract.json</Path>` 已登记且存在显式 migrator 的旧版本升级，其他冲突会保留当前安装并报告具体 blocker。只有状态不存在时才从当前 schema 模板创建。
-
-从模板生成：
-
-- `<Path>{roots.workflows}/specdev/I-init-setup/tracking-template.md</Path>` → `<Path>{roots.state}/specdev/.config/tracking.md</Path>`
-- `<Path>{roots.workflows}/specdev/I-init-setup/domain-layout-template.md</Path>` → `<Path>{roots.state}/specdev/.config/domain-layout.md</Path>`
-
-已有永久知识不得被初始化过程清空。已有配置应先验证和展示差异，再按用户授权更新。
-
-### 6. 验证初始化结果
-
-1. 解析 `<Path>{roots.state}/specdev/config.json</Path>` 和 `<Path>{roots.state}/specdev/status.json</Path>`；
-2. 对照 `<Path>{roots.workflows}/specdev/common/schemas/config.schema.json</Path>` 与 `<Path>{roots.workflows}/specdev/common/schemas/status.schema.json</Path>`；
-3. 确认 `<Path>{roots.workflows}/specdev/I-init-setup/change-status-template.json</Path>` 的字段与 `<Path>{roots.workflows}/specdev/common/schemas/change-status.schema.json</Path>` 对齐；实际创建 change 时替换模板占位符后再执行 Schema 验证；
-4. 确认所有必需目录存在；
-5. 确认两个配置文档均已从对应模板生成；
-6. 确认项目根 `.gitignore` 已忽略 `specdev-worktree/`；
-7. 运行：
+创建 change 前，对照 `<Path>{roots.workflows}/specdev/I-init-setup/change-status-template.json</Path>` 与 `<Path>{roots.workflows}/specdev/common/schemas/change-status.schema.json</Path>`，真实创建时替换占位符后校验；纯初始化不创建虚假的 change。
 
 ```bash
 node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> --self-check
 ```
 
-### 7. 更新状态并汇报
-
-若本 Work 由某个 active change 调用，开始时把该 entry 的 `current_work` 设为 `specdev/init-setup`，完成时将该 id 去重加入 `works_run` 并清空；纯工作流初始化没有 active change 时不创建虚假的 change。时间和验证结果写入本次回复或 change 自有 Evidence/LOG，不写入全局索引。向用户汇报：状态根、语言、验证命令、并发策略、人工批准策略和任何仍为 `null` 的配置项。
-
-## 完成标准
-
-- `<Path>{roots.state}/specdev/config.json</Path>` 与 `<Path>{roots.state}/specdev/status.json</Path>` 可解析且满足 Schema；
-- 状态目录、永久知识目录和归档目录齐全；
-- 两个配置文档已就位；
-- 验证命令与并发规则有来源；
-- 项目根 `.gitignore` 已包含 `specdev-worktree/`；
-- 无敏感值被写入；
-- 包级自检无 error；
-- 存在调用 change 时，其 `works_run` 已包含本 work且 `current_work` 已清空；纯初始化时全局 active 保持真实为空。
-
-## 子文件引用
-
-- `<Path>{roots.workflows}/specdev/I-init-setup/config-template.json</Path>`
-- `<Path>{roots.workflows}/specdev/I-init-setup/status-template.json</Path>`
-- `<Path>{roots.workflows}/specdev/I-init-setup/change-status-template.json</Path>`
-- `<Path>{roots.workflows}/specdev/I-init-setup/tracking-template.md</Path>`
-- `<Path>{roots.workflows}/specdev/I-init-setup/domain-layout-template.md</Path>`
+回读实际配置、状态、目录和忽略项后返回状态根、语言、验证命令、并发/批准策略、未确认配置与检查结果。若由 active change 调用，按原启动/交接合同登记 `current_work`，成功后去重更新 `works_run` 并清空；纯初始化不改已有 active 索引。时间和验证证据留在回复或调用 change 的 Evidence/LOG，不写进全局索引。

package/template/workflows/specdev/I-init-setup/config-template.json

@@ -1,5 +1,5 @@
 {
-  "schema_version": 5,
+  "schema_version": 6,
   "interaction_language": "zh-CN",
   "artifact_language": "zh-CN",
   "git": {
@@ -23,5 +23,9 @@
     "require_evidence": true,
     "ui_design_default_candidates": 3,
     "ui_design_max_candidates": 4
+  },
+  "github": {
+    "include_external_prs": false,
+    "labels": {}
   }
 }