bitfab-cli 0.2.502 → 0.2.504
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 +6 -6
- package/package.json +1 -1
package/dist/index.js
CHANGED
|
@@ -29634,7 +29634,7 @@ var listScenarios = {
|
|
|
29634
29634
|
var getScenario = {
|
|
29635
29635
|
name: "get_scenario",
|
|
29636
29636
|
title: "Get Scenario",
|
|
29637
|
-
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. When the organization has a scenario callback, it also says how the callback last went for this scenario and when: waiting to run, filled the scenario, answered with nothing to add, accepted the request to fill it later, skipped, or failed, with the reason for a skip or failure. A scenario not generated yet has no trigger or data of its own: it is returned with its review status, its categories, and the assertions on the trace it was made from, whose input and output stand in for its trigger and data. 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.",
|
|
29637
|
+
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 creation status (empty until something starts building it, generating while Bitfab builds it or waits for the scenario callback to save it, created once built, or error with the reason), 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. When the organization has a scenario callback, it also says how the callback last went for this scenario and when: waiting to run, filled the scenario, answered with nothing to add, accepted the request to fill it later, skipped, or failed, with the reason for a skip or failure. A scenario not generated yet has no trigger or data of its own: it is returned with its review status, its categories, and the assertions on the trace it was made from, whose input and output stand in for its trigger and data. 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.",
|
|
29638
29638
|
inputSchema: scenarioTargetSchema
|
|
29639
29639
|
};
|
|
29640
29640
|
var saveScenario = {
|
|
@@ -29686,7 +29686,7 @@ var saveTraceCategories = {
|
|
|
29686
29686
|
var generateScenario = {
|
|
29687
29687
|
name: "generate_scenario",
|
|
29688
29688
|
title: "Generate Scenario",
|
|
29689
|
-
description: "Start building the scenario for one trace and return at once, without waiting for it. The scenario
|
|
29689
|
+
description: "Start building the scenario for one trace and return at once, without waiting for it. The scenario's creation status becomes generating, and the answer names the scenario and its creation status. Read it later with get_scenario, which shows the creation status until the scenario is created or building it failed. Asking again while it is generating starts nothing more, and asking for one whose build failed starts it over. Bitfab builds the trigger itself for a noah-agent-turn trace, and the organization's scenario callback, when one is set up, fills in the rest for any trace. A trace that already has a scenario is left as it is and answers with that scenario's id. A replay, a trace outside this organization, or a trace Bitfab cannot build a scenario for (not noah-agent-turn and no scenario callback) is refused. Adding traces to a dataset links each one to an empty scenario, and starts this same build for each only when the organization has a scenario callback.",
|
|
29690
29690
|
inputSchema: {
|
|
29691
29691
|
traceId: external_exports.uuid().describe("The trace to build a scenario for.")
|
|
29692
29692
|
}
|
|
@@ -31133,10 +31133,10 @@ var semver2 = __toESM(require_semver2(), 1);
|
|
|
31133
31133
|
|
|
31134
31134
|
// ../bitfab-plugin-lib/dist/bakedSdkVersions.js
|
|
31135
31135
|
var BAKED_SDK_VERSIONS = {
|
|
31136
|
-
typescript: "0.
|
|
31137
|
-
python: "0.
|
|
31138
|
-
ruby: "0.
|
|
31139
|
-
go: "0.
|
|
31136
|
+
typescript: "0.74.1",
|
|
31137
|
+
python: "0.74.0",
|
|
31138
|
+
ruby: "0.73.0",
|
|
31139
|
+
go: "0.72.0"
|
|
31140
31140
|
};
|
|
31141
31141
|
|
|
31142
31142
|
// ../bitfab-plugin-lib/dist/installedSdk.js
|
package/package.json
CHANGED