From ed042cd16cb66a2dc99cc5afefcf970566090541 Mon Sep 17 00:00:00 2001 From: Gustavo Madeira Santana Date: Sun, 15 Mar 2026 16:53:43 +0000 Subject: [PATCH] Docs: refresh extension host migration status --- .../openclaw-capability-catalog-and-arbitration-spec.md | 4 ++-- .../openclaw-extension-contribution-schema-spec.md | 4 ++-- .../openclaw-extension-host-implementation-guide.md | 4 ++-- .../openclaw-extension-host-lifecycle-and-security-spec.md | 4 ++-- .../openclaw-kernel-event-pipeline-spec.md | 2 +- .../openclaw-kernel-extension-host-transition-plan.md | 7 ++++--- 6 files changed, 13 insertions(+), 12 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 eca27f3438e..7803bdab629 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 @@ -60,7 +60,7 @@ What has been implemented: - loader finalization policy results now route through `src/extension-host/loader-finalization-policy.ts` - loader final cache, readiness promotion, 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 -- low-risk runtime compatibility writes for tool, CLI, service, and command registrations now route through `src/extension-host/registry-writes.ts` ahead of broader catalog-backed registry ownership +- low-risk runtime compatibility writes for channel, provider, gateway-method, HTTP-route, tool, CLI, service, and command registrations now route through `src/extension-host/registry-writes.ts` ahead of broader catalog-backed registry ownership How it has been implemented: @@ -68,7 +68,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 actual low-risk runtime write ownership for tool, CLI, service, and command registrations before attempting full canonical catalog publication +- by beginning actual low-risk runtime write ownership for channel, provider, gateway-method, HTTP-route, tool, CLI, service, and command registrations 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, top-level load orchestration, record-state with compatibility lifecycle mapping, and finalization helpers before attempting canonical catalog publication - by extracting lazy runtime proxy creation and alias-wired Jiti module-loader creation into host-owned helpers before catalog publication work 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 f5675df1f3a..a443748a3c5 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 @@ -39,7 +39,7 @@ What has been implemented: - a host-owned resolved-extension registry now exists for static consumers - config doc baseline generation now reads bundled extension metadata through the resolved-extension registry - the first runtime registration normalization helpers now exist in `src/extension-host/runtime-registrations.ts` for channel, provider, HTTP-route, gateway-method, tool, CLI, service, command, context-engine, and hook writes -- low-risk runtime compatibility writes for tool, CLI, service, and command registrations now route through `src/extension-host/registry-writes.ts` +- low-risk runtime compatibility writes for channel, provider, gateway-method, HTTP-route, tool, CLI, service, and command registrations now route through `src/extension-host/registry-writes.ts` - plugin SDK alias resolution now routes through `src/extension-host/loader-compat.ts` - loader alias-wired module loader creation now routes through `src/extension-host/loader-module-loader.ts` - loader cache key construction and registry cache control now route through `src/extension-host/loader-cache.ts` @@ -72,7 +72,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 starting actual low-risk runtime write ownership for tool, CLI, service, and command registrations only after normalization helpers preserved the legacy plugin API surface +- by starting actual low-risk runtime write ownership for channel, provider, gateway-method, HTTP-route, tool, CLI, service, and command registrations only after normalization helpers preserved 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, top-level load orchestration, record-state with compatibility lifecycle mapping, and finalization helpers explicit host-owned seams before introducing a versioned compatibility layer - by extracting lazy runtime proxy creation and alias-wired Jiti module-loader creation into host-owned helpers before broader schema-driven lifecycle ownership changes 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 86d688a94a7..78797e93426 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 @@ -85,7 +85,7 @@ What has been implemented so far: - loader finalization policy results now route through `src/extension-host/loader-finalization-policy.ts` - loader final cache, readiness promotion, 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 -- low-risk runtime compatibility writes for tool, CLI, service, and command registrations now route through `src/extension-host/registry-writes.ts` +- low-risk runtime compatibility writes for channel, provider, gateway-method, HTTP-route, tool, CLI, service, and command registrations now route through `src/extension-host/registry-writes.ts` - several static and lookup consumers now read through the host boundary or resolved-extension model: - channel registry and dock lookups - message-channel normalization @@ -104,7 +104,7 @@ How it has been done: - by introducing normalized static records before touching heavy runtime activation paths - by converting one static consumer at a time so each call site can move without forcing a loader rewrite - by extracting low-risk runtime registration helpers next and letting `src/plugins/registry.ts` delegate to them as a compatibility facade -- by starting actual low-risk runtime write ownership next for tool, CLI, service, and command registrations while keeping duplicate enforcement and lifecycle semantics in legacy owners where that behavior still lives +- by starting actual low-risk runtime write ownership next for channel, provider, gateway-method, HTTP-route, tool, CLI, service, and command registrations while keeping duplicate enforcement and lifecycle semantics in legacy owners where that behavior still lives - by keeping duplicate enforcement in legacy subsystems only where that logic has not moved yet, such as plugin commands - by starting loader and lifecycle migration with compatibility helpers for activation and SDK alias resolution before changing discovery or policy behavior - by moving cache-key construction, cache reads, cache writes, and cache clearing behind host-owned helpers before changing activation-state ownership 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 1b4efdd6750..399738fc149 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 @@ -38,7 +38,7 @@ What has been implemented: - a host-owned resolved-extension registry exists for static consumers - static config-baseline generation now reads bundled extension metadata through the host-owned resolved-extension registry - 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` -- low-risk runtime compatibility writes for tool, CLI, service, and command registrations now delegate through `src/extension-host/registry-writes.ts` +- low-risk runtime compatibility writes for channel, provider, gateway-method, HTTP-route, tool, CLI, service, and command registrations now delegate through `src/extension-host/registry-writes.ts` - loader alias-wired module loader creation now routes through `src/extension-host/loader-module-loader.ts` - loader cache key construction and registry cache control now route through `src/extension-host/loader-cache.ts` - loader lazy runtime proxy creation now routes through `src/extension-host/loader-runtime-proxy.ts` @@ -70,7 +70,7 @@ How it has been implemented: - by moving low-risk readers first, such as channel lookup, dock lookup, message-channel lookup, and default HTTP route registry access - by extending that same host-owned boundary into static consumers instead of introducing separate one-off metadata loaders - by starting runtime-registry migration with low-risk validation and normalization helpers while leaving lifecycle ordering and activation behavior unchanged -- by starting actual low-risk runtime write ownership for tool, CLI, service, and command registrations only after normalization helpers existed, while leaving lifecycle ordering and activation behavior unchanged +- by starting actual low-risk runtime write ownership for channel, provider, gateway-method, HTTP-route, tool, CLI, service, and command registrations only after normalization helpers existed, while leaving lifecycle ordering and activation behavior unchanged - by leaving start/stop ordering and duplicate-enforcement behavior in legacy subsystems where those subsystems are still the real owner - by treating hook execution and hook registration as separate migration concerns so event-pipeline work does not get conflated with record normalization - by starting loader/lifecycle migration with activation and SDK alias compatibility helpers while leaving discovery and policy flow unchanged 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 eb65c83152b..715166359ef 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 @@ -59,7 +59,7 @@ Relevant prerequisite work that has landed: - loader record-state transitions now have a host-owned helper boundary and enforced loader lifecycle state machine, while still preserving compatibility `PluginRecord.status` values - loader finalization policy outcomes now have a host-owned helper boundary - loader final cache, readiness promotion, and activation finalization now has a host-owned helper boundary -- low-risk tool, CLI, service, and command compatibility writes now have a host-owned helper boundary in `src/extension-host/registry-writes.ts` +- low-risk channel, provider, gateway-method, HTTP-route, tool, CLI, service, and command compatibility writes now have a host-owned helper boundary in `src/extension-host/registry-writes.ts` Why this matters for this spec: 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 d55ab6356d4..4d0b8324dc1 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 @@ -70,7 +70,7 @@ What has landed: - loader finalization policy results now route through `src/extension-host/loader-finalization-policy.ts` - loader final cache, readiness promotion, 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 -- low-risk runtime compatibility writes for tool, CLI, service, and command registrations now route through `src/extension-host/registry-writes.ts` +- low-risk runtime compatibility writes for channel, provider, gateway-method, HTTP-route, tool, CLI, service, and command registrations now route through `src/extension-host/registry-writes.ts` - several existing consumers now read host-owned normalized data instead of plugin-era manifest or runtime state directly: - channel and dock lookup surfaces - message-channel normalization @@ -90,7 +90,7 @@ How it was done: - by letting the legacy manifest registry project into a host-owned resolved-extension shape so existing call sites could migrate incrementally - by migrating static consumers one by one onto resolved-extension data instead of forcing a single cutover - by moving the first low-risk runtime writes behind host-owned helpers while keeping `src/plugins/registry.ts` as the compatibility call surface -- by starting actual low-risk runtime write ownership for tool, CLI, service, and command registrations once normalization helpers were already in place, while keeping duplicate enforcement and lifecycle semantics in legacy owners where they still apply +- by starting actual low-risk runtime write ownership for channel, provider, gateway-method, HTTP-route, tool, CLI, service, and command registrations once normalization helpers were already in place, while keeping duplicate enforcement and lifecycle semantics in legacy owners where they still apply - by leaving duplicate enforcement in legacy subsystems only where that behavior has not been migrated yet, such as plugin commands - by moving the first loader-owned compatibility pieces behind host-owned helpers before changing discovery, enablement, or policy flow - by moving cache-key construction, cache reads, cache writes, and cache clearing behind host-owned helpers before changing activation-state ownership @@ -145,6 +145,7 @@ Committed implementation slices so far: - `0df51ae6b4` `Plugins: extract loader pipeline` - `e557b39cb2` `Plugins: extract loader host state` - `07c3ae9c87` `Plugins: extract low-risk registry writes` +- `bc71592270` `Plugins: extend registry write helpers` - `89414ed857` `Docs: track extension host migration internally` - `d8af1eceaf` `Docs: refresh extension host migration status` @@ -152,7 +153,7 @@ What has not landed: - keeping the cutover inventory current as more surfaces move - broader lifecycle ownership beyond the loader state machine, session-owned activation state, and explicit discovery-policy, activation-policy, and finalization-policy outcomes, plus remaining policy semantics -- host-owned registration surfaces beyond the first normalization helpers and low-risk tool, CLI, service, and command compatibility write slices +- host-owned registration surfaces beyond the first normalization helpers and low-risk channel, provider, gateway-method, HTTP-route, tool, CLI, service, and command compatibility write slices - SDK compatibility translation work - canonical event stages - canonical capability catalogs