bitfab-cli 0.2.413 → 0.2.414

package/dist/index.js

@@ -29868,10 +29868,10 @@ var semver3 = __toESM(require_semver2(), 1);
 
 // ../bitfab-plugin-lib/dist/bakedSdkVersions.js
 var BAKED_SDK_VERSIONS = {
-  typescript: "0.63.3",
-  python: "0.63.3",
-  ruby: "0.63.3",
-  go: "0.63.4"
+  typescript: "0.64.0",
+  python: "0.64.0",
+  ruby: "0.64.0",
+  go: "0.64.0"
 };
 
 // ../bitfab-plugin-lib/dist/installedSdk.js
@@ -36515,7 +36515,7 @@ If the block prints \`ERROR: Bitfab plugin not installed\`, the user hasn't inst
     inspect: "Diagnose (and offer to fix) your tracing setup: auth, what's instrumented, plugin/SDK freshness, replay coverage, trace arrival.",
     "switch-org": "Switch which Bitfab org the plugin reads and writes (replaces the local API key).",
     replay: "Create or update replay registry modules for instrumented workflows.",
-    cloud: "Run your normal replay on your own GitHub Actions by adding --cloud. One workflow file in the repository; no Bitfab repository connection or GitHub CLI required.",
+    cloud: "Run your normal replay on your own GitHub Actions by adding --cloud: same options, same output, same exit code. One workflow file in the repository; no Bitfab repository connection or GitHub CLI required.",
     "db-snapshot": "Set up per-trace database snapshots so replay runs against the DB state at trace time (TypeScript, Python, Ruby).",
     templates: "Iterate on the span-rendering templates for one trace function.",
     "analyze-repo": "Read-only discovery: scan source, rank the top workflows to instrument, and report recommendations without creating artifacts or changing code."
@@ -36579,35 +36579,29 @@ Never modify existing code on a refactor path without completing this three-step
           kind: "action",
           title: "Inspect the replay environment",
           toolCalls: ["bash", "read", "glob", "grep", "ask"],
-          body: `Cloud replay runs the replay the user already runs locally on their own GitHub Actions: they add --cloud to their normal bitfab-replay command and every other option works the same. The code that snapshots, dispatches, watches, and runs the replay ships inside the SDK, and the repository keeps one file: .github/workflows/bitfab-replay.yml, which holds only settings (install steps, the secrets the replay reads, the runner, and an optional Environment). Nothing else is written to the repository.
+          body: `Cloud replay is the user's normal replay plus --cloud: every replay option works the same, the runner replays a snapshot of their working tree (changed files, plus new files git does not ignore) from the same directory, and the command prints the replay's own output and exits with its exit code. The code ships inside the SDK, and the repository keeps one file: .github/workflows/bitfab-replay.yml, which holds only settings.
 
-Read the existing GitHub Actions, runtime manifests, lockfiles, replay registry, gitignore, and environment-variable NAMES. Never read or print secret values. Check the git origin is github.com and Python 3.10+ exists (macOS or Linux). GitHub access needs no GitHub CLI: the SDK uses gh when it is logged in, otherwise GH_TOKEN or GITHUB_TOKEN, otherwise the github.com credential git already stores for pushing. Only copying secrets from local files needs gh. Run the installed SDK's bitfab-replay --cloud --help; if it does not describe --cloud-init with --secret, upgrade the SDK through bitfab:update before continuing.
+Run the installed SDK's bitfab-replay --cloud --help; if it does not list --cloud-preview, upgrade the SDK through bitfab:update first. Check that the git origin is github.com and that Python 3.10+ exists (macOS or Linux). GitHub access needs no GitHub CLI: the SDK uses gh when it is logged in, otherwise GH_TOKEN or GITHUB_TOKEN, otherwise the github.com credential git stores. When the repository still has .bitfab/cloud.json from an older SDK, the SDK says to delete it and the old workflow and run --cloud-init again; show the user the old file's settings first.
 
-When the repository has .bitfab/cloud.json from an older SDK, run bitfab-replay --cloud-init from the directory where replay normally runs. It moves the settings into the workflow, removes .bitfab/cloud.json and any old .bitfab/cloudReplay.py, and reports droppedCommand when cloud.json had a custom replay command: the runner now starts the same bitfab-replay the user runs locally, so move any environment variables that command set into the Replay step's env. When the Replay step did not run the SDK command, pass --run with the command that starts bitfab-replay. Show the diff.
+Read the existing GitHub Actions, lockfiles, replay registry, and environment-variable NAMES; never read or print secret values. Note what the replay needs beyond an install (build or code-generation steps, services, the working directory) and which environment variables it reads from secrets. For database reads, prefer database branching: it needs no database secret, but only works when every registry entry that reads the database sets dbBranch and the application takes its connection per call from the replay branch URL (getCurrentReplayBranch().databaseUrl, or the Python, Ruby, or Go equivalent); offer db-snapshot mode when either piece is missing. Do not silently give replay production side effects.
 
-Inspect push-triggered workflows and deployment integrations: each replay pushes a temporary bitfab-replay/<UUID> branch. --cloud-init lists the ones it finds in reviewPushTriggers. Offer the usual fixes: a push workflow can add bitfab-replay/** to branches-ignore, or, when its push trigger already lists branches (GitHub does not allow both keys on one trigger), add !bitfab-replay/** as the last entry of that list, and a Vercel project can skip those branches with git.deploymentEnabled {"bitfab-replay/**": false} in its vercel.json or an Ignored Build Step in the dashboard. Ask before changing existing CI or deployment behavior.
+Say plainly which identity the runner uses: only the credentials in its GitHub secrets, never the user's. Local gcloud or AWS logins do not travel to the runner; when a secret is a service account, ask for its email (never the key) and, when the user's CLI is logged in, check it can read what replay reads, such as gcloud storage ls gs://<bucket> --impersonate-service-account=<email>.
 
-Compare what --cloud-init will detect with the project's CI (its result lists what it detected): the runtime and version, package manager, install command, build or code-generation steps, services, and working directory every pipeline in the registry needs. Go needs --run with the command that starts its registry program, such as go run ./cmd/registry, and the program must call RunCloudReplayCLI before building its registry. For database reads, prefer database branching: when the Bitfab organization has a database connected, each replay item gets a branch at its trace's captured instant and the runner needs no database secret. That works only when every registry entry that reads the database sets dbBranch and the application takes its connection per call from the replay branch URL (getCurrentReplayBranch().databaseUrl, or the Python, Ruby, or Go equivalent). A pool created once at import from DATABASE_URL never sees the branch, so check how the application builds its database client, and offer db-snapshot mode when either piece is missing. Without branching, a private database needs runner network access or a replay-safe fixture. Do not silently give replay production side effects. Submodules/gitlinks and credential-like tracked files are refused by the snapshot; a gitlink with no .gitmodules entry is usually a nested repository committed by accident, so offer to untrack it with git rm --cached and ignore its folder.
-
-Say plainly which identity the runner uses: it authenticates only with the credentials in its GitHub secrets, never as the user. Local gcloud, AWS, or other cloud logins do not travel to the runner, so a bucket the user can read from their laptop can still refuse the runner. When a credential secret is a service account, ask for its email (never the key) and, when the user's own CLI is logged in, check that the account can read what replay reads, such as gcloud storage ls gs://<bucket> --impersonate-service-account=<email>. Report a refusal as the fix to make before the first run.
-
-State who can start a replay: once GitHub has registered the workflow, anyone with write access to the repository can dispatch it on any branch, including code the user never reviewed, and that run receives every secret the workflow reads. Recommend a GitHub Environment (environment: bitfab-replay, set with --environment bitfab-replay) holding the replay secrets, with required reviewers, so no run gets credentials until someone approves it. Name the tradeoff: every replay then waits for an approval. Let the user decline.
-
-Present the secret names the replay needs, the Environment choice, and any push-trigger exclusions. Ask only about unresolved choices. Never ask for secret values in chat.`,
+State who can start a replay: once GitHub registers the workflow, anyone with write access can dispatch it on any branch, and that run receives every secret it reads. Recommend a GitHub Environment with required reviewers (environment: bitfab-replay, set with --environment bitfab-replay), and name the tradeoff that every replay then waits for an approval. Ask only about unresolved choices (secret names, the Environment). Never ask for secret values in chat.`,
           next: "cloud/install"
         },
         {
           id: "install",
           kind: "action",
           title: "Write the cloud replay workflow",
-          toolCalls: ["bash", "read", "write", "edit"],
-          body: `From the directory where replay normally runs, run the SDK's bitfab-replay --cloud-init with --secret <NAME> for each environment variable the replay reads from a secret (BITFAB_API_KEY is always included), --environment <name> when the user chose one, and --check "<command>" when replay reads cloud storage or another service with its own credentials, such as a small script that reads one object from the bucket. Add --run "<command>" for Go or when the detected command is wrong, and --runs-on <label> to match existing CI. It detects the runtime, package manager, and install command from the directory it runs in, and writes .github/workflows/bitfab-replay.yml, the only file it creates. Running it again on a current setup changes nothing.
+          toolCalls: ["bash", "read", "write", "edit", "ask"],
+          body: `From the directory where replay normally runs, run the SDK's bitfab-replay --cloud-init with --secret <NAME> for each environment variable the replay reads from a secret (BITFAB_API_KEY is always included), --environment <name> when chosen, and --check "<command>" when replay reads a bucket or service with its own credentials. It detects the runtime, package manager, install command, and replay command (for Go, the program that calls RunCloudReplayCLI), writes the workflow, and returns next: the remaining steps with the exact secret names and the page to create them on. Work through that list with the user.
 
-Review the generated workflow against the project's CI and edit it directly for anything detection missed, such as a build step, code generation, a monorepo install filter, or services. When the user normally starts replay through a wrapper script that sets environment variables, add those variables to the Replay step's env, because the runner starts bitfab-replay itself. Pin any third-party action you add to a reviewed commit SHA. Keep its run-name and its execution_id and request inputs as generated: the SDK finds and feeds each run through them. Put every variable the replay reads from a secret in the Replay step's env, written like the generated entries: a GitHub expression reading secrets.<GitHub secret name>. That mapping is what --cloud-secrets and the runner's empty-secret check read, so a secret stored under another name is mapped there directly, such as OPENAI_API_KEY reading secrets.EVAL_OPENAI_API_KEY, and a non-secret value reads vars.<name>. When the registry's Bitfab client reads its key from another variable, map the same secret to that name too. When a setup step needs a credential file, such as a Google service account JSON, write it under $RUNNER_TEMP with umask 077 and export its path through $GITHUB_ENV: a step whose env maps GOOGLE_CREDENTIALS_JSON from its secret and whose run is umask 077; printf '%s' "$GOOGLE_CREDENTIALS_JSON" > "$RUNNER_TEMP/google.json"; echo "GOOGLE_APPLICATION_CREDENTIALS=$RUNNER_TEMP/google.json" >> "$GITHUB_ENV". Do not use google-github-actions/auth or similar actions that write the key file into the checked-out workspace. Do not copy deployment steps, local env values, or API keys into the workflow.
+Edit the workflow directly for anything detection missed, such as a build step, code generation, a monorepo install filter, or a service, and pin any added action to a commit SHA. When the user normally starts replay through a wrapper that sets environment variables, add them to the replay step's env. Every variable read from a secret stays in that env as a GitHub expression reading secrets.<name>, which is how --cloud-secrets and the runner's empty-secret check find them; a secret stored under another name is mapped directly, such as OPENAI_API_KEY reading secrets.EVAL_OPENAI_API_KEY, and a non-secret value reads vars.<name>. When a setup step needs a credential file, write it under $RUNNER_TEMP with umask 077 and export its path through $GITHUB_ENV; do not use google-github-actions/auth or similar actions that write the key into the checked-out workspace. Do not copy deployment steps or secret values into the workflow.
 
-Secrets are read from GitHub secrets prefixed BITFAB_CLOUD_ unless the user asks otherwise (--secret-prefix, or an empty prefix to reuse bare-named secrets), so BITFAB_CLOUD_OPENAI_API_KEY reaches the replay as OPENAI_API_KEY and replay credentials never collide with secrets the repository already uses. Tell the user which secrets to create (the init result lists them) in GitHub Settings \u2192 Secrets and variables \u2192 Actions, in the repository or the Environment. BITFAB_API_KEY belongs to the Bitfab organization that holds the registry's traces; confirm that, because a key from another organization finds none of them. Have the user create a dedicated key for the runner on the API keys page of the Bitfab dashboard, named for what it is (such as "GitHub cloud replay"), rather than reusing the key the plugin logged in with or their personal development key, so it can be revoked or rotated on its own. BITFAB_SERVICE_URL is optional; do not override the SDK default with an empty variable. Do not create a Bitfab cloud target, install a GitHub App, or request a repository connection.
+For BITFAB_API_KEY, have the user create a dedicated key for the runner on the Bitfab dashboard's API keys page, in the organization that holds the registry's traces, named for what it is (such as "GitHub cloud replay"), and set it by hand. For the other secrets, when local environment files define them, ask once whether to copy them, then run bitfab-replay --cloud-secrets --env-file <file> --dry-run, then without --dry-run. It pipes values to gh on standard input, creates a missing Environment, and without the GitHub CLI returns createByHand with the page to create them on; relay that list instead of treating it as a failure. Never hand-extract a value with grep, cut, or a shell variable. Warn before copying a value a runner cannot use, such as a localhost URL. Setting secrets needs the same explicit authorization as any other remote write.
 
-When the project keeps local environment files, list the NAMES each secret could come from and ask once whether to copy those local values into GitHub. Never read, print, or compare the values. On a yes, run bitfab-replay --cloud-secrets --env-file <file> [--env-file <file>] --dry-run first, then without --dry-run. It reads the secret names and the Environment from the workflow, parses quoted, multi-line, and JSON values, and pipes each value to gh on standard input so it never appears in arguments, process listings, or shell history. Without gh it says which secrets to create by hand and where. Never hand-extract a value with grep, cut, or a shell variable, and never pass one through gh secret set --body. A name the files define as blank is skipped, because an empty secret replaces a working default with nothing. Warn before copying a value that points somewhere a runner cannot reach, such as a localhost URL, or that grants more than replay needs. Leave BITFAB_API_KEY out of the copy by default and have the user set the dedicated runner key by hand. Environment secrets need the Environment to exist: check with gh api repos/<owner>/<repo>/environments, and ask before creating it with gh api -X PUT repos/<owner>/<repo>/environments/<name>, offering the user as a required reviewer. Setting secrets requires the same explicit authorization as any other remote write.`,
+Each replay pushes a temporary bitfab-replay/<UUID> branch. For each push-triggered workflow or deployment in reviewPushTriggers, offer to exclude those branches: branches-ignore: [bitfab-replay/**] on a push trigger (or a last !bitfab-replay/** entry when it already lists branches), and git.deploymentEnabled {"bitfab-replay/**": false} in vercel.json. Ask before changing existing CI or deployments.`,
           next: "cloud/verify"
         },
         {
@@ -36615,11 +36609,11 @@ When the project keeps local environment files, list the NAMES each secret could
           kind: "action",
           title: "Verify and hand off",
           toolCalls: ["bash", "read", "ask"],
-          body: `Validate workflow syntax (actionlint when available). GitHub must register the workflow before it can be dispatched, and merging it to the default branch once registers it. After that, each replay dispatches the workflow as it is in that replay's snapshot, so later edits apply on the next replay without merging. Explain the one required merge. Do not push, merge, change repository permissions, or set secrets without authorization.
+          body: `Validate the workflow (actionlint when available). GitHub must register it before it can be dispatched: merging it to the default branch once does that, and after that each replay runs the copy in its own snapshot, so later edits apply without merging. Do not push, merge, or change repository settings without authorization.
 
-Verify with the replay command the user already runs, plus cloud flags. First add --cloud --cloud-dry-run, which pushes nothing and reports the changed tracked files and omitted new files; include new source files with repeated --cloud-include <repository-relative-file> (until the workflow is committed, include it too). Review the entire snapshot for credentials; filename screening is not a secret scanner. Then, once the workflow is merged and the secrets are set, and when remote runs are authorized, run the same command with --cloud --dry-run. That dispatches a real run that replays nothing but receives the workflow's secrets, so it needs the same authorization as a replay: it stops with the names of any mapped secrets that are empty (GitHub turns a secret that does not exist into an empty string), runs the --check command, and resolves the traces with the replay's own --dry-run, proving the registry loads and the Bitfab key reaches the traces. --cloud-check is the same. Fix what it reports before the first replay, reading the Replay step log it links. Then, only when remote replay is authorized, run with just --cloud. Every replay option works as it does locally, in any order; --params and --code-change files must be in the snapshot; seeding stays local. Add --fail-on-error when a script should exit 1 on errored items. HEAD, staged changes, and working files stay untouched; never reset or undo the user's work.
+Verify with the replay command the user already runs. First add --cloud --cloud-preview, which pushes nothing and lists the changed and new files the snapshot would carry; review them for anything that should not leave the machine, since filename screening is not a secret scanner, and have the user gitignore it. Once the workflow is merged and secrets are set, and remote runs are authorized, run the same command with --cloud --dry-run: a real run that replays nothing but receives the secrets, stops on any empty secret, runs the --check command, and resolves the traces. Then, only when a replay is authorized, run with --cloud alone.
 
-Always add --cloud-detach from an agent session, since a replay can run for hours and, once GitHub shows the run, the wait has no local limit (it gives up only when GitHub shows no run within 10 minutes). --cloud-timeout <minutes> (1..7200) stops one replay early and keeps finished traces as an interrupted experiment. The generated job sets no timeout, so GitHub's 6-hour limit for its own runners applies. Explain --cloud-status, --cloud-watch, --cloud-cancel, and --cloud-cleanup with the printed execution UUID; records live under this worktree's Git directory, and a detached run's branch is removed only by a later watch, status, or cleanup. Recover interrupted submissions with --cloud-request-id instead of dispatching again. Report separately whether the workflow is written, secrets configured, workflow merged, snapshot dry run reviewed, cloud dry run passed, and a real replay completed.`,
+From an agent session always add --cloud-detach, since a replay can run for hours, and follow it with --cloud-watch <UUID> (prints the replay's output and exits with its code), --cloud-status, --cloud-cancel, or --cloud-cleanup. --cloud-timeout <minutes> stops one replay early and keeps finished traces. Report separately whether the workflow is written, secrets are set, the workflow is merged, the preview was reviewed, the dry run passed, and a real replay completed.`,
           next: "cleanup/finish"
         }
       ]

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "bitfab-cli",
-  "version": "0.2.413",
+  "version": "0.2.414",
   "description": "Install and configure the Bitfab plugin in Claude Code, Codex, or Cursor, or the Bitfab skill pack in Amp (Alpha).",
   "type": "module",
   "main": "dist/index.js",