From 8bfe6bb03f0c8189a830455eee418a9ca44c4f02 Mon Sep 17 00:00:00 2001 From: Gustavo Madeira Santana Date: Sun, 15 Mar 2026 16:56:03 +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 7803bdab629..a0784e42a31 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 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 +- low-risk runtime compatibility writes for channel, provider, gateway-method, HTTP-route, tool, CLI, service, command, context-engine, and hook 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 channel, provider, gateway-method, HTTP-route, 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, command, context-engine, and hook 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 a443748a3c5..482a3b09015 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 channel, provider, gateway-method, HTTP-route, 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, command, context-engine, and hook 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 channel, provider, gateway-method, HTTP-route, 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, command, context-engine, and hook 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 78797e93426..64e8dc7936d 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 channel, provider, gateway-method, HTTP-route, 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, command, context-engine, and hook 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 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 starting actual low-risk runtime write ownership next for channel, provider, gateway-method, HTTP-route, tool, CLI, service, command, context-engine, and hook 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 399738fc149..183fc7386b8 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 channel, provider, gateway-method, HTTP-route, 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, command, context-engine, and hook 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 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 starting actual low-risk runtime write ownership for channel, provider, gateway-method, HTTP-route, tool, CLI, service, command, context-engine, and hook 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 715166359ef..45266d39feb 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 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` +- low-risk channel, provider, gateway-method, HTTP-route, tool, CLI, service, command, context-engine, and hook 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 4d0b8324dc1..255bb700aa7 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 channel, provider, gateway-method, HTTP-route, 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, command, context-engine, and hook 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 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 starting actual low-risk runtime write ownership for channel, provider, gateway-method, HTTP-route, tool, CLI, service, command, context-engine, and hook 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 @@ -146,6 +146,7 @@ Committed implementation slices so far: - `e557b39cb2` `Plugins: extract loader host state` - `07c3ae9c87` `Plugins: extract low-risk registry writes` - `bc71592270` `Plugins: extend registry write helpers` +- `27fc645484` `Plugins: extend registry writes for hooks` - `89414ed857` `Docs: track extension host migration internally` - `d8af1eceaf` `Docs: refresh extension host migration status` @@ -153,7 +154,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 channel, provider, gateway-method, HTTP-route, 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, command, context-engine, and hook compatibility write slices - SDK compatibility translation work - canonical event stages - canonical capability catalogs