scene-capability-engine 3.6.36 → 3.6.38

package/template/.sce/steering/CORE_PRINCIPLES.md

@@ -1,225 +1,35 @@
 # 核心开发原则（基准规则）
 
-> **重要**: 这些是项目的基准规则，适用于所有 Spec，不应随意修改。场景特定规则参考 `CURRENT_CONTEXT.md`
+> 模板只保留长期原则。当前阶段状态写入 `CURRENT_CONTEXT.md`，详细规则写入项目文档。
 
----
+## 1. 先建 Spec，再动实现
 
-## 📋 Spec 驱动开发
+- 所有需求先进入 `.sce/specs/<spec>/`，再进入设计、任务、实现与验证。
+- 产物归档到对应 Spec，避免散落根目录。
 
-**命名**: `{序号}-{序号}-{简短描述}` (kebab-case)，如 `01-00-user-authentication`
+## 2. Steering 只保留长期有效内容
 
-**工作流**: 创建 Spec → requirements.md → design.md → tasks.md → 执行任务 → 产物归档
+- `CORE_PRINCIPLES.md` 放长期原则。
+- `ENVIRONMENT.md` 放项目级运行与发布规则。
+- `CURRENT_CONTEXT.md` 放当前阶段最小上下文。
+- `RULES_GUIDE.md` 放职责边界与迁移规则。
 
-**目录**: `.sce/specs/{feature-name}/` 包含文档和产物（scripts/, reports/, diagnostics/, tests/, results/）
+## 3. 默认自主闭环推进
 
----
+- 默认流程：分析 -> 修改 -> 测试 -> 修复 -> 文档同步 -> 交付。
+- 非阻断问题不应频繁等待确认。
 
-## ⚠️ 核心原则
+## 4. 复用已有机制，不要平行造轮子
 
-### 0. KSE 项目接管声明 🎯
+- 已有能力优先复用，例如缺陷经验与发布阻断统一走 `errorbook`。
+- 不要在 steering 中额外定义另一套错题、发布、会话或治理模式。
 
-**核心**: 项目已由 sce 接管，AI 拥有完全开发和管理权限
+## 5. 质量问题必须追根
 
-**接管标志**: 存在 `.sce/` 目录、`version.json`、`specs/`、`steering/`
+- 禁止靠跳过测试、关闭校验、吞错回退来伪装成功。
+- 临时兜底必须附带退出条件、清理任务与截止时间。
 
-**AI 权限**: 创建执行 Spec、修改代码、运行测试、访问网络、发布版本、更新文档、管理依赖
+## 6. 定期净化 steering
 
-**用户角色**: 提供需求、验收成果、处理致命错误、提供外部资源
-
-**目标**: AI 作为主要开发者，用户作为产品经理，共同高效推进项目
-
-### 1. Spec 驱动开发
-任何需求先建 Spec，产物归档到 Spec 目录，禁止脚本/测试放根目录
-
-### 2. 文件管理
-**根目录**: 禁止随意生成临时文件，用完立删
-
-**Steering 严格管控** ⚠️: 只放 4 个核心文件（CORE_PRINCIPLES, ENVIRONMENT, CURRENT_CONTEXT, RULES_GUIDE），其他归档到 `.sce/specs/` 或 `docs/`
-
-### 3. 质量零容忍 ⚠️⚠️⚠️
-
-**千里之堤溃于蚁穴 - 绝不忽视任何问题**
-
-**代码质量**: 必须编译通过、运行相关测试、遵循编码规范
-
-**测试零容忍**: ❌ 禁止忽视失败、禁止失败时发布 | ✅ 必须调查根因、修复后继续、发布前全量测试
-
-**避免重复测试**: 任务中已测试则完成后不重复，SCE 文件保存触发 subagent 时跳过重复测试
-
-**重要性**: 测试是质量防线，小问题累积致崩溃，忽视问题成本指数增长
-
-### 4. Ultrawork 精神 🔥
-
-**核心**: 像西西弗斯推石上山，永不放弃，直到任务完美完成
-
-**标准**: 专业级质量（生产级标准）、不懈努力（持续尝试不轻易求助）、完整交付（输出完整准确可用）
-
-**要求**: Requirements 考虑边界异常安全性能 | Design 架构优雅可扩展易维护 | Tasks 代码质量测试覆盖文档完整
-
-**困难处理**: 分析根因持续修复、重审需求不断迭代、换思路查资料持续突破、分解问题多维尝试，永不轻易转移责任
-
-### 4.1 完全自主执行权限 🚀
-
-**授权**: sce 接管项目后，AI 拥有完全自主执行权限
-
-**原则**: 无需确认直接推进、自主决策方案工具、自主修复不中断、自主测试分析修复、自主优化代码设计
-
-**策略**: 连续推进多任务、批量操作、智能跳过可选任务、错误自动尝试多方案
-
-**用户介入时机**: 致命错误、需外部资源、重大架构决策、Spec 完成验收
-
-**禁止**: 每任务询问、每修改确认、小问题求助、过度谨慎低效
-
-**目标**: 用户说"开始执行 Spec XX"，AI 自主完成所有任务交付功能
-
-### 4.2 强制默认自主推进（无二次确认）⚡
-
-**核心**: 默认执行策略必须是“自主闭环推进”，不是“每步等待确认”
-
-**默认行为**:
-1) 接到任务后直接进入：分析 → 修改 → 测试 → 修复 → 提交 → 推送（若已配置远端）  
-2) 非阻断性问题（可自行定位/修复）不得暂停等待用户二次确认  
-3) 仅在以下情况允许中断并请求用户介入：外部权限缺失、不可恢复致命错误、生产高风险变更、业务目标冲突
-
-**强制要求**: 不得以“先等你确认再继续”替代执行；未形成可验证结果前不得提前结束
-
-### 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 完成前确保同步、发布前验证一致
-
-**后果**: 违反导致用户困惑、功能难发现、门槛高、维护成本增
-
-### 8.1 Git 托管强制门禁原则 🔐
-
-**核心**: 新增或修改代码必须进入 Git 托管管理链路，禁止“本地改完未推送”进入发布流程
-
-**默认强制**: 若仓库配置了 GitHub/GitLab 远端，发布前必须满足：
-1) 工作区干净（无未提交变更）  
-2) 当前分支已配置 upstream  
-3) 与 upstream 完全同步（ahead=0, behind=0）
-
-**豁免条件**: 仅当客户环境确实没有 GitHub/GitLab 托管时允许放行（策略控制），并需在交付记录中声明原因
-
-**落地门禁**: `scripts/git-managed-gate.js`（`prepublishOnly` 与 release preflight 默认执行）
-
-### 9. 版本同步和 Steering 刷新原则
-
-**核心**: 版本更新或首次安装后，必须阅读 `.sce/README.md` 并刷新 Steering
-
-**时机**: 首次安装、版本更新、长时间未用、功能不一致时
-
-**步骤**: 读 README 了解新功能 → 检查 Steering 是否需更新 → 更新 CURRENT_CONTEXT → 验证一致性
-
-**重要性**: 新版本引入新功能命令工作流，Steering 可能过时导致 AI 行为不符最新实践
-
-**后果**: 违反导致使用过时工作流、忽略新功能、行为不一致、效率降低
-
-### 10. 开发测试环境完全授权原则 🔓
-
-**核心**: 开发测试环境下，AI 完全授权访问本地、局域网、互联网资源，无需询问
-
-**授权**: 本地系统、局域网资源、互联网资源、工具调用、资源创建
-
-**操作**: 读写项目文件、运行测试构建、访问网络资源、创建删除临时资源、调试诊断
-
-**安全边界**: ⚠️ 生产环境需确认、敏感数据谨慎处理、破坏性操作评估风险、外部影响需确认
-
-**禁止**: 每次网络请求询问、每次读文件确认、每次命令等批准、过度谨慎低效
-
-**目标**: AI 像人类开发者自由使用开发环境资源，专注解决问题而非权限申请
-
-### 11. 缺陷修复优先根因原则 🛠️
-
-**核心**: 定位问题时，第一要务是修复根因，不是绕过问题
-
-**硬规则**: ❌ 禁止通过关闭校验、跳过测试、降级关键路径、屏蔽异常等方式“假修复”
-
-**失败显式原则**: 核心路径禁止吞错继续。无法确认安全修复时，必须 `fail-fast + 明确告警`，不得用静默回退伪装成功
-
-**兜底治理原则**: 允许临时兜底仅用于止血，不得替代根因修复；临时兜底必须结构化记录：
-1) 退出条件（exit criteria）  
-2) 清理任务（cleanup task/spec）  
-3) 截止时间（deadline）
-
-**发布门禁**: 若存在临时兜底但缺少上述治理信息，或已超过截止时间未清理，默认阻断发布（`errorbook release-gate`）
-
-**复杂问题定位方法**: 优先使用 debug 日志与可观测信号定位（输入、输出、关键分支、异常栈、上下文参数），先还原执行路径再下结论
-
-**两轮失败强制调试规则**: 同一问题连续 2 轮修复仍未达到目标验证（测试/门禁/验收）时，必须切换到 debug 定位模式；先补充结构化 debug 日志与关键观测点，复现并固化失败证据，再进入第 3 轮修复。❌ 禁止在未接入调试证据前继续盲改
-
-**修复后清理要求**: 问题修复并验证通过后，必须清理临时 debug 日志、临时埋点、一次性脚本和调试开关；需要长期保留的日志必须转为可配置观测项且默认关闭
-
-**允许的临时措施**: 仅在生产止血场景可临时绕行，但必须同时给出根因修复任务、回滚条件和截止时间
-
-**验收标准**: 必须有可复现用例、修复后回归通过、明确根因记录（不是仅现象描述）
-
-### 12. Ontology 四层一链分析原则 🧭
-
-**核心**: 梳理项目必须按统一语义框架推进，避免只看页面或只看接口
-
-**标准口径（修正）**:
-1) 实体模型（Entity）
-2) 关系图谱（Relation）
-3) 业务规则（Business Rule）
-4) 决策逻辑（Decision）
-5) 执行链路（Action/Lineage，体现“决策如何被执行与影响到哪里”）
-
-**要求**: 需求分析、问题定位、模板沉淀、发布门禁均按该口径检查完整性与一致性
-
-### 13. Scene 主会话强制治理原则 🎛️
-
-**核心**: SCE 默认并强制采用 `1 Scene = 1 主会话`，会话生命周期由 Scene 驱动而不是由单个 Agent 的原生 session 决定
-
-**硬规则**:
-1) `studio plan` 必须提供 `--scene`，并绑定 Scene 主会话  
-2) 同一 Scene 同时只允许一个活动主会话  
-3) `Spec` 必须作为该 Scene 主会话下的子会话管理（创建、归档、摘要回写）  
-4) Scene 完成（如 release 成功）后，当前主会话自动归档，并自动开启下一周期主会话
-
-**目标**: 保证跨 Agent 连续性、可追溯历史、上下文可控，避免因 Agent session 长短差异导致上下文漂移
-
-### 14. 问题域思维导图 + 场景化 Spec 强制原则 🧠
-
-**核心**: Spec 推进必须先完成“问题域思维导图”与“场景化 Spec 契约”，再进入实现与修复闭环
-
-**硬规则**:
-1) 每个 Spec 必须具备：
-   - `.sce/specs/<spec>/custom/problem-domain-map.md`
-   - `.sce/specs/<spec>/custom/scene-spec.md`
-   - `.sce/specs/<spec>/custom/problem-domain-chain.json`
-   - `.sce/specs/<spec>/custom/problem-contract.json`
-2) `problem-domain-map` 必须包含：Root Problem、Mind Map、Layered Exploration Chain、Correction Loop
-3) `scene-spec` 必须包含：Scene Definition、Ontology Coverage、Decision & Execution Path、Acceptance & Gate
-4) `problem-domain-chain.json` 必须包含可机读思维链：problem/ontology/hypotheses/risks/decision_execution_path/correction_loop/verification/problem_contract/ontology_evidence
-5) `problem-contract.json` 必须包含：issue_statement、expected_outcome、reproduction_steps、impact_scope、forbidden_workarounds
-6) 默认门禁强制校验上述结构，缺失即 `no-go`（`problem-closure-gate` 在 verify/release 默认启用）
-
-**目标**: 用全局问题域视角 + 场景契约约束，减少方向性错误与盲改，提升纠偏效率
-
----
-
-v21.0 | 2026-03-01 | 强化“强制默认自主推进（无二次确认）”执行基线
+- 每周、发布前、重大 Spec 收尾后运行 `npm run audit:steering`。
+- 发现问题时优先合并重复、迁移错层、归档历史、删除失效条目。

package/template/.sce/steering/CURRENT_CONTEXT.md

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

package/template/.sce/steering/ENVIRONMENT.md

@@ -1,35 +1,21 @@
 # 项目环境配置（模板）
 
-> ⚠️ **模板文件**: 请根据实际项目修改所有 `[TODO: ...]` 占位符
-
-## 📋 项目信息
-
 - **项目**: [TODO: 项目名称]
-- **类型**: [TODO: 项目类型 - Web应用/CLI工具/库]
-- **技术**: [TODO: 核心技术栈 - React + Node.js]
-- **语言**: [TODO: 主要开发语言 - TypeScript/Python]
-
-## 🖥️ 环境
-
-**本地**: Windows (cmd) | Python 3.8+ | AI IDE
-
-**核心组件**:
-- `.sce/specs/` - Spec 驱动开发
-- `.sce/steering/` - AI 行为规则
-- `.sce/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
+- **类型**: [TODO: 项目类型]
+- **技术栈**: [TODO: 核心技术栈]
+- **环境**: [TODO: 本地系统 / Shell / Node / Python / IDE]
+- **仓库**: [TODO: Git 仓库地址]
+
+**核心目录**:
+- `.sce/specs/`
+- `.sce/steering/`
+- `.sce/tools/`
+
+**发布规则**:
+- [TODO: 是否使用 GitHub Actions / 其他 CI]
+- [TODO: 发版是否由 tag 触发]
+- [TODO: 发布前必须通过哪些门禁]
+
+**steering 治理**:
+- 详细规范放项目文档，不要堆在 steering 本身
+- 周期性运行 `npm run audit:steering`

package/template/.sce/steering/RULES_GUIDE.md

@@ -1,46 +1,18 @@
 # 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
+**职责边界**:
+- `CORE_PRINCIPLES.md`：长期原则
+- `ENVIRONMENT.md`：项目级规则
+- `CURRENT_CONTEXT.md`：当前阶段上下文
+- `RULES_GUIDE.md`：迁移与维护规则
+
+**迁移原则**:
+- 长期有效 -> `CORE_PRINCIPLES.md`
+- 项目运行约束 -> `ENVIRONMENT.md`
+- 当前阶段状态 -> `CURRENT_CONTEXT.md`
+- 详细制度与示例 -> 项目文档
+- 任务、证据、历史 -> 对应 Spec
+
+**治理动作**:
+- 定期运行 `npm run audit:steering`
+- 审计失败时，优先合并重复、迁移错层、归档历史、删除失效内容

package/template/.sce/steering/manifest.yaml

@@ -0,0 +1,50 @@
+schema_version: '1.0'
+engine: sce
+profile: default
+description: SCE steering template contract
+layers:
+  core_principles: CORE_PRINCIPLES.md
+  environment: ENVIRONMENT.md
+  current_context: CURRENT_CONTEXT.md
+  rules_guide: RULES_GUIDE.md
+governance:
+  review_cadence: weekly
+  stable_layers:
+    - CORE_PRINCIPLES.md
+    - ENVIRONMENT.md
+    - RULES_GUIDE.md
+  files:
+    CORE_PRINCIPLES.md:
+      max_lines: 96
+      max_headings: 16
+      max_history_entries: 0
+      allow_spec_refs: false
+      allow_version_markers: false
+      allow_checklists: false
+    ENVIRONMENT.md:
+      max_lines: 36
+      max_headings: 8
+      max_history_entries: 0
+      allow_spec_refs: false
+      allow_version_markers: false
+      allow_checklists: false
+    CURRENT_CONTEXT.md:
+      max_lines: 24
+      max_headings: 6
+      max_history_entries: 3
+      allow_spec_refs: true
+      allow_version_markers: true
+      allow_checklists: false
+    RULES_GUIDE.md:
+      max_lines: 36
+      max_headings: 8
+      max_history_entries: 0
+      allow_spec_refs: false
+      allow_version_markers: false
+      allow_checklists: false
+  canonical_terms:
+    errorbook:
+      aliases:
+        - 错题
+        - 错题本
+      guidance: Reuse the existing errorbook capability instead of inventing a parallel mistake-book mode in steering.

package/bin/kse.js

@@ -1,3 +0,0 @@
-#!/usr/bin/env node
-
-require('./scene-capability-engine');