bitfab-cli 0.2.386 → 0.2.387

package/dist/index.js

@@ -24962,10 +24962,10 @@ var semver3 = __toESM(require_semver2(), 1);
 
 // ../bitfab-plugin-lib/dist/bakedSdkVersions.js
 var BAKED_SDK_VERSIONS = {
-  typescript: "0.60.1",
-  python: "0.60.2",
-  ruby: "0.60.1",
-  go: "0.60.1"
+  typescript: "0.61.0",
+  python: "0.61.0",
+  ruby: "0.61.0",
+  go: "0.61.0"
 };
 
 // ../bitfab-plugin-lib/dist/installedSdk.js
@@ -31449,10 +31449,10 @@ var setupFlow = Flow.parse({
   id: "setup",
   title: "Bitfab Setup",
   frontmatter: {
-    description: "Set up and maintain Bitfab tracing for AI features. TRIGGER when: user wants to set up Bitfab, instrument code, add tracing/observability for LLM or agent calls, observe AI calls, add evaluation, trace LLM functions, trace a new workflow, change what an existing trace captures, re-instrument an existing traced function (move a database read or other side effect in or out of a span, change what a span records as its input/output), inspect or debug their tracing setup (what's instrumented, why traces aren't showing up), or understand what Bitfab is; or says anything like 'instrument', 'add tracing', 'trace my code', 'set up observability', 'hook up Bitfab', 'start tracking my AI workflow', 'trace a new workflow', 'update my tracing setup', 're-instrument', 're-instrument <function>', 'move the database read out of the span', 'make this trace replayable without a database', 'change what this span records as input', 'why aren't my traces showing up', 'what is Bitfab', 'set up database snapshots', 'replay against my database state at trace time', 'analyze the repo for what to instrument', 'analyze-repo', 'instrument the second/next/other one', 'instrument another function'. This trigger applies even mid-conversation and after setup already ran: every additional function to instrument must re-enter this skill. SKIP when: user is (a) improving the QUALITY of a traced function's outputs, fixing failures, pass rates, labeling, running experiments (use bitfab:assistant); or (b) upgrading the plugin/SDK to a newer *version* (use bitfab:update)",
+    description: "Set up and maintain Bitfab tracing, replay registries, and cloud replay. Use for instrumenting AI/LLM code, adding observability or evaluation, tracing another workflow, changing captured inputs/outputs, re-instrumenting a function, moving side effects across trace boundaries, inspecting missing traces, explaining Bitfab, login, organization switching, session-log consent, database snapshots, templates, or read-only repo instrumentation recommendations (analyze-repo). Also use for 'setup cloud', 'set up cloud replay', or 'replay on GitHub'. Re-enter this skill for each additional function to instrument, even after earlier setup. Do not use for improving output quality, pass rates, labeling, or experiments (use bitfab:assistant), or upgrading SDK/plugin versions (use bitfab:update)",
     argumentHint: {
       deriveFromModes: true,
-      suffix: "[<what to do>]"
+      suffix: "[what to do]"
     }
   },
   commands: BITFAB_PLUGIN_COMMANDS.defineCommands({
@@ -31520,9 +31520,9 @@ var setupFlow = Flow.parse({
 - Keep prose between tool calls to one line or none. Save fuller explanation for decision points and the workflow summaries the user acts on.
 - Surfacing a risk, ambiguity, or unexpected finding is never the narration to suppress: raise it immediately, even mid-probe (e.g. unserializable inputs, a shim with lazy init, an ambiguous project root).
 
-This skill has eleven phases: **explain**, **login**, **session-logs**, **instrument**, **modify**, **inspect**, **switch-org**, **replay**, **db-snapshot**, **templates**, and **analyze-repo**. Run individually or through setup (\`wizard\` runs login \u2192 instrument; \`explain\` is a standalone read-only overview that requires no login; \`session-logs\` is standalone and does not require login; \`modify\` is only invoked explicitly or as a branch from Instrument's existing-SDK-usage menu; \`inspect\` is a standalone diagnostic (with optional one-shot fixes) invoked explicitly; \`switch-org\` is a standalone account action (requires auth) invoked explicitly; \`db-snapshot\` is only invoked explicitly; \`templates\` is only invoked explicitly; \`analyze-repo\` is a standalone, **non-interactive** batch action (requires auth) invoked explicitly: it scans, picks the top few candidates, and reports source locations and replay dependencies, asking nothing and editing no code).
+This skill has twelve phases: **explain**, **login**, **session-logs**, **instrument**, **modify**, **inspect**, **switch-org**, **replay**, **db-snapshot**, **templates**, **analyze-repo**, and **cloud**. The \`cloud\` mode configures direct GitHub Actions replay without Bitfab login or a repository connection. Run individually or through setup (\`wizard\` runs login \u2192 instrument; \`explain\` is a standalone read-only overview that requires no login; \`session-logs\` is standalone and does not require login; \`modify\` is only invoked explicitly or as a branch from Instrument's existing-SDK-usage menu; \`inspect\` is a standalone diagnostic (with optional one-shot fixes) invoked explicitly; \`switch-org\` is a standalone account action (requires auth) invoked explicitly; \`db-snapshot\` is only invoked explicitly; \`templates\` is only invoked explicitly; \`analyze-repo\` is a standalone, **non-interactive** batch action (requires auth) invoked explicitly: it scans, picks the top few candidates, and reports source locations and replay dependencies, asking nothing and editing no code).
 
-**Natural-language aliases:** "explain Bitfab" \u2192 \`explain\`; "trace a new workflow" / "instrument another function" \u2192 \`instrument\`; "adjust what is captured" / "re-instrument" \u2192 \`modify\`; "why are my traces missing" \u2192 \`inspect\`; "switch org" \u2192 \`switch-org\`; "set up database snapshots" \u2192 \`db-snapshot\`; "analyze the repo" \u2192 \`analyze-repo\` (read-only source recommendations).
+**Natural-language aliases:** "set up cloud replay" / "replay on GitHub" \u2192 \`cloud\`; "explain Bitfab" \u2192 \`explain\`; "trace a new workflow" / "instrument another function" \u2192 \`instrument\`; "adjust what is captured" / "re-instrument" \u2192 \`modify\`; "why are my traces missing" \u2192 \`inspect\`; "switch org" \u2192 \`switch-org\`; "set up database snapshots" \u2192 \`db-snapshot\`; "analyze the repo" \u2192 \`analyze-repo\` (read-only source recommendations).
 
 When instrumenting a workflow, **its instrumentation and replay pipeline are written together in the same cycle** after the workflow is selected (see Instrument's write-instrumentation step). The standalone \`replay\` mode remains available for coverage-verification and backfill.
 
@@ -31555,6 +31555,7 @@ If the block prints \`ERROR: Bitfab plugin not installed\`, the user hasn't inst
     inspect: "inspect/status-check",
     "switch-org": "switch-org/status-check",
     replay: "replay/gather-keys",
+    cloud: "cloud/inspect",
     "db-snapshot": "db-snapshot/preflight",
     templates: "templates/pick-function",
     "analyze-repo": "analyze-repo/preflight"
@@ -31570,6 +31571,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: "Set up replay in your own GitHub Actions using local gh authentication. No Bitfab repository connection 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."
@@ -31622,6 +31624,50 @@ Never modify existing code on a refactor path without completing this three-step
     }
   ],
   phases: [
+    {
+      id: "cloud",
+      title: "Cloud replay",
+      stepStyle: "list",
+      intro: "Run replay in the customer's GitHub Actions. Use this standalone mode for 'setup cloud', 'set up cloud replay', or 'replay on GitHub'. Do not enter login or connect a repository to Bitfab. Normal replay still uses a Bitfab API key on the runner.",
+      steps: [
+        {
+          id: "inspect",
+          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. 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 pipeline and reproduce its runtime, dependency installation, build steps, working directory, caches, and required services from CI. Use the installed SDK's cloud-capable CLI. TypeScript/Python/Ruby registry imports happen on the runner only. Go must dispatch cloud flags before building its registry or initializing the application. 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. 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"
+        },
+        {
+          id: "install",
+          kind: "action",
+          title: "Install the repository-owned runner",
+          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, command (a JSON argv array without the pipeline argument or cloud flags), pushTriggersReviewed: true, setupSteps (GitHub Actions step objects), secrets (names including BITFAB_API_KEY), and variables (names only). 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.
+
+Run python3 "{{pluginRoot}}/scripts/cloudReplay.py" init --config <specification-path>. This creates .bitfab/cloud.json, .bitfab/cloudReplay.py, 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 these two files. 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 their intended Bitfab organization. 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.`,
+          next: "cloud/verify"
+        },
+        {
+          id: "verify",
+          kind: "action",
+          title: "Verify and hand off",
+          toolCalls: ["bash", "read", "ask"],
+          body: `Validate workflow syntax (actionlint when available) and run the installed SDK CLI with --cloud --help. The workflow must land on the default branch once before workflow_dispatch can run it on temporary branches. Explain the required commit/merge. Do not push, merge, change repository permissions, or set secrets without authorization.
+
+After the setup files are tracked, 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.`,
+          next: "cleanup/finish"
+        }
+      ]
+    },
     {
       id: "login",
       title: "Login",
@@ -31718,6 +31764,7 @@ Save the answer (replace \`CONSENT\` with \`true\` or \`false\`):
               inspect: "cleanup/finish",
               "switch-org": "cleanup/finish",
               replay: "cleanup/finish",
+              cloud: "cleanup/finish",
               "db-snapshot": "cleanup/finish",
               templates: "cleanup/finish",
               "analyze-repo": "cleanup/finish"
@@ -31786,6 +31833,7 @@ then close with one line: to start tracing, run \`{{cmd}}setup\`; to debug an ex
           next: {
             byMode: {
               wizard: "approach/choose-driver",
+              cloud: "cleanup/finish",
               explain: "cleanup/finish",
               login: "cleanup/finish",
               "session-logs": "cleanup/finish",
@@ -31985,6 +32033,7 @@ Confirm the change to the user.`,
                   inspect: "cleanup/finish",
                   "switch-org": "cleanup/finish",
                   replay: "cleanup/finish",
+                  cloud: "cleanup/finish",
                   "db-snapshot": "cleanup/finish",
                   templates: "cleanup/finish",
                   "analyze-repo": "cleanup/finish"

package/package.json

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