scene-capability-engine 3.3.5 → 3.3.10

package/docs/multi-repo-management-guide.md

@@ -17,8 +17,8 @@ sce repo init
 This command:
 - Scans your project directory for Git repositories
 - Extracts remote URLs and current branches
-- Creates `.kiro/project-repos.json` configuration file
-- Excludes the `.kiro` directory from scanning
+- Creates `.sce/project-repos.json` configuration file
+- Excludes the `.sce` directory from scanning
 
 **Example output:**
 ```
@@ -28,7 +28,7 @@ Found 3 repositories:
   ✓ backend (develop) - https://github.com/user/backend.git
   ✓ shared (main) - https://github.com/user/shared.git
 
-Configuration saved to .kiro/project-repos.json
+Configuration saved to .sce/project-repos.json
 ```
 
 ### 2. Check Repository Status
@@ -110,7 +110,7 @@ Overall Health: 2 healthy, 1 unhealthy
 
 ## Configuration File Format
 
-The configuration is stored in `.kiro/project-repos.json`:
+The configuration is stored in `.sce/project-repos.json`:
 
 ```json
 {
@@ -197,7 +197,7 @@ Paths can be specified as:
 
 ### Overview
 
-Starting with v1.21.0, you can manually create and edit the `.kiro/project-repos.json` configuration file without relying solely on `sce repo init`. This is useful for:
+Starting with v1.21.0, you can manually create and edit the `.sce/project-repos.json` configuration file without relying solely on `sce repo init`. This is useful for:
 
 - Curating a specific list of repositories
 - Removing false positives from auto-scan
@@ -307,12 +307,12 @@ When you manually create or edit the configuration, `sce` validates:
 **Step 1: Create the directory structure**
 
 ```bash
-mkdir -p .kiro
+mkdir -p .sce
 ```
 
 **Step 2: Create the configuration file**
 
-Create `.kiro/project-repos.json` with your repositories:
+Create `.sce/project-repos.json` with your repositories:
 
 ```json
 {
@@ -691,7 +691,7 @@ Error: Circular parent reference detected: repo-a -> repo-b -> repo-a
 ```
 
 **Solution:**
-1. Open `.kiro/project-repos.json`
+1. Open `.sce/project-repos.json`
 2. Check the `parent` fields
 3. Remove or fix the circular reference
 4. Run `sce repo health` to verify
@@ -724,7 +724,7 @@ To migrate an existing configuration to use nested scanning:
 
 ```bash
 # Backup existing configuration
-cp .kiro/project-repos.json .kiro/project-repos.json.backup
+cp .sce/project-repos.json .sce/project-repos.json.backup
 
 # Re-initialize with nested scanning
 sce repo init --nested -y
@@ -754,7 +754,7 @@ sce repo init [options]
 
 **Behavior:**
 - Scans project directory recursively for Git repositories
-- Excludes `.kiro` directory and common build directories (node_modules, build, dist, etc.)
+- Excludes `.sce` directory and common build directories (node_modules, build, dist, etc.)
 - Extracts remote URL from `origin` remote (or first available remote)
 - Detects current branch
 - Prompts for confirmation if configuration already exists
@@ -970,7 +970,7 @@ sce repo exec "git push"
 
 ## Manual Configuration
 
-You can manually edit `.kiro/project-repos.json` to:
+You can manually edit `.sce/project-repos.json` to:
 
 ### Add a Repository
 
@@ -1081,7 +1081,7 @@ If you're using a version prior to v1.20.5, the scanner may incorrectly identify
 
 **Error:**
 ```
-Error: Configuration file not found at .kiro/project-repos.json
+Error: Configuration file not found at .sce/project-repos.json
 ```
 
 **Solution:**
@@ -1095,7 +1095,7 @@ Error: Repository path does not exist: packages/frontend
 ```
 
 **Solution:**
-1. Verify the path in `.kiro/project-repos.json`
+1. Verify the path in `.sce/project-repos.json`
 2. Ensure the repository is cloned
 3. Update the path if the repository moved
 
@@ -1122,7 +1122,7 @@ Error: Configuration validation failed:
 ```
 
 **Solution:**
-1. Open `.kiro/project-repos.json`
+1. Open `.sce/project-repos.json`
 2. Fix validation errors
 3. Ensure all required fields are present
 4. Remove duplicate names
@@ -1157,10 +1157,10 @@ Error: Permission denied accessing repository: frontend
 
 ### 1. Keep Configuration in Version Control
 
-Add `.kiro/project-repos.json` to your main repository:
+Add `.sce/project-repos.json` to your main repository:
 
 ```bash
-git add .kiro/project-repos.json
+git add .sce/project-repos.json
 git commit -m "docs: add multi-repo configuration"
 ```
 
@@ -1299,7 +1299,7 @@ Validate configuration before committing:
 ```bash
 # Add to pre-commit hook
 #!/bin/bash
-if [ -f .kiro/project-repos.json ]; then
+if [ -f .sce/project-repos.json ]; then
   sce repo health || exit 1
 fi
 ```

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

@@ -90,7 +90,7 @@ cd your-project
 sce adopt
 ```
 
-这会在项目中创建 `.kiro/` 目录。
+这会在项目中创建 `.sce/` 目录。
 
 ### 步骤 3：创建你的第一个 Spec
 
@@ -99,9 +99,9 @@ sce spec bootstrap --name 01-00-user-login --non-interactive
 ```
 
 然后编辑生成的文件：
-- `.kiro/specs/01-00-user-login/requirements.md` - 写需求
-- `.kiro/specs/01-00-user-login/design.md` - 写设计
-- `.kiro/specs/01-00-user-login/tasks.md` - 列任务
+- `.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：导出上下文
 
@@ -109,7 +109,7 @@ sce spec bootstrap --name 01-00-user-login --non-interactive
 sce context export 01-00-user-login
 ```
 
-这会生成：`.kiro/specs/01-00-user-login/context-export.md`
+这会生成：`.sce/specs/01-00-user-login/context-export.md`
 
 ### 步骤 5：使用 AI 工具
 
@@ -136,7 +136,7 @@ sce context export 01-00-user-login
 1. 在代码文件中添加注释：
    ```javascript
    // Task 1.1: Implement user login
-   // See: .kiro/specs/01-00-user-login/design.md
+   // See: .sce/specs/01-00-user-login/design.md
    ```
 
 2. Copilot 会根据 Spec 文件生成代码
@@ -302,7 +302,7 @@ sce context export 01-00-user-login --steering --steering-files=CORE_PRINCIPLES.
 
 ### 1. 使用 Steering Rules 控制 AI 行为
 
-创建 `.kiro/steering/CODING_STANDARDS.md`：
+创建 `.sce/steering/CODING_STANDARDS.md`：
 
 ```markdown
 # 编码规范

package/docs/quick-start.md

@@ -38,7 +38,7 @@ cd your-project
 sce adopt
 ```
 
-This creates `.kiro/` directory with:
+This creates `.sce/` directory with:
 - `README.md` - Project development guide
 - `steering/` - Development rules
 - `specs/` - Where Specs will live
@@ -50,7 +50,7 @@ This creates `.kiro/` directory with:
 **In your AI tool (Cursor, Claude, Windsurf, etc.), say:**
 
 ```
-Please read .kiro/README.md to understand how this project works.
+Please read .sce/README.md to understand how this project works.
 ```
 
 **Your AI will learn:**

package/docs/release-checklist.md

@@ -32,7 +32,7 @@ node bin/scene-capability-engine.js value metrics --help
 sce value metrics sample --out ./kpi-input.json --json
 sce value metrics snapshot --input ./kpi-input.json --json
 node scripts/release-ops-weekly-summary.js --json
-node scripts/release-risk-remediation-bundle.js --gate-report .kiro/reports/release-evidence/release-gate.json --json
+node scripts/release-risk-remediation-bundle.js --gate-report .sce/reports/release-evidence/release-gate.json --json
 ```
 
 Expected:
@@ -146,10 +146,10 @@ Ensure:
 - Optional release-asset 0-byte guard (enabled in workflow by default):
   - `scripts/release-asset-nonempty-normalize.js` auto-fills placeholder content for optional assets such as `.lines` and `.jsonl` before GitHub Release upload.
   - Local dry-run example:
-    - `node scripts/release-asset-nonempty-normalize.js --file .kiro/reports/release-evidence/matrix-remediation-vX.Y.Z.lines --kind lines --note "no matrix remediation items for this release" --dry-run --json`
+    - `node scripts/release-asset-nonempty-normalize.js --file .sce/reports/release-evidence/matrix-remediation-vX.Y.Z.lines --kind lines --note "no matrix remediation items for this release" --dry-run --json`
   - Local normalize example:
-    - `node scripts/release-asset-nonempty-normalize.js --file .kiro/reports/release-evidence/interactive-matrix-signals-vX.Y.Z.jsonl --kind jsonl --event interactive-matrix-signals --note "No interactive matrix signals collected for this release." --json`
+    - `node scripts/release-asset-nonempty-normalize.js --file .sce/reports/release-evidence/interactive-matrix-signals-vX.Y.Z.jsonl --kind jsonl --event interactive-matrix-signals --note "No interactive matrix signals collected for this release." --json`
 - Optional local dry-run for gate history index artifact:
-  - `sce auto handoff gate-index --dir .kiro/reports/release-evidence --out .kiro/reports/release-evidence/release-gate-history.json --json`
+  - `sce auto handoff gate-index --dir .sce/reports/release-evidence --out .sce/reports/release-evidence/release-gate-history.json --json`
 
 Then proceed with your release workflow (tag, push, npm publish, GitHub release).

package/docs/sce-business-mode-map.md

@@ -0,0 +1,103 @@
+# SCE Business Mode Map
+
+This guide defines how SCE should run as the default capability control plane after being integrated into an application system.
+
+## 1. Scope
+
+- Applies to integrated business systems that expose UI + AI assistant capabilities.
+- SCE is the default orchestrator for all AI-driven tasks in the host system.
+- Every request is routed by mode, risk, and authorization state before execution.
+
+## 2. Three Operating Modes
+
+| Mode | Primary Goal | Typical Actor | Default Execution | Mutating Change Policy | Required Evidence |
+| --- | --- | --- | --- | --- | --- |
+| `user-mode` | Complete business tasks safely | End user | `suggestion` | Block direct apply by default | intent, summary, guidance |
+| `ops-mode` | Maintain system health and fix runtime issues | Operations / support | `suggestion` + guarded `apply` | Allow apply after runtime + authorization + approval gates | plan, work-order, ledger, gate signals |
+| `dev-mode` | Deliver new features and structural changes | Developer / product engineer | `suggestion` + staged `apply` | Require branch-level review and release gates | spec deltas, test evidence, release evidence |
+
+## 3. Default Takeover Principle
+
+After SCE integration is enabled:
+
+1. All AI intents must enter SCE first.
+2. SCE decides route: answer only, generate patch, repair, or rollback.
+3. Any mutating action must pass governance gates before apply.
+4. Every apply/rollback must write auditable artifacts.
+
+## 4. Runtime Flow (Default)
+
+1. `intent intake`: capture goal + page/context payload.
+2. `mode classification`: resolve `user-mode` / `ops-mode` / `dev-mode`.
+3. `strategy routing`: choose answer-only, patch, repair loop, or rollback.
+4. `symbol-level evidence`: locate affected files/symbols and build plan.
+5. `gated execution`: runtime policy + authorization tier + approval gate.
+6. `execution + audit`: execute or block, then emit summary and evidence.
+
+## 5. Mode Playbooks
+
+### 5.1 user-mode (business usage UI)
+
+- UI profile: business-user.
+- Default policy: advice and guided actions only.
+- Apply behavior: denied unless elevated to ops/dev flow explicitly.
+- Recommended command pattern:
+
+```bash
+sce scene interactive-flow \
+  --goal "<business-goal>" \
+  --ui-mode user-app \
+  --dialogue-profile business-user \
+  --execution-mode suggestion \
+  --json
+```
+
+### 5.2 ops-mode (maintenance console)
+
+- UI profile: system-maintainer.
+- Default policy: allow guarded apply for low/medium risk fixes.
+- Required gates: runtime policy, authorization tier, approval workflow.
+- Recommended command pattern:
+
+```bash
+sce scene interactive-flow \
+  --goal "<ops-goal>" \
+  --ui-mode ops-console \
+  --dialogue-profile system-maintainer \
+  --execution-mode apply \
+  --runtime-environment staging \
+  --auto-execute-low-risk \
+  --json
+```
+
+### 5.3 dev-mode (feature and restructuring)
+
+- UI profile: system-maintainer or engineering profile.
+- Default policy: spec-first planning + controlled implementation.
+- Required gates: spec completeness, tests, release preflight evidence.
+- Recommended command pattern:
+
+```bash
+sce auto close-loop-batch <manifest.json> \
+  --format json \
+  --batch-retry-until-complete \
+  --json
+```
+
+## 6. Security and Authorization Baseline
+
+- Password authorization is mandatory for mutating apply mode.
+- Runtime `non-allow` decisions must block unattended apply.
+- Weekly governance gates are mandatory before release.
+- Legacy steering migration must be manually approved before non-migration commands can proceed.
+
+See also: `docs/security-governance-default-baseline.md`
+
+## 7. Integration Checklist
+
+1. Map UI surfaces to one of the three modes.
+2. Wire the AI assistant to call SCE as first-hop router.
+3. Enable required gate artifacts and audit logs.
+4. Run weekly governance and release gates.
+5. Keep capability matrix and ontology mapping updated per release.
+

package/docs/security-governance-default-baseline.md

@@ -33,17 +33,17 @@ This baseline is the default operating policy for SCE-driven delivery, including
 
 ## 4. Mandatory Audit Artifacts
 
-- `.kiro/reports/release-evidence/handoff-runs.json`
-- `.kiro/reports/release-evidence/release-gate-history.json`
-- `.kiro/reports/release-evidence/governance-snapshot-<tag>.json`
-- `.kiro/reports/release-evidence/weekly-ops-summary-<tag>.json`
-- `.kiro/reports/interactive-governance-report.json`
-- `.kiro/reports/interactive-dialogue-authorization-signals.jsonl`
-- `.kiro/reports/interactive-runtime-signals.jsonl`
-- `.kiro/reports/interactive-authorization-tier-signals.jsonl`
-- `.kiro/reports/interactive-dialogue-governance.json`
-- `.kiro/reports/interactive-execution-ledger.jsonl`
-- `.kiro/reports/interactive-approval-events.jsonl`
+- `.sce/reports/release-evidence/handoff-runs.json`
+- `.sce/reports/release-evidence/release-gate-history.json`
+- `.sce/reports/release-evidence/governance-snapshot-<tag>.json`
+- `.sce/reports/release-evidence/weekly-ops-summary-<tag>.json`
+- `.sce/reports/interactive-governance-report.json`
+- `.sce/reports/interactive-dialogue-authorization-signals.jsonl`
+- `.sce/reports/interactive-runtime-signals.jsonl`
+- `.sce/reports/interactive-authorization-tier-signals.jsonl`
+- `.sce/reports/interactive-dialogue-governance.json`
+- `.sce/reports/interactive-execution-ledger.jsonl`
+- `.sce/reports/interactive-approval-events.jsonl`
 
 ## 5. Weekly Control Loop
 
@@ -51,7 +51,7 @@ This baseline is the default operating policy for SCE-driven delivery, including
 node scripts/interactive-governance-report.js --period weekly --fail-on-alert --json
 node scripts/release-ops-weekly-summary.js --json
 node scripts/release-weekly-ops-gate.js
-node scripts/release-risk-remediation-bundle.js --gate-report .kiro/reports/release-evidence/release-gate.json --json
+node scripts/release-risk-remediation-bundle.js --gate-report .sce/reports/release-evidence/release-gate.json --json
 node scripts/release-asset-integrity-check.js
 ```
 

package/docs/spec-collaboration-guide.md

@@ -71,7 +71,7 @@ sce collab assign session-manager SCE-3
 
 ### 4. Define Interface Contracts
 
-Create an interface contract for a Spec (in `.kiro/specs/{spec-name}/interfaces/`):
+Create an interface contract for a Spec (in `.sce/specs/{spec-name}/interfaces/`):
 
 ```json
 {
@@ -306,7 +306,7 @@ When you need to make breaking changes to an interface:
 
 ### Custom Integration Tests
 
-Create integration tests in `.kiro/specs/{master-spec}/integration-tests/`:
+Create integration tests in `.sce/specs/{master-spec}/integration-tests/`:
 
 ```javascript
 module.exports = {
@@ -332,7 +332,7 @@ module.exports = {
 
 ## Metadata File Format
 
-Collaboration metadata is stored in `.kiro/specs/{spec-name}/collaboration.json`:
+Collaboration metadata is stored in `.sce/specs/{spec-name}/collaboration.json`:
 
 ```json
 {

package/docs/spec-locking-guide.md

@@ -174,7 +174,7 @@ sce lock acquire quick-fix --timeout 2  # 2 hours
 
 ### Machine ID Storage
 
-Machine IDs are stored in `.kiro/config/machine-id.json` and are automatically generated on first use.
+Machine IDs are stored in `.sce/config/machine-id.json` and are automatically generated on first use.
 
 ## Troubleshooting
 
@@ -202,7 +202,7 @@ Consider adding this to your CI/CD pipeline or team workflow.
 
 ## File Format
 
-Lock files are stored as `.kiro/specs/<spec-name>/.lock` with JSON format:
+Lock files are stored as `.sce/specs/<spec-name>/.lock` with JSON format:
 
 ```json
 {

package/docs/spec-workflow.md

@@ -254,7 +254,7 @@ Response: { ... }
 sce spec bootstrap --name 01-00-user-login --non-interactive
 ```
 
-**2. Write Requirements** (`.kiro/specs/01-00-user-login/requirements.md`):
+**2. Write Requirements** (`.sce/specs/01-00-user-login/requirements.md`):
 ```markdown
 # User Login
 
@@ -266,7 +266,7 @@ sce spec bootstrap --name 01-00-user-login --non-interactive
 - WHEN user enters invalid credentials THEN they see an error
 ```
 
-**3. Write Design** (`.kiro/specs/01-00-user-login/design.md`):
+**3. Write Design** (`.sce/specs/01-00-user-login/design.md`):
 ```markdown
 # User Login - Design
 
@@ -281,7 +281,7 @@ Response: { token } or { error }
 - UserRepository - database access
 ```
 
-**4. Write Tasks** (`.kiro/specs/01-00-user-login/tasks.md`):
+**4. Write Tasks** (`.sce/specs/01-00-user-login/tasks.md`):
 ```markdown
 - [ ] 1.1 Create AuthController
 - [ ] 1.2 Create AuthService

package/docs/starter-kit/README.md

@@ -44,7 +44,7 @@ node scripts/release-ops-weekly-summary.js --json
 
 ## Default Evidence Set
 
-- `.kiro/reports/release-evidence/handoff-runs.json`
-- `.kiro/reports/release-evidence/release-gate-history.json`
-- `.kiro/reports/release-evidence/governance-snapshot-<tag>.json`
-- `.kiro/reports/release-evidence/weekly-ops-summary-<tag>.json`
+- `.sce/reports/release-evidence/handoff-runs.json`
+- `.sce/reports/release-evidence/release-gate-history.json`
+- `.sce/reports/release-evidence/governance-snapshot-<tag>.json`
+- `.sce/reports/release-evidence/weekly-ops-summary-<tag>.json`

package/docs/starter-kit/handoff-manifest.starter.json

@@ -5,8 +5,8 @@
     {
       "id": "60-10-example-capability-spec",
       "status": "completed",
-      "scene_package": ".kiro/specs/60-10-example-capability-spec/custom/scene-package.json",
-      "scene_manifest": ".kiro/specs/60-10-example-capability-spec/custom/scene.yaml"
+      "scene_package": ".sce/specs/60-10-example-capability-spec/custom/scene-package.json",
+      "scene_manifest": ".sce/specs/60-10-example-capability-spec/custom/scene.yaml"
     }
   ],
   "templates": [

package/docs/starter-kit/release.workflow.sample.yml

@@ -25,7 +25,7 @@ jobs:
         run: |
           set -euo pipefail
           TAG="${GITHUB_REF_NAME}"
-          NOTES_DIR=".kiro/reports/release-evidence"
+          NOTES_DIR=".sce/reports/release-evidence"
           mkdir -p "${NOTES_DIR}"
 
           node scripts/release-ops-weekly-summary.js \

package/docs/steering-strategy-guide.md

@@ -2,11 +2,11 @@
 
 ## Overview
 
-When adopting scene-capability-engine (sce) into a project that already has steering files in `.kiro/steering/`, you must choose a steering strategy. This is because AI IDE loads all files in the steering directory, and having both sce steering rules and your project's custom steering rules can cause conflicts.
+When adopting scene-capability-engine (sce) into a project that already has steering files in `.sce/steering/`, you must choose a steering strategy. This is because AI IDE loads all files in the steering directory, and having both sce steering rules and your project's custom steering rules can cause conflicts.
 
 ## Why Steering Exclusivity?
 
-AI IDE automatically loads all Markdown files in `.kiro/steering/` as AI behavior rules. If you have both sce steering files and your project's custom steering files, the AI will try to follow both sets of rules, which can lead to:
+AI IDE automatically loads all Markdown files in `.sce/steering/` as AI behavior rules. If you have both sce steering files and your project's custom steering files, the AI will try to follow both sets of rules, which can lead to:
 
 - Conflicting instructions
 - Unpredictable AI behavior
@@ -24,9 +24,9 @@ Therefore, you must choose **one** set of steering rules to use.
 - You want the full sce experience with optimized AI behavior
 
 **What happens:**
-1. Your existing steering files are backed up to `.kiro/backups/steering-{timestamp}/`
-2. sce steering template files are installed to `.kiro/steering/`
-3. The backup ID is saved in `.kiro/adoption-config.json`
+1. Your existing steering files are backed up to `.sce/backups/steering-{timestamp}/`
+2. sce steering template files are installed to `.sce/steering/`
+3. The backup ID is saved in `.sce/adoption-config.json`
 4. You can rollback if needed
 
 **Files installed:**
@@ -45,7 +45,7 @@ Therefore, you must choose **one** set of steering rules to use.
 **What happens:**
 1. Your existing steering files are preserved
 2. sce steering files are **not** installed
-3. The choice is documented in `.kiro/adoption-config.json`
+3. The choice is documented in `.sce/adoption-config.json`
 4. You can manually integrate sce steering concepts if desired
 
 **Trade-offs:**
@@ -81,20 +81,20 @@ sce rollback --list
 sce rollback {backup-id}
 ```
 
-Or manually restore from `.kiro/backups/steering-{timestamp}/`.
+Or manually restore from `.sce/backups/steering-{timestamp}/`.
 
 ## Manual Integration
 
 If you chose "use-project" but want to incorporate sce steering concepts:
 
-1. Review sce steering templates in `template/.kiro/steering/`
+1. Review sce steering templates in `template/.sce/steering/`
 2. Identify useful concepts (Spec workflow, Ultrawork principles, etc.)
 3. Manually merge relevant sections into your steering files
 4. Test with a sample Spec to ensure compatibility
 
 ## Configuration File
 
-Your steering strategy choice is saved in `.kiro/adoption-config.json`:
+Your steering strategy choice is saved in `.sce/adoption-config.json`:
 
 ```json
 {
@@ -137,7 +137,7 @@ Your steering strategy choice is saved in `.kiro/adoption-config.json`:
 ### Problem: AI behavior is inconsistent after adoption
 
 **Solution:**
-- Check which steering strategy you chose: `cat .kiro/adoption-config.json`
+- Check which steering strategy you chose: `cat .sce/adoption-config.json`
 - If "use-kse", verify sce steering files are present
 - If "use-project", ensure your steering files are compatible with sce
 
@@ -151,13 +151,13 @@ Your steering strategy choice is saved in `.kiro/adoption-config.json`:
 
 2. If currently "use-project":
    - Manually backup your steering files
-   - Copy sce templates from `template/.kiro/steering/`
-   - Update `.kiro/adoption-config.json`
+   - Copy sce templates from `template/.sce/steering/`
+   - Update `.sce/adoption-config.json`
 
 ### Problem: Lost steering backup
 
 **Solution:**
-- Check `.kiro/backups/` for steering backups
+- Check `.sce/backups/` for steering backups
 - Backups are named `steering-{timestamp}`
 - If no backup exists, you'll need to recreate your steering files
 
@@ -186,8 +186,8 @@ A: Yes, but you'll need to manually manage the steering files and update the con
 ## Related Documentation
 
 - [Adoption Guide](./adoption-guide.md) - Complete adoption workflow
-- [Spec Workflow Guide](../.kiro/specs/SPEC_WORKFLOW_GUIDE.md) - How to use Specs
-- [Steering Files](../.kiro/steering/) - sce steering templates
+- [Spec Workflow Guide](../.sce/specs/SPEC_WORKFLOW_GUIDE.md) - How to use Specs
+- [Steering Files](../.sce/steering/) - sce steering templates
 
 ---