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 c053bd486cd..0fd9778ea4f 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 @@ -43,6 +43,7 @@ What has been implemented: - loader post-import planning and `register(...)` execution now route through `src/extension-host/loader-register.ts` - loader per-candidate orchestration now routes through `src/extension-host/loader-flow.ts` - loader record-state transitions now route through `src/extension-host/loader-state.ts` +- loader final cache, warning, and activation finalization now routes through `src/extension-host/loader-finalize.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 How it has been implemented: @@ -51,7 +52,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, import-flow, policy, runtime, register-flow, candidate-orchestration, and record-state helpers before attempting canonical catalog publication +- by beginning loader-path migration with host-owned compatibility, candidate-planning, import-flow, policy, runtime, register-flow, candidate-orchestration, record-state, and finalization 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 f62368d3726..e1282923420 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 @@ -47,6 +47,7 @@ What has been implemented: - loader post-import planning and `register(...)` execution now route through `src/extension-host/loader-register.ts` - loader per-candidate orchestration now routes through `src/extension-host/loader-flow.ts` - loader record-state transitions now route through `src/extension-host/loader-state.ts` +- loader final cache, warning, and activation finalization now routes through `src/extension-host/loader-finalize.ts` How it has been implemented: @@ -55,7 +56,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, import-flow, runtime-decision, register-flow, and candidate-orchestration helpers explicit host-owned seams before introducing a versioned compatibility layer +- by making the first loader compatibility, candidate-planning, import-flow, runtime-decision, register-flow, candidate-orchestration, record-state, and finalization 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 f248f24368f..78397ba5ac5 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 @@ -68,6 +68,7 @@ What has been implemented so far: - loader post-import planning and `register(...)` execution now route through `src/extension-host/loader-register.ts` - loader per-candidate orchestration now routes through `src/extension-host/loader-flow.ts` - loader record-state transitions now route through `src/extension-host/loader-state.ts` +- loader final cache, warning, and activation finalization now routes through `src/extension-host/loader-finalize.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: - channel registry and dock lookups @@ -96,6 +97,7 @@ How it has been done: - by moving post-import planning and `register(...)` execution behind host-owned helpers before changing entry-path and import flow - by composing those seams into one host-owned per-candidate orchestrator before changing cache and lifecycle finalization behavior - by moving loader record-state transitions into host-owned helpers before introducing a full lifecycle state machine +- by moving cache writes, provenance warnings, final memory-slot warnings, and activation into a host-owned loader finalizer before introducing an explicit 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 @@ -107,13 +109,14 @@ Committed implementation slices so far: - `3a122c95fa` `Plugins: extract loader register flow` - `fc81454038` `Plugins: extract loader import flow` - `e1b207f4cf` `Plugins: extract loader candidate orchestration` +- `0c44d8049b` `Plugins: extract loader finalization` - `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 cache and final registry orchestration flow, policy gate, and broad host-owned registries described for Phase 2 +- the lifecycle state machine, remaining explicit activation-state ownership, 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 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 db5f7d8b202..b331c31ffd5 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 @@ -44,6 +44,7 @@ What has been implemented: - loader post-import planning and `register(...)` execution now route through `src/extension-host/loader-register.ts` - loader per-candidate orchestration now routes through `src/extension-host/loader-flow.ts` - loader record-state transitions now route through `src/extension-host/loader-state.ts` +- loader final cache, warning, and activation finalization now routes through `src/extension-host/loader-finalize.ts` How it has been implemented: @@ -62,6 +63,7 @@ How it has been implemented: - by moving post-import planning and `register(...)` execution next while leaving entry-path and import flow unchanged - by composing those seams into one host-owned per-candidate loader orchestrator before moving final lifecycle-state behavior - by moving record-state transitions next while leaving the lifecycle state machine itself unimplemented +- by moving cache writes, provenance warnings, final memory-slot warnings, and activation into a host-owned loader finalizer before introducing an explicit lifecycle state machine 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 440623e2678..1338fce4bcf 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 @@ -43,6 +43,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 record-state transitions now have a host-owned helper boundary +- loader final cache, warning, and activation finalization now has 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 7a0eebe0e47..0c4caaf3ad5 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 @@ -53,6 +53,7 @@ What has landed: - loader post-import planning and `register(...)` execution now route through `src/extension-host/loader-register.ts` - loader per-candidate orchestration now routes through `src/extension-host/loader-flow.ts` - loader record-state transitions now route through `src/extension-host/loader-state.ts` +- loader final cache, warning, and activation finalization now routes through `src/extension-host/loader-finalize.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: - channel and dock lookup surfaces @@ -82,6 +83,7 @@ How it was done: - by moving post-import planning and `register(...)` execution behind host-owned helpers before changing entry-path and import flow - by composing those seams into one host-owned per-candidate orchestrator before changing cache and lifecycle finalization behavior - by moving loader record-state transitions into host-owned helpers before introducing a full lifecycle state machine +- by moving cache writes, provenance warnings, final memory-slot warnings, and activation into a host-owned loader finalizer before introducing an explicit 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: @@ -92,14 +94,14 @@ Committed implementation slices so far: - `3a122c95fa` `Plugins: extract loader register flow` - `fc81454038` `Plugins: extract loader import flow` - `e1b207f4cf` `Plugins: extract loader candidate orchestration` +- `0c44d8049b` `Plugins: extract loader finalization` - `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 cache wiring and final registry orchestration in the loader +- the lifecycle state machine and remaining explicit activation-state ownership - 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