From a54eda5051a286763a07929eabd0fe61146e1a2e Mon Sep 17 00:00:00 2001 From: Gustavo Madeira Santana Date: Sun, 15 Mar 2026 14:40:27 +0000 Subject: [PATCH] Docs: refresh extension host migration status --- .../openclaw-capability-catalog-and-arbitration-spec.md | 3 ++- .../openclaw-extension-contribution-schema-spec.md | 3 ++- .../openclaw-extension-host-implementation-guide.md | 5 ++++- .../openclaw-extension-host-lifecycle-and-security-spec.md | 2 ++ .../openclaw-kernel-event-pipeline-spec.md | 1 + .../openclaw-kernel-extension-host-transition-plan.md | 7 +++++-- 6 files changed, 16 insertions(+), 5 deletions(-) diff --git a/docs/.internal/extension-host-migration/openclaw-capability-catalog-and-arbitration-spec.md b/docs/.internal/extension-host-migration/openclaw-capability-catalog-and-arbitration-spec.md index 0b43fb6219d..6672e52de5f 100644 --- a/docs/.internal/extension-host-migration/openclaw-capability-catalog-and-arbitration-spec.md +++ b/docs/.internal/extension-host-migration/openclaw-capability-catalog-and-arbitration-spec.md @@ -43,6 +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 top-level load orchestration now routes through `src/extension-host/loader-orchestrator.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 @@ -54,7 +55,7 @@ How it has been implemented: - 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 moving cache-key construction and registry cache control behind host-owned 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 +- by beginning loader-path migration with host-owned compatibility, candidate-planning, import-flow, policy, runtime, register-flow, candidate-orchestration, top-level load orchestration, record-state with compatibility lifecycle mapping, and finalization helpers before attempting canonical catalog publication What remains pending: diff --git a/docs/.internal/extension-host-migration/openclaw-extension-contribution-schema-spec.md b/docs/.internal/extension-host-migration/openclaw-extension-contribution-schema-spec.md index d68ffc6fa09..8d862584b12 100644 --- a/docs/.internal/extension-host-migration/openclaw-extension-contribution-schema-spec.md +++ b/docs/.internal/extension-host-migration/openclaw-extension-contribution-schema-spec.md @@ -47,6 +47,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 top-level load orchestration now routes through `src/extension-host/loader-orchestrator.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` @@ -58,7 +59,7 @@ How it has been implemented: - 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 cache-key construction and registry cache control explicit host-owned seams before changing loader activation-state ownership -- 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 +- by making the first loader compatibility, candidate-planning, import-flow, runtime-decision, register-flow, candidate-orchestration, top-level load orchestration, record-state with compatibility lifecycle mapping, and finalization helpers explicit host-owned seams before introducing a versioned compatibility layer What remains pending: diff --git a/docs/.internal/extension-host-migration/openclaw-extension-host-implementation-guide.md b/docs/.internal/extension-host-migration/openclaw-extension-host-implementation-guide.md index dbbe1945b95..13317e4aef9 100644 --- a/docs/.internal/extension-host-migration/openclaw-extension-host-implementation-guide.md +++ b/docs/.internal/extension-host-migration/openclaw-extension-host-implementation-guide.md @@ -68,6 +68,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 top-level load orchestration now routes through `src/extension-host/loader-orchestrator.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 @@ -101,6 +102,7 @@ How it has been done: - 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 the remaining top-level loader orchestration into a host-owned module so `src/plugins/loader.ts` becomes a compatibility facade instead of the real owner - 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 @@ -115,6 +117,7 @@ Committed implementation slices so far: - `0c44d8049b` `Plugins: extract loader finalization` - `33ef55a9ee` `Plugins: add loader lifecycle state mapping` - `6590e19095` `Plugins: extract loader cache control` +- `c8d82a8f19` `Plugins: extract loader orchestration` - `89414ed857` `Docs: track extension host migration internally` - `d8af1eceaf` `Docs: refresh extension host migration status` @@ -311,7 +314,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 cache control, 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/*` +- activation, loader cache control, loader policy, loader candidate planning, loader import flow, loader runtime decisions, loader post-import register flow, loader candidate orchestration, loader top-level load 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 diff --git a/docs/.internal/extension-host-migration/openclaw-extension-host-lifecycle-and-security-spec.md b/docs/.internal/extension-host-migration/openclaw-extension-host-lifecycle-and-security-spec.md index b0cd828425a..e866771cdd5 100644 --- a/docs/.internal/extension-host-migration/openclaw-extension-host-lifecycle-and-security-spec.md +++ b/docs/.internal/extension-host-migration/openclaw-extension-host-lifecycle-and-security-spec.md @@ -44,6 +44,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 top-level load orchestration now routes through `src/extension-host/loader-orchestrator.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` @@ -64,6 +65,7 @@ How it has been implemented: - 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 composing those seams into one host-owned per-candidate loader orchestrator before moving final lifecycle-state behavior +- by moving the remaining top-level loader orchestration into a host-owned module while leaving the full lifecycle state machine itself unimplemented - 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 diff --git a/docs/.internal/extension-host-migration/openclaw-kernel-event-pipeline-spec.md b/docs/.internal/extension-host-migration/openclaw-kernel-event-pipeline-spec.md index 5c0f8996412..14e61fc43da 100644 --- a/docs/.internal/extension-host-migration/openclaw-kernel-event-pipeline-spec.md +++ b/docs/.internal/extension-host-migration/openclaw-kernel-event-pipeline-spec.md @@ -43,6 +43,7 @@ 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 top-level load orchestration now has 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 diff --git a/docs/.internal/extension-host-migration/openclaw-kernel-extension-host-transition-plan.md b/docs/.internal/extension-host-migration/openclaw-kernel-extension-host-transition-plan.md index 11f639e114d..c212ae42bfa 100644 --- a/docs/.internal/extension-host-migration/openclaw-kernel-extension-host-transition-plan.md +++ b/docs/.internal/extension-host-migration/openclaw-kernel-extension-host-transition-plan.md @@ -53,6 +53,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 top-level load orchestration now routes through `src/extension-host/loader-orchestrator.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 @@ -87,6 +88,7 @@ How it was done: - 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 the remaining top-level loader orchestration into a host-owned module so `src/plugins/loader.ts` becomes a compatibility facade instead of the real owner - by moving static and lookup-heavy consumers first, where the ownership boundary matters but runtime risk is lower Committed implementation slices so far: @@ -100,13 +102,14 @@ Committed implementation slices so far: - `0c44d8049b` `Plugins: extract loader finalization` - `33ef55a9ee` `Plugins: add loader lifecycle state mapping` - `6590e19095` `Plugins: extract loader cache control` +- `c8d82a8f19` `Plugins: extract loader orchestration` - `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 full lifecycle state machine and remaining explicit activation-state plus policy ownership +- the full lifecycle state machine and remaining explicit activation-state and policy semantics - 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 @@ -1322,7 +1325,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 cache control, loader policy, loader runtime decisions, loader record-state helpers, and loader finalization now route through `src/extension-host/*` +- activation, loader cache control, loader policy, loader runtime decisions, loader top-level load orchestration, 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