Docs: refresh extension host migration status

docs/.internal/extension-host-migration/openclaw-capability-catalog-and-arbitration-spec.md

@@ -42,7 +42,7 @@ What has been implemented:
 - loader module-export resolution, config validation, and memory-slot load decisions now route through `src/extension-host/loader-runtime.ts`
 - loader post-import planning and `register(...)` execution now route through `src/extension-host/loader-register.ts`
 - loader per-candidate orchestration now routes through `src/extension-host/loader-flow.ts`
-- loader record-state transitions now route through `src/extension-host/loader-state.ts`
+- loader record-state transitions now route through `src/extension-host/loader-state.ts`, including explicit compatibility `lifecycleState` mapping
 - loader final cache, warning, and activation finalization now routes through `src/extension-host/loader-finalize.ts`
 - channel, provider, gateway-method, tool, CLI, service, command, context-engine, and hook registration normalization now has a host-owned helper boundary for future catalog migration
 
@@ -52,7 +52,7 @@ How it has been implemented:
 - by keeping the existing catalog behavior intact while shifting metadata ownership into normalized host-owned records
 - by reusing the resolved-extension registry for static operator/documentation surfaces instead of creating separate metadata caches
 - by beginning runtime registration migration with host-owned normalization helpers before attempting full canonical catalog publication
-- by beginning loader-path migration with host-owned compatibility, candidate-planning, import-flow, policy, runtime, register-flow, candidate-orchestration, record-state, and finalization helpers before attempting canonical catalog publication
+- by beginning loader-path migration with host-owned compatibility, candidate-planning, import-flow, policy, runtime, register-flow, candidate-orchestration, record-state with compatibility lifecycle mapping, and finalization helpers before attempting canonical catalog publication
 
 What remains pending:
 

docs/.internal/extension-host-migration/openclaw-extension-contribution-schema-spec.md

@@ -46,7 +46,7 @@ What has been implemented:
 - loader module-export resolution, config validation, and memory-slot load decisions now route through `src/extension-host/loader-runtime.ts`
 - loader post-import planning and `register(...)` execution now route through `src/extension-host/loader-register.ts`
 - loader per-candidate orchestration now routes through `src/extension-host/loader-flow.ts`
-- loader record-state transitions now route through `src/extension-host/loader-state.ts`
+- loader record-state transitions now route through `src/extension-host/loader-state.ts`, including explicit compatibility `lifecycleState` mapping
 - loader final cache, warning, and activation finalization now routes through `src/extension-host/loader-finalize.ts`
 
 How it has been implemented:
@@ -56,7 +56,7 @@ How it has been implemented:
 - by moving static metadata consumers onto the normalized model before attempting runtime contribution migration
 - by keeping legacy manifest records available only as compatibility projections while new readers move to the normalized shape
 - by starting runtime contribution migration with normalization helpers that preserve the legacy plugin API surface
-- by making the first loader compatibility, candidate-planning, import-flow, runtime-decision, register-flow, candidate-orchestration, record-state, and finalization helpers explicit host-owned seams before introducing a versioned compatibility layer
+- by making the first loader compatibility, candidate-planning, import-flow, runtime-decision, register-flow, candidate-orchestration, record-state with compatibility lifecycle mapping, and finalization helpers explicit host-owned seams before introducing a versioned compatibility layer
 
 What remains pending:
 

docs/.internal/extension-host-migration/openclaw-extension-host-implementation-guide.md

@@ -67,7 +67,7 @@ What has been implemented so far:
 - loader module-export resolution, config validation, and memory-slot load decisions now route through `src/extension-host/loader-runtime.ts`
 - loader post-import planning and `register(...)` execution now route through `src/extension-host/loader-register.ts`
 - loader per-candidate orchestration now routes through `src/extension-host/loader-flow.ts`
-- loader record-state transitions now route through `src/extension-host/loader-state.ts`
+- loader record-state transitions now route through `src/extension-host/loader-state.ts`, including explicit compatibility `lifecycleState` mapping
 - loader final cache, warning, and activation finalization now routes through `src/extension-host/loader-finalize.ts`
 - runtime registration normalization has started in `src/extension-host/runtime-registrations.ts` for channel, provider, HTTP-route, gateway-method, tool, CLI, service, command, context-engine, and hook registrations
 - several static and lookup consumers now read through the host boundary or resolved-extension model:
@@ -98,6 +98,7 @@ How it has been done:
 - by composing those seams into one host-owned per-candidate orchestrator before changing cache and lifecycle finalization behavior
 - by moving loader record-state transitions into host-owned helpers before introducing a full lifecycle state machine
 - by moving cache writes, provenance warnings, final memory-slot warnings, and activation into a host-owned loader finalizer before introducing an explicit lifecycle state machine
+- by adding explicit compatibility `lifecycleState` mapping on loader-owned plugin records before introducing a full lifecycle state machine
 - by moving central readers first, so later lifecycle and compatibility work can land on one boundary instead of many ad hoc call sites
 - by adding focused tests for each extracted seam before widening the boundary further
 
@@ -110,13 +111,14 @@ Committed implementation slices so far:
 - `fc81454038` `Plugins: extract loader import flow`
 - `e1b207f4cf` `Plugins: extract loader candidate orchestration`
 - `0c44d8049b` `Plugins: extract loader finalization`
+- `33ef55a9ee` `Plugins: add loader lifecycle state mapping`
 - `89414ed857` `Docs: track extension host migration internally`
 - `d8af1eceaf` `Docs: refresh extension host migration status`
 
 What is still missing for these phases:
 
 - keeping the cutover inventory current as more surfaces move
-- the lifecycle state machine, remaining explicit activation-state ownership, policy gate, and broad host-owned registries described for Phase 2
+- the full lifecycle state machine, remaining explicit activation-state ownership, policy gate, and broad host-owned registries described for Phase 2
 - minimal SDK compatibility work beyond preserving current behavior indirectly through existing loading
 - any pilot migration, event pipeline, canonical catalog, or arbitration implementation
 
@@ -306,7 +308,7 @@ Current implementation status:
 - the host owns the active registry state
 - the host exposes a resolved-extension registry view for static consumers
 - plugin skills, plugin auto-enable, and config validation indexing now consume host-owned resolved-extension data
-- activation, loader policy, loader candidate planning, loader import flow, loader runtime decisions, loader post-import register flow, loader candidate orchestration, and loader record-state helpers now route through `src/extension-host/*`
+- activation, loader policy, loader candidate planning, loader import flow, loader runtime decisions, loader post-import register flow, loader candidate orchestration, loader record-state helpers, and loader finalization now route through `src/extension-host/*`
 - lifecycle state ownership, activation states, policy evaluation, and broad host-owned registries are still not implemented
 
 ### Phase 3: Build compatibility bridges

docs/.internal/extension-host-migration/openclaw-extension-host-lifecycle-and-security-spec.md

@@ -43,7 +43,7 @@ What has been implemented:
 - loader module-export resolution, config validation, and memory-slot load decisions now route through `src/extension-host/loader-runtime.ts`
 - loader post-import planning and `register(...)` execution now route through `src/extension-host/loader-register.ts`
 - loader per-candidate orchestration now routes through `src/extension-host/loader-flow.ts`
-- loader record-state transitions now route through `src/extension-host/loader-state.ts`
+- loader record-state transitions now route through `src/extension-host/loader-state.ts`, including explicit compatibility `lifecycleState` mapping
 - loader final cache, warning, and activation finalization now routes through `src/extension-host/loader-finalize.ts`
 
 How it has been implemented:
@@ -64,10 +64,11 @@ How it has been implemented:
 - by composing those seams into one host-owned per-candidate loader orchestrator before moving final lifecycle-state behavior
 - by moving record-state transitions next while leaving the lifecycle state machine itself unimplemented
 - by moving cache writes, provenance warnings, final memory-slot warnings, and activation into a host-owned loader finalizer before introducing an explicit lifecycle state machine
+- by adding explicit compatibility `lifecycleState` mapping on loader-owned plugin records before introducing the full lifecycle state machine
 
 What is still pending from this spec:
 
-- the lifecycle state machine
+- the full lifecycle state machine
 - activation pipeline ownership
 - host-owned registries for setup, CLI, routes, services, slots, and backends
 - permission-mode enforcement

docs/.internal/extension-host-migration/openclaw-kernel-event-pipeline-spec.md

@@ -42,13 +42,13 @@ Relevant prerequisite work that has landed:
 - loader module-export resolution, config validation, and memory-slot load decisions now have a host-owned helper boundary
 - loader post-import planning and `register(...)` execution now have a host-owned helper boundary
 - loader per-candidate orchestration now has a host-owned helper boundary
-- loader record-state transitions now have a host-owned helper boundary
+- loader record-state transitions now have a host-owned helper boundary, including explicit compatibility `lifecycleState` mapping
 - loader final cache, warning, and activation finalization now has a host-owned helper boundary
 
 Why this matters for this spec:
 
 - event work should land on top of a host-owned boundary and normalized contribution model rather than on top of more plugin-era runtime seams
-- the current implementation has deliberately not started bridge or stage work before those earlier boundaries were in place, including the first loader-runtime and record-state seams
+- the current implementation has deliberately not started bridge or stage work before those earlier boundaries were in place, including the first loader-runtime, record-state, and finalization seams
 
 ## Design Goals
 

docs/.internal/extension-host-migration/openclaw-kernel-extension-host-transition-plan.md

@@ -52,7 +52,7 @@ What has landed:
 - loader module-export resolution, config validation, and memory-slot load decisions now route through `src/extension-host/loader-runtime.ts`
 - loader post-import planning and `register(...)` execution now route through `src/extension-host/loader-register.ts`
 - loader per-candidate orchestration now routes through `src/extension-host/loader-flow.ts`
-- loader record-state transitions now route through `src/extension-host/loader-state.ts`
+- loader record-state transitions now route through `src/extension-host/loader-state.ts`, including explicit compatibility `lifecycleState` mapping
 - loader final cache, warning, and activation finalization now routes through `src/extension-host/loader-finalize.ts`
 - runtime registration normalization has started in `src/extension-host/runtime-registrations.ts` for channel, provider, HTTP-route, gateway-method, tool, CLI, service, command, context-engine, and hook registrations
 - several existing consumers now read host-owned normalized data instead of plugin-era manifest or runtime state directly:
@@ -84,6 +84,7 @@ How it was done:
 - by composing those seams into one host-owned per-candidate orchestrator before changing cache and lifecycle finalization behavior
 - by moving loader record-state transitions into host-owned helpers before introducing a full lifecycle state machine
 - by moving cache writes, provenance warnings, final memory-slot warnings, and activation into a host-owned loader finalizer before introducing an explicit lifecycle state machine
+- by adding explicit compatibility `lifecycleState` mapping on loader-owned plugin records before introducing a full lifecycle state machine
 - by moving static and lookup-heavy consumers first, where the ownership boundary matters but runtime risk is lower
 
 Committed implementation slices so far:
@@ -95,13 +96,14 @@ Committed implementation slices so far:
 - `fc81454038` `Plugins: extract loader import flow`
 - `e1b207f4cf` `Plugins: extract loader candidate orchestration`
 - `0c44d8049b` `Plugins: extract loader finalization`
+- `33ef55a9ee` `Plugins: add loader lifecycle state mapping`
 - `89414ed857` `Docs: track extension host migration internally`
 - `d8af1eceaf` `Docs: refresh extension host migration status`
 
 What has not landed:
 
 - keeping the cutover inventory current as more surfaces move
-- the lifecycle state machine and remaining explicit activation-state ownership
+- the full lifecycle state machine and remaining explicit activation-state ownership
 - host-owned registration surfaces beyond the first channel, provider, HTTP-route, gateway-method, tool, CLI, service, command, context-engine, and hook helper slices
 - SDK compatibility translation work
 - canonical event stages
@@ -1317,7 +1319,7 @@ Current implementation status:
 - partially implemented in a compatibility-preserving form
 - the host now owns active registry state
 - the host now exposes resolved static registries for static consumers
-- activation, loader policy, loader runtime decisions, and loader record-state helpers now route through `src/extension-host/*`
+- activation, loader policy, loader runtime decisions, loader record-state helpers, and loader finalization now route through `src/extension-host/*`
 - broader lifecycle ownership, registration surfaces, policy gates, and activation-state management are still pending
 
 ## Phase 3: Broader Legacy Compatibility Bridges