chore(sync): mirror docs from openclaw/openclaw@c677861032

.openclaw-sync/source.json

@@ -1,5 +1,5 @@
 {
   "repository": "openclaw/openclaw",
-  "sha": "be14820b5d64ddde590bbee409dafcacc73bc78e",
-  "syncedAt": "2026-05-01T06:22:15.944Z"
+  "sha": "c6778610323b43c66b70b871db94001d3b4dc1dd",
+  "syncedAt": "2026-05-01T06:40:02.508Z"
 }

docs/plugins/google-meet.md

@@ -1133,6 +1133,8 @@ Expected Twilio state:
   `twilio-voice-call-credentials`, and `twilio-voice-call-webhook` checks.
 - `voicecall` is available in the CLI after Gateway reload.
 - The returned session has `transport: "twilio"` and a `twilio.voiceCallId`.
+- `openclaw logs --follow` shows DTMF TwiML served before realtime TwiML, then a
+  realtime bridge with the initial greeting queued.
 - `googlemeet leave <sessionId>` hangs up the delegated voice call.
 
 ## Troubleshooting
@@ -1407,6 +1409,10 @@ participant:
   active.
 - Run `openclaw voicecall tail` and check that Twilio webhooks are arriving at
   the Gateway.
+- Run `openclaw logs --follow` and look for the Twilio Meet sequence: Google
+  Meet delegates the join, Voice Call stores pre-connect DTMF TwiML, serves
+  that initial TwiML, then serves realtime TwiML and starts the realtime bridge
+  with `initialGreeting=queued`.
 - Re-run `openclaw googlemeet setup --transport twilio`; a green setup check is
   required but does not prove the meeting PIN sequence is correct.
 - Confirm the dial-in number belongs to the same Meet invitation and region as
@@ -1414,9 +1420,9 @@ participant:
 - Increase the leading pauses in `--dtmf-sequence` if Meet answers slowly, for
   example `wwww123456#`.
 - If the participant joins but you do not hear the greeting, check
-  `openclaw voicecall tail` for a Twilio stream start followed by realtime
-  provider readiness. The greeting is now generated from the initial
-  `voicecall.start` message after the stream connects.
+  `openclaw logs --follow` for realtime TwiML, realtime bridge startup, and
+  `initialGreeting=queued`. The greeting is generated from the initial
+  `voicecall.start` message after the realtime bridge connects.
 
 If webhooks do not arrive, debug the Voice Call plugin first: the provider must
 reach `plugins.entries.voice-call.config.publicUrl` or the configured tunnel.

docs/plugins/voice-call.md

@@ -723,6 +723,7 @@ Then inspect runtime state:
 ```bash
 openclaw voicecall status --call-id <id>
 openclaw voicecall tail
+openclaw logs --follow
 ```
 
 Common causes:
@@ -775,6 +776,19 @@ For Twilio calls, Voice Call serves the DTMF TwiML first, redirects back to the
 webhook, then opens the realtime media stream so the saved intro is generated
 after the phone participant has joined the meeting.
 
+Use `openclaw logs --follow` for the live phase trace. A healthy Twilio Meet
+join logs this order:
+
+- Google Meet delegates the Twilio join to Voice Call.
+- Voice Call stores pre-connect DTMF TwiML.
+- Twilio initial TwiML is consumed and served before realtime handling.
+- Voice Call serves realtime TwiML for the Twilio call.
+- The realtime bridge starts with the initial greeting queued.
+
+`openclaw voicecall tail` still shows persisted call records; it is useful for
+call state and transcripts, but not every webhook/realtime transition appears
+there.
+
 ### Realtime call has no speech
 
 Confirm only one audio mode is enabled. `realtime.enabled` and
@@ -785,8 +799,8 @@ For realtime Twilio calls, also verify:
 - A realtime provider plugin is loaded and registered.
 - `realtime.provider` is unset or names a registered provider.
 - The provider API key is available to the Gateway process.
-- `openclaw voicecall tail` shows the media stream accepted and realtime
-  provider readiness before the initial greeting.
+- `openclaw logs --follow` shows realtime TwiML served, the realtime bridge
+  started, and the initial greeting queued.
 
 ## Related