@gordon.gan/specflow 1.8.0-beta → 1.8.2-beta

package/templates/approval-index.yaml

@@ -1,93 +0,0 @@
-# specflow.approval.index/v1 — copy to specflow/changes/<name>/approval/index.yaml
-schema: specflow.approval.index/v1
-change: <change-name>
-generated_at: 2026-08-26T12:00:00+08:00
-mode: segmented
-ui_in_scope: false
-db_in_scope: true
-api_in_scope: true
-
-optional:
-  s5: false
-  s7: false
-  s8: false
-
-parts_order:
-  - 01-intro
-  - 02-design-review
-  - 03-architecture
-  - 04-detail-core
-  - 04.4-data
-  - 04.5-api
-  - 04.7-logic
-  - 04.8-config
-  - 04.9-compat
-  - 06-test
-  - 09-implementability
-  - 10-signoff
-
-design_points: [P1]
-decisions: [D1]
-
-tables: []
-interfaces: []
-pages: []
-capabilities: []
-
-batching:
-  tables_per_call: 3
-  interfaces_per_call: 3
-  pages_per_call: 3
-  capabilities_per_call: 1
-
-conventions:
-  architecture: []
-  database: []
-  api: []
-  frontend: []
-
-meta:
-  language: zh-CN
-  tech_stack: unknown
-  project_mode: brownfield
-
-# ACP (recommended for non-lightweight) — see prompts/approval/acp-pipeline.md
-acp:
-  pipeline: acp/v2
-  context_budget_tokens: 40000
-  output_budget_tokens: 8000
-  review:
-    enabled: true
-    required_pass: true
-  # feature_slices:
-  #   - id: core-flow
-  #     parts: [04-detail-core, 04.5-api]
-
-# 多仓时启用 (见 prompts/approval/multi-repo-guidance.md)
-# multi_repo:
-#   enabled: true
-#   document_mode: per_repo          # per_repo + bundle (推荐 A) | per_repo only (B) | unified (C)
-#   primary_repo: talos              # bundle 或 unified 时必填
-#   bundle:
-#     enabled: true
-#     playbook: approval-playbook.yaml
-#     output: approval-unified.md
-#     readonly: true
-#   repos:
-#     - id: talos
-#       label: 平台
-#       role: platform
-#       change: <change-name>
-#     - id: talos-web
-#       label: 控制台
-#       role: web
-#       change: <web-change-name>
-#   outputs:
-#     per_repo:
-#       - repo: talos
-#         change: <change-name>
-#         path: specflow/changes/<change-name>/approval.md
-#     bundle:
-#       repo: talos
-#       change: <change-name>
-#       path: specflow/changes/<change-name>/approval-unified.md

package/templates/approval-part.md

@@ -1,15 +0,0 @@
-<!--
-  Approval part fragment — NOT a standalone document.
-  Written under specflow/changes/<name>/approval/parts/<part-id>.md
-  Assembled by: specflow approval finalize <change>
--->
-
-<!-- part-id: <must match filename without .md> -->
-<!-- index-ref: approval/index.yaml parts_order -->
-
-<!-- FORBIDDEN in parts:
-  - Top-level "# 技术方案审批文档"
-  - Foreign chapter headings "## N." not owned by this part
-  - TODO / 待补充 / 此处省略 / 详见 design (without §ref)
-  - Empty or placeholder-only body
--->

package/templates/approval-playbook-talos-scenario-job-compile.yaml

@@ -1,29 +0,0 @@
-# specflow.approval.playbook/v1 — TALOS scenario-job-compile 三仓合订示例
-# Copy to: specflow/changes/scenario-job-compile/approval/approval-playbook.yaml
-# Used after per_repo split: each repo has its own approval/parts + approval.md
-schema: specflow.approval.playbook/v1
-change: scenario-job-compile
-title: 场景作业编译与逐步上报（三仓合订）
-primary_repo: talos
-
-sources:
-  - repo: talos
-    change: scenario-job-compile
-    include_parts: all
-  - repo: talos-web
-    change: web-scenario-cases
-    root: /Users/gankang/TALOS-WORK/talos-web
-    include_parts: all
-  - repo: talos-worker
-    change: scenario-execution
-    root: /Users/gankang/TALOS-WORK/talos-worker
-    include_parts: all
-
-overlay:
-  - overlays/01-unified-scope.md
-
-assemble:
-  inject_headers: true
-  dedupe_appendix: true
-  output: approval-unified.md
-  readonly: true

package/templates/approval-playbook.yaml

@@ -1,28 +0,0 @@
-# specflow.approval.playbook/v1 — copy to specflow/changes/<change>/approval/approval-playbook.yaml
-schema: specflow.approval.playbook/v1
-change: <change-name>
-title: <合订标题>
-primary_repo: talos
-
-sources:
-  - repo: talos
-    change: <platform-change>
-    include_parts: all
-  - repo: talos-web
-    change: <web-change>
-    root: /path/to/talos-web/planning-root
-    include_parts: [04.6-ui, 06-test]
-  - repo: talos-worker
-    change: <worker-change>
-    root: /path/to/talos-worker/planning-root
-    include_parts: [04.5-api-worker, 04.7-logic]
-
-# optional overlay markdown under approval/overlays/
-# overlay:
-#   - overlays/01-unified-scope.md
-
-assemble:
-  inject_headers: true
-  dedupe_appendix: true
-  output: approval-unified.md
-  readonly: true

package/templates/approval.md

@@ -1,261 +0,0 @@
-<!--
-  Approval document template (v4 — implementer-first, optional chapters).
-  Generated by /specflow:approval after refine converges (phase=refined).
-  OPTIONAL artifact — does not affect phase, apply gate, or archive.
-
-  Chapter order:
-  1. 绪论与边界
-  2. 技术方案评估
-  3. 架构整体设计
-  4. 方案详细设计
-  5. 验收标准 — 可选(写入前询问用户)
-  6. 测试策略
-  7. 部署/发布/回滚 — 可选(写入前询问用户)
-  8. 闭环性检查 — 可选(写入前询问用户;分析仍必做)
-  9. 可实施性评估
-  10. 审批意见 — 仅人工签字栏(AI 预审只在对话反馈)
-
-  质量红线 G1–G6 + 文风(含禁止代码腔):见 prompts/approval/generate.md Part E。
--->
-
-# 技术方案审批文档: <change-name>
-
-> 本文档由 `/specflow:approval` 基于 refine 收敛后的四件套 + 现有代码与 spec 基线生成,
-> 含架构与详细设计等章节,供人工审批使用。AI 闭环/预审结论在对话中反馈,不写入本文。
-> 生成时间: YYYY-MM-DD HH:MM | phase: refined | 产物语言: <en|zh-CN> | 技术栈: <stack> | 项目模式: <greenfield|brownfield>
-
-> **质量红线(必须满足)**:G1 超 5 行流程→图示 · G2 接口须有失败示例 · G3 JSON/新列须有存量填充策略 · G4 须有回滚数据兼容说明 · G5 有 UI 须有页面/路由清单+栈五元组 · G6 关键页须有空/加载/错态。  
-> **文风**:通俗中文、缩写首次注解、禁用含糊词;**正文禁止代码腔**(路径/函数名堆砌→可读中文)。
-
----
-
-## 1. 绪论与边界 (Introduction & Boundaries)
-
-### 1.1 背景与痛点 (Background & Pain Points)
-
-### 1.2 做什么与影响面 (What & Impact)
-
-### 1.3 业务闭环与目标 (Business Loop & Goals)
-
-### 1.4 非目标 (Non-Goals)
-
----
-
-## 2. 技术方案评估 (Technical Design Review)
-
-### 2.1 现状与约束 (Context & Constraints)
-
-<!-- 可读中文要点;禁止代码腔。绿场可写「尚无存量代码」。 -->
-
-### 2.2 技术选型 (Tech Stack Selection)
-
-<!-- 0→1 或四件套缺选型时强制;来源=用户确认优先。棕地小改可写「沿用现网」。 -->
-
-| 方向 | 选定方案 | 备选(若有) | 选择理由 | 来源 |
-|------|----------|------------|----------|------|
-| 前端 | | | | |
-| 后端 | | | | |
-| 数据库与缓存 | | | | |
-| 基础设施 | | | | |
-
-### 2.3 目标与非目标 (Goals & Non-Goals)
-
-### 2.4 决策评审表 (Decision Review)
-
-| 决策 | 选定方案 | 备选方案 | 理由 | 影响评估 | 状态 |
-|------|---------|---------|------|---------|------|
-| | | | | | |
-
-### 2.5 风险与权衡 (Risks & Trade-offs)
-
-### 2.6 设计质量评估 (Design Quality)
-
----
-
-## 3. 架构整体设计 (Architecture Design)
-
-<!-- 起草前:project-conventions-guidance.md topic=architecture;图要点注明项目约定路径。 -->
-
-### 3.1 总体架构 (Architecture Overview)
-
-### 3.2 核心组件说明 (Core Components)
-
-### 3.3 架构一致性自检
-
----
-
-## 4. 方案详细设计 (Detailed Design)
-
-### 4.1 设计要点一览
-
-### 4.2 核心业务时序 · Happy Path(强制)
-
-### 4.3 业务场景时序
-
-### 4.4 数据结构 / 数据模型变更 (Data Structures)
-
-<!-- 顺序:项目约定(database) → SpecFlow DB guidance → 现网 DDL。
-     总则必填「项目约定」「DB 技能」「DDL 来源」。优先级:项目>guidance>LLM。 -->
-
-#### 4.4.1 总则与本迭代结构变更结论
-
-| 项 | 结论 |
-|----|------|
-| 数据库迁移 | |
-| 新建表 | |
-| 新增/修改/删除列 | |
-| 新增索引 | |
-| DDL 来源 | |
-| 项目约定 | <path / 未发现> |
-| DB 技能 | <guidance 路径 / LLM-fallback> |
-
-#### 4.4.2 ER 图(核心实体关系)
-
-#### 4.4.3 逐表详设
-
-#### 4.4.4 非表字段、数据迁移与回滚兼容
-
-### 4.5 接口设计 (Interface Design)
-
-<!-- 起草前:project-conventions-guidance.md topic=api。
-     大纲仅 4.5.1–4.5.3 + ##### In;字段/示例用加粗。 -->
-
-### 4.6 前端 / UI 设计 (Frontend / UI Design)
-
-<!-- 仅 uiInScope=yes。起草前:topic=frontend + frontend-guidance.md §3
-     (强制扫 IDE skills/rules + 落地文档 ≤5)。大纲仅 4.6.1–4.6.5 + ##### Page。G5/G6。 -->
-
-#### 4.6.1 总则与本迭代结论
-
-| 项 | 结论 |
-|----|------|
-| Surface | |
-| Framework | |
-| Styling / 设计系统 | |
-| State | |
-| UI kit | |
-| FE testing | |
-| 本迭代页面 | |
-| 项目约定 | <path / 未发现> |
-| IDE skills/rules | <path / 未发现> |
-
-#### 4.6.2 信息架构与路由
-
-#### 4.6.3 关键页面 / 组件详设
-
-#### 4.6.4 状态与数据获取
-
-#### 4.6.5 视觉与验证回路
-
-### 4.7 核心算法 / 逻辑说明 (Core Logic)
-
-### 4.8 配置与运行环境 (Configuration & Runtime)
-
-### 4.9 兼容性与迁移 (Compatibility & Migration)
-
----
-
-## 5. 验收标准 (Acceptance Criteria)
-
-<!-- 可选:用户确认「要」才输出本整章;否则删除本节。 -->
-
-### 5.1 Capability: <name>
-
-| Scenario | WHEN | THEN | 可测试性 | 说明 |
-|----------|------|------|---------|------|
-| | | | | |
-
----
-
-## 6. 测试策略 (Test Strategy)
-
-### 6.1 分层测试矩阵
-
-| 测试层级 | 覆盖对象 | 工具/框架 | 目标(证明什么) | 覆盖的验收标准 |
-|---------|---------|----------|---------------|---------------|
-| | | | | 有 §5 则引 Scenario;无 §5 则引 specs 名 |
-
-### 6.2 测试环境与数据
-
-### 6.3 测试策略自检
-
----
-
-## 7. 部署/发布/回滚方案 (Deployment & Release)
-
-<!-- 可选:用户确认「要」才输出本整章;否则删除本节。 -->
-
-### 7.1 部署方案 (Deployment)
-
-### 7.2 发布策略 (Release Strategy)
-
-### 7.3 回滚方案 (Rollback)
-
-### 7.4 监控与可观测性 (Monitoring & Observability)
-
-### 7.5 部署方案自检
-
----
-
-## 8. 闭环性检查 (Closed-Loop Verification)
-
-<!-- 可选:用户确认「要」才输出。内部分析仍必跑 Pass 1–7,结论在对话反馈。 -->
-
-| Pass | 检查项 | 结论 | 关键证据(一句话;⚠️/❌ 可列 2–3 条要点) |
-|------|--------|------|--------------------------------------|
-| 1 | 需求闭环 proposal↔specs | ✅/⚠️/❌ | |
-| 2 | 方案闭环 design↔specs | ✅/⚠️/❌ | |
-| 3 | 规格闭环 场景/可测试性/delta | ✅/⚠️/❌ | |
-| 4 | 实施闭环 tasks↔specs | ✅/⚠️/❌ | |
-| 5 | 风险闭环 缓解/BREAKING | ✅/⚠️/❌ | |
-| 6 | 代码落地性 锚点/结构/栈 | ✅/⚠️/❌/⊘ | |
-| 7 | 基线对照 主 specs | ✅/⚠️/❌/⊘ | |
-
-**整体闭环性:** PASS / PASS WITH WARNINGS / FAIL
-
----
-
-## 9. 可实施性评估 (Implementability Assessment)
-
-| 评估维度 | 结论 | 说明 |
-|---------|------|------|
-| 完整性 | READY / NEEDS REFINEMENT / BLOCKED | |
-| 规格对齐 | | |
-| 任务可执行性 | | |
-| 技术可行性 | | |
-| 依赖明确性 | | |
-| 架构一致性 | | |
-| 实施风险 | | |
-
-**可实施性总评:** READY / NEEDS REFINEMENT / BLOCKED
-
----
-
-## 10. 审批意见 (Approval Decision)
-
-<!-- 禁止写入 AI 预审建议;仅人工签字栏。 -->
-
-### 10.1 人工审批签字栏
-
-| 角色 | 姓名 | 审批结论 | 日期 | 意见 |
-|------|------|---------|------|------|
-| 技术负责人 | | □ 批准 □ 退回 □ 拒绝 | | |
-| 产品负责人 | | □ 批准 □ 退回 □ 拒绝 | | |
-| 架构师 | | □ 批准 □ 退回 □ 拒绝 | | |
-
-> 批准 → `/specflow:apply`;退回 → `/specflow:refine`;拒绝 → 废弃本次 change。
-
----
-
-## 附录 A: 产物溯源
-
-| 章节 | 数据来源 | 处理方式 |
-|------|---------|---------|
-| 绪论与边界 | proposal + explore(可选) | AI 提炼 |
-| 技术方案评估 | design + 用户确认选型(若有) | 约束 + **技术选型(绿场/补缺)** + 决策/风险/质量 |
-| 架构 / 详细设计 | design + specs + 锚点 + FE 约定(若有 UI) | 图+要点+数据/接口/**前端** |
-| 验收标准 | specs | **可选** |
-| 测试策略 | §5 或 specs 名 | 分层矩阵 |
-| 部署/闭环 | 运行环境 / Pass 1–7 | **可选** |
-| 可实施性 | 四件套+代码 | 写入文档 |
-| 审批意见 | 人工 | 仅签字栏 |