AgentsMesh E2E
Run the smallest real end-to-end test that proves the requested behavior, then expand coverage in proportion to the change.
Invariants
- Use the current worktree's generated
deploy/dev/.env; never assume fixed ports or container names. - A UI requirement must be verified by a browser or app UI test. Do not replace it with a raw API request.
- Start the development stack only when the selected suite needs it. Record whether this workflow started the stack before deciding whether to clean it.
- Authentication uses Connect-RPC. Never restore the removed REST login route;
read
references/connect-rpc.mdwhen testing auth or proxy routing. - Do not claim a suite passed unless its command completed successfully.
- Preserve test artifacts and relevant service logs when a failure occurs.
Workflow
Inspect the requested behavior and changed files.
Select the suite from
references/test-matrix.md. Read the selected target's BUILD file, config, and nearby tests before running it.Reuse a healthy existing stack. Otherwise start
//deploy/dev:upfor Web flows or//deploy/dev:backend_onlywhen frontends are not required.Load
deploy/dev/.envwith automatic export enabled so Bazel can forward the worktree-specific values:set -a source deploy/dev/.env set +aRun the narrowest relevant spec or test filter first. If it passes, run the owning target when the blast radius warrants it.
For UI behavior, inspect the rendered state and interaction result through the suite's browser/app assertions. Capture a screenshot or trace when the visual result is central to the bug.
On failure, report the failing assertion and inspect the applicable service logs and test artifacts listed in the test matrix.
Clean the stack with
bazel run //deploy/dev:cleanonly when this workflow started it and no concurrent work depends on it.
Result
Report the exact target and filter, actual worktree ports used, pass/fail status, failing evidence when applicable, and any coverage that could not be run with the reason.