scene-capability-engine 3.0.1 → 3.0.2

package/docs/knowledge-management-guide.md

@@ -2,14 +2,14 @@
 
 ## Overview
 
-The Knowledge Management system allows you to build and maintain a personal knowledge base within your kse projects. Capture experiences, patterns, best practices, and lessons learned as you work.
+The Knowledge Management system allows you to build and maintain a personal knowledge base within your sce projects. Capture experiences, patterns, best practices, and lessons learned as you work.
 
 ## Quick Start
 
 ### Initialize Knowledge Base
 
 ```bash
-kse knowledge init
+sce knowledge init
 ```
 
 This creates `.kiro/knowledge/` directory with:
@@ -23,12 +23,12 @@ This creates `.kiro/knowledge/` directory with:
 
 ```bash
 # Add a design pattern
-kse knowledge add pattern "Repository Pattern Best Practices" \
+sce knowledge add pattern "Repository Pattern Best Practices" \
   --tags "design-pattern,database" \
   --category backend
 
 # Add a lesson learned
-kse knowledge add lesson "Avoid N+1 Queries" \
+sce knowledge add lesson "Avoid N+1 Queries" \
   --tags "performance,database" \
   --category optimization
 ```
@@ -37,51 +37,51 @@ kse knowledge add lesson "Avoid N+1 Queries" \
 
 ```bash
 # List all entries
-kse knowledge list
+sce knowledge list
 
 # Filter by type
-kse knowledge list --type pattern
+sce knowledge list --type pattern
 
 # Filter by tag
-kse knowledge list --tag database
+sce knowledge list --tag database
 
 # Sort by date
-kse knowledge list --sort created:desc
+sce knowledge list --sort created:desc
 ```
 
 ### Search
 
 ```bash
 # Search in titles and tags
-kse knowledge search "database"
+sce knowledge search "database"
 
 # Full-text search in content
-kse knowledge search "repository" --full-text
+sce knowledge search "repository" --full-text
 ```
 
 ### View Entry
 
 ```bash
-kse knowledge show kb-1770099318706-4dmali
+sce knowledge show kb-1770099318706-4dmali
 ```
 
 ### Delete Entry
 
 ```bash
 # With confirmation
-kse knowledge delete kb-xxx
+sce knowledge delete kb-xxx
 
 # Skip confirmation
-kse knowledge delete kb-xxx --force
+sce knowledge delete kb-xxx --force
 
 # Without backup
-kse knowledge delete kb-xxx --force --no-backup
+sce knowledge delete kb-xxx --force --no-backup
 ```
 
 ### Statistics
 
 ```bash
-kse knowledge stats
+sce knowledge stats
 ```
 
 ## Entry Types
@@ -190,10 +190,10 @@ Content here...
 
 ```bash
 # Export all entries
-kse knowledge export --output my-knowledge.zip
+sce knowledge export --output my-knowledge.zip
 
 # Import entries
-kse knowledge import my-knowledge.zip
+sce knowledge import my-knowledge.zip
 ```
 
 ### Integration with Project
@@ -214,7 +214,7 @@ See implementation in `lib/repository/user-repository.js`
 Error: Knowledge base not initialized
 ```
 
-**Solution**: Run `kse knowledge init`
+**Solution**: Run `sce knowledge init`
 
 ### Entry Not Found
 
@@ -222,7 +222,7 @@ Error: Knowledge base not initialized
 Error: Entry not found: kb-xxx
 ```
 
-**Solution**: Check ID with `kse knowledge list`
+**Solution**: Check ID with `sce knowledge list`
 
 ### Corrupted Index
 
@@ -236,7 +236,7 @@ Error: Failed to load index
 rm .kiro/knowledge/index.json
 
 # Reinitialize
-kse knowledge init
+sce knowledge init
 ```
 
 ## FAQ
@@ -254,7 +254,7 @@ A: Commit `.kiro/knowledge/` to git (except `.backups/`).
 A: Yes, create custom templates in `.kiro/knowledge/.templates/`.
 
 **Q: How do I backup my knowledge?**  
-A: Use `kse knowledge export` or commit to git.
+A: Use `sce knowledge export` or commit to git.
 
 ## See Also
 

package/docs/manual-workflows-guide.md

@@ -6,7 +6,7 @@
 
 ## Overview
 
-This guide provides step-by-step instructions for common workflows when using kiro-spec-engine without automation (watch mode or agent hooks). These workflows are designed to be efficient and easy to follow.
+This guide provides step-by-step instructions for common workflows when using scene-capability-engine without automation (watch mode or agent hooks). These workflows are designed to be efficient and easy to follow.
 
 **When to use manual workflows:**
 - When automation is not set up
@@ -35,7 +35,7 @@ Keep your workspace synchronized with task progress across multiple users or too
 - Subsequent syncs: 30-60 seconds
 
 ### Prerequisites
-- Project adopted with kiro-spec-engine
+- Project adopted with scene-capability-engine
 - Active spec with tasks.md file
 - Write access to .kiro/specs/ directory
 
@@ -43,7 +43,7 @@ Keep your workspace synchronized with task progress across multiple users or too
 
 #### 1. Check Current Status
 ```bash
-kse status
+sce status
 ```
 
 **What to look for:**
@@ -75,7 +75,7 @@ Open your spec's `tasks.md` file and review:
 
 #### 3. Sync Workspace
 ```bash
-kse workspace sync
+sce workspace sync
 ```
 
 **What this does:**
@@ -90,7 +90,7 @@ kse workspace sync
 
 #### 4. Verify Sync
 ```bash
-kse status
+sce status
 ```
 
 **Verify:**
@@ -116,7 +116,7 @@ kse status
 
 3. **Team Coordination**
    - Communicate task claims in team chat
-   - Use task claiming feature: `kse task claim <spec> <task-id>`
+   - Use task claiming feature: `sce task claim <spec> <task-id>`
    - Check for claimed tasks before starting work
 
 ---
@@ -138,7 +138,7 @@ Export spec context for sharing with AI assistants or team members.
 
 #### 1. Identify Spec to Export
 ```bash
-kse status
+sce status
 ```
 
 Note the spec name you want to export.
@@ -149,7 +149,7 @@ Note the spec name you want to export.
 
 #### 2. Export Context
 ```bash
-kse context export <spec-name>
+sce context export <spec-name>
 ```
 
 **Options:**
@@ -159,7 +159,7 @@ kse context export <spec-name>
 
 **Example:**
 ```bash
-kse context export my-feature --include-steering --steering-files CORE_PRINCIPLES.md,ENVIRONMENT.md
+sce context export my-feature --include-steering --steering-files CORE_PRINCIPLES.md,ENVIRONMENT.md
 ```
 
 **Time:** ~10-20 seconds
@@ -238,16 +238,16 @@ cat .kiro/specs/<spec-name>/tasks.md
 
 #### 2. Generate Prompt
 ```bash
-kse prompt generate <spec-name> <task-id>
+sce prompt generate <spec-name> <task-id>
 ```
 
 **Options:**
-- `--target <tool>`: Target tool (kiro, vscode, cursor, other)
+- `--target <tool>`: Target tool (SCE, vscode, cursor, other)
 - `--output <path>`: Custom output path
 
 **Example:**
 ```bash
-kse prompt generate my-feature 1.2 --target vscode
+sce prompt generate my-feature 1.2 --target vscode
 ```
 
 **Time:** ~10-15 seconds
@@ -281,7 +281,7 @@ For multiple tasks:
 ```bash
 # Generate prompts for all incomplete tasks
 for task in 1.1 1.2 1.3; do
-  kse prompt generate my-feature $task
+  sce prompt generate my-feature $task
 done
 ```
 
@@ -316,8 +316,8 @@ done
 ### Daily Workflow Checklist
 
 **Morning (Start of Work)**
-- [ ] Sync workspace: `kse workspace sync`
-- [ ] Check status: `kse status`
+- [ ] Sync workspace: `sce workspace sync`
+- [ ] Check status: `sce status`
 - [ ] Review task list
 - [ ] Claim tasks you'll work on
 - [ ] Export context for active tasks
@@ -331,7 +331,7 @@ done
 **End of Day**
 - [ ] Mark completed tasks
 - [ ] Update in-progress tasks
-- [ ] Final sync: `kse workspace sync`
+- [ ] Final sync: `sce workspace sync`
 - [ ] Commit changes to version control
 
 ---
@@ -351,7 +351,7 @@ done
 
 ### Spec Creation Checklist
 
-- [ ] Create spec: `kse spec bootstrap --name <name> --non-interactive`
+- [ ] Create spec: `sce spec bootstrap --name <name> --non-interactive`
 - [ ] Write requirements.md
 - [ ] Write design.md
 - [ ] Generate tasks.md
@@ -396,8 +396,8 @@ done
 
 1. **Set Up Automation:** Consider using watch mode for automatic workflows
    ```bash
-   kse watch init
-   kse watch install auto-sync
+   sce watch init
+   sce watch install auto-sync
    ```
 
 2. **Learn More:**
@@ -406,7 +406,7 @@ done
    - [Architecture](./architecture.md)
 
 3. **Get Help:**
-   - Run `kse --help` for command reference
+   - Run `sce --help` for command reference
    - Check [GitHub Issues](https://github.com/heguangyong/scene-capability-engine/issues)
    - Review [Contributing Guide](../CONTRIBUTING.md)
 

package/docs/moqui-capability-matrix.md

@@ -1,20 +1,20 @@
-# Moqui Capability Matrix For KSE
+# Moqui Capability Matrix For sce
 
-This document defines the execution boundary for converting Moqui capabilities into KSE capabilities.
+This document defines the execution boundary for converting Moqui capabilities into sce capabilities.
 
 ## Scope
 
-- Goal: turn Moqui ERP resources into reusable KSE scene templates.
+- Goal: turn Moqui ERP resources into reusable sce scene templates.
 - Method: `extract -> normalize -> package-gate -> handoff-run -> release evidence`.
 - Output: template assets with ontology, governance, and runtime-safe bindings.
 
 ## Capability Mapping
 
-| Priority | Moqui Capability | KSE Scene Pattern | Template ID | Ontology Anchors | Governance/Gate Focus | Status |
+| Priority | Moqui Capability | sce Scene Pattern | Template ID | Ontology Anchors | Governance/Gate Focus | Status |
 | --- | --- | --- | --- | --- | --- | --- |
-| P0 | Order read (`OrderHeader`, `OrderItem`, query services) | `query` | `kse.scene--erp-order-query-read--0.1.0` | `order_header`, `order_item`, `order_projection`, `customer_party` | low risk, idempotent query, lineage complete | template-ready |
-| P0 | Order fulfillment (reserve, payment, release) | `workflow` | `kse.scene--erp-order-fulfillment-workflow--0.1.0` | `order_header`, `order_item`, `inventory_reservation`, `payment_authorization`, `fulfillment_execution` | medium risk, approval required, compensation strategy | template-ready |
-| P0 | Inventory reserve + adjust | `workflow/crud hybrid` | `kse.scene--erp-inventory-reserve-adjust--0.1.0` | `inventory_item`, `inventory_reservation`, `inventory_adjustment`, `inventory_snapshot` | medium risk, approval required, non-negative stock rule | template-ready |
+| P0 | Order read (`OrderHeader`, `OrderItem`, query services) | `query` | `sce.scene--erp-order-query-read--0.1.0` | `order_header`, `order_item`, `order_projection`, `customer_party` | low risk, idempotent query, lineage complete | template-ready |
+| P0 | Order fulfillment (reserve, payment, release) | `workflow` | `sce.scene--erp-order-fulfillment-workflow--0.1.0` | `order_header`, `order_item`, `inventory_reservation`, `payment_authorization`, `fulfillment_execution` | medium risk, approval required, compensation strategy | template-ready |
+| P0 | Inventory reserve + adjust | `workflow/crud hybrid` | `sce.scene--erp-inventory-reserve-adjust--0.1.0` | `inventory_item`, `inventory_reservation`, `inventory_adjustment`, `inventory_snapshot` | medium risk, approval required, non-negative stock rule | template-ready |
 
 ## Ownership Boundary
 
@@ -25,7 +25,7 @@ This document defines the execution boundary for converting Moqui capabilities i
 - Handoff package (`docs/handoffs/handoff-manifest.json`) and ontology evidence.
 - Real-world acceptance cases and risk context.
 
-### KSE owns
+### sce owns
 
 - Template contract normalization and packaging format.
 - Ontology/gate enforcement and strict checks.
@@ -35,18 +35,18 @@ This document defines the execution boundary for converting Moqui capabilities i
 ## Batch Workflow
 
 1. 331-poc exports spec/template/handoff artifacts.
-2. KSE runs `auto handoff capability-matrix` as the fast intake gate.
-3. KSE runs `auto handoff run` with strict gates.
-4. KSE validates template registry and ontology consistency.
-5. KSE executes close-loop batch and snapshots observability.
-6. KSE archives evidence and publishes release.
+2. sce runs `auto handoff capability-matrix` as the fast intake gate.
+3. sce runs `auto handoff run` with strict gates.
+4. sce validates template registry and ontology consistency.
+5. sce executes close-loop batch and snapshots observability.
+6. sce archives evidence and publishes release.
 
 ## Fast Matrix Loop
 
 Use this command during template iteration before full handoff execution:
 
 ```bash
-kse auto handoff capability-matrix \
+sce auto handoff capability-matrix \
   --manifest docs/handoffs/handoff-manifest.json \
   --format markdown \
   --out .kiro/reports/handoff-capability-matrix.md \
@@ -56,18 +56,18 @@ kse auto handoff capability-matrix \
 
 `capability-matrix` now checks both capability coverage and semantic completeness (ontology entities/relations + governance business rules/decision logic) by default.
 
-When gaps exist, KSE writes remediation queue lines (default `.kiro/auto/moqui-remediation.lines`) that can be fed directly into:
+When gaps exist, sce writes remediation queue lines (default `.kiro/auto/moqui-remediation.lines`) that can be fed directly into:
 
 ```bash
-kse auto close-loop-batch .kiro/auto/moqui-remediation.lines --format lines --json
+sce auto close-loop-batch .kiro/auto/moqui-remediation.lines --format lines --json
 ```
 
 ## Definition Of Done
 
-A capability is considered absorbed by KSE when all checks pass:
+A capability is considered absorbed by sce when all checks pass:
 
-- `kse scene package-validate --strict`
-- `kse scene lint --strict`
-- `kse scene score --threshold 85`
-- `kse scene ontology validate`
-- `kse auto handoff run`
+- `sce scene package-validate --strict`
+- `sce scene lint --strict`
+- `sce scene score --threshold 85`
+- `sce scene ontology validate`
+- `sce auto handoff run`

package/docs/moqui-template-core-library-playbook.md

@@ -1,6 +1,6 @@
 # Moqui Template Core Library Playbook
 
-This playbook defines a generic (project-agnostic) path to absorb Moqui capabilities into the KSE core template library.
+This playbook defines a generic (project-agnostic) path to absorb Moqui capabilities into the sce core template library.
 
 ## Objectives
 
@@ -10,14 +10,14 @@ This playbook defines a generic (project-agnostic) path to absorb Moqui capabili
 
 ## Default Gate Baseline
 
-KSE defaults already enforce the baseline below:
+sce defaults already enforce the baseline below:
 
-- `kse auto handoff run`: ontology validation is required by default.
-- `kse auto handoff run`: generates Moqui baseline snapshot by default and appends it to release-evidence sessions.
-- `kse auto handoff run`: requires Moqui baseline portfolio pass by default.
-- `kse auto handoff run`: evaluates capability coverage matrix by default when manifest `capabilities` is declared (default minimum `100%`).
-- `kse auto handoff capability-matrix`: enforces both capability coverage and capability semantic completeness (default minimum `100%` for each).
-- `kse scene package-publish-batch`:
+- `sce auto handoff run`: ontology validation is required by default.
+- `sce auto handoff run`: generates Moqui baseline snapshot by default and appends it to release-evidence sessions.
+- `sce auto handoff run`: requires Moqui baseline portfolio pass by default.
+- `sce auto handoff run`: evaluates capability coverage matrix by default when manifest `capabilities` is declared (default minimum `100%`).
+- `sce auto handoff capability-matrix`: enforces both capability coverage and capability semantic completeness (default minimum `100%` for each).
+- `sce scene package-publish-batch`:
   - ontology validation required by default
   - batch ontology gate defaults:
     - average ontology score `>= 70`
@@ -33,16 +33,16 @@ Emergency bypass exists but is not recommended:
 
 ```bash
 # 0) Generate template baseline scoreboard (Moqui/ERP templates by default)
-kse scene moqui-baseline --json
+sce scene moqui-baseline --json
 
 # 0.1) CI/release mode: compare against previous baseline and enforce portfolio gate
-kse scene moqui-baseline \
+sce scene moqui-baseline \
   --compare-with .kiro/reports/release-evidence/moqui-template-baseline-prev.json \
   --fail-on-portfolio-fail \
   --json
 
 # 0.2) Fast capability matrix gate (recommended before full handoff run)
-kse auto handoff capability-matrix \
+sce auto handoff capability-matrix \
   --manifest docs/handoffs/handoff-manifest.json \
   --format markdown \
   --out .kiro/reports/handoff-capability-matrix.md \
@@ -50,24 +50,24 @@ kse auto handoff capability-matrix \
   --json
 
 # 1) Handoff close-loop
-kse auto handoff run --manifest docs/handoffs/handoff-manifest.json --json
+sce auto handoff run --manifest docs/handoffs/handoff-manifest.json --json
 
 # 2) Publish templates from scene packages (with default ontology gates)
-kse scene package-publish-batch \
+sce scene package-publish-batch \
   --manifest docs/handoffs/handoff-manifest.json \
   --json
 
 # 3) Persist ontology publish evidence for governance/review
-kse scene package-publish-batch \
+sce scene package-publish-batch \
   --manifest docs/handoffs/handoff-manifest.json \
   --dry-run \
   --ontology-report-out .kiro/reports/scene-package-ontology-batch.json \
   --json
 
 # 4) Validate registry + package gate
-kse scene package-registry --template-dir .kiro/templates/scene-packages --strict --json
-kse scene package-gate-template --out .kiro/templates/scene-package-gate-policy.json --profile three-layer --force --json
-kse scene package-gate --registry .kiro/templates/scene-packages/registry.json --policy .kiro/templates/scene-package-gate-policy.json --strict --json
+sce scene package-registry --template-dir .kiro/templates/scene-packages --strict --json
+sce scene package-gate-template --out .kiro/templates/scene-package-gate-policy.json --profile three-layer --force --json
+sce scene package-gate --registry .kiro/templates/scene-packages/registry.json --policy .kiro/templates/scene-package-gate-policy.json --strict --json
 ```
 
 ## Evidence Contract
@@ -80,7 +80,7 @@ Required artifacts for each intake batch:
 - `.kiro/reports/release-evidence/moqui-template-baseline.md`
 - `.kiro/reports/release-evidence/moqui-capability-coverage.json`
 - `.kiro/reports/release-evidence/moqui-capability-coverage.md`
-- `.kiro/reports/handoff-capability-matrix.md` (or JSON equivalent from `kse auto handoff capability-matrix`)
+- `.kiro/reports/handoff-capability-matrix.md` (or JSON equivalent from `sce auto handoff capability-matrix`)
 - `.kiro/reports/handoff-runs/<session>.json`
 - `.kiro/reports/scene-package-ontology-batch.json`
 - `.kiro/auto/moqui-remediation.lines` (when baseline/coverage gaps exist)
@@ -99,11 +99,11 @@ Each accepted template should include ontology semantics for:
 If any area is weak, export remediation queue lines and feed back to close-loop:
 
 ```bash
-kse scene package-publish-batch \
+sce scene package-publish-batch \
   --manifest docs/handoffs/handoff-manifest.json \
   --dry-run \
   --ontology-task-queue-out .kiro/auto/ontology-remediation.lines \
   --json
 
-kse auto close-loop-batch .kiro/auto/ontology-remediation.lines --format lines --json
+sce auto close-loop-batch .kiro/auto/ontology-remediation.lines --format lines --json
 ```

package/docs/multi-agent-coordination-guide.md

@@ -1,6 +1,6 @@
 # Multi-Agent Parallel Coordination Guide
 
-> Enable multiple AI agents to work on the same kse project simultaneously without conflicts.
+> Enable multiple AI agents to work on the same sce project simultaneously without conflicts.
 
 **Version**: 1.44.0  
 **Last Updated**: 2026-02-12
@@ -9,7 +9,7 @@
 
 ## Overview
 
-When multiple AI agent instances (e.g., multiple Kiro IDE windows, Claude Code sessions, or Cursor instances) work on the same project, they can accidentally overwrite each other's changes, claim the same tasks, or corrupt shared files like `tasks.md`.
+When multiple AI agent instances (e.g., multiple AI IDE windows, Claude Code sessions, or Cursor instances) work on the same project, they can accidentally overwrite each other's changes, claim the same tasks, or corrupt shared files like `tasks.md`.
 
 The Multi-Agent Parallel Coordination system solves this with six layers of protection:
 
@@ -56,7 +56,7 @@ Create the configuration file `.kiro/config/multi-agent.json`:
 When an agent starts working, it registers with the AgentRegistry:
 
 ```javascript
-const { AgentRegistry } = require('kiro-spec-engine/lib/collab');
+const { AgentRegistry } = require('scene-capability-engine/lib/collab');
 
 const registry = new AgentRegistry(workspaceRoot);
 const { agentId } = await registry.register();
@@ -67,7 +67,7 @@ const { agentId } = await registry.register();
 ### 3. Lock Tasks Before Working
 
 ```javascript
-const { TaskLockManager } = require('kiro-spec-engine/lib/lock');
+const { TaskLockManager } = require('scene-capability-engine/lib/lock');
 
 const lockManager = new TaskLockManager(workspaceRoot);
 const result = await lockManager.acquireTaskLock('my-spec', '1.1', agentId);
@@ -124,7 +124,7 @@ Manages agent lifecycle with heartbeat-based health monitoring.
 **Storage**: `.kiro/config/agent-registry.json`
 
 ```javascript
-const { AgentRegistry } = require('kiro-spec-engine/lib/collab');
+const { AgentRegistry } = require('scene-capability-engine/lib/collab');
 const registry = new AgentRegistry(workspaceRoot);
 
 // Register a new agent
@@ -157,7 +157,7 @@ File-based mutual exclusion for task ownership.
 **Lock files**: `.kiro/specs/{specName}/locks/{taskId}.lock`
 
 ```javascript
-const { TaskLockManager } = require('kiro-spec-engine/lib/lock');
+const { TaskLockManager } = require('scene-capability-engine/lib/lock');
 const lockManager = new TaskLockManager(workspaceRoot);
 
 // Acquire a task lock
@@ -194,7 +194,7 @@ Concurrent-safe updates to `tasks.md` with conflict detection and retry.
 **File**: `lib/task/task-status-store.js`
 
 ```javascript
-const { TaskStatusStore } = require('kiro-spec-engine/lib/task');
+const { TaskStatusStore } = require('scene-capability-engine/lib/task');
 const store = new TaskStatusStore(workspaceRoot);
 
 // Update task status with file locking
@@ -223,7 +223,7 @@ Write serialization for steering files (`.kiro/steering/*.md`).
 **File**: `lib/lock/steering-file-lock.js`
 
 ```javascript
-const { SteeringFileLock } = require('kiro-spec-engine/lib/lock');
+const { SteeringFileLock } = require('scene-capability-engine/lib/lock');
 const steeringLock = new SteeringFileLock(workspaceRoot);
 
 // Execute callback with lock held
@@ -249,7 +249,7 @@ Git branch isolation per agent for conflict-free parallel development.
 **File**: `lib/collab/merge-coordinator.js`
 
 ```javascript
-const { MergeCoordinator } = require('kiro-spec-engine/lib/collab');
+const { MergeCoordinator } = require('scene-capability-engine/lib/collab');
 const merger = new MergeCoordinator(workspaceRoot);
 
 // Create agent-specific branch
@@ -277,7 +277,7 @@ When `coordinator: true` in config, provides intelligent task assignment based o
 **Log**: `.kiro/config/coordination-log.json`
 
 ```javascript
-const { Coordinator } = require('kiro-spec-engine/lib/collab');
+const { Coordinator } = require('scene-capability-engine/lib/collab');
 const coordinator = new Coordinator(workspaceRoot, depManager, registry, lockManager);
 
 // Get tasks ready to execute (dependencies satisfied, not locked)
@@ -303,7 +303,7 @@ Per-Spec `steering.md` providing independent constraints, notes, and decisions f
 **Storage**: `.kiro/specs/{spec-name}/steering.md`
 
 ```javascript
-const { SpecSteering } = require('kiro-spec-engine/lib/steering');
+const { SpecSteering } = require('scene-capability-engine/lib/steering');
 const specSteering = new SpecSteering(workspaceRoot);
 
 // Create a steering template for a new Spec
@@ -330,7 +330,7 @@ Unified loader that merges all four steering layers (L1-L4) into a single contex
 **File**: `lib/steering/steering-loader.js`
 
 ```javascript
-const { SteeringLoader } = require('kiro-spec-engine/lib/steering');
+const { SteeringLoader } = require('scene-capability-engine/lib/steering');
 const loader = new SteeringLoader(workspaceRoot);
 
 // Load a specific layer
@@ -351,7 +351,7 @@ Multi-agent friendly maintenance of `CURRENT_CONTEXT.md` with structured Spec pr
 **File**: `lib/steering/context-sync-manager.js`
 
 ```javascript
-const { ContextSyncManager } = require('kiro-spec-engine/lib/steering');
+const { ContextSyncManager } = require('scene-capability-engine/lib/steering');
 const syncManager = new ContextSyncManager(workspaceRoot);
 
 // Read current context
@@ -382,7 +382,7 @@ State machine managing Spec lifecycle transitions with auto-completion detection
 Valid transitions: `planned → assigned → in-progress → completed → released`
 
 ```javascript
-const { SpecLifecycleManager } = require('kiro-spec-engine/lib/collab');
+const { SpecLifecycleManager } = require('scene-capability-engine/lib/collab');
 const lifecycle = new SpecLifecycleManager(workspaceRoot);
 
 // Get current Spec status
@@ -407,7 +407,7 @@ Ensures agents synchronize state before switching between Specs.
 **File**: `lib/collab/sync-barrier.js`
 
 ```javascript
-const { SyncBarrier } = require('kiro-spec-engine/lib/collab');
+const { SyncBarrier } = require('scene-capability-engine/lib/collab');
 const barrier = new SyncBarrier(workspaceRoot);
 
 // Check before switching Specs
@@ -532,16 +532,16 @@ All components check `MultiAgentConfig.isEnabled()` before doing anything:
 
 ```javascript
 // Collaboration modules
-const { AgentRegistry, Coordinator, MergeCoordinator, MultiAgentConfig, SpecLifecycleManager, SyncBarrier } = require('kiro-spec-engine/lib/collab');
+const { AgentRegistry, Coordinator, MergeCoordinator, MultiAgentConfig, SpecLifecycleManager, SyncBarrier } = require('scene-capability-engine/lib/collab');
 
 // Steering modules
-const { SpecSteering, SteeringLoader, ContextSyncManager } = require('kiro-spec-engine/lib/steering');
+const { SpecSteering, SteeringLoader, ContextSyncManager } = require('scene-capability-engine/lib/steering');
 
 // Lock modules
-const { TaskLockManager, SteeringFileLock } = require('kiro-spec-engine/lib/lock');
+const { TaskLockManager, SteeringFileLock } = require('scene-capability-engine/lib/lock');
 
 // Task modules
-const { TaskStatusStore } = require('kiro-spec-engine/lib/task');
+const { TaskStatusStore } = require('scene-capability-engine/lib/task');
 ```
 
 ---