OpenClaw Test Performance

Use evidence first. The goal is real pnpm test, plugin-suite, and plugin-inspector speed/RSS improvement with coverage intact, not runner tuning by guesswork.

Workflow

1. Read the relevant local AGENTS.md files before editing:
   • src/agents/AGENTS.md for agent/import hotspots.
   • src/channels/AGENTS.md and src/plugins/AGENTS.md for plugin/channel laziness.
   • src/gateway/AGENTS.md for server lifecycle tests.
   • test/helpers/AGENTS.md and test/helpers/channels/AGENTS.md for shared contract helpers.
   • src/infra/outbound/AGENTS.md for outbound/media/action tests.
2. Establish a baseline before changing code:
   • Prefer pnpm test:perf:groups --full-suite --allow-failures --output <file> for full-suite ranking.
   • For bundled plugin breadth, run the smallest relevant pnpm test:extensions:batch <plugin[,plugin...]> or plugin-inspector command before jumping to the full extension sweep.
   • For a scoped hotspot use: /usr/bin/time -l pnpm test <file-or-files> --maxWorkers=1 --reporter=verbose
   • For import-heavy suspicion add: OPENCLAW_VITEST_IMPORT_DURATIONS=1 OPENCLAW_VITEST_PRINT_IMPORT_BREAKDOWN=1.
3. Separate wall/runner noise from real file cost:
   • Compare Vitest duration, test body timing, import breakdown, wall time, and max RSS.
   • Re-run single files when grouped/full-suite numbers look stale or noisy.
   • If a full-suite grouped run reports a lane failure but JSON says tests passed, capture that as harness/noise and verify the suspect file directly.
4. Pick the next attack by return and risk:
   • High return: one file/test dominates seconds or RSS and has a clear root.
   • High leverage: one plugin or SDK barrel causes every plugin-inspector or extension-batch run to load broad runtime.
   • Lower risk: static descriptors, target parsing, routing, auth bypass, setup hints, registry fixtures, or test server lifecycle.
   • Higher risk: real memory/runtime behavior, live providers, protocol contracts, or broad production refactors.
5. Fix the root cause, not the symptom:
   • Move static metadata/parsing into narrow helpers or lightweight artifacts reused by full runtime and fast paths.
   • Prefer dependency injection, loaded-plugin-only lookup, explicit fixtures, and pure helpers over broad mocks.
   • Reuse suite-level servers/clients when a fresh handshake is irrelevant.
   • Keep schedulers/background loops off unless the test proves scheduling.
   • In plugin paths, move static metadata into manifest/lightweight artifacts and keep runtime plugin loads behind explicit execution boundaries.
6. Preserve coverage shape:
   • Do not delete a slow integration proof unless the exact production composition is extracted into a named helper and tested.
   • Keep one cheap integration smoke when cross-component wiring matters.
   • State explicitly what incidental coverage was removed, if any.
7. Re-benchmark the same command after the change and compute seconds plus percent gain.
8. Update the running report when requested or when this thread is tracking one. Include before/after commands, artifacts, coverage notes, verification, and next attack order.
9. Commit with scripts/committer "<message>" <paths...> and push when the user asked for commits/pushes. Stage only files touched for this attack.

Plugin-Suite Workflow

Use this section when perf work involves bundled plugins, plugin-inspector, SDK barrels, package-boundary tests, or extension suites.

1. Map the suite shape first:
   • source tests: pnpm test extensions/<id> or pnpm test:extensions:batch <id>
   • package boundaries: pnpm run test:extensions:package-boundary:canary and pnpm run test:extensions:package-boundary:compile
   • all bundled source tests: pnpm test:extensions

…