Greptile Summary

This PR adds Inworld AI as a fourth built-in TTS provider alongside OpenAI, ElevenLabs, and Microsoft. The integration follows the existing provider plugin pattern well: a new extensions/inworld/ package implements SpeechProviderPlugin with streaming synthesis, voice listing, and telephony support; the core src/tts/tts.ts wires in auto-detection and config resolution; and all the surrounding plumbing (Zod schema, secrets collection, /tts command status, generated baselines) is updated consistently.

Key findings:

• Temperature schema off-by-one (gt(0) → should be gte(0)): The types.tts.ts JSDoc documents the valid range as 0–2, but the Zod schema uses .gt(0), silently rejecting the minimum documented value. Users who set temperature: 0 for deterministic synthesis will hit a schema error.
• pull_policy: never in docker-compose.yml: This unrelated change, applied to both openclaw-gateway and openclaw-cli, prevents Docker from pulling pre-built images and will break docker-compose up for users without locally-built images.
• Unguarded JSON.parse in the NDJSON streaming loop: A non-JSON line from the API would produce an opaque SyntaxError instead of a descriptive Inworld-specific message.

Confidence Score: 4/5

Safe to merge after addressing the temperature schema bug and reverting the unrelated pull_policy: never docker-compose change.

Two P1 findings remain: a schema validation bug that rejects a documented valid input value, and an unrelated docker-compose change that breaks image-pull deployments. The core implementation is otherwise solid and well-tested.

src/config/zod-schema.core.ts (temperature range) and docker-compose.yml (pull_policy: never).

This is a comment left during a code review.
Path: src/config/zod-schema.core.ts
Line: 455

Comment:
**Temperature validation rejects documented minimum value**

The Zod schema uses `.gt(0)` (strictly greater than 0), but the JSDoc comment in `src/config/types.tts.ts` defines the valid range as `"0–2"`, meaning `temperature: 0` is a documented and plausible value (e.g. for deterministic, low-variance synthesis). Any user who tries to set `temperature: 0` will get a schema validation error, silently contradicting the documented range.

```suggestion
        temperature: z.number().gte(0).lte(2).optional(),
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: docker-compose.yml
Line: 31

Comment:
**`pull_policy: never` breaks image-pull deployments**

Adding `pull_policy: never` to both `openclaw-gateway` (line 31) and `openclaw-cli` (line 48) means Docker will never attempt to pull a pre-built image from a registry. Any user who does not already have the image locally and runs `docker-compose up` will get an immediate `"unable to find image ... locally"` error instead of pulling the image.

This appears to be a local-development convenience setting that leaked into the shared `docker-compose.yml`. It is also unrelated to the Inworld TTS feature and should either be reverted or kept only in a local override file (`docker-compose.override.yml`).

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: extensions/inworld/speech-provider.ts
Line: 88-94

Comment:
**Unguarded `JSON.parse` in streaming loop**

If the Inworld API returns a line that is not valid JSON (e.g., a rate-limit HTML error page that slips through after a `200` status, or a partial flush), `JSON.parse(trimmed)` will throw a raw `SyntaxError`. The error will propagate out of `inworldTTS`, be caught by the provider-level try/catch in `synthesizeSpeech`, and surface as a cryptic `"Unexpected token …"` message rather than something actionable.

Wrapping the parse in a try/catch with a descriptive re-throw would make debugging much easier:

```ts
let parsed: { result?: { audioContent?: string }; error?: { code?: number; message?: string } };
try {
  parsed = JSON.parse(trimmed) as typeof parsed;
} catch {
  throw new Error(`Inworld TTS stream parse error: unexpected non-JSON line: ${trimmed.slice(0, 80)}`);
}
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "feat(tts): add Inworld as built-in speec..." | Re-trigger Greptile}

Deep review against current main (5163a2f): this is a real missing provider, but the PR still needs work before land.

Current state:

• main has no Inworld plugin/provider (rg "inworld|INWORLD" returns nothing).
• .profile does not currently expose INWORLD_API_KEY, so I could not run a live synthesis probe here.
• Official Inworld docs still match the basic API shape used here: POST https://api.inworld.ai/tts/v1/voice:stream, Authorization: Basic $INWORLD_API_KEY, newline JSON chunks with result.audioContent.

Good changes since the earlier bot review:

• The current diff no longer shows the unrelated docker-compose.yml pull_policy: never change.
• The stream parser now wraps JSON.parse and reports a provider-specific parse error.
• This includes docs, changelog, provider tests, and uses the current plugin speech-provider contract.

Remaining blockers:

1. CI is still red on this head: checks-node-agentic-control-plane and aggregate checks-node-core failed. That has to be green before land.
2. New bundled plugin surface needs repo plumbing check: add/update labeler coverage for extensions/inworld/** if missing, and make sure bundled plugin metadata generation/checks are current.
3. Add a small live/contract note or test fixture for the exact Inworld auth expectation. The docs say Authorization: Basic $INWORLD_API_KEY; users often interpret API keys as raw bearer-style tokens, so docs should state the value must be the Inworld Basic credential exactly as copied/generated.
4. Consider a provider-specific docs page (docs/providers/inworld.md) or at least link the Inworld config from provider docs. docs/tools/tts.md is useful, but new first-class providers usually deserve a provider page/discoverable entry.

So: valid provider, not solved on main, and the implementation is close, but do not merge with current red CI.

@steipete Thanks for the detailed review. I've pushed updates addressing all four blockers:

1. CI — rebased the branch onto current origin/main (was 3,600+ commits behind, which is what was driving the conflicts and likely some of the red checks). The earlier checks-node-agentic-control-plane / checks-node-core failures should now be re-evaluated against current main. Locally I'm green on pnpm test extensions/inworld (22/22), pnpm test:bundled, pnpm config:docs:check, and pnpm build. The remaining pnpm tsgo failures I see locally are all in unrelated files (src/gateway/server-methods/*, src/plugin-sdk/provider-tools.ts, ui/src/ui/*) — none mention Inworld and they reproduce on stock origin/main.

2. Repo plumbing — added extensions: inworld to .github/labeler.yml (covers extensions/inworld/** and docs/providers/inworld.md). Heads up: the matching GitHub label needs to be created on the repo side before the workflow can apply it — would you mind adding extensions: inworld with the existing extensions: * color (#0E8A16)? Also enriched extensions/inworld/openclaw.plugin.json with name, description, providerAuthEnvVars, and a real configSchema (apiKey/baseUrl/voiceId/modelId/temperature with descriptions and bounds), and regenerated docs/.generated/config-baseline.sha256 to match.

3. Auth docs — strengthened the callout in docs/tools/tts.md and added a matching inline comment in extensions/inworld/tts.ts near the Authorization header. Both make it explicit that apiKey must be the Base64 credential from the Inworld dashboard, sent verbatim as Authorization: Basic <apiKey>, and to not pass a raw bearer token or Base64-encode it again.

4. Provider docs page — added docs/providers/inworld.md (modeled on docs/providers/deepgram.md) and wired it into the Providers nav in docs/docs.json alphabetically.

One incidental: while rebasing, I also realigned the SDK imports from openclaw/plugin-sdk/speech to openclaw/plugin-sdk/speech-core to match the merged Gemini TTS template (#67515) — same exports, just the post-extraction canonical path.

@obviyus I saw you merged in a Gemini TTS PR (#67515) recently.

If you could take a look at this PR for Inworld TTS (currently #1 on Artificial Analysis TTS arena) that would be much appreciated! Thanks!

Landed in 0bcb4c9.

Maintainer proof:

• CI green on source SHA e2fbe6a.
• Local targeted tests: pnpm test src/plugin-sdk/facade-loader.test.ts src/plugins/setup-registry.test.ts src/plugins/doctor-contract-registry.test.ts src/channels/plugins/module-loader.test.ts src/cli/program/preaction.test.ts src/infra/diagnostic-events.test.ts extensions/inworld.
• Local typecheck: pnpm tsgo:all.
• Live .profile Inworld check: OPENCLAW_LIVE_TEST_QUIET=0 pnpm test:live extensions/inworld/inworld.live.test.ts.

Also verified no open Inworld duplicate issues/PRs remain.