scene-capability-engine 3.0.1 → 3.0.3

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,41 @@
-# 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 |
+| P1 | Party master (`Party`, `PartyRole`) | `crud` | `sce.scene--erp-party-management--0.1.0` | `party`, `party_role`, `party_relationship` | medium risk, merge/dedup strategy required | matrix-intake-ready |
+| P1 | Product master (`Product`, classification/pricing) | `crud` | `sce.scene--erp-product-management--0.1.0` | `product`, `product_category`, `price_rule` | medium risk, version consistency, rule closure | matrix-intake-ready |
+| P1 | Procurement + supplier flow | `workflow` | `sce.scene--erp-procurement-management--0.1.0` | `purchase_order`, `supplier_party`, `receipt_line` | medium risk, approval + receipt reconciliation | matrix-intake-ready |
+| P1 | Shipment execution + tracking | `workflow` | `sce.scene--erp-shipment-management--0.1.0` | `shipment`, `shipment_item`, `fulfillment_event` | medium risk, irreversible step guard | matrix-intake-ready |
+| P1 | Return/RMA handling | `workflow` | `sce.scene--erp-return-rma-management--0.1.0` | `return_header`, `return_item`, `refund_decision` | medium risk, policy decision completeness | matrix-intake-ready |
+| P1 | Production run + work order execution | `workflow` | `sce.scene--erp-production-run--0.1.0` | `production_run`, `work_effort`, `material_issue` | high risk, capacity/exception path required | matrix-intake-ready |
+| P1 | BOM + routing maintenance | `crud/workflow hybrid` | `sce.scene--erp-bom-routing-management--0.1.0` | `bom`, `routing`, `operation_step` | medium risk, effective-date governance | matrix-intake-ready |
+| P1 | Quality inspection + hold/release | `decision workflow` | `sce.scene--erp-quality-inspection--0.1.0` | `inspection_lot`, `quality_rule`, `release_decision` | high risk, decision closure mandatory | matrix-intake-ready |
+| P1 | Equipment lifecycle + maintenance | `workflow` | `sce.scene--erp-equipment-management--0.1.0` | `equipment_asset`, `maintenance_order`, `downtime_event` | medium risk, safety/approval policy | matrix-intake-ready |
+| P2 | Workflow approval engine | `platform service` | `sce.scene--platform-workflow-approval-engine--0.1.0` | `approval_flow`, `approval_node`, `approval_decision` | high risk, branch decision coverage | matrix-intake-ready |
+| P2 | Reporting + audit operations | `platform query` | `sce.scene--platform-reporting-audit-ops--0.1.0` | `audit_event`, `report_slice`, `trace_lineage` | low risk, lineage completeness | matrix-intake-ready |
+| P2 | Suite observability/parity audit | `platform query/dashboard` | `sce.scene--platform-suite-observability-parity--0.1.0` | `suite_capability`, `parity_audit`, `scene_coverage` | medium risk, regression signal quality | matrix-intake-ready |
+
+## 331-poc Intake Snapshot
+
+- Source baseline: `331-poc/docs/handoffs/handoff-manifest.json` (timestamp `2026-02-18T01:08:00+08:00`).
+- Newly aligned domain set in this round: party/product/order/procurement/inventory/production/quality/equipment/cost/engineering/hr/calendar + suite platform governance templates.
+- Core landing contract:
+  - capability aliases are normalized through `lib/data/moqui-capability-lexicon.json`
+  - handoff run default gate keeps `max_moqui_matrix_regressions=0`
+  - governance stats/close-loop consumes matrix regression signals as release-block conditions
 
 ## Ownership Boundary
 
@@ -25,7 +46,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 +56,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 +77,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,16 @@ 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`: enforces Moqui matrix regression hard-gate by default (`max_moqui_matrix_regressions=0`).
+- `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 auto governance stats` / `sce auto governance close-loop`: treats Moqui matrix regressions as first-class risk/block signals (including over-gate stop reasons).
+- `sce scene package-publish-batch`:
   - ontology validation required by default
   - batch ontology gate defaults:
     - average ontology score `>= 70`
@@ -32,42 +34,55 @@ Emergency bypass exists but is not recommended:
 ## One-Shot Intake Flow
 
 ```bash
-# 0) Generate template baseline scoreboard (Moqui/ERP templates by default)
-kse scene moqui-baseline --json
+# 0) Generate template baseline scoreboard (Moqui + scene orchestration templates by default)
+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 \
   --fail-on-gap \
   --json
 
+# 0.3) Capability lexicon audit (expected/provided canonical alignment)
+node scripts/moqui-lexicon-audit.js \
+  --manifest docs/handoffs/handoff-manifest.json \
+  --template-dir .kiro/templates/scene-packages \
+  --fail-on-gap \
+  --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
+
+# 1.1) Explicitly keep strict matrix hard-gate (same as default, recommended in CI)
+sce auto handoff run \
+  --manifest docs/handoffs/handoff-manifest.json \
+  --max-moqui-matrix-regressions 0 \
+  --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,13 +95,26 @@ 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/release-evidence/moqui-lexicon-audit.json`
+- `.kiro/reports/release-evidence/moqui-lexicon-audit.md`
+- `.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)
 - `.kiro/templates/scene-packages/registry.json`
 - gate output/evidence linked from release notes or handoff summary
 
+`moqui-template-baseline.json` summary should be consumed as a matrix gate:
+- `scope_breakdown` (moqui_erp / scene_orchestration / other)
+- `coverage_matrix` (entity/relation/business-rule/decision coverage and closure rates)
+- `gap_frequency` (top recurring ontology gaps for remediation prioritization)
+- `compare.coverage_matrix_deltas` (trend deltas used to detect matrix regression/plateau between runs)
+- `compare.coverage_matrix_regressions` (negative-delta signals consumed by auto remediation/recommendation flows)
+- default handoff hard-gate enforces `max_moqui_matrix_regressions=0` unless explicitly relaxed
+- governance close-loop block reasons include:
+  - `handoff-moqui-matrix-regressions-positive:<n>`
+  - `handoff-moqui-matrix-regressions-over-gate:<n>/<max>`
+
 ## Minimum Semantic Coverage
 
 Each accepted template should include ontology semantics for:
@@ -99,11 +127,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
 ```