battle-test

Battle-test the current change

Decide what can be run, run it, score how well the change is actually covered, and hand back the checks a human still has to do. $ARGUMENTS narrows the side (frontend/backend) and the git scope; blank means both sides, all pending changes.

Phase 1 - Triage (before running anything)

1. Resolve the scope: staged -> git diff --cached, unstaged -> git diff, last-commit -> git diff HEAD~1 (empty tree if there is no parent), blank -> both diffs. Add untracked files (git ls-files --others --exclude-standard): a brand-new module is invisible to git diff and is exactly the code least likely to be covered. Not a git repo (git rev-parse --git-dir fails) -> fall back to the files the user names, and say the scope came from them, not from git.
2. Empty-diff guard: no changes in scope -> say so and stop. Do not run a suite for nothing.
3. Detect what the repo actually has (package.json scripts, composer.json, Makefile, pytest/cargo/go, a dev script, a compose file, an emulator), then sort every check that matters for this diff into three buckets and print them before executing anything:
   • AUTO - runnable now, non-destructive, no credentials: test/typecheck/lint/build scripts, and single-file language checks (php -l through the Docker wrapper, tsc --noEmit, node --check).
   • BOOTABLE - runnable after starting something the repo owns: dev server, Docker stack, emulator. Start it, use it, stop only what this run started.
   • MANUAL - impossible here: prod or client credentials, a real payment, a real device, a third-party dashboard, an email or message actually arriving, a visual judgment call, or a production DB change.

Bucket by what the diff touches, not by what the repo owns. A backend-only diff earns no browser pass.

1. Blast-radius preflight, before the first command runs. A check that can reach real data or a real person is NOT auto, whatever the script is named. The default is refuse, not try:
   • Read the env the command will actually use (.env*, firebase.json / .firebaserc, the compose file, the test config) before running it. Pointed at a production project, a live API key, a shared staging DB, a real SMTP host or a third-party webhook -> MANUAL. Prefer the repo's emulator or test env; if the only env available is the real one, do not run it.
   • Anything that reaches a human (email, SMS, WhatsApp, push, a call to a partner API that bills or writes) is MANUAL even in "test mode", unless the repo pins a sandbox you verified.
   • Anything that mutates a store: seed, reset, migrate, truncate, --force, fixtures that drop collections. MANUAL unless it provably targets a local throwaway you started.
   • Rate-limited or paid third parties (Apollo, LinkedIn, HubSpot, OpenAI, a payment provider): MANUAL. Burning a client's quota to raise a score is not a trade worth making. When you cannot tell which env a command uses, it is MANUAL. State the reason in one line and move on; an unrun check costs points, and that is the correct outcome.