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 17:34:50 +00:00
parent b33e0c566b
commit 3fd9f20f5b
No known key found for this signature in database
7 changed files with 16 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -69,6 +69,7 @@ What has been implemented:
- service startup, stop ordering, service-context creation, and failure logging now route through `src/extension-host/service-lifecycle.ts` ahead of broader catalog-backed lifecycle ownership
- CLI duplicate detection, registrar invocation, and async failure logging now route through `src/extension-host/cli-lifecycle.ts` ahead of broader catalog-backed CLI ownership
- gateway method-id aggregation, plugin diagnostic shaping, and extra-handler composition now route through `src/extension-host/gateway-methods.ts` ahead of broader catalog-backed gateway ownership
- plugin tool resolution, conflict handling, optional-tool gating, and plugin-tool metadata tracking now route through `src/extension-host/tool-runtime.ts` ahead of broader catalog-backed tool ownership
How it has been implemented:
@ -100,6 +101,7 @@ How it has been implemented:
- by extracting service startup, stop ordering, service-context creation, and failure logging into a host-owned service-lifecycle helper before broader catalog-backed service ownership
- by extracting CLI duplicate detection, registrar invocation, and async failure logging into a host-owned CLI-lifecycle helper before broader catalog-backed CLI ownership
- by extracting gateway method-id aggregation, plugin diagnostic shaping, and extra-handler composition into a host-owned gateway-methods helper before broader catalog-backed gateway ownership
- by extracting plugin tool resolution, conflict handling, optional-tool gating, and plugin-tool metadata tracking into a host-owned tool-runtime helper before broader catalog-backed tool ownership
What remains pending:

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

@ -48,6 +48,7 @@ What has been implemented:
- service startup, stop ordering, service-context creation, and failure logging now route through `src/extension-host/service-lifecycle.ts`
- CLI duplicate detection, registrar invocation, and async failure logging now route through `src/extension-host/cli-lifecycle.ts`
- gateway method-id aggregation, plugin diagnostic shaping, and extra-handler composition now route through `src/extension-host/gateway-methods.ts`
- plugin tool resolution, conflict handling, optional-tool gating, and plugin-tool metadata tracking now route through `src/extension-host/tool-runtime.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`
@ -104,6 +105,7 @@ How it has been implemented:
- by extracting service startup, stop ordering, service-context creation, and failure logging into a host-owned service-lifecycle helper while `src/plugins/services.ts` remains the compatibility entry point
- by extracting CLI duplicate detection, registrar invocation, and async failure logging into a host-owned CLI-lifecycle helper while `src/plugins/cli.ts` remains the compatibility entry point
- by extracting gateway method-id aggregation, plugin diagnostic shaping, and extra-handler composition into a host-owned gateway-methods helper while request dispatch semantics remain in the gateway server code
- by extracting plugin tool resolution, conflict handling, optional-tool gating, and plugin-tool metadata tracking into a host-owned tool-runtime helper while `src/plugins/tools.ts` remains the loader and config-normalization facade
What remains pending:

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

@ -94,6 +94,7 @@ What has been implemented so far:
- service startup, stop ordering, service-context creation, and failure logging now route through `src/extension-host/service-lifecycle.ts`
- CLI duplicate detection, registrar invocation, and async failure logging now route through `src/extension-host/cli-lifecycle.ts`
- gateway method-id aggregation, plugin diagnostic shaping, and extra-handler composition now route through `src/extension-host/gateway-methods.ts`
- plugin tool resolution, conflict handling, optional-tool gating, and plugin-tool metadata tracking now route through `src/extension-host/tool-runtime.ts`
- several static and lookup consumers now read through the host boundary or resolved-extension model:
- channel registry and dock lookups
- message-channel normalization
@ -147,6 +148,7 @@ How it has been done:
- by extracting service startup, stop ordering, service-context creation, and failure logging into a host-owned service-lifecycle helper while `src/plugins/services.ts` remains the compatibility entry point
- by extracting CLI duplicate detection, registrar invocation, and async failure logging into a host-owned CLI-lifecycle helper while `src/plugins/cli.ts` remains the compatibility entry point
- by extracting gateway method-id aggregation, plugin diagnostic shaping, and extra-handler composition into a host-owned gateway-methods helper while request dispatch semantics remain in the gateway server code
- by extracting plugin tool resolution, conflict handling, optional-tool gating, and plugin-tool metadata tracking into a host-owned tool-runtime helper while `src/plugins/tools.ts` remains the loader and config-normalization facade
- 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
@ -186,6 +188,7 @@ Committed implementation slices so far:
- `6b24e65719` `Plugins: extract service lifecycle`
- `b5757a6625` `Plugins: extract CLI lifecycle`
- `e0e3229bcb` `Gateway: extract extension host method surface`
- `af7ac14eed` `Plugins: extract tool runtime`
- `89414ed857` `Docs: track extension host migration internally`
- `d8af1eceaf` `Docs: refresh extension host migration status`

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

@ -47,6 +47,7 @@ What has been implemented:
- service startup, stop ordering, service-context creation, and failure logging now delegate through `src/extension-host/service-lifecycle.ts`
- CLI duplicate detection, registrar invocation, and async failure logging now delegate through `src/extension-host/cli-lifecycle.ts`
- gateway method-id aggregation, plugin diagnostic shaping, and extra-handler composition now delegate through `src/extension-host/gateway-methods.ts`
- plugin tool resolution, conflict handling, optional-tool gating, and plugin-tool metadata tracking now delegate through `src/extension-host/tool-runtime.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`
@ -114,6 +115,7 @@ How it has been implemented:
- by extracting service startup, stop ordering, service-context creation, and failure logging into a host-owned service-lifecycle helper while `src/plugins/services.ts` remains the compatibility entry point
- by extracting CLI duplicate detection, registrar invocation, and async failure logging into a host-owned CLI-lifecycle helper while `src/plugins/cli.ts` remains the compatibility entry point
- by extracting gateway method-id aggregation, plugin diagnostic shaping, and extra-handler composition into a host-owned gateway-methods helper while request dispatch semantics remain in the gateway server code
- by extracting plugin tool resolution, conflict handling, optional-tool gating, and plugin-tool metadata tracking into a host-owned tool-runtime helper while `src/plugins/tools.ts` remains the loader and config-normalization facade
What is still pending from this spec:

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

@ -68,11 +68,12 @@ Relevant prerequisite work that has landed:
- service startup, stop ordering, service-context creation, and failure logging now have a host-owned helper boundary in `src/extension-host/service-lifecycle.ts`
- CLI duplicate detection, registrar invocation, and async failure logging now have a host-owned helper boundary in `src/extension-host/cli-lifecycle.ts`
- gateway method-id aggregation, plugin diagnostic shaping, and extra-handler composition now have a host-owned helper boundary in `src/extension-host/gateway-methods.ts`
- plugin tool resolution, conflict handling, optional-tool gating, and plugin-tool metadata tracking now have a host-owned helper boundary in `src/extension-host/tool-runtime.ts`
Why this matters for this spec:
- event work should land on top of a host-owned boundary and normalized contribution model rather than on top of more plugin-era runtime seams
- the current implementation has deliberately not started canonical bridge or stage work before those earlier boundaries were in place, including the first loader-runtime, record-state, discovery-policy, activation-policy, finalization-policy, low-risk registry-write, hook-compat, plugin-api, plugin-registry, plugin-registry-compat, plugin-registry-registrations, service-lifecycle, CLI-lifecycle, and gateway-methods seams
- the current implementation has deliberately not started canonical bridge or stage work before those earlier boundaries were in place, including the first loader-runtime, record-state, discovery-policy, activation-policy, finalization-policy, low-risk registry-write, hook-compat, plugin-api, plugin-registry, plugin-registry-compat, plugin-registry-registrations, service-lifecycle, CLI-lifecycle, gateway-methods, and tool-runtime seams
## Design Goals

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

@ -79,6 +79,7 @@ What has landed:
- service startup, stop ordering, service-context creation, and failure logging now route through `src/extension-host/service-lifecycle.ts`
- CLI duplicate detection, registrar invocation, and async failure logging now route through `src/extension-host/cli-lifecycle.ts`
- gateway method-id aggregation, plugin diagnostic shaping, and extra-handler composition now route through `src/extension-host/gateway-methods.ts`
- plugin tool resolution, conflict handling, optional-tool gating, and plugin-tool metadata tracking now route through `src/extension-host/tool-runtime.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
@ -133,6 +134,7 @@ How it was done:
- by extracting service startup, stop ordering, service-context creation, and failure logging into a host-owned service-lifecycle helper while `src/plugins/services.ts` remains the compatibility entry point
- by extracting CLI duplicate detection, registrar invocation, and async failure logging into a host-owned CLI-lifecycle helper while `src/plugins/cli.ts` remains the compatibility entry point
- by extracting gateway method-id aggregation, plugin diagnostic shaping, and extra-handler composition into a host-owned gateway-methods helper while request dispatch semantics remain in the gateway server code
- by extracting plugin tool resolution, conflict handling, optional-tool gating, and plugin-tool metadata tracking into a host-owned tool-runtime helper while `src/plugins/tools.ts` remains the loader and config-normalization facade
- by moving static and lookup-heavy consumers first, where the ownership boundary matters but runtime risk is lower
Committed implementation slices so far:
@ -171,6 +173,7 @@ Committed implementation slices so far:
- `6b24e65719` `Plugins: extract service lifecycle`
- `b5757a6625` `Plugins: extract CLI lifecycle`
- `e0e3229bcb` `Gateway: extract extension host method surface`
- `af7ac14eed` `Plugins: extract tool runtime`
- `89414ed857` `Docs: track extension host migration internally`
- `d8af1eceaf` `Docs: refresh extension host migration status`

2
src/extension-host/cutover-inventory.md
View File

@ -63,6 +63,7 @@ This is an implementation checklist, not a future-design spec.
| Plugin auto-enable | `src/config/plugin-auto-enable.ts` | host-owned resolved registry | `partial` | Primary logic runs on resolved-extension data; old manifest-registry injection remains as a compatibility input for older callers and tests. |
| Config validation indexing | `src/config/validation.ts`, `src/config/resolved-extension-validation.ts` | host-owned resolved registry | `moved` | Validation indexing now builds from resolved-extension records instead of flat manifest rows. |
| Config doc baseline generation | `src/config/doc-baseline.ts` | host-owned resolved registry | `moved` | Bundled plugin and channel metadata now load through the resolved-extension registry. |
| Plugin tool resolution and metadata | `src/plugins/tools.ts` | `src/extension-host/tool-runtime.ts` | `partial` | Optional-tool gating, plugin-id and tool-name conflict handling, tool-factory resolution, and plugin-tool metadata tracking now delegate through a host-owned tool-runtime helper while `src/plugins/tools.ts` remains the loader and config-normalization facade. |
| Plugin loader activation | `src/plugins/loader.ts` | extension host lifecycle + compatibility loader | `partial` | Activation now routes through `src/extension-host/activation.ts`, but discovery, enablement, provenance, module loading, and policy still live in the legacy plugin loader. |
| Plugin API compatibility facade | `src/plugins/registry.ts` | `src/extension-host/plugin-api.ts` | `partial` | Compatibility `OpenClawPluginApi` composition and logger shaping now delegate through a host-owned helper; concrete registration callbacks now come from `src/extension-host/plugin-registry.ts` while `src/plugins/registry.ts` remains the external wrapper. |
| Plugin registry compatibility facade | `src/plugins/registry.ts` | `src/extension-host/plugin-registry.ts` | `partial` | The compatibility plugin-registry facade now delegates through a host-owned helper; `src/plugins/registry.ts` mainly defines shared types and forwards to the host-owned facade. |
@ -104,6 +105,7 @@ That pattern has been used for:
- active registry ownership
- normalized extension schema and resolved-extension records
- static consumers such as skills, validation, auto-enable, and config baseline generation
- plugin tool resolution, conflict handling, optional-tool gating, and plugin-tool metadata tracking
- loader compatibility, cache control, initial candidate planning, entry-path import, explicit discovery-policy outcomes, explicit activation-policy outcomes, runtime decisions, post-import register flow, per-candidate orchestration, top-level load orchestration, session-owned activation state, explicit loader lifecycle transitions, explicit finalization-policy results, and final cache plus activation finalization
- service startup, stop ordering, and failure logging
- CLI duplicate detection, registrar invocation, and async failure logging