scene-capability-engine 3.6.32 → 3.6.37

package/docs/magicball-write-auth-adaptation-guide.md

@@ -0,0 +1,328 @@
+# MagicBall Write Auth Adaptation Guide
+
+## Goal
+
+Define how MagicBall should adapt to SCE write-authorization requirements.
+
+This guide focuses on:
+1. which actions require authorization
+2. how MagicBall should request or reuse a lease
+3. how to pass lease information to SCE
+4. how to handle denied / expired / invalid lease errors
+
+This guide is intentionally frontend-oriented.
+
+## Current SCE Authorization Model
+
+SCE uses a write-authorization layer centered on:
+- policy file: `.sce/config/authorization-policy.json`
+- lease storage: `.sce/state/sce-state.sqlite`
+- commands:
+  - `sce auth grant`
+  - `sce auth status`
+  - `sce auth revoke`
+
+The runtime enforcement entry is:
+- `ensureWriteAuthorization(...)`
+
+## What MagicBall Should Assume By Default
+
+MagicBall should assume:
+1. read operations do not require lease
+2. write operations may require lease
+3. the exact enforcement depends on SCE policy
+4. frontend must not guess policy internals from static assumptions
+
+Therefore, MagicBall should design write flows as:
+- optimistic if lease exists
+- blocked-with-guidance if lease is missing or invalid
+
+## SCE Commands Relevant To Auth
+
+### Grant lease
+```bash
+sce auth grant --scope <scope> --reason "<reason>" --json
+```
+
+### Inspect lease status
+```bash
+sce auth status --json
+sce auth status --lease <lease-id> --json
+```
+
+### Revoke lease
+```bash
+sce auth revoke --lease <lease-id> --json
+```
+
+## Scopes MagicBall Should Care About
+
+Current implemented write flows in SCE imply these practical action families:
+
+### App / mode related
+- `app:bundle:register`
+- `app:registry:configure`
+- `app:engineering:attach`
+- `app:engineering:hydrate`
+- `app:engineering:activate`
+- `app:runtime:install`
+- `app:runtime:activate`
+
+### Engineering mode PM data plane
+- `pm:requirement:upsert`
+- `pm:tracking:upsert`
+- `pm:planning:upsert`
+- `pm:change:upsert`
+- `pm:issue:upsert`
+
+### Ontology mode data plane
+- `ontology:er:upsert`
+- `ontology:br:upsert`
+- `ontology:dl:upsert`
+
+### Existing studio/task actions
+- `studio:apply`
+- `studio:release`
+- `studio:rollback`
+- `task:rerun`
+
+## Recommended MagicBall UI Rule
+
+### Rule 1
+Treat all mutating actions as lease-aware actions.
+
+### Rule 2
+Do not hide all write buttons permanently.
+Instead:
+- show action button
+- if no valid lease is present, show locked state or auth prompt before execution
+
+### Rule 3
+For dangerous write actions, require an explicit authorization step even if the button is visible.
+
+## Recommended Frontend State Model
+
+MagicBall should keep a lightweight authorization state model:
+
+```ts
+interface WriteLeaseState {
+  leaseId: string | null
+  subject: string | null
+  role: string | null
+  scope: string[]
+  expiresAt: string | null
+  revokedAt: string | null
+  active: boolean
+  stale: boolean
+}
+```
+
+Recommended derived flags:
+- `hasLease`
+- `leaseActive`
+- `leaseExpired`
+- `scopeSatisfied(action)`
+
+## Recommended Frontend Flow
+
+### 1. Startup / app switch
+When MagicBall starts or switches app/project context:
+1. call `sce auth status --json`
+2. cache active leases
+3. derive whether current user/session can write
+
+### 2. Before a write action
+When user clicks a write action:
+1. map UI action to SCE action scope
+2. check local cached lease state
+3. if lease exists and scope matches, execute command with `--auth-lease <lease-id>`
+4. if lease missing or insufficient, open auth prompt flow
+
+### 3. Auth prompt flow
+Recommended UI steps:
+1. show why authorization is required
+2. show requested action scope
+3. ask user to authorize
+4. execute `sce auth grant ... --json`
+5. cache returned `lease_id`
+6. retry original write action with `--auth-lease`
+
+## Suggested UI Copy Pattern
+
+### Locked action hint
+- `This action requires SCE write authorization.`
+- `Requested scope: pm:requirement:upsert`
+
+### Grant dialog content
+- `Action`: human-readable action name
+- `Requested scope`: exact SCE scope string
+- `Reason`: user-editable reason text
+- `Password`: if needed by policy
+
+### Success hint
+- `Write authorization granted for 15 minutes.`
+
+### Failure hint
+- `Authorization failed. Check password, lease policy, or requested scope.`
+
+## Recommended Scope Mapping Table
+
+| MagicBall UI action | SCE command | Required scope |
+| --- | --- | --- |
+| Save app bundle | `sce app bundle register` | `app:bundle:register` |
+| Update registry config | `sce app registry configure` | `app:registry:configure` |
+| Attach engineering project | `sce app engineering attach` | `app:engineering:attach` |
+| Hydrate engineering workspace | `sce app engineering hydrate` | `app:engineering:hydrate` |
+| Activate engineering workspace | `sce app engineering activate` | `app:engineering:activate` |
+| Install runtime release | `sce app runtime install` | `app:runtime:install` |
+| Activate runtime release | `sce app runtime activate` | `app:runtime:activate` |
+| Save requirement | `sce pm requirement upsert` | `pm:requirement:upsert` |
+| Save tracking item | `sce pm tracking upsert` | `pm:tracking:upsert` |
+| Save plan | `sce pm planning upsert` | `pm:planning:upsert` |
+| Save change request | `sce pm change upsert` | `pm:change:upsert` |
+| Save issue item | `sce pm issue upsert` | `pm:issue:upsert` |
+| Save ER asset | `sce ontology er upsert` | `ontology:er:upsert` |
+| Save BR rule | `sce ontology br upsert` | `ontology:br:upsert` |
+| Save DL chain | `sce ontology dl upsert` | `ontology:dl:upsert` |
+| Apply studio change | `sce studio apply` | `studio:apply` |
+| Release studio result | `sce studio release` | `studio:release` |
+| Rollback studio result | `sce studio rollback` | `studio:rollback` |
+| Rerun task | `sce task rerun` | `task:rerun` |
+
+## Recommended Grant Command Patterns
+
+### Generic lease
+```bash
+sce auth grant --scope app:runtime:activate --reason "activate selected runtime release" --json
+```
+
+### Multiple scopes if one workflow batches mutations
+```bash
+sce auth grant --scope app:engineering:attach,app:engineering:hydrate,app:engineering:activate --reason "initialize engineering workspace" --json
+```
+
+## How MagicBall Should Pass Lease To SCE
+
+For every write command, pass:
+- `--auth-lease <lease-id>`
+
+Example:
+```bash
+sce pm requirement upsert --input requirement.json --auth-lease <lease-id> --json
+```
+
+## Error Handling Rules
+
+MagicBall should not treat all write failures the same.
+
+### Case A: lease required
+Typical symptom:
+- error mentions `Write authorization required`
+- or says lease is required for action
+
+Frontend action:
+1. keep form state intact
+2. open authorization prompt
+3. let user retry after grant
+
+### Case B: lease not found
+Typical symptom:
+- error mentions `lease not found`
+
+Frontend action:
+1. clear cached lease id
+2. force refresh auth status
+3. reopen grant flow
+
+### Case C: lease expired / revoked
+Typical symptom:
+- error mentions expired / revoked / inactive lease
+
+Frontend action:
+1. mark local lease stale
+2. force refresh auth status
+3. ask user to grant again
+
+### Case D: scope mismatch
+Typical symptom:
+- authorization denied for action despite active lease
+
+Frontend action:
+1. show requested scope
+2. request a new lease with broader or correct scope
+
+### Case E: business validation error
+Typical symptom:
+- payload/field/schema validation failure
+- no auth wording in error message
+
+Frontend action:
+1. do not reopen auth flow
+2. keep current form state
+3. show validation feedback only
+
+## Recommended Frontend State Machine
+
+```text
+idle
+  -> checking_lease
+  -> lease_ready
+  -> lease_missing
+  -> requesting_lease
+  -> lease_granted
+  -> executing_write
+  -> write_succeeded
+  -> write_failed_auth
+  -> write_failed_validation
+```
+
+## Minimal Frontend Implementation Checklist
+
+### Required now
+1. local lease cache
+2. `auth status` fetch on startup / app switch
+3. action-to-scope mapping table
+4. shared auth prompt dialog
+5. automatic retry of blocked action after successful grant
+
+### Can wait
+1. lease auto-refresh before expiry
+2. batch lease orchestration for multi-step workflows
+3. lease history panel
+4. revoke button in UI
+
+## Recommended MagicBall Button Policy
+
+### Safe read-only buttons
+- always enabled
+
+### Write buttons with no lease
+- visible
+- disabled or soft-blocked
+- click opens auth dialog
+
+### Write buttons with valid lease
+- enabled
+- execute command with `--auth-lease`
+
+### High-risk buttons
+Examples:
+- runtime activate
+- engineering activate
+- studio release
+- backup restore
+
+Recommended behavior:
+- keep visible
+- require explicit confirmation even with valid lease
+
+## Practical Conclusion
+
+MagicBall should now implement write authorization as a shared UI capability, not as page-by-page special handling.
+
+The most important thing is:
+- centralize scope mapping
+- centralize lease state
+- centralize retry-after-grant flow
+
+That will keep all app/runtime/pm/ontology/studio write flows consistent.

package/docs/moqui-standard-rebuild-guide.md

@@ -84,12 +84,12 @@ Defaults: `ready>=6`, `partial<=0`, `gap<=0`.
 
 ## Default Moqui Template Matrix
 
-- `kse.scene--moqui-entity-model-core--0.1.0`
-- `kse.scene--moqui-service-contract-core--0.1.0`
-- `kse.scene--moqui-screen-flow-core--0.1.0`
-- `kse.scene--moqui-form-interaction-core--0.1.0`
-- `kse.scene--moqui-rule-decision-core--0.1.0`
-- `kse.scene--moqui-page-copilot-dialog--0.1.0`
+- `sce.scene--moqui-entity-model-core--0.1.0`
+- `sce.scene--moqui-service-contract-core--0.1.0`
+- `sce.scene--moqui-screen-flow-core--0.1.0`
+- `sce.scene--moqui-form-interaction-core--0.1.0`
+- `sce.scene--moqui-rule-decision-core--0.1.0`
+- `sce.scene--moqui-page-copilot-dialog--0.1.0`
 
 ## Next Step for Business Project
 

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

@@ -201,7 +201,7 @@ sce auto close-loop-batch .sce/auto/ontology-remediation.lines --format lines --
 
 Stage-D baseline package for the interactive business customization loop:
 
-- `kse.scene--moqui-interactive-customization-loop--0.1.0`
+- `sce.scene--moqui-interactive-customization-loop--0.1.0`
 
 This package captures:
 

package/docs/refactor-completion-roadmap.md

@@ -0,0 +1,116 @@
+# Refactor Completion And Next Roadmap
+
+## Scope
+
+This document records the completion state of the `3.6.33` refactor round and defines the next engineering direction.
+
+Current stable commits:
+
+- `0c9594d` `refactor(auto): finalize close-loop governance split and docs refresh`
+- `0fb49b7` `refactor(handoff): extract capability matrix service`
+- `8ebc5bc` `release: 3.6.33`
+
+## What Is Considered Done
+
+This refactor round is considered complete because the main autonomous delivery chain is no longer centered in `lib/commands/auto.js`.
+
+Completed extractions:
+
+- `lib/auto/close-loop-controller-service.js`
+- `lib/auto/close-loop-batch-service.js`
+- `lib/auto/close-loop-program-service.js`
+- `lib/auto/observability-service.js`
+- `lib/auto/program-summary.js`
+- `lib/auto/program-output.js`
+- `lib/auto/batch-output.js`
+- `lib/auto/program-governance-helpers.js`
+- `lib/auto/program-governance-loop-service.js`
+- `lib/auto/program-auto-remediation-service.js`
+- `lib/auto/output-writer.js`
+- `lib/auto/handoff-capability-matrix-service.js`
+
+Supporting cleanup completed in the same round:
+
+- README and docs hub restructuring
+- governance summary regression fix
+- governance weekly-ops session telemetry fix
+- session stats `criteria.days` fix
+
+## Resulting Architecture Shift
+
+Before this round:
+
+- `lib/commands/auto.js` contained both command registration and most major orchestration logic.
+- changes to program or governance behavior were high-risk because too many concerns were coupled.
+
+After this round:
+
+- `lib/commands/auto.js` is primarily a command-layer shell plus wrappers.
+- major delivery orchestration now lives under `lib/auto/`.
+- the first `auto-handoff` subdomain now has a dedicated service boundary.
+
+This is the practical reason the round is treated as complete even though `auto.js` is still large.
+
+## Why Some Work Was Explicitly Deferred
+
+Not every remaining function in `lib/commands/auto.js` should be extracted immediately.
+
+Deferred on purpose:
+
+- low-value helper moves with poor payoff
+- unstable `auto-handoff` micro-extractions that increased regression risk
+- cosmetic-only reductions that do not improve long-term maintainability
+
+The rule used during this round was:
+
+- keep extractions that create durable service boundaries
+- stop when the next move becomes lower value than the regression risk it introduces
+
+## Remaining High-Value Areas
+
+The next meaningful work is no longer the close-loop main path. It is concentrated in `auto-handoff` and a few release/governance support areas.
+
+Highest-value remaining themes:
+
+1. `auto-handoff` release evidence and history services
+2. `auto-handoff` release note / evidence review renderers
+3. `auto-handoff` baseline and coverage snapshot services
+4. final documentation and release process hardening
+
+## Recommended Next Round
+
+The next round should be treated as a focused `auto-handoff` refactor, not a continuation of generic `auto.js` cleanup.
+
+Recommended order:
+
+1. `release evidence` subdomain
+2. `release gate history` subdomain
+3. `release note / evidence review` rendering subdomain
+4. `baseline / coverage snapshot` subdomain
+
+Each subdomain should follow the same rule used in `3.6.33`:
+
+- extract one coherent service boundary
+- keep command behavior unchanged
+- require unit coverage for the new module
+- require guarded integration coverage before keeping the change
+
+## Validation Baseline
+
+The following checks were used to accept the current refactor round:
+
+- `npx jest tests/unit/auto --runInBand`
+- `npx jest tests/unit/commands/auto.test.js --runInBand`
+- `npx jest tests/integration/auto-close-loop-cli.integration.test.js tests/integration/version-cli.integration.test.js --runInBand`
+- `npm run test:release`
+
+Any next round should continue to use these as the minimum baseline.
+
+## Release Status
+
+Current stable release:
+
+- version: `3.6.33`
+- tag: `v3.6.33`
+
+This version is the baseline for future `auto-handoff` evolution.

package/docs/release-checklist.md

@@ -115,41 +115,48 @@ Verify:
 
 Ensure:
 
+- Release automation is tag-driven, not commit-driven:
+  - `.github/workflows/release.yml` only triggers on `push.tags: v*`
+  - plain `git push` runs normal CI and does not publish npm/GitHub release
+- GitHub Actions publish prerequisites are in place:
+  - repository secret `NPM_TOKEN` must exist and remain valid for `npm publish --access public`
+  - `GITHUB_TOKEN` is used by workflow for release asset/readback steps
 - `package.json` version is correct.
+- `package.json` version must be greater than the currently published npm version.
 - `CHANGELOG.md` includes release-relevant entries.
 - Release notes draft exists (for example `docs/releases/vX.Y.Z.md`).
 - Optional: configure release evidence gate with repository variables (`Settings -> Secrets and variables -> Actions -> Variables`):
-  - `KSE_RELEASE_GATE_ENFORCE`: `true|false` (default advisory, non-blocking)
-  - `KSE_RELEASE_GATE_REQUIRE_EVIDENCE`: require `handoff-runs.json` summary
-  - `KSE_RELEASE_GATE_REQUIRE_GATE_PASS`: require evidence gate `passed=true` (default true when evidence exists)
-  - `KSE_RELEASE_GATE_MIN_SPEC_SUCCESS_RATE`: minimum allowed success rate percent
-  - `KSE_RELEASE_GATE_MAX_RISK_LEVEL`: `low|medium|high|unknown` (default `unknown`)
-  - `KSE_RELEASE_GATE_MAX_UNMAPPED_RULES`: maximum allowed unmapped ontology business rules
-  - `KSE_RELEASE_GATE_MAX_UNDECIDED_DECISIONS`: maximum allowed undecided ontology decisions
-  - `KSE_RELEASE_GATE_REQUIRE_SCENE_BATCH_PASS`: require scene package publish-batch gate passed (`true|false`, default `true`)
-  - `KSE_RELEASE_GATE_MAX_SCENE_BATCH_FAILURES`: maximum allowed scene package batch failure count (default `0`)
+  - `SCE_RELEASE_GATE_ENFORCE`: `true|false` (default advisory, non-blocking)
+  - `SCE_RELEASE_GATE_REQUIRE_EVIDENCE`: require `handoff-runs.json` summary
+  - `SCE_RELEASE_GATE_REQUIRE_GATE_PASS`: require evidence gate `passed=true` (default true when evidence exists)
+  - `SCE_RELEASE_GATE_MIN_SPEC_SUCCESS_RATE`: minimum allowed success rate percent
+  - `SCE_RELEASE_GATE_MAX_RISK_LEVEL`: `low|medium|high|unknown` (default `unknown`)
+  - `SCE_RELEASE_GATE_MAX_UNMAPPED_RULES`: maximum allowed unmapped ontology business rules
+  - `SCE_RELEASE_GATE_MAX_UNDECIDED_DECISIONS`: maximum allowed undecided ontology decisions
+  - `SCE_RELEASE_GATE_REQUIRE_SCENE_BATCH_PASS`: require scene package publish-batch gate passed (`true|false`, default `true`)
+  - `SCE_RELEASE_GATE_MAX_SCENE_BATCH_FAILURES`: maximum allowed scene package batch failure count (default `0`)
 - Optional: tune release drift alerts in release notes:
   - Drift evaluation is executed by `scripts/release-drift-evaluate.js` in CI (history load, alert calc, gate report writeback, enforce exit code).
-  - `KSE_RELEASE_DRIFT_ENFORCE`: `true|false` (default `false`), block publish when drift alerts are triggered
-  - `KSE_RELEASE_DRIFT_FAIL_STREAK_MIN`: minimum consecutive failed gates to trigger alert (default `2`)
-  - `KSE_RELEASE_DRIFT_HIGH_RISK_SHARE_MIN_PERCENT`: minimum high-risk share in latest 5 versions (default `60`)
-  - `KSE_RELEASE_DRIFT_HIGH_RISK_SHARE_DELTA_MIN_PERCENT`: minimum short-vs-long high-risk share delta (default `25`)
-  - `KSE_RELEASE_DRIFT_PREFLIGHT_BLOCK_RATE_MIN_PERCENT`: minimum release preflight blocked rate in latest 5 known runs (default `40`)
-  - `KSE_RELEASE_DRIFT_HARD_GATE_BLOCK_STREAK_MIN`: minimum consecutive hard-gate preflight blocked streak (latest window, default `2`)
-  - `KSE_RELEASE_DRIFT_PREFLIGHT_UNAVAILABLE_STREAK_MIN`: minimum consecutive release preflight unavailable streak (latest window, default `2`)
+  - `SCE_RELEASE_DRIFT_ENFORCE`: `true|false` (default `false`), block publish when drift alerts are triggered
+  - `SCE_RELEASE_DRIFT_FAIL_STREAK_MIN`: minimum consecutive failed gates to trigger alert (default `2`)
+  - `SCE_RELEASE_DRIFT_HIGH_RISK_SHARE_MIN_PERCENT`: minimum high-risk share in latest 5 versions (default `60`)
+  - `SCE_RELEASE_DRIFT_HIGH_RISK_SHARE_DELTA_MIN_PERCENT`: minimum short-vs-long high-risk share delta (default `25`)
+  - `SCE_RELEASE_DRIFT_PREFLIGHT_BLOCK_RATE_MIN_PERCENT`: minimum release preflight blocked rate in latest 5 known runs (default `40`)
+  - `SCE_RELEASE_DRIFT_HARD_GATE_BLOCK_STREAK_MIN`: minimum consecutive hard-gate preflight blocked streak (latest window, default `2`)
+  - `SCE_RELEASE_DRIFT_PREFLIGHT_UNAVAILABLE_STREAK_MIN`: minimum consecutive release preflight unavailable streak (latest window, default `2`)
 - Optional: tune weekly ops release gate:
-  - `KSE_RELEASE_WEEKLY_OPS_ENFORCE`: `true|false` (default `true`)
-  - `KSE_RELEASE_WEEKLY_OPS_REQUIRE_SUMMARY`: require weekly summary artifact (`true|false`, default `true`)
-  - `KSE_RELEASE_WEEKLY_OPS_MAX_RISK_LEVEL`: `low|medium|high|unknown` (default `medium`)
-  - `KSE_RELEASE_WEEKLY_OPS_MAX_GOVERNANCE_BREACHES`: optional max breach count
-  - `KSE_RELEASE_WEEKLY_OPS_MAX_AUTHORIZATION_TIER_BLOCK_RATE_PERCENT`: max authorization-tier deny/review block rate percent (default `40`)
-  - `KSE_RELEASE_WEEKLY_OPS_MAX_DIALOGUE_AUTHORIZATION_BLOCK_RATE_PERCENT`: max dialogue-authorization block rate percent (default `40`)
-  - `KSE_RELEASE_WEEKLY_OPS_MAX_MATRIX_REGRESSION_RATE_PERCENT`: optional max regression-positive rate percent
+  - `SCE_RELEASE_WEEKLY_OPS_ENFORCE`: `true|false` (default `true`)
+  - `SCE_RELEASE_WEEKLY_OPS_REQUIRE_SUMMARY`: require weekly summary artifact (`true|false`, default `true`)
+  - `SCE_RELEASE_WEEKLY_OPS_MAX_RISK_LEVEL`: `low|medium|high|unknown` (default `medium`)
+  - `SCE_RELEASE_WEEKLY_OPS_MAX_GOVERNANCE_BREACHES`: optional max breach count
+  - `SCE_RELEASE_WEEKLY_OPS_MAX_AUTHORIZATION_TIER_BLOCK_RATE_PERCENT`: max authorization-tier deny/review block rate percent (default `40`)
+  - `SCE_RELEASE_WEEKLY_OPS_MAX_DIALOGUE_AUTHORIZATION_BLOCK_RATE_PERCENT`: max dialogue-authorization block rate percent (default `40`)
+  - `SCE_RELEASE_WEEKLY_OPS_MAX_MATRIX_REGRESSION_RATE_PERCENT`: optional max regression-positive rate percent
   - Invalid numeric values are reported as gate `config_warnings` and default threshold fallback is applied.
 - Optional: tune release asset integrity gate:
-  - `KSE_RELEASE_ASSET_INTEGRITY_ENFORCE`: `true|false` (default `true`)
-  - `KSE_RELEASE_ASSET_INTEGRITY_REQUIRE_NON_EMPTY`: `true|false` (default `true`)
-  - `KSE_RELEASE_ASSET_INTEGRITY_REQUIRED_FILES`: override required asset list (comma-separated, supports `{tag}`)
+  - `SCE_RELEASE_ASSET_INTEGRITY_ENFORCE`: `true|false` (default `true`)
+  - `SCE_RELEASE_ASSET_INTEGRITY_REQUIRE_NON_EMPTY`: `true|false` (default `true`)
+  - `SCE_RELEASE_ASSET_INTEGRITY_REQUIRED_FILES`: override required asset list (comma-separated, supports `{tag}`)
 - 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:
@@ -159,4 +166,20 @@ Ensure:
 - Optional local dry-run for gate history index artifact:
   - `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).
+Then proceed with your release workflow:
+
+```bash
+# 1. bump version + commit first
+# 2. push branch changes
+git push origin main
+
+# 3. create and push release tag
+git tag vX.Y.Z
+git push origin vX.Y.Z
+```
+
+Expected:
+
+- `git push origin main` only runs normal CI.
+- `git push origin vX.Y.Z` triggers GitHub Actions `Release` workflow.
+- workflow publishes npm package and creates GitHub Release if all release gates pass.

package/docs/releases/README.md

@@ -9,6 +9,7 @@ This directory stores release-facing documents:
 ## Archived Versions
 
 - [Release checklist](../release-checklist.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)
 - [GitHub Releases](https://github.com/heguangyong/scene-capability-engine/releases) (latest)

package/docs/releases/v3.6.37.md

@@ -0,0 +1,22 @@
+# v3.6.37 Release Notes
+
+Release date: 2026-03-12
+
+## Highlights
+
+- Removed legacy `kse` command/content references from active runtime paths, templates, fixtures, and release-facing documentation without keeping a compatibility bridge.
+- Standardized scene package/template metadata and fixture paths on `sce` naming so generated artifacts no longer leak old `kse` identifiers.
+- Fixed Windows release preflight for `scripts/git-managed-gate.js` by adding `git.cmd` / `git.exe` fallback resolution.
+- Documented the actual release trigger model: only `v*` tag pushes trigger GitHub Actions release publishing, and workflow publishing depends on repository secret `NPM_TOKEN`.
+
+## Verification
+
+- `npx jest tests/unit/workspace/workspace-context-resolver.test.js tests/unit/workspace/workspace-state-manager.test.js tests/unit/steering/compliance-cache.test.js tests/unit/scripts/moqui-lexicon-audit.test.js tests/unit/scripts/moqui-standard-rebuild.test.js tests/unit/scripts/moqui-metadata-extract.test.js tests/unit/task/task-claimer.test.js tests/unit/commands/auto.test.js tests/integration/auto-close-loop-cli.integration.test.js --runInBand`
+- `node scripts/check-branding-consistency.js`
+- `npx jest tests/unit/scripts/git-managed-gate.test.js --runInBand`
+
+## Release Notes
+
+- Plain `git push` does not publish this project.
+- Release automation starts only when `git push origin vX.Y.Z` triggers `.github/workflows/release.yml`.
+- GitHub Actions publish requires repository secret `NPM_TOKEN`.

package/docs/steering-strategy-guide.md

@@ -64,14 +64,14 @@ Detect existing steering files
     │
     └─ Steering files found → Prompt for strategy
            ↓
-           ├─ use-kse → Backup existing → Install sce steering
+           ├─ use-sce → Backup existing → Install sce steering
            │
            └─ use-project → Keep existing → Skip sce steering
 ```
 
 ## Rollback
 
-If you chose "use-kse" and want to restore your original steering files:
+If you chose "use-sce" and want to restore your original steering files:
 
 ```bash
 # List available backups
@@ -100,7 +100,7 @@ Your steering strategy choice is saved in `.sce/adoption-config.json`:
 {
   "version": "1.0.0",
   "adoptedAt": "2026-01-23T10:00:00.000Z",
-  "steeringStrategy": "use-kse",
+  "steeringStrategy": "use-sce",
   "steeringBackupId": "steering-2026-01-23T10-00-00-000Z",
   "multiUserMode": false,
   "lastUpdated": "2026-01-23T10:00:00.000Z"
@@ -111,7 +111,7 @@ Your steering strategy choice is saved in `.sce/adoption-config.json`:
 
 ### For New sce Users
 
-1. **Choose "use-kse"** to get the full experience
+1. **Choose "use-sce"** to get the full experience
 2. Review the installed steering files to understand sce workflow
 3. Customize `ENVIRONMENT.md` for your project specifics
 4. Update `CURRENT_CONTEXT.md` as you work on different Specs
@@ -123,7 +123,7 @@ Your steering strategy choice is saved in `.sce/adoption-config.json`:
 3. Consider creating a hybrid approach:
    - Keep your core steering rules
    - Add sce-specific rules in separate files
-   - Use file naming to control load order (e.g., `00-core.md`, `10-kse.md`)
+   - Use file naming to control load order (e.g., `00-core.md`, `10-sce.md`)
 
 ### For Teams
 
@@ -138,13 +138,13 @@ Your steering strategy choice is saved in `.sce/adoption-config.json`:
 
 **Solution:**
 - Check which steering strategy you chose: `cat .sce/adoption-config.json`
-- If "use-kse", verify sce steering files are present
+- If "use-sce", verify sce steering files are present
 - If "use-project", ensure your steering files are compatible with sce
 
 ### Problem: Want to switch strategies after adoption
 
 **Solution:**
-1. If currently "use-kse":
+1. If currently "use-sce":
    ```bash
    sce rollback {steering-backup-id}
    ```

package/docs/troubleshooting.md

@@ -1045,7 +1045,7 @@ ls -la .sce/
 
 **4. Community:**
 - Discord: [Join our Discord](https://discord.gg/sce)
-- Twitter: [@kse_dev](https://twitter.com/kse_dev)
+- Twitter: [@sce_dev](https://twitter.com/sce_dev)
 
 ### Creating a Good Issue Report