vultr/openclaw
1
0
Fork 0
mirror of https://github.com/openclaw/openclaw.git synced 2026-03-25 08:52:12 +00:00
Code Issues Packages Projects Releases Wiki Activity

Docs: refresh extension host migration status

Browse Source
This commit is contained in:
Gustavo Madeira Santana
2026-03-15 14:56:54 +00:00
parent ae6210d789
commit 9cbdb075f3
6 changed files with 25 additions and 12 deletions
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

@@ -37,7 +37,8 @@ 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 cache key construction and registry cache control now route through `src/extension-host/loader-cache.ts`
- loader provenance, duplicate-order, and warning policy now route through `src/extension-host/loader-policy.ts`
- loader provenance, duplicate-order, and record/error policy now route through `src/extension-host/loader-policy.ts`
- loader discovery policy outcomes now route through `src/extension-host/loader-discovery-policy.ts`
- loader initial candidate planning and record creation now route through `src/extension-host/loader-records.ts`
- loader entry-path opening and module import now route through `src/extension-host/loader-import.ts`
- loader module-export resolution, config validation, and memory-slot load decisions now route through `src/extension-host/loader-runtime.ts`
@@ -61,6 +62,7 @@ How it has been implemented:
- 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 converting the compatibility record-state layer into an enforced loader lifecycle state machine before catalog publication work
- by moving mutable activation state into a host-owned loader session before catalog publication work
- by turning open-allowlist discovery warnings into explicit host-owned discovery-policy results before catalog publication work
- by moving duplicate precedence, config enablement, and early memory-slot gating into explicit host-owned activation-policy outcomes before catalog publication work
- by turning provenance-based untracked-extension warnings and final memory-slot warnings into explicit host-owned finalization-policy results before catalog publication work

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

@@ -41,7 +41,8 @@ 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 cache key construction and registry cache control now route through `src/extension-host/loader-cache.ts`
- loader provenance, duplicate-order, and warning policy now route through `src/extension-host/loader-policy.ts`
- loader provenance, duplicate-order, and record/error policy now route through `src/extension-host/loader-policy.ts`
- loader discovery policy outcomes now route through `src/extension-host/loader-discovery-policy.ts`
- loader initial candidate planning and record creation now route through `src/extension-host/loader-records.ts`
- loader entry-path opening and module import now route through `src/extension-host/loader-import.ts`
- loader module-export resolution, config validation, and memory-slot load decisions now route through `src/extension-host/loader-runtime.ts`
@@ -65,6 +66,7 @@ How it has been implemented:
- 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 turning the compatibility record-state layer into an enforced loader lifecycle state machine before broadening the schema-driven host lifecycle model
- by moving mutable activation state into a host-owned loader session before broadening the schema-driven host lifecycle model
- by turning open-allowlist discovery warnings into explicit host-owned discovery-policy results before broadening the schema-driven host lifecycle model
- by moving duplicate precedence, config enablement, and early memory-slot gating into explicit host-owned activation-policy outcomes before broadening the schema-driven host lifecycle model
- by turning provenance-based untracked-extension warnings and final memory-slot warnings into explicit host-owned finalization-policy results before broadening the schema-driven host lifecycle model

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

@@ -62,7 +62,8 @@ 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 cache key construction and registry cache control now route through `src/extension-host/loader-cache.ts`
- loader provenance, duplicate-order, and warning policy now route through `src/extension-host/loader-policy.ts`
- loader provenance, duplicate-order, and record/error policy now route through `src/extension-host/loader-policy.ts`
- loader discovery policy outcomes now route through `src/extension-host/loader-discovery-policy.ts`
- loader initial candidate planning and record creation now route through `src/extension-host/loader-records.ts`
- loader entry-path opening and module import now route through `src/extension-host/loader-import.ts`
- loader module-export resolution, config validation, and memory-slot load decisions now route through `src/extension-host/loader-runtime.ts`
@@ -108,6 +109,7 @@ How it has been done:
- by turning that compatibility `lifecycleState` field into an enforced loader lifecycle state machine with readiness promotion during finalization
- by moving the remaining top-level loader orchestration into a host-owned module so `src/plugins/loader.ts` becomes a compatibility facade instead of the real owner
- by moving mutable activation state such as seen-id tracking, memory-slot selection, and finalization inputs into a host-owned loader session instead of leaving them in top-level loader variables
- by turning open-allowlist discovery warnings into explicit host-owned discovery-policy results before the orchestrator logs them
- by moving duplicate precedence, config enablement, and early memory-slot gating into explicit host-owned activation-policy outcomes instead of leaving them inline in the loader flow
- by turning provenance-based untracked-extension warnings and final memory-slot warnings into explicit host-owned finalization-policy results before the finalizer applies them
- by moving central readers first, so later lifecycle and compatibility work can land on one boundary instead of many ad hoc call sites
@@ -129,13 +131,14 @@ Committed implementation slices so far:
- `da9aad0c0f` `Plugins: add loader activation session`
- `fc51ce2867` `Plugins: add loader activation policy`
- `fd7488e10a` `Plugins: add loader finalization policy`
- `97e2af7f97` `Plugins: add loader discovery policy`
- `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, session-owned activation state, and explicit 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, 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
@@ -325,7 +328,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 cache control, loader policy, loader activation-policy outcomes, loader finalization-policy outcomes, loader candidate planning, loader import flow, loader runtime decisions, loader post-import register flow, loader candidate orchestration, loader top-level load orchestration, loader session state, loader record-state helpers, and loader finalization now route through `src/extension-host/*`
- activation, loader cache control, loader policy, loader discovery-policy outcomes, loader activation-policy outcomes, loader finalization-policy outcomes, loader candidate planning, loader import flow, loader runtime decisions, loader post-import register flow, loader candidate orchestration, loader top-level load orchestration, loader session state, loader record-state helpers, and loader finalization now route through `src/extension-host/*`
- broader lifecycle state ownership beyond the loader state machine, activation states, policy evaluation, and broad host-owned registries are still not implemented
### Phase 3: Build compatibility bridges
@@ -493,7 +496,7 @@ If you want the lowest-risk start, do this first:
Status of this slice:
- steps 2 through 6 are underway
- step 1 is still missing as a formal artifact
- step 1 has landed as `src/extension-host/cutover-inventory.md`
- steps 7 and 8 have not started
Concrete landings from this slice:

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

@@ -39,7 +39,8 @@ 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 cache key construction and registry cache control now route through `src/extension-host/loader-cache.ts`
- loader provenance, duplicate-order, and warning policy now route through `src/extension-host/loader-policy.ts`
- loader provenance, duplicate-order, and record/error policy now route through `src/extension-host/loader-policy.ts`
- loader discovery policy outcomes now route through `src/extension-host/loader-discovery-policy.ts`
- loader initial candidate planning and record creation now route through `src/extension-host/loader-records.ts`
- loader entry-path opening and module import now route through `src/extension-host/loader-import.ts`
- loader module-export resolution, config validation, and memory-slot load decisions now route through `src/extension-host/loader-runtime.ts`
@@ -75,12 +76,13 @@ How it has been implemented:
- by adding explicit compatibility `lifecycleState` mapping on loader-owned plugin records before enforcing the loader lifecycle state machine
- by promoting successfully registered plugins to `ready` during host-owned finalization while leaving broader activation-state semantics for later phases
- by moving mutable activation state such as seen-id tracking, memory-slot selection, and finalization inputs into a host-owned loader session before broader activation-state semantics move
- by turning open-allowlist discovery warnings into explicit host-owned discovery-policy results before the orchestrator logs them
- by moving duplicate precedence, config enablement, and early memory-slot gating into explicit host-owned activation-policy outcomes before broader policy semantics move
- by turning provenance-based untracked-extension warnings and final memory-slot warnings into explicit host-owned finalization-policy results before the finalizer applies them
What is still pending from this spec:
- broader extension-host lifecycle ownership beyond the loader state machine, session-owned activation state, and explicit activation-policy and finalization-policy outcomes
- broader extension-host lifecycle ownership beyond the loader state machine, 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

@@ -44,6 +44,7 @@ Relevant prerequisite work that has landed:
- loader post-import planning and `register(...)` execution now have a host-owned helper boundary
- loader per-candidate orchestration now has a host-owned helper boundary
- loader top-level load orchestration now has a host-owned helper boundary
- loader discovery policy outcomes now have a host-owned helper boundary
- loader mutable activation state now has a host-owned helper boundary
- loader activation policy outcomes now have a host-owned helper boundary
- loader record-state transitions now have a host-owned helper boundary and enforced loader lifecycle state machine, while still preserving compatibility `PluginRecord.status` values
@@ -53,7 +54,7 @@ Relevant prerequisite work that has landed:
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 bridge or stage work before those earlier boundaries were in place, including the first loader-runtime, record-state, activation-policy, and finalization-policy seams
- the current implementation has deliberately not started bridge or stage work before those earlier boundaries were in place, including the first loader-runtime, record-state, discovery-policy, activation-policy, and finalization-policy seams
## Design Goals

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

@@ -47,7 +47,8 @@ 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 cache key construction and registry cache control now route through `src/extension-host/loader-cache.ts`
- loader provenance, duplicate-order, and warning policy now route through `src/extension-host/loader-policy.ts`
- loader provenance, duplicate-order, and record/error policy now route through `src/extension-host/loader-policy.ts`
- loader discovery policy outcomes now route through `src/extension-host/loader-discovery-policy.ts`
- loader initial candidate planning and record creation now route through `src/extension-host/loader-records.ts`
- loader entry-path opening and module import now route through `src/extension-host/loader-import.ts`
- loader module-export resolution, config validation, and memory-slot load decisions now route through `src/extension-host/loader-runtime.ts`
@@ -94,6 +95,7 @@ How it was done:
- by turning that compatibility `lifecycleState` field into an enforced loader lifecycle state machine with readiness promotion during finalization
- by moving the remaining top-level loader orchestration into a host-owned module so `src/plugins/loader.ts` becomes a compatibility facade instead of the real owner
- by moving mutable activation state such as seen-id tracking, memory-slot selection, and finalization inputs into a host-owned loader session instead of leaving them in top-level loader variables
- by turning open-allowlist discovery warnings into explicit host-owned discovery-policy results before the orchestrator logs them
- by moving duplicate precedence, config enablement, and early memory-slot gating into explicit host-owned activation-policy outcomes instead of leaving them inline in the loader flow
- by turning provenance-based untracked-extension warnings and final memory-slot warnings into explicit host-owned finalization-policy results before the finalizer applies them
- by moving static and lookup-heavy consumers first, where the ownership boundary matters but runtime risk is lower
@@ -114,13 +116,14 @@ Committed implementation slices so far:
- `da9aad0c0f` `Plugins: add loader activation session`
- `fc51ce2867` `Plugins: add loader activation policy`
- `fd7488e10a` `Plugins: add loader finalization policy`
- `97e2af7f97` `Plugins: add loader discovery policy`
- `89414ed857` `Docs: track extension host migration internally`
- `d8af1eceaf` `Docs: refresh extension host migration status`
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 activation-policy and finalization-policy outcomes, plus remaining policy semantics
- 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 channel, provider, HTTP-route, gateway-method, tool, CLI, service, command, context-engine, and hook helper slices
- SDK compatibility translation work
- canonical event stages
@@ -1336,7 +1339,7 @@ Current implementation status:
- partially implemented in a compatibility-preserving form
- the host now owns active registry state
- the host now exposes resolved static registries for static consumers
- activation, loader cache control, loader policy, loader activation-policy outcomes, loader finalization-policy outcomes, loader runtime decisions, loader top-level load orchestration, loader session state, loader record-state helpers, and loader finalization now route through `src/extension-host/*`
- activation, loader cache control, loader policy, loader discovery-policy outcomes, loader activation-policy outcomes, loader finalization-policy outcomes, loader runtime decisions, loader top-level load orchestration, loader session state, loader record-state helpers, and loader finalization now route through `src/extension-host/*`
- broader lifecycle ownership beyond the loader state machine, registration surfaces, policy gates, and activation-state management are still pending
## Phase 3: Broader Legacy Compatibility Bridges