scene-capability-engine 3.6.37 → 3.6.38

package/CHANGELOG.md

@@ -7,6 +7,18 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [3.6.38] - 2026-03-12
+
+### Added
+- Added `scripts/steering-content-audit.js` to audit steering content budgets, stale history, checklist leakage, stable-layer spec leakage, and non-canonical governance aliases.
+- Added weekly scheduled workflow `.github/workflows/steering-hygiene.yml` and project guidance in `docs/steering-governance.md` for recurring steering review and cleanup.
+- Added Spec `119-00-steering-self-governance` to document the steering self-governance model, audit scope, and CI rollout.
+
+### Changed
+- Refactored `.sce/steering/` and `template/.sce/steering/` so baseline steering content stays lean, layered, and free of long history or task-state drift.
+- Extended steering manifest governance metadata with file budgets, relocation targets, review cadence, and canonical mechanism rules.
+- Wired `npm run audit:steering` into CI and `prepublishOnly`, making steering hygiene part of normal validation and release flow.
+
 ## [3.6.37] - 2026-03-12
 
 ### Added

package/docs/releases/README.md

@@ -9,6 +9,7 @@ This directory stores release-facing documents:
 ## Archived Versions
 
 - [Release checklist](../release-checklist.md)
+- [v3.6.38 release notes](./v3.6.38.md)
 - [v3.6.37 release notes](./v3.6.37.md)
 - [v1.46.2 release notes](./v1.46.2.md) (historical)
 - [v1.46.2 validation report](./v1.46.2-validation.md) (historical)

package/docs/releases/v3.6.38.md

@@ -0,0 +1,19 @@
+# v3.6.38 Release Notes
+
+Release date: 2026-03-12
+
+## Highlights
+
+- Added a steering self-governance audit that checks content budgets, stale history, checklist leakage, stable-layer Spec leakage, and non-canonical governance aliases.
+- Refactored the live steering baseline and template steering files so they stay lean, layered, and easier to refresh over time.
+- Added recurring steering hygiene enforcement in normal CI, `prepublishOnly`, and a weekly GitHub Actions schedule.
+
+## Verification
+
+- `npm run audit:steering`
+- `npx jest tests/unit/steering/steering-compliance-checker.test.js tests/unit/scripts/steering-content-audit.test.js tests/unit/scripts/git-managed-gate.test.js --runInBand`
+
+## Release Notes
+
+- Steering is now expected to self-correct through recurring audit rather than rely on ad hoc cleanup.
+- Stable steering layers should remain short-lived in content size but long-lived in principle quality.

package/docs/steering-governance.md

@@ -0,0 +1,112 @@
+# Steering 治理与净化
+
+## 目标
+
+让 `.sce/steering/` 长期保持三种品质：
+
+- 健壮：长期规则稳定，不被短期任务污染
+- 活力：随着项目演进持续校正，不靠历史惯性堆积
+- 节制：只保留最小必要上下文，其他内容迁回更合适的位置
+
+## 分层标准
+
+| 位置 | 应放什么 | 不应放什么 |
+|------|---------|-----------|
+| `.sce/steering/CORE_PRINCIPLES.md` | 长期原则、跨 Spec 仍成立的默认行为 | 任务项、历史版本、阶段流水、短期战术 |
+| `.sce/steering/ENVIRONMENT.md` | 项目环境、目录约定、发布触发方式、长期运行约束 | Spec 进度、问题清单、临时 workaround |
+| `.sce/steering/CURRENT_CONTEXT.md` | 当前阶段最小必要上下文、近期优先级 | 长历史、完整日志、旧阶段总结 |
+| `.sce/steering/RULES_GUIDE.md` | 职责边界、迁移规则、审计入口 | 详细制度、示例、长篇解释 |
+| `.sce/specs/<spec>/` | 任务、证据、诊断、阶段记录、报告 | 不应再回写到 steering 的长历史 |
+| `docs/` | 详细制度、示例、方法论、治理说明 | 当前 session 的即时状态 |
+
+## 审查周期
+
+- 每周一次
+- 每次发布前一次
+- 每次重大 Spec 收尾后一次
+- 接管老项目或大规模文档迁移后，再补一次
+
+## 审查动作
+
+每次审查只做四类决定：
+
+1. 保留
+   条件：内容长期有效，且放在当前层是正确的
+2. 合并
+   条件：多条规则表达同一个约束，只是换了说法
+3. 迁移
+   条件：内容有效，但层级错了
+4. 删除
+   条件：短期价值已结束、已有现成机制承接、或已经被文档/系统能力覆盖
+
+## 防腐重点
+
+### 1. 不允许平行机制
+
+steering 不能因为“想提醒 AI”就再造一套并行机制。
+
+典型案例：
+
+- 缺陷经验、临时兜底、发布阻断：统一复用 `errorbook`
+- Scene / session 生命周期：复用现有 close-loop / scene 运行时
+- release gate：复用现有 release workflow 与 gate 脚本
+
+如果某条 steering 规则本质上是在说“再搞一套模式”，应先问两件事：
+
+1. 现有 SCE 是否已经有能力承接？
+2. 这条内容应该写成机制引用，而不是重新定义机制吗？
+
+### 2. 不允许长历史驻留
+
+历史记录、阶段流水、版本脚注、完成纪要不应长期留在 steering。
+
+迁移目标：
+
+- 当前阶段以外的推进历史 -> 对应 Spec `custom/` 或 `reports/`
+- 发布历史 -> `CHANGELOG.md` / `docs/releases/`
+- 详细治理说明 -> `docs/steering-governance.md`
+
+### 3. 不允许任务态混入
+
+steering 不是待办清单。
+
+以下内容应迁出：
+
+- checklist
+- “下一个动作”
+- 具体执行命令流水
+- 某个 Spec 的进行中任务状态
+
+### 4. 不允许错层
+
+判断标准很简单：
+
+- 跨项目、跨阶段仍成立？放 `CORE_PRINCIPLES.md`
+- 仅对当前项目成立？放 `ENVIRONMENT.md`
+- 仅对当前阶段成立？放 `CURRENT_CONTEXT.md`
+- 需要示例和长解释？放 `docs/`
+
+## 审计入口
+
+本项目提供自动审计：
+
+```bash
+npm run audit:steering
+```
+
+当前会检查：
+
+- 文件预算是否超线
+- 长期层是否混入历史版本脚注
+- 长期层是否混入 Spec 引用
+- steering 中是否混入 checklist / 任务态
+- `CURRENT_CONTEXT.md` 是否与当前包版本脱节
+- 是否出现“错题 / 错题本”这类非规范机制别名
+
+## 通过标准
+
+- `CORE_PRINCIPLES.md` 能在短时间读完并说明默认行为
+- `CURRENT_CONTEXT.md` 不依赖长历史也能让 Agent 开工
+- steering 中不再出现任务态和阶段流水
+- 已有机制统一复用，不再出现平行命名
+- 周期性审计可稳定通过

package/docs/zh/releases/README.md

@@ -9,6 +9,7 @@
 ## 历史版本归档
 
 - [发布检查清单](../release-checklist.md)
+- [v3.6.38 发布说明](./v3.6.38.md)
 - [v3.6.37 发布说明](./v3.6.37.md)
 - [v1.46.2 发布说明](./v1.46.2.md)（历史归档）
 - [v1.46.2 验证报告](./v1.46.2-validation.md)（历史归档）

package/docs/zh/releases/v3.6.38.md

@@ -0,0 +1,19 @@
+# v3.6.38 发布说明
+
+发布日期：2026-03-12
+
+## 重点变化
+
+- 新增 steering 自治理审计，检查内容预算、历史堆积、checklist 泄漏、稳定层 Spec 泄漏，以及非规范治理别名。
+- 重构了当前 steering 基线和模板 steering，使其长期保持精简、分层明确、便于刷新。
+- 将 steering 卫生检查接入常规 CI、`prepublishOnly` 和每周 GitHub Actions 定时任务。
+
+## 验证
+
+- `npm run audit:steering`
+- `npx jest tests/unit/steering/steering-compliance-checker.test.js tests/unit/scripts/steering-content-audit.test.js tests/unit/scripts/git-managed-gate.test.js --runInBand`
+
+## 发布说明
+
+- steering 现在通过周期审计持续自我净化，而不是靠人工想起来时再清理。
+- 稳定层应保持“原则长期有效、内容尽量精简”的状态，避免再回到大而杂的历史堆积。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "scene-capability-engine",
-  "version": "3.6.37",
+  "version": "3.6.38",
   "description": "SCE (Scene Capability Engine) - A CLI tool and npm package for spec-driven development with AI coding assistants.",
   "main": "index.js",
   "bin": {
@@ -38,6 +38,8 @@
     "test:skip-audit": "node scripts/check-skip-allowlist.js",
     "test:sce-tracking": "node scripts/check-sce-tracking.js",
     "test:brand-consistency": "node scripts/check-branding-consistency.js",
+    "audit:steering": "node scripts/steering-content-audit.js --fail-on-error",
+    "report:steering-audit": "node scripts/steering-content-audit.js --json",
     "test:watch": "npx jest --watch",
     "coverage": "npx jest --coverage",
     "report:moqui-metadata": "node scripts/moqui-metadata-extract.js --json",
@@ -76,7 +78,7 @@
     "gate:release-asset-integrity": "node scripts/release-asset-integrity-check.js",
     "report:release-risk-remediation": "node scripts/release-risk-remediation-bundle.js --json",
     "report:moqui-core-regression": "node scripts/moqui-core-regression-suite.js --json",
-    "prepublishOnly": "npm run test:release && npm run test:skip-audit && npm run test:sce-tracking && npm run test:brand-consistency && npm run gate:git-managed && npm run gate:errorbook-registry-health && npm run gate:errorbook-release && npm run report:interactive-governance -- --fail-on-alert",
+    "prepublishOnly": "npm run test:release && npm run test:skip-audit && npm run test:sce-tracking && npm run test:brand-consistency && npm run audit:steering && npm run gate:git-managed && npm run gate:errorbook-registry-health && npm run gate:errorbook-release && npm run report:interactive-governance -- --fail-on-alert",
     "publish:manual": "npm publish --access public",
     "install-global": "npm install -g .",
     "uninstall-global": "npm uninstall -g scene-capability-engine"

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. SCE 项目接管声明 🎯
+- 已有能力优先复用，例如缺陷经验与发布阻断统一走 `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.