bitfab-cli 0.2.444 → 0.2.446

package/dist/index.js

@@ -29257,7 +29257,7 @@ var getScenario = {
 var saveScenario = {
   name: "save_scenario",
   title: "Save Scenario",
-  description: "Create or update one scenario. To create a scenario, or to replace its records, send traceId with records or recordsPath: the records your own system holds that relate to that trace's run, as of the run. Bitfab builds the trigger and data from the trace when the trace has no scenario yet (so far only for traces of Noah's noah-agent-turn function; any other trace with no scenario is refused), then looks for each record's quote, and failing that its text, in the inputs and outputs of the trace's spans. A record found in a span cites that span and can back an assertion; a record found in no span is kept as context the run never saw. A trace that is a replay is refused, because a scenario belongs on the original. Send sources beside records to say where the records came from and how much of each kind of data was read; recordsPath forwards the file's sources on its own. records and recordsPath replace the saved records and sources whole (records with no sources clear the saved sources), need traceId rather than scenarioId, and cannot be sent with any field other than sources. To edit a scenario that already exists, find it by its id or by a trace it was built from and send name, description, trigger, data, or appendData, 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 its text came from, on any trace linked to the scenario (a trace that finds it by traceId is one); set it to null or leave it out when the text is not in such a 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 on any other trace is refused. The trigger and data summaries are rebuilt from what is saved. An edit to a trace with no scenario, or to a scenario id that does not exist, is refused. Returns the saved scenario.",
+  description: "Create or update one scenario. To create a scenario, or to replace its records, send traceId with records or recordsPath: the records your own system holds that relate to that trace's run, as of the run. Create the scenario first by sending traceId with records as an empty list: Bitfab builds the trigger and data from the trace (so far only for traces of Noah's noah-agent-turn function; any other trace with no scenario is refused) and saves no records. Check that the returned trigger is not empty before sending records. Records that are not empty are refused for a trace with no scenario yet, and for a scenario whose trigger is empty. Bitfab looks for each record's quote, and failing that its text, in the inputs and outputs of the trace's spans. A record found in a span cites that span and can back an assertion; a record found in no span is kept as context the run never saw. A trace that is a replay is refused, because a scenario belongs on the original. Send sources beside records to say where the records came from and how much of each kind of data was read; recordsPath forwards the file's sources on its own. records and recordsPath replace the saved records and sources whole (records with no sources clear the saved sources), need traceId rather than scenarioId, and cannot be sent with any field other than sources. To edit a scenario that already exists, find it by its id or by a trace it was built from and send name, description, trigger, data, or appendData, 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 its text came from, on any trace linked to the scenario (a trace that finds it by traceId is one); set it to null or leave it out when the text is not in such a 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 on any other trace is refused. The trigger and data summaries are rebuilt from what is saved. An edit to a trace with no scenario, or to a scenario id that does not exist, is refused. Returns the saved scenario.",
   inputSchema: {
     ...scenarioTargetSchema,
     name: external_exports.string().min(1).optional().describe("The scenario's name."),
@@ -30010,10 +30010,10 @@ var semver3 = __toESM(require_semver2(), 1);
 
 // ../bitfab-plugin-lib/dist/bakedSdkVersions.js
 var BAKED_SDK_VERSIONS = {
-  typescript: "0.64.22",
-  python: "0.64.20",
-  ruby: "0.64.18",
-  go: "0.64.19"
+  typescript: "0.64.23",
+  python: "0.64.21",
+  ruby: "0.64.19",
+  go: "0.64.20"
 };
 
 // ../bitfab-plugin-lib/dist/installedSdk.js
@@ -36782,7 +36782,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. 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.
+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 runs as whoever started it, through a one-time token in the key_id input that only a run of that workflow, on that replay's branch, in that repository can trade for a short-lived key, which it proves with GitHub's OIDC token for the run. This secret is the key a run falls back to when no token can be passed, such as a dispatch from another workflow. Keep the key_id input and the id-token: write permission --cloud-init writes. When a workflow already exists, run --cloud-update (the same command as --cloud-init) anyway: it adds a missing key_id input and id-token: write permission, removes the BITFAB_REPLAY_BITFAB_API_KEY line older SDKs wrote (it made GitHub hand the runner every secret in the repository), leaves the rest alone, and lists anything it could not place for you to add by hand. Its result also lists in oldKeySecrets any BITFAB_REPLAY_KEY_* secrets an older SDK left in the repository, each a copy of the Bitfab API key of whoever started that replay. Name them to the user and ask once whether to delete them; on yes, run --cloud-update --remove-old-key-secrets, which returns removedOldKeySecrets and lists any it could not delete with the page to delete them on. 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.444",
+  "version": "0.2.446",
   "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",