scene-capability-engine 3.6.64 → 3.6.67

package/docs/project-management/delivery/acceptance/exceptions/README.md

@@ -0,0 +1,3 @@
+# 验收例外
+
+用于记录带条件通过、遗留问题与例外项。

package/docs/project-management/delivery/acceptance/reports/README.md

@@ -0,0 +1,3 @@
+# 验收报告
+
+用于沉淀验收结论、评审意见和签收说明。

package/docs/project-management/delivery/documents/changes.md

@@ -0,0 +1,3 @@
+# 变更说明
+
+用于说明变更请求对象、影响面与决策要求。

package/docs/project-management/delivery/documents/issues.md

@@ -0,0 +1,3 @@
+# 问题说明
+
+用于说明问题跟踪对象、严重级别和闭环方式。

package/docs/project-management/delivery/documents/overview.md

@@ -0,0 +1,3 @@
+# 交付总览说明
+
+这里说明交付推进目录的组织方式、审查入口和闭环要求。

package/docs/project-management/delivery/documents/planning.md

@@ -0,0 +1,3 @@
+# 计划说明
+
+用于说明计划排期对象、里程碑和责任分工。

package/docs/project-management/delivery/documents/requirements.md

@@ -0,0 +1,3 @@
+# 需求说明
+
+用于说明需求清单字段规范、维护方式与验收边界。

package/docs/project-management/delivery/documents/tracking.md

@@ -0,0 +1,3 @@
+# 推进说明
+
+用于说明推进跟踪对象、状态字段和节奏要求。

package/docs/project-management/delivery/handoffs/README.md

@@ -0,0 +1,3 @@
+# 交接
+
+用于组织交接记录、未完成项、风险项与交接证据。

package/docs/project-management/delivery/handoffs/evidence/README.md

@@ -0,0 +1,3 @@
+# 交接证据
+
+用于归档交接附件、快照、日志和审查证据。

package/docs/project-management/delivery/handoffs/records/README.md

@@ -0,0 +1,3 @@
+# 交接记录
+
+用于按交接对象沉淀 handoff 记录。

package/docs/project-management/delivery/overview.md

@@ -0,0 +1,10 @@
+# 交付推进总览
+
+用于承接当前项目的交付范围、推进状态、风险与审查入口。
+
+建议补充：
+
+- 当前交付目标
+- 主要场景 / spec 范围
+- 当前里程碑
+- 交付风险与阻塞

package/docs/project-management/delivery/releases/README.md

@@ -0,0 +1,3 @@
+# 版本 / 发布
+
+用于组织发布基线、批次、变更摘要与回滚线索。

package/docs/project-management/delivery/releases/baselines/README.md

@@ -0,0 +1,3 @@
+# 发布基线
+
+用于沉淀每次交付的基线说明与版本清单。

package/docs/project-management/delivery/releases/evidence/README.md

@@ -0,0 +1,3 @@
+# 发布证据
+
+用于归档发布结果、比对记录与回滚证据。

package/docs/project-management/delivery/tables/changes.md

@@ -0,0 +1,3 @@
+# 变更请求
+
+此处用于映射范围调整、影响面和决策记录。

package/docs/project-management/delivery/tables/issues.md

@@ -0,0 +1,3 @@
+# 问题跟踪
+
+此处用于映射测试、验收和运行问题。

package/docs/project-management/delivery/tables/planning.md

@@ -0,0 +1,3 @@
+# 计划排期
+
+此处用于映射计划、里程碑和责任分工。

package/docs/project-management/delivery/tables/requirements.md

@@ -0,0 +1,3 @@
+# 需求清单
+
+此处用于映射结构化需求总表，支持人工审查与快速浏览。

package/docs/project-management/delivery/tables/tracking.md

@@ -0,0 +1,3 @@
+# 推进跟踪
+
+此处用于映射当前推进状态板与下一步动作。

package/docs/project-management/environment/agent-discovery.md

@@ -0,0 +1,3 @@
+# 自动发现
+
+用于说明不同 Agent 的发现职责、写回位置和页面装载规则。

package/docs/project-management/environment/development.md

@@ -0,0 +1,3 @@
+# 开发环境
+
+用于记录开发环境的应用容器、入口代理、本机依赖和资源状态。

package/docs/project-management/environment/overview.md

@@ -0,0 +1,10 @@
+# 应用环境监管总览
+
+用于总览当前项目的开发、测试环境，统一查看运行状态、版本对齐、容器状态和运维观测范围。
+
+建议补充：
+
+- 当前纳管环境清单
+- 每套环境的发现来源
+- 版本漂移与风险摘要
+- 仍待补齐的运维观测项

package/docs/project-management/environment/testing.md

@@ -0,0 +1,3 @@
+# 测试环境
+
+用于记录测试环境的提测版本、回归任务、数据快照和入口健康状态。

package/docs/project-management/environment/version-alignment.md

@@ -0,0 +1,3 @@
+# 版本对齐
+
+用于统一比对代码版本、镜像标签、环境配置与规格基线，定位环境漂移。

package/docs/quick-start-with-ai-tools.md

@@ -1,375 +1,135 @@
-# 快速入门：配合 AI 工具使用 sce
+# Quick Start with AI Tools
 
-> 5分钟学会如何用 sce 配合 Claude、Cursor、Copilot 等 AI 工具
+> Use SCE as the project governance layer while working from Codex CLI, Claude Code, Cursor, Kiro, or other AI runtimes.
 
 ---
 
-## ⚠️ 重要：sce 的定位
+## Positioning
 
-**sce 不是独立开发工具，而是 AI 工具的增强器**
+SCE is not just a pile of helper prompts.
 
-```
-你的工作界面 = AI 工具（Codex/Claude/Cursor）
-sce 的角色 = 后台管理 Spec，为 AI 提供结构化上下文
-```
-
-**简单理解**：
-- ❌ sce 不是用来写代码的
-- ✅ sce 是用来**组织项目信息**，让 AI 更好地帮你写代码
-- ✅ 你主要在 AI 工具中工作，sce 在后台提供支持
+Today it can work through host tools, but the governed project model belongs to SCE itself:
 
-**三种使用模式**：
-1. **AI 主动调用 sce**（Windsurf/Cline）- 最佳，完全自动 ⭐
-2. **手动导出上下文**（Claude/ChatGPT）- 当前方式
-3. **Watch Mode 自动化**（所有工具）- 进阶用法
+- SCE governs `project -> channel/session -> scene/spec -> task -> evidence`
+- host tools are collaboration shells, not the source of project truth
+- compatibility flows such as `context export` still exist, but they are fallback paths, not the preferred mainline
 
-**详细说明**：查看 [集成哲学文档](./integration-philosophy.md)
+Before execution, adopted projects use the `Four Teachings + Little Nine` governance baseline.
 
 ---
 
-## 核心理念
+## Default Working Model
 
-**sce 是什么？**
-- 一个 CLI 工具，帮你管理项目的 Spec（需求、设计、任务）
-- 生成结构化的上下文，让 AI 工具更好地理解你的项目
+After `sce adopt`, the default assumptions are:
 
-**为什么需要 sce？**
-- AI 工具需要清晰的上下文才能生成高质量代码
-- sce 帮你组织和导出这些上下文
-- 让 AI 按照你的设计和规范工作
+- one project may have multiple collaboration channels in parallel
+- each `project + channel/session` keeps its own `scene/spec/doc/session/tabs/tree/draft/runState`
+- `CURRENT_CONTEXT.md` is a summary only
+- active work must be attached to a Spec
+- agent-generated logs, scripts, reports, and debug artifacts belong under the active Spec subtree
+- if a Spec is not explicit yet, stage the work through governed planning first
+- after more than two failed localization rounds, update the errorbook incident and use bisection-style debug evidence
 
 ---
 
-## 工作流程图
-
-```
-┌─────────────┐
-│  1. 用 sce  │
-│  创建 Spec  │
-└──────┬──────┘
-       │
-       ▼
-┌─────────────┐
-│  2. 导出    │
-│  上下文     │
-└──────┬──────┘
-       │
-       ▼
-┌─────────────┐
-│  3. 复制到  │
-│  AI 工具    │
-└──────┬──────┘
-       │
-       ▼
-┌─────────────┐
-│  4. AI 帮你 │
-│  写代码     │
-└──────┬──────┘
-       │
-       ▼
-┌─────────────┐
-│  5. 更新    │
-│  任务状态   │
-└─────────────┘
-```
-
----
+## Preferred Path: Command-Capable AI Runtime
 
-## 5分钟快速开始
+If your AI tool can execute commands in the repo, use this path first.
 
-### 步骤 1：安装 sce
+### 1. Install and adopt
 
 ```bash
 npm install -g scene-capability-engine
-```
-
-### 步骤 2：初始化项目
-
-```bash
 cd your-project
 sce adopt
 ```
 
-这会在项目中创建 `.sce/` 目录。
-
-### 步骤 3：创建你的第一个 Spec
-
-```bash
-sce spec bootstrap --name 01-00-user-login --non-interactive
-```
-
-然后编辑生成的文件：
-- `.sce/specs/01-00-user-login/requirements.md` - 写需求
-- `.sce/specs/01-00-user-login/design.md` - 写设计
-- `.sce/specs/01-00-user-login/tasks.md` - 列任务
-
-### 步骤 4：导出上下文
-
-```bash
-sce context export 01-00-user-login
-```
-
-这会生成：`.sce/specs/01-00-user-login/context-export.md`
-
-### 步骤 5：使用 AI 工具
+### 2. Let the AI read the project contract
 
-#### 方式 A：Claude Code / ChatGPT
+Tell the AI runtime:
 
-1. 打开生成的 `context-export.md`
-2. 复制全部内容
-3. 粘贴到 Claude/ChatGPT 对话框
-4. 说："请帮我实现任务 1.1"
-
-#### 方式 B：Cursor
-
-1. 生成任务提示：
-   ```bash
-   sce prompt generate 01-00-user-login 1.1
-   ```
-
-2. 打开 Cursor Composer (Cmd+K)
-3. 粘贴生成的提示
-4. Cursor 会根据上下文生成代码
-
-#### 方式 C：GitHub Copilot
-
-1. 在代码文件中添加注释：
-   ```javascript
-   // Task 1.1: Implement user login
-   // See: .sce/specs/01-00-user-login/design.md
-   ```
-
-2. Copilot 会根据 Spec 文件生成代码
-
-### 步骤 6：更新任务状态
-
-完成任务后，编辑 `tasks.md`：
-
-```markdown
-- [x] 1.1 实现用户登录功能  ← 改成 [x] 表示完成
-- [ ] 1.2 添加密码加密
+```text
+Read .sce/README.md and the active steering/spec files before making changes.
 ```
 
----
-
-## 详细示例：用 Claude Code 实现登录功能
-
-### 1. 创建 Spec
+### 3. Stage or continue governed work
 
 ```bash
-sce spec bootstrap --name 01-00-user-login --non-interactive
-```
-
-### 2. 编写需求（requirements.md）
-
-```markdown
-# 用户登录功能
-
-## 1. 功能需求
-
-### 1.1 用户可以用邮箱和密码登录
-- 输入：邮箱、密码
-- 输出：登录成功返回 token，失败返回错误信息
-- 验证：邮箱格式、密码长度 >= 6
-```
-
-### 3. 编写设计（design.md）
-
-```markdown
-# 设计方案
-
-## 1. API 设计
-
-### 1.1 登录接口
-- 路径：POST /api/auth/login
-- 请求体：{ email: string, password: string }
-- 响应：{ token: string } 或 { error: string }
-
-## 2. 实现方案
-
-### 2.1 AuthController
-- validateEmail() - 验证邮箱格式
-- validatePassword() - 验证密码长度
-- login() - 处理登录逻辑
-```
-
-### 4. 列出任务（tasks.md）
-
-```markdown
-- [ ] 1.1 实现 AuthController 类
-- [ ] 1.2 实现邮箱验证
-- [ ] 1.3 实现密码验证
-- [ ] 1.4 实现登录逻辑
-- [ ] 1.5 编写单元测试
+sce status
+sce studio plan --goal "clarify and stage the next work item" --json
+sce spec bootstrap --name 01-00-example --scene scene.example --non-interactive
+sce spec pipeline run --spec 01-00-example --scene scene.example
+sce spec gate run --spec 01-00-example --scene scene.example --json
 ```
 
-### 5. 导出上下文
+### 4. Inspect cross-project or semantic drift when needed
 
 ```bash
-sce context export 01-00-user-login
-```
-
-### 6. 在 Claude Code 中使用
-
-**对话示例**：
-
+sce project supervision show --json
+sce semantic progress --json
 ```
-你：[粘贴 context-export.md 的全部内容]
-
-你：请帮我实现任务 1.1 "实现 AuthController 类"，
-    按照设计文档中的方案，用 TypeScript 实现。
-
-Claude：好的，我会根据设计文档实现 AuthController 类...
-[生成代码]
-
-你：很好！现在请为这个类编写单元测试。
-
-Claude：[生成测试代码]
 
-你：完美！请帮我更新 tasks.md，标记任务 1.1 为完成。
-
-[你手动更新 tasks.md：- [x] 1.1 实现 AuthController 类]
-```
+This is the preferred path because the AI works against governed state instead of relying on fragile chat memory.
 
 ---
 
-## 不同 AI 工具的最佳实践
-
-### Claude Code / ChatGPT
-✅ **优势**：大上下文窗口，可以一次加载完整 Spec  
-📝 **用法**：复制 `context-export.md` 全部内容  
-💡 **技巧**：一次对话可以完成多个任务
-
-### Cursor
-✅ **优势**：IDE 集成，可以直接修改文件  
-📝 **用法**：用 `sce prompt generate` 生成任务提示  
-💡 **技巧**：使用 Composer 模式，让 Cursor 直接编辑文件
-
-### GitHub Copilot
-✅ **优势**：实时代码补全  
-📝 **用法**：在代码注释中引用 Spec 文件  
-💡 **技巧**：写详细的注释，Copilot 会根据 Spec 生成代码
-
-### Windsurf / Cline
-✅ **优势**：可以执行命令和修改文件  
-📝 **用法**：让 AI 直接运行 `sce` 命令  
-💡 **技巧**：AI 可以自动导出上下文和更新任务状态
-
----
-
-## 常见问题
-
-### Q: 每次都要复制粘贴上下文吗？
-
-**A**: 取决于 AI 工具：
-- **Claude/ChatGPT**：是的，每次新对话需要重新加载
-- **Cursor**：可以在项目中持续使用，Cursor 会记住上下文
-- **Copilot**：不需要，它会自动读取项目文件
+## Compatibility Path: Read-Only or Limited AI Runtime
 
-### Q: 上下文太大怎么办？
+If your tool cannot reliably execute SCE commands, use compatibility export as a fallback:
 
-**A**: 使用任务级别的提示：
 ```bash
-# 只导出特定任务的上下文
-sce prompt generate 01-00-user-login 1.1
+sce context export 01-00-example
+sce prompt generate 01-00-example 1.1
 ```
 
-### Q: AI 生成的代码不符合设计怎么办？
-
-**A**: 
-1. 检查 `design.md` 是否写得够详细
-2. 在提示中明确说："严格按照设计文档实现"
-3. 提供代码示例在设计文档中
-
-### Q: 如何让 AI 遵循项目规范？
-
-**A**: 使用 Steering Rules：
-```bash
-# 导出时包含规范
-sce context export 01-00-user-login --steering --steering-files=CORE_PRINCIPLES.md
-```
-
-### Q: 可以自动更新任务状态吗？
-
-**A**: 
-- **AI IDE**：支持自动更新
-- **其他工具**：需要手动更新 `tasks.md`
-- **未来**：计划支持更多工具的自动更新
+Use this path only when direct governed execution is unavailable. It is a compatibility bridge, not the long-term primary model.
 
 ---
 
-## 进阶技巧
+## Three Practical Modes
 
-### 1. 使用 Steering Rules 控制 AI 行为
+### 1. Takeover Mode
 
-创建 `.sce/steering/CODING_STANDARDS.md`：
+Best for Codex CLI, Claude Code, Kiro, or any runtime that can operate in the repo.
 
-```markdown
-# 编码规范
+- AI reads `.sce/README.md`
+- AI follows steering + active Spec
+- AI writes governed artifacts under the active Spec
 
-- 使用 TypeScript
-- 所有函数必须有 JSDoc 注释
-- 使用 async/await 而不是 Promise.then
-- 错误处理使用 try-catch
-```
+### 2. Compatibility Export Mode
 
-导出时包含：
-```bash
-sce context export 01-00-user-login --steering
-```
+Best for tools that mainly consume pasted context.
 
-### 2. 为不同工具生成不同格式的提示
+- operator runs `context export` / `prompt generate`
+- AI works from exported context
+- operator still keeps final artifacts/spec changes under SCE governance
 
-```bash
-# 为 Claude 生成
-sce prompt generate 01-00-user-login 1.1 --tool=claude-code
+### 3. Native SCE Runtime Mode
 
-# 为 Cursor 生成
-sce prompt generate 01-00-user-login 1.1 --tool=cursor
+This is the direction being expanded through the semantic/runtime line.
 
-# 通用格式
-sce prompt generate 01-00-user-login 1.1
-```
+- host tool dependency is reduced over time
+- semantic observation, replay, evaluation, shared-source backflow, and operator control keep moving into SCE-native surfaces
 
-### 3. 批量导出多个任务
+---
 
-```bash
-# 导出整个 Spec
-sce context export 01-00-user-login
+## What To Avoid
 
-# 然后在 AI 工具中说：
-# "请按顺序实现任务 1.1 到 1.5"
-```
+- Do not treat one chat thread as the source of project truth
+- Do not scatter analysis documents or debug logs outside governed Spec locations
+- Do not assume a project has only one current session
+- Do not keep patching blindly after repeated failed localization attempts
 
 ---
 
-## 总结
+## Next Reading
 
-**sce 的价值**：
-1. ✅ 结构化管理项目需求和设计
-2. ✅ 生成 AI 友好的上下文
-3. ✅ 让 AI 按照你的规范工作
-4. ✅ 跟踪任务进度
-
-**配合 AI 工具的流程**：
-1. 用 sce 写 Spec（需求、设计、任务）
-2. 导出上下文
-3. 复制给 AI 工具
-4. AI 帮你写代码
-5. 更新任务状态
-
-**下一步**：
-- 查看 [完整跨工具指南](./cross-tool-guide.md)
-- 查看 [命令参考](./command-reference.md)
-- 查看 [手动工作流指南](./manual-workflows-guide.md)
+- [Quick Start](./quick-start.md)
+- [Integration Modes](./integration-modes.md)
+- [Integration Philosophy](./integration-philosophy.md)
+- [Command Reference](./command-reference.md)
 
 ---
 
-**开始使用！** 🚀
-
-```bash
-npm install -g scene-capability-engine
-sce adopt
-sce spec bootstrap --name 01-00-my-feature --non-interactive
-```
-
+**Version**: 3.6.67
+**Last Updated**: 2026-03-29

package/docs/releases/README.md

@@ -9,6 +9,9 @@ This directory stores release-facing documents:
 ## Archived Versions
 
 - [Release checklist](../release-checklist.md)
+- [v3.6.67 release notes](./v3.6.67.md)
+- [v3.6.66 release notes](./v3.6.66.md)
+- [v3.6.65 release notes](./v3.6.65.md)
 - [v3.6.64 release notes](./v3.6.64.md)
 - [v3.6.63 release notes](./v3.6.63.md)
 - [v3.6.62 release notes](./v3.6.62.md)

package/docs/releases/v3.6.65.md

@@ -0,0 +1,25 @@
+# v3.6.65 Release Notes
+
+Release date: 2026-03-22
+
+## Highlights
+
+- Formalized onboarding-to-portfolio convergence: `sce project onboarding import --root <path> --json` now emits an explicit `publish` step plus `publication` metadata, so IDEs can tell whether the imported project is already visible in the canonical portfolio without inventing a shadow registry.
+- Locked the contract with unit and integration coverage that proves onboarding identity matches the follow-up `sce project portfolio show --json` identity.
+- Published the next runtime-planning line into the main repository through Specs `137-00` to `140-03`, keeping the external agent direction vendor-neutral and split into bounded rollout contracts instead of one oversized implementation spec.
+- Strengthened release metadata hygiene by extending `audit:release-docs` to also check `docs/command-reference.md`, `docs/README.md`, and `docs/zh/README.md`.
+
+## Validation
+
+- `npx jest tests/unit/commands/project.test.js --runInBand`
+- `npx jest tests/integration/project-cli.integration.test.js --runInBand`
+- `node scripts/magicball-project-contract-audit.js --json`
+- `npm run report:clarification-first-audit`
+- `npm run audit:release-docs`
+- `npm run prepublishOnly`
+- `npm pack --dry-run`
+
+## Release Notes
+
+- Use `v3.6.65` if you need canonical onboarding publication semantics for IDE project import flows, plus the upstream runtime rollout specs that define the next vendor-neutral external agent integration line.
+- This patch also hardens the release process itself: key docs now fail release metadata audit when their version/date footers drift behind the package version and latest CHANGELOG release date.

package/docs/releases/v3.6.66.md

@@ -0,0 +1,23 @@
+# v3.6.66 Release Notes
+
+Release date: 2026-03-28
+
+## Highlights
+
+- Rebuilt the publish path around a stable-core release gate instead of one oversized release workflow that mixed stable publish checks with Moqui, matrix, weekly-ops, and other extended evidence generation.
+- Added explicit deprecated-entry governance so top-level integration docs and template entry docs can no longer quietly drift back to the old embedded/manual-export-first model.
+- Elevated the project release posture to `stable` after wiring stable-core, deprecated-entry audit, errorbook gates, and release posture self-check into the publish path.
+
+## Validation
+
+- `npm run gate:release-posture`
+- `npm run audit:deprecated-entry`
+- `npm run audit:release-docs`
+- `node scripts/agent-governance-baseline-audit.js --fail-on-violation --json`
+- `npx jest tests/unit/scripts/deprecated-entry-audit.test.js tests/unit/scripts/release-posture-report.test.js --runInBand`
+- `npx jest tests/integration/project-cli.integration.test.js tests/integration/adopt-upgrade-clarification-first.integration.test.js --runInBand`
+
+## Release Notes
+
+- Use `v3.6.66` if you want the release process to treat stable publish as a narrow, explainable gate instead of a bundle of unrelated extended evidence flows.
+- This release also aligns top-level entry docs and template entry docs with the current `project -> channel/session -> scene/spec` mainline and keeps compatibility export flows as fallback paths instead of primary guidance.