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 11:31:31 +00:00
parent 7bc3135082
commit d8af1eceaf
No known key found for this signature in database
6 changed files with 28 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -37,6 +37,7 @@ What has been implemented:
- config doc baseline generation now uses the same host-owned resolved-extension metadata path
- plugin SDK alias resolution now routes through `src/extension-host/loader-compat.ts`
- loader provenance, duplicate-order, and warning policy now route through `src/extension-host/loader-policy.ts`
- loader initial candidate planning and record creation now route through `src/extension-host/loader-records.ts`
- loader module-export resolution, config validation, and memory-slot load decisions now route through `src/extension-host/loader-runtime.ts`
- loader record-state transitions now route through `src/extension-host/loader-state.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
@ -47,7 +48,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 loader-path migration with host-owned compatibility, policy, runtime, and record-state helpers before attempting canonical catalog publication
- by beginning loader-path migration with host-owned compatibility, candidate-planning, policy, runtime, and record-state helpers before attempting canonical catalog publication
What remains pending:

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

@ -41,6 +41,7 @@ What has been implemented:
- 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
- plugin SDK alias resolution now routes through `src/extension-host/loader-compat.ts`
- loader provenance, duplicate-order, and warning policy now route through `src/extension-host/loader-policy.ts`
- loader initial candidate planning and record creation now route through `src/extension-host/loader-records.ts`
- loader module-export resolution, config validation, and memory-slot load decisions now route through `src/extension-host/loader-runtime.ts`
- loader record-state transitions now route through `src/extension-host/loader-state.ts`
@ -51,7 +52,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 making the first loader compatibility and runtime decisions explicit host-owned helpers before introducing a versioned compatibility layer
- by making the first loader compatibility, candidate-planning, and runtime decisions explicit host-owned helpers before introducing a versioned compatibility layer
What remains pending:

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

@ -62,6 +62,7 @@ What has been implemented so far:
- an initial Phase 0 inventory now exists in `src/extension-host/cutover-inventory.md`
- plugin SDK alias resolution now routes through `src/extension-host/loader-compat.ts`
- loader provenance, duplicate-order, and warning policy now route through `src/extension-host/loader-policy.ts`
- loader initial candidate planning and record creation now route through `src/extension-host/loader-records.ts`
- loader module-export resolution, config validation, and memory-slot load decisions now route through `src/extension-host/loader-runtime.ts`
- loader record-state transitions now route through `src/extension-host/loader-state.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
@ -86,15 +87,23 @@ How it has been done:
- 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 loader-owned policy helpers next, while keeping module loading and enablement flow behavior unchanged
- by moving initial candidate planning and record construction behind host-owned helpers before changing import and registration flow
- by moving loader runtime decisions behind host-owned helpers while preserving lazy loading, config validation behavior, and memory-slot policy behavior
- by moving loader record-state transitions into host-owned helpers before introducing a full lifecycle state machine
- 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
Committed implementation slices so far:
- `6abf6750ee` `Plugins: add extension host registry boundary`
- `1aab89e820` `Plugins: extract loader host seams`
- `7bc3135082` `Plugins: extract loader candidate planning`
- `89414ed857` `Docs: track extension host migration internally`
What is still missing for these phases:
- keeping the cutover inventory current as more surfaces move
- the lifecycle state machine, remaining loader orchestration, policy gate, and broad host-owned registries described for Phase 2
- the lifecycle state machine, remaining per-plugin import and registration flow, policy gate, 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
@ -284,7 +293,7 @@ Current implementation status:
- the host owns the active registry state
- the host exposes a resolved-extension registry view for static consumers
- plugin skills, plugin auto-enable, and config validation indexing now consume host-owned resolved-extension data
- activation, loader policy, loader runtime decisions, and loader record-state helpers now route through `src/extension-host/*`
- activation, loader policy, loader candidate planning, loader runtime decisions, and loader record-state helpers now route through `src/extension-host/*`
- lifecycle state ownership, activation states, policy evaluation, and broad host-owned registries are still not implemented
### Phase 3: Build compatibility bridges

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

@ -38,6 +38,7 @@ What has been implemented:
- 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`
- loader provenance, duplicate-order, and warning policy now route through `src/extension-host/loader-policy.ts`
- loader initial candidate planning and record creation now route through `src/extension-host/loader-records.ts`
- loader module-export resolution, config validation, and memory-slot load decisions now route through `src/extension-host/loader-runtime.ts`
- loader record-state transitions now route through `src/extension-host/loader-state.ts`
@ -52,6 +53,7 @@ How it has been implemented:
- 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
- by moving provenance and duplicate-order policy next, so lifecycle migration can land on host-owned policy helpers instead of loader-local utilities
- by moving initial candidate planning and record construction next while leaving module import and registration flow unchanged
- by moving loader runtime decisions next while preserving the current lazy-load, config-validation, and memory-slot behavior
- by moving record-state transitions next while leaving the lifecycle state machine itself unimplemented

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

@ -37,6 +37,7 @@ Relevant prerequisite work that has landed:
- config doc baseline generation now uses the same host-owned resolved-extension data path
- channel, provider, HTTP-route, gateway-method, tool, CLI, service, command, context-engine, and hook registration normalization now has a host-owned helper boundary
- loader provenance and duplicate-order policy now have a host-owned helper boundary
- loader initial candidate planning and record creation now have a host-owned helper boundary
- loader module-export resolution, config validation, and memory-slot load decisions now have a host-owned helper boundary
- loader record-state transitions now have a host-owned helper boundary

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

@ -47,6 +47,7 @@ What has landed:
- an initial Phase 0 cutover inventory now exists in `src/extension-host/cutover-inventory.md`
- plugin SDK alias resolution now routes through `src/extension-host/loader-compat.ts`
- loader provenance, duplicate-order, and warning policy now route through `src/extension-host/loader-policy.ts`
- loader initial candidate planning and record creation now route through `src/extension-host/loader-records.ts`
- loader module-export resolution, config validation, and memory-slot load decisions now route through `src/extension-host/loader-runtime.ts`
- loader record-state transitions now route through `src/extension-host/loader-state.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
@ -72,14 +73,23 @@ How it was done:
- 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 the next loader-owned policy helpers behind host-owned modules while preserving the current load/skip/error behavior
- by moving initial candidate planning and record construction behind host-owned helpers before changing import and registration flow
- by moving loader runtime decisions next, while preserving lazy loading, config validation behavior, and memory-slot policy behavior
- by moving loader record-state transitions into host-owned helpers before introducing a full lifecycle state machine
- by moving static and lookup-heavy consumers first, where the ownership boundary matters but runtime risk is lower
Committed implementation slices so far:
- `6abf6750ee` `Plugins: add extension host registry boundary`
- `1aab89e820` `Plugins: extract loader host seams`
- `7bc3135082` `Plugins: extract loader candidate planning`
- `89414ed857` `Docs: track extension host migration internally`
What has not landed:
- keeping the cutover inventory current as more surfaces move
- the lifecycle state machine and remaining loader orchestration
- the remaining per-plugin import and registration flow in the loader
- host-owned registration surfaces beyond the first channel, provider, HTTP-route, gateway-method, tool, CLI, service, command, context-engine, and hook helper slices
- SDK compatibility translation work
- canonical event stages