scene-capability-engine 3.0.0

package/template/.kiro/specs/SPEC_WORKFLOW_GUIDE.md

@@ -0,0 +1,134 @@
+# Kiro Specs 工作流指南
+
+> **用途**: Spec 驱动开发的完整工作流程和设计原则  
+> **适用**: 所有使用 kiro-spec-engine (kse) 的 Spec 驱动开发项目
+
+---
+
+## 📋 一、Spec 命名规范
+
+**格式**: `[功能名称]`（kebab-case）
+- 示例：`fix-duplicate-file-space-calculation`、`oauth-api-upgrade`
+
+**文档结构**:
+- `requirements.md` - 需求文档
+- `design.md` - 设计文档（可选）
+- `tasks.md` - 任务列表（可选）
+- `scripts/`, `diagnostics/`, `reports/`, `results/`
+
+---
+
+## 📁 二、三件套文档结构
+
+```
+XX-YY-功能名称/
+├── requirements.md  ← WHAT（做什么）
+├── design.md        ← HOW（怎么做）
+├── tasks.md         ← STEPS（执行步骤）
+└── scripts/, tests/, results/, reports/
+```
+
+### 2.1 requirements.md
+
+**结构**:
+```markdown
+# 功能名称
+## 1. 概述
+## 2. 用户故事
+## 3. 功能需求
+### 3.1 需求标题
+**描述**: ...
+**验收标准**: WHEN [条件] THEN [结果]
+## 4. 非功能需求
+## 5. 约束条件
+```
+
+### 2.2 design.md（可选）
+
+**结构**:
+```markdown
+# 功能名称 - 技术设计
+## 1. 架构概览
+## 2. 核心实现原则
+_Requirements: X.X_
+## 3. 组件设计
+## 4. 数据流
+## 5. 错误处理
+## 6. 测试策略
+```
+
+### 2.3 tasks.md（可选）
+
+**结构**:
+```markdown
+# 功能名称 - 实现任务
+## 阶段一: 诊断分析
+### 任务 1.1: 任务标题
+**Validates: Requirements X.X**
+- [ ] 子任务1
+- [ ] 子任务2
+```
+
+---
+
+## 🔄 三、Spec 创建工作流程
+
+### 阶段 1: Requirements
+1. 创建 requirements.md（使用 EARS 模式）
+2. 请求用户审核（`userInput` 工具）
+3. 等待批准 → 进入 Design 或直接执行
+
+### 阶段 2: Design（可选）
+1. 创建 design.md
+2. 请求用户审核
+3. 等待批准 → 进入 Tasks 或直接执行
+
+### 阶段 3: Tasks（可选）
+1. 创建 tasks.md
+2. 请求用户审核
+3. 等待批准 → Spec 创建完成
+
+---
+
+## ⚙️ 四、Spec 任务执行流程
+
+**核心原则**: 一次只执行一个任务
+
+**执行步骤**:
+1. 读取 requirements.md, design.md, tasks.md
+2. 更新任务状态为 `in_progress`
+3. 执行任务（遵循 design.md）
+4. 更新任务状态为 `completed`
+5. 停止并等待用户审核
+
+---
+
+## 🎯 五、核心设计原则
+
+1. **场景覆盖**: 覆盖原型系统的全部场景
+2. **风格一致性**: 与现有代码库保持风格一致
+3. **复杂性分解**: 大任务拆分为可独立验证的子任务
+4. **遗留清理**: 清理旧的临时代码和注释
+5. **实现整合**: 同一功能的实现整合在一处
+
+---
+
+## 🔗 六、双向追溯机制
+
+**正向追溯**（需求 → 设计 → 任务）:
+```markdown
+## 2. 核心实现原则
+_Requirements: 3.1, 3.2_
+```
+
+**反向追溯**（任务 → 需求）:
+```markdown
+### 任务 1.1: 实现进度条组件
+**Validates: Requirements 3.1**
+```
+
+---
+
+**版本**: v2.0  
+**更新**: 2026-01-27  
+**适用范围**: 所有使用 kiro-spec-engine (kse) 的 Spec 驱动开发项目

package/template/.kiro/steering/CORE_PRINCIPLES.md

@@ -0,0 +1,133 @@
+# 核心开发原则（基准规则）
+
+> **重要**: 这些是项目的基准规则，适用于所有 Spec，不应随意修改。场景特定规则参考 `CURRENT_CONTEXT.md`
+
+---
+
+## 📋 Spec 驱动开发
+
+**命名**: `{序号}-{序号}-{简短描述}` (kebab-case)，如 `01-00-user-authentication`
+
+**工作流**: 创建 Spec → requirements.md → design.md → tasks.md → 执行任务 → 产物归档
+
+**目录**: `.kiro/specs/{feature-name}/` 包含文档和产物（scripts/, reports/, diagnostics/, tests/, results/）
+
+---
+
+## ⚠️ 核心原则
+
+### 0. KSE 项目接管声明 🎯
+
+**核心**: 项目已由 kse 接管，AI 拥有完全开发和管理权限
+
+**接管标志**: 存在 `.kiro/` 目录、`version.json`、`specs/`、`steering/`
+
+**AI 权限**: 创建执行 Spec、修改代码、运行测试、访问网络、发布版本、更新文档、管理依赖
+
+**用户角色**: 提供需求、验收成果、处理致命错误、提供外部资源
+
+**目标**: AI 作为主要开发者，用户作为产品经理，共同高效推进项目
+
+### 1. Spec 驱动开发
+任何需求先建 Spec，产物归档到 Spec 目录，禁止脚本/测试放根目录
+
+### 2. 文件管理
+**根目录**: 禁止随意生成临时文件，用完立删
+
+**Steering 严格管控** ⚠️: 只放 4 个核心文件（CORE_PRINCIPLES, ENVIRONMENT, CURRENT_CONTEXT, RULES_GUIDE），其他归档到 `.kiro/specs/` 或 `docs/`
+
+### 3. 质量零容忍 ⚠️⚠️⚠️
+
+**千里之堤溃于蚁穴 - 绝不忽视任何问题**
+
+**代码质量**: 必须编译通过、运行相关测试、遵循编码规范
+
+**测试零容忍**: ❌ 禁止忽视失败、禁止失败时发布 | ✅ 必须调查根因、修复后继续、发布前全量测试
+
+**避免重复测试**: 任务中已测试则完成后不重复，Kiro 文件保存触发 subagent 时跳过重复测试
+
+**重要性**: 测试是质量防线，小问题累积致崩溃，忽视问题成本指数增长
+
+### 4. Ultrawork 精神 🔥
+
+**核心**: 像西西弗斯推石上山，永不放弃，直到任务完美完成
+
+**标准**: 专业级质量（生产级标准）、不懈努力（持续尝试不轻易求助）、完整交付（输出完整准确可用）
+
+**要求**: Requirements 考虑边界异常安全性能 | Design 架构优雅可扩展易维护 | Tasks 代码质量测试覆盖文档完整
+
+**困难处理**: 分析根因持续修复、重审需求不断迭代、换思路查资料持续突破、分解问题多维尝试，永不轻易转移责任
+
+### 4.1 完全自主执行权限 🚀
+
+**授权**: kse 接管项目后，AI 拥有完全自主执行权限
+
+**原则**: 无需确认直接推进、自主决策方案工具、自主修复不中断、自主测试分析修复、自主优化代码设计
+
+**策略**: 连续推进多任务、批量操作、智能跳过可选任务、错误自动尝试多方案
+
+**用户介入时机**: 致命错误、需外部资源、重大架构决策、Spec 完成验收
+
+**禁止**: 每任务询问、每修改确认、小问题求助、过度谨慎低效
+
+**目标**: 用户说"开始执行 Spec XX"，AI 自主完成所有任务交付功能
+
+### 5. 上下文管控
+
+**主动管控避免 token 耗尽**
+
+**时机**: 完成任务组精简详情、完成阶段更新 CURRENT_CONTEXT、Token>50% 立即精简、阶段切换聚焦新阶段
+
+**规则**: Spec 保留标题状态删详情、CURRENT_CONTEXT 只留核心、文档>1000 行拆分、历史归档
+
+### 6. Steering 更新
+
+完成 Spec 后评估更新：通用经验 → CORE_PRINCIPLES，当前场景 → CURRENT_CONTEXT
+
+### 7. 数据原子性原则
+
+**核心**: 每类数据有且仅有一个权威数据源（Single Source of Truth）
+
+**要求**: 避免数据源多重、保证更新原子、架构保证一致
+
+**后果**: 违反导致数据不一致、同步复杂、事务困难、维护成本高
+
+### 8. 文档同步更新原则
+
+**核心**: 重要功能代码变更必须同步更新文档
+
+**范围**: 项目功能更新 README、新命令更新用户文档、API 变更更新 API 文档、配置变更更新配置文档
+
+**时机**: 功能完成立即更新、Spec 完成前确保同步、发布前验证一致
+
+**后果**: 违反导致用户困惑、功能难发现、门槛高、维护成本增
+
+### 9. 版本同步和 Steering 刷新原则
+
+**核心**: 版本更新或首次安装后，必须阅读 `.kiro/README.md` 并刷新 Steering
+
+**时机**: 首次安装、版本更新、长时间未用、功能不一致时
+
+**步骤**: 读 README 了解新功能 → 检查 Steering 是否需更新 → 更新 CURRENT_CONTEXT → 验证一致性
+
+**重要性**: 新版本引入新功能命令工作流，Steering 可能过时导致 AI 行为不符最新实践
+
+**后果**: 违反导致使用过时工作流、忽略新功能、行为不一致、效率降低
+
+### 10. 开发测试环境完全授权原则 🔓
+
+**核心**: 开发测试环境下，AI 完全授权访问本地、局域网、互联网资源，无需询问
+
+**授权**: 本地系统、局域网资源、互联网资源、工具调用、资源创建
+
+**操作**: 读写项目文件、运行测试构建、访问网络资源、创建删除临时资源、调试诊断
+
+**安全边界**: ⚠️ 生产环境需确认、敏感数据谨慎处理、破坏性操作评估风险、外部影响需确认
+
+**禁止**: 每次网络请求询问、每次读文件确认、每次命令等批准、过度谨慎低效
+
+**目标**: AI 像人类开发者自由使用开发环境资源，专注解决问题而非权限申请
+
+---
+
+v14.0 | 2026-02-02 | 无损重构，精简 40% token

package/template/.kiro/steering/CURRENT_CONTEXT.md

@@ -0,0 +1,30 @@
+# 当前场景规则（模板）
+
+> ⚠️ **模板文件**: 请在开始第一个 Spec 前更新为实际项目信息
+
+## 🎯 当前状态
+
+**状态**: 🆕 待开始  
+**Spec**: 无  
+**项目**: [TODO: 项目名称]  
+**更新**: [TODO: 日期]
+
+## 📝 当前 Spec
+
+**当前无活跃 Spec**
+
+开始新 Spec 前更新：
+1. 设置 Spec 名称和目标
+2. 更新项目信息
+3. 记录当前阶段和进展
+4. 清理历史详细内容
+
+## 💡 管控原则
+
+**每完成 Spec**: 立即精简历史详情，只保留核心经验（1-2行）
+
+**Token>50%**: 立即精简本文档，删除已完成阶段详细配置
+
+---
+
+v3.2 | 2026-02-02 | 精简 50% token

package/template/.kiro/steering/ENVIRONMENT.md

@@ -0,0 +1,35 @@
+# 项目环境配置（模板）
+
+> ⚠️ **模板文件**: 请根据实际项目修改所有 `[TODO: ...]` 占位符
+
+## 📋 项目信息
+
+- **项目**: [TODO: 项目名称]
+- **类型**: [TODO: 项目类型 - Web应用/CLI工具/库]
+- **技术**: [TODO: 核心技术栈 - React + Node.js]
+- **语言**: [TODO: 主要开发语言 - TypeScript/Python]
+
+## 🖥️ 环境
+
+**本地**: Windows (cmd) | Python 3.8+ | Kiro IDE
+
+**核心组件**:
+- `.kiro/specs/` - Spec 驱动开发
+- `.kiro/steering/` - AI 行为规则
+- `.kiro/tools/` - Ultrawork 工具
+
+## 🔧 配置
+
+**Steering**: CORE_PRINCIPLES | ENVIRONMENT | CURRENT_CONTEXT | RULES_GUIDE
+
+**Spec**: requirements.md | design.md | tasks.md
+
+## 🔐 AI 权限
+
+**授权**: ✅ Spec 文档 | ✅ Steering 规则 | ✅ Ultrawork 工具 | ✅ Python 脚本
+
+**限制**: ❌ 修改 CORE_PRINCIPLES 需用户同意 | 新工具需先设计
+
+---
+
+v7.0 | 2026-02-02 | 精简 60% token

package/template/.kiro/steering/RULES_GUIDE.md

@@ -0,0 +1,46 @@
+# Steering 规则索引
+
+> **快速参考**: 各文件职责和快速链接
+
+---
+
+## 📚 文件列表
+
+| 文件 | 职责 | 更新频率 |
+|------|------|---------|
+| **CORE_PRINCIPLES.md** | 核心开发规范 | 很少 |
+| **ENVIRONMENT.md** | 环境配置 | 很少 |
+| **CURRENT_CONTEXT.md** | 当前 Spec 场景 | 每个 Spec ⚠️ |
+
+---
+
+## 🔗 快速链接
+
+- **当前场景**: `CURRENT_CONTEXT.md` - 当前正在推进的 Spec
+- **开发规范**: `CORE_PRINCIPLES.md` - 适用于所有 Spec 的规范
+- **环境配置**: `ENVIRONMENT.md` - 项目环境信息
+- **Spec 工作流**: `../ specs/SPEC_WORKFLOW_GUIDE.md` - Spec 创建和执行流程
+- **体系说明**: `../README.md` - 新项目引导文档
+
+---
+
+## ⚠️ 重要提示
+
+### CURRENT_CONTEXT.md 管控
+
+- **每个新 Spec 开始前**：更新为新 Spec 的场景
+- **Spec 推进中**：及时精简已完成内容
+- **Spec 完成后**：清空，准备下一个 Spec
+- **Token 消耗 > 50% 时**：立即精简
+
+### 精简策略
+
+- ❌ 删除：已完成阶段的详细配置、命令、表格
+- ❌ 删除：历史测试数据和详细流程
+- ✅ 保留：当前阶段的核心信息
+- ✅ 保留：关键经验教训（1-2 行）
+
+---
+
+**版本**: v2.0  
+**更新**: 2025-01-22

package/template/.kiro/templates/operations/default/change-impact.md

@@ -0,0 +1,112 @@
+# Change Impact Assessment
+
+## Change Classification
+
+**Change Level**: L1 / L2 / L3 / L4 / L5
+
+- L1 (Code): Pure code changes, no external impact
+- L2 (Config): Configuration changes, may affect behavior
+- L3 (API): API contract changes, affects consumers
+- L4 (Data Structure): Database schema changes, requires migration
+- L5 (Architecture): Architectural changes, affects multiple systems
+
+**Justification**: Why this classification was chosen
+
+## Affected Systems
+
+### System 1: [System Name]
+
+**Impact type**: Direct / Indirect
+
+**Impact description**: How this system is affected
+
+**Criticality**: Critical / High / Medium / Low
+
+**Mitigation**: How to minimize impact
+
+### System 2: [System Name]
+
+**Impact type**: Direct / Indirect
+
+**Impact description**: How this system is affected
+
+**Criticality**: Critical / High / Medium / Low
+
+**Mitigation**: How to minimize impact
+
+## Risk Assessment
+
+### Risk 1: [Risk Name]
+
+**Probability**: High / Medium / Low
+
+**Impact**: High / Medium / Low
+
+**Description**: Detailed description of risk
+
+**Mitigation strategy**:
+1. Strategy 1
+2. Strategy 2
+3. Strategy 3
+
+**Contingency plan**: What to do if risk materializes
+
+### Risk 2: [Risk Name]
+
+**Probability**: High / Medium / Low
+
+**Impact**: High / Medium / Low
+
+**Description**: Detailed description of risk
+
+**Mitigation strategy**:
+1. Strategy 1
+2. Strategy 2
+3. Strategy 3
+
+**Contingency plan**: What to do if risk materializes
+
+## Deployment Impact
+
+**Downtime required**: Yes / No
+
+**Downtime duration**: If yes, how long
+
+**Maintenance window**: When to deploy
+
+**User impact**: How users are affected
+
+**Communication plan**:
+- Who to notify
+- When to notify
+- What to communicate
+
+**Rollback plan**: Reference to rollback.md
+
+## Post-Deployment Tracking
+
+**Metrics to monitor**:
+- Metric 1
+- Metric 2
+- Metric 3
+
+**Success criteria**:
+- [ ] Criterion 1
+- [ ] Criterion 2
+- [ ] Criterion 3
+
+**Review period**: How long to monitor
+
+**Actual vs Predicted Impact**:
+
+| Aspect | Predicted | Actual | Notes |
+|--------|-----------|--------|-------|
+| Downtime | | | |
+| User impact | | | |
+| Performance | | | |
+| Issues | | | |
+
+**Lessons learned**:
+- Lesson 1
+- Lesson 2
+- Lesson 3

package/template/.kiro/templates/operations/default/deployment.md

@@ -0,0 +1,91 @@
+# Deployment Specification
+
+## Prerequisites
+
+List all prerequisites that must be met before deployment:
+
+- [ ] Prerequisite 1
+- [ ] Prerequisite 2
+- [ ] Prerequisite 3
+
+## Deployment Steps
+
+### Step 1: [Step Name]
+
+Description of the step and what it accomplishes.
+
+```bash
+# Commands to execute
+```
+
+**Expected outcome**: What should happen after this step
+
+**Rollback**: How to undo this step if needed
+
+### Step 2: [Step Name]
+
+Description of the step and what it accomplishes.
+
+```bash
+# Commands to execute
+```
+
+**Expected outcome**: What should happen after this step
+
+**Rollback**: How to undo this step if needed
+
+## Environment Variables
+
+| Variable | Description | Required | Default | Example |
+|----------|-------------|----------|---------|---------|
+| VAR_NAME | Description | Yes/No | value | example |
+
+## Health Checks
+
+### Check 1: [Check Name]
+
+**Purpose**: What this check validates
+
+**Command**:
+```bash
+# Health check command
+```
+
+**Expected result**: What indicates success
+
+**Failure action**: What to do if check fails
+
+### Check 2: [Check Name]
+
+**Purpose**: What this check validates
+
+**Command**:
+```bash
+# Health check command
+```
+
+**Expected result**: What indicates success
+
+**Failure action**: What to do if check fails
+
+## Rollback Procedure
+
+### When to Rollback
+
+- Condition 1
+- Condition 2
+- Condition 3
+
+### Rollback Steps
+
+1. Step 1
+2. Step 2
+3. Step 3
+
+### Verification
+
+How to verify rollback was successful:
+
+- [ ] Verification 1
+- [ ] Verification 2
+- [ ] Verification 3