bitfab-cli 0.2.464 → 0.2.466
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/index.js +17 -3
- package/package.json +1 -1
package/dist/index.js
CHANGED
|
@@ -29597,16 +29597,27 @@ var scenarioTargetSchema = {
|
|
|
29597
29597
|
traceId: external_exports.uuid().optional().describe("ID of a trace whose scenario to use. Send this or scenarioId, not both."),
|
|
29598
29598
|
scenarioId: external_exports.uuid().optional().describe("ID of the scenario, as get_scenario prints it. Send this or traceId, not both.")
|
|
29599
29599
|
};
|
|
29600
|
+
var listScenarios = {
|
|
29601
|
+
name: "list_scenarios",
|
|
29602
|
+
title: "List Scenarios",
|
|
29603
|
+
description: `List scenarios, newest first, with each one's id, name, trace function, and review status: needs updating (a person flagged the scenario itself as wrong or incomplete, for example missing history or records), updated (the flag was resolved and waits for the person to check the fix), needs label, drafting (assertions are being drafted from the label), drafting failed, no assertions (the draft found nothing checkable), needs review (drafted assertions wait for approval), or done. A scenario that needs updating is printed with its note. Pass queue "needs_updating" to find the scenarios people flagged for fixing, then read each with get_scenario and fix it with save_scenario, sending needsUpdatingResolution to say what you changed. That puts it back in the person's inbox, under needs review, to check. Returns a cursor when more remain.`,
|
|
29604
|
+
inputSchema: {
|
|
29605
|
+
traceFunctionKey: external_exports.string().min(1).optional().describe("Key of the trace function whose scenarios to list. Leave it out to list every trace function's."),
|
|
29606
|
+
queue: external_exports.enum(["inbox", "needs_label", "needs_review", "needs_updating", "done"]).optional().describe("inbox: waiting on a person, everything in needs_label and needs_review. needs_label: needs a label, or its draft failed and the label needs sending again. needs_review: drafting, drafted assertions waiting for approval, a draft that found nothing to check, or a resolved update waiting to be checked. needs_updating: a person flagged the scenario itself with a note. done: every assertion reviewed, or accepted with none. Leave it out to list all."),
|
|
29607
|
+
cursor: external_exports.string().min(1).optional().describe("The cursor a previous call returned, to read the next page."),
|
|
29608
|
+
limit: external_exports.number().int().min(1).max(100).optional().describe("How many scenarios to return, up to 100. Defaults to 25.")
|
|
29609
|
+
}
|
|
29610
|
+
};
|
|
29600
29611
|
var getScenario = {
|
|
29601
29612
|
name: "get_scenario",
|
|
29602
29613
|
title: "Get Scenario",
|
|
29603
|
-
description: "Read one scenario, found by its id or by a trace it was built from: 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. The name, description, trigger, and data describe the situation only, never what the run did or should do. Returns the trigger and data summaries, then the actual outcome when one was saved (what the run actually did: one example, not what it should have done), then the name, description, trigger, data, and actualOutcome as JSON in exactly the shape save_scenario accepts, including the categories it is filed under. data.sources, when saved, says where the records came from and, for each kind of data, whether it was read in full, as of the run or as of capture, with columns the capture predates, or not captured at all. Call it before save_scenario so an edit starts from what is saved.",
|
|
29614
|
+
description: "Read one scenario, found by its id or by a trace it was built from: 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. The name, description, trigger, and data describe the situation only, never what the run did or should do. Returns the review status, the note saying what needs updating when a person flagged the scenario (and the resolution once one was sent), then the trigger and data summaries, then the actual outcome when one was saved (what the run actually did: one example, not what it should have done), then the name, description, trigger, data, and actualOutcome as JSON in exactly the shape save_scenario accepts, including the categories it is filed under. data.sources, when saved, says where the records came from and, for each kind of data, whether it was read in full, as of the run or as of capture, with columns the capture predates, or not captured at all. Call it before save_scenario so an edit starts from what is saved.",
|
|
29604
29615
|
inputSchema: scenarioTargetSchema
|
|
29605
29616
|
};
|
|
29606
29617
|
var saveScenario = {
|
|
29607
29618
|
name: "save_scenario",
|
|
29608
29619
|
title: "Save Scenario",
|
|
29609
|
-
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 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.",
|
|
29620
|
+
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.",
|
|
29610
29621
|
inputSchema: {
|
|
29611
29622
|
...scenarioTargetSchema,
|
|
29612
29623
|
name: external_exports.string().min(1).optional().describe("The scenario's name."),
|
|
@@ -29634,6 +29645,8 @@ var saveScenario = {
|
|
|
29634
29645
|
}).nullable()).optional().describe("What the run actually did. Replaces the saved actual outcome whole. Send null to clear it."),
|
|
29635
29646
|
categoryIds: external_exports.preprocess(parseJsonString, external_exports.array(external_exports.uuid())).optional().describe("Every category this scenario is filed under, from list_categories. Replaces the saved categories whole: send an empty list to remove them all, and leave it out to keep them. An id outside the organization fails the call."),
|
|
29636
29647
|
records: external_exports.preprocess(parseJsonString, external_exports.array(external_exports.record(external_exports.string(), external_exports.unknown()))).optional().describe(`The records related to this run, each { kind, ref, at, asOf, title, text, quote }. kind is one of "message", "contact", "preference", "memory", "email", "calendar_event", "action_item". ref is your own pointer to the row, such as "Input:234605". at is when the record came to exist, or null. asOf is "run" when the record is as it was at the run, or "now" when no history is kept for it. quote is a short exact string to look for in the run's spans, or null to look for the whole text. Prefer recordsPath, so the records never pass through the conversation. Send records or recordsPath, not both.`),
|
|
29648
|
+
needsUpdatingNote: external_exports.string().trim().min(1).optional().describe("Flag the scenario itself as wrong or incomplete, saying what is wrong or missing. Moves it out of review until the note is resolved, and replaces any earlier note and resolution."),
|
|
29649
|
+
needsUpdatingResolution: external_exports.string().trim().min(1).optional().describe("What you changed to resolve the scenario's needs-updating note. Only for a scenario flagged as needing an update; send it with the fix. The scenario goes back to the person's inbox, under needs review, to check the fix."),
|
|
29637
29650
|
recordsPath: external_exports.string().min(1).optional().describe("Path to a local JSON file holding the records, either as an array or as an object with a records array. The Bitfab plugin reads the file and sends its records, so they never pass through the conversation. When the object also has frameAt, capturedAt, windows, and coverage, as Noah's scenario builder writes them, the plugin sends those as sources. Send records or recordsPath, not both."),
|
|
29638
29651
|
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.`)
|
|
29639
29652
|
}
|
|
@@ -29705,6 +29718,7 @@ var ALL_TOOL_CONTRACTS = [
|
|
|
29705
29718
|
saveTemplate,
|
|
29706
29719
|
getSimPlan,
|
|
29707
29720
|
saveSimPlan,
|
|
29721
|
+
listScenarios,
|
|
29708
29722
|
getScenario,
|
|
29709
29723
|
saveScenario,
|
|
29710
29724
|
generateScenarioAssertions
|
|
@@ -30379,7 +30393,7 @@ var semver3 = __toESM(require_semver2(), 1);
|
|
|
30379
30393
|
|
|
30380
30394
|
// ../bitfab-plugin-lib/dist/bakedSdkVersions.js
|
|
30381
30395
|
var BAKED_SDK_VERSIONS = {
|
|
30382
|
-
typescript: "0.65.
|
|
30396
|
+
typescript: "0.65.8",
|
|
30383
30397
|
python: "0.65.5",
|
|
30384
30398
|
ruby: "0.65.5",
|
|
30385
30399
|
go: "0.65.5"
|
package/package.json
CHANGED