diff --git a/docs/.internal/extension-host-migration/openclaw-capability-catalog-and-arbitration-spec.md b/docs/.internal/extension-host-migration/openclaw-capability-catalog-and-arbitration-spec.md index 3d22f10d6fb..bcbec124007 100644 --- a/docs/.internal/extension-host-migration/openclaw-capability-catalog-and-arbitration-spec.md +++ b/docs/.internal/extension-host-migration/openclaw-capability-catalog-and-arbitration-spec.md @@ -39,6 +39,7 @@ What has been implemented: - 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 post-import planning and `register(...)` execution now route through `src/extension-host/loader-register.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 @@ -48,7 +49,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, candidate-planning, policy, runtime, and record-state helpers before attempting canonical catalog publication +- by beginning loader-path migration with host-owned compatibility, candidate-planning, policy, runtime, register-flow, and record-state helpers before attempting canonical catalog publication What remains pending: diff --git a/docs/.internal/extension-host-migration/openclaw-extension-contribution-schema-spec.md b/docs/.internal/extension-host-migration/openclaw-extension-contribution-schema-spec.md index 68d2df22dd7..e60e3f21401 100644 --- a/docs/.internal/extension-host-migration/openclaw-extension-contribution-schema-spec.md +++ b/docs/.internal/extension-host-migration/openclaw-extension-contribution-schema-spec.md @@ -43,6 +43,7 @@ What has been implemented: - 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 post-import planning and `register(...)` execution now route through `src/extension-host/loader-register.ts` - loader record-state transitions now route through `src/extension-host/loader-state.ts` How it has been implemented: @@ -52,7 +53,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, candidate-planning, and runtime decisions explicit host-owned helpers before introducing a versioned compatibility layer +- by making the first loader compatibility, candidate-planning, runtime-decision, and register-flow helpers explicit host-owned seams before introducing a versioned compatibility layer What remains pending: diff --git a/docs/.internal/extension-host-migration/openclaw-extension-host-implementation-guide.md b/docs/.internal/extension-host-migration/openclaw-extension-host-implementation-guide.md index d17feeac7f8..08552f9337d 100644 --- a/docs/.internal/extension-host-migration/openclaw-extension-host-implementation-guide.md +++ b/docs/.internal/extension-host-migration/openclaw-extension-host-implementation-guide.md @@ -64,6 +64,7 @@ What has been implemented so far: - 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 post-import planning and `register(...)` execution now route through `src/extension-host/loader-register.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 - several static and lookup consumers now read through the host boundary or resolved-extension model: @@ -89,6 +90,7 @@ How it has been done: - 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 post-import planning and `register(...)` execution behind host-owned helpers before changing entry-path and import flow - 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 @@ -98,12 +100,14 @@ Committed implementation slices so far: - `6abf6750ee` `Plugins: add extension host registry boundary` - `1aab89e820` `Plugins: extract loader host seams` - `7bc3135082` `Plugins: extract loader candidate planning` +- `3a122c95fa` `Plugins: extract loader register flow` - `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 -- the lifecycle state machine, remaining per-plugin import and registration flow, policy gate, and broad host-owned registries described for Phase 2 +- the lifecycle state machine, remaining entry-path and import 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 @@ -293,7 +297,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 candidate planning, loader runtime decisions, and loader record-state helpers now route through `src/extension-host/*` +- activation, loader policy, loader candidate planning, loader runtime decisions, loader post-import register flow, 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 diff --git a/docs/.internal/extension-host-migration/openclaw-extension-host-lifecycle-and-security-spec.md b/docs/.internal/extension-host-migration/openclaw-extension-host-lifecycle-and-security-spec.md index db3534473a6..31bc8843885 100644 --- a/docs/.internal/extension-host-migration/openclaw-extension-host-lifecycle-and-security-spec.md +++ b/docs/.internal/extension-host-migration/openclaw-extension-host-lifecycle-and-security-spec.md @@ -40,6 +40,7 @@ What has been implemented: - 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 post-import planning and `register(...)` execution now route through `src/extension-host/loader-register.ts` - loader record-state transitions now route through `src/extension-host/loader-state.ts` How it has been implemented: @@ -55,6 +56,7 @@ How it has been implemented: - 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 post-import planning and `register(...)` execution next while leaving entry-path and import flow unchanged - by moving record-state transitions next while leaving the lifecycle state machine itself unimplemented What is still pending from this spec: diff --git a/docs/.internal/extension-host-migration/openclaw-kernel-event-pipeline-spec.md b/docs/.internal/extension-host-migration/openclaw-kernel-event-pipeline-spec.md index 493c055a929..92d0f42ec91 100644 --- a/docs/.internal/extension-host-migration/openclaw-kernel-event-pipeline-spec.md +++ b/docs/.internal/extension-host-migration/openclaw-kernel-event-pipeline-spec.md @@ -39,6 +39,7 @@ Relevant prerequisite work that has landed: - 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 post-import planning and `register(...)` execution now have a host-owned helper boundary - loader record-state transitions now have a host-owned helper boundary Why this matters for this spec: diff --git a/docs/.internal/extension-host-migration/openclaw-kernel-extension-host-transition-plan.md b/docs/.internal/extension-host-migration/openclaw-kernel-extension-host-transition-plan.md index 14070909ac4..5c047579ade 100644 --- a/docs/.internal/extension-host-migration/openclaw-kernel-extension-host-transition-plan.md +++ b/docs/.internal/extension-host-migration/openclaw-kernel-extension-host-transition-plan.md @@ -49,6 +49,7 @@ What has landed: - 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 post-import planning and `register(...)` execution now route through `src/extension-host/loader-register.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 - several existing consumers now read host-owned normalized data instead of plugin-era manifest or runtime state directly: @@ -75,6 +76,7 @@ How it was done: - 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 post-import planning and `register(...)` execution behind host-owned helpers before changing entry-path and import flow - 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 @@ -83,13 +85,15 @@ Committed implementation slices so far: - `6abf6750ee` `Plugins: add extension host registry boundary` - `1aab89e820` `Plugins: extract loader host seams` - `7bc3135082` `Plugins: extract loader candidate planning` +- `3a122c95fa` `Plugins: extract loader register flow` - `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 - the lifecycle state machine and remaining loader orchestration -- the remaining per-plugin import and registration flow in the loader +- the remaining entry-path opening and import 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