@namewta/speculo 0.2.16 → 0.3.1

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

@@ -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

@@ -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

@@ -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/common/dev-worktree/SKILL.md

@@ -1,138 +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)。核心流程：
-
-### A0. 检测现有隔离
-
-```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，跳到 A3 设置
-- `GIT_DIR == GIT_COMMON` → 主工作区，继续
-
-### A1. 命名与路径
-
-| 要素 | 值 |
-|------|-----|
-| 基础分支 | 当前分支（`git rev-parse --abbrev-ref HEAD`） |
-| change 分支 | `speculo/<workflow>/<change>` |
-| worktree 路径 | `{state-root}/<workflow>/changes/<change>/.worktree/` |
-
-分支或路径已存在 → 停止，不覆盖不复用。
-
-**前置检查：** `speculo/.speculo/` 必须被 git 跟踪——产物需随分支合并。若被忽略则降级为非 worktree 模式。
-
-### A2. 创建
-
-```bash
-git worktree add -b speculo/<workflow>/<change> {state-root}/<workflow>/changes/<change>/.worktree
-```
-
-确保 `.gitignore` 含 `.worktree/`；缺失则追加并提交。
-
-### A3. 项目设置与基线
-
-自动检测并安装依赖、运行基线测试：
-
-```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
-# 跑基线测试
-```
-
-基线测试失败 → 报告并询问，未获许可不开始实现。
-
-### A4. 写回状态
-
-将 `base_branch`、`change_branch`、`worktree_path`、`worktree_status: active` 写入 change 的 `.status.json`。
-
----
-
-## 阶段 B：收尾合并
-
-详细步骤见 [references/finalize.md](references/finalize.md)。
-
-### B1. 验证测试
-
-跑项目测试套件。失败 → 停止，禁止合并/PR。
-
-### B2. 展示选项
-
-```
-实现已完成。你想怎么做？
-
-1. 本地合并回 <base-branch>（推荐，默认）
-2. 推送并创建 Pull Request
-3. 保持现状（稍后处理）
-4. 丢弃
-
-选哪个？
-```
-
-分离 HEAD 时移除选项 1。用户未指定时默认选项 1。
-
-### B3. 执行 —— 顺序不可变
-
-**选项 1（本地合并）：**
-1. 合并到 base：`git checkout <base> && git pull && git merge --no-ff <change_branch>`
-2. 在合并结果上再跑测试
-3. 测试通过 → 从主仓库根删除 worktree：`git worktree remove <path>`
-4. 删除分支：`git branch -d <change_branch>`
-5. `git worktree prune`
-6. 更新 `.status.json`：`worktree_status: removed`
-
-**选项 2（PR）：** 推送分支、创建 PR，保留 worktree。
-**选项 3（保持）：** 不动，报告状态。
-**选项 4（丢弃）：** 确认后删除 worktree 和分支。
-
-合并冲突或测试失败 → 停止，保留现场，报告原因，不强推。
-
----
-
-## 红线
-
-**绝不：**
-- 已在 worktree 时嵌套创建
-- 覆盖已有分支或路径
-- 测试失败时继续合并/PR
-- 合并结果未验证就删 worktree
-- 先删分支再 worktree remove（顺序：merge → remove worktree → delete branch）
-- 在 worktree 内部执行 `git worktree remove`
-- 未经确认执行破坏性操作
-- 强制推送
-
-**始终：**
-- 分支名：`speculo/<workflow>/<change>`
-- worktree 路径：change 目录下的 `.worktree/`
-- 创建后装依赖 + 基线测试
-- 收尾前验证测试
-- 合并成功后再清理
-- 清理后 `git worktree prune`

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

@@ -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`

package/template/workflows/specdev/common/dev-worktree/references/finalize.md

@@ -1,102 +0,0 @@
-# 收尾合并与清理
-
-实现完成后合并回 base、清理 worktree 与分支。由 SKILL.md 阶段 B 调用。**破坏性操作须先确认。**
-
-## 前置
-
-- 测试通过（未通过不得合并）
-- 产物已在 `change_branch` 上提交
-- 已有 `base_branch`、`change_branch`、`worktree_path`
-
-## 检测环境
-
-```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)
-WORKTREE_PATH=$(git rev-parse --show-toplevel)
-FEATURE_BRANCH=$(git branch --show-current)
-```
-
-确定 base 分支：
-```bash
-BASE=$(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null || echo "")
-```
-
-## 展示选项
-
-展示前先验测试。**命名分支：**
-
-```
-实现已完成。你想怎么做？
-
-1. 本地合并回 <base-branch>（推荐，默认）
-2. 推送并创建 Pull Request
-3. 保持现状（稍后处理）
-4. 丢弃
-
-选哪个？
-```
-
-**分离 HEAD：** 移除选项 1，仅提供 2/3/4。用户未指定时默认推荐选项 1。
-
-## 选项 1：本地合并
-
-顺序固定——**先合并验证 → 再删 worktree → 最后删分支**：
-
-```bash
-MAIN_ROOT=$(git rev-parse --show-toplevel)
-cd "$MAIN_ROOT"
-
-git checkout <base-branch>
-git pull   # 仅远程存在且用户未禁止时
-git merge --no-ff <change_branch>
-```
-
-合并后跑测试。**失败 → 停止，保留现场，报告原因。**
-
-测试通过后：
-
-```bash
-# 必须在主仓库根执行，不能在 worktree 内部
-git worktree remove {worktree_path}
-git worktree prune
-git branch -d <change_branch>
-```
-
-更新 `.status.json`：`worktree_status: removed`。
-
-报告：已合并到 `<base-branch>`，worktree 与分支已清理。
-
-## 选项 2：PR
-
-推送分支，创建 PR，保留 worktree。若需指定远程或目标分支，先确认。
-
-## 选项 3：保持
-
-不动 worktree 和分支。报告当前状态，以便后续继续。
-
-## 选项 4：丢弃
-
-确认后删除 worktree 和分支（不合并）：
-
-```bash
-cd "$MAIN_ROOT"
-git worktree remove {worktree_path}
-git worktree prune
-git branch -D <change_branch>
-```
-
-## 失败处理
-
-| 情况 | 处理 |
-|------|------|
-| 合并冲突 | 停止，报告冲突文件，保留 worktree/分支，不强推 |
-| worktree remove 失败 | 停止报告，不 `--force`（用户明确要求除外） |
-| 已合并不回滚 | 除非用户明确要求 |
-
-## 清理规则
-
-- **只清理约定路径下的 worktree**（change 目录下 `.worktree/`）
-- 路径不匹配 → 不删（可能由 harness 管理）
-- 永远在主仓库根执行 `git worktree remove`
-- 顺序不可颠倒：merge → remove worktree → delete branch

package/template/workflows/specdev/common/improve-codebase-architecture/HTML-REPORT.md

@@ -1,125 +0,0 @@
-# HTML 报告格式
-
-架构审查渲染为一个独立的 HTML 文件，存放在操作系统临时目录中。Tailwind 和 Mermaid 均来自 CDN。Mermaid 处理图形状的图表；手工构建的 div 和内联 SVG 处理更具编辑性的可视化（质量图、横截面图）。混合使用两者 — 不要所有事情都依赖 Mermaid，否则会变得千篇一律。
-
-`{{config.defaults.report_language}}` 占位符由 runtime-context 输出的 `config` 对象填充，值来自 `speculo/config.json` 的 `defaults.report_language` 字段；若 config 文件不存在，默认值为 `"en"`。Tailwind 和 Mermaid 均来自 CDN。Mermaid 处理图形状的图表；手工构建的 div 和内联 SVG 处理更具编辑性的可视化（质量图、横截面图）。混合使用两者 — 不要所有事情都依赖 Mermaid，否则会变得千篇一律。
-
-## 脚手架
-
-```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>
-      /* Tailwind 无法很好覆盖的小型自定义层：
-         虚线接缝线、手绘感箭头等。 */
-      .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>
-```
-
-## 页头
-
-仓库名称、日期和一个紧凑的图例：实线框 = 模块，虚线 = 接缝，红色箭头 = 泄漏，粗黑框 = 深模块。无介绍段落 — 直接进入候选。
-
-## 候选卡片
-
-图表承担主要分量。文字稀疏、平实，并使用来自 `/codebase-design` skill 的术语，不刻意修饰。
-
-每个候选是一个 `<article>`：
-
-- **标题** — 简短，命名深化方案（例如"Collapse the Order intake pipeline"）。
-- **徽章行** — 推荐强度（`Strong` = 翡翠绿，`Worth exploring` = 琥珀色，`Speculative` = 石板灰），外加一个依赖类别标签（`in-process`、`local-substitutable`、`ports & adapters`、`mock`）。
-- **文件** — 等宽字体列表，`font-mono text-sm`。
-- **Before / After 图表** — 核心。两列，并排。参见下方模式。
-- **Problem** — 一句话。痛点是什么。
-- **Solution** — 一句话。改变了什么。
-- **Wins** — 要点，每个不超过 6 个词。例如 "Tests hit one interface"、"Pricing logic stops leaking"、"Delete 4 shallow wrappers"。
-- **ADR 标注**（如适用）— 一行，放在琥珀色调的框中。
-
-无需解释段落。如果图表需要一段文字才能理解，重新画图。
-
-## 图表模式
-
-选择适合候选的模式。混合使用它们。不要让每个图表看起来都一样 — 多样性本身就是目的的一部分。
-
-### Mermaid 图表（依赖/调用流的常用工具）
-
-当重点是"X 调用 Y 调用 Z，看看这有多混乱"时，使用 Mermaid `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>` 表示。箭头用绝对定位在相对容器上的内联 SVG `<line>` 或 `<path>` 元素表示。当你希望"after"图表看起来像一个粗边的深模块，内部元素灰显时使用 — Mermaid 不会以合适的权重渲染这种效果。
-
-### 横截面图（适合分层浅度）
-
-堆叠水平条（`h-12 border-l-4`）来展示调用经过的各层。Before：6 个薄层，每个都不做什么。After：一个厚条，标注合并后的职责。
-
-### 质量图（适合"接口与实现一样宽"的场景）
-
-每个模块两个矩形 — 一个表示接口表面积，一个表示实现。Before：接口矩形几乎和实现矩形一样高（浅）。After：接口矩形短，实现矩形高（深）。
-
-### 调用图坍缩
-
-Before：嵌套框呈现的函数调用树。After：同一棵树坍缩成一个框，内部调用在其内部以淡化形式显示。
-
-## 样式指导
-
-- 偏向编辑风格，而非企业仪表盘风格。宽松的留白。标题可选择衬线字体（`font-serif` 与 stone/slate 搭配效果很好）。
-- 色彩使用克制：一种强调色（翠绿或靛蓝），加上红色用于泄漏，琥珀色用于警告。
-- 保持图表约 320px 高，使 before/after 能够舒适地并排放置而无需滚动。
-- 使用 `text-xs uppercase tracking-wider` 用于图表内的模块标签 — 它们应读起来像示意图，而非 UI。
-- 唯一的脚本是 Tailwind CDN 和 Mermaid ESM 导入。除此之外报告是静态的 — 没有应用代码，除了 Mermaid 自身的渲染之外没有交互。
-
-## 顶部推荐部分
-
-一张更大的卡片。候选名称，一句话说明为什么，指向其卡片的锚链接。这就够了。
-
-## 语气
-
-平实的英语，简洁 — 但架构名词和动词直接来自 `/codebase-design` skill。简洁不是偏离的借口。
-
-**完全使用：** module、interface、implementation、depth、deep、shallow、seam、adapter、leverage、locality。
-
-**绝不替代：** component、service、unit（代替 module）· API、signature（代替 interface）· boundary（代替 seam）· layer、wrapper（代替 module，当你的意思是 module 时）。
-
-**符合风格的表达方式：**
-
-- "Order intake module is shallow — interface nearly matches the implementation."
-- "Pricing leaks across the seam."
-- "Deepen: one interface, one place to test."
-- "Two adapters justify the seam: HTTP in prod, in-memory in tests."
-
-**Wins 要点**用术语表命名收益：*"locality: bugs concentrate in one module"*、*"leverage: one interface, N call sites"*、*"interface shrinks; implementation absorbs the wrappers"*。不要写 *"easier to maintain"* 或 *"cleaner code"* — 这些术语不在术语表中，不值得留下。
-
-不模糊其词，不清喉咙，不说"值得注意的是……"。如果一句话可以变成一个要点，就变成要点。如果一个要点可以删除，就删除它。如果一个术语不在 `/codebase-design` 术语表中，在发明新术语之前先用术语表中已有的。