Docs: refresh TTS API migration status

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

@@ -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
-- remaining media compatibility-facade cleanup, remaining TTS facade cleanup, plus catalog-backed runtime-family registration for embeddings, media, and TTS, should become runtime-internal subsystem registries rather than remaining part of a universal plugin-provider API
+- remaining media compatibility-facade cleanup, plus catalog-backed runtime-family registration for embeddings, media, and TTS, should become runtime-internal subsystem registries rather than remaining part of a universal plugin-provider API
 - 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 remaining media compatibility-facade cleanup, remaining TTS facade cleanup, plus catalog-backed runtime-family registration for embeddings, media, and TTS, with explicit capability routing and built-in fallback policy.
+9. Finish remaining media compatibility-facade cleanup plus catalog-backed runtime-family registration 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.

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

@@ -261,6 +261,7 @@ Committed implementation slices so far:
 - `fa4f53896e` `TTS: extract runtime setup`
 - `64353a2b16` `TTS: extract preferences`
 - `ed5941ed7e` `TTS: extract payload planning`
+- `454e44242f` `TTS: extract API composition`
 - `89414ed857` `Docs: track extension host migration internally`
 - `d8af1eceaf` `Docs: refresh extension host migration status`
 
@@ -270,7 +271,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
-- remaining media compatibility-facade cleanup, remaining TTS facade cleanup, plus catalog-backed runtime-family registration for embeddings, media, and TTS
+- remaining media compatibility-facade cleanup, plus catalog-backed runtime-family registration 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
 
@@ -280,7 +281,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, and safe-reindex temp-db creation, file swap, reopen, and cleanup now extracted, media registry, execution, auto-entry selection, active-model fallback, orchestration, and planning helpers now extracted, TTS registry, execution, request setup, config normalization, preferences, payload planning, and shared status state now extracted, and the remaining media compatibility-facade cleanup, TTS facade cleanup, plus catalog-backed runtime-family registration for embeddings, media, and TTS 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, and safe-reindex temp-db creation, file swap, reopen, and cleanup now extracted, media registry, execution, auto-entry selection, active-model fallback, orchestration, and planning helpers now extracted, TTS registry, execution, request setup, config normalization, preferences, payload planning, shared status state, and API composition now extracted, and the remaining media compatibility-facade cleanup plus catalog-backed runtime-family registration for embeddings, media, and TTS 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
 

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

@@ -140,13 +140,14 @@ How it has been implemented:
 - by introducing host-owned runtime-registry accessors for channel, provider, tool, service, CLI, command, gateway-method, and HTTP-route consumers first, then moving channel, provider, tool, command, HTTP-route, gateway-method, CLI, and service storage into that host-owned state while keeping mirrored legacy compatibility arrays and handler maps
 - by moving plugin command duplicate enforcement, registration, matching, execution, listing, native command-spec projection, and loader reload clearing into `src/extension-host/command-runtime.ts` while keeping the legacy command module as a compatibility facade
 - by tightening the CLI pre-load fast path to treat any host-known runtime entry surface as already loaded rather than only plugins, channels, or tools
+- by moving the remaining TTS API composition, system-prompt hint assembly, request validation, telephony setup, auto-TTS payload application, and failed-conversion fallback handling into `src/extension-host/tts-api.ts` while keeping `src/tts/tts.ts` as the compatibility facade
 
 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
-- remaining media compatibility-facade cleanup, remaining TTS facade cleanup, plus catalog-backed runtime-family registration for embeddings, media, and TTS, including explicit fallback and override policy instead of plugin-era capability reads
+- remaining media compatibility-facade cleanup plus catalog-backed runtime-family registration 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
@@ -745,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 remaining media compatibility-facade cleanup, remaining TTS facade cleanup, plus catalog-backed runtime-family registration for embeddings, media, and TTS, instead of widening `registerProvider(...)`.
+7. Finish remaining media compatibility-facade cleanup plus catalog-backed runtime-family registration 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.

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

@@ -247,6 +247,7 @@ Committed implementation slices so far:
 - `fa4f53896e` `TTS: extract runtime setup`
 - `64353a2b16` `TTS: extract preferences`
 - `ed5941ed7e` `TTS: extract payload planning`
+- `454e44242f` `TTS: extract API composition`
 - `89414ed857` `Docs: track extension host migration internally`
 - `d8af1eceaf` `Docs: refresh extension host migration status`
 
@@ -255,7 +256,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
-- remaining media compatibility-facade cleanup, remaining TTS facade cleanup, plus catalog-backed runtime-family registration for embeddings, media, and TTS
+- remaining media compatibility-facade cleanup, plus catalog-backed runtime-family registration for embeddings, media, and TTS
 - SDK compatibility translation work
 - canonical event stages
 - canonical capability catalogs