scene-capability-engine 3.6.37 → 3.6.39

package/CHANGELOG.md

@@ -7,6 +7,36 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [3.6.39] - 2026-03-13
+
+### Added
+- Added state storage tiering policy artifacts and guidance in `docs/state-storage-tiering.md`, `docs/state-migration-reconciliation-runbook.md`, `.sce/config/state-storage-policy.json`, and `template/.sce/config/state-storage-policy.json`.
+- Added append-only evidence projection and audit tooling via `scripts/interactive-approval-event-projection.js`, `scripts/state-storage-tiering-audit.js`, and the `audit:state-storage` / `report:state-storage` package scripts.
+- Added scene command coverage and helper fixtures for the expanded `scene` subcommand surface, including publish/install/info/diff/validate/owner/tag/stats/lock/contribute/version and related property tests.
+- Added release-facing closeout evidence for the scene command specs and the quality hardening master spec under `.sce/specs/*/custom/`.
+
+### Changed
+- Expanded `lib/commands/scene.js` to cover the newer scene command flows and stabilized JSON summary output so CLI JSON mode preserves edge-case numeric payloads such as `-0`.
+- Hardened state migration and storage behavior in `lib/state/sce-state-store.js`, `lib/state/state-migration-manager.js`, `lib/runtime/session-store.js`, and related governance/config plumbing while keeping file sources canonical.
+- Completed the `115-00-sce-quality-hardening-program` integration closeout, including `watch logs --follow` completion, open-handle governance follow-through, and master/sub-spec status convergence.
+- Updated `docs/command-reference.md`, `docs/document-governance.md`, and multiple Spec task ledgers to reflect the shipped command surface and governance posture.
+
+### Fixed
+- Removed the remaining `forceExit` dependency from the validated Jest path and confirmed `npm run test:handles` passes without open-handle leakage.
+- Stabilized watch/integration helper timing and watcher cleanup paths so `test:smoke`, `test:full`, and `test:handles` can run cleanly in sequence.
+
+## [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/command-reference.md

@@ -876,6 +876,29 @@ Runtime read preference:
 - `sce state doctor --json` now includes:
   - `summary` aggregate (`pending_components`, `total_record_drift`, `blocking_count`, `alert_count`)
   - runtime read diagnostics (`runtime.timeline`, `runtime.scene_session`) with read-source/read-preference and consistency status
+  - hardened severity model:
+    - `blocking`: `sqlite-unavailable`, `source-parse-error`, `sqlite-ahead`, `sqlite-only`
+    - `alert`: `pending-migration`, `missing-source`, runtime `pending-sync`
+  - current release guidance:
+    - treat `sqlite-ahead` and `sqlite-only` as anomalies requiring repair before release
+    - treat `pending-migration` as repairable drift, not a steady-state
+    - only allow `missing-source` to persist when the component is intentionally out of scope for the project
+
+State storage tiering policy:
+- Policy file: `.sce/config/state-storage-policy.json`
+- Audit command: `npm run audit:state-storage`
+- Machine-readable report: `npm run report:state-storage`
+- Tier meanings:
+  - `file-source`: canonical evidence, audit, recovery payloads, and low-cardinality personal state
+  - `sqlite-index`: query-oriented registry/index layer with files still canonical
+  - `derived-sqlite-projection`: rebuildable SQLite projection for append-only stream queries
+- Explicit non-candidates for SQLite source replacement:
+  - `~/.sce/workspace-state.json`
+  - `.sce/reports/**/*.jsonl`
+  - `.sce/audit/**/*.jsonl`
+- Supporting docs:
+  - `docs/state-storage-tiering.md`
+  - `docs/state-migration-reconciliation-runbook.md`
 
 Write lease model (optional, policy-driven, SQLite-backed):
 - Policy file: `.sce/config/authorization-policy.json`
@@ -1836,6 +1859,10 @@ Interactive approval workflow helper (script-level stage-B approval state machin
 - `node scripts/interactive-approval-workflow.js --action <init|submit|approve|reject|execute|verify|archive|status> [--plan <path>] [--state-file <path>] [--audit-file <path>] [--actor <id>] [--actor-role <name>] [--role-policy <path>] [--comment <text>] [--password <text>] [--password-hash <sha256>] [--password-hash-env <name>] [--password-required] [--password-scope <csv>] [--json]`: maintain approval lifecycle state for interactive change plans and append approval events to JSONL audit logs.
   - Default state file: `.sce/reports/interactive-approval-state.json`
   - Default audit file: `.sce/reports/interactive-approval-events.jsonl`
+- `node scripts/interactive-approval-event-projection.js --action <rebuild|doctor|query> [--input <path>] [--read-source <auto|file|projection>] [--workflow-id <id>] [--actor <id>] [--approval-action <name>] [--event-type <type>] [--blocked|--not-blocked] [--limit <n>] [--fail-on-drift] [--fail-on-parse-error] [--json]`: build and inspect a rebuildable SQLite projection for `interactive-approval-events.jsonl` while keeping raw JSONL as canonical evidence.
+  - `rebuild` clears and rebuilds the projection for the target audit file
+  - `doctor` compares raw file count vs projection count and flags `projection-missing`, `pending-projection`, `projection-ahead`, or parse errors
+  - `query` discloses `read_source=file|projection`
   - `init` requires `--plan`; high-risk plans are marked as `approval_required=true`.
   - Password authorization can be required per plan (`plan.authorization.password_required=true`) or overridden in `init`.
   - `execute` is blocked (exit code `2`) when approval is required but current status is not `approved`.

package/docs/document-governance.md

@@ -21,7 +21,7 @@ Document governance ensures your project follows these rules:
 
 1. **Root Directory** - Only 4 markdown files allowed: `README.md`, `README.zh.md`, `CHANGELOG.md`, `CONTRIBUTING.md`
 2. **Spec Structure** - Each Spec must have `requirements.md`, `design.md`, `tasks.md`
-3. **Artifact Organization** - Spec artifacts must be in subdirectories: `reports/`, `scripts/`, `tests/`, `results/`, `docs/`
+3. **Artifact Organization** - Spec artifacts must be in subdirectories, except approved Spec-root metadata such as `requirements.md`, `design.md`, `tasks.md`, and `collaboration.json`
 4. **No Temporary Files** - Temporary documents (like `*-SUMMARY.md`, `SESSION-*.md`) must be deleted after use
 
 ### Why Use Document Governance?
@@ -128,7 +128,7 @@ sce docs diagnose
 - Root directory for non-allowed markdown files
 - Root directory for temporary documents
 - Spec directories for missing required files
-- Spec directories for misplaced artifacts
+- Spec directories for misplaced artifacts outside approved Spec-root metadata
 - Spec directories for temporary documents
 
 **Output:**
@@ -240,6 +240,7 @@ sce docs validate [options]
 **What it validates:**
 - Root directory has only allowed markdown files
 - Spec directories have required files (requirements.md, design.md, tasks.md)
+- Spec root contains only approved metadata files plus governed subdirectories
 - Spec subdirectories follow naming conventions
 - No misplaced artifacts
 
@@ -443,6 +444,7 @@ sce docs config [options]
 
 **Configuration keys:**
 - `root-allowed-files` - Allowed markdown files in root
+- `spec-allowed-root-files` - Allowed files at Spec root before artifact warnings apply
 - `spec-subdirs` - Recognized Spec subdirectories
 - `temporary-patterns` - Patterns for temporary files
 
@@ -467,6 +469,12 @@ Spec Subdirectories:
   • results
   • docs
 
+Spec Allowed Root Files:
+  • requirements.md
+  • design.md
+  • tasks.md
+  • collaboration.json
+
 Temporary Patterns:
   • *-SUMMARY.md
   • SESSION-*.md
@@ -724,6 +732,12 @@ The default configuration is:
     "CHANGELOG.md",
     "CONTRIBUTING.md"
   ],
+  "specAllowedRootFiles": [
+    "requirements.md",
+    "design.md",
+    "tasks.md",
+    "collaboration.json"
+  ],
   "specSubdirs": [
     "reports",
     "scripts",
@@ -749,6 +763,11 @@ The default configuration is:
 sce docs config --set root-allowed-files "README.md,README.zh.md,CHANGELOG.md,CONTRIBUTING.md,LICENSE.md,SECURITY.md"
 ```
 
+**Allow additional Spec-root metadata:**
+```bash
+sce docs config --set spec-allowed-root-files "requirements.md,design.md,tasks.md,collaboration.json"
+```
+
 **Add custom subdirectories:**
 ```bash
 sce docs config --set spec-subdirs "reports,scripts,tests,results,docs,diagrams,examples"
@@ -768,6 +787,7 @@ You can also edit this file directly:
 ```json
 {
   "rootAllowedFiles": ["README.md", "CUSTOM.md"],
+  "specAllowedRootFiles": ["requirements.md", "design.md", "tasks.md", "collaboration.json"],
   "specSubdirs": ["reports", "scripts", "custom"],
   "temporaryPatterns": ["*-TEMP.md"]
 }

package/docs/releases/README.md

@@ -9,6 +9,8 @@ This directory stores release-facing documents:
 ## Archived Versions
 
 - [Release checklist](../release-checklist.md)
+- [v3.6.39 release notes](./v3.6.39.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/releases/v3.6.39.md

@@ -0,0 +1,24 @@
+# v3.6.39 Release Notes
+
+Release date: 2026-03-13
+
+## Highlights
+
+- Added a canonical state-storage tiering policy, reconciliation runbook, and audit/report tooling so SQLite remains a scoped index layer rather than a silent source-of-truth replacement.
+- Expanded and hardened the `sce scene` command surface with broader command coverage, stronger property tests, and JSON summary output that preserves edge-case numeric payloads.
+- Closed the `115-00-sce-quality-hardening-program` integration loop, including `watch logs --follow` completion and Jest open-handle governance without relying on `forceExit`.
+
+## Verification
+
+- `node bin/sce.js collab status 115-00-sce-quality-hardening-program --graph`
+- `npm run test:smoke`
+- `npm run test:skip-audit`
+- `npm run test:brand-consistency`
+- `npm run test:full`
+- `npm run test:handles`
+
+## Release Notes
+
+- State persistence is now explicitly tiered: evidence and operator-facing files remain canonical, while SQLite stays limited to rebuildable index/projection use cases.
+- The scene command family is substantially more release-ready, with dedicated tests and closeout artifacts across publish/install/info/diff/validate/owner/tag/stats/lock/contribute/version flows.
+- Quality hardening gates should be executed in sequence for release validation; `test:full` and `test:handles` are both green when run serially.

package/docs/state-migration-reconciliation-runbook.md

@@ -0,0 +1,76 @@
+# State Migration Reconciliation Runbook
+
+Use this runbook when working with the current file-to-SQLite migration surface.
+
+## Normal Flow
+
+1. Inspect scope
+   - `sce state plan --json`
+2. Diagnose drift
+   - `sce state doctor --json`
+3. Apply repair
+   - `sce state reconcile --all --apply --json`
+4. Re-check gate posture
+   - `node scripts/state-migration-reconciliation-gate.js --fail-on-blocking --fail-on-pending --json`
+
+## Severity Model
+
+### Blocking
+
+Treat these as release-blocking anomalies:
+
+- `sqlite-unavailable`
+- `source-parse-error`
+- `sqlite-ahead`
+- `sqlite-only`
+- runtime `sqlite-ahead`
+- runtime `sqlite-only`
+
+Typical meaning:
+
+- `sqlite-ahead`: SQLite contains index rows that are no longer represented by canonical files
+- `sqlite-only`: canonical file source disappeared but SQLite rows still exist
+
+### Alert
+
+Treat these as repairable but non-steady-state conditions:
+
+- `pending-migration`
+- `missing-source`
+- runtime `pending-sync`
+
+Typical meaning:
+
+- `pending-migration`: file source has more records than SQLite index
+- `missing-source`: the project does not currently have that source artifact
+
+## Operator Decisions
+
+### When `pending-migration`
+
+- Run `sce state reconcile --all --apply --json`
+- Re-run `sce state doctor --json`
+- If it persists, inspect source parser assumptions and source file health
+
+### When `sqlite-ahead`
+
+- Treat as anomaly first, not optimization
+- Inspect whether source artifacts were deleted, rotated, or never written
+- Rebuild or re-sync from canonical file source before release
+
+### When `sqlite-only`
+
+- Confirm whether the file source was removed accidentally
+- Restore canonical files when possible
+- Do not normalize this into a permanent state for current migration-scope components
+
+### When `missing-source`
+
+- If the component is intentionally unused in the current project, keep it advisory
+- If the component should exist for this workflow, generate or restore the source artifact and reconcile
+
+## Related Commands
+
+- `npm run gate:state-migration-reconciliation`
+- `npm run audit:state-storage`
+- `npm run report:interactive-approval-projection`

package/docs/state-storage-tiering.md

@@ -0,0 +1,104 @@
+# State Storage Tiering
+
+SCE uses a selective SQLite strategy.
+
+The operating rule is:
+
+- keep canonical evidence, audit, recovery payloads, and low-cardinality personal state in files
+- use SQLite for registry/index workloads with real query pressure
+- allow SQLite projections for append-only streams only when they are rebuildable from files
+
+## Tiers
+
+### `file-source`
+
+Use this tier when:
+
+- the file is the canonical evidence or audit artifact
+- the resource is a small personal or local configuration object
+- manual inspection, Git diff, and recovery are more important than indexed querying
+
+Examples:
+
+- `~/.sce/workspace-state.json`
+- `.sce/reports/**/*.jsonl`
+- `.sce/audit/**/*.jsonl`
+- `.sce/timeline/snapshots/**`
+- `.sce/session-governance/sessions/**`
+
+### `sqlite-index`
+
+Use this tier when:
+
+- the canonical content still lives in files
+- the resource behaves like a registry or index
+- repeated filtering, sorting, and cross-run queries justify an index
+
+Current active scope:
+
+- `collab.agent-registry` -> `.sce/config/agent-registry.json`
+- `runtime.timeline-index` -> `.sce/timeline/index.json`
+- `runtime.scene-session-index` -> `.sce/session-governance/scene-index.json`
+- `errorbook.entry-index` -> `.sce/errorbook/index.json`
+- `errorbook.incident-index` -> `.sce/errorbook/staging/index.json`
+- `governance.spec-scene-overrides` -> `.sce/spec-governance/spec-scene-overrides.json`
+- `governance.scene-index` -> `.sce/spec-governance/scene-index.json`
+- `release.evidence-runs-index` -> `.sce/reports/release-evidence/handoff-runs.json`
+- `release.gate-history-index` -> `.sce/reports/release-evidence/release-gate-history.json`
+
+### `derived-sqlite-projection`
+
+Use this tier only when:
+
+- the source remains append-only files
+- the projection can be deleted and rebuilt
+- reads clearly disclose when SQLite projection is used
+
+This tier is for query acceleration, not source-of-truth replacement.
+
+## Admission Rubric
+
+A resource should only enter SQLite scope when all of the following are true:
+
+1. Cross-run or cross-session query pressure is real.
+2. File scans are materially weaker than indexed filtering/sorting.
+3. SQLite rows are rebuildable from a canonical file or stream.
+4. Diagnostics, reconcile behavior, and operator guidance are defined up front.
+
+Reject SQLite source migration when any of the following are true:
+
+1. The resource is raw audit or evidence.
+2. The resource is low-cardinality workspace or preference state.
+3. Human-readable recovery and Git diff matter more than query speed.
+4. The change would silently cut over the source of truth.
+
+## Current Classification
+
+| Resource | Tier | Why |
+| --- | --- | --- |
+| `~/.sce/workspace-state.json` | `file-source` | Atomic personal state; no meaningful query pressure |
+| `.sce/reports/**/*.jsonl` | `file-source` | Canonical append-only governance/evidence streams |
+| `.sce/audit/**/*.jsonl` | `file-source` | Canonical audit evidence |
+| `.sce/timeline/index.json` | `sqlite-index` | Index-like query workload |
+| `.sce/session-governance/scene-index.json` | `sqlite-index` | Registry-like query workload |
+| `.sce/errorbook/index.json` | `sqlite-index` | Filtered status/quality lookup |
+| `.sce/errorbook/staging/index.json` | `sqlite-index` | Incident triage lookup |
+| `.sce/spec-governance/*.json` indexes | `sqlite-index` | Governance registry lookup |
+| `.sce/reports/release-evidence/handoff-runs.json` | `sqlite-index` | Historical release summary lookup |
+| `.sce/reports/release-evidence/release-gate-history.json` | `sqlite-index` | Gate history lookup |
+| `.sce/timeline/snapshots/**` | `file-source` | Recovery payloads |
+| `.sce/session-governance/sessions/**` | `file-source` | Session payload archives |
+
+## Operator Rules
+
+- Do not propose blanket sqlite-ization.
+- Before adding a new SQLite candidate, update `.sce/config/state-storage-policy.json`.
+- Run `npm run audit:state-storage` after changing state storage behavior.
+- If the resource is append-only evidence, prefer a projection pilot over source migration.
+
+## Related Assets
+
+- Policy file: `.sce/config/state-storage-policy.json`
+- Audit command: `npm run audit:state-storage`
+- Machine-readable report: `npm run report:state-storage`
+- State migration commands: `sce state plan|doctor|migrate|reconcile`

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,8 @@
 ## 历史版本归档
 
 - [发布检查清单](../release-checklist.md)
+- [v3.6.39 发布说明](./v3.6.39.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/docs/zh/releases/v3.6.39.md

@@ -0,0 +1,24 @@
+# v3.6.39 发布说明
+
+发布日期：2026-03-13
+
+## 重点变化
+
+- 新增规范化的状态存储分层策略、迁移对账 runbook，以及配套 audit/report 工具，明确 SQLite 只承担受控索引层，不替代文件真源。
+- 扩展并加固了 `sce scene` 命令族，补齐多类命令覆盖、性质测试和 JSON summary 输出边界处理。
+- 完成 `115-00-sce-quality-hardening-program` 主 Spec 的集成收口，包含 `watch logs --follow` 补完，以及不依赖 `forceExit` 的 Jest open-handle 治理。
+
+## 验证
+
+- `node bin/sce.js collab status 115-00-sce-quality-hardening-program --graph`
+- `npm run test:smoke`
+- `npm run test:skip-audit`
+- `npm run test:brand-consistency`
+- `npm run test:full`
+- `npm run test:handles`
+
+## 发布说明
+
+- 状态持久化现在有了明确分层：证据、审计和操作员可读文件继续保持 canonical，SQLite 仅用于可重建索引或投影。
+- `scene` 命令面已经更接近稳定发布状态，publish/install/info/diff/validate/owner/tag/stats/lock/contribute/version 等流都有专门测试和 closeout 证据。
+- 质量门禁建议串行执行；`test:full` 与 `test:handles` 在串行场景下均已验证通过。

package/lib/commands/docs.js

@@ -301,6 +301,12 @@ async function handleConfigDisplay(configManager, reporter) {
     console.log(`  • ${dir}`);
   });
   console.log();
+
+  console.log(chalk.bold('Spec Allowed Root Files:'));
+  (config.specAllowedRootFiles || []).forEach(file => {
+    console.log(`  • ${file}`);
+  });
+  console.log();
   
   console.log(chalk.bold('Temporary Patterns:'));
   config.temporaryPatterns.forEach(pattern => {
@@ -350,10 +356,10 @@ async function handleConfigSet(configManager, reporter, options) {
   const camelKey = key.replace(/-([a-z])/g, (g) => g[1].toUpperCase());
   
   // Validate key
-  const validKeys = ['rootAllowedFiles', 'specSubdirs', 'temporaryPatterns'];
+  const validKeys = ['rootAllowedFiles', 'specAllowedRootFiles', 'specSubdirs', 'temporaryPatterns'];
   if (!validKeys.includes(camelKey)) {
     reporter.displayError(`Invalid configuration key: ${key}`);
-    console.log(chalk.gray('Valid keys: root-allowed-files, spec-subdirs, temporary-patterns\n'));
+    console.log(chalk.gray('Valid keys: root-allowed-files, spec-allowed-root-files, spec-subdirs, temporary-patterns\n'));
     return 2;
   }