bitfab-cli 0.2.402 → 0.2.404

package/dist/index.js

@@ -24697,10 +24697,10 @@ var semver3 = __toESM(require_semver2(), 1);
 
 // ../bitfab-plugin-lib/dist/bakedSdkVersions.js
 var BAKED_SDK_VERSIONS = {
-  typescript: "0.62.4",
-  python: "0.62.3",
-  ruby: "0.62.3",
-  go: "0.62.3"
+  typescript: "0.62.6",
+  python: "0.62.5",
+  ruby: "0.62.5",
+  go: "0.62.5"
 };
 
 // ../bitfab-plugin-lib/dist/installedSdk.js
@@ -31401,9 +31401,9 @@ 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: `Read the existing GitHub Actions, runtime manifests, lockfiles, replay registry, gitignore, and environment-variable NAMES. Never read or print secret values. Check git origin, Python 3.10+, and gh authentication. Local dispatch supports macOS/Linux and github.com. Inspect all push-triggered workflows and deployment integrations. Temporary branches use bitfab-replay/** and can trigger those systems. Offer the usual fixes: a push workflow can add bitfab-replay/** to branches-ignore, 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. Do not set pushTriggersReviewed until these triggers have been reviewed with the user.
+          body: `Read the existing GitHub Actions, runtime manifests, lockfiles, replay registry, gitignore, and environment-variable NAMES. Never read or print secret values. Check git origin, Python 3.10+, and gh authentication. Local dispatch supports macOS/Linux and github.com. Inspect all push-triggered workflows and deployment integrations. Temporary branches use bitfab-replay/** and can trigger those systems. 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. Do not set pushTriggersReviewed until these triggers have been reviewed with the user.
 
-Choose one existing replay registry and reproduce its runtime, dependency installation, build steps, working directory, caches, and required services from CI. Cover what every pipeline in that registry needs, since cloud replay allows all of them by default. Use the installed SDK's cloud-capable CLI: run its bitfab-replay --cloud --help now. If it does not list --cloud-init, the project's SDK predates this setup, so upgrade it through bitfab:update before continuing. The code that submits, watches, and runs cloud replays ships inside the SDK and updates with it; the repository keeps only settings, .bitfab/cloud.json and the workflow. An older setup also left .bitfab/cloudReplay.py in the repository. The SDK no longer reads that file, so offer to migrate: change the workflow's Replay step to run the SDK command with --cloud-execute (next step), then delete .bitfab/cloudReplay.py. TypeScript/Python/Ruby registry imports happen on the runner only. Go must dispatch cloud flags before building its registry or initializing the application. 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), falling back to its normal URL. A pool or engine created once at import from DATABASE_URL never sees the branch, and the SDK does not change DATABASE_URL, so check how the application builds its database client. When either piece is missing, offer to run db-snapshot mode first. Without branching, a private database needs runner network access or a replay-safe service fixture. Do not silently give replay production side effects. Submodules/gitlinks and credential-like tracked files are rejected by the snapshot helper. A gitlink with no .gitmodules entry is usually a nested repository committed by accident: offer to untrack it with git rm --cached and ignore its folder. Surface blockers instead of claiming the environment is ready.
+Choose one existing replay registry and reproduce its runtime, dependency installation, build steps, working directory, caches, and required services from CI. Cover what every pipeline in that registry needs, since cloud replay allows all of them by default. Use the installed SDK's cloud-capable CLI: run its bitfab-replay --cloud --help now. If it does not list --cloud-init, the project's SDK predates this setup, so upgrade it through bitfab:update before continuing. The code that submits, watches, and runs cloud replays ships inside the SDK and updates with it; the repository keeps only settings: .bitfab/cloud.json and a workflow whose Replay step runs the SDK's bitfab-replay command with --cloud-execute. The runner reports its result as a job annotation, so the workflow needs no upload step. When the repository already has an older generated workflow (a Save replay identity upload step, a job timeout-minutes of 35, or a Replay step that runs .bitfab/cloudReplay.py), offer to update it: from workingDirectory run the SDK's bitfab-replay command with --cloud-init. On an existing setup it rewrites the Replay step to run the SDK command and removes two things older setups generated that the SDK now owns: the separate Save replay identity upload step and a job timeout-minutes of exactly 35. It keeps the checkout, other setup steps, secrets, runner, environment, services, and any timeout the user chose, and does nothing when the setup is already current. When the old step ran .bitfab/cloudReplay.py rather than the SDK, pass --config with a JSON file holding just cliCommand, the argv that starts bitfab-replay from workingDirectory. Delete any file the result lists as removable. Show the diff, and treat merging it like any other workflow change. TypeScript/Python/Ruby registry imports happen on the runner only. Go must dispatch cloud flags before building its registry or initializing the application. 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), falling back to its normal URL. A pool or engine created once at import from DATABASE_URL never sees the branch, and the SDK does not change DATABASE_URL, so check how the application builds its database client. When either piece is missing, offer to run db-snapshot mode first. Without branching, a private database needs runner network access or a replay-safe service fixture. Do not silently give replay production side effects. Submodules/gitlinks and credential-like tracked files are rejected by the snapshot helper. A gitlink with no .gitmodules entry is usually a nested repository committed by accident: offer to untrack it with git rm --cached and ignore its folder. Surface blockers instead of claiming the environment is ready.
 
 Present the proposed workflow, fixed replay command, required secret/variable names, and any required CI trigger exclusions. Ask only about unresolved project choices. Never ask for secret values in chat.`,
           next: "cloud/install"
@@ -31413,9 +31413,9 @@ Present the proposed workflow, fixed replay command, required secret/variable na
           kind: "action",
           title: "Install the cloud replay settings",
           toolCalls: ["bash", "read", "write", "edit"],
-          body: `Create a reviewed JSON setup specification containing version: 1, provider: "github", workflow: "bitfab-replay.yml", workingDirectory (repository-relative), registry (repository-relative path or null for Go), pipeline (null allows every pipeline in the registry and is the default; a name restricts replay to that one pipeline, for when the others need credentials or services the runner should not have), command (a JSON argv array without the pipeline argument or cloud flags), cliCommand (the JSON argv array that starts the SDK's bitfab-replay command from workingDirectory, with no flags, such as ["npx", "--no-install", "bitfab-replay"] or ["node", "node_modules/@bitfab/sdk/dist/replayCli.js"]; the Replay step runs it with --cloud-execute), pushTriggersReviewed: true, setupSteps (GitHub Actions step objects), secrets (names including BITFAB_API_KEY), and variables (names only). The runner always provides BITFAB_API_KEY. Find the variable the registry's Bitfab client actually reads its key from, and when it is another name, map it in the command, for example ["sh", "-c", "APP_KEY_NAME=\\"$BITFAB_API_KEY\\" exec <command> \\"$@\\"", "sh"]. Optional secretPrefix (uppercase, ending in an underscore) names the GitHub secret each one is read from without changing the environment variable the replay sees; it defaults to BITFAB_CLOUD_, and only an explicit empty string turns prefixing off. Optional runsOn, services, and environment match the existing CI. Prefer a GitHub Environment with required reviewers when replay code receives sensitive credentials. Pin third-party actions to reviewed commit SHAs. Ensure Python 3.10+ exists on the runner. Commands run in workingDirectory. Registry in the command must be relative to that directory. Set step working-directory explicitly where needed. Do not copy deployment steps, local env values, or API keys into the specification.
+          body: `Create a reviewed JSON setup specification containing version: 1, provider: "github", workflow: "bitfab-replay.yml", workingDirectory (repository-relative), registry (repository-relative path or null for Go), pipeline (null allows every pipeline in the registry and is the default; a name restricts replay to that one pipeline, for when the others need credentials or services the runner should not have), command (the JSON argv array the runner uses to run the replay itself: the project's normal bitfab-replay invocation including --registry when the registry needs it, without the pipeline argument or any cloud flags; the runner appends the pipeline, --trace-ids, and --max-concurrency), cliCommand (the JSON argv array that starts the SDK's bitfab-replay command from workingDirectory, with no flags, such as ["npx", "--no-install", "bitfab-replay"] or ["node", "node_modules/@bitfab/sdk/dist/replayCli.js"]; the generated Replay step runs it with --cloud-execute), pushTriggersReviewed: true, setupSteps (GitHub Actions step objects), secrets (names including BITFAB_API_KEY), and variables (names only). The runner always provides BITFAB_API_KEY. Find the variable the registry's Bitfab client actually reads its key from, and when it is another name, map it in the command, for example ["sh", "-c", "APP_KEY_NAME=\\"$BITFAB_API_KEY\\" exec <command> \\"$@\\"", "sh"]. Optional secretPrefix (uppercase, ending in an underscore) names the GitHub secret each one is read from without changing the environment variable the replay sees; it defaults to BITFAB_CLOUD_, and only an explicit empty string turns prefixing off. Optional runsOn, services, and environment match the existing CI. Prefer a GitHub Environment with required reviewers when replay code receives sensitive credentials. Pin third-party actions to reviewed commit SHAs. Ensure Python 3.10+ exists on the runner. Commands run in workingDirectory. Registry in the command must be relative to that directory. Set step working-directory explicitly where needed. Do not copy deployment steps, local env values, or API keys into the specification.
 
-From workingDirectory, run the SDK's bitfab-replay command with --cloud-init --config <specification-path>. This creates .bitfab/cloud.json and .github/workflows/bitfab-replay.yml. The generated workflow is JSON, which is valid YAML. Existing files are never overwritten. For an existing setup, review the diff and edit project configuration deliberately. Remove only your temporary specification after successful installation. If .bitfab is ignored, propose a narrow gitignore exception for .bitfab/cloud.json. Never force-add secrets or arbitrary ignored files.
+From workingDirectory, run the SDK's bitfab-replay command with --cloud-init --config <specification-path>. This creates .bitfab/cloud.json and .github/workflows/bitfab-replay.yml. The generated workflow is JSON, which is valid YAML. Its run-name and its execution_id and request inputs are how the SDK finds and feeds each run; never rename them. Running --cloud-init again is safe: on an existing setup it ignores the rest of the specification and only brings the Replay step up to date as described above, so change other settings by editing the files and reviewing the diff. Remove only your temporary specification after successful installation. If .bitfab is ignored, propose a narrow gitignore exception for .bitfab/cloud.json. Never force-add secrets or arbitrary ignored files.
 
 Tell the user which repository or Environment secrets to create in GitHub Settings \u2192 Secrets and variables \u2192 Actions. BITFAB_API_KEY belongs to the Bitfab organization that holds the registry's traces; confirm that with the user, because a key from another organization finds none of them. Other names come from their application, such as OPENAI_API_KEY. BITFAB_SERVICE_URL is optional. Do not override the SDK's default with an empty GitHub variable. Runtime secrets belong on the replay step. Any install-time credentials need explicit references on the relevant setup step. Local gh authentication is separate from these runner secrets. Do not create a Bitfab cloud target, install a GitHub App, or request a repository connection.
 
@@ -31433,7 +31433,7 @@ When the project keeps local environment files, list the NAMES each required sec
 
 After the setup files are tracked (until then, pass each one with --cloud-include; the helper names any that are missing), run bitfab-replay --cloud <pipeline> --trace-ids <real-trace-uuid> --cloud-dry-run using the selected SDK command. It reports changed tracked files and omitted new files. Include new source files explicitly with repeated --cloud-include <repository-relative-file>. Review the entire snapshot for credentials. Filename screening is not a secret scanner. Then, only when remote replay is authorized, run without --cloud-dry-run. The helper creates a commit through an isolated index, pushes bitfab-replay/<UUID>, dispatches that branch, waits, retrieves the test-run identity, and deletes the branch with an exact-SHA lease. HEAD, staged changes, and working files stay untouched. Never reset or undo the user's work.
 
-Use --cloud-detach to return immediately. Explain --cloud-status, --cloud-watch, --cloud-cancel, and --cloud-cleanup with the printed execution UUID. Records live under this worktree's Git directory. Interrupted/lost-response submissions must be recovered, not blindly dispatched again. Cancel requests do not imply the job stopped. Watch/status confirms completion before deleting the branch. Detached jobs do not automatically clean themselves without a later local lifecycle command. Report separately whether files are generated, secrets configured, workflow merged, dry-run verified, and an actual remote replay completed. Never call a mock smoke run a real replay.`,
+Use --cloud-detach to return immediately; always 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 for a dispatch within 10 minutes). Pass --cloud-timeout <minutes> (1..7200) to stop one replay early: the runner stops it cleanly and finished traces stay saved as an interrupted experiment. The generated job sets no timeout, so GitHub's 6-hour limit for its own runners applies; longer replays need a self-hosted runner with timeout-minutes set on the job. Explain --cloud-status, --cloud-watch, --cloud-cancel, and --cloud-cleanup with the printed execution UUID. Records live under this worktree's Git directory. Interrupted/lost-response submissions must be recovered, not blindly dispatched again. Cancel requests do not imply the job stopped. Watch/status confirms completion before deleting the branch. Detached jobs do not automatically clean themselves without a later local lifecycle command. Report separately whether files are generated, secrets configured, workflow merged, dry-run verified, and an actual remote replay completed. Never call a mock smoke run a real replay.`,
           next: "cleanup/finish"
         }
       ]

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "bitfab-cli",
-  "version": "0.2.402",
+  "version": "0.2.404",
   "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",