nyrn
/
openclaw
mirror of https://github.com/openclaw/openclaw.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Docs: refine extension host binding and interaction plan

This commit is contained in:
Gustavo Madeira Santana 2026-03-15 18:06:45 +00:00
parent 7d350538de
commit 2126997f50
No known key found for this signature in database
7 changed files with 212 additions and 71 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
docs/.internal/extension-host-migration/openclaw-capability-catalog-and-arbitration-spec.md
View File

@ -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:

55
docs/.internal/extension-host-migration/openclaw-extension-contribution-schema-spec.md
View File

@ -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.

9
docs/.internal/extension-host-migration/openclaw-extension-host-implementation-guide.md
View File

@ -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

30
docs/.internal/extension-host-migration/openclaw-extension-host-lifecycle-and-security-spec.md
View File

@ -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.<id>.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.

16
docs/.internal/extension-host-migration/openclaw-kernel-event-pipeline-spec.md
View File

@ -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.

10
docs/.internal/extension-host-migration/openclaw-kernel-extension-host-transition-plan.md
View File

@ -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.

152
src/extension-host/cutover-inventory.md
View File

@ -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