openclaw-testing
Openclaw Testing
Codex adaptation of the pinned OpenClaw source. Repository-specific commands apply only to a verified OpenClaw checkout; portable debugger commands apply to their selected process.
Select proof in the owning checkout
Read root/scoped instructions and identify the exact changed contract, source trust and host capacity. The packaged source contains focused command routing, package/Docker branches and CI failure diagnosis; use current checkout commands and help when the pinned reference differs.
Start with touched tests, targeted typecheck/lint/format and required build proof. Builds are relevant for lazy imports, package boundaries and public artifacts; SDK changes need representative consumers. Documentation changes need their docs/link/format checks. Broad PR CI can provide broad proof once publication is authorized; this skill does not itself authorize opening a PR.
Use the existing $openclaw-crabbox for a deliberate capacity/platform/live-service gap. Do not wait on queues, chain providers or force broad tests onto a busy host. Preserve source-trust, budget, credentials and live Gateway boundaries. Contributor-controlled code must use the repository's approved untrusted-source route, not a credentialed local run.
Run repo wrappers, not guessed raw Vitest calls. Separate concurrent Vitest caches or serialize. Reuse valid unaffected evidence; repeat for changed inputs, concrete failures or a named missing risk. For CI, bind logs to the exact SHA/job and classify product, harness, infrastructure, auth and superseded runs before repairing. Do not rerun merely to chase green.
Read source test-audit guidance for independent behavioral assertions; use the installed test-audit workflow as its Codex owner. Sibling upstream release/channel/maintainer references are on-demand source documentation, not installed skills or permissions. Their publication, landing, expected-failure and install policies remain subject to the owning repository and operator authorization; unresolved failures must be reported, not silently declared acceptable.
Report commands, exact source, outcomes, failure classification, unrun gates and strongest proven boundary. Do not turn discovery of commands or a fixture pass into live or cross-platform proof.