TestSprite Files

Added

• Per-test step timeouts from the CLI. test create --step-timeout <ms> and test update --step-timeout <ms> set the 1–60000 ms timeout the execution engine applies to every step; test update --clear-step-timeout restores engine defaults. test get echoes a configured value, validation and mutual exclusion fail before any request, and successful set operations warn that the independent test run --wait --timeout poll deadline may need to be raised without implying that a client timeout stops the server-side run.
• ci init github — scaffold a GitHub Actions workflow in one command. Writes a ready-to-run .github/workflows/testsprite.yml that delegates to the published TestSprite/testsprite-action@v1, so a project gets a CI gate without hand-copying YAML. Because the run, the JUnit upload, the annotations, and the skipped-test guard (allow-partial: false by default — a partial batch fails the job instead of a false green) all live in one maintained action, the scaffold stays a thin, correct wire-up. The generated workflow pins the CLI version (not latest), sets least-privilege permissions: contents: read, skips fork PRs (which have no secrets, so the check can't run), and limits the push trigger to the repo's detected default branch. The project id is auto-detected when the key owns exactly one project (otherwise --project is required, and the validation error names the fix); --filter and --timeout thread into the action, and a non-default endpoint (resolved from your profile / --endpoint-url, not just the flag) is carried through for self-hosted / staging. Interpolated values are validated so the scaffold can never emit a workflow GitHub refuses to parse. --dry-run previews the file without writing; an existing workflow is never clobbered without --force (which keeps a .bak). The workflow reads the key from a TESTSPRITE_API_KEY repo secret; ci init prints the exact gh secret set command to add it, and --set-secret runs it for you when the gh CLI is installed and authenticated (the key is passed on stdin, never the process list), degrading to the printed instruction rather than failing the scaffold.
• test plan generate / test plan accept — ask TestSprite to write the first tests. Until now the CLI could run tests but not come up with them: a project with no tests meant a trip to the Portal, or a coding agent inventing plans by reading the source. testsprite test plan generate --project <id> runs whichever preparation stages the project is still missing — exploring the live app, building the feature map, drafting the cases — shows live progress, and prints the resulting proposals with stable ids. testsprite test plan accept --project <id> turns them into real test cases, all of them or a subset with --only. Nothing is written to your disk: proposals are staged server-side, which is where the review happens, so there is no plan file to manage and no prompt to answer. Only the stages a project is actually missing run — an already-explored project skips straight to proposals — so re-running picks up where the last call left off instead of starting over. Requires a V3-platform account; an account still on the older platform gets a clear message and exit 6 rather than a confusing failure.
• Every precondition failure names its exact fix, and nothing prompts. A frontend project whose environment has no URL, an API project with no processed sources, an account not yet migrated — each exits 6 with the literal command to run next (project update … --url, project docs upload …, or a pointer at the Portal). A generation stage already running — including one started from the Portal — is not an error at all: the command attaches to it and keeps polling. Proposals already staged means nothing is started, said plainly rather than silently no-opped. Ctrl-C detaches honestly (exit 130/143/129) with the truth on stderr — the server keeps working — and --timeout (exit 7) prints a partial object with the project id so re-running the same command re-attaches. --only naming any unknown proposal id is a validation error whose request is never sent, because an empty selection means "reject everything" to the server and would destroy the staged batch.
• project docs upload <file> — supply the source material generation reads. An API project created purely from the CLI used to dead-end: with no uploaded spec there was nothing to build a feature map from, and the only fix was a Portal trip. This uploads an API spec or PRD straight into the project's source pipeline (--role api-doc|prd, display name defaulting to the file name) and starts processing. The file is streamed rather than read into memory, so a large spec costs constant memory; the local file is only ever read, never written back. The two failure points are deliberately distinguished because their fixes differ: if the upload itself fails, nothing was registered and re-running mints a fresh signed URL; if registration fails, the bytes already landed and re-running is safe — the server stores each document by its storage key and replaces rather than duplicates it.
• test run --local <port> and the tunnel command — test an app running on your own machine. Until now a CLI test had to point at something TestSprite could already reach, so an app on localhost meant deploying it first or hand-rolling a public tunnel. testsprite test run <id> --local 3000 opens a TestSprite tunnel, runs the test against http://127.0.0.1:3000, and proxies the runner's traffic back to this machine for as long as the command is running. --local-host picks which loopback spelling the run targets (localhost, 127.0.0.1, ::1) for apps that only answer on one of them. Because the tunnel closes with the process, --local implies --wait and, on Ctrl-C, cancels the run rather than leaving one that could only fail — --no-cancel-on-interrupt opts out. It is mutually exclusive with --target-url, is frontend-only, and probes the port before anything is minted or billed, so a dead port costs nothing. For a longer session, testsprite tunnel start holds one tunnel open across many runs (tunnel status <client-id>, tunnel stop <client-id>); test run --local --tunnel-client <id> attaches to it instead of opening its own, and leaves it running afterwards. The id it prints is a non-secret handle — the credential itself is never echoed. Availability: local runs are rolling out — an account already on the newer platform gets UNSUPPORTED (exit 7) with the reason and a pointer to support, rather than a run that would be charged and could not be trusted; everyone else has it now.

Changed

• test run --all fails (exit 5) when it dispatches zero tests, instead of a silent exit 0. A batch that runs nothing — every test skipped (e.g. a frontend-only project on the backend-only wave engine), an empty project, or a --filter that matched nothing — used to exit 0 with no summary, no annotation, and no JUnit report: a CI gate that greens on zero tests, which is worse than no gate. It now emits the summary, the ::error:: annotation, and the JUnit report (skipped test cases) so the gate shows why, then fails with exit 5. Pass --allow-empty to opt back into exit 0 when a zero-dispatch run is expected. Single-test test run <id> is unaffected (it always has one test).

• CI output shows the test's title, not its raw id. The --gh-output job-summary Test column and the ::error:: annotations rendered the raw testId UUID, so a reviewer saw a column of ids they had to paste into the portal to identify. The run response now carries the test's human title (resolved server-side), and test run, test rerun, and testlist run render title in the summary + annotations, falling back to the id when a title isn't available (older server / unresolved). testlist run's JUnit <testcase name> gets the title too (it had no name-enrichment pass, so it showed the id where test run --all already showed the name). The raw id stays reachable — JUnit keeps it as the testId attribute — so automation is unaffected.

• CI summary links are clickable and point where you'd expect. In the --gh-output job-summary table the test title now links to the test's portal page and the Run column links to that run's execution-result page (two distinct destinations); the ::error:: annotation on a failing run links straight to its result page. Every link is built by the server for the store that actually answered the read — never templated client-side — so it resolves for V3 projects and non-prod endpoints where the old client-built guess was dead or missing. A run with no result page (a V2 run) keeps its raw run id in the Run column, and when the server provides no link the cells stay plain text, exactly as before.
• The live progress line no longer shows a completed/total steps counter. Both read paths compute total and completed from the same set of already-finished step rows (a step row exists only once its step has a verdict), so the two could never differ — the line read 0/0 steps for the whole early window and N/N thereafter. test run --wait, test wait, batch --all --wait, test rerun --wait and testlist run --wait now show the recorded step count when there is one (running · 3 steps · 14s) and just the status and elapsed time otherwise. The final line uses the same shape (the test rerun --wait replay's final line now carries the elapsed time too). Batch members stay tagged (test_id) and closure members [role], as before. The full live step feed is tracked separately (DEV-1018).
• The elapsed counter keeps moving between polls. In long-poll mode the server answers every ~25 s, so the seconds on the progress line used to freeze between answers; test run --wait and test wait now redraw the last snapshot once a second (TTY only; never under NO_COLOR, where each redraw would be a new line).
• test plan generate reports what it actually spent instead of quoting a price up front. The pre-run price quote came from a static table that could drift from what the server charges; the command now stays quiet before the fact and prints the real credits used and the remaining balance when the work is done.

Fixed

• Exit codes are correct on Windows again. On Windows with Node 23 and newer, any failed command printed a low-level crash line and replaced its documented exit code (e.g. 4 for not-found) with -1073740791, so scripts, CI jobs, and coding agents that branch on the CLI's exit codes got garbage instead of a contract. The CLI now lets Node exit on its own rather than forcing the process down, and an end-to-end test pins the real exit code per class.
• Asking for help on a command that does not exist is an error, not silent success. testsprite <typo> --help and testsprite help <typo> printed the root help and exited 0, so a typo in a script looked like a successful run. Both now exit 5 (VALIDATION_ERROR) and name the unknown command.
• agent list is readable. The text table dropped the STATUS/MODE columns in favour of AGENT/SKILL/PATH, folding maturity into an (exp.) tag, and agent install / agent setup now print the reload hint the editor actually needs. --output json is unchanged, so anything scripting against it keeps working.