From 2126997f50cbcfbda1905fadb266f5bfa9ae3baf Mon Sep 17 00:00:00 2001 From: Gustavo Madeira Santana Date: Sun, 15 Mar 2026 18:06:45 +0000 Subject: [PATCH] Docs: refine extension host binding and interaction plan --- ...capability-catalog-and-arbitration-spec.md | 11 ++ ...claw-extension-contribution-schema-spec.md | 55 +++++++ ...law-extension-host-implementation-guide.md | 9 ++ ...ension-host-lifecycle-and-security-spec.md | 30 ++++ .../openclaw-kernel-event-pipeline-spec.md | 16 ++ ...w-kernel-extension-host-transition-plan.md | 10 ++ src/extension-host/cutover-inventory.md | 152 ++++++++++-------- 7 files changed, 212 insertions(+), 71 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 e38184ae66a..b5f1ba788fc 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 @@ -267,6 +267,11 @@ Includes: - voice or telephony actions - selected interaction or workflow actions +Important interaction rule: + +- interaction-driven actions must be filtered by the current binding and route context +- a bound conversation should only surface interaction actions that are valid for the owning extension and current adapter capabilities + ### Operator-visible Used for admin, control, setup, CLI, and diagnostic surfaces. @@ -418,6 +423,12 @@ When the agent or runtime needs one provider for a canonical action, selection s This is especially important for `message.send` and `message.reply`. +It also applies to interaction and conversation-control actions, which should prefer: + +- current binding owner +- current adapter support +- explicit target selection only when ownership or adapter support is ambiguous + ## Messaging Example One agent may have: 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 f49f75ff29a..bcbc5b91868 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 @@ -599,10 +599,48 @@ Required descriptor metadata: - fail-open or fail-closed behavior - whether the handler must run on a sync hot path +Additional first-cut cases that should be modeled here: + +- ingress claim or bound-route ownership decisions +- explicit conversation binding requests or detaches +- send veto decisions + +Additional metadata when binding or ingress claim is involved: + +- binding mode (`claim-only`, `bind`, `detach`, or `mixed`) +- whether operator approval is required before a bind can take effect +- persistence mode for approved or detached bindings +- restore-on-restart behavior +- whether the handler is allowed to short-circuit downstream command or agent dispatch + +Important migration rule: + +- do not preserve `inbound_claim` as a permanent plugin-era hook name in the final model +- bridge it during migration if needed, but normalize it into canonical ingress-stage route-augmentation behavior + ### `capability.interaction` Represents canonical interaction handlers such as slash commands, buttons, form submissions, or modal actions. +Required descriptor metadata: + +- interaction namespace or routing key +- supported interaction classes +- supported channels or adapter families +- dedupe class or id strategy when callbacks may be retried +- fallback policy when no handler claims the interaction +- whether the handler may request conversation binding or detachment + +First-cut constraint: + +- the first interactive runtime cut may stay limited to Telegram and Discord because those are the validated immediate needs +- that limitation is a rollout choice, not a reason to encode Telegram- or Discord-specific handler APIs as the permanent kernel contract + +Ownership rule: + +- extensions may own interaction logic and channel-specific rendering details +- the host owns namespace registration, dedupe, callback routing, approval persistence, and binding policy + ### `capability.rpc` Represents internal callable methods that are not agent tools. @@ -634,6 +672,23 @@ Required descriptor metadata: This family exists because not all runtime providers are user-facing adapters. +### Adapter-runtime helper contracts + +Some interactive and bound-conversation extensions need a bounded set of runtime helper contracts from the active adapter. + +Examples of first-cut helpers: + +- typing leases +- message edit or delete +- component or reply-markup updates +- pin or unpin +- thread or topic rename when already supported by the adapter + +Important rule: + +- these helpers should be modeled as adapter-runtime contracts or host-injected capabilities +- they should not be frozen into permanent Telegram- or Discord-shaped kernel APIs + ### `service.background` Represents long-running extension-managed processes owned by the host. 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 0cd0268844d..4b969730015 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 @@ -216,8 +216,16 @@ 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, 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 +- host-owned conversation binding, interaction routing, ingress claim, and bounded interactive channel-control surfaces identified by external-plugin validation - any pilot migration, event pipeline, canonical catalog, or arbitration implementation +Recent plan refinement from external-plugin validation: + +- the plan now explicitly treats conversation binding ownership, approval persistence, restore-on-restart behavior, and detached-binding cleanup as first-class migration surfaces +- it now explicitly treats interactive callback routing, namespace ownership, dedupe, and fallback behavior as first-class migration surfaces +- it now explicitly treats inbound claim as a canonical ingress-stage concern rather than a permanent plugin-era hook shape +- it now explicitly limits the first-cut interactive channel-control surface to a bounded set of Telegram and Discord capabilities, but models them as host-owned adapter-runtime contracts rather than permanent product-shaped kernel APIs + ## Implementation Order Implement phases in this order: @@ -239,6 +247,7 @@ This order matters because each layer depends on the previous one: - migrated hooks depend on the canonical event pipeline - install, onboarding, and status flows depend on static metadata before runtime activation - catalogs and arbitration already exist in partial forms, so their phases are migrations, not greenfield work +- useful ideas from external-plugin validation should be harvested as parity requirements and host-owned capabilities, not by broadening legacy `src/plugins/*` or `src/plugin-sdk/*` surfaces as the target architecture - safe removal of legacy paths depends on compatibility coverage and parity checks ## Implementation Guardrails 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 cd7c2ee6ebe..d169822b6af 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 @@ -399,6 +399,9 @@ The host must track both: - `agent.tool.expose` - `control.command.expose` - `interaction.handle` +- `conversation.bind` +- `conversation.bind.approve` +- `conversation.control` - `rpc.expose` - `service.background` - `http.route.gateway` @@ -432,6 +435,8 @@ Examples: - prompt mutation or prompt injection behavior - sync transcript-write participation - fail-open versus fail-closed route augmentation +- whether an extension may bind conversations without per-request operator approval +- whether an interaction handler may invoke conversation-control verbs This preserves the intent of current controls such as `plugins.entries..hooks.allowPromptInjection`. @@ -441,6 +446,8 @@ These should require explicit operator approval or a strong default policy: - `runtime.veto-send` - `runtime.route-augment` +- `conversation.bind` +- `conversation.bind.approve` - `runtime.backend-register` - `credentials.write` - `process.spawn` @@ -449,6 +456,29 @@ These should require explicit operator approval or a strong default policy: High-risk permissions should still matter in `advisory` mode because they drive operator trust decisions even before real isolation exists. +### Binding and interaction ownership + +Conversation binding and interactive callback routing should be treated as host-owned lifecycle surfaces. + +The host must own: + +- namespace registration and dedupe for interactive callbacks +- approval persistence for extension-requested conversation binds +- restore-on-restart behavior for approved bindings +- cleanup behavior for detached or stale bindings +- channel-surface gating for first-cut conversation-control verbs + +Extensions may own: + +- the logic that decides whether to request a bind +- the interaction payload semantics +- channel-specific presentation details that fit inside the host-owned adapter contract + +Important migration rule: + +- do not turn `src/plugins/conversation-binding.ts` or `src/plugins/interactive.ts` into the permanent architecture target +- those behaviors should migrate into host-owned lifecycle and policy surfaces, with compatibility bridges only where needed + ## Persistence Ownership Persistence must be partitioned by owner and intent. 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 ac61ac0a11e..c672d48c15b 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 @@ -120,6 +120,7 @@ Recommended families: - `account.stopped` - `ingress.received` - `ingress.normalized` +- `ingress.claiming` - `routing.resolving` - `routing.resolved` - `session.starting` @@ -151,6 +152,12 @@ Recommended families: These families intentionally cover the behavior currently spread across `src/plugins/hooks.ts:1`, `src/hooks/internal-hooks.ts:13`, `src/infra/agent-events.ts:3`, and channel monitors. +`ingress.claiming` exists to absorb behavior that is currently tempting to model as plugin-specific hooks or direct dispatch short-circuits: + +- bound conversation ownership +- first-claim-wins plugin or extension routing +- future route-claim or veto decisions that must run before command or agent dispatch + ## Canonical Event Envelope Every event should carry: @@ -226,6 +233,15 @@ Examples today: Only `veto` and `resolver` handlers may influence routing or delivery decisions. +`ingress.claiming` is the first concrete place where a resolver-like route claim is expected to matter during migration. + +First-cut parity rule for `ingress.claiming`: + +- claim handlers run sequentially in deterministic order +- the first successful claim wins ownership of the inbound turn +- passive observers still run in their own stages instead of being skipped accidentally +- the migration bridge may target a single extension when a host-owned binding already resolved the owner + ## Execution Modes The semantic handler class is not enough by itself. 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 9576820caa8..c2de236c19c 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 @@ -467,6 +467,10 @@ Before implementation starts, write and maintain a cutover inventory for every c - HTTP routes and gateway methods - CLI registrars and plugin commands - services and context-engine registrations +- conversation binding ownership, approval persistence, and restore-on-restart behavior +- interactive callback routing, namespace ownership, and dedupe +- ingress claim and bound-route short-circuit behavior +- bounded interactive channel-control helpers needed by external interactive agents - slot selection and existing arbitration paths - status, reload, install, update, and diagnostics surfaces @@ -573,6 +577,12 @@ Concrete examples: - `extensions/phone-control/index.ts:330` becomes `capability.control-command` - `extensions/thread-ownership/index.ts:63` becomes `capability.route-augmenter` +Additional migration rule from external-plugin validation: + +- conversation binding, interactive callback routing, and inbound claim are real runtime needs, but they must not be solved by turning `src/plugins/*` into the permanent public architecture +- bind approvals, callback namespace routing, and bound-ingress short-circuit behavior belong to host-owned surfaces and canonical pipeline stages +- first-cut interactive channel controls may be parity-driven around Telegram and Discord, but the long-term contract must remain adapter-runtime and host-owned rather than product-shaped kernel APIs + ## 1d. Lightweight descriptors and distribution metadata The host also needs a static descriptor layer that is not the same thing as runtime contributions. diff --git a/src/extension-host/cutover-inventory.md b/src/extension-host/cutover-inventory.md index 46918415773..e753ed08de5 100644 --- a/src/extension-host/cutover-inventory.md +++ b/src/extension-host/cutover-inventory.md @@ -25,76 +25,80 @@ This is an implementation checklist, not a future-design spec. ## Current Inventory -| Surface | Current implementation | Target owner | Status | How it has been handled so far | -| ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Active runtime registry state | `src/plugins/runtime.ts` plus global plugin runtime state | `src/extension-host/active-registry.ts` | `moved` | Host-owned active registry exists; `src/plugins/runtime.ts` is now a compatibility facade. | -| Normalized extension descriptor model | plugin manifests and package metadata interpreted ad hoc across `src/plugins/manifest.ts`, `src/plugins/discovery.ts`, `src/plugins/install.ts` | `src/extension-host/schema.ts` | `partial` | `ResolvedExtension`, `ResolvedContribution`, and `ContributionPolicy` exist; current manifests project into them through compatibility adapters. | -| Resolved static registry | flat rows in `src/plugins/manifest-registry.ts` | `src/extension-host/resolved-registry.ts` | `partial` | Manifest records now carry `resolvedExtension`; a host-owned resolved registry view exists for static consumers. | -| Manifest/package metadata loading | `src/plugins/manifest.ts`, `src/plugins/discovery.ts`, `src/plugins/install.ts` | `src/extension-host/schema.ts` and `src/extension-host/manifest-registry.ts` | `partial` | Package metadata parsing is routed through host schema helpers; legacy loader flow still supplies the source manifests. | -| Loader SDK alias compatibility | `src/plugins/loader.ts` | `src/extension-host/loader-compat.ts` | `partial` | Plugin-SDK alias candidate ordering, alias-file resolution, and scoped alias-map construction now live in host-owned loader compatibility helpers. | -| Loader alias-wired module loader creation | `src/plugins/loader.ts` | `src/extension-host/loader-module-loader.ts` | `partial` | Lazy Jiti creation and SDK-alias-wired module loading now delegate through a host-owned loader-module-loader helper. | -| Loader cache key and registry cache control | `src/plugins/loader.ts` | `src/extension-host/loader-cache.ts` | `partial` | Cache-key construction, LRU registry cache reads and writes, and cache clearing now delegate through host-owned loader-cache helpers while preserving the current cache shape and cap. | -| Loader lazy runtime proxy creation | `src/plugins/loader.ts` | `src/extension-host/loader-runtime-proxy.ts` | `partial` | Lazy plugin runtime creation now delegates through a host-owned loader-runtime-proxy helper instead of remaining inline in the orchestrator. | -| Loader provenance and duplicate-order policy | `src/plugins/loader.ts` | `src/extension-host/loader-policy.ts` | `partial` | Plugin-record creation, duplicate precedence, and provenance indexing now live in host-owned loader-policy helpers. | -| Loader discovery policy results | mixed inside `src/extension-host/loader-policy.ts` and `src/extension-host/loader-orchestrator.ts` | `src/extension-host/loader-discovery-policy.ts` | `partial` | Open-allowlist discovery warnings now resolve through explicit host-owned discovery-policy results before the orchestrator logs them. | -| Loader initial candidate planning and record creation | `src/plugins/loader.ts` | `src/extension-host/loader-records.ts` | `partial` | Duplicate detection, initial record creation, manifest metadata attachment, and first-pass enable-state planning now delegate through host-owned loader-records helpers. | -| Loader entry-path opening and module import | `src/plugins/loader.ts` | `src/extension-host/loader-import.ts` | `partial` | Boundary-checked entry opening and module import now delegate through host-owned loader-import helpers while preserving the current trusted in-process loading model. | -| Loader module-export, config-validation, and memory-slot decisions | `src/plugins/loader.ts` | `src/extension-host/loader-runtime.ts` | `partial` | Module export resolution, export-metadata application, config validation, and early or final memory-slot decisions now delegate through host-owned loader-runtime helpers. | -| Loader post-import planning and register execution | `src/plugins/loader.ts` | `src/extension-host/loader-register.ts` | `partial` | Definition application, post-import validation planning, and `register(...)` execution now delegate through host-owned loader-register helpers while preserving current plugin behavior. | -| Loader per-candidate orchestration | `src/plugins/loader.ts` | `src/extension-host/loader-flow.ts` | `partial` | The per-candidate load flow now runs through a host-owned orchestrator that composes planning, import, runtime validation, register execution, and record-state helpers. | -| Loader top-level load orchestration | `src/plugins/loader.ts` | `src/extension-host/loader-orchestrator.ts` | `partial` | High-level load entry and compatibility facade behavior now route through a host-owned loader orchestrator while `src/plugins/loader.ts` remains the external compatibility surface. | -| Loader host process state | mixed inside `src/plugins/loader.ts` and `src/extension-host/loader-orchestrator.ts` | `src/extension-host/loader-host-state.ts` | `partial` | Shared discovery warning-cache state and loader reset behavior now delegate through a host-owned loader-host-state helper. | -| Loader preflight and cache-hit setup | mixed inside `src/plugins/loader.ts` and `src/extension-host/loader-orchestrator.ts` | `src/extension-host/loader-preflight.ts` | `partial` | Test-default application, config normalization, cache-key construction, cache-hit activation, and command-clear preflight now delegate through a host-owned loader-preflight helper. | -| Loader post-preflight pipeline composition | mixed inside `src/plugins/loader.ts` and `src/extension-host/loader-orchestrator.ts` | `src/extension-host/loader-pipeline.ts` | `partial` | Post-preflight execution setup and session-run composition now delegate through a host-owned loader-pipeline helper. | -| Loader execution setup composition | mixed inside `src/plugins/loader.ts` and `src/extension-host/loader-orchestrator.ts` | `src/extension-host/loader-execution.ts` | `partial` | Runtime creation, registry creation, bootstrap setup, module-loader creation, and session creation now delegate through a host-owned loader-execution helper. | -| Loader discovery and manifest bootstrap | mixed inside `src/plugins/loader.ts` and `src/extension-host/loader-orchestrator.ts` | `src/extension-host/loader-bootstrap.ts` | `partial` | Discovery, manifest loading, manifest diagnostics, discovery-policy logging, provenance building, and candidate ordering now delegate through a host-owned loader-bootstrap helper. | -| Loader mutable activation state session | local variables in `src/extension-host/loader-orchestrator.ts` | `src/extension-host/loader-session.ts` | `partial` | Seen-id tracking, memory-slot selection state, and finalization inputs now live in a host-owned loader session instead of being spread across top-level loader variables. | -| Loader session run and finalization composition | mixed inside `src/extension-host/loader-orchestrator.ts` and `src/extension-host/loader-session.ts` | `src/extension-host/loader-run.ts` | `partial` | Candidate iteration, manifest lookup, per-candidate session processing, and finalization handoff now delegate through a host-owned loader-run helper. | -| Loader activation policy outcomes | open-coded in `src/extension-host/loader-flow.ts` | `src/extension-host/loader-activation-policy.ts` | `partial` | Duplicate precedence, config enablement, and early memory-slot gating now resolve through explicit host-owned activation-policy outcomes instead of remaining as inline loader decisions. | -| Loader record-state transitions | `src/plugins/loader.ts` | `src/extension-host/loader-state.ts` | `partial` | The loader now enforces an explicit lifecycle transition model (`prepared -> imported -> validated -> registered -> ready`, plus terminal `disabled` and `error`) while still mapping back to compatibility `PluginRecord.status` values. | -| Loader finalization policy results | mixed inside `src/extension-host/loader-policy.ts` and `src/extension-host/loader-finalize.ts` | `src/extension-host/loader-finalization-policy.ts` | `partial` | Memory-slot finalization warnings and provenance-based untracked-extension warnings now resolve through explicit host-owned finalization-policy results before the finalizer applies them. | -| Loader final cache, readiness, and activation finalization | `src/plugins/loader.ts` | `src/extension-host/loader-finalize.ts` | `partial` | Cache writes, readiness promotion, and registry activation now delegate through a host-owned loader-finalize helper; broader host lifecycle and policy semantics are still pending. | -| Channel lookup | `src/channels/plugins/index.ts`, `src/channels/plugins/registry-loader.ts`, `src/channels/registry.ts` | extension-host-backed registries plus kernel channel contracts | `partial` | Readers now consume the host-owned active registry, but writes still originate from plugin registration. | -| Dock lookup | `src/channels/dock.ts` | host-owned static descriptors | `partial` | Runtime lookup now uses the host boundary; dock ownership itself has not moved yet. | -| Message-channel normalization | `src/utils/message-channel.ts` | host-owned channel registry view | `partial` | Lookup path now reads through the host-owned active registry. | -| Default plugin HTTP route lookup | `src/plugins/http-registry.ts` | host-owned route registry | `partial` | Default registry resolution now uses the host boundary; route registration compatibility still flows through the legacy plugin API. | -| Channel catalog static metadata | `src/channels/plugins/catalog.ts` | host-owned static descriptors | `partial` | Package metadata parsing now flows through host schema helpers; full canonical catalog migration has not started. | -| Plugin skill discovery | `src/agents/skills/plugin-skills.ts` | host-owned resolved registry | `moved` | Static consumer now reads only resolved-extension data for skill paths and enablement filtering. | -| Plugin auto-enable | `src/config/plugin-auto-enable.ts` | host-owned resolved registry | `partial` | Primary logic runs on resolved-extension data; old manifest-registry injection remains as a compatibility input for older callers and tests. | -| Config validation indexing | `src/config/validation.ts`, `src/config/resolved-extension-validation.ts` | host-owned resolved registry | `moved` | Validation indexing now builds from resolved-extension records instead of flat manifest rows. | -| Config doc baseline generation | `src/config/doc-baseline.ts` | host-owned resolved registry | `moved` | Bundled plugin and channel metadata now load through the resolved-extension registry. | -| Plugin tool resolution and metadata | `src/plugins/tools.ts` | `src/extension-host/tool-runtime.ts` | `partial` | Optional-tool gating, plugin-id and tool-name conflict handling, tool-factory resolution, and plugin-tool metadata tracking now delegate through a host-owned tool-runtime helper while `src/plugins/tools.ts` remains the loader and config-normalization facade. | -| Plugin provider resolution | `src/plugins/providers.ts` | `src/extension-host/provider-runtime.ts` | `partial` | Provider projection from registry entries into runtime provider objects now delegates through a host-owned provider-runtime helper while `src/plugins/providers.ts` remains the loader and config-normalization facade. | -| Plugin provider discovery | `src/plugins/provider-discovery.ts` | `src/extension-host/provider-discovery.ts` | `partial` | Discovery-capable provider filtering, order grouping, and result normalization now delegate through a host-owned provider-discovery helper while `src/plugins/provider-discovery.ts` remains the compatibility facade around the legacy provider loader path. | -| 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. | -| Plugin registry compatibility policy | mixed inside `src/extension-host/plugin-registry.ts` | `src/extension-host/plugin-registry-compat.ts` | `partial` | Provider normalization, command duplicate enforcement, and registry-local diagnostic shaping now delegate through a host-owned compatibility helper; the underlying provider-validation and plugin-command subsystems still remain legacy-owned. | -| Plugin registry registration actions | mixed inside `src/extension-host/plugin-registry.ts` | `src/extension-host/plugin-registry-registrations.ts` | `partial` | Low-risk registration actions for tools, hooks, gateway methods, HTTP routes, channels, CLI, services, typed hooks, and context engines now delegate through a host-owned helper; the compatibility facade still composes those actions with provider and command compatibility policy. | -| Channel registration writes | `src/plugins/registry.ts` | host-owned channel registry | `partial` | Validation and normalization now delegate to `src/extension-host/runtime-registrations.ts`, and compatibility writes now route through `src/extension-host/registry-writes.ts`; the legacy plugin API still remains the call surface. | -| Provider registration writes | `src/plugins/registry.ts` | host-owned provider registry | `partial` | Provider normalization and compatibility diagnostics now delegate through `src/extension-host/plugin-registry-compat.ts`, duplicate detection and normalized registration shape still delegate to `src/extension-host/runtime-registrations.ts`, and compatibility writes route through `src/extension-host/registry-writes.ts`. | -| HTTP route registration writes | `src/plugins/registry.ts` | host-owned route registry | `partial` | Route validation and normalization now delegate to `src/extension-host/runtime-registrations.ts`, and compatibility append or replace writes now route through `src/extension-host/registry-writes.ts`. | -| Gateway method registration writes | `src/plugins/registry.ts` | host-owned runtime contribution registry | `partial` | Duplicate detection and normalized method registration now delegate to `src/extension-host/runtime-registrations.ts`, and compatibility writes now route through `src/extension-host/registry-writes.ts`. | -| Tool registration writes | `src/plugins/registry.ts` | host-owned tool registry | `partial` | Tool-name normalization and tool-factory shaping delegate through `src/extension-host/runtime-registrations.ts`, and low-risk compatibility writes now route through `src/extension-host/registry-writes.ts`; duplicate handling still follows the legacy tool path. | -| CLI registration writes | `src/plugins/registry.ts` | host-owned CLI registry | `partial` | CLI command-name normalization delegates through `src/extension-host/runtime-registrations.ts`, and compatibility writes now route through `src/extension-host/registry-writes.ts`; the legacy plugin API still remains the call surface. | -| Service registration writes | `src/plugins/registry.ts` | host-owned service registry | `partial` | Service-id normalization delegates through `src/extension-host/runtime-registrations.ts`, compatibility writes now route through `src/extension-host/registry-writes.ts`, and broader lifecycle ownership now starts in `src/extension-host/service-lifecycle.ts`. | -| Command registration writes | `src/plugins/registry.ts` | host-owned command registry | `partial` | Command-name normalization, duplicate-enforcement diagnostics, and legacy plugin-command registry bridging now delegate through `src/extension-host/plugin-registry-compat.ts`; the final compatibility write still routes through `src/extension-host/registry-writes.ts`. | -| Context-engine registration writes | `src/plugins/registry.ts` | host-owned context-engine registry | `partial` | Context-engine id normalization now delegates to `src/extension-host/runtime-registrations.ts`, and the compatibility write now routes through `src/extension-host/registry-writes.ts`; the actual context-engine registry remains legacy-owned. | -| Legacy hook registration writes | `src/plugins/registry.ts` | host-owned hook registry | `partial` | Hook-entry construction and event normalization now delegate to `src/extension-host/runtime-registrations.ts`, and the compatibility write now routes through `src/extension-host/registry-writes.ts`; internal-hook bridging still remains in the legacy plugin registry. | -| Typed-hook registration writes | `src/plugins/registry.ts` | host-owned typed-hook registry | `partial` | Typed-hook record construction and hook-name validation now delegate to `src/extension-host/runtime-registrations.ts`, and the compatibility write now routes through `src/extension-host/registry-writes.ts`; prompt-injection policy and execution semantics remain legacy-owned. | -| 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 | `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 plus gateway runtime consumers | `src/extension-host/gateway-methods.ts` plus host-owned runtime contribution registry | `partial` | Gateway method-id aggregation, plugin diagnostic shaping, and extra-handler composition now delegate through a host-owned gateway-methods helper while request dispatch semantics still live in the gateway server code. | -| 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. | -| Onboarding/install/setup surfaces | `src/plugins/install.ts`, package manifests, channel catalog, onboarding commands | host-owned static descriptors | `partial` | Static metadata normalization has started; full setup/install descriptor migration is not done. | -| Pilot migrations | `extensions/thread-ownership`, `extensions/telegram`, `extensions/acpx` | extension-host path with parity tracking | `not started` | No pilot runs through the host path yet. | +| Surface | Current implementation | Target owner | Status | How it has been handled so far | +| ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Active runtime registry state | `src/plugins/runtime.ts` plus global plugin runtime state | `src/extension-host/active-registry.ts` | `moved` | Host-owned active registry exists; `src/plugins/runtime.ts` is now a compatibility facade. | +| Normalized extension descriptor model | plugin manifests and package metadata interpreted ad hoc across `src/plugins/manifest.ts`, `src/plugins/discovery.ts`, `src/plugins/install.ts` | `src/extension-host/schema.ts` | `partial` | `ResolvedExtension`, `ResolvedContribution`, and `ContributionPolicy` exist; current manifests project into them through compatibility adapters. | +| Resolved static registry | flat rows in `src/plugins/manifest-registry.ts` | `src/extension-host/resolved-registry.ts` | `partial` | Manifest records now carry `resolvedExtension`; a host-owned resolved registry view exists for static consumers. | +| Manifest/package metadata loading | `src/plugins/manifest.ts`, `src/plugins/discovery.ts`, `src/plugins/install.ts` | `src/extension-host/schema.ts` and `src/extension-host/manifest-registry.ts` | `partial` | Package metadata parsing is routed through host schema helpers; legacy loader flow still supplies the source manifests. | +| Loader SDK alias compatibility | `src/plugins/loader.ts` | `src/extension-host/loader-compat.ts` | `partial` | Plugin-SDK alias candidate ordering, alias-file resolution, and scoped alias-map construction now live in host-owned loader compatibility helpers. | +| Loader alias-wired module loader creation | `src/plugins/loader.ts` | `src/extension-host/loader-module-loader.ts` | `partial` | Lazy Jiti creation and SDK-alias-wired module loading now delegate through a host-owned loader-module-loader helper. | +| Loader cache key and registry cache control | `src/plugins/loader.ts` | `src/extension-host/loader-cache.ts` | `partial` | Cache-key construction, LRU registry cache reads and writes, and cache clearing now delegate through host-owned loader-cache helpers while preserving the current cache shape and cap. | +| Loader lazy runtime proxy creation | `src/plugins/loader.ts` | `src/extension-host/loader-runtime-proxy.ts` | `partial` | Lazy plugin runtime creation now delegates through a host-owned loader-runtime-proxy helper instead of remaining inline in the orchestrator. | +| Loader provenance and duplicate-order policy | `src/plugins/loader.ts` | `src/extension-host/loader-policy.ts` | `partial` | Plugin-record creation, duplicate precedence, and provenance indexing now live in host-owned loader-policy helpers. | +| Loader discovery policy results | mixed inside `src/extension-host/loader-policy.ts` and `src/extension-host/loader-orchestrator.ts` | `src/extension-host/loader-discovery-policy.ts` | `partial` | Open-allowlist discovery warnings now resolve through explicit host-owned discovery-policy results before the orchestrator logs them. | +| Loader initial candidate planning and record creation | `src/plugins/loader.ts` | `src/extension-host/loader-records.ts` | `partial` | Duplicate detection, initial record creation, manifest metadata attachment, and first-pass enable-state planning now delegate through host-owned loader-records helpers. | +| Loader entry-path opening and module import | `src/plugins/loader.ts` | `src/extension-host/loader-import.ts` | `partial` | Boundary-checked entry opening and module import now delegate through host-owned loader-import helpers while preserving the current trusted in-process loading model. | +| Loader module-export, config-validation, and memory-slot decisions | `src/plugins/loader.ts` | `src/extension-host/loader-runtime.ts` | `partial` | Module export resolution, export-metadata application, config validation, and early or final memory-slot decisions now delegate through host-owned loader-runtime helpers. | +| Loader post-import planning and register execution | `src/plugins/loader.ts` | `src/extension-host/loader-register.ts` | `partial` | Definition application, post-import validation planning, and `register(...)` execution now delegate through host-owned loader-register helpers while preserving current plugin behavior. | +| Loader per-candidate orchestration | `src/plugins/loader.ts` | `src/extension-host/loader-flow.ts` | `partial` | The per-candidate load flow now runs through a host-owned orchestrator that composes planning, import, runtime validation, register execution, and record-state helpers. | +| Loader top-level load orchestration | `src/plugins/loader.ts` | `src/extension-host/loader-orchestrator.ts` | `partial` | High-level load entry and compatibility facade behavior now route through a host-owned loader orchestrator while `src/plugins/loader.ts` remains the external compatibility surface. | +| Loader host process state | mixed inside `src/plugins/loader.ts` and `src/extension-host/loader-orchestrator.ts` | `src/extension-host/loader-host-state.ts` | `partial` | Shared discovery warning-cache state and loader reset behavior now delegate through a host-owned loader-host-state helper. | +| Loader preflight and cache-hit setup | mixed inside `src/plugins/loader.ts` and `src/extension-host/loader-orchestrator.ts` | `src/extension-host/loader-preflight.ts` | `partial` | Test-default application, config normalization, cache-key construction, cache-hit activation, and command-clear preflight now delegate through a host-owned loader-preflight helper. | +| Loader post-preflight pipeline composition | mixed inside `src/plugins/loader.ts` and `src/extension-host/loader-orchestrator.ts` | `src/extension-host/loader-pipeline.ts` | `partial` | Post-preflight execution setup and session-run composition now delegate through a host-owned loader-pipeline helper. | +| Loader execution setup composition | mixed inside `src/plugins/loader.ts` and `src/extension-host/loader-orchestrator.ts` | `src/extension-host/loader-execution.ts` | `partial` | Runtime creation, registry creation, bootstrap setup, module-loader creation, and session creation now delegate through a host-owned loader-execution helper. | +| Loader discovery and manifest bootstrap | mixed inside `src/plugins/loader.ts` and `src/extension-host/loader-orchestrator.ts` | `src/extension-host/loader-bootstrap.ts` | `partial` | Discovery, manifest loading, manifest diagnostics, discovery-policy logging, provenance building, and candidate ordering now delegate through a host-owned loader-bootstrap helper. | +| Loader mutable activation state session | local variables in `src/extension-host/loader-orchestrator.ts` | `src/extension-host/loader-session.ts` | `partial` | Seen-id tracking, memory-slot selection state, and finalization inputs now live in a host-owned loader session instead of being spread across top-level loader variables. | +| Loader session run and finalization composition | mixed inside `src/extension-host/loader-orchestrator.ts` and `src/extension-host/loader-session.ts` | `src/extension-host/loader-run.ts` | `partial` | Candidate iteration, manifest lookup, per-candidate session processing, and finalization handoff now delegate through a host-owned loader-run helper. | +| Loader activation policy outcomes | open-coded in `src/extension-host/loader-flow.ts` | `src/extension-host/loader-activation-policy.ts` | `partial` | Duplicate precedence, config enablement, and early memory-slot gating now resolve through explicit host-owned activation-policy outcomes instead of remaining as inline loader decisions. | +| Loader record-state transitions | `src/plugins/loader.ts` | `src/extension-host/loader-state.ts` | `partial` | The loader now enforces an explicit lifecycle transition model (`prepared -> imported -> validated -> registered -> ready`, plus terminal `disabled` and `error`) while still mapping back to compatibility `PluginRecord.status` values. | +| Loader finalization policy results | mixed inside `src/extension-host/loader-policy.ts` and `src/extension-host/loader-finalize.ts` | `src/extension-host/loader-finalization-policy.ts` | `partial` | Memory-slot finalization warnings and provenance-based untracked-extension warnings now resolve through explicit host-owned finalization-policy results before the finalizer applies them. | +| Loader final cache, readiness, and activation finalization | `src/plugins/loader.ts` | `src/extension-host/loader-finalize.ts` | `partial` | Cache writes, readiness promotion, and registry activation now delegate through a host-owned loader-finalize helper; broader host lifecycle and policy semantics are still pending. | +| Channel lookup | `src/channels/plugins/index.ts`, `src/channels/plugins/registry-loader.ts`, `src/channels/registry.ts` | extension-host-backed registries plus kernel channel contracts | `partial` | Readers now consume the host-owned active registry, but writes still originate from plugin registration. | +| Dock lookup | `src/channels/dock.ts` | host-owned static descriptors | `partial` | Runtime lookup now uses the host boundary; dock ownership itself has not moved yet. | +| Message-channel normalization | `src/utils/message-channel.ts` | host-owned channel registry view | `partial` | Lookup path now reads through the host-owned active registry. | +| Default plugin HTTP route lookup | `src/plugins/http-registry.ts` | host-owned route registry | `partial` | Default registry resolution now uses the host boundary; route registration compatibility still flows through the legacy plugin API. | +| Channel catalog static metadata | `src/channels/plugins/catalog.ts` | host-owned static descriptors | `partial` | Package metadata parsing now flows through host schema helpers; full canonical catalog migration has not started. | +| Plugin skill discovery | `src/agents/skills/plugin-skills.ts` | host-owned resolved registry | `moved` | Static consumer now reads only resolved-extension data for skill paths and enablement filtering. | +| Plugin auto-enable | `src/config/plugin-auto-enable.ts` | host-owned resolved registry | `partial` | Primary logic runs on resolved-extension data; old manifest-registry injection remains as a compatibility input for older callers and tests. | +| Config validation indexing | `src/config/validation.ts`, `src/config/resolved-extension-validation.ts` | host-owned resolved registry | `moved` | Validation indexing now builds from resolved-extension records instead of flat manifest rows. | +| Config doc baseline generation | `src/config/doc-baseline.ts` | host-owned resolved registry | `moved` | Bundled plugin and channel metadata now load through the resolved-extension registry. | +| Plugin tool resolution and metadata | `src/plugins/tools.ts` | `src/extension-host/tool-runtime.ts` | `partial` | Optional-tool gating, plugin-id and tool-name conflict handling, tool-factory resolution, and plugin-tool metadata tracking now delegate through a host-owned tool-runtime helper while `src/plugins/tools.ts` remains the loader and config-normalization facade. | +| Plugin provider resolution | `src/plugins/providers.ts` | `src/extension-host/provider-runtime.ts` | `partial` | Provider projection from registry entries into runtime provider objects now delegates through a host-owned provider-runtime helper while `src/plugins/providers.ts` remains the loader and config-normalization facade. | +| Plugin provider discovery | `src/plugins/provider-discovery.ts` | `src/extension-host/provider-discovery.ts` | `partial` | Discovery-capable provider filtering, order grouping, and result normalization now delegate through a host-owned provider-discovery helper while `src/plugins/provider-discovery.ts` remains the compatibility facade around the legacy provider loader path. | +| 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. | +| Plugin registry compatibility policy | mixed inside `src/extension-host/plugin-registry.ts` | `src/extension-host/plugin-registry-compat.ts` | `partial` | Provider normalization, command duplicate enforcement, and registry-local diagnostic shaping now delegate through a host-owned compatibility helper; the underlying provider-validation and plugin-command subsystems still remain legacy-owned. | +| Plugin registry registration actions | mixed inside `src/extension-host/plugin-registry.ts` | `src/extension-host/plugin-registry-registrations.ts` | `partial` | Low-risk registration actions for tools, hooks, gateway methods, HTTP routes, channels, CLI, services, typed hooks, and context engines now delegate through a host-owned helper; the compatibility facade still composes those actions with provider and command compatibility policy. | +| Channel registration writes | `src/plugins/registry.ts` | host-owned channel registry | `partial` | Validation and normalization now delegate to `src/extension-host/runtime-registrations.ts`, and compatibility writes now route through `src/extension-host/registry-writes.ts`; the legacy plugin API still remains the call surface. | +| Provider registration writes | `src/plugins/registry.ts` | host-owned provider registry | `partial` | Provider normalization and compatibility diagnostics now delegate through `src/extension-host/plugin-registry-compat.ts`, duplicate detection and normalized registration shape still delegate to `src/extension-host/runtime-registrations.ts`, and compatibility writes route through `src/extension-host/registry-writes.ts`. | +| HTTP route registration writes | `src/plugins/registry.ts` | host-owned route registry | `partial` | Route validation and normalization now delegate to `src/extension-host/runtime-registrations.ts`, and compatibility append or replace writes now route through `src/extension-host/registry-writes.ts`. | +| Gateway method registration writes | `src/plugins/registry.ts` | host-owned runtime contribution registry | `partial` | Duplicate detection and normalized method registration now delegate to `src/extension-host/runtime-registrations.ts`, and compatibility writes now route through `src/extension-host/registry-writes.ts`. | +| Tool registration writes | `src/plugins/registry.ts` | host-owned tool registry | `partial` | Tool-name normalization and tool-factory shaping delegate through `src/extension-host/runtime-registrations.ts`, and low-risk compatibility writes now route through `src/extension-host/registry-writes.ts`; duplicate handling still follows the legacy tool path. | +| CLI registration writes | `src/plugins/registry.ts` | host-owned CLI registry | `partial` | CLI command-name normalization delegates through `src/extension-host/runtime-registrations.ts`, and compatibility writes now route through `src/extension-host/registry-writes.ts`; the legacy plugin API still remains the call surface. | +| Service registration writes | `src/plugins/registry.ts` | host-owned service registry | `partial` | Service-id normalization delegates through `src/extension-host/runtime-registrations.ts`, compatibility writes now route through `src/extension-host/registry-writes.ts`, and broader lifecycle ownership now starts in `src/extension-host/service-lifecycle.ts`. | +| Command registration writes | `src/plugins/registry.ts` | host-owned command registry | `partial` | Command-name normalization, duplicate-enforcement diagnostics, and legacy plugin-command registry bridging now delegate through `src/extension-host/plugin-registry-compat.ts`; the final compatibility write still routes through `src/extension-host/registry-writes.ts`. | +| Context-engine registration writes | `src/plugins/registry.ts` | host-owned context-engine registry | `partial` | Context-engine id normalization now delegates to `src/extension-host/runtime-registrations.ts`, and the compatibility write now routes through `src/extension-host/registry-writes.ts`; the actual context-engine registry remains legacy-owned. | +| Legacy hook registration writes | `src/plugins/registry.ts` | host-owned hook registry | `partial` | Hook-entry construction and event normalization now delegate to `src/extension-host/runtime-registrations.ts`, and the compatibility write now routes through `src/extension-host/registry-writes.ts`; internal-hook bridging still remains in the legacy plugin registry. | +| Typed-hook registration writes | `src/plugins/registry.ts` | host-owned typed-hook registry | `partial` | Typed-hook record construction and hook-name validation now delegate to `src/extension-host/runtime-registrations.ts`, and the compatibility write now routes through `src/extension-host/registry-writes.ts`; prompt-injection policy and execution semantics remain legacy-owned. | +| 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 | `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 plus gateway runtime consumers | `src/extension-host/gateway-methods.ts` plus host-owned runtime contribution registry | `partial` | Gateway method-id aggregation, plugin diagnostic shaping, and extra-handler composition now delegate through a host-owned gateway-methods helper while request dispatch semantics still live in the gateway server code. | +| Conversation binding ownership, approvals, and restore semantics | `src/plugins/conversation-binding.ts` plus `src/infra/outbound/session-binding-service.ts` | host-owned binding registry and approval policy surface | `not started` | External-plugin evaluation showed this is a real missing migration surface. The host needs to own plugin-scoped conversation binding, approval persistence, restore-on-restart behavior, detached-binding cleanup, and legacy binding migration without making `src/plugins/conversation-binding.ts` the long-term public surface. | +| Interactive callback routing and namespace ownership | `src/plugins/interactive.ts` plus Telegram and Discord monitor-specific callback wiring | host-owned interaction router and namespace registry | `not started` | External-plugin evaluation showed this needs to be explicit. The host should own namespace registration, dedupe, fallback rules, and callback dispatch, while first-cut channel support stays intentionally limited to Telegram and Discord. | +| Ingress claim and bound-route short-circuit semantics | `src/plugins/hooks.ts` typed `inbound_claim` hook plus `src/auto-reply/reply/dispatch-from-config.ts` | canonical event-pipeline ingress claim stage | `not started` | The behavior is conceptually in-scope today, but it should land as a canonical ingress-stage contract with legacy hook bridging only as migration. The key parity rule is first-claim-wins for route ownership while passive observers still run through their own stages. | +| Interactive channel control verbs for bound agents | product-shaped runtime helpers added under `src/plugins/runtime/*` and direct channel-specific helpers in extension code | host-owned adapter runtime contracts and interaction capabilities | `not started` | The host needs a bounded first-cut set of control verbs for interactive agents, such as typing leases plus message or conversation actions. These should be injected as generic host-owned capabilities or adapter-runtime contracts, not frozen as permanent Telegram- or Discord-shaped kernel APIs. | +| 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. | +| Onboarding/install/setup surfaces | `src/plugins/install.ts`, package manifests, channel catalog, onboarding commands | host-owned static descriptors | `partial` | Static metadata normalization has started; full setup/install descriptor migration is not done. | +| Pilot migrations | `extensions/thread-ownership`, `extensions/telegram`, `extensions/acpx` | extension-host path with parity tracking | `not started` | No pilot runs through the host path yet. | ## Completed Pattern So Far @@ -122,6 +126,7 @@ That pattern has been used for: - service startup, stop ordering, and failure logging - CLI duplicate detection, registrar invocation, and async failure logging - gateway method-id aggregation, plugin diagnostic shaping, and extra-handler composition +- explicit scoping of still-unimplemented migration targets discovered by external-plugin evaluation: conversation binding ownership, interactive callback routing, ingress claim semantics, and bounded first-cut interactive channel controls ## Immediate Next Targets @@ -131,7 +136,8 @@ These are the next lowest-risk cutover steps: 2. Extend the new loader lifecycle state machine, session-owned activation state, discovery-policy outcomes, activation-policy outcomes, and finalization-policy results into broader activation-state and policy ownership in `src/extension-host/*`. 3. Introduce explicit host-owned registration surfaces for runtime writes, starting with the least-coupled registries. 4. Move minimal SDK compatibility and loader normalization into `src/extension-host/*` without breaking current `openclaw/plugin-sdk/*` loading. -5. Start the first pilot on `extensions/thread-ownership` only after the host-side registry and lifecycle seams are explicit. +5. Add host-owned surfaces for conversation binding, interactive callback routing, and ingress claim before broadening any legacy plugin-era runtime APIs. +6. Start the first pilot on `extensions/thread-ownership` only after the host-side registry and lifecycle seams are explicit. ## Explicitly Not Done Yet @@ -142,6 +148,10 @@ The following remain legacy-owned today: - activation ordering - policy gates - typed and legacy hook execution +- conversation binding ownership, approval persistence, and restore-on-restart behavior +- interaction namespace routing, dedupe, and callback fallback rules +- canonical ingress claim semantics +- bounded interactive channel control contracts - slot arbitration - ACP backend registration - channel runtime compatibility bridges