mirror of https://github.com/openclaw/openclaw.git
Docs: clarify backend family terminology
This commit is contained in:
Gustavo Madeira Santana
parent
81ad5aaa1d
commit
8dbef2c431
|
|
@ -561,7 +561,7 @@ Selection rules for these subsystem runtimes should preserve the useful parts of
|
|||
|
||||
Architecture rule:
|
||||
|
||||
- keep those selection and envelope rules inside host-owned subsystem runtime registries or typed backend families
|
||||
- keep those selection and envelope rules inside host-owned subsystem runtime registries for typed backend families
|
||||
- do not widen provider-integration or legacy plugin-provider APIs into a universal surface for unrelated runtime subsystems
|
||||
- if search is agent-visible, publish it through canonical tool catalogs; reserve runtime-backend modeling for search backends that are consumed internally by the host or another subsystem
|
||||
|
||||
|
|
|
|||
|
|
@ -715,7 +715,7 @@ Useful harvested behavior:
|
|||
|
||||
Important rule:
|
||||
|
||||
- keep these as host-owned runtime registries or backend families
|
||||
- keep these inside host-owned runtime registries for typed backend families
|
||||
- do not widen `registerProvider(...)` into the permanent universal surface for every runtime subsystem
|
||||
- if search is directly agent-visible, model it as `capability.agent-tool` instead of treating it as a generic provider family
|
||||
|
||||
|
|
|
|||
|
|
@ -97,9 +97,9 @@ 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` | 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. |
|
||||
| Embedding provider registry and fallback routing | `src/memory/embeddings.ts` plus plugin provider capability filtering through `src/plugins/runtime.ts` | host-owned embedding runtime registry or typed runtime-backend family | `not started` | This is a real missing scope area. Embedding providers should be modeled as host-owned subsystem runtimes with explicit capability metadata, request envelopes, provider-id normalization, and fallback rules, not by widening legacy `registerProvider(...)` as the long-term architecture. |
|
||||
| Media-understanding provider registry and fallback routing | `src/media-understanding/providers/index.ts` plus plugin provider capability filtering through `src/plugins/runtime.ts` | host-owned media runtime registry or typed runtime-backend family | `not started` | Audio transcription, image understanding, and video understanding should be modeled as host-owned subsystem runtimes with capability routing, explicit request envelopes, and fallback behavior rather than as permanent extensions of the plugin-era provider API. |
|
||||
| TTS provider registry and telephony override routing | `src/tts/providers.ts`, `src/tts/tts.ts`, and plugin provider capability filtering through `src/plugins/runtime.ts` | host-owned TTS runtime registry or typed runtime-backend family | `not started` | TTS providers and telephony TTS overrides should move behind host-owned runtime registries with explicit capability and fallback policy rather than staying coupled to plugin-era provider capabilities and global active-registry reads. |
|
||||
| Embedding provider registry and fallback routing | `src/memory/embeddings.ts` plus plugin provider capability filtering through `src/plugins/runtime.ts` | host-owned embedding runtime registry for a typed backend family | `not started` | This is a real missing scope area. Embedding providers should be modeled as host-owned subsystem runtimes with explicit capability metadata, request envelopes, provider-id normalization, and fallback rules, not by widening legacy `registerProvider(...)` as the long-term architecture. |
|
||||
| Media-understanding provider registry and fallback routing | `src/media-understanding/providers/index.ts` plus plugin provider capability filtering through `src/plugins/runtime.ts` | host-owned media runtime registry for a typed backend family | `not started` | Audio transcription, image understanding, and video understanding should be modeled as host-owned subsystem runtimes with capability routing, explicit request envelopes, and fallback behavior rather than as permanent extensions of the plugin-era provider API. |
|
||||
| TTS provider registry and telephony override routing | `src/tts/providers.ts`, `src/tts/tts.ts`, and plugin provider capability filtering through `src/plugins/runtime.ts` | host-owned TTS runtime registry for a typed backend family | `not started` | TTS providers and telephony TTS overrides should move behind host-owned runtime registries with explicit capability and fallback policy rather than staying coupled to plugin-era provider capabilities and global active-registry reads. |
|
||||
| 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. |
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue