bitfab-cli 0.2.469 → 0.2.471

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."),
@@ -29648,6 +29648,15 @@ var saveScenario = {
     sources: external_exports.preprocess(parseJsonString, external_exports.record(external_exports.string(), external_exports.unknown())).optional().describe(`Where the records came from, as { frameAt, capturedAt, windows, coverage }: when the run started, when its data was captured (or null), how many days each windowed kind reaches (such as { "messagesDays": 3, "calendarDays": 7 }), and coverage, which gives each kind of data its capture status ("rewound-to-frame" for as of the run, "current-at-capture" for as of capture, "not-recorded" or "unavailable" for not captured) plus filledColumns { absentNullable, defaultedNonNullable }, the "table.column" names the capture predates. Only with records, never with recordsPath, which sends the file's own.`)
   }
 };
+var saveTraceCategories = {
+  name: "save_trace_categories",
+  title: "Save Trace Categories",
+  description: "File one trace under categories, replacing its whole set. Send categoryIds with every category the trace belongs to; an empty list clears them. Categories are held by the trace's scenario, so every trace linked to that scenario shows the same categories. A trace with no scenario yet gets a dummy one, which has no trigger or data until save_scenario generates it and keeps its categories when it does. Category ids come from save_category or list_categories, and an id not in this organization is refused. Returns the trace's categories after the save and the scenario that holds them.",
+  inputSchema: {
+    traceId: external_exports.uuid().describe("The trace to file."),
+    categoryIds: external_exports.preprocess(parseJsonString, external_exports.array(external_exports.uuid()).max(100)).describe("Every category the trace belongs to, replacing its saved set. An empty list clears it.")
+  }
+};
 var generateScenarioAssertions = {
   name: "generate_scenario_assertions",
   title: "Generate Scenario Assertions",
@@ -29718,6 +29727,7 @@ var ALL_TOOL_CONTRACTS = [
   listScenarios,
   getScenario,
   saveScenario,
+  saveTraceCategories,
   generateScenarioAssertions
 ];
 var TOOL_NAMES = ALL_TOOL_CONTRACTS.map((contract) => contract.name).sort();

package/package.json

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