nyrn
/
openclaw
mirror of https://github.com/openclaw/openclaw.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Docs: refresh extension host migration status

This commit is contained in:
Gustavo Madeira Santana 2026-03-15 17:21:27 +00:00
parent 4ca9cd7e5e
commit 278f1c4268
No known key found for this signature in database
7 changed files with 15 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

@ -65,6 +65,7 @@ What has been implemented:
- compatibility `OpenClawPluginApi` composition and logger shaping now route through `src/extension-host/plugin-api.ts` ahead of broader catalog-backed registry ownership
- compatibility plugin-registry facade ownership now routes through `src/extension-host/plugin-registry.ts` ahead of broader catalog-backed registry ownership
- 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
How it has been implemented:
@ -92,6 +93,7 @@ How it has been implemented:
- by extracting compatibility `OpenClawPluginApi` composition and logger shaping into a host-owned plugin-api helper while keeping the concrete registration callbacks in the legacy registry surface
- by extracting the remaining compatibility plugin-registry facade into a host-owned helper so `src/plugins/registry.ts` becomes a thin wrapper instead of the real owner
- 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
What remains pending:

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

@ -44,6 +44,7 @@ What has been implemented:
- compatibility `OpenClawPluginApi` composition and logger shaping now route through `src/extension-host/plugin-api.ts`
- compatibility plugin-registry facade ownership now routes through `src/extension-host/plugin-registry.ts`
- 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`
- 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`
@ -96,6 +97,7 @@ How it has been implemented:
- by extracting compatibility `OpenClawPluginApi` composition and logger shaping into a host-owned plugin-api helper while keeping the concrete registration callbacks in the legacy registry surface
- by extracting the remaining compatibility plugin-registry facade into a host-owned helper so `src/plugins/registry.ts` becomes a thin wrapper instead of the real owner
- 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
What remains pending:

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

@ -90,6 +90,7 @@ What has been implemented so far:
- compatibility `OpenClawPluginApi` composition and logger shaping now route through `src/extension-host/plugin-api.ts`
- compatibility plugin-registry facade ownership now routes through `src/extension-host/plugin-registry.ts`
- 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`
- several static and lookup consumers now read through the host boundary or resolved-extension model:
- channel registry and dock lookups
- message-channel normalization
@ -139,6 +140,7 @@ How it has been done:
- by extracting compatibility `OpenClawPluginApi` composition and logger shaping into a host-owned plugin-api helper while keeping the concrete registration callbacks in the legacy registry surface
- by extracting the remaining compatibility plugin-registry facade into a host-owned helper so `src/plugins/registry.ts` becomes a thin wrapper instead of the real owner
- 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 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
@ -174,6 +176,7 @@ Committed implementation slices so far:
- `a1e1dcc01a` `Plugins: extract plugin api facade`
- `0e190d64d4` `Plugins: extract registry compatibility facade`
- `944d787df1` `Plugins: extract registry compatibility policy`
- `4ca9cd7e5e` `Plugins: extract registry registration actions`
- `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

@ -43,6 +43,7 @@ What has been implemented:
- compatibility `OpenClawPluginApi` composition and logger shaping now delegate through `src/extension-host/plugin-api.ts`
- compatibility plugin-registry facade ownership now delegates through `src/extension-host/plugin-registry.ts`
- 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`
- 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`
@ -106,6 +107,7 @@ How it has been implemented:
- by extracting compatibility `OpenClawPluginApi` composition and logger shaping into a host-owned plugin-api helper while keeping the concrete registration callbacks in the legacy registry surface
- by extracting the remaining compatibility plugin-registry facade into a host-owned helper so `src/plugins/registry.ts` becomes a thin wrapper instead of the real owner
- 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
What is still pending from this spec:

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

@ -64,11 +64,12 @@ Relevant prerequisite work that has landed:
- compatibility `OpenClawPluginApi` composition and logger shaping now have a host-owned helper boundary in `src/extension-host/plugin-api.ts`
- compatibility plugin-registry facade ownership now has a host-owned helper boundary in `src/extension-host/plugin-registry.ts`
- 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`
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, and plugin-registry-compat 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, and plugin-registry-registrations seams
## Design Goals

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

@ -75,6 +75,7 @@ What has landed:
- compatibility `OpenClawPluginApi` composition and logger shaping now route through `src/extension-host/plugin-api.ts`
- compatibility plugin-registry facade ownership now routes through `src/extension-host/plugin-registry.ts`
- 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`
- 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
@ -125,6 +126,7 @@ How it was done:
- by extracting compatibility `OpenClawPluginApi` composition and logger shaping into a host-owned plugin-api helper while keeping the concrete registration callbacks in the legacy registry surface
- by extracting the remaining compatibility plugin-registry facade into a host-owned helper so `src/plugins/registry.ts` becomes a thin wrapper instead of the real owner
- 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 moving static and lookup-heavy consumers first, where the ownership boundary matters but runtime risk is lower
Committed implementation slices so far:
@ -159,6 +161,7 @@ Committed implementation slices so far:
- `a1e1dcc01a` `Plugins: extract plugin api facade`
- `0e190d64d4` `Plugins: extract registry compatibility facade`
- `944d787df1` `Plugins: extract registry compatibility policy`
- `4ca9cd7e5e` `Plugins: extract registry registration actions`
- `89414ed857` `Docs: track extension host migration internally`
- `d8af1eceaf` `Docs: refresh extension host migration status`

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

@ -67,6 +67,7 @@ This is an implementation checklist, not a future-design spec.
| 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. |
| Plugin registry compatibility policy | mixed inside `src/extension-host/plugin-registry.ts` | `src/extension-host/plugin-registry-compat.ts` | `partial` | Provider normalization, command duplicate enforcement, and registry-local diagnostic shaping now delegate through a host-owned compatibility helper; the underlying provider-validation and plugin-command subsystems still remain legacy-owned. |
| Plugin registry registration actions | mixed inside `src/extension-host/plugin-registry.ts` | `src/extension-host/plugin-registry-registrations.ts` | `partial` | Low-risk registration actions for tools, hooks, gateway methods, HTTP routes, channels, CLI, services, typed hooks, and context engines now delegate through a host-owned helper; the compatibility facade still composes those actions with provider and command compatibility policy. |
| Channel registration writes | `src/plugins/registry.ts` | host-owned channel registry | `partial` | Validation and normalization now delegate to `src/extension-host/runtime-registrations.ts`, and compatibility writes now route through `src/extension-host/registry-writes.ts`; the legacy plugin API still remains the call surface. |
| Provider registration writes | `src/plugins/registry.ts` | host-owned provider registry | `partial` | Provider normalization and compatibility diagnostics now delegate through `src/extension-host/plugin-registry-compat.ts`, duplicate detection and normalized registration shape still delegate to `src/extension-host/runtime-registrations.ts`, and compatibility writes route through `src/extension-host/registry-writes.ts`. |
| HTTP route registration writes | `src/plugins/registry.ts` | host-owned route registry | `partial` | Route validation and normalization now delegate to `src/extension-host/runtime-registrations.ts`, and compatibility append or replace writes now route through `src/extension-host/registry-writes.ts`. |