@namewta/speculo 1.0.24 → 2.0.1

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

@@ -1,53 +0,0 @@
----
-schema_version: 1
-artifact: code-review
-change: <YYYY-MM-DD-topic>
-review_id: CR-001
-fixed_point: <sha>
-head: <sha>
-status: request-changes
-standards_result: request-changes
-specification_result: skipped
-spec_sources: []
-standards_sources: []
-created_at: <ISO-8601>
----
-
-# Code Review CR-001
-
-## Fixed Input
-
-- **Comparison mode:** baseline / range / commit / pr
-- **Diff:** 实际冻结的 argv；legacy 未声明模式时才采用 `git diff <fixed_point>...<head>`
-- **Diff digest:** 实际 diff 字节的 SHA-256
-- **Original base/head:** 原始不可变引用；fixed_point 为实际比较起点
-- **Commits:** `git log <fixed_point>..<head> --oneline`
-- **Scope:**
-
-## 标准
-
-| Severity | Path / block | Finding | Authority | Satisfied when |
-|---|---|---|---|---|
-
-## 规范
-
-| Severity | Requirement | Finding | Source | Satisfied when |
-|---|---|---|---|---|
-
-规范不存在时写 `skipped:no-spec`，不伪造通过。
-
-## Summary
-
-- **Standards findings:**
-- **Specification findings:**
-- **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 摘要、工具/环境相关证据、两轴隔离核对、复用或重跑的轴与原因。未发生时写“不适用”；本节不是通过声明，也不改变原始审查结果。
-
-## 比较语义与证据有效期
-
-记录 baseline/range/commit/pr、实际 diff argv/digest、原 base/head 与 fixed point、消费者和相关配置/规范版本。合法 no-diff 不创建本 CR；非法引用和根提交无 committed baseline 明确报告。head 或相关输入变更后，核对受影响审查与验证，不沿用旧通过。

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

@@ -1,83 +0,0 @@
----
-id: specdev/diagnose-bugs
-type: workflow-entry
-workflow: specdev
-name: 诊断 Bug
-description: 调查故障并建立精确症状的红灯回路，以单变量实验确认根因；无法安全复现时仅收集事件证据，不将解释冒充根因，也不实施生产修复。
-keywords: [bug, 诊断, 红灯, tight-loop, 根因, 复现, 假设, incident, 事件证据]
----
-
-# 诊断 Bug
-
-> 激活本 Work 后，先读取 `<Path>{roots.workflows}/specdev/README.md</Path>`，再执行本入口。
-
-D 的主导词是**红灯**：没有一条已执行且能在此 bug 上变红的紧凑命令，就没有可进入的假设阶段。D 默认只读项目代码，可以创建 change 诊断工件和经授权的临时可撤销探针；生产修复由 Implement 拥有。
-
-激活时读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前步骤定位输入和证据。
-
-## 输入与所有权
-
-按存在情况读取：
-
-- `<Path>{roots.state}/specdev/changes/{change}/source.md</Path>`
-- `<Path>{roots.state}/specdev/changes/{change}/triage.md</Path>`
-- `<Path>{roots.state}/specdev/changes/{change}/CONTEXT.md</Path>`
-- `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>`
-- 相关代码、测试、配置、日志和运行环境事实。
-
-D 拥有：
-
-- `<Path>{roots.state}/specdev/changes/{change}/diagnosis.md</Path>`
-- `<Path>{roots.state}/specdev/changes/{change}/diagnostics/</Path>`，仅在需要脚本、捕获物或临时探针结果时延迟创建。
-
-## 流程
-
-### 1. 建立并执行红灯反馈回路
-
-加载 `<Path>{roots.workflows}/specdev/D-diagnose-bugs/feedback-loop.md</Path>`。按其顺序尝试测试、HTTP/CLI、浏览器、追踪回放、夹具、模糊循环、bisect、差分和最终 HITL。保存命令、至少一次真实输出、精确症状断言、运行时间、确定性或复现率，以及 Agent 可运行性。
-
-无法建立回路时使用诊断模板写 `status: blocked`、`feedback_loop_ready: false`、已尝试方式和所需输入；假设表保持为空，保留 `current_work`。不得继续阅读代码来构造根因理论并据此宣称已确认；可以进入下述事件证据分支收集观察与下一安全检查，但不能直接进入正式假设实验或 Ready 修复。
-
-**完成标准**：一条已运行命令快速、可重复、由 Agent 执行，并能在用户精确症状上变红。
-
-### 2. 复现并最小化
-
-运行回路确认捕获的是用户报告的故障。逐个删除输入、调用者、配置、数据和步骤，每次删除后重跑；只保留对红灯有负载作用的元素。非确定性 bug 通过并行、压力、固定时间/随机或缩小窗口提高到可调试复现率。
-
-**完成标准**：剩余每个元素被移除都会使回路变绿，最小复现和最后红灯证据已持久化。
-
-### 3. 假设与单变量探针
-
-只有前两步完成后才加载 `<Path>{roots.workflows}/specdev/D-diagnose-bugs/hypothesis-and-instrumentation.md</Path>`。生成 3–5 个带预测的可证伪假设，先展示排名；用户 AFK 时保存 checkpoint 后继续。每个探针只检验一个预测，优先 debugger/REPL，其次定向日志；性能问题使用测量和分析器。
-
-**完成标准**：根因由区分性实验确认，其他高排名候选有反证，所有临时探针有唯一清理标记。
-
-### 4. 写入修复契约
-
-使用 `<Path>{roots.workflows}/specdev/D-diagnose-bugs/diagnosis-template.md</Path>` 写入 diagnosis：触发条件、失败机制、影响范围、漏检原因、必须改变、必须保持、正确 seam、回归测试、非目标、风险和回滚。
-
-存在正确 seam 时，把最小复现定义为 I 必须先观察红灯的回归测试合同；不存在正确 seam 时明确记录架构缺口并路由 R。D 不编写生产修复。
-
-### 5. 清理、验证与路由
-
-重跑原始未最小化回路，确认当前诊断结论可解释症状；搜索唯一 `[DEBUG-...]` 前缀并删除临时插桩，无法删除项登记 owner 与删除条件。运行：
-
-```bash
-node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
-  --stage diagnosis \
-  <Path>{roots.state}/specdev/changes/{change}</Path>
-```
-
-根因确认后将本 Work 加入 `works_run` 并清空 `current_work`，返回 diagnosis 和下一 Work：局部修复进入 Tickets/I，公共行为或高风险进入 S/Tickets，缺 seam 进入 R，仍无根因则保持 blocked 或进入 W。
-
-## 一次性事件与 CI flake
-
-故障不可再次触发或缺安全复现条件时，读取 <Path>{roots.workflows}/specdev/D-diagnose-bugs/references/incident-evidence.md</Path> 进入 evidence-triage。保持原 D ID、diagnosis/diagnostics 和合法状态；事实收集不等于根因确认，未知解释不写入已确认字段。
-
-涉及并发、时钟、子进程或 CI 易抖动测试时，再读 <Path>{roots.workflows}/specdev/common/rules/test-reliability.md</Path>；核对实际 worker/job 拓扑与资源释放，以显式同步制造竞态，不用无证据的 sleep、宽 timeout、全套串行或重试当根因修复。
-
-## 脱敏与强制变异证据
-
-在日志、报告和重现材料中移除 token、Cookie、认证头、秘密配置、个人数据及机器绝对路径；保留项目相对定位和必要错误形态。原始敏感数据不进入长期工件。
-
-如果使用强制变异检验测试敏感性，先记录未变异文件的 hash/diff，实际修改目标后读取 git diff 与运行路径，证明变异已落到执行文件。只有测试因预期行为断言失败才算有效 red；编译错误、未选中测试、变异未落地均为无效证据。恢复原内容，复跑基线并核对 diff。D 输出诊断及修复不变量，正式修复仍交 I。

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

@@ -1,43 +0,0 @@
-# 红灯反馈回路
-
-本文件只负责阶段 1–2。回路尚未满足完成门时，不加载假设或修复材料。
-
-## 构建顺序
-
-按大致顺序穷尽适用方式：
-
-1. 能触及 bug 的失败测试；
-2. 针对开发服务器的 curl/HTTP 脚本；
-3. 固定输入的 CLI 调用和已知良好输出 diff；
-4. 对 DOM、控制台或网络断言的无头浏览器脚本；
-5. 回放真实请求、负载、事件或追踪捕获物；
-6. 启动最小系统子集的一次性夹具；
-7. 属性或模糊测试循环；
-8. 可供 `git bisect run` 使用的状态检查夹具；
-9. 旧/新版本或配置的差分循环；
-10. 最后手段：复制并定制 `<Path>{roots.workflows}/specdev/D-diagnose-bugs/scripts/hitl-loop.template.sh</Path>`。
-
-## 收紧
-
-把回路当作需要优化的产品：缩小启动范围和测试目标；断言精确症状而非“没有崩溃”；固定时间、随机、文件系统与网络。记录一次运行耗时和复现率。
-
-非确定性问题先用 barrier、deferred、可控时钟或独立并发进程建立可观察重叠，再用压力运行补充复现率。定时等待只界定观测预算，不作为断言正确或根因修复的依据；不得以注入 sleep 掩盖缺少同步。
-
-## 最小化
-
-看见正确红灯后，逐项删除输入、调用者、配置、数据和步骤，每次只删除一项并重跑。删除后仍红则永久移除；变绿则恢复。完成时剩余每一项都承载故障。
-
-## 无法建立回路
-
-停止并列出尝试过的方式，请求以下之一：可复现环境、HAR/日志/core dump/带时间戳录屏等捕获物，或临时生产插桩授权。没有红灯不得进入假设。
-
-## 完成门
-
-- 命令已至少运行一次并保存调用与输出；
-- 驱动真实 bug 路径并断言用户精确症状；
-- 结果确定，或有稳定且足够高的复现率；
-- 秒级或已证明是当前最短可行回路；
-- Agent 可无人值守运行，或由结构化 HITL 脚本捕获结果；
-- 最小复现的每个剩余元素都有负载作用。
-
-无法复现时可按 <Path>{roots.workflows}/specdev/D-diagnose-bugs/references/incident-evidence.md</Path> 收集事件事实与下一安全检查；正式假设表和已确认根因保持未就绪。

package/template/workflows/specdev/D-diagnose-bugs/references/incident-evidence.md

@@ -1,21 +0,0 @@
-# 事件证据调查
-
-当故障只发生过一次、暂时无法复现，或缺少安全的运行环境时读取。此分支允许收集事实，不放宽已确认根因的红灯标准。当前 Work 仍为 `specdev/diagnose-bugs`；原 diagnosis 与 diagnostics 承载结果，不新建事故状态或永久知识。
-
-## 可执行的调查
-
-1. 固定事件、时间区间、受影响对象、版本和读权限。按来源定位脱敏日志、trace、变更、配置和相关源码路径，不全面导出生产数据。
-2. 分开写直接观察、来源之间的矛盾、尚缺证据和待验证解释。只读源码可以帮助确定下一步观测点，但解释不进入“已确认根因”或正式假设实验结果。
-3. 按信息增益和风险排列下一安全检查。生产插桩、重放有副作用请求、真实数据修改或对外调用需要原动作明确授权；缺少授权不代表可以换一个入口执行。
-4. 事件材料仍写入 diagnosis 的现象部分与附加事件证据节。`feedback_loop_ready` 保持 false，`red_command/red_evidence` 不伪造，正式假设表保持为空，状态为 reproducing 或 blocked；已确认根因和修复契约明确“尚未确认”。
-5. 写入 <Path>{roots.workflows}/specdev/common/rules/engineering-evidence.md</Path> 规定的 kind=incident 记录，运行 `--stage diagnosis --engineering incident`。校验通过只证明记录满足条件，不表示 bug 已解决或可以 Ready 实施。
-
-## 转入正常诊断
-
-获得一条确实命中精确症状的已运行红灯回路后，再按 <Path>{roots.workflows}/specdev/D-diagnose-bugs/feedback-loop.md</Path> 最小化并进入正式假设/探针。编译失败、未选中测试或基础设施失败不是红灯；临时 probe 要证明落在真实路径并恢复。
-
-反馈回路与确认实验齐全前，不设置 root-cause-confirmed，不移交声称已确认的 Ready 修复。收集完事件材料不把 D 记成根因诊断成功；保留 current_work、缺失证据和恢复入口。用户选择终止调查时按原取消/交接协议处理，不伪造 works_run 或重新打开归档来源。
-
-## 示例
-
-部署后出现一次重复扣款：可以检查脱敏请求 ID、时间、部署 diff 和幂等实现，提出“先核对支付方回执”的安全检查；不能在真实支付端重放以求红灯，也不能仅凭某个可疑分支宣称它就是根因。重复端口错误的 CI 则先核对 worker/job 拓扑和资源分配，使用 <Path>{roots.workflows}/specdev/common/rules/test-reliability.md</Path> 建立确定性观察，不用扩大 sleep 代替原因。

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

@@ -1,33 +0,0 @@
----
-id: specdev/grill-with-docs
-type: workflow-entry
-workflow: specdev
-name: Change 决策访谈
-description: 一个已界定 change 仍有产品、领域或架构决定待确认时进行可恢复访谈；跨 change 边界未清晰时先用 W。
-keywords: [grill, 设计树, 领域, 决策, 共识]
----
-
-# Change 决策访谈
-
-> 激活后读取 `<Path>{roots.workflows}/specdev/README.md</Path>`。
-
-## 读取范围
-
-读取 `<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 或索引。
-
-## 按风险选择问题
-
-涉及失败、重试、取消或恢复时读取 <Path>{roots.workflows}/specdev/common/rules/error-handling.md</Path>：谁拥有状态，何时算成功，超时后副作用是否未知，谁核实结果，什么可以重复，哪些依赖应停止？涉及工具/prompt/context 时再读取 <Path>{roots.workflows}/specdev/common/rules/agent-experience.md</Path>。问题由当前 change 风险触发，不固定全问；仓库能查明的事实先查，高影响取舍才询问用户。
-
-局部 ADR 保留真实问题、采纳决定、考虑过的替代方案、代价、适用范围和验证义务。未确认方案留 LOG/设计树，不编造备选，也不把已采纳但未实现的决定写成已交付。
-
-## 当前 change 的访谈与共识
-
-进入访谈必须读取 `<Path>{roots.workflows}/specdev/G-grill-with-docs/references/interview-procedure.md</Path>`，由该过程在出现设计取舍、术语变化、日志写入或外部 stakeholder 缺口时分别读取 grilling、领域建模、日志格式或 questionnaire；不默认加载所有参考。保留完整 frontier、推荐答案和逐轮共识检查，但不替用户回答高影响取舍。
-
-- 先查仓库可发现事实，只询问会改变行为、架构、风险、范围、迁移或验收的决定。
-- W 的每个 materialized change 在自己的目录拥有设计树和文档；共享答案以来源指针引用，不能共用一棵可写设计树。
-- 当前 change 的 LOG/CONTEXT/ADR 可按 Work 授权写入；永久 namespace 对 G 只读，正式知识只能经 A 的原有写入网关提升。
-- 没有未决的高影响决定且证据可定位才标记共识；无法回答时只暂停相关分支，返回明确问题和恢复入口。
-
-完成后使用 `<Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path>` 的 `--stage grill`，回读四个真实源工件，再交给 `<Path>{roots.workflows}/specdev/S-spec/S-spec.md</Path>`；若属于 W 调查票，只关闭本票并返回探索地图。

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

@@ -1,138 +0,0 @@
-# 设计访谈（带文档）
-
-
-不留情面地访谈用户，直到达成共识。把这件事映射为一棵**设计树（design tree）**：每个决策都会分出挂在它下面的后续决策。
-
-按**轮次**推进这棵树。**前沿（frontier）** 是所有前置条件已经确定的决策——那些现在就能问、不必猜测尚未得到答案的问题。每轮询问完整 frontier；用户的答案会重塑设计树并解除下一层问题的阻塞。
-
-本 work 只把访谈写成当前 change 的可恢复工件：设计树保存进度，LOG 保存讨论轨迹，CONTEXT 保存本 change 已确认的规范语言，ADR 保存已成为本 change 下游合同的架构决定。这些工件不等于项目永久知识，也不构成实现授权；永久 namespace 对 G 只读，只有 `<Path>{roots.workflows}/specdev/A-archive-and-consolidate/A-archive-and-consolidate.md</Path>` 能在实现证据、毕业评估和用户确认通过后执行提升。
-
-
-## 输入与产物
-
-按存在情况读取：
-
-- `<Path>{roots.state}/specdev/config.json</Path>`
-- `<Path>{roots.state}/specdev/adr/</Path>`（只读永久基线）
-- `<Path>{roots.state}/specdev/context/</Path>`（只读永久基线）
-- `<Path>{roots.state}/specdev/changes/{change}/source.md</Path>`
-- `<Path>{roots.state}/specdev/changes/{change}/triage.md</Path>`
-- `<Path>{roots.state}/specdev/changes/{change}/diagnosis.md</Path>`
-- `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`
-- `<Path>{roots.workflows}/specdev/common/rules/artifact-contract.md</Path>`
-- `<Path>{roots.workflows}/specdev/common/rules/planning-principles.md</Path>`
-
-本 work 拥有：
-
-- `<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>`
-- `<Path>{roots.state}/specdev/changes/{change}/questionnaires/</Path>`，仅在第三方 stakeholder 持有阻塞答案时延迟创建。
-
-不存在的可选输入静默跳过，不把缺失文件伪装成已知事实。
-
-## 流程
-
-### 1. 启动或恢复 change
-
-创建或恢复 `<Path>{roots.state}/specdev/changes/{change}/</Path>`。首次启动时创建 `<Path>{roots.state}/specdev/changes/{change}/.status.json</Path>`、`<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>`、`<Path>{roots.state}/specdev/changes/{change}/LOG.md</Path>`、`<Path>{roots.state}/specdev/changes/{change}/CONTEXT.md</Path>`，并以 `<Path>{roots.workflows}/specdev/G-grill-with-docs/design-tree-template.json</Path>` 为模板创建 `<Path>{roots.state}/specdev/changes/{change}/design-tree.json</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/common/rules/context-format.md</Path>`
-- `<Path>{roots.workflows}/specdev/common/schemas/design-tree.schema.json</Path>`
-
-恢复时先读取四份工件，按 design tree 的节点状态恢复，避免重复询问已关闭问题。
-
-**完成标准**：四份工件均可读取；节点依赖无环，所有 LOG 指针存在，当前 frontier 可确定。
-
-### 2. 查找事实
-
-查找*事实*是 Agent 的工作，永远不是用户的。先探索相关代码、配置、接口、schema、测试、历史 ADR 和相邻实现。
-
-当前沿问题需要来自环境的事实时，派遣独立探索去查找。不要阻塞等待：一次进行中的探索是一个未解决的前置条件，所以只有它下游的问题等待结果；现在就继续处理 frontier 的其余部分。不熟悉的外部技术使用 `<Path>{roots.workflows}/specdev/common/skills/research/SKILL.md</Path>`。
-
-将未知项分为：
-
-- 可发现事实：探索或研究，不询问用户；
-- 高影响决策：进入设计树；
-- 低影响实现细节：记录为实现者可自行决定，不制造决策节点。
-
-阻塞答案既不可发现、当前用户也无法回答、但另一个明确 stakeholder 掌握时，加载 `<Path>{roots.workflows}/specdev/G-grill-with-docs/stakeholder-questionnaire.md</Path>`，生成问卷并保存恢复条件；不在本轮继续猜测该分支。
-
-**完成标准**：每个候选问题已分类；用户只接收无法从环境发现的真实决策。
-
-### 3. 建立设计树
-
-围绕目标、角色、范围、主要流程、状态与失败、数据与接口、兼容与迁移、安全与隐私、性能与可观测性、验证与验收建立适用节点。
-
-每个节点包含稳定 `D-###`、标题、问题、依赖、推荐答案和状态。只有问题本身已经可以精确陈述时才创建节点；依赖尚未确定的节点可以存在，但不进入 frontier。
-
-**完成标准**：每个高影响已知决策有且只有一个节点；每条依赖指向真实上游节点；没有默默采用的高影响假设。
-
-### 4. 逐轮推进完整 frontier
-
-加载 `<Path>{roots.workflows}/specdev/G-grill-with-docs/grilling-protocol.md</Path>`。每轮原子增加 `round`，重读设计树并计算完整 frontier。按协议格式给每个问题编号并附推荐答案，然后等待用户回答。
-
-用户回答后：
-
-1. 为每个回答更新对应节点；
-2. 每个节点各追加一条 LOG，不把多个决定压成一条；
-3. 根据回答增加、删除或重新连接后续节点；
-4. 重新计算 frontier，进入下一轮。
-
-一个答案依赖本轮仍开放问题的提问属于后续轮次。用户延后且该决定会影响外部行为、公共接口、数据、安全、兼容、迁移或验收时，保持 blocked，不把它伪装成共识。
-
-**完成标准**：本轮开始时的完整 frontier 每个节点都有回答、明确延后或阻塞记录；所有状态已原子写入并重读。
-
-### 5. 同步 change-local 领域模型
-
-加载 `<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/`；它记录共识生长过程，不授权产品实现。
-
-**完成标准**：LOG、CONTEXT、ADR 和 design tree 无冲突；每个同步结论都有用户回答或事实来源；永久 namespace 未被修改。
-
-### 6. 共识确认与路由
-
-frontier 为空时，向用户确认设计树的每个分支均已走过且已经达成共识。用户指出遗漏时新增节点并继续；只有明确确认后把 design tree 标为 `consensus`。
-
-路由前使用 `<Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path>` 的 `--stage grill` 校验当前 change；失败时保持本 Work 可恢复状态，不发布共识。
-
-随后按成熟度路由：
-
-- 通常进入 `<Path>{roots.workflows}/specdev/S-spec/S-spec.md</Path>`；
-- 外部行为已经完全明确时进入 `<Path>{roots.workflows}/specdev/T-tickets/T-tickets.md</Path>`；
-- 获批的极小局部工作可进入 `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>`；
-- 路径或关键事实仍未知时进入 `<Path>{roots.workflows}/specdev/W-wayfinder/W-wayfinder.md</Path>`。
-
-同步 workflow/change 状态，返回四份权威工件和下一 work 的完整路径。不自动执行下一 work。
-
-## 完成标准
-
-- 设计树的每个适用分支都已走过，没有高影响事项被默默假定；
-- 每轮询问的是完整 frontier，依赖未关闭的问题没有提前出现；
-- 可发现事实由 Agent 查找，没有转交用户；
-- design tree 通过 schema，LOG 指针完整；
-- CONTEXT 只包含当前 change 已确认的规范语言，ADR 只包含满足条件且已成为本 change 合同的架构决定；
-- 永久 `context/`、`adr/` 保持只读，未在 G 中执行知识提升；
-- frontier 为空且用户明确确认共识；
-- 状态、权威工件和下一 work 路径已返回；
-- 未执行产品实现。
-
-## 子文件引用
-
-- 质询协议：`<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/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>`
-
-## 决策记录的完整性
-
-结晶时区分采纳决定与实际落地；ADR 留真实备选、理由、代价、适用范围和验证义务，未确认解释留 LOG。以后路径/命名变化更新当前事实，决定改变则保留取代关系；永久知识仍经 A，不把提案当作已实现。

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

@@ -1,36 +0,0 @@
----
-id: specdev/implement
-type: workflow-entry
-workflow: specdev
-name: 实现与验收
-description: 执行已授权的 Ready Ticket 或获批 Direct Spec，覆盖代码实现与文档维护，产生可回读验收证据；不从模糊需求或只读审查直接写入。
-keywords: [implement, Ticket, TDD, Evidence, integration, documentation, 文档维护]
----
-
-# 实现与验收
-
-> 激活后读取 `<Path>{roots.workflows}/specdev/README.md</Path>`。
-
-## 读取范围
-
-先读 `<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>`；执行过程按当前阶段路由设计、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 状态写入者。
-3. current 模式串行使用当前 workspace；required 模式使用独立 worktree，E2E 由 Lead 在 parent-candidate 完成。实现 commit、父分支推进和集成均需真实授权。
-4. 安全、并发、公共接口、数据迁移或用户要求全面审查时展开 `<Path>{roots.workflows}/specdev/common/skills/code-review/references/risk-review.md</Path>`；不为省上下文删减必要检查或限制发现数量。
-5. 写 Evidence、运行适用校验并回读后才推进状态；必需 Skill 失败、验收失败、越界或归属冲突暂停本票及依赖它的分支。无关工作仍由总控继续，不接管他人事务。
-
-## 专业分支与工程判断
-
-已授权的 documentation Ticket 或获批 Direct Spec，读取 <Path>{roots.workflows}/specdev/I-implement/references/documentation-procedure.md</Path>；它只替换不适用的代码 TDD步骤，不跳过原预检、两轴审查、workspace、授权或完成门。
-
-失败/重试/取消/恢复读取 <Path>{roots.workflows}/specdev/common/rules/error-handling.md</Path>；异步资源、CI flake、替换测试读取 <Path>{roots.workflows}/specdev/common/rules/test-reliability.md</Path>；工具/prompt/schema/结果变化读取 <Path>{roots.workflows}/specdev/common/rules/agent-experience.md</Path>。沿真实调用入口与消费者两端验证，不能用内部函数或 mock 的通过代替产品路径。检查和证据复用只按原证据规范，不默认重跑全仓。
-
-## 返回总控
-
-完成、暂停或重规划后返回 `<Path>{roots.workflows}/specdev/P-goal-plan/P-goal-plan.md</Path>` 的当前 Goal；旧父 O 恢复键继续有效。恢复先核对 HEAD、Ticket/Skill 摘要、证据和未闭合动作，避免重复提交、迁移、发布或正式记忆写入。没有不可变实现证据时不得宣称完成。

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

@@ -1,145 +0,0 @@
-# Evidence: <Ticket ID> — <Ticket title>
-
-本模板按 Goal Plan 的 workspace/integration 策略记录实际验证环境；不适用的环境明确写 `not-applicable`，不伪造 source、candidate 或 result 链。Direct Spec 使用本模板时写入 `<Path>{roots.state}/specdev/changes/{change}/evidence/direct-spec.md</Path>`，以实施前基线和最终 checkpoint 代替 Ticket 集成链。
-
-- **Change：** `<change>`
-- **Ticket：** `<Path>{roots.state}/specdev/changes/{change}/ticket/{ticket-file}.md</Path>`
-- **Spec：** `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`
-- **Goal Plan：** `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>` / 不适用
-- **Lead：** `<owner-or-session-locator>`
-- **Workspace/branch：** `<workspace_ref>` / `<branch>`
-- **Base/implementation-or-source/candidate/result SHA：** `<sha>` / `<sha>` / `<sha>` / `<sha>`
-- **状态：** review / done / blocked / deviated / cancelled
-
-## 1. 实现摘要
-
-用可观察行为与已锁定合同说明实际完成内容。Cancelled 时说明为何无需实现及其权威来源。
-
-## 2. Lead Dispatch And Candidate Return
-
-- **Implementation owner：** Lead / `<agent/provider>`
-- **Dispatch Packet/checkpoint：** Lead direct / `<locator + immutable checkpoint>`
-- **允许动作：** worktree changes / implementation commit / ...
-- **返回：** commit、dirty 状态、修改路径、非 E2E 命令、未验证项与恢复条件
-- **Lead 独立核对：** pass / fail；实际读取与命令摘要
-- **只读 Agent findings：** 无 / 固定输入、来源、结论、Lead 核对
-
-subagent 不写本 Evidence；以上内容由 Lead 从实际 workspace、Git 和返回事实整理。
-
-## 3. 修改范围与路径所有权
-
-| 路径 | 所有权 | 改动目的 |
-|---|---|---|
-| `<Path>src/example.ts</Path>` | writable / shared:<owner> | ... |
-
-- **read-only 修改：** 无
-- **未声明路径：** 无
-- **生成文件/锁文件：** 无 / 来源与 owner
-
-## 4. 验收与合同映射
-
-| Contract / Acceptance ID | 验证接缝 | 证据 | 结果 |
-|---|---|---|---|
-| AC-... | ... | 测试、日志或人工检查摘要 | pass / fail / not-run |
-
-每个 Ticket 验收项恰好落到一行。
-
-## 5. Workspace Verification
-
-按 Goal Plan 记录 current workspace 或 source worktree 检查，并注明运行环境。
-
-| 命令或步骤 | 运行环境 | 结果 | 摘要 |
-|---|---|---|---|
-| ... | current-workspace | pass / fail / not-run | ... |
-
-- **失败后修复与重跑：** 无 / ...
-- **未运行检查：** 无 / 原因与风险
-- **E2E：** 按 Goal Plan 的 E2E disposition 记录；未在本环境运行时说明 owner 与原因
-
-## 6. 双轴审查
-
-标准轴与规范轴保持独立，分别记录固定输入、结果和修正。
-
-### 标准轴
-
-- **固定输入：** `<base_sha>..<source_checkpoint>`
-- **结果：** pass / request-changes
-- **Findings 与修正：** 无 / ...
-
-### 规范轴
-
-- **固定输入与来源：** Spec / Ticket / Goal Plan / source
-- **结果：** pass / request-changes / skipped:no-spec
-- **Findings 与修正：** 无 / ...
-
-两个轴隔离并按上述顺序记录。
-
-## 7. Integration Verification
-
-按 Goal Plan 记录 direct-parent 或 parent-candidate 集成；未采用的字段写 `null` 或 `not-applicable`。
-
-| 项目 | 结果 |
-|---|---|
-| Parent before SHA | `<sha>` |
-| Implementation/source SHA | `<sha>` / `<sha>` |
-| Candidate branch/workspace | current / `<branch>` / `not-applicable` |
-| Method/conflicts | direct-parent / fast-forward / merge-commit；无 / paths |
-| Integration checks | 命令、运行环境 `current-workspace`、结果 |
-| E2E disposition | required / not-required: reason |
-| E2E result | pending / passed / failed / not-required；场景与证据 |
-| Parent result/re-read | `<sha>`；HEAD/tree/ancestor 核对 |
-
-集成失败时明确父 HEAD 是否推进、失败命令、旧 SHA 和恢复条件。
-
-### Failure History And Lead Recovery
-
-| 轮次 | 阶段 | Checkpoint/candidate | 失败事实 | 下一轮变化 |
-|---|---|---|---|---|
-| ... | implementation / review / direct-parent / parent-candidate | `<sha-or-locator>` | blocker、命令与摘要 | 首次失败待定 / Lead 决定 |
-
-- **共同失败模式：** not-applicable / ...
-- **最可能原因：** not-applicable / ...
-- **下一轮具体改变：** not-applicable / ...
-- **下一 owner/路由：** not-applicable / same owner / new owner / Lead / upstream owner
-
-首次失败不要求额外分类；同一 blocker 反复出现、下一轮没有新证据，或 integration attempts 达到有效上限时，Lead 必须填写以上四项。重置 attempts 后仍保留此前轮次，不覆盖失败历史。
-
-## 8. 偏差与决策
-
-- **偏差：** 无 / `<deviation-id>`
-- **记录：** `<Path>{roots.state}/specdev/changes/{change}/LOG.md</Path>` / 不适用
-- **批准来源及影响：** ...
-
-## 9. 残余风险与交付定位
-
-- **残余风险/已知限制：** 无 / ...
-- **后续 Ticket：** 无 / `<ticket-id>`
-- **监控或回滚触发：** 不适用 / ...
-- **Source commit：** `<sha>`
-- **Parent result：** `<sha>`
-- **Source workspace：** `<workspace_ref>`
-- **Evidence：** `<Path>{roots.state}/specdev/changes/{change}/evidence/{ticket-id}.md</Path>`
-
-## Skill Execution Records
-
-按 `<Path>{roots.workflows}/specdev/common/rules/skill-invocation.md</Path>` 从真实执行轨迹填写以下 JSON 数组；每个 required 调用必须唯一匹配 Ticket 的 id、phase、operation 和 sha256，并有 passed 状态及可回读证据。没有绑定时保留空数组。仅阅读入口不能写 passed；失败/未执行保持 blocker，不伪造工具结果。
-
-```json
-[]
-```
-
-## 用户交付与源回读
-
-记录用户要求的实际数量、交付位置、源/链接/必要元数据回读、行为差异、备份和未完成项。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 任务。
-
-## 工程检查的选择与失效
-
-记录为什么选择这些定向检查、覆盖哪些消费者与风险；复用时列原 checkpoint/配置/输入/Skill 与有效性，失效时只列受影响项。测试删除列旧风险到新测试的承接；资源清理记录真正完成信号。专业分支按 <Path>{roots.workflows}/specdev/common/rules/engineering-evidence.md</Path> 在本文件追加标记记录；普通实施不要求空白记录，结构通过不认证真实运行。

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

@@ -1,48 +0,0 @@
-# Execution Preflight
-
-## Ticket 硬检查
-
-- [ ] Ticket frontmatter 可解析，`ready: true`，`status: ready`。
-- [ ] Tickets Map 已完整读取，包含总体实施背景和项目 Skill 读取矩阵；当前 Ticket 被 `ALL` 或自身 ID 覆盖。
-- [ ] 当前 Ticket 映射的项目 Skill 路径均为真实存在的项目根相对入口文件，Lead 已读取入口并完整展开命中的 Skill；implementation subagent Packet 包含 Map 与同一最低必读集合。
-- [ ] 项目 Agent 指令或当前实现范围没有触发矩阵外的未读项目 Skill；发现新匹配项时由 Lead 更新 Map、重新运行 tickets 校验后再恢复项目写入。
-- [ ] 所有 `blocked_by` Ticket 为 done 且 Evidence 存在。
-- [ ] Spec、ADR、Ticket 与 Goal Plan 无冲突；旧 Goal Plan schema 必须重跑 P-goal-plan。
-- [ ] Goal Plan（若存在）为 `lead-directed`，workspace/integration 策略为 `current/direct-parent` 或 `required/candidate-merge`，Lead 可恢复，implementation/integration 上限不超过 config 与平台能力。
-- [ ] 当前代码入口、接口、路径和父分支仍与 Ticket 假设一致。
-- [ ] writable/shared paths 有唯一 owner；current 模式的 Ticket 顺序已固定且没有其他 active implementation writer。
-- [ ] implementation commit 与当前策略对应的 direct-parent 或 local candidate integration/父分支更新已授权；push/PR/remote/deploy 等保持独立。
-- [ ] required 模式的 dev-worktree 记录 schema v6，`base_sha`、父分支、owners、branch、`workspace_ref`、integration 与 E2E disposition 完整；current 模式的 current workspace 记录使用 `workspace_ref: current`、`branch: parent_branch` 和 direct-parent integration。
-- [ ] implementation subagent 若被派遣，Packet 绑定唯一 Ticket workspace 或 current workspace/checkpoint；subagent 不写 SpecDev 状态。
-- [ ] current 模式 source 检查在 current workspace 且不宣称 E2E；required 模式 source 检查明确为非 E2E，required E2E 有 parent-candidate 场景与预期。
-- [ ] 验证命令/环境可用，关键静默失败风险有受控反向验证。
-- [ ] Deep Ticket 批准点已满足。
-- [ ] 若属于父 Implementation Map：父 revision 与 Plan source revision 一致，组合 Ticket 在 tasks/frontier 中，dependency Gate 已满足，serialization lock 可用，派单未重复，workspace 策略一致，全部成员 active implementation 数未超过父上限。
-
-## Direct Spec 硬检查
-
-- [ ] 用户明确批准 Direct Spec；单一行为、局部、低风险、可逆且无需并行/Ticket DAG。
-- [ ] current workspace 只有一个项目与 SpecDev 写入 owner。
-- [ ] 目标、IN/OUT、可写范围、不变量、验证与验收完整。
-- [ ] 实施前 Git checkpoint、dirty 状态和现有用户改动已记录，不覆盖无关改动。
-- [ ] 非 E2E、适用回归与 E2E 验证环境可执行；E2E owner 固定为 Lead。
-- [ ] implementation commit 授权状态明确；未授权时不提交，并在轻量合同与 Evidence 中记录交付状态。
-
-## 失效分类
-
-- **stale-navigation**：导航过时但契约仍有效；更新导航继续。
-- **local-implementation**：局部实现调整不改变契约；记录后继续。
-- **ticket-invalid**：范围、接口、依赖、验证或路径合同失效；停止并修 Ticket。
-- **map-context-stale**：总体实施背景、项目 Skill 矩阵、Ticket 覆盖或 Skill 路径失效；停止项目写入并返回 T-tickets 更新 Map。
-- **spec-invalid / adr-conflict**：返回对应上游 owner。
-- **checkpoint-drift**：current/来源/父分支/派单 checkpoint 漂移；由 Lead 重建执行记录或 required 模式的 worktree/candidate。
-- **workspace-contract-invalid**：缺少父分支、owner、locator、implementation/source/适用 result 字段或授权；停止并修状态/计划。
-- **workspace-strategy-invalid**：Goal Plan 的 workspace/integration 组合非法，或 current 模式出现并发 implementation writer；停止并修状态/计划。
-- **delivery-unverified**：候选、provider 声明或附件不能独立核对；保持 unverified。
-- **e2e-owner-invalid**：required 模式 E2E 被安排在 source worktree，或任一模式不是 Lead owner；停止并修 Ticket/Goal Plan。
-- **direct-parent-invalid**：current 模式的 Ticket commit、父 HEAD、验证或 Evidence 不一致；保留最后可信 commit 并阻塞当前 Ticket。
-- **parent-plan-stale**：父 Implementation Map revision、成员 Ticket、serialization、workspace 策略、全局实现配额或 repository/ref 已变化；停止当前派单并返回 P-goal-plan 重算。
-
-## 验证范围与失败保证
-
-冻结本票真实消费者、配置/构建入口、适用文档与验证命令；不把 DSH 命令当项目事实。只复用输入和环境仍有效的证据；失败副作用未知时按 <Path>{roots.workflows}/specdev/common/rules/error-handling.md</Path> 暂停依赖工作，恢复前沿原 owner 核实，不重放未决动作。

package/template/workflows/specdev/I-implement/merge-conflict-protocol.md

@@ -1,21 +0,0 @@
-# Merge / Rebase Conflict Protocol
-
-只在 `git status` 证明仓库正处于 merge/rebase 冲突时加载。
-
-## 流程
-
-1. 读取 Git 状态、操作类型、冲突路径、base/ours/theirs SHA、Ticket/Evidence 与匹配的 candidate integration 记录。
-2. 从 commit、source、Spec、Ticket、ADR、测试和调用者追溯双方意图；信息不足时不猜产品行为。
-3. 对每个 hunk 写出双方意图、共同约束和唯一可推导结果；需要新行为或上层决定时停止并登记 deviation。
-4. 在授权路径内解决文本，运行受影响的非 E2E 检查；candidate checkout 中按 finalize 合同运行父状态检查/E2E。
-5. 匹配的 local candidate integration 授权包含 `git add`、candidate merge commit、必要的 `git merge --abort` 和 transient candidate checkout/branch 生命周期；不扩展到来源 branch/worktree cleanup 或远端动作。
-6. 需要改变 Spec/ADR、安全/迁移决定、越过 owner 或无法同时保持既有意图时，在 Lead-created candidate 中执行 `git merge --abort`，记录 blocker 并保留来源 worktree；未知普通冲突现场不擅自 abort。
-7. 重读 Git 状态、parents 与 diff，确认无 marker、无未声明路径、双方合同及验证仍成立。
-
-## 完成标准
-
-- 每个 hunk 可追溯到既有意图；
-- 新产品决定没有藏在冲突解决中；
-- 验证记录命令、运行环境、退出码和摘要；
-- Git 副作用来自明确的 candidate integration 或其他逐动作授权；
-- 完成/暂停可以从 Git、change status 和 Evidence 恢复。