Docs: refresh extension host migration status

This commit is contained in:
Gustavo Madeira Santana
2026-03-15 17:54:31 +00:00
parent bb4681fca6
commit bb8349fde1
7 changed files with 16 additions and 1 deletions

View File

@@ -69,6 +69,7 @@ This is an implementation checklist, not a future-design spec.
| Plugin provider auth helpers | `src/commands/provider-auth-helpers.ts` | `src/extension-host/provider-auth.ts` | `partial` | Provider matching, auth-method selection, config-patch merging, and default-model application now delegate through a host-owned provider-auth helper while command and onboarding entry points remain compatibility surfaces. |
| Plugin provider wizard metadata and choice resolution | `src/plugins/provider-wizard.ts` | `src/extension-host/provider-wizard.ts` | `partial` | Onboarding option building, model-picker entry building, and provider-method choice resolution now delegate through a host-owned provider-wizard helper while `src/plugins/provider-wizard.ts` remains the compatibility facade around loader-backed provider access and post-selection hooks. |
| Plugin provider auth application flow | `src/commands/auth-choice.apply.plugin-provider.ts` | `src/extension-host/provider-auth-flow.ts` | `partial` | Loaded-provider auth application, plugin-enable gating, auth-method execution, and post-auth default-model handling now delegate through a host-owned provider-auth-flow helper while `src/commands/auth-choice.apply.plugin-provider.ts` remains the compatibility entry point. |
| Plugin provider post-selection hook execution | `src/plugins/provider-wizard.ts`, `src/commands/model-picker.ts` | `src/extension-host/provider-model-selection.ts` | `partial` | Provider post-selection hook lookup and invocation now delegate through a host-owned provider-model-selection helper while `src/plugins/provider-wizard.ts` remains a compatibility facade and existing command consumers continue migrating onto the host-owned surface. |
| Plugin loader activation | `src/plugins/loader.ts` | extension host lifecycle + compatibility loader | `partial` | Activation now routes through `src/extension-host/activation.ts`, but discovery, enablement, provenance, module loading, and policy still live in the legacy plugin loader. |
| Plugin API compatibility facade | `src/plugins/registry.ts` | `src/extension-host/plugin-api.ts` | `partial` | Compatibility `OpenClawPluginApi` composition and logger shaping now delegate through a host-owned helper; concrete registration callbacks now come from `src/extension-host/plugin-registry.ts` while `src/plugins/registry.ts` remains the external wrapper. |
| Plugin registry compatibility facade | `src/plugins/registry.ts` | `src/extension-host/plugin-registry.ts` | `partial` | The compatibility plugin-registry facade now delegates through a host-owned helper; `src/plugins/registry.ts` mainly defines shared types and forwards to the host-owned facade. |
@@ -116,6 +117,7 @@ That pattern has been used for:
- provider matching, auth-method selection, config-patch merging, and default-model application
- provider onboarding option building, model-picker entry building, and provider-method choice resolution
- loaded-provider auth application, plugin-enable gating, auth-method execution, and post-auth default-model handling
- provider post-selection hook lookup and invocation
- 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