scene-capability-engine 3.6.54 → 3.6.56

package/docs/examples/app-intent-phase1/.sce/app/scene-profiles/warehouse-tablet.json

@@ -0,0 +1,23 @@
+{
+  "workspace_id": "warehouse-tablet",
+  "name": "Warehouse Tablet Workspace",
+  "description": "Tablet-first warehouse workspace with scanning and receiving actions.",
+  "status": "active",
+  "tags": ["warehouse", "tablet"],
+  "collection_refs": ["warehouse-kiosk"],
+  "default_entry": "scan/inbound",
+  "layout_hint": "single-focus",
+  "items": [
+    {
+      "app_key": "notes",
+      "required": false,
+      "allow_local_remove": true,
+      "priority": 40,
+      "capability_tags": ["tablet"]
+    }
+  ],
+  "metadata": {
+    "persona": "warehouse-operator",
+    "device_type": "tablet"
+  }
+}

package/docs/examples/app-intent-phase1/README.md

@@ -0,0 +1,29 @@
+# App Intent Phase-1 Examples
+
+This folder provides copy-ready sample assets for the shipped phase-1 app intent model.
+
+It mirrors the canonical workspace layout:
+
+- `.sce/app/collections/*.json`
+- `.sce/app/scene-profiles/*.json`
+
+## Suggested usage
+
+Copy the example files you actually need into your project workspace:
+
+```bash
+mkdir -p .sce/app/collections .sce/app/scene-profiles
+cp docs/examples/app-intent-phase1/.sce/app/collections/*.json .sce/app/collections/
+cp docs/examples/app-intent-phase1/.sce/app/scene-profiles/*.json .sce/app/scene-profiles/
+```
+
+Then adapt:
+
+- `app_key`
+- `required`
+- `allow_local_remove`
+- `priority`
+- `capability_tags`
+- `default_entry`
+
+These are examples, not mandatory defaults. Do not copy them blindly without aligning them to the target business scene.

package/docs/magicball-app-collection-phase-1.md

@@ -0,0 +1,170 @@
+# MagicBall App Collection Phase 1
+
+## Status
+
+Shipped phase-1 baseline in SCE.
+
+Current shipped read-model baseline:
+
+- `sce device current`
+- `sce device override show`
+- `sce device override upsert`
+- `sce app collection list`
+- `sce app collection show`
+- `sce app collection apply` with plan-first diff and explicit execute for non-blocked install/uninstall actions
+- `sce app install-state list`
+- `sce scene workspace list`
+- `sce scene workspace show`
+- `sce scene workspace apply` with plan-first diff and explicit execute for non-blocked install/uninstall actions
+
+Current shipped runtime controls remain:
+
+- `sce app runtime show`
+- `sce app runtime releases`
+- `sce app runtime install`
+- `sce app runtime activate`
+- `sce app runtime uninstall`
+
+## Goal
+
+Add a scene-oriented installation model above the current single-app runtime controls so MagicBall can manage "what this workbench wants" separately from "what this device actually has installed".
+
+## Core decision
+
+SCE should split the model into two layers plus one local overlay:
+
+- intent layer: `app_collection` and `scene_profile`
+- device fact layer: `device_installation`
+- local override layer: `device_override`
+
+This means:
+
+- users or workspaces sync the desired app set
+- devices decide their own actual install set
+- one user on multiple devices does not get forced into identical installs
+
+## Why SCE should support this
+
+The current runtime commands are enough for single-app control, but they are not enough to express:
+
+- sales workbench vs planning workbench vs development workbench
+- device-specific install differences
+- reasoned batch install and uninstall planning
+
+Without this layer, frontend code has to invent business grouping and install logic outside SCE, which would fragment the contract.
+
+## Phase 1 scope
+
+Phase-1 should stay local-device-first.
+
+It should add:
+
+- current device identity and capability view
+- file-backed app collections
+- file-backed scene profiles
+- local install-state listing
+- collection or scene apply diff planning
+- explicit execute step for apply
+
+It should not require:
+
+- user account system
+- cross-device installation-state sync
+- organization policy rollout
+
+## Storage position
+
+SCE already has a selective SQLite policy. This capability should follow it.
+
+Recommended split:
+
+- shared intent stays file-backed or registry-backed
+- device facts and rebuildable resolution projections may use SQLite
+- local device override stays file-backed at `.sce/state/device/device-override.json`
+
+This boundary matters because SQLite is suitable for local query-heavy facts, but it should not become the only source of truth for portable shared intent.
+
+## Copy-ready examples
+
+Sample assets are available here:
+
+- `docs/examples/app-intent-phase1/.sce/app/collections/*.json`
+- `docs/examples/app-intent-phase1/.sce/app/scene-profiles/*.json`
+- `docs/examples/app-intent-phase1/README.md`
+
+These examples are intentionally realistic but still generic:
+
+- sales desktop workspace
+- planning desktop workspace
+- warehouse tablet workspace
+
+Use them as a starting point, then replace app keys and business metadata with project-specific values.
+
+## Recommended phase-1 command shape
+
+Phase-1 overall command surface:
+
+- `sce device current`
+- `sce device override show`
+- `sce device override upsert`
+- `sce app collection list`
+- `sce app collection show`
+- `sce app collection apply`
+- `sce app install-state list`
+- `sce scene workspace list`
+- `sce scene workspace show`
+- `sce scene workspace apply`
+
+Execution rule:
+
+- `apply` should return a plan or diff by default
+- actual mutation requires explicit execute confirmation
+- execute stays blocked when the plan still contains unresolved collections, missing app bundles, or active-release protection skips
+- resolution now also considers local `device_override` add/remove overlays and item-level `capability_tags`
+- local override updates now also have an explicit CLI governance surface instead of requiring manual file edits
+- execution should reuse the existing app runtime path
+
+JSON response contract:
+
+- `docs/app-intent-apply-contract.md`
+
+## Frontend implication for MagicBall
+
+MagicBall should keep using current per-app runtime controls until this phase ships.
+
+Today, MagicBall can already use:
+
+1. `sce device current` for current device identity and capability tags
+2. `sce device override show/upsert` for local per-device add/remove overlays
+3. `sce app collection list/show/apply` for file-backed shared collection intent and plan-first diff
+4. `sce scene workspace list/show/apply` for file-backed scene-profile intent and plan-first diff
+5. `sce app install-state list` for current cross-app installation projection
+6. existing per-app runtime controls for concrete runtime actions
+
+Once phase-1 lands, the preferred top-level interaction should become:
+
+1. pick a scene workspace or app collection
+2. inspect the proposed device diff
+3. explicitly apply the plan
+4. continue using per-app runtime controls for detail views
+
+## Phase 2 direction
+
+Phase-2 should be planned as lightweight user-intent sync, not as device-state sync.
+
+Recommended boundary:
+
+- sync shared `app_collection` / `scene_profile` selections or bindings
+- do not sync `device_installation` facts as the cross-device source of truth
+- keep `device_override` local unless a project explicitly introduces a higher-level policy mechanism
+
+Recommended deliverables for phase-2 planning:
+
+1. user binding model for scene/profile selection
+2. device-aware resolution order for `user intent + local override + capability tags`
+3. pull/push sync semantics with conflict visibility rather than silent overwrite
+4. explicit non-goal: do not force all devices into the same installed app set
+
+## Practical conclusion
+
+SCE should support this direction, but it should do so by extending the current app/runtime model rather than replacing it.

package/docs/magicball-cli-invocation-examples.md

@@ -21,6 +21,47 @@ Assume:
 
 ## 1. Workspace Bootstrap
 
+### 1.0 Read current device baseline
+```bash
+sce device current --json
+sce device override show --json
+sce app collection list --json
+sce app collection show --collection sales-workbench --json
+sce app collection apply --collection sales-workbench --json
+sce scene workspace list --json
+sce scene workspace show --workspace sales --json
+sce scene workspace apply --workspace sales --json
+sce app install-state list --json
+```
+
+Expected use:
+- cache current device id / tags
+- load file-backed shared app collection intent
+- load file-backed shared scene workspace intent
+- render cross-app local install baseline before scene-oriented collection flows arrive
+
+Optional local override input:
+- `.sce/state/device/device-override.json`
+- use this for per-device add/remove exceptions instead of mutating shared collection/workspace definitions
+- update it explicitly via `sce device override upsert --input <json> --json`
+- copy-ready collection/workspace examples live under `docs/examples/app-intent-phase1/.sce/app/...`
+
+Example local override patch:
+```json
+{
+  "removed_apps": ["crm"],
+  "added_apps": [
+    {
+      "app_key": "notes",
+      "required": false
+    }
+  ],
+  "metadata": {
+    "reason": "tablet kiosk profile"
+  }
+}
+```
+
 ### 1.1 App bundle identity
 ```bash
 sce app bundle show --app customer-order-demo --json

package/docs/magicball-integration-doc-index.md

@@ -14,6 +14,8 @@ It is a navigation layer, not a new source of truth.
 
 These are the current first-line integration documents:
 - `docs/magicball-sce-adaptation-guide.md`
+- `docs/magicball-app-collection-phase-1.md`
+- `docs/app-intent-apply-contract.md`
 - `docs/magicball-ui-surface-checklist.md`
 - `docs/magicball-mode-home-and-ontology-empty-state-playbook.md`
 - `docs/magicball-frontend-state-and-command-mapping.md`
@@ -32,28 +34,36 @@ These are the current first-line integration documents:
    - implementation checklist
    - milestone-oriented execution order
 
-3. `docs/magicball-mode-home-and-ontology-empty-state-playbook.md`
+3. `docs/magicball-app-collection-phase-1.md`
+   - current device / collection / workspace / override baseline
+   - shipped phase-1 install orchestration contract
+
+4. `docs/app-intent-apply-contract.md`
+   - stable JSON response contract for `collection apply` and `scene workspace apply`
+   - execution/blocking/preflight semantics
+
+5. `docs/magicball-mode-home-and-ontology-empty-state-playbook.md`
    - two active frontend-sensitive defaults
    - serialized mode-home loading
    - ontology empty-state and starter-seed behavior
 
-4. `docs/magicball-frontend-state-and-command-mapping.md`
+6. `docs/magicball-frontend-state-and-command-mapping.md`
    - page state ownership
    - command-to-action mapping
    - error and retry boundaries
 
-5. `docs/magicball-write-auth-adaptation-guide.md`
+7. `docs/magicball-write-auth-adaptation-guide.md`
    - write authorization and lease handling
 
-6. `docs/magicball-task-feedback-timeline-guide.md`
+8. `docs/magicball-task-feedback-timeline-guide.md`
    - task feedback cards
    - timeline view integration
 
-7. `docs/magicball-cli-invocation-examples.md`
+9. `docs/magicball-cli-invocation-examples.md`
    - copy-ready CLI examples
    - wrapper and smoke verification patterns
 
-8. `docs/magicball-integration-issue-tracker.md`
+10. `docs/magicball-integration-issue-tracker.md`
    - current cross-project truth
    - only open issues, active decisions, and verified resolutions
 
@@ -62,6 +72,8 @@ These are the current first-line integration documents:
 ### I need to bootstrap the three-mode app shell
 Use:
 - `docs/magicball-sce-adaptation-guide.md`
+- `docs/magicball-app-collection-phase-1.md`
+- `docs/app-intent-apply-contract.md`
 - `docs/magicball-mode-home-and-ontology-empty-state-playbook.md`
 - `docs/magicball-frontend-state-and-command-mapping.md`
 
@@ -95,6 +107,8 @@ Use:
 | Document | Role | Should change often? |
 | --- | --- | --- |
 | `magicball-sce-adaptation-guide.md` | main overview | low |
+| `magicball-app-collection-phase-1.md` | next-phase install model | medium |
+| `app-intent-apply-contract.md` | apply JSON contract | medium |
 | `magicball-adaptation-task-checklist-v1.md` | execution checklist | medium |
 | `magicball-mode-home-and-ontology-empty-state-playbook.md` | frontend behavior policy | medium |
 | `magicball-frontend-state-and-command-mapping.md` | frontend implementation mapping | medium |
@@ -127,6 +141,7 @@ As of the current tracker state:
 - fresh ontology pages use `fallback + optional seed apply`
 - seed apply stays explicit and user-triggered
 - command failures should be preserved in copyable form for AI-assisted diagnosis
+- app installation orchestration should use `scene_profile` and `app_collection` intent, not a global identical install set
 
 ## Maintenance Rule
 

package/docs/magicball-integration-issue-tracker.md

@@ -17,7 +17,11 @@
 ### Current SCE capabilities ready for MagicBall integration
 
 SCE changes completed and now available for MagicBall:
+- `device current`
 - `app bundle` registry local state and CLI
+- `app collection list/show/apply`
+- `scene workspace list/show/apply`
+- `app install-state list`
 - `mode application home --app ... --json`
 - `mode ontology home --app ... --json`
 - `mode engineering home --app ... --json`
@@ -32,9 +36,10 @@ SCE changes completed and now available for MagicBall:
 
 ### Current recommended MagicBall consumption order
 1. consume `mode * home` as the top-level source for the three modes
-2. consume `pm`, `ontology`, and `assurance` table payloads
-3. wire runtime install/activate/uninstall and engineering attach/hydrate/activate actions
-4. use demo app: `customer-order-demo`
+2. consume `device current`, `app collection list/show/apply`, `scene workspace list/show/apply`, and `app install-state list` as the local device/install baseline
+3. consume `pm`, `ontology`, and `assurance` table payloads
+4. wire runtime install/activate/uninstall and engineering attach/hydrate/activate actions
+5. use demo app: `customer-order-demo`
 
 ### Related SCE docs
 - `docs/magicball-sce-adaptation-guide.md`
@@ -65,6 +70,11 @@ SCE changes completed and now available for MagicBall:
    - expected payload
    - UI impact
 
+### Cross-project decision recorded
+- The next install-management phase should not use a single global install set.
+- SCE will separate shared app intent from local device installation facts.
+- Planned phase-1 capability is documented in `docs/magicball-app-collection-phase-1.md`.
+
 ## Open Items
 
 ### Issue 001: SQLite lock when frontend triggers multiple SCE projection commands concurrently
@@ -153,6 +163,35 @@ Status:
 - local verification covered: `triad summary` empty -> `seed list/show` preview -> `seed apply` -> `triad summary` ready
 - keep open until broader field verification confirms the UX is stable
 
+### Issue 006: scene-profile and app-collection install orchestration is not yet command-ready
+
+Context:
+- MagicBall now needs a scene-oriented install-management model above current per-app runtime controls.
+- Current SCE already supports per-app runtime install, activate, uninstall, but not shared app intent vs device fact resolution.
+
+Cross-project decision:
+- Do not model this as one global install set shared blindly across devices.
+- Separate:
+  - shared intent: `app_collection`, `scene_profile`
+  - local fact: `device_installation`
+  - local override: `device_override`
+- Keep shared intent file-backed or registry-backed.
+- Use SQLite only for local facts and rebuildable projections.
+- `apply` must be plan-first and require explicit execution confirmation.
+
+Reference:
+- `docs/magicball-app-collection-phase-1.md`
+- `.sce/specs/128-00-app-collection-scene-profile-device-installation/`
+
+Status:
+- architecture decision aligned
+- spec added in SCE
+- read-model and plan-first diff commands implemented
+- explicit execute path now implemented for non-blocked install/uninstall actions
+- execute remains blocked when unresolved collections, missing app bundles, or active-release protection skips are present
+- local `device_override` file is now respected during resolution, so per-device add/remove exceptions no longer require mutating shared intent definitions
+- local `device_override` now also has explicit `show/upsert` command support, so frontend or operator flows no longer need to hand-edit the override file
+
 ## Resolved
 
 ### Issue 002: pm requirement upsert succeeds but requirement list still returns empty

package/docs/magicball-sce-adaptation-guide.md

@@ -12,6 +12,8 @@ Implementation detail should live in the specialized documents listed below.
 
 Use these documents together:
 - `docs/magicball-integration-doc-index.md`
+- `docs/magicball-app-collection-phase-1.md`
+- `docs/app-intent-apply-contract.md`
 - `docs/magicball-ui-surface-checklist.md`
 - `docs/magicball-mode-home-and-ontology-empty-state-playbook.md`
 - `docs/magicball-frontend-state-and-command-mapping.md`
@@ -23,15 +25,41 @@ Use these documents together:
 ## Current Scope
 
 SCE currently provides MagicBall-facing support for:
-1. `app bundle registry`
-2. `application / ontology / engineering home projections`
-3. `app runtime install / activate / uninstall`
-4. `app engineering attach / hydrate / activate`
-5. `pm` delivery data plane
-6. `ontology` triad data plane
-7. `assurance` data plane
-8. `write authorization`
-9. `task feedback + timeline`
+1. `device current` identity read model
+2. `device override show/upsert` local overlay governance
+3. `app bundle registry`
+4. `app collection list/show/apply` with plan-first diff and guarded explicit execution
+5. `scene workspace list/show/apply` with plan-first diff and guarded explicit execution
+6. `app install-state` local device projection
+7. `application / ontology / engineering home projections`
+8. `app runtime install / activate / uninstall`
+9. `app engineering attach / hydrate / activate`
+10. `pm` delivery data plane
+11. `ontology` triad data plane
+12. `assurance` data plane
+13. `write authorization`
+14. `task feedback + timeline`
+
+## Planned Next Scope
+
+The next planned SCE capability line for MagicBall is lightweight cross-device sync and richer collection resolution above the current shipped local-device-first baseline.
+
+Planned model split:
+- `app_collection` and `scene_profile` as shared intent
+- `device_installation` as local device fact
+- `device_override` as local device overlay
+
+Planned phase-1 position:
+- local device-first
+- file-backed shared intent
+- SQLite only for local facts and rebuildable projections
+- `apply` must be plan-first, not blind mutation
+- local device override is file-backed and applied during collection/workspace resolution
+- local device override mutation now uses explicit CLI upsert rather than manual-only file editing
+
+Reference:
+- `docs/magicball-app-collection-phase-1.md`
+- `docs/app-intent-apply-contract.md`
 
 ## Core Integration Positioning
 
@@ -100,6 +128,7 @@ Use `docs/magicball-cli-invocation-examples.md` for copy-ready commands.
 - `sce app engineering show`
 
 ### Runtime and engineering control
+- `sce device override show/upsert`
 - `sce app runtime show/releases/install/activate/uninstall`
 - `sce app engineering show/attach/hydrate/activate`
 - `sce app registry status/configure/sync*`

package/docs/releases/README.md

@@ -9,6 +9,9 @@ This directory stores release-facing documents:
 ## Archived Versions
 
 - [Release checklist](../release-checklist.md)
+- [v3.6.56 release notes](./v3.6.56.md)
+- [v3.6.55 release notes](./v3.6.55.md)
+- [v3.6.54 release notes](./v3.6.54.md)
 - [v3.6.48 release notes](./v3.6.48.md)
 - [v3.6.47 release notes](./v3.6.47.md)
 - [v3.6.46 release notes](./v3.6.46.md)

package/docs/releases/v3.6.55.md

@@ -0,0 +1,18 @@
+# v3.6.55 Release Notes
+
+Release date: 2026-03-16
+
+## Highlights
+
+- Added explicit local device override governance commands: `sce device override show` and `sce device override upsert --input <json>`.
+- Scene-oriented install planning now keeps `device_override` mutation on one conservative path instead of requiring manual file edits or introducing a parallel state mechanism.
+- `device_override` updates now merge only explicitly provided fields, which aligns with the SCE core rule against blind replacement and preserves unrelated local device policy state.
+
+## Validation
+
+- `npx jest tests/unit/commands/device-and-install-state.test.js tests/unit/commands/scene-workspace.test.js tests/unit/commands/app-mode.test.js --runInBand`
+- `node scripts/release-doc-version-audit.js --fail-on-error`
+
+## Release Notes
+
+- This patch closes the last obvious usability gap in the phase-1 MagicBall install-management baseline. Shared intent, local device facts, and local override policy were already modeled, but local override updates still depended on hand-editing JSON. `3.6.55` makes that layer governable through the CLI while keeping the same single source of truth and conservative merge semantics.

package/docs/releases/v3.6.56.md

@@ -0,0 +1,19 @@
+# v3.6.56 Release Notes
+
+Release date: 2026-03-17
+
+## Highlights
+
+- Added read-only `sce spec strategy assess` to decide whether a problem should stay `single-spec` or escalate to `multi-spec-program` / `research-program`.
+- Added a formal strategy Spec for complex-problem program escalation so SCE can stop forcing highly entangled work through one oversized Spec.
+- Added copy-ready phase-1 app intent examples plus a stable `apply` JSON contract document so scene-oriented install management can be adopted directly instead of inferred from source code.
+
+## Validation
+
+- `npx jest tests/unit/commands/spec-strategy.test.js --runInBand`
+- `node bin/sce.js --skip-steering-check --no-version-check spec strategy assess --goal "fix login button alignment in application home page" --json`
+- `node scripts/release-doc-version-audit.js --fail-on-error`
+
+## Release Notes
+
+- This patch turns SCE's existing multi-Spec and close-loop-program runtime into a better governed path for complex work. The key addition is not another executor, but an explicit strategy assessment layer that can say when one Spec is still enough and when the problem should first be treated as a coordinated program or a research-first clarification portfolio.

package/docs/spec-workflow.md

@@ -115,6 +115,46 @@ sce spec domain validate --spec <spec-id> --fail-on-gap --json
 
 This is the default way to avoid wrong-direction implementation and to force evidence-based correction loops.
 
+## When One Spec Is Not Enough
+
+Not every problem should be forced into a single Spec.
+
+Use this rule of thumb:
+
+- simple problem: stay with one Spec
+- medium complexity: split into a few implementation Specs and use orchestrate mode
+- very complex problem: first treat it as a program, not as a single implementation Spec
+
+Typical escalation signals:
+
+- one Spec keeps expanding but still cannot produce stable executable tasks
+- the problem spans multiple scenes, roles, or bounded contexts
+- API/data contracts are still unclear enough that task breakdown would be guesswork
+- business rules and policy boundaries are not yet settled
+- a single problem-domain chain already shows multiple semi-independent clusters
+
+Current SCE execution paths you can already use:
+
+```bash
+# read-only strategy assessment
+sce spec strategy assess --goal "broad complex goal" --json
+
+# multi-spec implementation program
+sce spec bootstrap --specs "spec-a,spec-b" --max-parallel 3
+
+# broad goal -> autonomous master/sub program decomposition
+sce auto close-loop-program "broad complex goal" --program-goals 4 --json
+```
+
+The strategic gap currently being formalized is:
+
+- how SCE should assess this threshold explicitly
+- when it should recommend `single-spec` vs `multi-spec-program` vs `research-program`
+
+Reference Spec:
+
+- `.sce/specs/129-00-complex-problem-program-escalation/`
+
 ---
 
 ## Stage 1: Requirements

package/docs/zh/releases/README.md

@@ -9,6 +9,9 @@
 ## 历史版本归档
 
 - [发布检查清单](../release-checklist.md)
+- [v3.6.56 发布说明](./v3.6.56.md)
+- [v3.6.55 发布说明](./v3.6.55.md)
+- [v3.6.54 发布说明](./v3.6.54.md)
 - [v3.6.48 发布说明](./v3.6.48.md)
 - [v3.6.47 发布说明](./v3.6.47.md)
 - [v3.6.46 发布说明](./v3.6.46.md)

package/docs/zh/releases/v3.6.55.md

@@ -0,0 +1,18 @@
+# v3.6.55 发布说明
+
+发布日期：2026-03-16
+
+## 重点变化
+
+- 新增显式的本地设备覆盖治理命令：`sce device override show` 和 `sce device override upsert --input <json>`。
+- 面向场景的安装规划现在把 `device_override` 的修改也收敛到统一治理路径，不再依赖手工改 JSON，也没有再引入并行状态机制。
+- `device_override` 更新采用“只合并明确给出的字段”的保守语义，符合 SCE 的“禁止盲改/禁止盲替换”核心原则，并保留未触及的本地设备策略状态。
+
+## 验证
+
+- `npx jest tests/unit/commands/device-and-install-state.test.js tests/unit/commands/scene-workspace.test.js tests/unit/commands/app-mode.test.js --runInBand`
+- `node scripts/release-doc-version-audit.js --fail-on-error`
+
+## 发布说明
+
+- 这个补丁版把 MagicBall phase-1 安装管理基线里最后一个明显缺口补上了。共享意图、本地设备事实和本地覆盖策略此前都已经建模完成，但本地覆盖更新仍依赖手工改 JSON。`3.6.55` 把这层能力补成了可治理的 CLI 命令，同时继续保持单一事实来源和保守合并语义。

package/docs/zh/releases/v3.6.56.md

@@ -0,0 +1,19 @@
+# v3.6.56 发布说明
+
+发布日期：2026-03-17
+
+## 重点变化
+
+- 新增只读命令 `sce spec strategy assess`，用于判断问题应继续使用 `single-spec`，还是升级为 `multi-spec-program` / `research-program`。
+- 新增复杂问题升级策略 Spec，使 SCE 不再默认把高度纠缠的问题硬塞进一个超大 Spec。
+- 补充 phase-1 应用意图样例与稳定的 `apply` JSON 契约文档，让面向场景的安装管理能力可以直接落地，而不是只能靠读源码理解。
+
+## 验证
+
+- `npx jest tests/unit/commands/spec-strategy.test.js --runInBand`
+- `node bin/sce.js --skip-steering-check --no-version-check spec strategy assess --goal "fix login button alignment in application home page" --json`
+- `node scripts/release-doc-version-audit.js --fail-on-error`
+
+## 发布说明
+
+- 这个补丁版的重点不是再造一个执行器，而是给 SCE 已有的多 Spec / close-loop-program 执行能力补上策略层。现在 SCE 可以更明确地判断：一个问题是否还适合留在单 Spec，还是应该先升级为协调型 program，或者先进入 research-first 的澄清拆分路径。