mirror of
https://github.com/openclaw/openclaw.git
synced 2026-03-25 00:42:24 +00:00
Docs: refresh runtime backend adoption status
This commit is contained in:
Gustavo Madeira Santana
@@ -618,7 +618,7 @@ Capability selection must emit structured events for:
|
||||
- channel capabilities from `extensions/discord/src/channel.ts:74`, `extensions/slack/src/channel.ts:107`, and `extensions/telegram/src/channel.ts:120` collapse into canonical messaging action families
|
||||
- diffs becomes an agent-visible tool family plus a host-managed route surface from `extensions/diffs/index.ts:27`
|
||||
- provider integration from `extensions/google-gemini-cli-auth/index.ts:24` becomes operator-visible setup and auth capabilities
|
||||
- catalog-backed runtime-family descriptors for embeddings, media, and TTS now route through `src/extension-host/runtime-backend-catalog.ts`; consumer adoption and arbitration should continue moving those subsystem runtimes toward runtime-internal registries rather than leaving them as a universal plugin-provider API shape
|
||||
- catalog-backed runtime-family descriptors for embeddings, media, and TTS now route through `src/extension-host/runtime-backend-catalog.ts`; TTS request setup and status already consume that catalog order, and broader consumer adoption and arbitration should continue moving those subsystem runtimes toward runtime-internal registries rather than leaving them as a universal plugin-provider API shape
|
||||
- extension-backed web search should become an agent-visible tool family unless it is only a runtime-internal backend feeding another host-owned surface
|
||||
- voice-call from `extensions/voice-call/index.ts:230` becomes a mix of agent-visible actions, runtime providers, and operator surfaces
|
||||
- ACP backend registration from `extensions/acpx/src/service.ts:55` becomes runtime-internal backend arbitration
|
||||
@@ -635,7 +635,7 @@ Capability selection must emit structured events for:
|
||||
6. Migrate the existing provider auth and setup selection path onto host-owned setup catalogs and canonical provider metadata.
|
||||
7. Add provider selection logic for the broader messaging action family before migrating all channels.
|
||||
8. Add runtime-backend and context-engine arbitration using the same rank and slot model where appropriate.
|
||||
9. Finish consumer adoption and arbitration on top of the catalog-backed runtime-family descriptors for embeddings, media, and TTS, with explicit capability routing and built-in fallback policy.
|
||||
9. Finish broader consumer adoption and arbitration on top of the catalog-backed runtime-family descriptors for embeddings, media, and TTS, with explicit capability routing and built-in fallback policy.
|
||||
10. Decide whether extension-backed search needs only canonical tool publication or also a host-owned runtime registry for internal search backends, and keep those two cases distinct.
|
||||
11. Ensure lightweight setup catalogs can be built from static descriptors alone.
|
||||
12. Add a reviewed core registry for canonical action families and document how new ids are introduced.
|
||||
|
||||
@@ -264,6 +264,7 @@ Committed implementation slices so far:
|
||||
- `64353a2b16` `TTS: extract preferences`
|
||||
- `ed5941ed7e` `TTS: extract payload planning`
|
||||
- `454e44242f` `TTS: extract API composition`
|
||||
- `6240fb31b5` `TTS: adopt runtime backend catalog`
|
||||
- `89414ed857` `Docs: track extension host migration internally`
|
||||
- `d8af1eceaf` `Docs: refresh extension host migration status`
|
||||
|
||||
@@ -273,7 +274,7 @@ What is still missing for these phases:
|
||||
- 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 generic interactive control surfaces
|
||||
- consumer adoption and arbitration on top of catalog-backed runtime-family descriptors for embeddings, media, and TTS
|
||||
- broader consumer adoption and arbitration on top of catalog-backed runtime-family descriptors for embeddings, media, and TTS
|
||||
- explicit support for extension-backed search, with a generic split between agent-visible tool publication and optional runtime-internal search backends
|
||||
- any pilot migration, event pipeline, canonical catalog, or arbitration implementation
|
||||
|
||||
@@ -283,7 +284,7 @@ Recent plan refinements:
|
||||
- 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 treats Telegram and Discord as the first validated rollout targets for interactive control surfaces while keeping the underlying contracts generic, host-owned, and kernel-agnostic
|
||||
- it now explicitly treats embeddings, media understanding, and TTS as in-progress host-owned subsystem runtimes, with embedding selection, fallback routing, public runtime surface, result typing, manager-side batch and fallback policy, sync plus reindex planning, sync plus reindex orchestration, reindex sync-body execution plus unsafe reset, safe-reindex temp-db creation, file swap, reopen, and cleanup, plus runtime-backend catalog descriptors now extracted, media registry, execution, auto-entry selection, active-model fallback, orchestration, planning helpers, remaining API composition, lazy entrypoint wiring, plus runtime-backend catalog descriptors now extracted, TTS registry, execution, request setup, config normalization, preferences, payload planning, shared status state, API composition, plus runtime-backend catalog descriptors now extracted, and consumer adoption and arbitration on top of those catalog-backed runtime-family descriptors still pending, all with capability routing, typed request envelopes, provider-id normalization, and fallback policy
|
||||
- it now explicitly treats embeddings, media understanding, and TTS as in-progress host-owned subsystem runtimes, with embedding selection, fallback routing, public runtime surface, result typing, manager-side batch and fallback policy, sync plus reindex planning, sync plus reindex orchestration, reindex sync-body execution plus unsafe reset, safe-reindex temp-db creation, file swap, reopen, and cleanup, plus runtime-backend catalog descriptors now extracted, media registry, execution, auto-entry selection, active-model fallback, orchestration, planning helpers, remaining API composition, lazy entrypoint wiring, plus runtime-backend catalog descriptors now extracted, TTS registry, execution, request setup, config normalization, preferences, payload planning, shared status state, API composition, plus runtime-backend catalog descriptors now extracted, with TTS request setup and status already consuming that catalog order, and broader consumer adoption and arbitration on top of those catalog-backed runtime-family descriptors still pending, all with capability routing, typed request envelopes, provider-id normalization, and fallback policy
|
||||
- it now explicitly rejects widening the legacy `registerProvider(...)` or `ProviderPlugin` surface into a universal runtime API while retaining capability routing, typed request envelopes, provider-id normalization, and fallback behavior where those are part of the target model
|
||||
- it now explicitly treats extension-backed search as either a canonical tool contribution or a host-owned runtime backend depending on whether the search surface is agent-visible
|
||||
|
||||
|
||||
@@ -147,7 +147,7 @@ What is still pending from this spec:
|
||||
- broader extension-host lifecycle ownership beyond the loader state machine, service-lifecycle boundary, CLI-lifecycle boundary, session-owned activation state, and explicit discovery-policy, activation-policy, and finalization-policy outcomes
|
||||
- activation pipeline ownership
|
||||
- host-owned registries for setup, CLI, routes, services, slots, and backends
|
||||
- consumer adoption and arbitration on top of catalog-backed runtime-family descriptors for embeddings, media, and TTS, including explicit fallback and override policy instead of plugin-era capability reads
|
||||
- broader consumer adoption and arbitration on top of catalog-backed runtime-family descriptors for embeddings, media, and TTS, including explicit fallback and override policy instead of plugin-era capability reads
|
||||
- a clear host-owned split for extension-backed search between agent-visible tool publication and any optional runtime-internal search backend registry
|
||||
- permission-mode enforcement
|
||||
- per-extension state ownership and migration
|
||||
@@ -746,7 +746,7 @@ The host must emit structured telemetry for:
|
||||
4. Add a policy evaluator that understands advisory versus enforced permission modes.
|
||||
5. Add host-owned credential and per-extension state boundaries for extension services.
|
||||
6. Generalize backend registration into a host-managed `capability.runtime-backend` registry.
|
||||
7. Finish consumer adoption and arbitration on top of the catalog-backed runtime-family descriptors for embeddings, media, and TTS, instead of widening `registerProvider(...)`.
|
||||
7. Finish broader consumer adoption and arbitration on top of the catalog-backed runtime-family descriptors for embeddings, media, and TTS, instead of widening `registerProvider(...)`.
|
||||
8. Keep extension-backed search generic by publishing agent-visible search through tool contracts and using runtime-backend only for search backends consumed internally by the host or another subsystem.
|
||||
9. Add slot-backed provider management for context engines and other exclusive runtime providers.
|
||||
10. Preserve provenance, origin precedence, and current workspace and bundled enablement rules in host policy.
|
||||
|
||||
@@ -250,6 +250,7 @@ Committed implementation slices so far:
|
||||
- `64353a2b16` `TTS: extract preferences`
|
||||
- `ed5941ed7e` `TTS: extract payload planning`
|
||||
- `454e44242f` `TTS: extract API composition`
|
||||
- `6240fb31b5` `TTS: adopt runtime backend catalog`
|
||||
- `89414ed857` `Docs: track extension host migration internally`
|
||||
- `d8af1eceaf` `Docs: refresh extension host migration status`
|
||||
|
||||
@@ -258,7 +259,7 @@ What has not landed:
|
||||
- keeping the cutover inventory current as more surfaces move
|
||||
- broader lifecycle ownership beyond the loader state machine, session-owned activation state, and explicit discovery-policy, activation-policy, and finalization-policy outcomes, plus remaining policy semantics
|
||||
- host-owned registration surfaces beyond the first normalization helpers and low-risk channel, provider, gateway-method, HTTP-route, tool, CLI, service, command, context-engine, and hook compatibility write slices
|
||||
- consumer adoption and arbitration on top of catalog-backed runtime-family descriptors for embeddings, media, and TTS
|
||||
- broader consumer adoption and arbitration on top of catalog-backed runtime-family descriptors for embeddings, media, and TTS
|
||||
- SDK compatibility translation work
|
||||
- canonical event stages
|
||||
- canonical capability catalogs
|
||||
|
||||
@@ -99,10 +99,10 @@ This is an implementation checklist, not a future-design spec.
|
||||
| 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. Those verbs should be expressed as generic host-owned adapter capabilities, even if the first validated rollout only exercises them through Telegram and Discord. |
|
||||
| Slot arbitration | `src/plugins/slots.ts` | `src/extension-host/slot-arbitration.ts` | `partial` | Exclusive-slot selection and default-slot resolution now route through a host-owned slot-arbitration helper while `src/plugins/slots.ts` remains the compatibility facade. Broader slot and catalog arbitration are still pending. |
|
||||
| ACP backend registry | `src/acp/runtime/registry.ts` | `src/extension-host/acp-runtime-backend-registry.ts` | `partial` | ACP backend registration and resolution now route through a host-owned ACP runtime-backend registry while `src/acp/runtime/registry.ts` remains the compatibility facade. Broader runtime-backend catalog ownership and ACPX pilot migration are still pending. |
|
||||
| Runtime-backend family catalog | built-in embedding, media-understanding, and TTS runtime descriptors currently implied by runtime-specific host registries | `src/extension-host/runtime-backend-catalog.ts` | `partial` | Embedding, media-understanding, and TTS runtime families now publish host-owned `capability.runtime-backend` catalog descriptors through `src/extension-host/runtime-backend-catalog.ts`. The catalog keeps subsystem ids, selector keys, capabilities, and default ranking explicit without widening the legacy provider API. Selection and arbitration consumers still need to adopt that catalog surface directly. |
|
||||
| Runtime-backend family catalog | built-in embedding, media-understanding, and TTS runtime descriptors currently implied by runtime-specific host registries | `src/extension-host/runtime-backend-catalog.ts` | `partial` | Embedding, media-understanding, and TTS runtime families now publish host-owned `capability.runtime-backend` catalog descriptors through `src/extension-host/runtime-backend-catalog.ts`. The catalog keeps subsystem ids, selector keys, capabilities, and default ranking explicit without widening the legacy provider API. TTS request setup and status now read provider ordering from that catalog, while broader selection and arbitration consumers still need to adopt it. |
|
||||
| Embedding provider registry and fallback routing | `src/memory/embeddings.ts`, `src/memory/manager.ts`, `src/memory/manager-sync-ops.ts`, plus plugin provider capability filtering through `src/plugins/runtime.ts` | `src/extension-host/embedding-runtime-registry.ts`, `src/extension-host/embedding-runtime.ts`, `src/extension-host/embedding-runtime-types.ts`, `src/extension-host/embedding-manager-runtime.ts`, `src/extension-host/embedding-sync-planning.ts`, `src/extension-host/embedding-sync-execution.ts`, `src/extension-host/embedding-reindex-execution.ts`, and `src/extension-host/embedding-safe-reindex.ts` | `partial` | Embedding-provider auto-selection, provider creation, local-setup guidance, and primary and fallback routing now route through a host-owned embedding runtime-registry helper. The public embedding runtime surface and result typing now route through `src/extension-host/embedding-runtime.ts` and `src/extension-host/embedding-runtime-types.ts`, the main memory-manager consumers now use that host-owned boundary, manager-side batch policy plus fallback activation now route through `src/extension-host/embedding-manager-runtime.ts`, sync and reindex planning now route through `src/extension-host/embedding-sync-planning.ts`, sync and reindex orchestration now route through `src/extension-host/embedding-sync-execution.ts`, reindex sync-body execution plus unsafe reset now route through `src/extension-host/embedding-reindex-execution.ts`, and safe-reindex temp-db creation, file swap, reopen, and cleanup now route through `src/extension-host/embedding-safe-reindex.ts` while `src/memory/embeddings.ts` remains the compatibility facade. Runtime-backend catalog descriptors now also route through `src/extension-host/runtime-backend-catalog.ts`. Remaining embedding work is down to consumer adoption and arbitration on top of that catalog surface. |
|
||||
| Media-understanding provider registry and execution routing | `src/media-understanding/providers/index.ts`, `src/media-understanding/runner.ts`, `src/media-understanding/runner.entries.ts`, `src/media-understanding/resolve.ts`, plus plugin provider capability filtering through `src/plugins/runtime.ts` | `src/extension-host/media-runtime-registry.ts`, `src/extension-host/media-runtime-execution.ts`, `src/extension-host/media-runtime-auto.ts`, `src/extension-host/media-runtime-orchestration.ts`, `src/extension-host/media-runtime-config.ts`, `src/extension-host/media-runtime-decision.ts`, `src/extension-host/media-runtime-api.ts`, and `src/extension-host/media-runtime-entrypoints.ts` | `partial` | Media-provider normalization, built-in registry construction, override merging, and runtime lookup now route through a host-owned media runtime-registry helper. Provider and CLI entry execution, output parsing, provider query normalization, provider auth and context shaping, and proxy-aware fetch handling now route through `src/extension-host/media-runtime-execution.ts`. Local-binary probing, auto-entry selection, active-model fallback, and top-level capability orchestration now route through `src/extension-host/media-runtime-auto.ts` and `src/extension-host/media-runtime-orchestration.ts`. Prompt, timeout, scope, model-entry, and concurrency planning now route through `src/extension-host/media-runtime-config.ts`, and media decision shaping now routes through `src/extension-host/media-runtime-decision.ts`. The remaining API composition in `src/media-understanding/runner.ts` now routes through `src/extension-host/media-runtime-api.ts`, and the remaining lazy provider and CLI entrypoint wiring in `src/media-understanding/runner.entries.ts` now routes through `src/extension-host/media-runtime-entrypoints.ts`, leaving `src/media-understanding/providers/index.ts`, `src/media-understanding/runner.ts`, `src/media-understanding/runner.entries.ts`, and `src/media-understanding/resolve.ts` as compatibility facades. Runtime-backend catalog descriptors now also route through `src/extension-host/runtime-backend-catalog.ts`. Remaining media work is down to consumer adoption and arbitration on top of that catalog surface. |
|
||||
| TTS provider registry and execution routing | `src/tts/tts.ts`, `src/gateway/server-methods/tts.ts`, and `src/auto-reply/reply/commands-tts.ts` | `src/extension-host/tts-runtime-registry.ts`, `src/extension-host/tts-runtime-execution.ts`, `src/extension-host/tts-runtime-setup.ts`, `src/extension-host/tts-config.ts`, `src/extension-host/tts-preferences.ts`, `src/extension-host/tts-payload.ts`, `src/extension-host/tts-status.ts`, and `src/extension-host/tts-api.ts` | `partial` | Built-in TTS provider metadata, provider ordering, API-key resolution, configuration checks, and telephony support now route through a host-owned TTS runtime-registry helper. Provider execution loops, output-format selection, telephony synthesis, and provider-error shaping now route through `src/extension-host/tts-runtime-execution.ts`. Provider selection and request setup now route through `src/extension-host/tts-runtime-setup.ts`. TTS config normalization, defaults, and model-override policy now route through `src/extension-host/tts-config.ts`. Prefs-path resolution, auto-mode policy, and persisted TTS preference reads and writes now route through `src/extension-host/tts-preferences.ts`. Auto-TTS gating, directive cleanup, truncation, summarization, and payload planning now route through `src/extension-host/tts-payload.ts`. Last-attempt state, status snapshots, and shared status formatting now route through `src/extension-host/tts-status.ts`. The remaining API composition in `src/tts/tts.ts` now routes through `src/extension-host/tts-api.ts`, so `src/tts/tts.ts` is down to a compatibility facade. Runtime-backend catalog descriptors now also route through `src/extension-host/runtime-backend-catalog.ts`. Remaining TTS work is down to consumer adoption and arbitration on top of that catalog surface. |
|
||||
| TTS provider registry and execution routing | `src/tts/tts.ts`, `src/gateway/server-methods/tts.ts`, and `src/auto-reply/reply/commands-tts.ts` | `src/extension-host/tts-runtime-registry.ts`, `src/extension-host/tts-runtime-execution.ts`, `src/extension-host/tts-runtime-setup.ts`, `src/extension-host/tts-config.ts`, `src/extension-host/tts-preferences.ts`, `src/extension-host/tts-payload.ts`, `src/extension-host/tts-status.ts`, and `src/extension-host/tts-api.ts` | `partial` | Built-in TTS provider metadata, provider ordering, API-key resolution, configuration checks, and telephony support now route through a host-owned TTS runtime-registry helper. Provider execution loops, output-format selection, telephony synthesis, and provider-error shaping now route through `src/extension-host/tts-runtime-execution.ts`. Provider selection and request setup now route through `src/extension-host/tts-runtime-setup.ts`. TTS config normalization, defaults, and model-override policy now route through `src/extension-host/tts-config.ts`. Prefs-path resolution, auto-mode policy, and persisted TTS preference reads and writes now route through `src/extension-host/tts-preferences.ts`. Auto-TTS gating, directive cleanup, truncation, summarization, and payload planning now route through `src/extension-host/tts-payload.ts`. Last-attempt state, status snapshots, and shared status formatting now route through `src/extension-host/tts-status.ts`. The remaining API composition in `src/tts/tts.ts` now routes through `src/extension-host/tts-api.ts`, so `src/tts/tts.ts` is down to a compatibility facade. Runtime-backend catalog descriptors now also route through `src/extension-host/runtime-backend-catalog.ts`, and TTS request setup plus status now consume that catalog order directly. Remaining TTS work is down to broader consumer adoption and arbitration on top of that catalog surface. |
|
||||
| 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. |
|
||||
|
||||
@@ -134,7 +134,7 @@ That pattern has been used for:
|
||||
- gateway method-id aggregation, plugin diagnostic shaping, and extra-handler composition
|
||||
- host-owned runtime registry read accessors for provider, tool, service, CLI, gateway-method, and HTTP-route consumers, plus the broader CLI pre-load fast path those accessors enabled
|
||||
- explicit scoping of still-unimplemented migration targets: conversation binding ownership, interactive callback routing, ingress claim semantics, and bounded first-cut interactive channel controls
|
||||
- explicit scoping of remaining subsystem-runtime targets: consumer adoption and arbitration on top of catalog-backed runtime-family descriptors for embeddings, media, and TTS, all with capability routing and fallback
|
||||
- explicit scoping of remaining subsystem-runtime targets: broader consumer adoption and arbitration on top of catalog-backed runtime-family descriptors for embeddings, media, and TTS, all with capability routing and fallback
|
||||
- explicit scoping of extension-backed search as either a canonical tool contribution or an optional host-owned runtime backend, rather than as another universal provider surface
|
||||
|
||||
## Immediate Next Targets
|
||||
@@ -161,7 +161,7 @@ The following remain legacy-owned today:
|
||||
- interaction namespace routing, dedupe, and callback fallback rules
|
||||
- canonical ingress claim semantics
|
||||
- generic host-owned interactive channel control contracts
|
||||
- consumer adoption and arbitration on top of catalog-backed runtime-family descriptors for embeddings, media, and TTS
|
||||
- broader consumer adoption and arbitration on top of catalog-backed runtime-family descriptors for embeddings, media, and TTS
|
||||
- a clear host-owned split for extension-backed search between canonical tool publication and any optional runtime-internal search backend registry
|
||||
- channel runtime compatibility bridges
|
||||
- pilot parity tracking
|
||||
|
||||
Reference in New Issue
Block a user