From af32c026c60e6e5575c145f4dc848a231fb6cae8 Mon Sep 17 00:00:00 2001 From: Gustavo Madeira Santana Date: Sun, 15 Mar 2026 11:55:24 +0000 Subject: [PATCH] Docs: refresh extension host migration status --- .../openclaw-capability-catalog-and-arbitration-spec.md | 2 ++ .../openclaw-extension-contribution-schema-spec.md | 2 ++ .../openclaw-extension-host-implementation-guide.md | 5 ++++- .../openclaw-extension-host-lifecycle-and-security-spec.md | 2 ++ .../openclaw-kernel-event-pipeline-spec.md | 1 + .../openclaw-kernel-extension-host-transition-plan.md | 7 +++++-- 6 files changed, 16 insertions(+), 3 deletions(-) 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 8ddeffdfce9..0b43fb6219d 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 @@ -36,6 +36,7 @@ What has been implemented: - host-owned resolved-extension records now carry the static metadata needed for install, onboarding, and lightweight operator UX - 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 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` @@ -52,6 +53,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 moving cache-key construction and registry cache control behind host-owned 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 with compatibility lifecycle mapping, 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 407020f3eee..d68ffc6fa09 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 @@ -40,6 +40,7 @@ What has been implemented: - config doc baseline generation now reads bundled extension metadata through the resolved-extension registry - 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 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` @@ -56,6 +57,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 cache-key construction and registry cache control explicit host-owned seams before changing loader activation-state ownership - by making the first loader compatibility, candidate-planning, import-flow, runtime-decision, register-flow, candidate-orchestration, record-state with compatibility lifecycle mapping, 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 3099580b4e9..dbbe1945b95 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 @@ -61,6 +61,7 @@ What has been implemented so far: - `src/extension-host/resolved-registry.ts` now exposes a host-owned resolved-extension registry view - 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 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` @@ -90,6 +91,7 @@ How it has been done: - by extracting low-risk runtime registration helpers next and letting `src/plugins/registry.ts` delegate to them as a compatibility facade - 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 cache-key construction, cache reads, cache writes, and cache clearing behind host-owned helpers before changing activation-state ownership - 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 entry-path opening and module import behind host-owned helpers before changing cache wiring or lifecycle orchestration @@ -112,6 +114,7 @@ Committed implementation slices so far: - `e1b207f4cf` `Plugins: extract loader candidate orchestration` - `0c44d8049b` `Plugins: extract loader finalization` - `33ef55a9ee` `Plugins: add loader lifecycle state mapping` +- `6590e19095` `Plugins: extract loader cache control` - `89414ed857` `Docs: track extension host migration internally` - `d8af1eceaf` `Docs: refresh extension host migration status` @@ -308,7 +311,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 import flow, loader runtime decisions, loader post-import register flow, loader candidate orchestration, loader record-state helpers, and loader finalization now route through `src/extension-host/*` +- activation, loader cache control, loader policy, loader candidate planning, loader import flow, loader runtime decisions, loader post-import register flow, loader candidate orchestration, loader record-state helpers, and loader finalization 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 08f02230b0b..b0cd828425a 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 @@ -37,6 +37,7 @@ What has been implemented: - a host-owned resolved-extension registry exists for static consumers - 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 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` @@ -56,6 +57,7 @@ How it has been implemented: - by leaving start/stop ordering and duplicate-enforcement behavior in legacy subsystems where those subsystems are still the real owner - 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 cache-key construction, cache reads, cache writes, and cache clearing next while leaving activation-state ownership 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 entry-path opening and module import next while leaving cache wiring and lifecycle orchestration unchanged 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 70df32813b9..5c0f8996412 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 @@ -36,6 +36,7 @@ Relevant prerequisite work that has landed: - static consumers can now read host-owned resolved-extension data - 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 cache key construction and registry cache control now have 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 entry-path opening and module import now have a host-owned helper boundary 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 e1adbab24b7..11f639e114d 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 @@ -46,6 +46,7 @@ What has landed: - a host-owned resolved-extension registry view now exists for static consumers - 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 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` @@ -76,6 +77,7 @@ How it was done: - by moving the first low-risk runtime writes behind host-owned helpers while keeping `src/plugins/registry.ts` as the compatibility call surface - 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 cache-key construction, cache reads, cache writes, and cache clearing behind host-owned helpers before changing activation-state ownership - 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 entry-path opening and module import behind host-owned helpers before changing cache wiring or lifecycle orchestration @@ -97,13 +99,14 @@ Committed implementation slices so far: - `e1b207f4cf` `Plugins: extract loader candidate orchestration` - `0c44d8049b` `Plugins: extract loader finalization` - `33ef55a9ee` `Plugins: add loader lifecycle state mapping` +- `6590e19095` `Plugins: extract loader cache control` - `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 full lifecycle state machine and remaining explicit activation-state ownership +- the full lifecycle state machine and remaining explicit activation-state plus policy 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 @@ -1319,7 +1322,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 policy, loader runtime decisions, loader record-state helpers, and loader finalization now route through `src/extension-host/*` +- activation, loader cache control, loader policy, loader runtime decisions, loader record-state helpers, and loader finalization now route through `src/extension-host/*` - broader lifecycle ownership, registration surfaces, policy gates, and activation-state management are still pending ## Phase 3: Broader Legacy Compatibility Bridges