diff --git a/.openclaw-sync/source.json b/.openclaw-sync/source.json index 22d116944..c54263b25 100644 --- a/.openclaw-sync/source.json +++ b/.openclaw-sync/source.json @@ -1,5 +1,5 @@ { "repository": "openclaw/openclaw", - "sha": "68e7db753b9652a99540761e40fa8e721d5333d4", - "syncedAt": "2026-04-23T08:39:58.352Z" + "sha": "57f28285be43a2d6a68cbfa5d8a3ca16720b3ac9", + "syncedAt": "2026-04-23T09:04:10.440Z" } diff --git a/docs/concepts/qa-e2e-automation.md b/docs/concepts/qa-e2e-automation.md index c6219b2f1..c499c0198 100644 --- a/docs/concepts/qa-e2e-automation.md +++ b/docs/concepts/qa-e2e-automation.md @@ -82,6 +82,8 @@ observation works best when both bots have Bot-to-Bot Communication Mode enabled in `@BotFather`. The command exits non-zero when any scenario fails. Use `--allow-failures` when you want artifacts without a failing exit code. +The Telegram report and summary include per-reply RTT from the driver message +send request to the observed SUT reply, starting with the canary. Live transport lanes now share one smaller contract instead of each inventing their own scenario list shape: diff --git a/docs/help/testing.md b/docs/help/testing.md index c6042284f..b69bb0fd0 100644 --- a/docs/help/testing.md +++ b/docs/help/testing.md @@ -133,7 +133,7 @@ runs the same lanes before release approval. want artifacts without a failing exit code. - Requires two distinct bots in the same private group, with the SUT bot exposing a Telegram username. - For stable bot-to-bot observation, enable Bot-to-Bot Communication Mode in `@BotFather` for both bots and ensure the driver bot can observe group bot traffic. - - Writes a Telegram QA report, summary, and observed-messages artifact under `.artifacts/qa-e2e/...`. + - Writes a Telegram QA report, summary, and observed-messages artifact under `.artifacts/qa-e2e/...`. Replying scenarios include RTT from driver send request to observed SUT reply. Live transport lanes share one standard contract so new transports do not drift: @@ -303,7 +303,7 @@ Think of the suites as “increasing realism” (and increasing flakiness/cost): ### Unit / integration (default) - Command: `pnpm test` -- Config: ten sequential shard runs (`vitest.full-*.config.ts`) over the existing scoped Vitest projects +- Config: untargeted runs use the `vitest.full-*.config.ts` shard set and may expand multi-project shards into per-project configs for parallel scheduling - Files: core/unit inventories under `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts`, and the whitelisted `ui` node tests covered by `vitest.unit.config.ts` - Scope: - Pure unit tests @@ -314,7 +314,7 @@ Think of the suites as “increasing realism” (and increasing flakiness/cost): - No real keys required - Should be fast and stable - Projects note: - - Untargeted `pnpm test` now runs eleven smaller shard configs (`core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) instead of one giant native root-project process. This cuts peak RSS on loaded machines and avoids auto-reply/extension work starving unrelated suites. + - Untargeted `pnpm test` now runs twelve smaller shard configs (`core-unit-fast`, `core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) instead of one giant native root-project process. This cuts peak RSS on loaded machines and avoids auto-reply/extension work starving unrelated suites. - `pnpm test --watch` still uses the native root `vitest.config.ts` project graph, because a multi-shard watch loop is not practical. - `pnpm test`, `pnpm test:watch`, and `pnpm test:perf:imports` route explicit file/directory targets through scoped lanes first, so `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` avoids paying the full root project startup tax. - `pnpm test:changed` expands changed git paths into the same scoped lanes when the diff only touches routable source/test files; config/setup edits still fall back to the broad root-project rerun.