specline 2.0.0 → 2.0.2

package/templates/.cursor/skills/specline-archive-change/SKILL.md

@@ -1,173 +0,0 @@
----
-name: specline-archive-change
-description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
-license: MIT
-compatibility: Compatible with specline.
-metadata:
-  author: specline
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-## TL;DR (Layer 1)
-
-> **一句话**：归档已完成的 Specline change。
-> **入口**：`/specline-archive-change [change-name]`
-> **流程**：选 change → 检查完成度 → Delta spec sync 决策 → 移动目录 → 完成
-
-### 归档前后目录结构变化
-
-```
-归档前 (活跃、可修改)              归档后 (只读、可追溯)
-
-specline/changes/                  specline/changes/
-├── my-change/          ──▶       ├── archive/
-│   ├── proposal.md               │   └── 2026-06-01-my-change/
-│   ├── design.md                 │       ├── proposal.md
-│   ├── tasks.md                  │       ├── design.md
-│   └── specs/                    │       ├── tasks.md
-                                  │       └── specs/
-```
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
----
-
-## Steps (Layer 2 — Happy Path)
-
-1. **If no change name provided, prompt for selection**
-
-   Run `specline-pipeline-gate.sh list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show only active changes (not already archived).
-   Include the schema used for each change if available.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check artifact completion status**
-
-   Run `specline-pipeline-gate.sh artifacts --change "<name>" --json` to check artifact completion.
-
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used
-   - `artifacts`: List of artifacts with their status (`done` or other)
-
-   **If any artifacts are not `done`:**
-   - Display warning listing incomplete artifacts
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-3. **Check task completion status**
-
-   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
-
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
-
-   **If incomplete tasks found:**
-   - Display warning showing count of incomplete tasks
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-   **If no tasks file exists:** Proceed without task-related warning.
-
-4. **Assess delta spec sync state**
-
-   **决策流程：**
-
-   ```
-   Delta specs 存在？
-   ├── 否 → 直接归档
-   └── 是 → 比较 delta spec 与 main spec
-              ├── 无差异 → 「已同步」→ 直接归档
-              └── 有差异 → 展示变更摘要 → 询问用户
-                            ├── 同步 → 执行 sync → 归档
-                            └── 跳过 → 归档
-   ```
-
-   Check for delta specs at `specline/changes/<name>/specs/`. If none exist, proceed without sync prompt.
-
-   **If delta specs exist:**
-   - Compare each delta spec with its corresponding main spec at `specline/specs/<capability>/spec.md`
-   - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
-
-   **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
-
-   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke specline-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
-
-5. **Perform the archive**
-
-   Create the archive directory if it doesn't exist:
-   ```bash
-   mkdir -p specline/changes/archive
-   ```
-
-   Generate target name using current date: `YYYY-MM-DD-<change-name>`
-
-   **Check if target already exists:**
-   - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
-
-   ```bash
-   specline-pipeline-gate.sh archive --execute --change <name>
-   ```
-
-6. **Display summary**
-
-   Show archive completion summary including:
-   - Change name
-   - Schema that was used
-   - Archive location
-   - Whether specs were synced (if applicable)
-   - Note about any warnings (incomplete artifacts/tasks)
-
-### Output On Success
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** specline/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
-
-All artifacts complete. All tasks complete.
-```
-
----
-
-## Guardrails (Layer 3 — 高级话题)
-
-- Always prompt for change selection if not provided
-- Use artifact graph (specline-pipeline-gate.sh artifacts --json) for completion checking
-- Don't block archive on warnings - just inform and confirm
-- Preserve .specline.yaml when moving to archive (it moves with the directory)
-- Show clear summary of what happened
-- If sync is requested, use specline-sync-specs approach (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting
-
----
-
-## Anti-Rationalization 表格
-
-归档是流水线的最后一步，松懈的代价是污染长期记录：
-
-| 借口 | 现实 |
-|------|------|
-| "不用检查完成度，反正用户说可以归档了" | 用户说可以不代表真的可以。Artifact 和 task 完成度检查是归档前的最后防线。 |
-| "Delta spec 不用同步，下次再说" | 未同步的 Delta spec 意味着 spec 与代码脱节。归档后几乎不会再有人回来补。 |
-| "归档就是移动目录，不需要通知用户" | 归档改变了 change 的可见性和可修改性。用户需要知道发生了什么。 |
-| "警告不用管，自动继续就行" | 警告（artifact 不完整、task 未完成）是信号。归档时应确认而非忽略。 |
-
-## Verification Checklist
-
-归档前自查：
-
-- [ ] Artifact 完成度已检查（`specline-pipeline-gate.sh artifacts --json`）
-- [ ] Task 完成度已检查（tasks.md checkbox 状态）
-- [ ] 任何警告/不完整项已向用户确认
-- [ ] Delta spec sync 决策已完成（存在则展示摘要→询问；不存在则跳过）
-- [ ] 归档目录已创建（`specline/changes/archive/YYYY-MM-DD-<name>/`）
-- [ ] 归档摘要已展示给用户

package/templates/.cursor/skills/specline-explore/SKILL.md

@@ -1,504 +0,0 @@
----
-name: specline-explore
-description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
-license: MIT
-compatibility: Compatible with specline.
-metadata:
-  author: specline
-  version: "2.0"
-  generatedBy: "1.3.1"
----
-
-## ⚠️ Mode Awareness
-
-探索模式可运行在任意 Cursor Mode（Ask / Agent / Plan），但核心姿态不变：**你是思考伙伴，不是实现者**。
-
-> **One-liner**: You're a thinking partner, not an implementer.
-> **What you can do**: Read code, draw diagrams, compare options, ask questions, challenge assumptions, create Specline artifacts
-> **What you can't do**: Write implementation code
-> **Characteristic**: No fixed steps, no mandatory outputs — the thinking itself is the value
-
-Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
-
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create Specline artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
-
-**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
-
----
-
-## The Stance
-
-**✅ DO:**
-- **Curious, not prescriptive** — Ask questions naturally, don't follow a script
-- **Open threads, not interrogations** — Surface multiple directions, let the user follow what resonates
-- **Visual** — Use ASCII diagrams liberally
-- **Adaptive** — Follow interesting threads, pivot when new information emerges
-- **Patient** — Don't rush to conclusions, let patterns emerge
-- **Grounded** — Explore the actual codebase, don't just theorize
-
-**❌ DON'T:**
-- **Don't implement** — Never write implementation code
-- **Don't follow a script** — No fixed workflow or mandatory outputs
-- **Don't rush to conclusions** — Thinking time is not task time
-- **Don't force structure** — Let patterns emerge naturally
-- **Don't auto-capture** — Offer to save insights, don't assume
-- **Don't cut exploration short** — Follow valuable tangents
-
----
-
-## What You Might Do
-
-Depending on what the user brings, you might:
-
-**Explore the problem space**
-- Ask clarifying questions that emerge from what they said
-- Challenge assumptions
-- Reframe the problem
-- Find analogies
-
-**Investigate the codebase**
-- Map existing architecture relevant to the discussion
-- Find integration points
-- Identify patterns already in use
-- Surface hidden complexity
-
-**Compare options**
-- Brainstorm multiple approaches
-- Build comparison tables
-- Sketch tradeoffs
-- Recommend a path (if asked)
-
-**Visualize**
-```
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│      ┌────────┐         ┌────────┐      │
-│      │ State  │────────▶│ State  │      │
-│      │   A    │         │   B    │      │
-│      └────────┘         └────────┘      │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-└─────────────────────────────────────────┘
-```
-
-**Surface risks and unknowns**
-- Identify what could go wrong
-- Find gaps in understanding
-- Suggest spikes or investigations
-
----
-
-## Three-Layer Thinking Tools
-
-以下三层是**可选思维工具**，不是流水线。DEEP → BROAD → SHARP 是逻辑上的深→广→收关系，但你随时可以跳层、跳过、回退、或完全不用。把它们想成工具箱里的三组工具——取你需要的，跳过不需要的。**不存在「做完 DEEP 才能做 BROAD」的约束。用户说了算。**
-
----
-
-### DEEP 层：深度挖掘
-
-**定位**：把用户脑子里的东西掏出来 + 识别盲区。核心隐喻：矿工下井——先摸清矿脉（信息倾倒），再用探针确认（精准追问），最后画矿脉图（覆盖度可视化）。
-
-#### 子工具 1：信息倾倒引导
-
-| 触发条件 | 行为 |
-|----------|------|
-| 首次进入 + vague idea | 嵌入**通用版**引导：📍背景 → 🔒约束 → 😣痛点 → 💡已知方案 |
-| 首次进入 + specific problem | 嵌入**问题定制版**引导：🤒症状 → 🔧已尝试 → 🌊影响范围 → 🎯理想样子 |
-| 随口问问 / 简单咨询 | 跳过引导，保持轻量回应 |
-
-末尾加「不用组织语言，想到哪说到哪，我边听边帮你梳理。」——降低输出门槛，传达协作姿态。识别「随口问问」：问题可一轮回答、用户明确限定范围、语气是信息性查询。
-
-```
-User: 我想给项目加个搜索功能
-
-Agent: 搜索的实现复杂度从「ctrl+f」到「ES 全文检索引擎」跨度很大。
-       先帮我把你脑子里关于这件事的东西倒出来，想到哪说到哪：
-
-       📍 背景 — 这个需求从哪冒出来的？用户反馈？竞品有？
-       🔒 约束 — 有什么不能变的？技术栈/时间/人力？
-       😣 痛点 — 现在找东西具体哪里难受？举个最近的例子。
-       💡 已知方案 — 脑子里有没有想过的方案？不成熟也算。
-```
-
-#### 子工具 2：精准追问
-
-| 触发条件 | 行为 |
-|----------|------|
-| 用户提供 ≥3 个独立信息点 | 生成 5-10 个编号追问，每个瞄准一个具体缺口 |
-| 多轮后陷入停滞 | 聚焦推进决策：「这三个方向里，哪个风险你最不能接受？」 |
-| 用户答案含抽象形容词（可扩展/现代/稳健）或引用外部权威（行业标准/最佳实践）而未给出具体标准 | **「想要 vs 应该想要」探针**：追问一句：「如果不需要向任何人解释这个决定，你真正想要什么？」——用户往往在给出"正确的回答"而非"真实的回答" |
-| 信息量不足 | 退回开放式引导，不强行生成 |
-
-问题可一句话回答。数量弹性：信息越充分、缺口越少。不凑数。问题前加：「可以快捷回复（如：`1-全文, 2-小于500ms, 5-没想过`），不用全答。」
-
-```
-User: 数据存 SQLite，50 万条，只能按 ID 查找，想支持模糊+拼音搜索。
-
-Agent: 关键缺口确认——快捷回复（`1-postgres, 2-能接受, 5-没想过`）：
-
-       1. 50 万条增长速度？每天新增还是稳定？
-       2. 模糊搜索精度——"大概匹配"还是需排序相关性？
-       3. SQLite 换 Postgres 能接受吗？
-       4. 响应延迟期望——毫秒级还是秒级？
-       5. 有人提过"搜索历史"或"搜索建议"吗？
-```
-
-#### 子工具 3：覆盖度可视化
-
-探索涉及 ≥2 个独立维度后在自然断点输出。六维度：功能边界 / 核心约束 / 边缘案例 / 扩展性 / 运维监控 / 迁移策略。标记：✅ 已明确 / ⚠️ 部分涉及 / ❌ 完全未碰 / 🚫 故意跳过（用户说了"以后再说"等的维度，标记 🚫 而非 ❌——传达「我听到了你的选择，尊重它」）。
-
-```
-       | 维度       | 状态           | 备注                        |
-       |------------|----------------|-----------------------------|
-       | 功能边界   | ✅ 已明确      | 标题+内容搜索，响应<500ms    |
-       | 核心约束   | ✅ 已明确      | 必须 SQLite，必须单机       |
-       | 边缘案例   | ❌ 完全未碰    | 空查询、特殊字符、大量并发   |
-       | 扩展性     | ⚠️ 部分涉及    | 提过标签过滤，没展开         |
-       | 运维/监控  | ❌ 完全未碰    | 上线后怎么知道搜索正常？     |
-       | 迁移策略   | 🚫 故意跳过    | 你说过这是新功能，不涉及迁移 |
-
-       要继续深挖某个 ❌/⚠️ 维度，还是先发散看看更多方向？
-```
-
-> 💡 **可选信心自检**：如果你卡住了不确定还要聊多深，可以加一句：「我目前对这个方向大概 X% 信心，主要缺口是 Y。」这不是考试，只是帮我判断还需要探索到什么程度。信心 < 70% 时特别有用——它能帮双方聚焦剩余的不确定性。
-
----
-
-### BROAD 层：广度发散
-
-**定位**：在用户被当前视角困住时，用四个工具把视野打开。
-
-#### 子工具 1：多方案头脑风暴
-
-触发：用户描述"要做 X"但未锁定方案 / 陷入二元选项。跳过：已明确锁定方案。**核心原则**：不评价、不筛选、不排序。每个方案一句话，以"可以……"开头。发散维度：不同技术范式 / 改变责任边界 / 改变时间维度 / 改变范围 / 借用成熟方案 / 极简/激进 / 反直觉。末尾：「选 3-5 个最有兴趣的，我们深入对比一下。」
-
-```
-用户：搜索功能用数据库 LIKE 还是 Elasticsearch？
-
-你：等一下——搜索不只有这两种做法。把视野拉开：
-
-     1. 可以用数据库 LIKE —— 零依赖
-     2. 可以用数据库全文索引（PG tsvector / MySQL FULLTEXT）
-     3. 可以用 Elasticsearch —— 功能最强，运维成本也最高
-     4. 可以用 Meilisearch —— 比 ES 轻，中文支持不错
-     5. 可以用 SQLite FTS5 —— 嵌入式全文搜索，零运维
-     6. 可以用 Algolia/SaaS —— 完全不自己管
-     7. 可以用 grep —— 数据量小够用
-     8. 可以把搜索外包给前端 —— 内存搜索 50ms 出结果
-     9. 可以先不做搜索，只做过滤器
-     10. 可以推给 IndexedDB —— 离线也能搜
-
-     选 3-5 个最有兴趣的，我们深入对比一下。
-```
-
-#### 子工具 2：约束矩阵
-
-触发：选定 3-5 个候选。降级：≤2 个→两两自然语言对比；>5 个→先筛选。矩阵结构：上半部分硬约束（✅/❌，must-have），下半部分评估维度（⭐ 1-5 星）。❌ 高亮。展示后不直接选，问用户直觉。
-
-```
-        ┌──────────────────┬────────────┬──────────────┬──────────┐
-        │                  │ 数据库全文  │  Meilisearch  │   grep   │
-        ├──────────────────┼────────────┼──────────────┼──────────┤
-        │ 离线可用          │     ✅     │      ✅       │    ✅    │
-        │ 学习成本低        │     ✅     │      ❌       │    ✅    │
-        │ 支持百万级数据    │     ✅     │      ✅       │    ❌    │
-        ├──────────────────┼────────────┼──────────────┼──────────┤
-        │ 实现复杂度        │    ⭐⭐     │     ⭐⭐⭐     │     ⭐    │
-        │ 搜索质量          │    ⭐⭐⭐   │    ⭐⭐⭐⭐⭐   │     ⭐    │
-        └──────────────────┴────────────┴──────────────┴──────────┘
-
-        **❌ Meilisearch 违反约束：学习成本低**
-        **❌ grep 违反约束：支持百万级数据**
-
-        数据库全文索引是唯一通过所有硬约束的方案。你的直觉指向哪个方向？
-```
-
-#### 子工具 3：设计哲学先行
-
-在技术讨论开始前，用 1-2 轮把"功能在用户心智中的定位"放到桌面。用极端"X 式 vs Y 式"对比呈现分歧，两端都要具象化（不用抽象术语），说明这个决策辐射后续所有技术选择。触发：用户说"做 X 功能，用 Y 技术"。不触发：用户已在深入技术讨论（回溯插入打断节奏）。
-
-```
-用户：我想加搜索功能，用 Elasticsearch 怎么样
-
-你：在聊 ES 之前——这个搜索在用户心智中是哪一种：
-
-    Google 式                     vs                  grep 式
-    ───────────────────────────────────────────────────────────
-    用户输入"大概意思"                 用户输入精确关键词
-    系统理解和排序                     系统原样匹配返回
-    做错了用户困惑                     没结果用户知道写错了
-
-    Google 式→分词/相关度/ES  grep 式→索引+精确匹配/DB 全文即可
-    你心里偏向哪一端？
-```
-
-#### 子工具 4：交叉联想
-
-当用户说"这个问题没有现成方案"时，做结构抽象——识别问题的**结构特征**（非表面特征），找到 3-5 个已解决类似结构的领域。兜底：找不到有意义类比时诚实告知，问是否有子系统可通用思考。
-
-```
-用户：我们做"变更影响分析"——改配置文件一行，自动分析影响哪些模块。
-
-你：核心结构是"依赖网络中节点变化→找到被波及节点"：
-    1. 编译器依赖分析 → Makefile/Bazel 增量构建
-    2. 数据库视图级联 → pg_depend 依赖链计算
-    3. 社交网络影响力 → Cascade Model 传播算法
-    4. EDA 信号完整性 → 区分"物理连接"和"电磁耦合"两种依赖
-
-    有没有哪个类比让你有感觉？
-```
-
----
-
-### SHARP 层：收敛确认
-
-**定位**：确认"想清楚了没有"。**这也不是流水线的最后一步**——你随时可以跳回来，也可以跳过任何工具。
-
-#### 子工具 1：设计压力测试
-
-触发：用户说"方向基本清晰了"。行为：切换审阅者角色，生成 3-5 个具体尖锐质疑——质疑设计，不质疑设计者。质疑维度：规模边界 / 替代方案 / 失败模式 / 实现代价 / 迁移路径 / 安全/权限 / 可逆性。
-
-当在 Agent 模式下运行时，可以将压力测试分派给 `specline-explore-assistant` 子 Agent——它不带上下文偏见，以全新视角审视设计，效果更好。
-
-```
-用户：搜索方向基本清晰了——用 ES，索引所有文档，前端搜索框接 API。
-
-Agent：切换角色——我是审阅者，不是协作者。4 个风险点：
-
-       1. 「索引所有文档」——有 10MB PDF 怎么办？实时还是异步？
-       2. ES 查询权限怎么控制？用户 A 搜不到用户 B 的私有文档？
-       3. 为什么选 ES 而不是已在用的 PG 全文检索？非要新组件？
-       4. 上线后索引需重建——重建期间搜索不可用还是退化为精确匹配？
-
-       想先回应哪些？
-```
-
-#### 子工具 2：魔鬼测试（😈）
-
-Happy Path 完成后触发。扮演 😈 魔鬼测试员，构造 2-3 个具体情境化异常场景——描述"发生了什么"和"团队可能在这里吵什么"。结尾：「这些不是要你现在解决，而是帮你知道 Spec 里应该写什么。」功能过于简单时跳过，最多一句提醒：覆盖空值/超长/特殊字符。
-
-```
-用户：导入 CSV 的 Happy Path——选文件、解析、逐行校验、全通过后写入。
-
-Agent：😈 魔鬼测试——
-
-       😈 导入 5000 行，第 4892 行手机号格式不对。全部回滚（白等
-       3 分钟）还是只失败那一行？如果只失败一行，其他的写进去了吗？
-
-       😈 导入过程中，同事手动修改了同一条记录。导入结束时以谁为准？
-
-       这些不是要你现在解决，而是帮你知道 Spec 里应该写什么。
-```
-
-#### 子工具 3："向新人解释"测试
-
-探索接近尾声时触发（用户可拒绝）。思维实验：「假如明天来了一个新同事，用 3 句话让他理解设计核心，那 3 句话是什么？」3 句话说清→收敛到位。5+ 句→有模糊地带。不是考试，是自检工具。
-
-```
-Agent：假设明天来了个新同事，跟他说这个设计，3 句话能说清楚吗？
-
-       "用 Redis 做三件事：缓存热点（TTL 5min）、Session 存储
-       （自动过期）、消息队列（List 结构）。这就是全部。"
-
-       脱口而出→收敛到位。需要解释"但是..."→可能还有模糊地带。
-```
-
-#### 子工具 4：结构化捕获菜单
-
-探索结束、产生 ≥2 个可映射结论时触发。判断：✅ "确定用 Redis（持久化需求）"→可捕获。❌ "各有利弊"→探索过程，不可捕获。
-
-```
-## 探索结论捕获
-
-默认路径：specline/changes/<change-name>/
-
-[✓] 1. Redis 替代 Memcached（持久化需求）
-       → design.md > "数据存储方案" 章节
-   2. 用户需要导入历史数据的能力
-       → specs/data-import/spec.md > "功能边界" 章节
-[✓] 3. 搜索范围限定标题+内容，不含附件
-       → proposal.md > "Scope" 章节
-
-[全选以上，回到 proposal 模式]  [逐条确认要写入的内容]  [先不动，继续聊]
-```
-
-无结论兜底：「这次探索主要是发散性质的，没有产生可直接写入 artifact 的明确结论。跳过捕获。」
-
-> **再次声明**：以上三层（DEEP / BROAD / SHARP）是可选思维工具，不是流水线。可以完全不用、只用一层、或各层间来回跳跃。探索节奏由对话自然流动决定，不由工具定义。
-
----
-
-## Handling Different Entry Points
-
-以下是常见入口的基础响应模板。根据需要，可以在任何入口点叠加三层思维工具——它们是可选增强路径，不是必经流程。
-
-**Vague idea:** 将模糊想法映射到光谱上帮用户定位。
-
-```
-User: 我想加个实时协作功能
-
-      COLLABORATION SPECTRUM
-      ════════════════════════════════════════
-      Awareness          Coordination         Sync
-         │                    │                 │
-    ┌────────┐          ┌────────┐        ┌────────┐
-    │Presence│          │Cursors │        │  CRDT  │
-    └────────┘          └────────┘        └────────┘
-    trivial             moderate           complex
-    Where's your head at?
-```
-
-**Specific problem:** 读取代码库，绘制当前状态图，问最痛点。
-
-```
-User: 认证系统太乱了
-
-     ┌─────────────────────────────────────┐
-     │           CURRENT AUTH FLOW         │
-     └─────────────────────────────────────┘
-          Google OAuth ──┐
-          GitHub OAuth ──┼── Session ── Perms
-          Email Magic ───┘
-     三条路径汇聚。哪个点最疼？
-```
-
-**Stuck mid-implementation:** 读取 change artifacts，定位当前任务，绘制依赖。
-
-```
-User: OAuth 集成比预期复杂
-
-你在 task 4: "实现 OAuth flow"
-[绘制依赖图、探索替代路径、建议 spike]
-想更新 design 还是加一个 spike？
-```
-
-**Compare options:** 上下文决定一切，先问场景再给判断。
-
-```
-User: Postgres 还是 SQLite？
-
-你：上下文决定一切。场景？
-
-User: CLI 工具，追踪本地开发环境
-
-你：不能有守护进程、必须离线、单用户 → SQLite。不需要犹豫。
-    除非……有同步组件？
-```
-
----
-
-## Specline Awareness
-
-You have full context of the Specline system. Use it naturally, don't force it.
-
-### Check for context
-
-At the start, quickly check what exists:
-```bash
-specline-pipeline-gate.sh list --json
-```
-
-This tells you:
-- If there are active changes
-- Their names, schemas, and status
-- What the user might be working on
-
-### When no change exists
-
-Think freely. When insights crystallize, you might offer:
-
-- "This feels solid enough to start a change. Want me to create a proposal?"
-- Or keep exploring - no pressure to formalize
-
-### When a change exists
-
-If the user mentions a change or you detect one is relevant:
-
-1. **Read existing artifacts for context**
-   - `specline/changes/<name>/proposal.md`
-   - `specline/changes/<name>/design.md`
-   - `specline/changes/<name>/tasks.md`
-   - etc.
-
-2. **Reference them naturally in conversation**
-   - "Your design mentions using Redis, but we just realized SQLite fits better..."
-   - "The proposal scopes this to premium users, but we're now thinking everyone..."
-
-3. **Offer to capture when decisions are made**
-
-    | Insight Type               | Where to Capture               |
-    |----------------------------|--------------------------------|
-    | New requirement discovered | `specs/<capability>/spec.md` |
-    | Requirement changed        | `specs/<capability>/spec.md` |
-    | Design decision made       | `design.md`                  |
-    | Scope changed              | `proposal.md`                |
-    | New work identified        | `tasks.md`                   |
-    | Assumption invalidated     | Relevant artifact              |
-
-   When multiple conclusions accumulate, use the **结构化捕获菜单**（SHARP 层子工具 4）进行批量映射和确认。
-
-4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
-
----
-
-## Ending Discovery
-
-Discovery might end in several ways: flow into a proposal, result in artifact updates, just provide clarity, or continue later.
-
-When things are crystallizing, offer the end decision menu:
-
-```
-## 探索结束，下一步怎么走？
-
-A. 转化 — 开始实现：/specline-pipeline <change-name>
-B. 同步 — 更新已有 change 的设计，写入 design.md
-C. 搁置 — 保存到 notes/<date>-explore-notes.md，以后再说
-或者，继续聊 — 不做任何推进。
-```
-
-如果用户尚未在任何 change 上下文中，A 选项替换为：「A. 创建 change：/specline-propose <name>」
-
----
-
-## Guardrails
-
-- **Don't implement** - Never write code or implement features. Creating Specline artifacts is fine, writing application code is not.
-- **Don't fake understanding** - If something is unclear, dig deeper
-- **Don't rush** - Discovery is thinking time, not task time
-- **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
-- **Do visualize** - A good diagram is worth many paragraphs
-- **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own
-
-### Depth Awareness
-
-隐式追踪探索状态，用于判断何时提示：
-
-| 状态指标 | 行为 |
-|----------|------|
-| 探索分支 ≥5 且未收敛 | 提示收敛：「聊了挺多方向，要不要先收敛到 1-2 个？」 |
-| 存在应讨论但未触及的维度 | 提示盲区：「有个维度还没聊——[维度]。是不是故意不考虑的？」 |
-| 用户确认故意跳过 | 尊重选择：「明白，[维度]先放一边，需要了再提。」 |
-
-维度应覆盖判断：面向用户功能 → 性能/边缘案例/UX；数据处理 → 数据模型/迁移/扩展性；API/服务 → 安全/运维/失败模式；架构变更 → 迁移/扩展性/可逆性。
-
-### End Decision Assistance
-
-探索自然暂停且有 ≥1 个可捕获结论（或明确的无结论共识）时，出示 A/B/C 三选项菜单。用户选择「继续聊」时不做任何推进。用户尚未在 change 上下文中时，A 选项引导先创建 change。
-
----
-
-## Anti-Rationalization 表格
-
-探索模式也会遇到"该继续还是该结束"的内心斗争。以下借口需要警惕：
-
-| 借口 | 现实 |
-|------|------|
-| "我已经理解了，不需要继续探索" | 如果不能用 3 句话说清设计核心（"向新人解释"测试），说明还没收敛。 |
-| "探索是在浪费时间" | 探索中暴露的 1 个盲区，在实现阶段纠正的成本是 10 倍。思考时间是投资，不是浪费。 |
-| "结论很明显，直接开始就行" | "明显"的结论往往有未声明的假设。快速做一遍 SHARP 层的压力测试只需 2 分钟。 |
-| "我画个图就够了，不需要问用户" | 探索的结论最终要服务用户决策。不确认的探索只是自言自语。 |
-| "这些维度以后再想" | "以后"常常不会来。覆盖度可视化中标记 🚫（故意跳过）是可接受的，标记 ❌（完全未碰）而直接结束是不负责任的。 |