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:28:23 +00:00
parent 2ad45cf8d2
commit f996804369
No known key found for this signature in database
7 changed files with 19 additions and 6 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

@ -67,6 +67,7 @@ What has been implemented:
- compatibility plugin-registry policy now routes through `src/extension-host/plugin-registry-compat.ts` ahead of broader catalog-backed registry ownership
- compatibility plugin-registry registration actions now route through `src/extension-host/plugin-registry-registrations.ts` ahead of broader catalog-backed registry ownership
- 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
How it has been implemented:
@ -96,6 +97,7 @@ How it has been implemented:
- by extracting provider normalization, command duplicate enforcement, and registry-local diagnostic shaping into a host-owned registry-compat helper while leaving the underlying provider-validation and plugin-command subsystems unchanged
- by extracting low-risk registry registration actions into a host-owned registry-registrations helper so the compatibility facade composes host-owned actions instead of implementing them inline
- 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
What remains pending:

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

@ -46,6 +46,7 @@ What has been implemented:
- compatibility plugin-registry policy now routes through `src/extension-host/plugin-registry-compat.ts`
- compatibility plugin-registry registration actions now route through `src/extension-host/plugin-registry-registrations.ts`
- 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`
- 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`
@ -100,6 +101,7 @@ How it has been implemented:
- by extracting provider normalization, command duplicate enforcement, and registry-local diagnostic shaping into a host-owned registry-compat helper while leaving the underlying provider-validation and plugin-command subsystems unchanged
- by extracting low-risk registry registration actions into a host-owned registry-registrations helper so the compatibility facade composes host-owned actions instead of implementing them inline
- 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
What remains pending:

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

@ -92,6 +92,7 @@ What has been implemented so far:
- compatibility plugin-registry policy now routes through `src/extension-host/plugin-registry-compat.ts`
- compatibility plugin-registry registration actions now route through `src/extension-host/plugin-registry-registrations.ts`
- 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`
- several static and lookup consumers now read through the host boundary or resolved-extension model:
- channel registry and dock lookups
- message-channel normalization
@ -143,6 +144,7 @@ How it has been done:
- by extracting provider normalization, command duplicate enforcement, and registry-local diagnostic shaping into a host-owned registry-compat helper while leaving the underlying provider-validation and plugin-command subsystems unchanged
- by extracting low-risk registry registration actions into a host-owned registry-registrations helper so the compatibility facade composes host-owned actions instead of implementing them inline
- 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 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
@ -180,13 +182,14 @@ Committed implementation slices so far:
- `944d787df1` `Plugins: extract registry compatibility policy`
- `4ca9cd7e5e` `Plugins: extract registry registration actions`
- `6b24e65719` `Plugins: extract service lifecycle`
- `b5757a6625` `Plugins: extract CLI lifecycle`
- `89414ed857` `Docs: track extension host migration internally`
- `d8af1eceaf` `Docs: refresh extension host migration status`
What is still missing for these phases:
- keeping the cutover inventory current as more surfaces move
- broader lifecycle ownership beyond the loader state machine, service-lifecycle boundary, session-owned activation state, and explicit discovery-policy, activation-policy, and finalization-policy outcomes, remaining policy gate ownership, and broad host-owned registries described for Phase 2
- broader lifecycle ownership beyond the loader state machine, service-lifecycle boundary, CLI-lifecycle boundary, session-owned activation state, and explicit discovery-policy, activation-policy, and finalization-policy outcomes, remaining policy gate ownership, and broad host-owned registries described for Phase 2
- minimal SDK compatibility work beyond preserving current behavior indirectly through existing loading
- any pilot migration, event pipeline, canonical catalog, or arbitration implementation

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

@ -27,7 +27,7 @@ Current status against this spec:
- registry ownership and the first compatibility-preserving loader slices have landed
- a loader-scoped lifecycle state machine has landed
- broader lifecycle orchestration, policy gates, and activation-state management beyond the current loader and service seams have not landed
- broader lifecycle orchestration, policy gates, and activation-state management beyond the current loader, service, and CLI seams have not landed
What has been implemented:
@ -45,6 +45,7 @@ What has been implemented:
- compatibility plugin-registry policy now delegates through `src/extension-host/plugin-registry-compat.ts`
- compatibility plugin-registry registration actions now delegate through `src/extension-host/plugin-registry-registrations.ts`
- 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`
- 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`
@ -110,10 +111,11 @@ How it has been implemented:
- by extracting provider normalization, command duplicate enforcement, and registry-local diagnostic shaping into a host-owned registry-compat helper while leaving the underlying provider-validation and plugin-command subsystems unchanged
- by extracting low-risk registry registration actions into a host-owned registry-registrations helper so the compatibility facade composes host-owned actions instead of implementing them inline
- 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
What is still pending from this spec:
- broader extension-host lifecycle ownership beyond the loader state machine, service-lifecycle boundary, session-owned activation state, and explicit discovery-policy, activation-policy, and finalization-policy outcomes
- broader extension-host lifecycle ownership beyond the loader state machine, service-lifecycle boundary, CLI-lifecycle boundary, session-owned activation state, and explicit discovery-policy, activation-policy, and finalization-policy outcomes
- activation pipeline ownership
- host-owned registries for setup, CLI, routes, services, slots, and backends
- permission-mode enforcement

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

@ -66,11 +66,12 @@ Relevant prerequisite work that has landed:
- compatibility plugin-registry policy now has a host-owned helper boundary in `src/extension-host/plugin-registry-compat.ts`
- compatibility plugin-registry registration actions now have a host-owned helper boundary in `src/extension-host/plugin-registry-registrations.ts`
- 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`
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, and service-lifecycle 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, and CLI-lifecycle seams
## Design Goals

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

@ -77,6 +77,7 @@ What has landed:
- compatibility plugin-registry policy now routes through `src/extension-host/plugin-registry-compat.ts`
- compatibility plugin-registry registration actions now route through `src/extension-host/plugin-registry-registrations.ts`
- 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`
- 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
@ -129,6 +130,7 @@ How it was done:
- by extracting provider normalization, command duplicate enforcement, and registry-local diagnostic shaping into a host-owned registry-compat helper while leaving the underlying provider-validation and plugin-command subsystems unchanged
- by extracting low-risk registry registration actions into a host-owned registry-registrations helper so the compatibility facade composes host-owned actions instead of implementing them inline
- 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 moving static and lookup-heavy consumers first, where the ownership boundary matters but runtime risk is lower
Committed implementation slices so far:
@ -165,6 +167,7 @@ Committed implementation slices so far:
- `944d787df1` `Plugins: extract registry compatibility policy`
- `4ca9cd7e5e` `Plugins: extract registry registration actions`
- `6b24e65719` `Plugins: extract service lifecycle`
- `b5757a6625` `Plugins: extract CLI lifecycle`
- `89414ed857` `Docs: track extension host migration internally`
- `d8af1eceaf` `Docs: refresh extension host migration status`

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

@ -82,7 +82,7 @@ This is an implementation checklist, not a future-design spec.
| Hook compatibility policy and bridging | `src/plugins/registry.ts` | `src/extension-host/hook-compat.ts` | `partial` | Legacy internal-hook bridging and typed prompt-injection compatibility policy now delegate through a host-owned helper; actual hook execution ownership remains legacy-owned. |
| Hook execution and global runner | `src/plugins/hook-runner-global.ts`, `src/hooks/internal-hooks.ts`, plugin hook registration in `src/plugins/registry.ts` | canonical kernel event stages + host bridges | `not started` | No canonical event-stage migration has landed yet. |
| Service lifecycle | `src/plugins/services.ts` and plugin service registration | `src/extension-host/service-lifecycle.ts` | `partial` | Service startup, stop ordering, service-context creation, and failure logging now delegate through a host-owned service-lifecycle helper while `src/plugins/services.ts` remains the compatibility entry point. |
| CLI registration | plugin CLI registration in `src/plugins/registry.ts` and CLI loaders | extension host registry + static descriptors where possible | `not started` | No host-owned CLI registry exists yet. |
| CLI registration | plugin CLI registration in `src/plugins/registry.ts` and CLI loaders | `src/extension-host/cli-lifecycle.ts` plus static descriptors where possible | `partial` | CLI duplicate detection, registrar invocation, and async failure logging now delegate through a host-owned CLI-lifecycle helper while `src/plugins/cli.ts` remains the compatibility entry point. |
| Gateway/server methods | `src/plugins/registry.ts` gateway handler registration | host-owned runtime contribution registry | `not started` | Still registered directly into the legacy plugin registry. |
| Slot arbitration | `src/plugins/slots.ts` | host-owned arbitration model | `not started` | Current slot selection remains plugin-era logic. |
| ACP backend registry | `src/acp/runtime/registry.ts` | host-owned runtime-backend registry | `not started` | ACP backends still mutate a global ACP runtime registry directly. |
@ -106,6 +106,7 @@ That pattern has been used for:
- static consumers such as skills, validation, auto-enable, and config baseline generation
- 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
## Immediate Next Targets
@ -126,7 +127,6 @@ The following remain legacy-owned today:
- activation ordering
- policy gates
- typed and legacy hook execution
- CLI registration
- gateway/server method registration
- slot arbitration
- ACP backend registration