specline 1.2.2 → 1.3.0

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

@@ -19,6 +19,10 @@ Implement tasks from a Specline change.
 > **入口**：`/specline-apply-change [change-name]` 或直接说「继续实现」
 > **流程**：选 change → 读上下文 → 逐任务实现 → 标记完成
 
+> ⚠️ **人机门禁策略感知**：当调用方传递了 `HUMAN_GATE_POLICY=minimal` 或 `HUMAN_GATE_POLICY=none` 上下文时，本 Skill 内所有的 `AskUserQuestion` 交互应自动采用默认安全选项：
+> - change 选择 → 若上下文中已有 change name，直接使用；否则取第一个活跃 change
+> - 其他确认交互 → 自动采用默认安全选项继续，不暂停等待人工输入
+
 **Fluid Workflow Integration**
 
 This skill supports the "actions on a change" model:

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

@@ -71,6 +71,20 @@ description: >-
     🟡 = Human Gate（人工确认检查点）
 ```
 
+### 人机门禁策略
+
+流水线有 3 个人工确认点：HG1（SPEC 确认）、HG2（Review 条件复核）、HG3（归档确认）。通过 `specline/config.yaml` 中的 `pipeline.human_gate_policy` 控制哪些 HG 需要人工确认：
+
+| 策略 | HG1 (SPEC确认) | HG2 (Review复核) | HG3 (归档确认) |
+|------|:-------------:|:----------------:|:-------------:|
+| `full`（默认） | 人工确认 | 条件人工复核 | 人工确认 |
+| `minimal` | 自动通过 | 自动通过 | 人工确认 |
+| `none` | 自动通过 | 自动通过 | 自动通过 |
+
+**读取方式**：在每个 HG 触发前读取 `specline/config.yaml` 的 `pipeline.human_gate_policy` 字段（通过 grep/yq），若策略指示跳过当前 HG，则直接写入 `.pipeline-state.json` 中对应 `human_gate_N.passed = true`，不调用 `AskUserQuestion`。
+
+**子 Agent 确认行为**：当策略为 `minimal` 或 `none` 时，编排者应在派发子 Agent 时传递 `HUMAN_GATE_POLICY=<policy>` 上下文，告知子 Agent 跳过所有 `AskUserQuestion` 交互（如 spec_ambiguity 暂停、skill 级确认等），直接采用默认安全选项继续执行。编排者自身在测试失败处理中的 spec_ambiguity 暂停也应改为记录 WARNING 事件日志后继续。
+
 ### 入口模式
 
 1. **新建流水线**: `/specline-pipeline <自然语言需求>`
@@ -173,6 +187,8 @@ exit code 0 = 通过，写入 passed。exit code != 0 = 失败，读取 stderr
 
 #### Step 5: 人工确认 (Human Gate 1) 🟡
 
+> **策略判断**：读取 `specline/config.yaml` → `pipeline.human_gate_policy`。若为 `minimal` 或 `none` → 跳过此 HG，直接写入 `human_gate_1.passed = true`，进入 Phase 2。
+
 Spec Gate 通过后，使用 `AskUserQuestion` 工具请求确认。展示内容包括：需求提案摘要、功能需求列表、任务拆解概览（含并行组）。
 
 > **用户交互规范**：所有需要用户做选择的交互，必须使用 `AskUserQuestion` 工具而非自由文本询问。结构化问题能让 Cursor 在单次请求中完成交互，避免额外轮次。
@@ -581,6 +597,8 @@ code-review.json 中 unit test 相关的 finding 标注 `type` 为 `"unit_test_q
 
 #### Step 11: 可选人工复核 (Human Gate 2) 🟡
 
+> **策略判断**：读取 `specline/config.yaml` → `pipeline.human_gate_policy`。若为 `minimal` 或 `none` → 跳过此 HG，直接写入 `human_gate_2.passed = true`，进入 Phase 4。
+
 仅当 code-review.json 中 warnings > 0 且 errors = 0 时，使用 `AskUserQuestion`：
 
 ```javascript
@@ -637,6 +655,8 @@ exit code 全 0 = 通过，进入 Phase 5。失败处理见 [Layer 3: 测试失
 
 #### Step 14: 归档确认 (Human Gate 3) 🟡
 
+> **策略判断**：读取 `specline/config.yaml` → `pipeline.human_gate_policy`。若为 `none` → 跳过此 HG，直接写入 `human_gate_3.passed = true`，执行归档。`minimal` 策略下 HG3 保留人工确认。
+
 全部测试通过后，使用 `AskUserQuestion` 请求归档确认：
 
 ```javascript
@@ -718,6 +738,8 @@ jq '.phases.coding.gates.build_gate.passed = null' "$STATE_FILE" > tmp && mv tmp
 - 回对应 coding agent 修复实现代码或测试代码（最多 2 次循环）
 - `spec_ambiguity`（Spec 模糊）→ **不自动循环修复**，暂停流水线并展示模糊点给用户
 
+  > **策略判断**：若 `pipeline.human_gate_policy` 为 `minimal` 或 `none` → 不暂停，将 spec_ambiguity 降级为 WARNING 记录到事件日志并继续下一阶段。
+
 Gate 重置（仅重置 test_unit_gate）：
 
 ```bash
@@ -732,6 +754,8 @@ jq '.phases.test.sub_phases.unit.gates.test_unit_gate.passed = null' "$STATE_FIL
   - **测试代码问题** → specline-test-writer 自修（最多 2 次）
   - **实现代码问题** → 利用 `Covers` 追溯链定位到具体任务，回对应 coding agent 修复 → **使用影响范围算法精确重置受影响任务的 Gate**
   - **`spec_ambiguity`**（Spec 模糊）→ **不自动循环修复**，暂停流水线并展示模糊点给用户
+
+  > **策略判断**：若 `pipeline.human_gate_policy` 为 `minimal` 或 `none` → 不暂停，将 spec_ambiguity 降级为 WARNING 记录到事件日志并继续下一阶段。
 - 循环最多 2 次
 
 Gate 重置：
@@ -1029,7 +1053,7 @@ postToolUse    → specline-reminder.sh
 | 1 | **不做判断，只做编排** | 不评估代码质量、需求好坏、测试覆盖——这些由子 Agent 和 Gate 脚本负责 |
 | 2 | **所有门禁通过 Gate 脚本** | 调用 `specline-pipeline-gate.sh`，不要自己写 grep/检查逻辑 |
 | 3 | **状态文件是唯一真相源** | 所有决策基于 `.pipeline-state.json` 的当前值 |
-| 4 | **人工确认点必须暂停** | 不要自动跳过 human_gate |
+| 4 | **人工确认点必须尊重策略** | 根据 `pipeline.human_gate_policy` 配置决定是否暂停，不要无条件跳过或强制暂停 human_gate |
 | 5 | **测试 Agent 必须黑盒** | 不给 specline-test-writer 传递源代码文件路径 |
 | 6 | **Hook 阻断绝不静默降级** | 子 Agent 被 hook 阻止时，必须先诊断、沟通、修复后重试 |
 | 7 | **接受 Hook 约束** | preToolUse/postToolUse/sessionStart Hook 会自动校验和提醒，不要试图绕过 |

package/templates/specline/config.yaml

@@ -1,5 +1,7 @@
 schema: spec-driven
 
+# Specline 项目配置 (config-schema-v1)
+#
 # Project context (optional)
 # This is shown to AI when creating artifacts.
 # Add your tech stack, conventions, style guides, domain knowledge, etc.
@@ -18,3 +20,45 @@ schema: spec-driven
 #       - Always include a "Non-goals" section
 #     tasks:
 #       - Break tasks into chunks of max 2 hours
+
+# Project structure (optional)
+# Declares project layout and module configuration.
+# When present, Gate scripts use these settings instead of auto-detection.
+# When absent, Gates auto-detect by scanning for language marker files (go.mod, package.json, etc.)
+#
+# Example (monorepo with Go backend + TypeScript frontend):
+#   project:
+#     layout: monorepo
+#     modules:
+#       - path: backend/
+#         language: go
+#         build: go build ./...
+#         lint: golangci-lint run ./...
+#         test: go test ./...
+#       - path: frontend/
+#         language: typescript
+#         build: npm run build
+#         lint: npx eslint .
+#         test: npx vitest run
+#
+# Example (single-language project):
+#   project:
+#     layout: single
+#     modules:
+#       - path: .
+#         language: python
+#         build: python -m compileall .
+#         lint: ruff check .
+#         test: pytest
+#
+# Supported languages: go, python, typescript, javascript, rust, java, kotlin
+# All fields under modules[] are optional except 'path' and 'language'
+
+# Pipeline configuration (optional)
+# Control the human gate policy for the pipeline.
+# - full:    All 3 human gates are active (default, current behavior)
+# - minimal: Only the archive confirmation (HG3) requires human approval;
+#            HG1 (SPEC confirm) and HG2 (code review check) are auto-approved
+# - none:    All human gates are auto-approved (use with caution, primarily for CI/CD)
+pipeline:
+  human_gate_policy: full