bitfab-cli 0.2.470 → 0.2.472

package/dist/index.js

@@ -29614,7 +29614,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. Create the scenario first by sending traceId with records as an empty list: Bitfab builds only the trigger from the trace (so far only for traces of Noah's noah-agent-turn function; any other trace with no scenario is refused), and the data starts empty, with no records. The data holds only what you send afterwards: the trace shows what happened in the run, not all the data your system held when it ran. 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 record what the run actually did, send actualOutcome, read from the trace: its final output for the summary and the tool calls that ran for the actions. It is shown below the trigger as one example of how the run handled the situation, never as what it should have done, and it is not evidence for assertions. Bitfab does not fill it. Send null to clear it. To say the scenario itself needs fixing, send needsUpdatingNote with what is wrong. Once a scenario flagged that way is fixed, send needsUpdatingResolution saying what you changed, in the same call as the fix: the note and the resolution are kept, and the scenario goes back to the person's inbox, under needs review, to check the fix. To file the scenario under categories, send categoryIds with every category it belongs to; a scenario can be in any number. 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 only the trigger from the trace (so far only for traces of Noah's noah-agent-turn function), and the data starts empty, with no records. For a trace of any other function, create the scenario by sending traceId with trigger, data, or both, in the shape get_scenario returns; the part not sent starts empty and can be sent later. A scenario that holds only categories is filled in the same way. The data holds only what you send afterwards: the trace shows what happened in the run, not all the data your system held when it ran. 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 record what the run actually did, send actualOutcome, read from the trace: its final output for the summary and the tool calls that ran for the actions. It is shown below the trigger as one example of how the run handled the situation, never as what it should have done, and it is not evidence for assertions. Bitfab does not fill it. Send null to clear it. To say the scenario itself needs fixing, send needsUpdatingNote with what is wrong. Once a scenario flagged that way is fixed, send needsUpdatingResolution saying what you changed, in the same call as the fix: the note and the resolution are kept, and the scenario goes back to the person's inbox, under needs review, to check the fix. To file the scenario under categories, send categoryIds with every category it belongs to; a scenario can be in any number. 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. Any other 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."),
@@ -31098,7 +31098,7 @@ var semver2 = __toESM(require_semver2(), 1);
 
 // ../bitfab-plugin-lib/dist/bakedSdkVersions.js
 var BAKED_SDK_VERSIONS = {
-  typescript: "0.65.10",
+  typescript: "0.65.11",
   python: "0.65.7",
   ruby: "0.65.7",
   go: "0.65.7"

package/package.json

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