npm - @namewta/speculo - Versions diffs - 0.3.0 → 0.3.2 - Mend

@namewta/speculo 0.3.0 → 0.3.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (149) hide show

package/template/workflows/specdev/R-review-architecture/html-report-template.md DELETED Viewed

@@ -1,124 +0,0 @@
-# HTML 报告模板
-架构审查渲染为单个自包含 HTML 文件，写入操作系统临时目录。Tailwind 和 Mermaid 均来自 CDN。Mermaid 处理图形状图表（调用图、依赖关系、序列）；手工构建的 div 和 inline SVG 处理编辑性可视化（质量图、横截面、坍缩动画）。混合使用两者——不要所有图表都用 Mermaid，多样性本身就是目的。
-`{{config.defaults.report_language}}` 占位符由运行时解析为 `speculo/config.json` 的 `defaults.report_language` 字段值；若配置文件不存在则默认为 `"en"`。
-## 脚手架
-```html
-<!doctype html>
-<html lang="{{config.defaults.report_language}}">
-  <head>
-    <meta charset="utf-8" />
-    <title>Architecture review — {{repo name}}</title>
-    <script src="https://cdn.tailwindcss.com"></script>
-    <script type="module">
-      import mermaid from "https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.esm.min.mjs";
-      mermaid.initialize({ startOnLoad: true, theme: "neutral", securityLevel: "loose" });
-    </script>
-    <style>
-      .seam { stroke-dasharray: 4 4; }
-      .leak { stroke: #dc2626; }
-      .deep { background: linear-gradient(135deg, #0f172a, #1e293b); }
-    </style>
-  </head>
-  <body class="bg-stone-50 text-slate-900 font-sans">
-    <main class="max-w-5xl mx-auto px-6 py-12 space-y-12">
-      <header>...</header>
-      <section id="candidates" class="space-y-10">...</section>
-      <section id="top-recommendation">...</section>
-    </main>
-  </body>
-</html>
-```
-## 页头
-仓库名称、日期，以及紧凑图例：实线框 = 模块，虚线 = 接缝，红色箭头 = 泄漏，粗黑框 = 深模块。无介绍段落——直接进入候选列表。
-## 候选卡片
-每个候选渲染为一个 `<article>` 元素。图表承担主要分量——文字稀疏、平实，使用 `<Path>{roots.workflows}/specdev/I-implement/codebase-design-glossary.md</Path>` 中的术语，不刻意修饰。
-卡片结构：
-- **标题** — 简短命名深化方案（如"合并 Order 接收管线"）
-- **徽章行** — 推荐强度（`Strong` = 翠绿、`Worth exploring` = 琥珀、`Speculative` = 石板灰）+ 依赖类别标签（`进程内`、`本地可替换`、`端口与适配器`、`mock`）
-- **文件** — 等宽字体列表，`font-mono text-sm`
-- **Before / After 图表** — 核心。两列并排，见下方图表模式
-- **Problem** — 一句。当前架构的摩擦是什么
-- **Solution** — 一句。改变什么
-- **Wins** — 要点，每项 ≤6 词。用术语表命名收益："局部性：bug 集中在一个模块"、"杠杆：一个接口，N 个调用点"、"接口缩小；实现吸收包装器"
-- **ADR 标注**（如适用）— 一行，琥珀色调框中
-不要写"更易维护"或"更清晰的代码"——这些术语不在 `<Path>{roots.workflows}/specdev/I-implement/codebase-design-glossary.md</Path>` 术语表中。如果图表需要一段文字才能理解，重新画图。
-## 图表模式
-选择适合候选的模式。混合使用。不要让每个图表看起来都一样。
-### Mermaid 图表（依赖/调用流）
-当重点是"X 调用 Y 调用 Z，看这多混乱"时使用 `flowchart` 或 `graph`。用 Tailwind 风格卡片包裹。使用 classDef 将泄漏边缘着红色、深模块着深色。序列图适合展示"before：6 个往返；after：1 个"。
-```html
-<div class="rounded-lg border border-slate-200 bg-white p-4">
-  <pre class="mermaid">
-    flowchart LR
-      A[OrderHandler] --> B[OrderValidator]
-      B --> C[OrderRepo]
-      C -.leak.-> D[PricingClient]
-      classDef leak stroke:#dc2626,stroke-width:2px;
-      class C,D leak
-  </pre>
-</div>
-```
-### 手工框线图（Mermaid 布局难以驾驭时）
-模块用带边框和标签的 `<div>` 表示。箭头用绝对定位在相对容器上的 inline SVG `<line>` 或 `<path>` 表示。当希望"after"图表呈现为一个粗边深模块、内部灰显时使用——Mermaid 不会以合适的视觉权重渲染这种效果。
-### 横截面图（分层浅度）
-堆叠水平条（`h-12 border-l-4`）展示调用经过的各层。Before：6 个薄层各做极少。After：一个厚条标注合并后的职责。
-### 质量图（接口与实现一样宽）
-每个模块两个矩形——一个表示接口表面积，一个表示实现。Before：接口矩形几乎和实现矩形一样高（浅）。After：接口矩形短，实现矩形高（深）。
-### 调用图坍缩
-Before：嵌套框呈现的函数调用树。After：同一棵树坍缩成一个框，内部调用在其内部以淡化形式显示。
-### 模块关系图（接缝对比）
-Before：模块 A 和 B 紧耦合，虚线穿越表示接缝泄漏。After：一个深模块包裹 A 和 B 的内部，干净接口对外暴露。使用 inline SVG 绘制两个并列场景。
-## 样式指导
-- 偏向编辑风格而非企业仪表盘。宽松留白。标题可选用衬线字体（`font-serif` 与 stone/slate 搭配）
-- 色彩克制：一种强调色（翠绿或靛蓝）+ 红色用于泄漏 + 琥珀用于警告
-- 图表高度约 320px，使 before/after 并排舒适放置无需滚动
-- 模块标签用 `text-xs uppercase tracking-wider`——应读作示意图而非 UI
-- 唯一脚本是 Tailwind CDN 和 Mermaid ESM import——其余全部静态，无应用代码
-## 最佳推荐
-一张更大的卡片。候选名称，一句说明为什么，指向其卡片的锚链接。
-## 语气
-平实、简洁——架构名词和动词直接来自 `<Path>{roots.workflows}/specdev/I-implement/codebase-design-glossary.md`。简洁不是偏离的借口。
-**完全使用：** module、interface、implementation、depth、deep、shallow、seam、adapter、leverage、locality。
-**绝不替代：** component、service、unit（代替 module）· API、signature（代替 interface）· boundary（代替 seam）· layer、wrapper（代替 module 当实际指 module 时）。
-**符合风格的表达：**
-- "Order 接收模块是浅层的——接口几乎与实现匹配。"
-- "Pricing 跨越接缝泄漏。"
-- "深化：一个接口，一个测试点。"
-- "两个适配器证明接缝：生产用 HTTP，测试用内存。"
-不模糊其词，不说"值得注意的是……"。如果一句话可以变成要点，就变成要点。如果一个要点可以删除，就删除它。如果一个术语不在 `<Path>{roots.workflows}/specdev/I-implement/codebase-design-glossary.md` 术语表中，在发明新术语之前先用术语表中已有的。

package/template/workflows/specdev/T-triage/artifact-templates.md DELETED Viewed

@@ -1,122 +0,0 @@
-# 分诊产物模板
-本 work 在 change 目录**仅**写入以下两个文件。路径：
-- `<Path>{roots.state}/specdev/changes/{change}/source-issue.md</Path>`
-- `<Path>{roots.state}/specdev/changes/{change}/triage.md</Path>`
-行为契约章节对齐 `<Path>{roots.workflows}/specdev/common/triage/AGENT-BRIEF.md</Path>`，但落在本地文件，而非 tracker 评论。
-推荐 status 角色字符串：若存在 `<Path>{roots.state}/specdev/.config/status-labels.md</Path>`，使用其「标签」列；否则使用角色名本身（`needs-triage` / `needs-info` / `ready-for-agent` / `ready-for-human` / `wontfix`）。
----
-## source-issue.md
-```markdown
-# Source Issue
-- **Source:** gh | paste | manual
-- **Kind:** issue | pr | manual
-- **ID:** #N 或 n/a
-- **URL:** <url 或空>
-- **Fetched at:** <ISO-8601>
-- **Author:** <作者>
-- **Labels:** <逗号分隔，或无>
-- **State:** <open/closed 或空>
-## Title
-<标题>
-## Body
-<正文原文>
-## Comments
-### @<author> (<date>)
-<body>
-<!-- 无评论时写：_无评论_ -->
-```
-填写规则：
-- 保留摄入时快照；远端后续编辑不自动同步
-- 评论按时间顺序；过长可摘要并注明「已截断，完整内容见远端 #N」
-- `manual` 来源：Body 由问题描述 + 期望行为组成，并在顶部注明「非远端快照」
----
-## triage.md
-```markdown
-# Triage: <一句话主题>
-- **Change:** <YYYY-MM-DD-kebab-topic>
-- **Category:** bug | enhancement
-- **Recommended status:** needs-triage | needs-info | ready-for-agent | ready-for-human | wontfix
-- **Recommended next work:** <显示名> | none
-- **Source:** [./source-issue.md](./source-issue.md)
-- **Verification:** confirmed | not-reproduced | needs-info | n/a
-## 问题摘要
-<用户可理解的一两句>
-## 理解结论
-- **代码库现状：** <相关模块/接口与现状行为>
-- **验证结果：** <同上 Verification，可附命令/证据>
-- **冗余 / 范围外：** none | 已实现于… | 匹配 `.out-of-scope/<concept>.md`（用户选择：确认/重新考虑/不相关）
-## 行为契约草案
-**Current behavior:**
-<当前发生什么>
-**Desired behavior:**
-<完成后应发生什么；含边界与错误条件>
-**Key interfaces:**
-- `<TypeOrFn>` — 需要改变什么以及为什么
-- …
-**Acceptance criteria:**
-- [ ] <可独立验证的标准 1>
-- [ ] <可独立验证的标准 2>
-**Out of scope:**
-- <本 change 明确不做的事项>
-## 信息缺口
-<!-- needs-info 或仍有开放问题时填写；否则写「无」 -->
-- <具体可回答的问题 1>
-- <具体可回答的问题 2>
-## 推荐下一 Work
-- **主推荐：** <Path>{roots.workflows}/specdev/<Work>/<Work>.md</Path> 或 `none`
-- **理由：** <对应 routing-rules 首匹配条件的一句话>
-- **备选：** <可选一条 Path 或 none>
-- **停止说明：** 用户确认前不启动下游 work
-```
-填写规则：
-- 一句话主题来自 issue 标题的 kebab 压缩语义，与 change 目录名一致或为其可读版
-- `Recommended next work` 显示名与路由表一致（如「设计访谈」「编写 Spec」「实现」「诊断」「寻路」「none」）
-- 行为契约不足时：status 倾向 `needs-info`，next 为 `none`，缺口章节穷尽
-- 已实现或用户确认拒绝：status `wontfix`，next `none`；范围外文件仅提示，默认不自动创建
-- 无残留 `[TODO:]` 占位符
-## 完成检查
-- 两文件均已存在于 `{change}` 目录
-- `triage.md` 元数据五行齐全（Change / Category / Recommended status / Recommended next work / Source）
-- 行为契约五块齐全（Current / Desired / Key interfaces / AC / Out of scope）——`needs-info` 时 AC 可较少，但缺口必须穷尽
-- 主推荐 Path 使用 `{roots.workflows}` 别名，或为字面 `none`

package/template/workflows/specdev/T-triage/intake-rules.md DELETED Viewed

@@ -1,71 +0,0 @@
-# 摄入规则
-将外部 issue 或 PR 规范化为会话内统一结构，供后续理解与落盘使用。本步骤只读取远端或用户输入，不写回 tracker。
-## 远程可用性
-按顺序探测：
-1. 当前目录处于 git 仓库内
-2. `gh` 可执行
-3. `gh auth status` 成功
-三者皆满足 → **远程可用**。任一项失败 → 按粘贴 / 口头路径处理，向用户说明原因。
-## 远程拉取
-用户给出 `#N`、纯数字编号、issue URL 或 PR URL 时：
-**Issue（优先）**
-```bash
-gh issue view <n> --json number,title,body,author,labels,url,createdAt,state,comments
-```
-人类可读备选：`gh issue view <n> --comments`。
-**PR（用户明确给了 PR，或 issue view 失败且 `gh pr view <n>` 成功）**
-```bash
-gh pr view <n> --json number,title,body,author,labels,url,createdAt,state,comments,files
-```
-PR 按「附带代码的 issue」处理：正文 + 评论 + 变更文件列表进入内部结构；diff 摘要可记入 `body` 附录或 comments 旁注。仍只写本地产物。
-**解析 `#N`**：先尝试 `gh pr view N`，再 `gh issue view N`（或按用户声明的类型二选一）。
-**失败回退**：网络错误、无权限、编号不存在 → 向用户说明，并请粘贴标题 + 正文 + 关键评论。不中止分诊。
-## 粘贴与口头
-| 来源 | 条件 | 处理 |
-|------|------|------|
-| `paste` | 用户粘贴全文（可含评论） | 拆出标题、正文、评论块；缺评论则 `comments: []` |
-| `manual` | 仅口头 / 碎片描述 | 索取最小字段：标题、问题描述、期望行为；可选复现步骤 |
-## 规范化内部结构
-无论来源，统一为：
-| 字段 | 说明 |
-|------|------|
-| `source` | `gh` \| `paste` \| `manual` |
-| `kind` | `issue` \| `pr` \| `manual` |
-| `number` | 编号，无则 `n/a` |
-| `title` | 标题 |
-| `body` | 正文（markdown 原文） |
-| `url` | 远端 URL，无则空 |
-| `author` | 作者登录名或「用户」 |
-| `labels` | 标签字符串数组 |
-| `state` | open/closed 等，未知则空 |
-| `comments` | `{ author, created_at, body }[]` |
-| `fetched_at` | ISO-8601 摄入时间 |
-后续步骤只消费此结构；写入 `source-issue.md` 时按 `<Path>{roots.workflows}/specdev/T-triage/artifact-templates.md</Path>` 展开。
-## 完成检查
-- 标题非空
-- 正文非空（`manual` 时问题描述 + 期望行为可拼成 body）
-- `source` 与 `fetched_at` 已设
-- 远程路径下 `number` 与 `url` 尽量齐全；失败回退已标注

package/template/workflows/specdev/T-triage/routing-rules.md DELETED Viewed

@@ -1,70 +0,0 @@
-# 路由规则
-在 `triage.md` 已具备类别、验证结果、信息缺口与行为契约草案后，按**首匹配**（从上到下）选定恰好一条主推荐。可附一条备选。推荐后**停止**，等用户确认再加载对应 work 入口。
-## 首匹配表
-| # | 条件 | Recommended status | 主推荐 |
-|---|------|--------------------|--------|
-| 1 | 已实现，或用户确认拒绝 / wontfix | `wontfix` | `none` |
-| 2 | 关键信息不足（无法写出可测 AC 或无法判断类别/复现） | `needs-info` | `none` |
-| 3 | `bug`，可复现（confirmed），根因未知 | `ready-for-agent` 或 `needs-triage` | **诊断** |
-| 4 | `bug`，AC 清晰，范围小，修复点/模块清楚 | `ready-for-agent` | **实现** |
-| 5 | `enhancement`，设计未定或接口仍开放 | `needs-triage` 或 `ready-for-human` | **设计访谈** |
-| 6 | `enhancement`，设计已定，足以写 PRD | `ready-for-agent` | **编写 Spec** |
-| 7 | 工作超单会话、通往目标的路径仍在迷雾中 | `needs-triage` | **寻路** |
-| 8 | 以上皆非（默认） | `needs-triage` | **设计访谈** |
-规则 1 的补充：用户确认拒绝 enhancement 时，可**提示**写入项目根 `.out-of-scope/<concept>.md`（格式见 `<Path>{roots.workflows}/specdev/common/triage/OUT-OF-SCOPE.md</Path>`）；默认不自动写。已实现关闭不写 `.out-of-scope/`。
-规则 3 vs 4：「根因未知」= 知道坏在哪一类症状，但不知哪个模块/不变量失败；「修复点清楚」= 已能指出接口或模块级落点。
-规则 7 可选：仅当用户或理解结论明确「多会话 / 战争迷雾」时命中；否则落入默认规则 8。
-## 入口 Path
-| 显示名 | Path |
-|--------|------|
-| 设计访谈 | `<Path>{roots.workflows}/specdev/G-grill-with-docs/G-grill-with-docs.md</Path>` |
-| 编写 Spec | `<Path>{roots.workflows}/specdev/S-spec/S-spec.md</Path>` |
-| 实现 | `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>` |
-| 诊断 | `<Path>{roots.workflows}/specdev/D-diagnose-bugs/D-diagnose-bugs.md</Path>` |
-| 寻路 | `<Path>{roots.workflows}/specdev/W-wayfinder/W-wayfinder.md</Path>` |
-| none | 字面 `none`（向用户提问或结束分诊） |
-## 推荐话术
-向用户展示时使用固定骨架：
-```markdown
-## 分诊结论
-- **Change：** `{change}`
-- **类别：** bug | enhancement
-- **推荐 status：** …
-- **主推荐：** <显示名> → <Path>…
-- **理由：** <对应上表条件的一句话>
-- **备选：** <可选>
-产物：
-- `<Path>{roots.state}/specdev/changes/{change}/source-issue.md</Path>`
-- `<Path>{roots.state}/specdev/changes/{change}/triage.md</Path>`
-是否进入主推荐 work？确认前我不会启动下游或修改项目代码。
-```
-`needs-info` 时：话术改为列出「信息缺口」中的具体问题，主推荐写 `none`，并说明补齐后可再次运行本 work 或直接指定下游。
-`none` + `wontfix` 时：说明已实现位置或拒绝理由；询问是否需要记录到 `.out-of-scope/`（仅 enhancement 拒绝）。
-## 停止规则
-- 本步只推荐与展示；用户确认「进入 X」后再加载对应 Path，并移交 change 名、`triage.md` 路径与行为契约要点
-- 用户选择备选或否决时，先更新 `triage.md` 推荐字段，再结束或按新选择移交
-## 完成检查
-- 从上到下只命中一条主推荐
-- Path 使用上表别名格式（或 `none`）
-- 用户已看到理由与确认问题
-- 下游仍处于未启动状态

package/template/workflows/specdev/T-triage/understanding-rules.md DELETED Viewed

@@ -1,102 +0,0 @@
-# 深度理解规则
-在写入分诊产物之前，对摄入的 issue 完成可检查的理解。行为契约对齐 `<Path>{roots.workflows}/specdev/common/triage/AGENT-BRIEF.md</Path>`：
-- **持久优于精确**——描述接口、类型与行为契约；少绑易变文件路径与行号
-- **行为而非过程**——写系统应做什么，不写如何实现
-- **完整验收标准**——每条可独立验证
-- **明确范围外**——写清本 change 不做什么
-范围外只读去重遵循 `<Path>{roots.workflows}/specdev/common/triage/OUT-OF-SCOPE.md</Path>`。
-## 检查清单（逐项完成）
-### 1. 问题一句话
-用一句用户可理解的话概括「出了什么问题 / 要什么能力」。
-### 2. 类别
-判定恰好一个：
-- `bug`——现有行为不符合预期
-- `enhancement`——新功能或对现有能力的改进
-依据不足时倾向 `enhancement` 并在信息缺口中写清「请确认是回归还是新需求」。
-### 3. 当前行为 vs 期望行为
-- **当前**：代码库与 issue 共同描述的现状（bug 为故障表现；enhancement 为建立其上的基线）
-- **期望**：完成后应发生什么；含已知边界与错误条件
-未知部分列入信息缺口，不编造。
-### 4. 代码库探查
-- 先读 `<Path>{roots.state}/specdev/adr/</Path>` 与 `<Path>{roots.state}/specdev/context/</Path>`（若存在），使用既有术语与决策
-- 按**领域概念**搜索（不仅是 issue 措辞）
-- 记录相关模块、类型、函数签名或配置形态——行为级命名优先
-- 报告查找范围，便于用户质疑遗漏
-### 5. 冗余（已实现）
-若请求行为已在代码库中存在：
-- 指向存在位置（模块/接口名 + 简要证据）
-- 倾向推荐 status `wontfix`、next work `none`
-- 已实现路径只指向代码位置；`.out-of-scope/` 仅用于被拒绝的 enhancement
-### 6. 范围外匹配（只读）
-读取项目根 `.out-of-scope/*.md`（目录不存在则跳过）：
-- 按**概念相似**匹配（如「night theme」≈ `dark-mode`）
-- 有匹配则呈现文件路径与拒绝理由，请用户选择：
-  - **确认**——仍拒绝 → next `none`；可提示用户自行追加 prior request（本 work **默认不自动写** `.out-of-scope/`）
-  - **重新考虑**——进入正常分诊
-  - **不相关**——继续正常分诊
-### 7. 信息缺口
-列出具体、可回答的问题。每条应能独立关闭一个决策或验证点。
-- 好：「在 Node 20 + macOS 上执行 `speculo init` 后的完整终端输出是什么？」
-- 坏：「请提供更多信息。」
-无缺口则写「无」。
-### 8. Bug 验证（轻量）
-仅 `bug` 类别：
-| 结果 | 含义 |
-|------|------|
-| `confirmed` | 按报告步骤复现成功，或代码路径明确支撑该故障 |
-| `not-reproduced` | 按步骤未能复现；记录尝试环境与命令 |
-| `needs-info` | 步骤不足，无法尝试复现 |
-| `n/a` | 非 bug |
-完整反馈回路、插桩与假设排名由 `<Path>{roots.workflows}/specdev/D-diagnose-bugs/D-diagnose-bugs.md</Path>` 负责。本步只需确认「是否像真 bug」及可复现性档位。
-## 输出给后续步骤的结论包
-步骤 4 写入 `triage.md` 前，会话中应具备：
-| 字段 | 来源 |
-|------|------|
-| 类别 | 清单 §2 |
-| 问题摘要 | 清单 §1 |
-| 当前 / 期望行为 | 清单 §3 |
-| 关键接口（草案） | 清单 §4 |
-| 验收标准（草案） | 自期望行为拆出；不足则进缺口 |
-| 范围外 | 清单 §6 + 显式不做项 |
-| 验证结果 | 清单 §8 |
-| 冗余 / 范围外结论 | 清单 §5–6 |
-| 信息缺口 | 清单 §7 |
-| 完备性 | 足以写契约 → 可路由下游；否则 `needs-info` |
-## 完成检查
-- 八项均有结论或明确「不适用」
-- 用户已看到已实现 / 范围外匹配（若有）并给出方向（或已 AFK 默认继续）
-- 信息缺口每条可操作

package/template/workflows/specdev/_state/adr/.gitkeep DELETED Viewed

File without changes

package/template/workflows/specdev/_state/context/.gitkeep DELETED Viewed

File without changes

package/template/workflows/specdev/_state/research/.gitkeep DELETED Viewed

File without changes

package/template/workflows/specdev/common/dev-worktree/SKILL.md DELETED Viewed

@@ -1,48 +0,0 @@
----
-name: dev-worktree
-description: 在 Speculo workflow change 内创建隔离 git worktree 进行开发，完成后验证测试并合回基础分支。当用户要求隔离开发、开始实现、或实现完成后需要合并/清理时使用。与 specdev workflow 深度集成，worktree 持久化在 change 目录下的 .worktree/ 中。
----
-# Dev Worktree
-为当前 workflow change 创建独立 worktree，实现「隔离开发 → 验证 → 合并 → 清理」闭环。
-**启动时宣布：** 「正在使用 dev-worktree 技能。」
-## 决策树
-| 场景 | 入口 |
-|------|------|
-| 要开始实现 / 用户要求隔离 | **阶段 A：创建 worktree** |
-| 已在 worktree 中，开发完成 | **阶段 B：收尾合并** |
-| 已在 worktree 中，未完成 | 继续开发，不重复创建 |
-| 用户要求 PR / 暂存 / 丢弃 | 阶段 B 按对应选项执行 |
-## 阶段 A：创建 Worktree
-完整步骤见 [references/create.md](references/create.md)。概览：
-1. **检测现有隔离** — 已在 worktree 则跳过创建；submodule 内按普通仓库处理
-2. **命名** — 分支 `speculo/<workflow>/<change>`；路径 `{state-root}/<workflow>/changes/<change>/.worktree/`；已存在则停止
-3. **创建** — `git worktree add -b …`；确保 `.gitignore` 含 `.worktree/`
-4. **基线** — 安装依赖并跑基线测试；失败则报告并询问
-5. **写回** — 将 `base_branch` / `change_branch` / `worktree_path` / `worktree_status: active` 写入 change 的 `.status.json`
-**前置：** `speculo/.speculo/` 必须被 git 跟踪；若被忽略则降级为非 worktree 模式。
-## 阶段 B：收尾合并
-完整步骤见 [references/finalize.md](references/finalize.md)。概览：
-1. **验证测试** — 失败则停止，禁止合并/PR
-2. **展示选项** — 本地合并（默认）/ 创建 PR / 保持 / 丢弃
-3. **执行** — 本地合并顺序：checkout base → pull → `merge --no-ff` → 重跑测试 → `worktree remove` → `branch -d` → `prune` → 更新 `.status.json`
-合并冲突或测试失败 → 停止，保留现场。冲突解决见 `<Path>{roots.workflows}/specdev/common/resolving-merge-conflicts/SKILL.md</Path>`。
-## 红线
-- 已在 worktree 时不嵌套创建；不覆盖已有分支或路径
-- 测试失败时不合并/不发 PR；合并结果未验证不删 worktree
-- 清理顺序固定：merge → remove worktree → delete branch；在 worktree 内部不执行 `git worktree remove`
-- 破坏性操作须先确认；不强制推送

package/template/workflows/specdev/common/dev-worktree/references/create.md DELETED Viewed

@@ -1,63 +0,0 @@
-# 创建 Worktree
-为当前 workflow change 建立独立 worktree。由 SKILL.md 阶段 A 调用。
-## 前置
-1. git 仓库内，工作区干净或可接受
-2. `speculo/.speculo/` 被 git 跟踪（change 产物随分支合并回 base）；若被忽略则降级非 worktree 模式
-3. `.gitignore` 含 `.worktree/`；缺失则追加并提交
-## 检测已有隔离
-```bash
-GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P)
-GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P)
-SUPER=$(git rev-parse --show-superproject-working-tree 2>/dev/null)
-```
-| 条件 | 判断 |
-|------|------|
-| `SUPER` 有值 | submodule，按普通仓库 |
-| `GIT_DIR != GIT_COMMON` 且非 submodule | 已在 worktree |
-| `GIT_DIR == GIT_COMMON` | 主工作区，继续创建 |
-已在 worktree → 报告路径与分支，跳到设置步骤，不重复创建。
-## 命名
-| 要素 | 值 |
-|------|-----|
-| base 分支 | `git rev-parse --abbrev-ref HEAD` |
-| change 分支 | `speculo/<workflow>/<change>` |
-| worktree 路径 | `{state-root}/<workflow>/changes/<change>/.worktree/` |
-分支或路径已存在 → 停止报告，不覆盖、不复用。
-## 创建
-```bash
-mkdir -p {state-root}/<workflow>/changes/<change>
-git worktree add -b speculo/<workflow>/<change> {state-root}/<workflow>/changes/<change>/.worktree
-cd {state-root}/<workflow>/changes/<change>/.worktree
-```
-> 若平台有原生 worktree 工具（如 `EnterWorktree`）且用户要求使用：用原生工具，但目标路径对齐 change 目录下 `.worktree/` 约定。无法指定路径时注明实际路径，收尾时按真实路径清理。
-## 项目设置与基线
-```bash
-[ -f package.json ] && (npm install 2>/dev/null || true)
-[ -f Cargo.toml ] && cargo build
-[ -f requirements.txt ] && pip install -r requirements.txt
-[ -f go.mod ] && go mod download
-# 跑项目基线测试
-```
-基线失败 → 报告询问，未获许可不开始实现。
-## 返回
-- `base_branch`、`change_branch`、`worktree_path`（绝对路径）
-- `worktree_status: active`
-- 由调用方写入 change `.status.json`