bitfab-cli 0.2.431 → 0.2.433

package/dist/index.js

@@ -29231,6 +29231,31 @@ var saveSimPlan = {
     })).min(1).max(500)).describe("Nodes to change (1-500). `name` is the span name; `captureContent` false stops recording that span's inputs and outputs and does the same for every node beneath it, true records them again for that node only.")
   }
 };
+var scenarioTraceIdSchema = external_exports.uuid().describe("ID of the trace the scenario was built from.");
+var getScenario = {
+  name: "get_scenario",
+  title: "Get Scenario",
+  description: "Read the scenario built from one trace: the situation the trace function's run was in, as the trigger that started the run and the data available when it arrived, with a name and a description. It describes the situation only, never what the run did or should do. Returns the trigger and data summaries, then the name, description, trigger, and data as JSON in exactly the shape save_scenario accepts. Call it before save_scenario so an edit starts from what is saved.",
+  inputSchema: {
+    traceId: scenarioTraceIdSchema
+  }
+};
+var saveScenario = {
+  name: "save_scenario",
+  title: "Save Scenario",
+  description: "Update the scenario built from one trace, for example to add history the run had available, record data it was missing, or correct the trigger. name, description, trigger, and data each replace the saved value whole, and fields left out are kept. To add to the data without resending it, use appendData instead of data: its history entries go after the saved ones and its missing items after the saved missing items, in one step that cannot lose another caller's append made at the same time. Send data or appendData, not both. trigger, data, and appendData entries must keep the shape get_scenario returns. A history entry's source names the span on this trace its text came from; set it to null or leave it out when the text is not in the trace, and the entry still counts as data the run had but cannot be cited as evidence when the scenario is turned into assertions. A source naming a span that is not on this trace is refused. The trigger and data summaries are rebuilt from what is saved. It only updates a scenario that already exists; a trace with no scenario is refused. Returns the saved scenario.",
+  inputSchema: {
+    traceId: scenarioTraceIdSchema,
+    name: external_exports.string().min(1).optional().describe("The scenario's name."),
+    description: external_exports.string().min(1).optional().describe("The scenario's description."),
+    trigger: external_exports.preprocess(parseJsonString, external_exports.record(external_exports.string(), external_exports.unknown())).optional().describe("The whole trigger object, in the shape get_scenario returns: what started the run."),
+    data: external_exports.preprocess(parseJsonString, external_exports.record(external_exports.string(), external_exports.unknown())).optional().describe("The whole data object, in the shape get_scenario returns: topic, history (earlier facts in time order, each with its source span), and missing (what the run did not have). Replaces the saved data. Leave it out when sending appendData."),
+    appendData: external_exports.preprocess(parseJsonString, external_exports.object({
+      history: external_exports.array(external_exports.record(external_exports.string(), external_exports.unknown())).optional(),
+      missing: external_exports.array(external_exports.string()).optional()
+    })).optional().describe("Data to add to the saved data: history entries (same shape as data.history, source optional, in time order, after the saved ones) and missing items. At least one of the two must be non-empty. Leave data out when sending this.")
+  }
+};
 var ALL_TOOL_CONTRACTS = [
   getGraderLabels,
   saveGraderLabels,
@@ -29283,7 +29308,9 @@ var ALL_TOOL_CONTRACTS = [
   getTemplate,
   saveTemplate,
   getSimPlan,
-  saveSimPlan
+  saveSimPlan,
+  getScenario,
+  saveScenario
 ];
 var TOOL_NAMES = ALL_TOOL_CONTRACTS.map((contract) => contract.name).sort();
 
@@ -29893,10 +29920,10 @@ var semver3 = __toESM(require_semver2(), 1);
 
 // ../bitfab-plugin-lib/dist/bakedSdkVersions.js
 var BAKED_SDK_VERSIONS = {
-  typescript: "0.64.15",
-  python: "0.64.15",
-  ruby: "0.64.13",
-  go: "0.64.14"
+  typescript: "0.64.17",
+  python: "0.64.17",
+  ruby: "0.64.15",
+  go: "0.64.16"
 };
 
 // ../bitfab-plugin-lib/dist/installedSdk.js
@@ -36661,7 +36688,7 @@ State who can start a replay: once GitHub registers the workflow, anyone with wr
 
 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.
 
-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.
+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. Each replay started with bitfab-replay --cloud normally runs with the Bitfab API key of whoever started it, which the SDK stores through the GitHub CLI as a secret for that replay alone and deletes once the replay starts, so this key is the fallback for runs that cannot pass one, such as a dispatch from another workflow or a machine without the GitHub CLI. Keep the key_id input and the BITFAB_REPLAY_BITFAB_API_KEY line --cloud-init writes. When a workflow already exists, run --cloud-update (the same command as --cloud-init) anyway: it adds whichever of those lines is missing without touching the rest, and lists anything it could not place for you to add 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.
 
 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"

package/package.json

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