From f99680436930837f13ce3db2ba46573de9c036dd Mon Sep 17 00:00:00 2001 From: Gustavo Madeira Santana Date: Sun, 15 Mar 2026 17:28:23 +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 | 6 ++++-- .../openclaw-kernel-event-pipeline-spec.md | 3 ++- .../openclaw-kernel-extension-host-transition-plan.md | 3 +++ src/extension-host/cutover-inventory.md | 4 ++-- 7 files changed, 19 insertions(+), 6 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 2dbc30a25a3..b0b18947719 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 @@ -67,6 +67,7 @@ What has been implemented: - compatibility plugin-registry policy now routes through `src/extension-host/plugin-registry-compat.ts` ahead of broader catalog-backed registry ownership - compatibility plugin-registry registration actions now route through `src/extension-host/plugin-registry-registrations.ts` ahead of broader catalog-backed registry ownership - service startup, stop ordering, service-context creation, and failure logging now route through `src/extension-host/service-lifecycle.ts` ahead of broader catalog-backed lifecycle ownership +- CLI duplicate detection, registrar invocation, and async failure logging now route through `src/extension-host/cli-lifecycle.ts` ahead of broader catalog-backed CLI ownership How it has been implemented: @@ -96,6 +97,7 @@ How it has been implemented: - by extracting provider normalization, command duplicate enforcement, and registry-local diagnostic shaping into a host-owned registry-compat helper while leaving the underlying provider-validation and plugin-command subsystems unchanged - by extracting low-risk registry registration actions into a host-owned registry-registrations helper so the compatibility facade composes host-owned actions instead of implementing them inline - by extracting service startup, stop ordering, service-context creation, and failure logging into a host-owned service-lifecycle helper before broader catalog-backed service ownership +- by extracting CLI duplicate detection, registrar invocation, and async failure logging into a host-owned CLI-lifecycle helper before broader catalog-backed CLI ownership 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 a14a77a1888..3ba2ca94baf 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 @@ -46,6 +46,7 @@ What has been implemented: - compatibility plugin-registry policy now routes through `src/extension-host/plugin-registry-compat.ts` - compatibility plugin-registry registration actions now route through `src/extension-host/plugin-registry-registrations.ts` - service startup, stop ordering, service-context creation, and failure logging now route through `src/extension-host/service-lifecycle.ts` +- CLI duplicate detection, registrar invocation, and async failure logging now route through `src/extension-host/cli-lifecycle.ts` - plugin SDK alias resolution now routes through `src/extension-host/loader-compat.ts` - loader alias-wired module loader creation now routes through `src/extension-host/loader-module-loader.ts` - loader cache key construction and registry cache control now route through `src/extension-host/loader-cache.ts` @@ -100,6 +101,7 @@ How it has been implemented: - by extracting provider normalization, command duplicate enforcement, and registry-local diagnostic shaping into a host-owned registry-compat helper while leaving the underlying provider-validation and plugin-command subsystems unchanged - by extracting low-risk registry registration actions into a host-owned registry-registrations helper so the compatibility facade composes host-owned actions instead of implementing them inline - by extracting service startup, stop ordering, service-context creation, and failure logging into a host-owned service-lifecycle helper while `src/plugins/services.ts` remains the compatibility entry point +- by extracting CLI duplicate detection, registrar invocation, and async failure logging into a host-owned CLI-lifecycle helper while `src/plugins/cli.ts` remains the compatibility entry point 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 f2a0d0fc7f9..eb03943de21 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 @@ -92,6 +92,7 @@ What has been implemented so far: - compatibility plugin-registry policy now routes through `src/extension-host/plugin-registry-compat.ts` - compatibility plugin-registry registration actions now route through `src/extension-host/plugin-registry-registrations.ts` - service startup, stop ordering, service-context creation, and failure logging now route through `src/extension-host/service-lifecycle.ts` +- CLI duplicate detection, registrar invocation, and async failure logging now route through `src/extension-host/cli-lifecycle.ts` - several static and lookup consumers now read through the host boundary or resolved-extension model: - channel registry and dock lookups - message-channel normalization @@ -143,6 +144,7 @@ How it has been done: - by extracting provider normalization, command duplicate enforcement, and registry-local diagnostic shaping into a host-owned registry-compat helper while leaving the underlying provider-validation and plugin-command subsystems unchanged - by extracting low-risk registry registration actions into a host-owned registry-registrations helper so the compatibility facade composes host-owned actions instead of implementing them inline - by extracting service startup, stop ordering, service-context creation, and failure logging into a host-owned service-lifecycle helper while `src/plugins/services.ts` remains the compatibility entry point +- by extracting CLI duplicate detection, registrar invocation, and async failure logging into a host-owned CLI-lifecycle helper while `src/plugins/cli.ts` remains the compatibility entry point - 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 @@ -180,13 +182,14 @@ Committed implementation slices so far: - `944d787df1` `Plugins: extract registry compatibility policy` - `4ca9cd7e5e` `Plugins: extract registry registration actions` - `6b24e65719` `Plugins: extract service lifecycle` +- `b5757a6625` `Plugins: extract CLI lifecycle` - `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, service-lifecycle boundary, 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 +- broader lifecycle ownership beyond the loader state machine, service-lifecycle boundary, CLI-lifecycle boundary, 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 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 925dcc9c719..d364715b22d 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 @@ -27,7 +27,7 @@ Current status against this spec: - registry ownership and the first compatibility-preserving loader slices have landed - a loader-scoped lifecycle state machine has landed -- broader lifecycle orchestration, policy gates, and activation-state management beyond the current loader and service seams have not landed +- broader lifecycle orchestration, policy gates, and activation-state management beyond the current loader, service, and CLI seams have not landed What has been implemented: @@ -45,6 +45,7 @@ What has been implemented: - compatibility plugin-registry policy now delegates through `src/extension-host/plugin-registry-compat.ts` - compatibility plugin-registry registration actions now delegate through `src/extension-host/plugin-registry-registrations.ts` - service startup, stop ordering, service-context creation, and failure logging now delegate through `src/extension-host/service-lifecycle.ts` +- CLI duplicate detection, registrar invocation, and async failure logging now delegate through `src/extension-host/cli-lifecycle.ts` - loader alias-wired module loader creation now routes through `src/extension-host/loader-module-loader.ts` - loader cache key construction and registry cache control now route through `src/extension-host/loader-cache.ts` - loader lazy runtime proxy creation now routes through `src/extension-host/loader-runtime-proxy.ts` @@ -110,10 +111,11 @@ How it has been implemented: - by extracting provider normalization, command duplicate enforcement, and registry-local diagnostic shaping into a host-owned registry-compat helper while leaving the underlying provider-validation and plugin-command subsystems unchanged - by extracting low-risk registry registration actions into a host-owned registry-registrations helper so the compatibility facade composes host-owned actions instead of implementing them inline - by extracting service startup, stop ordering, service-context creation, and failure logging into a host-owned service-lifecycle helper while `src/plugins/services.ts` remains the compatibility entry point +- by extracting CLI duplicate detection, registrar invocation, and async failure logging into a host-owned CLI-lifecycle helper while `src/plugins/cli.ts` remains the compatibility entry point What is still pending from this spec: -- broader extension-host lifecycle ownership beyond the loader state machine, service-lifecycle boundary, session-owned activation state, and explicit discovery-policy, activation-policy, and finalization-policy outcomes +- broader extension-host lifecycle ownership beyond the loader state machine, service-lifecycle boundary, CLI-lifecycle boundary, 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 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 527ce1b1421..b54ae8fe003 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 @@ -66,11 +66,12 @@ Relevant prerequisite work that has landed: - compatibility plugin-registry policy now has a host-owned helper boundary in `src/extension-host/plugin-registry-compat.ts` - compatibility plugin-registry registration actions now have a host-owned helper boundary in `src/extension-host/plugin-registry-registrations.ts` - service startup, stop ordering, service-context creation, and failure logging now have a host-owned helper boundary in `src/extension-host/service-lifecycle.ts` +- CLI duplicate detection, registrar invocation, and async failure logging now have a host-owned helper boundary in `src/extension-host/cli-lifecycle.ts` 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 canonical bridge or stage work before those earlier boundaries were in place, including the first loader-runtime, record-state, discovery-policy, activation-policy, finalization-policy, low-risk registry-write, hook-compat, plugin-api, plugin-registry, plugin-registry-compat, plugin-registry-registrations, and service-lifecycle seams +- the current implementation has deliberately not started canonical bridge or stage work before those earlier boundaries were in place, including the first loader-runtime, record-state, discovery-policy, activation-policy, finalization-policy, low-risk registry-write, hook-compat, plugin-api, plugin-registry, plugin-registry-compat, plugin-registry-registrations, service-lifecycle, and CLI-lifecycle seams ## Design Goals 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 dfe8a304ef8..eaf3a5a4900 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 @@ -77,6 +77,7 @@ What has landed: - compatibility plugin-registry policy now routes through `src/extension-host/plugin-registry-compat.ts` - compatibility plugin-registry registration actions now route through `src/extension-host/plugin-registry-registrations.ts` - service startup, stop ordering, service-context creation, and failure logging now route through `src/extension-host/service-lifecycle.ts` +- CLI duplicate detection, registrar invocation, and async failure logging now route through `src/extension-host/cli-lifecycle.ts` - several existing consumers now read host-owned normalized data instead of plugin-era manifest or runtime state directly: - channel and dock lookup surfaces - message-channel normalization @@ -129,6 +130,7 @@ How it was done: - by extracting provider normalization, command duplicate enforcement, and registry-local diagnostic shaping into a host-owned registry-compat helper while leaving the underlying provider-validation and plugin-command subsystems unchanged - by extracting low-risk registry registration actions into a host-owned registry-registrations helper so the compatibility facade composes host-owned actions instead of implementing them inline - by extracting service startup, stop ordering, service-context creation, and failure logging into a host-owned service-lifecycle helper while `src/plugins/services.ts` remains the compatibility entry point +- by extracting CLI duplicate detection, registrar invocation, and async failure logging into a host-owned CLI-lifecycle helper while `src/plugins/cli.ts` remains the compatibility entry point - by moving static and lookup-heavy consumers first, where the ownership boundary matters but runtime risk is lower Committed implementation slices so far: @@ -165,6 +167,7 @@ Committed implementation slices so far: - `944d787df1` `Plugins: extract registry compatibility policy` - `4ca9cd7e5e` `Plugins: extract registry registration actions` - `6b24e65719` `Plugins: extract service lifecycle` +- `b5757a6625` `Plugins: extract CLI lifecycle` - `89414ed857` `Docs: track extension host migration internally` - `d8af1eceaf` `Docs: refresh extension host migration status` diff --git a/src/extension-host/cutover-inventory.md b/src/extension-host/cutover-inventory.md index 5f88c1acbad..a17131355bf 100644 --- a/src/extension-host/cutover-inventory.md +++ b/src/extension-host/cutover-inventory.md @@ -82,7 +82,7 @@ This is an implementation checklist, not a future-design spec. | Hook compatibility policy and bridging | `src/plugins/registry.ts` | `src/extension-host/hook-compat.ts` | `partial` | Legacy internal-hook bridging and typed prompt-injection compatibility policy now delegate through a host-owned helper; actual hook execution ownership remains legacy-owned. | | Hook execution and global runner | `src/plugins/hook-runner-global.ts`, `src/hooks/internal-hooks.ts`, plugin hook registration in `src/plugins/registry.ts` | canonical kernel event stages + host bridges | `not started` | No canonical event-stage migration has landed yet. | | Service lifecycle | `src/plugins/services.ts` and plugin service registration | `src/extension-host/service-lifecycle.ts` | `partial` | Service startup, stop ordering, service-context creation, and failure logging now delegate through a host-owned service-lifecycle helper while `src/plugins/services.ts` remains the compatibility entry point. | -| CLI registration | plugin CLI registration in `src/plugins/registry.ts` and CLI loaders | extension host registry + static descriptors where possible | `not started` | No host-owned CLI registry exists yet. | +| CLI registration | plugin CLI registration in `src/plugins/registry.ts` and CLI loaders | `src/extension-host/cli-lifecycle.ts` plus static descriptors where possible | `partial` | CLI duplicate detection, registrar invocation, and async failure logging now delegate through a host-owned CLI-lifecycle helper while `src/plugins/cli.ts` remains the compatibility entry point. | | Gateway/server methods | `src/plugins/registry.ts` gateway handler registration | host-owned runtime contribution registry | `not started` | Still registered directly into the legacy plugin registry. | | Slot arbitration | `src/plugins/slots.ts` | host-owned arbitration model | `not started` | Current slot selection remains plugin-era logic. | | ACP backend registry | `src/acp/runtime/registry.ts` | host-owned runtime-backend registry | `not started` | ACP backends still mutate a global ACP runtime registry directly. | @@ -106,6 +106,7 @@ That pattern has been used for: - static consumers such as skills, validation, auto-enable, and config baseline generation - loader compatibility, cache control, initial candidate planning, entry-path import, explicit discovery-policy outcomes, explicit activation-policy outcomes, runtime decisions, post-import register flow, per-candidate orchestration, top-level load orchestration, session-owned activation state, explicit loader lifecycle transitions, explicit finalization-policy results, and final cache plus activation finalization - service startup, stop ordering, and failure logging +- CLI duplicate detection, registrar invocation, and async failure logging ## Immediate Next Targets @@ -126,7 +127,6 @@ The following remain legacy-owned today: - activation ordering - policy gates - typed and legacy hook execution -- CLI registration - gateway/server method registration - slot arbitration - ACP backend registration