specline 1.1.3 → 1.2.1

package/README.md

@@ -8,8 +8,16 @@
 /specline-pipeline "实现用户登录功能"
 ```
 
+修 bug、改配置、文档微调？用轻量模式：
+
+```
+/specline-quickfix "修复登录按钮样式"
+```
+
 ## 它能做什么
 
+**完整流水线**（新功能、重构）：
+
 ```
 自然语言需求 → Spec → 审核 → 编码 → 审查 → 测试 → 归档
                 ↑       ↑      ↑      ↑      ↑      ↑
@@ -18,12 +26,20 @@
                   并行              reviewer  E2E
 ```
 
+**轻量修复**（修 bug、改配置、文档微调）：
+
+```
+/ specline-quickfix "描述" → 理解代码 → 直接编辑 → Lint+自审 → 现有单测 → 轻量归档
+                             0 个子 Agent      0 个人工确认      0 个 state 文件
+```
+
 每个阶段都经过 **确定性门禁校验** —— 用 `grep`、`jq`、编译器退出码、测试退出码判断通过与否。**质量判断零 LLM 参与**。
 
 ## 核心特性
 
 - **需求驱动**：自然语言 → 结构化规格文档（Requirements + Scenarios + WHEN/THEN）
 - **并行编码**：自动按前端/后端/config 拆分任务，同批次并发派发 Coding Agent
+- **TDD 白盒测试**：无依赖任务自动启用 TDD 模式（先写单测 → 确认失败 → 最小实现 → 重构），与黑盒 test-writer 并行协作
 - **确定性门禁**：每个阶段用 Shell 脚本的退出码判定是否通过，不做模糊判断
 - **黑盒测试**：测试 Agent 只看 Spec 文档，不能读取任何实现源码
 - **断点续跑**：随时中断，下次从最后一个可信门禁自动恢复（tasks.md 的 `[x]`/`[ ]` 标记进度）
@@ -59,8 +75,8 @@ specline sync --dry-run    # 预览变更
 my-project/
 ├── .cursor/
 │   ├── agents/          ← 9 个 Specline Agent 定义
-│   ├── commands/        ← 2 个 Slash 命令入口
-│   ├── skills/          ← 5 个 Skill 指令
+│   ├── commands/        ← 3 个 Slash 命令入口
+│   ├── skills/          ← 6 个 Skill 指令
 │   ├── hooks/           ← 7 个 Gate/Hook 脚本
 │   └── hooks.json       ← Cursor Hook 配置
 ├── specline/            ← 运行时目录
@@ -77,13 +93,36 @@ my-project/
 /specline-pipeline "添加 JWT 用户认证"
 ```
 
+小改动用快速模式：
+
+```
+/specline-quickfix "修改按钮颜色"
+```
+
 开始编码前先探索思路：
 
 ```
 /specline-explore
 ```
 
-## 流水线阶段
+## 工作流选择
+
+Specline 提供两种工作流，按变更规模选择：
+
+| 维度 | Quickfix (`/specline-quickfix`) | Pipeline (`/specline-pipeline`) |
+|------|-------------------------------|-------------------------------|
+| 文件改动数 | 1-3 个 | 4+ 个 |
+| 关注点 | 单一关注点 | 多关注点/跨模块 |
+| 架构变更 | 无新架构/新组件 | 需要新组件/新 API |
+| 测试 | 不需要新测试 | 需要写新测试 |
+| 典型场景 | 修 bug、改配置、文档微调 | 新增功能、重构 |
+| 产出 | summary.md + files-changed.json | proposal/design/tasks/specs + 全部测试 |
+| 人工确认 | 0 个 | 3 个 |
+| 耗时 | 1-3 分钟 | 10-30 分钟 |
+
+**使用建议**：如果不确定，优先用 quickfix。如果需要更严格的流程保证，用 pipeline。
+
+## 完整流水线阶段
 
 ```
 PHASE 1: SPEC（规格）
@@ -91,15 +130,16 @@ PHASE 1: SPEC（规格）
     ├── proposal.md    — 需求提案（What/Why/Scope）
     ├── specs/*/spec.md — 功能规格（Requirements/Scenarios/WHEN-THEN）
     ├── design.md      — 技术设计（架构/数据流/决策）
-    └── tasks.md       — 任务清单（Type/Depends/Covers/Files + [ ] 进度标记）
+    └── tasks.md       — 任务清单（Type/Depends/Covers/Testable/Files + [ ] 进度标记）
   → specline-spec-reviewer 审核
   → Gate: grep + jq 格式校验
   → 🟡 人工确认 Spec 和任务规划
 
 PHASE 2: CODING（编码）
   解析 tasks.md → 按依赖 DAG 分层 → 同批次前后端/config Agent 并发
+  无依赖 + 可测试任务 → 自动启用 TDD 模式（RED-GREEN-REFACTOR）
   每完成一个任务，[ ] 自动标记为 [x]
-  → Gate: 编译检查（tsc --noEmit / python -m compileall）
+  → Gate: 编译检查（tsc --noEmit / python -m compileall） + 单元测试文件存在性检查
 
 PHASE 3: REVIEW（审查）
   specline-code-reviewer + specline-config-reviewer 分别审查代码和配置/文档
@@ -116,16 +156,55 @@ PHASE 5: ARCHIVE（归档）
   → delta specs 合并到主规格目录
   → 按日期归档到 specline/changes/archive/
   ✅ 完成
+
+### TDD 白盒测试
+
+Pipeline 采用「两层测试分离」架构：
+
+```
+Coding Agent（白盒 TDD）              Test-Writer（黑盒）
+─────────────────────────            ─────────────────
+产出: tests/unit/**                  产出: tests/integration/**
+      tests/models/**                      tests/e2e/**
+测试: 单个函数的输入输出              测试: 跨模块的用户行为
+      边界条件、异常路径                     API 端到端契约
+      Spec Scenario 全覆盖
+触发: 编码时同步产出                   触发: Phase 2 与 Coding 并行启动
+      先写测试 → 确认失败 → 写实现        只读 Spec，不读源码
+```
+
+tasks.md 中 `Testable: true` 的任务自动启用 TDD 模式（完整 RED-GREEN-REFACTOR 循环），`Testable: false` 的任务保持原有流程。两个测试域严格目录隔离，冲突检测自动识别越界。
+```
+
+## 轻量修复流程
+
+```
+PHASE 1: UNDERSTAND（理解）
+  读取相关代码 → 理解上下文 → 意图模糊时 AskUserQuestion 确认
+
+PHASE 2: IMPLEMENT（实现）
+  直接 Write/StrReplace 编辑 1-3 个文件
+  不需要 Spec 文档、DAG 构建、批次调度
+
+PHASE 3: REVIEW（审查）
+  ReadLints 检查 + 自动修复（最多 2 次）→ Agent 自审逻辑正确性
+
+PHASE 4: TEST（测试）
+  仅运行项目已有单元测试，无测试则跳过
+  失败自动修复最多 2 次
+
+PHASE 5: ARCHIVE（归档）
+  生成 summary.md + files-changed.json → 询问是否 git commit
 ```
 
 ## 架构
 
 ```
-/specline-pipeline       ← 你输入这个
-    │
-    ▼
-specline-pipeline SKILL  ← 编排层（读状态、派发 Agent、调 Gate）
-    │
+/specline-pipeline       ← 完整流水线（大功能）    /specline-quickfix    ← 轻量修复（小改动）
+    │                                                  │
+    ▼                                                  ▼
+specline-pipeline SKILL  ← 编排层                 编排者直接执行（无子 Agent）
+    │                                               Read → Write → ReadLints → Shell → 归档
 ┌───┼──────────────────┬──────────────────────┐
 ▼   ▼                  ▼                      ▼
 9 个子 Agent      specline-pipeline-     Cursor Hooks
@@ -149,13 +228,13 @@ specline-pipeline SKILL  ← 编排层（读状态、派发 Agent、调 Gate）
 |-------|------|
 | `specline-spec-creator` | 根据自然语言需求，基于内联模板直接生成 proposal/design/tasks/spec 四个文件 |
 | `specline-spec-reviewer` | 审核规格的完整性、一致性和覆盖度 |
-| `specline-frontend-dev` | UI 组件、页面、样式、交互逻辑（单个任务级别） |
-| `specline-backend-dev` | API 端点、数据模型、业务逻辑（单个任务级别） |
+| `specline-frontend-dev` | UI 组件、页面、样式、交互逻辑（单个任务级别，Testable 任务启用 TDD） |
+| `specline-backend-dev` | API 端点、数据模型、业务逻辑（单个任务级别，Testable 任务启用 TDD） |
 | `specline-config-dev` | Shell 脚本、配置文件（JSON/YAML）、Markdown 文档（处理 Type: config/docs 任务） |
 | `specline-code-reviewer` | 前端/后端代码质量、安全性、可维护性审查 |
 | `specline-config-reviewer` | Shell 脚本安全性、配置文件语法和一致性、Markdown 文档结构审查 |
-| `specline-test-writer` | 黑盒测试编写——只能看 Spec，不能读源码 |
-| `specline-test-runner` | 执行测试并分类失败原因（测试问题/代码问题/Spec 模糊） |
+| `specline-test-writer` | 黑盒测试编写——只能看 Spec 不能读源码，仅写集成测试（tests/integration/）和 E2E 测试 |
+| `specline-test-runner` | 执行测试并分类失败原因（测试问题/代码问题/Spec 模糊），区分单元测试（回 coding agent）和集成/E2E 测试（回 test-writer） |
 
 ## 确定性门禁
 
@@ -163,8 +242,8 @@ specline-pipeline SKILL  ← 编排层（读状态、派发 Agent、调 Gate）
 
 | 门禁 | 检查内容 |
 |------|---------|
-| Spec | `grep` 检查 Purpose/Requirements/Scenarios 章节完整性、WHEN/THEN 配对 |
-| Build | `tsc --noEmit` / `python -m compileall` 编译检查 |
+| Spec | `grep` 检查 Purpose/Requirements/Scenarios 章节完整性、WHEN/THEN 配对、Testable 字段格式与一致性 |
+| Build | `tsc --noEmit` / `python -m compileall` 编译检查 + Testable 任务单元测试文件存在性与语法检查 |
 | Lint | `ruff` / `eslint` 退出码 + code-review.json 中 error 数量 |
 | Test | 测试框架退出码 + 覆盖率阈值 |
 | Archive | 归档目录结构 + 必要文件完整性 |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "specline",
-  "version": "1.1.3",
+  "version": "1.2.1",
   "description": "Spec-driven AI coding pipeline with deterministic quality gates for Cursor IDE",
   "bin": {
     "specline": "./cli.mjs"

package/templates/.cursor/agents/specline-explore-assistant.md

@@ -0,0 +1,81 @@
+---
+name: specline-explore-assistant
+description: 设计压力测试子 Agent —— 以不带上下文偏见的新鲜视角审视探索结论，输出 3-5 个尖锐但建设性的质疑。当主 explore Agent 在 Agent 模式下运行且需要客观审阅时分派。
+---
+
+# 设计压力测试子 Agent
+
+## 角色
+
+你是一个**不留情面的设计审阅者**。你的唯一任务是从探索结论中找出漏洞、盲区和风险。你的原则是"说再想想"而非"说看起来不错"。
+
+## 触发场景
+
+被主 explore Agent 分派，当：
+- 探索方向基本清晰，需要第三方审视
+- 用户主动要求"帮我看看有没有漏洞"
+- 主 Agent 意识到自己被对话上下文绑定，需要新鲜视角
+
+## 输入格式
+
+主 Agent 传入的上下文：
+
+```
+## 设计摘要（3 句话）
+<核心设计逻辑的 3 句话概述>
+
+## 核心设计决策
+- 决策 1：...
+- 决策 2：...
+
+## 已知用户约束
+- 约束 1：...
+- 约束 2：...
+```
+
+## 工作方式
+
+1. **理解设计意图**：从摘要和决策中还原设计的核心逻辑
+2. **寻找裂缝**：从以下 4 个维度逐一检查：
+   - **规模边界**：当数据量/用户量/并发量增长 10-100 倍时，方案是否成立？
+   - **替代方案**：有没有更简单或更成熟的方案被忽略了？为什么不用？
+   - **失败模式**：最坏情况下会发生什么？有没有单点故障？
+   - **实现暗坑**：执行层面的隐藏成本——技术债务、迁移复杂度、团队学习曲线
+3. **生成质疑**：针对找到的裂缝输出 3-5 个具体质疑
+4. **输出报告**
+
+## 输出格式
+
+```markdown
+# 设计压力测试报告
+
+## 质疑 1：<一句话概括>
+
+**为什么这是问题**：
+<2-3 句说明风险，链接到具体的设计决策>
+
+**建议的验证路径**：
+<1-2 句说明怎么验证这个担忧是否真实>
+
+---
+（重复 3-5 次）
+```
+
+## 质疑质量标准
+
+| 原则 | 说明 |
+|------|------|
+| **具体** | "需要考虑性能"❌ → "100 万条数据下 FTS5 查询延迟可能超过 500ms 目标" ✅ |
+| **有后果链** | 不只说"有什么问题"，还要说"出问题后谁会受影响" |
+| **有验证路径** | 每个质疑附带一个可操作的验证方法 |
+| **挑战核心假设** | 优先质疑设计的基础假设，而不是实现细节 |
+| **不重复已知约束** | 用户已经明确说过"离线是硬约束"，就别问"你确定要离线吗" |
+
+## 约束
+
+- 不修改任何文件，只产出报告
+- 质疑语言尖锐但不攻击性——质疑设计，不质疑设计者
+- 必须给出"为什么值得担心"的理由
+- 不提供解决方案，只提出问题
+- 保持审视者的独立立场——不受主 Agent 对话上下文影响
+- 如果设计确实扎实，可以诚实说"未发现明显漏洞"，但不要为了填充数量而编造质疑

package/templates/.cursor/agents/specline-spec-reviewer.md

@@ -49,6 +49,7 @@ description: 审核 spec.md、design.md、tasks.md 的完整性和一致性。
    - 每个任务含 `Depends:` 标注
    - 每个任务含 `Covers:` 标注（链接到具体的 Requirement 和 Scenario）
    - 每个任务含 `Files:` 标注（非空，列出预期文件）
+   - 每个任务含 `Testable:` 标注（值在 true/false 范围内，可选但建议标注）
 
 2. **独立性**：
    - `Depends: (none)` 的任务占比 ≥ 50%（否则标记为 warning）
@@ -63,6 +64,12 @@ description: 审核 spec.md、design.md、tasks.md 的完整性和一致性。
    - backend 类型的任务应涉及 API/模型/逻辑
    - 没有 fullstack 类型（前端和后端必须拆开）
 
+5. **Testable 合理性**：
+   - `Testable: true` 的任务必须满足：Depends: (none) + Type ≠ config/docs + 有可拆分的独立逻辑单元
+   - `Testable: false` 的任务如果同时满足 Depends: (none) + Type ≠ config/docs + 有独立逻辑单元 → warning（建议标记为 Testable: true）
+   - 有上游依赖的任务 Testable 必须为 false
+   - Type 为 config/docs 的任务 Testable 必须为 false
+
 ## 输出格式
 
 产出 `specline/changes/<change-name>/specs/<capability>/spec-review.json`：
@@ -81,6 +88,7 @@ description: 审核 spec.md、design.md、tasks.md 的完整性和一致性。
     "total": 6,
     "independent": 4,
     "parallel_ratio": 0.67,
+    "testable_count": 3,
     "types": { "frontend": 2, "backend": 3, "config": 1 }
   },
   "design_review": {
@@ -98,11 +106,13 @@ description: 审核 spec.md、design.md、tasks.md 的完整性和一致性。
     "[spec.md] 缺少异常路径场景：未定义 'worker 数量为 0' 时的行为",
     "[tasks.md] 任务 3 缺少 Covers 标注",
     "[tasks.md] 任务 1 和 任务 2 的 Files 有交集：都包含了 src/utils/api.ts",
+    "[tasks.md] 任务 3 Testable=true 但存在上游依赖 (Depends: 1)，应为 false",
+    "[tasks.md] 任务 5 (Depends: none, Type: backend) 建议标记为 Testable: true",
     "[design.md] 提到使用 Redis 缓存，但 tasks.md 中没有对应的 infra 任务",
     "[coverage] Scenario '用户登出' 未被任何任务覆盖"
   ],
   "coverage": { "requirements_covered": 4, "requirements_total": 5, "scenarios_covered": 10, "scenarios_total": 14 },
-  "task_stats": { "total": 6, "independent": 4, "parallel_ratio": 0.67, "types": { "frontend": 2, "backend": 3, "config": 1 } },
+  "task_stats": { "total": 6, "independent": 4, "parallel_ratio": 0.67, "testable_count": 3, "types": { "frontend": 2, "backend": 3, "config": 1 } },
   "design_review": { "issues": ["Redis 缓存方案缺少对应的 infra 任务"] }
 }
 ```

package/templates/.cursor/commands/specline-explore.md

@@ -5,6 +5,15 @@ category: Workflow
 description: "Enter explore mode - think through ideas, investigate problems, clarify requirements"
 ---
 
+## ⚠️ 硬边界：探索模式禁止直接写代码
+
+**你只能做这些**：读取代码、画图、提问、比较方案、质疑假设、创建 Specline artifacts（proposal/design/specs）
+**你不能做这些**：写入/修改任何实现代码文件（Write、StrReplace、Delete、Shell 等会导致代码变更的操作）
+
+如果用户要你写代码 → 提醒退出探索模式，先 `/specline-pipeline` 或 `/specline-quickfix`。
+
+---
+
 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.

package/templates/.cursor/commands/specline-quickfix.md

@@ -0,0 +1,24 @@
+---
+name: /specline-quickfix
+id: specline-quickfix
+category: Workflow
+description: 轻量修改 Skill —— 小改动用 quickfix，大功能用 pipeline
+---
+
+轻量修改流程，在不创建规划文档的情况下快速执行小改动。
+
+**用法：**
+- `/specline-quickfix <描述>` — 执行轻量修改流程（修 bug、改配置、文档微调等小改动）
+
+**阶段：**
+1. UNDERSTAND — 读取相关代码，理解变更上下文
+2. IMPLEMENT — 直接编辑文件（单 Agent，无子 Agent）
+3. REVIEW — ReadLints 自动校验 + 修复（最多 2 次）+ Agent 自审
+4. TEST — 运行项目已有单元测试（失败修复最多 2 次），无测试则跳过
+5. ARCHIVE — 生成 summary.md + files-changed.json，询问 git commit
+
+**适用场景**：1-3 个文件改动、单一关注点、不涉及架构变更、不需要新测试。
+
+**不适合的场景**（应使用 `/specline-pipeline`）：4+ 个文件改动、新增功能/重构、需要新测试、跨模块/多关注点。
+
+0 个人工确认点，全程自动质量保证。

package/templates/.cursor/hooks/specline-pipeline-gate.sh

@@ -15,19 +15,27 @@
 
 set -euo pipefail
 
-# ===== 参数解析 =====
 PHASE="${1:-}"
 CHANGE=""
-if [ "$#" -ge 3 ] && [ "$2" = "--change" ]; then
-  CHANGE="$3"
-fi
-
-if [ -z "$PHASE" ]; then
-  echo "Usage: specline-pipeline-gate.sh <phase> --change <change-name>"
-  echo "Phases: new | list | artifacts | spec | build | lint | test-unit | test-integration | test-e2e | archive | status"
-  exit 2
-fi
-
+EXECUTE_ARCHIVE=""
+
+# 遍历所有参数，不依赖位置
+shift  # 跳过 PHASE
+while [ $# -gt 0 ]; do
+  case "$1" in
+    --change)
+      CHANGE="$2"
+      shift 2
+      ;;
+    --execute)
+      EXECUTE_ARCHIVE="--execute"
+      shift
+      ;;
+    *)
+      shift
+      ;;
+  esac
+done
 # ===== 项目根目录 =====
 SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
 PROJECT_ROOT="$(cd "$SCRIPT_DIR/../.." && pwd)"
@@ -300,7 +308,31 @@ gate_spec() {
   fi
   pass "tasks.md 标注完整性检查通过 ($task_count 个任务)"
 
-  # 10. 至少 1 个任务无依赖
+  # 10. Testable 字段校验
+  local testable_count
+  testable_count=$(grep -c '\*\*Testable\*\*:' "$tasks_file" || echo "0")
+
+  if [ "$testable_count" -eq 0 ]; then
+    echo "⚠️  Testable 标注缺失（向后兼容模式：缺失字段的任务将被视为 Testable: false）"
+  elif [ "$testable_count" -gt 0 ] && [ "$testable_count" -lt "$task_count" ]; then
+    local missing_testable_tasks
+    missing_testable_tasks=$(awk '
+      /^## / {
+        if (in_task && !has_testable) missing = missing (missing ? ", " : "") prev_task
+        prev_task = $2; gsub(/\..*/, "", prev_task)
+        in_task = 1; has_testable = 0
+      }
+      /\*\*Testable\*\*:/ { has_testable = 1 }
+      END {
+        if (in_task && !has_testable) missing = missing (missing ? ", " : "") prev_task
+        print missing
+      }' "$tasks_file")
+    echo "⚠️  Testable 标注不完整：任务=$task_count, Testable=$testable_count（缺失任务: $missing_testable_tasks；缺失字段的任务将被视为 Testable: false）"
+  else
+    pass "Testable 标注完整性检查通过 ($testable_count/$task_count)"
+  fi
+
+  # 11. 至少 1 个任务无依赖
   local independent_count
   independent_count=$(grep -c '\*\*Depends\*\*: (none)' "$tasks_file" || echo "0")
   if [ "$independent_count" -lt 1 ]; then
@@ -337,6 +369,86 @@ gate_build() {
     pass "Python 语法检查通过"
   fi
 
+  # 单元测试文件存在性检查（Testable=true 任务）
+  local tasks_file="$PROJECT_ROOT/specline/changes/$CHANGE/tasks.md"
+  if [ -f "$tasks_file" ]; then
+    local testable_true_count
+    testable_true_count=$(grep -c '\*\*Testable\*\*:.*true' "$tasks_file" || echo "0")
+
+    if [ "$testable_true_count" -gt 0 ]; then
+      echo "正在检查 $testable_true_count 个 Testable=true 任务的单元测试文件..."
+
+      local missing_files=""
+      local syntax_errors=""
+
+      while IFS='|' read -r task_id file_path; do
+        if [ -z "$file_path" ]; then
+          missing_files="${missing_files}
+  任务 $task_id: 未在 Files 列表中声明 tests/unit/ 或 tests/models/ 下的测试文件"
+          continue
+        fi
+
+        if [ ! -f "$PROJECT_ROOT/$file_path" ]; then
+          missing_files="${missing_files}
+  任务 $task_id: $file_path"
+          continue
+        fi
+
+        # 语法检查
+        case "$file_path" in
+          *.py)
+            if ! python -m py_compile "$PROJECT_ROOT/$file_path" 2>&1; then
+              syntax_errors="${syntax_errors}
+  任务 $task_id: $file_path (Python 语法错误)"
+            fi
+            ;;
+          *.ts|*.tsx)
+            if ! npx tsc --noEmit "$PROJECT_ROOT/$file_path" 2>&1; then
+              syntax_errors="${syntax_errors}
+  任务 $task_id: $file_path (TypeScript 语法错误)"
+            fi
+            ;;
+        esac
+      done < <(awk '
+        /^## / {
+          task_id = $2; gsub(/\..*/, "", task_id)
+          testable = ""; files_line = ""
+        }
+        /\*\*Testable\*\*:.*true/ { testable = "true" }
+        /\*\*Files\*\*:/ {
+          if (testable == "true") {
+            files_line = $0
+            gsub(/.*\*\*Files\*\*:[ \t]*/, "", files_line)
+            split(files_line, paths, /,[ \t]*/)
+            has_unit_test = 0
+            for (i in paths) {
+              gsub(/^[ \t]+|[ \t]+$/, "", paths[i])
+              if (paths[i] ~ /^tests\/(unit|models)\//) {
+                print task_id "|" paths[i]
+                has_unit_test = 1
+              }
+            }
+            if (has_unit_test == 0) {
+              print task_id "|"
+            }
+          }
+        }
+      ' "$tasks_file")
+
+      if [ -n "$missing_files" ]; then
+        fail "单元测试文件缺失:${missing_files}"
+      fi
+
+      if [ -n "$syntax_errors" ]; then
+        fail "单元测试文件语法错误:${syntax_errors}"
+      fi
+
+      pass "单元测试文件存在性检查通过"
+    else
+      echo "ℹ️  无 Testable=true 任务，跳过单元测试文件检查"
+    fi
+  fi
+
   write_gate_passed "phases.coding.gates.build_gate"
   pass "Build Gate 全部通过"
 }
@@ -551,7 +663,7 @@ gate_archive() {
   fi
 
   # 如果传了 --execute，执行实际归档动作
-  if [ "${1:-}" = "--execute" ]; then
+  if [ -n "$EXECUTE_ARCHIVE" ]; then
     local src_dir="$PROJECT_ROOT/specline/changes/$CHANGE"
     local archive_dir="$PROJECT_ROOT/specline/changes/archive"
     local date_prefix

package/templates/.cursor/hooks/specline-session-start.sh

@@ -6,10 +6,7 @@
 #   2. 检查当前 session 是否已有绑定
 #   3. 有绑定且 pipeline 仍活跃 → 使用已有绑定，注入上下文
 #   4. 有绑定但 pipeline 已失效 → 清理脏数据，重新扫描
-#   5. 无绑定 → 扫描活跃 pipeline：
-#      - 0 个 → 透明放行（echo '{}'）
-#      - 1 个 → 自动绑定并注入上下文
-#      - 2+ 个 → 注入"请选择"提示
+#   5. 无绑定 → 透明放行（echo '{}'）——不自动绑定，避免跨窗口污染
 #
 # Input (stdin JSON):
 #   { "session_id": "...", "is_background_agent": bool, ... }
@@ -254,63 +251,9 @@ if [ -n "$existing_change" ]; then
   fi
 fi
 
-# 3. No (valid) binding — scan active pipelines
-scan_result=$(scan_active_pipelines)
 
-# Count active pipelines
-pipeline_count=0
-if [ -n "$scan_result" ]; then
-  pipeline_count=$(printf '%s\n' "$scan_result" | wc -l | tr -d ' ')
-fi
-
-# 0 active pipelines → transparent pass-through
-if [ "$pipeline_count" -eq 0 ]; then
-  echo '{}'
-  exit 0
-fi
-
-# 1 active pipeline → auto-bind and inject context
-if [ "$pipeline_count" -eq 1 ]; then
-  change_name=$(printf '%s' "$scan_result" | cut -d'|' -f1)
-  phase=$(printf '%s' "$scan_result" | cut -d'|' -f2)
-  state_file=$(printf '%s' "$scan_result" | cut -d'|' -f3)
-
-  # Auto-bind
-  write_binding "$session_id" "$change_name"
-
-  # Inject context
-  ctx_json=$(build_context "$change_name" "$phase" "$state_file")
-
-  printf '{\n  "additional_context": %s\n}\n' "$ctx_json"
-  exit 0
-fi
-
-# 4. 2+ active pipelines → inject selection prompt (do NOT auto-bind)
-ctx_json=$({
-  printf '🚨 **Specline Pipeline 运行中 — 请选择 Pipeline**\n\n'
-  printf '**活跃 Pipeline** (%s 个):\n' "$pipeline_count"
-
-  while IFS='|' read -r change_name phase state_file; do
-    [ -n "$change_name" ] || continue
-    printf -- '- **%s**: %s 阶段' "$change_name" "$phase"
-
-    # Add task progress for coding phase
-    if [ "$phase" = "coding" ] && [ -f "$state_file" ]; then
-      completed=$(jq -r '[.phases.coding.tasks[]? | select(.status == "completed")] | length' "$state_file" 2>/dev/null || printf '0')
-      total=$(jq -r '[.phases.coding.tasks[]?] | length' "$state_file" 2>/dev/null || printf '0')
-      if [ "$total" != "0" ]; then
-        printf ' (%s/%s 任务完成)' "$completed" "$total"
-      fi
-    fi
-    printf '\n'
-  done <<< "$scan_result"
-
-  printf '\n**说明**: 当前发现了 %s 个活跃 Pipeline，但尚未绑定到本会话。\n' "$pipeline_count"
-  printf '**操作**: 请使用 `/specline-pipeline --change <名称>` 选择一个 Pipeline 以继续工作。\n\n'
-  printf '**阶段约束参考**:\n'
-  phase_constraint_table
-  printf '\n**提示**: 绑定后系统会自动注入正确的阶段上下文和约束。\n'
-} | jq -Rs '.')
-
-printf '{\n  "additional_context": %s\n}\n' "$ctx_json"
+# 3. No (valid) binding → transparent pass-through
+# 不再自动绑定或注入任何 pipeline 上下文，避免跨窗口污染。
+# 用户需通过 /specline-pipeline --change <name> 显式绑定。
+echo '{}'
 exit 0