@namewta/speculo 1.0.24 → 2.0.1

package/template/workflows/specdev/common/rules/activation-and-memory.md

@@ -4,11 +4,15 @@
 
 ## Locate before read
 
-1. 先打开 `<Path>{roots.state}/workspace.json</Path>`，从中解析当前 workflow 的 roots、状态索引和稳定 ID；roots 必须来自该文件，不得凭字面猜测。不存在时静默跳过，不能凭旧路径猜测。
+1. 复用当前入口已经明确的项目、方法和数据根。已安装时验证 workspace roots；未安装时使用明确根参数与 Skill 内相对资源，不猜旧路径。根不明只阻塞依赖它的写入；按稳定名称定位所需对象。
 2. 根据当前请求、Work 分支、关键词、稳定 ID、状态和 provenance，先搜索相关索引行或目录项，再定位最小相关 entry；不把索引全文默认装入上下文。
 3. 只回读命中的 entry 和直接 provenance；需要恢复、冲突裁决、归档、迁移或执行安全证明时，才读取该阶段声明的完整证据集合。
 4. 没有匹配证据时返回缺失证据并停止依赖该结论的分支，不补造事实。
 
+## Design retrieval
+
+UI 工作先按 <Path>{roots.state}/specdev/design/</Path> 的索引条目或 scope/规则 ID 定位，再读取命中的 DESIGN revision 和来源。已有 change DESIGN 按它固定的 baseline revision/digest 回读，不静默换成最新版本。永久设计的唯一 owner 是 A，网关为 <Path>{roots.workflows}/specdev/specdev-a-archive-and-consolidate/references/design-knowledge-gateway.md</Path>；首次批准和归档提升遵守 <Path>{roots.workflows}/specdev/common/rules/design-contract.md</Path>。
+
 ## Memory writes
 
 正式知识、永久 context、synthesis 或 archive 写入前，先解析唯一 owner 与 gateway，检查 pending transaction、lock、未完成 promotion 和 recovery evidence。gateway 不明或事务未闭合时，只阻塞记忆写入，继续独立且已授权的审计、定位、验证和其他工作。

package/template/workflows/specdev/common/rules/adr-format.md

@@ -2,13 +2,13 @@
 
 本格式用于 `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>`。这里的 ADR 是当前 change 的架构决定合同，不是已经提升到永久 `<Path>{roots.state}/specdev/adr/</Path>` 的项目 ADR。
 
-只有一个决定同时满足以下三个条件才写 ADR：
+决定对未来有持续价值时写 ADR，以下特征是判断线索，不要求同时满足：
 
 1. 难以逆转；
 2. 没有上下文会令后续维护者惊讶；
 3. 来自真实可行方案之间的权衡。
 
-局部、可逆或没有实质替代方案的选择留在 Ticket/代码。一个 ADR 只表达一个决定。
+局部且无持续价值的选择留在 Ticket/代码；可逆不是拒绝保存重要理由的充分条件。没有真实替代方案时写明事实，不编造权衡。一个 ADR 只表达一个决定。
 
 ```markdown
 ## ADR-###: <标题>
@@ -35,4 +35,4 @@
 
 `accepted` 只表示用户已接受该决定作为当前 change 的下游合同；它不证明实现已经落地，也不代表永久知识毕业。修改已接受决定时新建 change ADR 并建立 supersedes 链，不重写历史。
 
-只有 A 在 change 完成后对照代码、测试和 Evidence 重新验证，并通过毕业评估与用户确认，才能把决定写为永久 ADR；不通过的决定随归档 change 保留。
+只有 A 对照真实来源重新验证，并通过适用价值评估与具体批准，才能提升或独立维护永久 ADR；完成来源以代码、测试和 Evidence 核对，取消来源不能把未实现计划写成现状；不通过的决定随归档 change 保留。

package/template/workflows/specdev/common/rules/agent-experience.md

@@ -1,6 +1,8 @@
 # 面向 Agent 的工具与 Work 体验
 
-修改工具名称、描述、参数、返回、prompt、Work、Skill 或上下文加载时读取。Work 的具名入口 Markdown 就是本工作流的技能入口；保留原 ID 与文件名，不另建技能注册根，也不要求每个 Work 启动子 Agent。
+修改工具名称、描述、参数、返回、prompt、Work、Skill 或上下文加载时读取。Work 的具名入口 Markdown 就是本工作流的技能入口；保留原 ID 与文件名，不另建技能注册根，也不要求每个 Work 启动任务执行者。
+
+普通代码修改不自动触发全库提示词审查。
 
 ## 发现、加载与执行分开
 
@@ -14,10 +16,14 @@ description 写真实触发时机、任务范围和相近但不适用的场景
 
 返回有界的结果摘要以及可回读的 ID、路径或游标，明确截断、遗漏、分页和证据完整性。包含少量当前动作确实需要的邻近上下文，不整页倒出日志，也不因过度裁剪迫使下一步反复搜索。缺少资源、格式无效和加载失败要能辨认，不伪造可用性。
 
+要能区分无结果、读取失败、权限不足和不完整视图。分页未完整不能报告穷尽；有结果句柄不意味着结果已读。
+
 ## 作为行为验证
 
 检查模型真正收到的工具 schema、prompt、结果和诊断，覆盖正常、失败、取消、权限不足、重复调用和恢复中的适用分支。用户直接调用已注入的 Work 不应再次重复加载同一正文。仅宿主支持时才依赖自动/显式调用元数据；文字字段本身不是安全控制。
 
+增加空结果、截断后继续读取等真实行为场景。相同请求反复工具调用、换问法但没有进展时，记录已尝试方法与新增证据；使用原 I/P 的停止和恢复规则，不新建无限自动循环。失败后的副作用与安全动作按 <Path>{roots.workflows}/specdev/common/rules/error-handling.md</Path>。
+
 比较优化前后实际首轮输入、总读取、重复调用、误触发和任务结果。在没有同模型、同工具、同任务的实际使用记录时，只报告文件字符或字节变化，不能宣称 token、费用或配额节省。已有正反任务观察与结构检查分别报告。
 
 方法参考：<Url>https://github.com/deepseek-ai/deepseek-harness/blob/d743267388641bc76f17c45ce8b4c231aed1d32c/.agents/skills/agent-experience/SKILL.md</Url>。SpecDev 不因此获得 DSH 的运行时 Skill 加载器。

package/template/workflows/specdev/common/rules/artifact-contract.md

@@ -2,6 +2,12 @@
 
 SpecDev 通过分层工件避免同一决策被多个模型反复重做。每个工件只承担自己的权威边界。
 
+## 轻量输入与唯一事实
+
+整体结论仅在 change README 顶层唯一 `Outcome: active | completed | cancelled` 行；简单任务的范围、可判定 AC、当前清单、真实验证与下一步也由 README 负责。被工具引用的章节使用唯一显式 `<a id="scope"></a>`、`<a id="acceptance"></a>`、`<a id="verification"></a>` 锚点。无 Ticket 的 Goal 只在原计划维护清单；有独立 Ticket 的进度在票及 Evidence，README/Goal/Map 不复制状态。
+
+工具用临时 `{path, section?}` 定位原文，不创建登记表。存在独立 Spec 默认读取它；仅当前合同允许且 README 等价章节完整时读取 README。两份都自称规格权威时停止裁决，不按时间挑一份。跨 change 集成、Deep、真实并行或复杂设计依赖使用完整工件，迁出位置改成导航；用户明确要求 Spec/Ticket/Goal 时照办。UI 小任务同样保留 DESIGN、具体批准及真实浏览器；LOGIC-only 保留独立验证。无需拆票的轻量任务不制造 Ticket/Map。
+
 ## 1. 工件职责
 
 | 工件 | 具体位置 | 必须决定 | 不应决定 |
@@ -17,7 +23,7 @@ SpecDev 通过分层工件避免同一决策被多个模型反复重做。每个
 | Change 架构决策 | `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>` | 已成为本 change 下游合同的架构决策、原因、后果和替代关系 | 永久项目 ADR 或尚未决定的方案集合 |
 | Spec | `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>` | 用户问题、外部行为、范围、验收合同、非功能要求和已锁定实现约束 | 文件级施工步骤 |
 | Ticket | `<Path>{roots.state}/specdev/changes/{change}/ticket/{ticket-file}.md</Path>` | 单一垂直切片的行为、决策、范围、路径所有权、执行路线和验证证据 | 跨 Ticket 里程碑治理或远程 Issue 编号 |
-| Tickets Map | `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>` | 总体实施背景、项目 Skill 最低调用路由、依赖 DAG、合同覆盖、Ready 投影、并行候选和路径冲突 | 单 Ticket 的完整实现契约 |
+| Tickets Map | `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>` | 总体实施背景、项目 Skill 最低调用路由、依赖 DAG、合同覆盖、Gate 导航、并行候选和路径冲突 | 单 Ticket 的完整实现契约、Ready、状态或执行 owner 副本 |
 | Goal Plan | `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>` | 跨 Ticket 调度、Gate、共享所有权、迁移顺序、集成和偏差治理 | 复制 Ticket 全文 |
 | Implementation Map | `<Path>{roots.state}/specdev/changes/{change}/implementation-map.md</Path>` | Ready 成员、组合 Ticket inventory、跨 change dependency/serialization 与 revision | 创建或改写子 Spec、Ticket 或实现细节 |
 | Implementation Plan | `<Path>{roots.state}/specdev/changes/{change}/implementation-plan.md</Path>` | 父 Lead、全局 workspace/实现上限、frontier/Wave/locks/integration queue 和可恢复进度投影 | 改写子 change 权威或伪造完成 |
@@ -25,32 +31,33 @@ SpecDev 通过分层工件避免同一决策被多个模型反复重做。每个
 | Evidence | `<Path>{roots.state}/specdev/changes/{change}/evidence/{ticket-id}.md</Path>` | 实际修改、命令、结果、验收映射、偏差、风险和提交引用 | 新的产品或架构决策或远程 Issue 正文 |
 | Change 学习图解 | `<Path>{roots.state}/specdev/changes/{change}/learning/index.md</Path>` 与 `<Path>{roots.state}/specdev/changes/{change}/learning/{number}_{topic}.md</Path>` | 面向零专业背景读者解释当前 change 的已验证工件、实现和测试事实；索引按序号持续追加 | 产品决定、架构决定、实现授权或 Learning workflow 知识 |
 | 代码审查 | `<Path>{roots.state}/specdev/changes/{change}/reviews/CR-###.md</Path>` | 固定点、标准轴和规范轴 finding | 实施修复或合并两轴排名 |
-| UI 设计包 | `<Path>{roots.state}/specdev/changes/{change}/prototypes/{design-id}/design-system.md</Path>`、`<Path>{roots.state}/specdev/changes/{change}/prototypes/{design-id}/comparison/</Path>` 与 `<Path>{roots.state}/specdev/changes/{change}/prototypes/{design-id}/final/</Path>` | 项目 UI 证据、功能风格候选、逐层用户决定、设计 token、交互合同和可运行 HTML/CSS/JS 投影 | 生产 UI 实现或替用户确认高影响偏好 |
+| 项目设计基线 | <Path>{roots.state}/specdev/design/DESIGN.md</Path> | 跨 change 的语义 token、组件/交互规范、版本及来源；A 唯一正式写入 | 单次页面设计或未批准提案 |
+| Change 设计合同 | <Path>{roots.state}/specdev/changes/{change}/DESIGN.md</Path> | 本 change 已批准的页面、状态、视觉/交互、基线版本和例外；P 拥有 | 改写永久基线或替代 Spec/ADR |
+| UI 设计包 | `<Path>{roots.state}/specdev/changes/{change}/prototypes/{design-id}/design-system.md</Path>`、`<Path>{roots.state}/specdev/changes/{change}/prototypes/{design-id}/comparison/</Path>` 与 `<Path>{roots.state}/specdev/changes/{change}/prototypes/{design-id}/final/</Path>` | 项目 UI 检测、模板组合、集中批准证据、可运行 HTML/CSS/JS 源码与浏览器证据 | 生产 UI 实现或替用户确认高影响偏好 |
 | Stakeholder 问卷 | `<Path>{roots.state}/specdev/changes/{change}/questionnaires/{slug}.md</Path>` | 第三方原始回答和恢复条件 | 未经转录确认的产品/架构决定 |
 | Wayfinder 地图 | `<Path>{roots.state}/specdev/changes/{change}/wayfinder-map.md</Path>` | 目的地、说明、已关闭决策索引、战争迷雾和范围之外 | 开放 Ticket 正文或答案详情 |
 | Wayfinder Ticket | `<Path>{roots.state}/specdev/changes/{change}/investigation/{investigation-id}.md</Path>` | 一个可精确陈述的问题、类型、阻塞和关闭状态 | 解决方案评论或交付目标 |
 | Wayfinder solution comment | `<Path>{roots.state}/specdev/changes/{change}/investigation/comments/{investigation-id}/NN-solution.md</Path>` | Ticket 的答案、结果事实和资产指针 | 地图索引或产品实现 |
 | 架构审查 | `<Path>{roots.state}/specdev/changes/{change}/architecture-review.md</Path>` | 结构性候选、code-judo 机会、证据、选择和访谈状态 | 未经用户选择的执行契约 |
 
-UI 设计包中的 `{design-id}` 由 P-prototype 分配为当前 change 内最小未占用的 `UI-NNN`；设计系统文档是唯一设计权威，comparison 与 final 不建立第二套规则。
+UI 设计包中的 `{design-id}` 由 P-prototype 分配为当前 change 内最小未占用的 `UI-NNN`；design-system.md 保留文件名但只拥有源码与证据，change DESIGN 是当前设计合同；comparison 与 final 不建立第二套规则。UI 分支按 <Path>{roots.workflows}/specdev/common/rules/design-contract.md</Path> 处理继承、确认、失效与下游硬引用。
 
-Change CONTEXT/ADR 是 active change 内的执行权威，不是 workflow 级永久知识。G 和其他设计/执行 Works 只读 `<Path>{roots.state}/specdev/context/</Path>` 与 `<Path>{roots.state}/specdev/adr/</Path>`；只有 A 在 change 完成、实现证据验证、毕业评估和用户确认后才能写入永久 namespace。未毕业内容随归档 change 保留，不能从 change 工件消失。
+Change CONTEXT/ADR/DESIGN 是 active change 内各自领域的执行权威，不是 workflow 级永久知识。G 和其他设计/执行 Works 只读 `<Path>{roots.state}/specdev/context/</Path>` 与 `<Path>{roots.state}/specdev/adr/</Path>`；ADR/context 的正式写入只有 A 在适用证据、价值评估和具体授权通过后执行；独立维护无需虚构 change，research/非标准 store 仍按实际声明及原 owner 判断，不能自动纳管；design 的首次批准意图发布与归档提升均只经 A 设计网关，按 design-contract 执行。未毕业内容随归档 change 保留，不能从 change 工件消失。
 
 ## 2. 权威顺序
 
-同一事项冲突时按下列顺序裁决：
+先确定问题类型，不以一个万能优先级覆盖全部事实：
+
+- 原始请求由 source 负责；产品目标和真实授权来自用户决定，当前 Spec/README 负责已确认外部行为。
+- 当前实现是什么，以真实源码、运行与验证为证；代码不静默授权修改已批准目标。
+- 长期取舍由 ADR 负责，领域含义和兼容范围由 context 负责；当前工程用法由负责 docs/源码维护，不复制决策全文。
+- 当前 change 的已接受 ADR 约束本次架构；与永久知识冲突必须显式记录替代范围，未通过 A 网关不改永久版本。
+- Ticket 拥有本票范围/依赖/写集/实现证据；Goal 和父 Implementation Map/Plan 拥有各自的 Gate、组合依赖、workspace 与集成安排，不能覆盖子行为合同。
+- 日志与历史解释出处，未确认推断不能提升为当前事实。
 
-1. 用户最新明确决定；
-2. 当前 change 已接受的架构决策：`<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>`；
-3. 永久 ADR 与领域上下文：`<Path>{roots.state}/specdev/adr/</Path>`、`<Path>{roots.state}/specdev/context/</Path>`；
-4. 当前外部行为权威：`<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`；
-5. 当前 Ticket 契约：`<Path>{roots.state}/specdev/changes/{change}/ticket/{ticket-file}.md</Path>`；
-6. 当前跨 Ticket 编排：`<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>`；
-7. 若当前 change 属于父实现 change，父 Implementation Map 对组合 Ticket dependency/serialization 具有权威，父 Implementation Plan 拥有全局 workspace、frontier 与 integration queue；
-8. 当前代码与运行事实；
-9. 旧计划、旧日志和未经确认的推断。
+视觉/交互事项先读取已批准 change DESIGN 和其引用的项目设计 revision；它不能覆盖 Spec 的外部行为或 ADR 的架构决定。缺少确认、内容漂移或规则冲突时返回 P，不由下游重新选择设计。
 
-当前 change 决定与永久知识冲突时，必须在 LOG/ADR 中显式说明替代关系；它只约束当前 change，直到 A 决定是否提升并更新永久版本。
+当前 change 决定与永久知识冲突时，必须在 LOG/ADR（设计事项为 DESIGN overrides）中显式说明替代关系；它只约束当前 change，直到 A 决定是否提升并更新永久版本。
 
 `<Path>{roots.state}/specdev/changes/{change}/source.md</Path>` 只对“原始输入是什么”具有权威；后续用户决定、ADR 和 Spec 可以显式演进该意图。远程来源在摄入后发生变化不会自动改写本地合同，必须重新 Triage。GitHub 上由 publish 投影出的 Issue 不是开发权威；发布计数以 `<Path>{roots.state}/specdev/changes/{change}/publish.md</Path>` 为准。GitHub 上由 capture 记下的 inbox Issue 也不是开发权威；inbox 计数以 `<Path>{roots.state}/specdev/capture.md</Path>` 为准，缺失该文件视为空 inbox。
 

package/template/workflows/specdev/common/rules/change-completion.md

@@ -1,20 +1,22 @@
 # Change Completion
 
-本规则是 change 从 active/blocked 转为 completed 的唯一合同。
+本规则是 change 整体完成或取消的唯一合同。README 的 Outcome 只是结论，必须能沿原工件重建证据；结束不等于已归档。
 
 ## 完成门
 
 一个 change 只有同时满足以下条件才能 completed：
 
 1. 所有计划内 Ticket 为 done，或因权威事实无需改动而记录为 cancelled；Direct Spec/非实现流程有等价验收。
-2. required Ticket 有 source commit、passed candidate、父分支 result SHA，且父分支包含 source commit；current Ticket 有 implementation commit、passed direct-parent 验证和父分支 result SHA；对应 workspace 记录均为完成状态。
+2. required Ticket 有 source commit、passed candidate、父分支 result SHA，且父分支包含 source commit；current Ticket 有 implementation commit、passed direct-parent 验证和父分支 result SHA；对应 Ticket Evidence 的 workspace/集成记录均完整；不要求 JSON 镜像。
 3. 每个行为有 Lead Evidence，全部 Spec 合同与 Goal Gate 可定位。
 4. current Ticket 的 current-workspace 检查/回归和适用 E2E，或 required Ticket 的 source-worktree 非 E2E 检查、parent-candidate 集成/回归和 required E2E 已通过；not-required 有理由。
 5. 迁移、发布、监控、恢复和不可逆批准已完成或明确不适用。
 6. 没有未批准 deviation、blocker、unverified、活动 candidate 或未集成 source checkpoint。
-7. Ticket、Map、Goal Plan、Evidence、change status 与实际 Git 一致。
+7. Ticket、Map 的依赖/导航、Goal Plan、Evidence、README 与实际 Git 一致；不复制单票状态。
 
-Evidence-only Done 和 empty commit 不满足完成门。
+UI 实施还需 Evidence 对照已批准 change DESIGN、固定基线与页面/状态验收；原型截图不代替实现的真实渲染。设计漂移或未确认例外按 <Path>{roots.workflows}/specdev/common/rules/design-contract.md</Path> 返回 owner，不能以票全 done 消除缺口。
+
+Evidence-only Done 和 empty commit 不满足完成门.
 
 父实现 change 还必须满足 `<Path>{roots.workflows}/specdev/common/rules/parent-implementation-orchestration.md</Path>`：全部成员 completed，Implementation Map 与 Implementation Plan completed 且 revision 一致，跨 change 全套验证通过，`<Path>{roots.state}/specdev/changes/{change}/evidence/implementation-orchestration.md</Path>` 完整，没有活动派单、candidate、serialization lock 或未裁决冲突。父完成不自动归档或移动任何成员。
 
@@ -25,7 +27,7 @@ Evidence-only Done 和 empty commit 不满足完成门。
 - 非实现型终点：最终验收工件 owner 使用本规则。
 - 父实现 change：Implementation Plan 的唯一 Lead 在全部成员与 aggregate gate 关闭后拥有转换。
 
-Owner 原子更新 `<Path>{roots.state}/specdev/changes/{change}/.status.json</Path>` 的 `change_status`、`completed_at`、`updated_at` 和 `current_work`，然后重读。全局 status 只维护 active/archived 索引。
+Owner 依据来自原 Goal/Implementation Plan、I 的真实会话或非实现验收工件，不由调用方任意声明。门全部通过后，重验 README 旧字节和证据，由同一 owner 原子更新 <Path>{roots.state}/specdev/changes/{change}/README.md</Path> 唯一 `Outcome: completed` 行并链接完成依据，再重读；不连带改票时间戳或复制进度。轻量任务由 README 的范围、逐 AC 实际结果、适用验证和下一步承接等价证据；用户要求的独立工件和复杂实现门不得省略。
 
 ## 远程来源与归档
 
@@ -38,3 +40,20 @@ Owner 原子更新 `<Path>{roots.state}/specdev/changes/{change}/.status.json</P
 仅有 R-retro（可先经 T intake）的 review-only change，以 completed 的 RETRO 报告作为等价验收；不能同时存在 Spec、Ticket、Map、Goal Plan、implementation 工件、Evidence 或 worktree。报告 sources 非空、结果诚实、全部验收完成，owner 按原完成转换规则更新状态；存在实现工件时仍走原实现完成门。insufficient-evidence 仅表示报告完整，不表示问题已解决。
 
 PR requested=true 且 status=planned/failed 时阻塞归档；delivery_target=ready 时 draft 也保持未闭合。draft 目标可由 draft/ready 满足，ready 目标只由 ready 满足；waived 须记录放弃交付的授权与原因。创建成功不等于已授权 merge。独立 TRI 不因关联 change 就参与完成/归档门。
+
+## 整体取消
+
+只有真实用户取消请求发生时，由原完成 owner 核对并记录：决定来源、范围和时间；未交付内容与已落地代码/数据/设计/远程影响；活动 writer 已停止或明确交接的证据；父子依赖、未集成 checkpoint/candidate 的处置；已承诺外部动作的结果或明确放弃/转交依据；后续 owner、保留材料和恢复限制。记录放 README 或原 Goal 决定章节并链接，齐全后重验旧字节，写入唯一 `Outcome: cancelled` 并重读。
+
+A 只验证取消结果，不代替用户取消。单 Ticket cancelled 不推导整体取消；不批量改票为 done/cancelled，不自动回滚、远程关闭或删除 branch/worktree。未知外部结果继续阻塞归档；超时/无响应不能证明 writer 结束。已发布 DESIGN revision 保留，未实现候选随 change 保存；cancelled 不满足 promotion 的 implemented 完成来源门。
+
+
+## 轻量证据与取消的只读语法
+
+轻量 README 使用唯一 scope/acceptance/verification 显式锚点，acceptance 列可观察的 AC-n。完成时 verification 表使用 `AC | Result | Evidence`（可选 SHA256 列），每个 AC 恰一行 `passed` 和可回读实际证据 locator；提供摘要时必须匹配真实字节。证据可用 #anchor 指向同 README 的独立证据段，不能指向 Outcome/Ownership 或该结果声明自身，记录 `Method`、`Source`、`Observed`、`Result: passed`；有 `Command` 时须 `Exit: 0`。实际运行后才形成，不为 active 任务先造空证据；静态字段只供回读，不认证语义真实性或授权。
+
+无 Goal 的 owner 在 README `## Ownership` 写 `Owner` 与 `Evidence`；后者指向实际会话/交接原文或同 README 的独立证据锚点，其 `Owner` 或 `Session` 必须匹配。若动作绑定 `Work`，原证据必须同值；不是每 Work 调用登记。
+
+取消在 README `<a id="cancellation"></a>` 下保留 `Source`、`Scope`、`Time`（实际 ISO 时间）、`Confirmed-By`（原 owner）、`Undelivered`、`Landed`、`Writers`、`Dependencies`、`Checkpoints`、`External`、`Next`。Source 指向真实取消决定原件或同 README 的独立原请求锚点，不能以取消结论自证。Writers 为 `none: <依据>` 或 `stopped: <停止/交接证据 locator>`；后者原件须有 `Writers: stopped` 与真实 Observed。Dependencies/Checkpoints/External 使用 `none|resolved|transferred|waived: <处置依据>`，不能把未知写成已解决。活动/review/integrating/blocked 的执行记录仍须原 owner 处置，不由取消声明抹掉。
+
+独立 Spec 的无票 Direct Spec 使用原 evidence/direct-spec 的 `## Acceptance Verification` JSON array 逐 AC 回读实际结果：id/result/method/source/observed；command 存在时 exit 为 0，外部 evidence 引用须有匹配 sha256，内联观察无需另建文件。空 Evidence、仅标题或 passed 自评不通过。`--stage complete` 只判本地完成；A 移动前使用 `--stage archive-ready` 同时核对对应 completed/cancelled 门和已承诺远程交付，目标移动后再使用 archived。

package/template/workflows/specdev/common/rules/design-contract.md

@@ -0,0 +1,51 @@
+# UI 设计权威、批准与继承
+
+P 创建 UI 包，或 S/T/I/C/W 消费 UI 决定时读取。纯 LOGIC 和没有 UI 影响的 change 不强制生成 DESIGN；不能以缺少 UI 工件阻塞独立的后端工作。
+
+## 三层产物与 owner
+
+| 层 | 位置 | 权威与 owner |
+|---|---|---|
+| 项目设计基线 | <Path>{roots.state}/specdev/design/DESIGN.md</Path> | 跨 change 的视觉语言、语义 token、组件与交互规范；唯一正式写入 owner 为 A |
+| Change 设计合同 | <Path>{roots.state}/specdev/changes/{change}/DESIGN.md</Path> | 本 change 的页面、任务流、状态、响应式、基线引用与已批准例外；P 写入并维护 |
+| 原型源码与证据 | <Path>{roots.state}/specdev/changes/{change}/prototypes/{design-id}/design-system.md</Path> | P 拥有项目检测、候选来源、HTML/CSS/JS 源码、验证和批准证据；不再重复拥有设计规则 |
+
+`design-id` 为当前 change 内最小未用的 `UI-NNN`。每个 UI 包引用同一 change DESIGN 的适用页面/规则；不能以新包覆盖其他已批准页面。comparison 与 final 是源码投影，项目内预览是有明确写集的临时验证。CONTEXT 拥有产品事实，ADR 拥有架构决定，Spec 拥有外部行为；DESIGN 不夺取这些职责。
+
+初始化只创建空的 <Path>{roots.state}/specdev/design/</Path>，不从模板预填品牌或创建已批准 DESIGN。根项目已有 <Path>DESIGN.md</Path> 或其他设计规范时记录实际 locator 和 owner；不得自动覆盖或同步出第二套可写基线。
+
+## 基线生命周期
+
+1. 先按 design 索引的 app、页面、关键词或规则 ID 定位，再读取相关原文与 provenance。已有基线时核验 revision/digest 与代码；未声明 rebrand 的局部变更继承它。
+2. 没有基线时先检测现有 token、组件和真实页面；新项目明确没有既有事实。P 在 change 内准备 baseline draft，观察值、用户约束与待验证建议分开。持久化草案不等于永久知识。
+3. 默认先自动组合模板并生成 HTML，再把基线差异、候选、推荐最终页、关键交互和提升范围作为一次初始批准包展示。用户可以选择、组合、修改或拒绝；不逐项追问可由代码或模板推导的 CSS 偏好。首次批准前，将候选基线的确定 revision/designDigest 预绑定到 draft DESIGN，以 draft 状态及包内发布记录明确它尚未发布，并连同候选完整字节 SHA-256、HTML 摘要及当前基线 CAS 条件一并展示。这样批准涵盖最终规范内容；发布后仅验证同一内容落盘。临时发布状态保存在包/回执中，不写入会改变 designDigest 的规范正文。
+
+4. 包获批后，P 通过 <Path>{roots.workflows}/specdev/specdev-a-archive-and-consolidate/references/design-knowledge-gateway.md</Path> 请求 A 创建首次永久基线；该嵌入网关保持调用方原 owner，不执行整项归档。P 无永久目录直写权。已有基线的普通 change 仅记录 delta，不能借初始批准覆盖永久基线。正式 baseline 的不可变快照保存到 <Path>{roots.state}/specdev/design/revisions/{revision}.md</Path>，`revision` 来自网关验证的 DESIGN-NNNN；恢复和历史 change 按引用版本读取，不静默替换为 current。
+
+5. 实施与验证后，A 在归档阶段按同一网关评估共享规则，生成 promotion diff 并在原授权范围内写入；一次性页面内容、未采纳方向、纯原型设想不提升。保持原 ID、来源和替代关系；未提升内容随 change 归档。
+
+基线冲突、未知 owner、未闭合事务或相关锁只阻塞永久写入及依赖分支。仍可完成独立的检测、草案和候选，但不得把未成功发布的基线当作已存在。正式写入前后遵循 activation-and-memory 的定位、事务检查、原子写入与回读。
+
+## 批准与失效
+
+用户批准绑定具体 change DESIGN 内容、基线版本和原型文件摘要，并记录可回读的确认来源。发布批准的 record.path/sha256 绑定不可追加改写的本次确认快照；LOG 追加其定位和回执。项目根已有设计规范时保留原 owner，以 derived-readonly 和根文件字节摘要明确只读派生关系。模板推荐和 Agent 自评不构成人类批准。用户已指定方向或已授权自主组合时直接完成 HTML；仍需取得最终 HTML/交互与设计合同的集中确认，不额外要求重复的风格选单。
+
+HTML、交互、设计合同、引用基线或影响布局的输入变化时，旧批准只对原摘要有效。先标记受影响部分待重新确认，完成新证据后再批准；无关页面不重新访谈。多个原型包与历史失败包并存时按 `--prototype-id UI-NNN` 选择本次目标，不能以任意一个 ready 包掩盖当前包失败。
+
+## 下游硬引用
+
+- **S**：UI 范围的 Spec 明确引用 change DESIGN、项目基线版本与原型 ID；将页面/状态映射到 AC。设计未批准或漂移时 UI 合同不可 Ready，返回 P。
+- **T**：UI Ticket 使用 ui_change=true、design_ref={revision,digest,pages,acceptance}，Map 引用同一版本和适用规则；实现票明确只读设计来源、组件复用边界与视觉/交互验收。不可让执行者重新选风格。
+- **I**：预检重算 design_ref 引用和摘要；按已批准设计实现，在 Evidence 的 Design Conformance 记录 digest/page/AC 与真实页面、原型差异、视口及任务证据。发现设计无效返回 P，行为冲突返回 S，不能修改设计文件给实现偏差补票。
+- **C**：规范轴读取适用 DESIGN 与批准证据，区分规则偏离、未验证 UI 与可接受实现差异；审查不代替用户确认。
+- **W**：solution comment 只保留 change DESIGN、指定 UI 包和 comparison/final 的定位与证据。探索原型不是 child change 的默认批准；child 复用时必须绑定自身范围并验证引用。
+
+下游必须实际读取引用内容；仅写路径或模板中的 `approved` 文本不算已消费。纯 LOGIC 仍用自身 logic.md/hash/浏览器合同，不生成虚假 UI DESIGN。
+
+## 质量与证据
+
+先做独立的视觉/任务 critique，再做可机械验证的 audit，最后按严重程度修复和 polish。检查产品特征、层级、字体、密度、色彩语义、完整状态、键盘/focus、缩放、触屏、长文案、响应式和 reduced motion。审美反模式是诊断提示，用户约束与已批准项目体系优先；检测器无告警不证明设计优秀。
+
+浏览器证据必须来自实际打开的本次产物，保存工具、环境、视口、操作、结果和截图相对路径。至少覆盖桌面与窄屏，适用手势单独操作；模拟 viewport 不证明真实触屏。无浏览器时可交付 draft，但不能 ready。原型 mock 只证明原型，不证明真实服务、生产性能或真实用户研究。
+
+schema 与 hash 校验由 <Path>{roots.workflows}/specdev/common/tools/design-artifacts.mjs</Path> 和 <Path>{roots.workflows}/specdev/specdev-p-prototype/scripts/validate-design-package.mjs</Path> 承担；通过结构校验后仍需上述人工批准及运行证据。归档引用按 `--stage archived` 验证，不能用活动 change 的路径判断历史失效。

package/template/workflows/specdev/common/rules/design-it-twice.md

@@ -1,6 +1,6 @@
 # 设计两次
 
-当用户想要为选定的深化候选探索替代接口时，使用此并行子 Agent 模式。基于 "Design It Twice"（Ousterhout）— 你的第一个想法不太可能是最好的。
+当用户想要为选定的深化候选探索替代接口时，使用此并行任务执行者 模式。基于 "Design It Twice"（Ousterhout）— 你的第一个想法不太可能是最好的。
 
 使用 `<Path>{roots.workflows}/specdev/common/rules/codebase-design.md</Path>` 中的词汇 — **module**（模块）、**interface**（接口）、**seam**（接缝）、**adapter**（适配器）、**leverage**（杠杆）。
 
@@ -8,28 +8,28 @@
 
 ### 1. 界定问题空间
 
-在启动子 Agent 之前，为选定候选编写一份面向用户的问题空间说明：
+在启动任务执行者 之前，为选定候选编写一份面向用户的问题空间说明：
 
 - 任何新接口需要满足的约束条件
 - 它将依赖的依赖项，以及它们属于哪个类别（参见 `<Path>{roots.workflows}/specdev/common/rules/codebase-design.md</Path>` 的“依赖类别”）
 - 一个粗略的示例代码草图来使约束具体化 — 不是提案，只是让约束变得具体的一种方式
 
-将此展示给用户，然后立即进入第 2 步。用户在子 Agent 并行工作时阅读和思考。
+将此展示给用户，随后进入第 2 步；有工具派遣时用户可同时阅读和思考。
 
-### 2. 启动子 Agent
+### 2. 启动任务执行者
 
-使用 Agent 工具并行启动 3+ 个子 Agent。每个子 Agent 必须为深化后的模块生成一个**截然不同的**接口。
+按共享编排方法选择执行方式：可派遣时建立至少 3 个独立候选；Lead 模式按相同约束依次完成至少 3 个候选。每个任务执行者 必须为深化后的模块生成一个**截然不同的**接口。
 
-为每个子 Agent 提供一份独立的技术简报（文件路径、耦合细节、来自共享设计规则的依赖类别、接缝背后的内容）。简报独立于第 1 步中面向用户的问题空间说明。给每个 Agent 一个不同的设计约束：
+为每个任务执行者 提供一份独立的技术简报（文件路径、耦合细节、来自共享设计规则的依赖类别、接缝背后的内容）。简报独立于第 1 步中面向用户的问题空间说明。给每个 Agent 一个不同的设计约束：
 
 - Agent 1："最小化接口 — 目标 1–3 个入口点。最大化每个入口点的杠杆。"
 - Agent 2："最大化灵活性 — 支持多种用例和扩展。"
 - Agent 3："为最常见的调用方优化 — 让默认情况变得简单。"
 - Agent 4（如适用）："围绕接缝设计端口与适配器，以处理跨接缝依赖。"
 
-在简报中同时包含共享设计规则的词汇和 CONTEXT 词汇，以便每个子 Agent 能使用架构语言和项目的领域语言一致地命名事物。
+在简报中同时包含共享设计规则的词汇和 CONTEXT 词汇，以便每个任务执行者 能使用架构语言和项目的领域语言一致地命名事物。
 
-每个子 Agent 输出：
+每个任务执行者 输出：
 
 1. 接口（类型、方法、参数 — 以及不变量、排序、错误模式）
 2. 使用示例，展示调用方如何使用它
@@ -45,4 +45,4 @@
 
 ## SpecDev 门禁
 
-本模式只探索接口，不修改代码。只有 Ticket 允许局部设计自由且候选不改变已锁定契约时可由实现者选择；涉及公共接口、数据、兼容、安全、范围或验收时停止并升级到 Ticket/ADR，暴露更广架构问题时返回 `<Path>{roots.workflows}/specdev/R-review-architecture/R-review-architecture.md</Path>`。
+本模式只探索接口，不修改代码。只有 Ticket 允许局部设计自由且候选不改变已锁定契约时可由实现者选择；涉及公共接口、数据、兼容、安全、范围或验收时停止并升级到 Ticket/ADR，暴露更广架构问题时返回 `<Path>{roots.workflows}/specdev/specdev-r-review-architecture/SKILL.md</Path>`。

package/template/workflows/specdev/common/rules/design-portability.md

@@ -0,0 +1,48 @@
+# 设计合同的离线消费、导出与恢复
+
+单文件能力消费 UI 决定、需要首次基线发布或归档提升，而宿主不具备原项目工具时使用。本文保留相同 owner、摘要和批准门；不能把不可执行工具的名称当作已执行能力。纯 LOGIC 与无 UI 影响的工作独立继续。
+
+## 工件与能力检查
+
+项目基线位于 <Path>{roots.state}/specdev/design/DESIGN.md</Path>，不可变版本位于 <Path>{roots.state}/specdev/design/revisions/{revision}.md</Path>，检索投影位于 <Path>{roots.state}/specdev/design/INDEX.md</Path>。当前 change 的合同位于 <Path>{roots.state}/specdev/changes/{change}/DESIGN.md</Path>，原型、确认和浏览器证据位于 <Path>{roots.state}/specdev/changes/{change}/prototypes/{design-id}/</Path>。change DESIGN 是规范，源码包不是第二份规则来源；跨 change 发布仍由项目设计知识网关唯一负责，消费方不能直写基线。
+
+先确定宿主能否读取全部相关文件、保留原始字节、计算 SHA-256、解析无重复键的 YAML/JSON、实际打开浏览器、写入文件，以及调用原 owner 的发布网关。缺少某能力只阻塞需要它的门。不能计算摘要时输出原始材料和待计算清单，不能编造 64 位字符串；没有真实浏览器时原型保持 draft/blocked；不能调用网关时导出待执行发布包，不宣称基线已发布。
+
+使用本文内联的项目设计、change 设计、UI 源码包和浏览器证据 schema 核对字段、类型、必需值和枚举；字段表不是许可。路径必须是所属根内的正斜杠相对 locator，不含绝对路径、反斜杠、空段、点段或符号链接。已有用户根设计文件保留原 owner，记录只读派生来源，冲突未解决不发布。
+
+## 可移植的摘要算法
+
+拥有确定性解析和加密工具时按以下算法计算；对话推测和人工抄写不能代替它们。
+
+1. `byte SHA-256` 对文件原始字节计算，保留换行和编码差异；用于候选、确认快照、实际 HTML、根设计文件和 current 的并发比较。
+2. `designDigest`：解析 Markdown YAML 头部及正文；删除头部顶层 confirmation、status、updated_at；递归按键名排序对象，数组次序保持不变；对排序结果生成无额外空白的 JSON，再连接一个换行和将 CRLF 换成 LF、首尾 trim 后的正文；以 UTF-8 计算 SHA-256。同一算法用于项目基线与 change 合同，不能用全文字节摘要替代。
+3. `prototype digest`：递归枚举该包 final/ 和 comparison/ 中全部普通文件，拒绝符号链接和其他文件类型；按路径排序，形成 `[包内相对路径, 文件字节SHA-256]` 数组。将 `{candidates, selected_candidate, files}` 递归按对象键排序后生成无额外空白 JSON，以 UTF-8 计算 SHA-256。候选内容、选择或任一运行文件变化都会使旧确认失效。所有运行依赖必须位于这两个目录中，离线运行，不能通过其他目录或网络旁路摘要。
+
+token 引用必须可解析且无循环；页面/规则/来源 ID 唯一。正式合同的 confirmation.digest 等于 designDigest，confirmation.record_digest 等于固定确认快照的字节 SHA-256，快照正文必须包含当前 designDigest、prototype_ref.digest 与 baseline.digest。baseline 指向存在的不可变 revision 且其 digest 相同；prototype_ref 与当前选中的包 ID、prototype digest 和 selection 一致。不得静默更新历史 change 所引用的基线。
+
+## 初始设计与下游消费门
+
+1. 已有项目先读代码中的 token、组件和真实页面，再继承已批准基线；没有基线时准备 change 内的 baseline-draft。默认自动组合候选并生成同任务 HTML，再集中展示。默认 3 个候选，配置范围 2–4 个；用户明确指定数量则记录 candidate_count_override 并严格按该数量生成。候选结构需要实质差异，不用换色复制冒充选择。
+2. 源码包保留 final/index.html、final/styles.css、final/app.js 三个具名源码块；提取后与实际文件逐字一致。comparison 索引能访问每个候选，候选和 final 内容、控制与状态完整，所有资源存在且离线。源码、候选、资源先全部生成，包仍处于 awaiting-confirmation。
+3. 浏览器证据对应当前 prototype digest。inspected_files 包含所有 candidate.entry 与 final/index.html；每个候选及 final 都至少有 390px、1440px case，case.entry 与实际入口相同，保存真实 PNG，final cases.states 覆盖每个页面的 `page-id:state`。实际检查操作、键盘/focus、溢出、长文案、缩放、reduced motion，记录 console_errors、offline、设计审查、技术审查及修复复核。模板或布尔标记不证明真实执行。
+4. 预览门先核对全部资源、源码一致性、页面状态与浏览器证据。首次批准前，将候选基线的确定 revision/designDigest 预绑定到 draft change DESIGN；一次展示最终 HTML、change 合同、候选基线、永久目标、来源和例外。批准绑定上述原始字节与规范摘要，固定用户决定为 approval.md；后续 LOG 只追加定位。首次批准范围必须包含永久规范写入，原有同范围批准可继续使用。
+5. 首次基线经原 owner 网关成功发布后回读 current、revision 和回执，确认与获批候选一致；再登记同一次 change confirmation。完整 approved 门通过后才能 ready。内容或摘要漂移时保持 blocked，先修订证据并重新确认受影响内容；不得用 pending 发布包满足 ready。
+6. S 的 UI 行为/页面/状态 AC 引用 change 合同和基线版本。T 的 UI Ticket 使用 ui_change 和 design_ref 的 revision/digest/pages/acceptance；I/C 在开始时重新计算并实际读取对应内容，在 Design Conformance 中逐页逐 AC 记录实现证据。仅引用路径或标记 approved 不算消费。W 探索材料复用于子 change 时重新绑定其范围；历史包保留，消费的是 change prototype_ref 指定的包。
+
+## 待执行网关包
+
+无法调用原 owner 网关或无法写项目时，在 <Path>{roots.state}/specdev/changes/{change}/prototypes/{design-id}/gateway-request.json</Path> 输出完整请求，状态为 `pending`；这是交接记录，不是新写入网关。请求明确 owner、mode（bootstrap/promotion）、候选路径、目标 current、预期 current 字节摘要（首次为 null）、批准对象、所需但尚未运行的门、已经完成的检查点。批准对象保留 approved、source、confirmed_at、candidate_sha256、current_sha256 和 新 `locator_version: 2`、`record: {base: "change", change, path, sha256}`；bootstrap 的 `preview: {base: "change", change, path, sha256, package_path, prototype_digest}` 绑定同一包实际 final HTML 和所有候选/运行资源。根项目已有设计规范时添加 `project_design: {owner, disposition: derived-readonly, sha256}`，候选 sources 保留相同 locator/digest。
+
+按稳定路径顺序输出完整 FILE 文件包：README 与原负责计划/owner 依据、原始请求、draft change DESIGN、候选 baseline、源码包、comparison/各候选/final 全部运行文件、浏览器证据和截图、固定确认、gateway-request、LOG。二进制截图保留为可下载原文件；若宿主不能导出则明确缺失并保持 blocked，不用 Markdown 假装 PNG。不要只提供 diff 或摘要，不导出并声称已经发布永久 current。若缺少真实批准，approval 为 null 且请求保持 draft，不伪造批准字段。
+
+答复必须区分“已实际保存”“待保存”“待网关执行”和“已验证/未验证”，列出每个完整相对路径、当前 phase、阻塞条件与下一步。只有工具成功回执才能宣称持久化或发布；消费方可以在依赖未满足时完成独立非 UI 工作。
+
+## 原 owner 恢复与归档提升
+
+恢复先重新读取用户保存或工具实际写入的状态、gateway-request、固定批准快照、全部候选与资源；检查原 pending transaction、相关锁、owner 和 recovery evidence。重新计算候选/确认/current/HTML/prototype 摘要，任一变化停止该发布并重备具体 diff。未知锁不接管，不因年龄删除，不改其他任务状态。
+
+由原 owner 先 dry-run，再按同一明确批准 apply；写入顺序是不可变 revision、current、INDEX，逐步保存 validated/revision-written/current-published/index-written 的真实回执。current 已是相同候选且 snapshot 一致时只修复缺失索引/回执，不重复发布；只有 snapshot 存在时核验原批准和 expected current 后继续；current 已被其他发布更新则停止合并。调用方原 owner 保持不变。
+
+实施完成后，归档仅提升有跨 change 价值并有来源的规则。一次性页面与未采用候选留在原 change；implemented 必须有实质实现证据，只有设计确认的规则保持 approved-intent。promotion 展示下一连续 revision、保留规则、merge/supersede/skip、证据和 current 并发条件，取得该具体 diff 的授权后交给同一网关。promotion 在移动前完成；若原操作已移动，则从 archive 实际位置恢复，只补原批准操作缺失步骤、不再次移动。移动后核验唯一位置、未变 Outcome、原型/合同/批准 locator 与原发布回执，完成原回执后冻结。
+
+请求 v2 的 path/package_path 相对稳定 change 根；旧请求 v1 保持 project locator 只读解释。移动不可变材料前后须能解析相同原字节，不能为修路径重算批准或另建 operation。

package/template/workflows/specdev/common/rules/deviation-control.md

@@ -6,8 +6,8 @@
 
 - **local**：只改变局部实现，不改变 Ticket 的行为、范围、公共契约、路径所有权或验证；记录到 Evidence 后可继续。
 - **ticket**：改变 Ticket 的执行路线、可写范围、局部契约或验收映射，但不改变 Spec；必须停止相关修改、更新 Ticket 并获得该 Ticket 或计划明确的批准 owner 同意。
-- **spec**：改变外部行为、范围、用户故事、验收合同或非功能要求；必须返回 `<Path>{roots.workflows}/specdev/S-spec/S-spec.md</Path>`。
-- **architecture**：改变已接受架构决策或公共架构约束；必须返回 `<Path>{roots.workflows}/specdev/G-grill-with-docs/G-grill-with-docs.md</Path>` 并更新 `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>`。
+- **spec**：改变外部行为、范围、用户故事、验收合同或非功能要求；必须返回 `<Path>{roots.workflows}/specdev/specdev-s-spec/SKILL.md</Path>`。
+- **architecture**：改变已接受架构决策或公共架构约束；必须返回 `<Path>{roots.workflows}/specdev/specdev-g-grill-with-docs/SKILL.md</Path>` 并更新 `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>`。
 - **release**：改变迁移、兼容窗口、发布门禁、回滚或不可逆批准点；必须停止并获得明确人工批准。
 
 ## 2. 触发条件
@@ -41,5 +41,5 @@
 
 - 未批准的 ticket、spec、architecture 或 release 偏差不得继续实现。
 - 不得通过扩大 `writable_paths`、删除测试、降低断言或把风险改写成“已知限制”来绕过停止。
-- 偏差影响并行执行、source checkpoint 或 candidate 集成时，Lead 必须暂停受影响 Wave，重新计算路径所有权、依赖、Gate 与父分支顺序；任何 subagent 都不能自行改写上层合同。
+- 偏差影响并行执行、source checkpoint 或 candidate 集成时，Lead 必须暂停受影响 Wave，重新计算路径所有权、依赖、Gate 与父分支顺序；任何 任务执行者 都不能自行改写上层合同。
 - 偏差跨越多个成员时，父 Lead 先递增 Implementation Map revision，再重算 Implementation Plan；旧派单和 candidate 全部标记 stale。

package/template/workflows/specdev/common/rules/documentation-standard.md

@@ -14,6 +14,8 @@ Work 入口说明如何执行；common 说明跨 Work 判断；项目源码、
 
 正文描述当前机制，不保留“本轮修改”“下一张 PR”“审查者已认可”或只有某次会话才能解释的编号。必要历史与事故证据留在 LOG/ADR/复盘中；真实 issue、公开规范和可定位历史引用不因出现编号就删除。未知理由保持未知，不补写想象中的设计史。
 
+数字和来源没有核实就写未验证，不编造备选方案或测试经历。HTTP API、服务、进程边界和事务边界有实际含义时保留精确术语，不机械替换成 module/seam。
+
 ## 运行声明与升级说明
 
 字段、默认值、命令和平台行为查 owning source，并在有执行条件时运行文档给出的实际操作。仅检查文字或链接不能证明命令成功。缺少网络、凭据、平台或权限时，明确未执行项、风险与验证 owner；不换成模拟后声称真实路径已验证。
@@ -24,6 +26,8 @@ Work 入口说明如何执行；common 说明跨 Work 判断；项目源码、
 
 ## 文档维护与可见行为
 
-纯文档可以使用链接、示例、类型片段、生成一致性和事实核对，不伪造 TDD 或 E2E。涉及工具说明、prompt、错误消息或 CLI/UI 输出时按行为变更处理，追加实际模型/用户可见证据或明确未验证。执行入口见 <Path>{roots.workflows}/specdev/I-implement/references/documentation-procedure.md</Path>；C 可仅审查，不获得写入权。
+纯文档可以使用链接、示例、类型片段、生成一致性和事实核对，不伪造 TDD 或 E2E。涉及工具说明、prompt、错误消息或 CLI/UI 输出时按行为变更处理，追加实际模型/用户可见证据或明确未验证。执行入口见 <Path>{roots.workflows}/specdev/specdev-i-implement/references/documentation-procedure.md</Path>；C 可仅审查，不获得写入权。
+
+没有所需行为层运行能力时报告缺口，并按原 Gate 保持未通过，不能借文档任务绕过。验收回读修改源和派生物，列出检查、未验证项及明确的新增行为；不用字数变化宣称 Token 或费用节省。
 
 方法参考：<Url>https://github.com/deepseek-ai/deepseek-harness/blob/d743267388641bc76f17c45ce8b4c231aed1d32c/.agents/skills/dsh-prose-standard/SKILL.md</Url> 与 <Url>https://github.com/deepseek-ai/deepseek-harness/blob/d743267388641bc76f17c45ce8b4c231aed1d32c/docs/AGENTS.md</Url>。

package/template/workflows/specdev/common/rules/domain-modeling.md

@@ -1,6 +1,6 @@
 # 领域建模规则
 
-本规则只规范当前 change 内的候选领域知识。G 和 A 的 consolidate-from-code 模式都可以用它整理 change 工件，但它不授权写入永久 namespace；永久知识只能由 `<Path>{roots.workflows}/specdev/A-archive-and-consolidate/A-archive-and-consolidate.md</Path>` 在完成证据、毕业评估和用户确认全部通过后提升。
+本规则只规范当前 change 内的候选领域知识。G 和 A 的 consolidate-from-code 模式都可以用它整理 change 工件，但它不授权写入永久 namespace；永久知识只能由 `<Path>{roots.workflows}/specdev/specdev-a-archive-and-consolidate/SKILL.md</Path>` 在完成证据、毕业评估和用户确认全部通过后提升。
 
 - 当前 change 的 CONTEXT 只保存已确认、供本 change 下游使用的项目规范语言，不保存普通编程概念、代码导航、一次性状态或讨论历史。
 - 每个术语使用规范名称和 1–2 句定义；不推荐的同义词写入 `_Avoid_`。

package/template/workflows/specdev/common/rules/domain-runtime.md

@@ -0,0 +1,35 @@
+# SpecDev 运行合同
+
+只在用户明确激活当前 Work 后读取；当前入口已明确时不重入领域 Skill，也不先执行初始化。项目与必要资源明确即可直接使用，无需 Speculo CLI 或安装元数据。
+
+## 启动顺序
+
+1. 明确项目根、方法资源根与获批业务数据根。已有安装时验证真实 workspace 与 roots；没有安装时使用明确根参数，方法资源可以只读。相对参数基于项目根，cwd 只作线索；不静默切换项目。根冲突、越界链接或重叠安装事务仅阻塞依赖该根的写入。详见 <Path>{roots.workflows}/specdev/common/rules/path-reference-contract.md</Path>。
+2. 读取当前请求和所选 Work；按 <Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path> 检索相关知识 ID/关键词，再回读少量原文与 provenance。没有相关知识不要求先初始化知识目录。
+3. 有 change 时定位用户指定对象或唯一合法候选，读取 README 的唯一 Outcome、当前负责工件和接续点。只枚举 changes 直接子目录，排除 archive；多个候选真实消歧。只读代码/架构审查、知识审计、capture 和初始化不强造 change。
+4. 按实际分支读取必要参考。创建、恢复、完成、取消或归档时读取 <Path>{roots.workflows}/specdev/common/rules/workflow-state-and-lifecycle.md</Path>；轻量/完整输入或事实冲突读取 <Path>{roots.workflows}/specdev/common/rules/artifact-contract.md</Path>；实际交接、并行、父子集成才加载 <Path>{roots.workflows}/specdev/common/rules/operating-governance.md</Path> 和 <Path>{roots.workflows}/specdev/common/rules/parent-implementation-orchestration.md</Path>。
+5. 写前核对路径、原 owner、实际写入者、相关 pending transaction、lock 和 recovery evidence。失败/阻塞记录在原 README、计划、Evidence 或操作回执；真实交接只更新原负责位置。完成产物、适用验证并回读，返回证据和下一入口。
+
+新普通流程不读写全局 status、change status 或 Work 调用镜像。发现旧活动协议、混合权威或转换 pending 标记时停止受影响写入，保留原件并交显式转换；README 存在不证明转换已完成。旧归档仅走独立历史只读定位。
+
+## 工件与能力
+
+小请求使用 README 中等价范围、AC 与验证；用户明确要求 Spec/Ticket/Goal 时交付指定工件。复杂需求可经 W → G → S → T → P → I 逐步形成合同，不要求全部 Work 串行必跑。Ticket frontmatter 拥有本票状态、依赖、写集与 Skill binding；有票的 Map/Goal 只管导航、依赖、Gate、集成和恢复，无票 Goal 由计划清单负责进度。整体结论只在 README，归档事实只在目录位置与回执。
+
+真实使用的 Spec/Ticket/Map/Goal、DESIGN、调查、远程账本 schema 与验证继续有效。并发上限、worktree 与集成尝试策略只在实际启用时由原 Goal/项目约定提供来源；缺省 current 单写入者、严格串行/direct-parent。Lead 自己实现也计入实现并发，只读 review/research/test-observation 不新增数字上限。GitHub labels 等实际工具配置仅对应分支读取；未知配置保留，缺标签只阻塞有关远程写入。
+
+UI 候选缺省 3 个，配置范围 2–4；用户明确数量覆盖默认及上限。W 每会话最多完成一张调查票。专业分支保留：R performance 先测量，D evidence-triage 不以观察冒充根因，I documentation 在原授权范围维护当前工程事实。
+
+## 写入边界
+
+实现只写获批项目路径；Work 不写 CLI-owned back/install/managed/baselines，不要求创建空 namespace。ADR/context 的提升、纠错、替代和清理由 A 原网关处理，research/非标准 store 只有声明的 owner 才可写。DESIGN 首次 approved-intent 和后续 promotion 都由 A 专用网关发布；P 嵌入调用保持原 owner，不启动归档。详见 <Path>{roots.workflows}/specdev/common/rules/design-contract.md</Path>。
+
+提交、推送、合并/父分支更新、来源 branch/worktree 清理、发布、部署、远程写入、归档移动、永久知识改写和不可逆迁移仍由 owning 入口核对具体授权。同一目标/动作/范围批准复用；新增副作用、范围或漂移才补充确认。文本、Outcome 和 owner 字符串都不能创造授权。
+
+只阻塞重叠写集及依赖分支，继续独立已授权工作。普通多文件修改没有整体原子保证；恢复先检查已落地结果，不能因报告缺失重复操作。同次任务已加载且未变化的规则可复用。
+
+## 验证与路由
+
+按当前分支运行 <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> 的适用 stage；传明确项目/方法/数据根，不用 CLI 包装器作为普通 Work 前置。prototype 传具体 UI-NNN/LOGIC-NNN；完成/取消按 <Path>{roots.workflows}/specdev/common/rules/change-completion.md</Path> 核验真实证据，票全 done 不替代整体验收。归档后以实际目标运行 archived 验证。
+
+场景出口见 <Path>{roots.workflows}/specdev/common/rules/workflow-routing.md</Path>。T 的 capture、publish、PR 和独立 TRI 各有原账本 owner；未请求远程动作不创建空账本或新完成门。completed/cancelled 不自动授权外部动作，已承诺而未结束的外部交付仍阻塞封存。已完成/归档来源的复盘另建 review-only change，不改写历史。

package/template/workflows/specdev/common/rules/error-handling.md

@@ -19,10 +19,14 @@
 
 重试必须说明安全重复的依据、执行 owner、取消途径和预算。只读、可幂等重试和需要先确认副作用的操作分别处理；“发生了超时”本身不能证明可重复。持续监督需要可释放的生命周期和可见降级，不伪装为有限次数操作。
 
-同一输入、同一方法、同一失败且没有新证据时，不通过更换 Agent、清空 attempts 或重复问用户来制造进展。恢复既有 Goal/Ticket 时沿用原失败记录，由 Lead 说明新增证据或方法变化后再派发。远程对账与 marker 去重由 <Path>{roots.workflows}/specdev/T-triage/T-triage.md</Path> 路由到原远程协议；进入远程分支后再读取，不在普通错误审查中加载传输实现。
+使用现有 config/Plan 的预算，不在下游偷偷扩大次数。只读操作也可能依赖已变化输入，仍需核实范围。
+
+同一输入、同一方法、同一失败且没有新证据时，不通过更换 Agent、清空 attempts 或重复问用户来制造进展。恢复既有 Goal/Ticket 时沿用原失败记录，由 Lead 说明新增证据或方法变化后再派发。远程对账与 marker 去重由 <Path>{roots.workflows}/specdev/specdev-t-triage/SKILL.md</Path> 路由到原远程协议；进入远程分支后再读取，不在普通错误审查中加载传输实现。
 
 取消只说明发出了取消请求，不保证远端副作用或子进程已经停止。传播 signal 后仍需等待属于本操作的完成信号；清理失败和业务失败分别报告，不能用后者隐藏前者。
 
+取消必须说明停止接收、停止执行和外部工作终止各自的时点；无法确认终止时保留未知状态和后续核实责任。
+
 ## 面向用户的结果
 
 最终说明必须指出受影响操作、已知影响、尚不确定的结果、系统当前处置和下一安全动作。失效状态持续存在时，提示也应持续可见；错误提示组件不能随已关闭的来源界面一起消失。保留有效数据，不为展示瞬时错误清空它。使用目标项目原有语言和诊断机制；敏感内部信息不进入公开文案。主要报告渠道失败时有独立的安全回退。

package/template/workflows/specdev/common/rules/evidence-and-verification.md

@@ -34,7 +34,7 @@ required 模式下，Lead 在最新父分支与 source commit 的 candidate 状
 
 ## 3. Agent 声明
 
-subagent 只返回候选命令与结果，不写 Evidence。Lead 重读 workspace/Git、必要时复跑或核对输出后落盘；外部 provider 自报、截图、模拟和推断在此之前标记 `unverified`。review/research/test-observation agent 不拥有 E2E Gate。
+任务执行者 只返回候选命令与结果，不写 Evidence。Lead 重读 workspace/Git、必要时复跑或核对输出后落盘；外部 provider 自报、截图、模拟和推断在此之前标记 `unverified`。review/research/test-observation agent 不拥有 E2E Gate。
 
 ## 4. 失败分类与完整性
 

package/template/workflows/specdev/common/rules/operating-governance.md

@@ -1,6 +1,6 @@
 # 运行治理细则
 
-规划、写入、并发、恢复、验收或归档时读取。
+仅真实交接、并行写入、共享所有权或父子集成时读取；普通启动不要求加载全部治理。
 
 
 1. **先发现、后询问**：仓库、配置、schema、测试和文档能回答的事实先探索；只询问真正影响行为、架构、风险、范围、迁移或验收的偏好。
@@ -12,10 +12,10 @@
 7. **偏差显式化**：计划与事实冲突时停止、记录、修订，不静默扩大范围或改写契约。
 8. **状态单一来源**：Ticket frontmatter 是单 Ticket 状态权威；Map 和 Goal Plan 是投影与编排。
 9. **知识以当前真相为目标**：归档保留历史，永久知识只保留仍真实且经实现验证的结论。
-10. **恢复依赖权威工件**：跨 Work 或 Agent 边界时同步 active change 的 `current_work`，成功完成后去重更新 `works_run`，返回下一 Work 和权威工件的完整路径。
+10. **恢复依赖权威工件**：跨 Work 或 Agent 的实际交接在原 README/计划/Evidence 记录 owner、范围、未决动作和下一步，不维护 Work 调用镜像；返回下一 Work 和权威工件完整路径。
 11. **本地执行权威**：远程 Issue/PR/URL 只作为来源或完成投影；Spec、Ticket、Map、Goal Plan、Evidence 和状态始终以本地工件为准。
 12. **完成与归档分离**：本地完成按 change completion 合同决定；远程 close 失败不回滚完成，但必须 reconcile 或 waive 后才归档。
-13. **Lead 与隔离正交**：Lead 固定拥有 SpecDev 状态、Evidence 与父分支；是否派遣 subagent 由 Lead 动态决定。Goal Plan 创建时询问 Ticket 是否开启 worktree，默认不开启；选择只作用于当前 Goal Plan。
+13. **Lead 与隔离正交**：Lead 固定拥有原计划、Evidence 与父分支；是否派遣 任务执行者 由 Lead 动态决定。Goal Plan 创建时询问 Ticket 是否开启 worktree，默认不开启；选择只作用于当前 Goal Plan。
 14. **策略化验收**：current 模式使用当前 workspace 严格串行、direct-parent 验证；required 模式使用 source worktree 与 parent-candidate。只有 required 模式创建独立 Ticket worktree。
 15. **父子权威隔离**：父实现 change 只拥有 Ready 子 change 的组合 Ticket DAG、serialization、全局 workspace/资源和实现进度投影；子 change 继续拥有全部行为与实现合同。一个未完成子 change 只能属于一个未完成父实现 change。
 

package/template/workflows/specdev/common/rules/parent-implementation-orchestration.md

@@ -1,6 +1,6 @@
 # Parent Implementation Orchestration
 
-本规则只约束 Ready Spec/Tickets 之后的跨 change 实现，供统一 P-goal-plan、兼容 P-goal-plan、I-implement 与 A-archive-and-consolidate 读取。
+本规则只约束 Ready Spec/Tickets 之后的跨 change 实现，供统一 P-goal-plan、I-implement 与 A-archive-and-consolidate 读取。
 
 ## 输入边界
 
@@ -16,11 +16,11 @@
 
 ## 唯一所有权
 
-一个 active/blocked 子 change 最多属于一个未完成父实现 change。v1 不支持父实现 change 嵌套。父 Lead 是父工件、全部 SpecDev 状态写入、E2E、repository/ref integration queue 和父分支推进的唯一 owner；implementation agent 只写授权项目 workspace。
+一个 active/blocked 子 change 最多属于一个未完成父实现 change。v1 不支持父实现 change 嵌套。父 Lead 是父工件、父计划及授权 Evidence 写入、E2E、repository/ref integration queue 和父分支推进的唯一 owner；implementation agent 只写授权项目 workspace。
 
 ## I-implement 调用
 
-父 Plan 可以替代缺失的子 Goal Plan 提供 workspace/integration 策略和全局执行边界。子 Goal Plan 存在时继续拥有子 change 内 Gate，但不得与父策略冲突。I-implement 完成或阻塞一个组合 Ticket 后返回父 P Goal（旧 O 入口保留恢复键），不要求用户重新激活 change。
+父 Plan 可以替代缺失的子 Goal Plan 提供 workspace/integration 策略和全局执行边界。子 Goal Plan 存在时继续拥有子 change 内 Gate，但不得与父策略冲突。I-implement 完成或阻塞一个组合 Ticket 后返回父 P Goal，不要求用户重新激活 change。
 
 ## 归档与完成
 

package/template/workflows/specdev/common/rules/path-ownership.md

@@ -15,21 +15,21 @@
 
 1. 可能并行的 Ticket，其 writable paths 不得相交；glob 按覆盖关系判断。
 2. shared path 只由专用 owner Ticket 修改；消费者 Ticket 只读。Lead 负责集成，不以冲突解决替代 shared owner。
-3. implementation subagent 只写其 Packet 与 Ticket 授权路径；Lead 自行实现也受同一边界约束。
+3. 实现执行者 只写其 Packet 与 Ticket 授权路径；Lead 自行实现也受同一边界约束。
 4. review/research/test-observation agent 只读项目与 SpecDev 工件。
 5. 越界前停止并按 deviation control 提出 ownership change；不得先改后报。
 6. 上游 Ticket 改变目录/合同后，下游基于已集成父分支重新解析路径和 preflight。
 
 ## 3. Ticket workspace strategy
 
-Goal Plan 创建时选择 Ticket workspace strategy，默认 `current`。`current` 模式的 Ticket 使用当前分支、当前 workspace 和严格串行执行；允许一个 implementation subagent 写入当前 workspace，但前一 Ticket 必须完成 commit、Lead 验收和 direct-parent 验证后才能开始下一个。`required` 模式每个 Ticket 使用唯一来源 worktree `specdev-worktree/<ticket-id>`，并通过 candidate-merge 集成。没有 Ticket 的获批 Direct Spec 继续由 current workspace 唯一 owner 执行；只读调查不创建实现 worktree。
+Goal Plan 创建时选择 Ticket workspace strategy，默认 `current`。`current` 模式的 Ticket 使用当前分支、当前 workspace 和严格串行执行；允许一个 实现执行者 写入当前 workspace，但前一 Ticket 必须完成 commit、Lead 验收和 direct-parent 验证后才能开始下一个。`required` 模式每个 Ticket 使用唯一来源 worktree `specdev-worktree/<ticket-id>`，并通过 candidate-merge 集成。没有 Ticket 的获批 Direct Spec 继续由 current workspace 唯一 owner 执行；只读调查不创建实现 worktree。
 
-workspace/implementation owner 可以是 Lead 或动态 implementation subagent；integration owner 固定为 Lead。current 模式 Lead 在父分支直接验收和推进，required 模式 Lead 建立 parent-candidate、运行适用 E2E 并推进父分支。required 生命周期由 `<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>` 管理，current 生命周期由 I-implement 的 direct-parent 规则管理。
+workspace/implementation owner 可以是 Lead 或动态 实现执行者；integration owner 固定为 Lead。current 模式 Lead 在父分支直接验收和推进，required 模式 Lead 建立 parent-candidate、运行适用 E2E 并推进父分支。required 生命周期由 `<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>` 管理，current 生命周期由 I-implement 的 direct-parent 规则管理。
 
 ## 4. 并发
 
-required 模式 implementation subagent 上限取 Goal Plan、config 和平台能力共同约束，Lead 不计入。current 模式保持单 writer 串行安全不变量，Ticket 严格串行。review/research/test-observation agent 不设置 SpecDev 数字上限，但 Lead 必须避免重复工作与可变环境争用。
+required 模式 实现执行者 上限取 Goal Plan、config 和平台能力共同约束，Lead 参与实现时计入。current 模式保持单 writer 串行安全不变量，Ticket 严格串行。review/research/test-observation agent 不设置 SpecDev 数字上限，但 Lead 必须避免重复工作与可变环境争用。
 
-子 change 属于父 Implementation Map 时，再取父 Implementation Plan 的全局 implementation subagent 上限与 workspace 策略；该上限跨全部成员合计。无 dependency 的组合 Ready Tickets 若 writable/shared paths 重叠，也必须在父 Map 建立 serialization。相同 repository/ref 的 parent integration 严格串行；一次父 HEAD 推进会使其他成员旧 candidate 失效。
+子 change 属于父 Implementation Map 时，再取父 Implementation Plan 的全局 实现执行者 上限与 workspace 策略；该上限跨全部成员合计。无 dependency 的组合 Ready Tickets 若 writable/shared paths 重叠，也必须在父 Map 建立 serialization。相同 repository/ref 的 parent integration 严格串行；一次父 HEAD 推进会使其他成员旧 candidate 失效。
 
 **完成标准**：每个项目写入映射到唯一 change、Ticket、owner 和来源 worktree；shared 与父分支写入 owner 唯一。