Docs: refresh extension host migration status

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

@@ -38,6 +38,7 @@ What has been implemented:
 - plugin SDK alias resolution now routes through `src/extension-host/loader-compat.ts`
 - loader provenance, duplicate-order, and warning policy now route through `src/extension-host/loader-policy.ts`
 - loader initial candidate planning and record creation now route through `src/extension-host/loader-records.ts`
+- loader entry-path opening and module import now route through `src/extension-host/loader-import.ts`
 - 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 record-state transitions now route through `src/extension-host/loader-state.ts`
@@ -49,7 +50,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, policy, runtime, register-flow, and record-state helpers before attempting canonical catalog publication
+- by beginning loader-path migration with host-owned compatibility, candidate-planning, import-flow, policy, runtime, register-flow, and record-state helpers before attempting canonical catalog publication
 
 What remains pending:
 

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

@@ -42,6 +42,7 @@ What has been implemented:
 - plugin SDK alias resolution now routes through `src/extension-host/loader-compat.ts`
 - loader provenance, duplicate-order, and warning policy now route through `src/extension-host/loader-policy.ts`
 - loader initial candidate planning and record creation now route through `src/extension-host/loader-records.ts`
+- loader entry-path opening and module import now route through `src/extension-host/loader-import.ts`
 - 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 record-state transitions now route through `src/extension-host/loader-state.ts`
@@ -53,7 +54,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, runtime-decision, and register-flow helpers explicit host-owned seams before introducing a versioned compatibility layer
+- by making the first loader compatibility, candidate-planning, import-flow, runtime-decision, and register-flow 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

@@ -63,6 +63,7 @@ What has been implemented so far:
 - plugin SDK alias resolution now routes through `src/extension-host/loader-compat.ts`
 - loader provenance, duplicate-order, and warning policy now route through `src/extension-host/loader-policy.ts`
 - loader initial candidate planning and record creation now route through `src/extension-host/loader-records.ts`
+- loader entry-path opening and module import now route through `src/extension-host/loader-import.ts`
 - 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 record-state transitions now route through `src/extension-host/loader-state.ts`
@@ -89,6 +90,7 @@ How it has been done:
 - by starting loader and lifecycle migration with compatibility helpers for activation and SDK alias resolution before changing discovery or policy behavior
 - by moving loader-owned policy helpers next, while keeping module loading and enablement flow behavior unchanged
 - by moving initial candidate planning and record construction behind host-owned helpers before changing import and registration flow
+- by moving entry-path opening and module import behind host-owned helpers before changing cache wiring or lifecycle orchestration
 - by moving loader runtime decisions behind host-owned helpers while preserving lazy loading, config validation behavior, and memory-slot policy behavior
 - by moving post-import planning and `register(...)` execution behind host-owned helpers before changing entry-path and import flow
 - by moving loader record-state transitions into host-owned helpers before introducing a full lifecycle state machine
@@ -101,13 +103,14 @@ Committed implementation slices so far:
 - `1aab89e820` `Plugins: extract loader host seams`
 - `7bc3135082` `Plugins: extract loader candidate planning`
 - `3a122c95fa` `Plugins: extract loader register flow`
+- `fc81454038` `Plugins: extract loader import flow`
 - `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 entry-path and import flow, policy gate, and broad host-owned registries described for Phase 2
+- the lifecycle state machine, remaining cache and final registry orchestration flow, 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
 
@@ -297,7 +300,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 runtime decisions, loader post-import register flow, 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, and loader record-state helpers 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

@@ -39,6 +39,7 @@ What has been implemented:
 - channel, provider, HTTP-route, gateway-method, tool, CLI, service, command, context-engine, and hook registration normalization now delegates through `src/extension-host/runtime-registrations.ts`
 - loader provenance, duplicate-order, and warning policy now route through `src/extension-host/loader-policy.ts`
 - loader initial candidate planning and record creation now route through `src/extension-host/loader-records.ts`
+- loader entry-path opening and module import now route through `src/extension-host/loader-import.ts`
 - 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 record-state transitions now route through `src/extension-host/loader-state.ts`
@@ -55,6 +56,7 @@ How it has been implemented:
 - by starting loader/lifecycle migration with activation and SDK alias compatibility helpers while leaving discovery and policy flow unchanged
 - by moving provenance and duplicate-order policy next, so lifecycle migration can land on host-owned policy helpers instead of loader-local utilities
 - by moving initial candidate planning and record construction next while leaving module import and registration flow unchanged
+- by moving entry-path opening and module import next while leaving cache wiring and lifecycle orchestration unchanged
 - by moving loader runtime decisions next while preserving the current lazy-load, config-validation, and memory-slot behavior
 - by moving post-import planning and `register(...)` execution next while leaving entry-path and import flow unchanged
 - by moving record-state transitions next while leaving the lifecycle state machine itself unimplemented

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

@@ -38,6 +38,7 @@ Relevant prerequisite work that has landed:
 - channel, provider, HTTP-route, gateway-method, tool, CLI, service, command, context-engine, and hook registration normalization now has a host-owned helper boundary
 - loader provenance and duplicate-order policy now have a host-owned helper boundary
 - loader initial candidate planning and record creation now have a host-owned helper boundary
+- loader entry-path opening and module import now have a host-owned helper boundary
 - 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 record-state transitions now have a host-owned helper boundary

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

@@ -48,6 +48,7 @@ What has landed:
 - plugin SDK alias resolution now routes through `src/extension-host/loader-compat.ts`
 - loader provenance, duplicate-order, and warning policy now route through `src/extension-host/loader-policy.ts`
 - loader initial candidate planning and record creation now route through `src/extension-host/loader-records.ts`
+- loader entry-path opening and module import now route through `src/extension-host/loader-import.ts`
 - 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 record-state transitions now route through `src/extension-host/loader-state.ts`
@@ -75,6 +76,7 @@ How it was done:
 - by moving the first loader-owned compatibility pieces behind host-owned helpers before changing discovery, enablement, or policy flow
 - by moving the next loader-owned policy helpers behind host-owned modules while preserving the current load/skip/error behavior
 - by moving initial candidate planning and record construction behind host-owned helpers before changing import and registration flow
+- by moving entry-path opening and module import behind host-owned helpers before changing cache wiring or lifecycle orchestration
 - by moving loader runtime decisions next, while preserving lazy loading, config validation behavior, and memory-slot policy behavior
 - by moving post-import planning and `register(...)` execution behind host-owned helpers before changing entry-path and import flow
 - by moving loader record-state transitions into host-owned helpers before introducing a full lifecycle state machine
@@ -86,6 +88,7 @@ Committed implementation slices so far:
 - `1aab89e820` `Plugins: extract loader host seams`
 - `7bc3135082` `Plugins: extract loader candidate planning`
 - `3a122c95fa` `Plugins: extract loader register flow`
+- `fc81454038` `Plugins: extract loader import flow`
 - `89414ed857` `Docs: track extension host migration internally`
 - `d8af1eceaf` `Docs: refresh extension host migration status`
 
@@ -93,6 +96,7 @@ What has not landed:
 
 - keeping the cutover inventory current as more surfaces move
 - the lifecycle state machine and remaining loader orchestration
+- the remaining cache wiring and final registry orchestration in the loader
 - the remaining entry-path opening and import flow in the loader
 - 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