Ayuriel/openclaw
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Docs: refresh extension host migration status

Browse Source
This commit is contained in:
Gustavo Madeira Santana 2026-03-15 16:56:03 +00:00
parent 8f22067992
commit 8bfe6bb03f
No known key found for this signature in database
6 changed files with 13 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -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

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

@ -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

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

@ -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

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

@ -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

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

@ -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:

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

@ -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