touched code. Aim for one after-fix E2E proof before commenting, closing, or

opening a PR for a user-visible bug.

When the user says "test in Crabbox", do not simply copy tests to the remote

box and run them there. Crabbox is for remote real-scenario proof: copy or

install OpenClaw as the user would, run the same setup/update/CLI/Gateway/API

call that failed, and capture behavior from that entrypoint. For regressions or

bug reports, prove the broken state first when feasible, then run the same

scenario after the fix.

Pick the lane by symptom:

- Docker/setup/install bug: build a package tarball and run the matching

Efficient flow:

1. Reproduce or prove the pre-fix symptom when feasible. If the issue cannot be

reproduced, capture the exact command and observed behavior instead.

1. Reproduce or prove the pre-fix symptom from the real user-facing entrypoint

when feasible. If the issue cannot be reproduced, capture the exact command

and observed behavior instead.

2. Patch locally and run narrow local tests for edit speed.

3. Run one Crabbox E2E command that starts from the user-facing entrypoint:

package install, Docker setup, onboarding, channel add, gateway start, or

## Validation

- Use `$openclaw-testing` for test/CI choice and `$crabbox` for remote/full/E2E proof.

- Crabbox request means real scenario proof: install/update/call/repro user path; not just copy tests and run them remotely.

- Small/narrow tests, lints, format checks, and type probes are fine locally only in a healthy normal checkout.

- In Codex worktrees, direct local `pnpm test*`, `pnpm check*`, `pnpm crabbox:run`, and `scripts/committer` can trigger pnpm dependency reconciliation or install prompts. Prefer `node` wrappers locally and Crabbox/Testbox for pnpm-gated proof.

- Full suites, broad changed gates, Docker/package/E2E/live/cross-OS proof, or anything that bogs down the Mac: Crabbox/Testbox.