bitfab-cli 0.2.418 → 0.2.420
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 +22 -8
- package/package.json +1 -1
package/dist/index.js
CHANGED
|
@@ -28875,7 +28875,7 @@ var deleteAssertionCategory = {
|
|
|
28875
28875
|
var generateTraceAssertions = {
|
|
28876
28876
|
name: "generate_trace_assertions",
|
|
28877
28877
|
title: "Generate Trace Assertions",
|
|
28878
|
-
description:
|
|
28878
|
+
description: 'Generate review-ready assertion drafts from what one original trace actually did. Call this when the user asks Bitfab to generate assertions, infer expected behavior from a trace, or turn a known root cause into regression checks. Bitfab reads the organization\'s existing assertion categories, selects the categories supported by trace evidence, and generates assertions one category at a time. The generated assertions are saved awaiting human review, so they are not checked on replays until a person approves them. Read them back with get_trace_assertions and `approvalStates: ["pending"]`. Generation runs on Bitfab and this call waits up to four minutes for it. If it is still running after that, the result says so, and calling again with the same traceId and without regenerate checks on it. A trace has one generation at a time, so a repeat call joins the running or finished generation instead of spending model calls again, and regenerate while one is running joins that one too. Set regenerate to true after it finishes to archive the prior generated drafts and replace them. A failed generation is returned as an error with its reason. Human-authored assertions are never replaced. Pass guidance when the user knows what the assertions should be about, most often a root cause analysis of why the trace was wrong; it narrows the evidence and produces smaller assertions. Pass categoryIds to limit generation to those assertion categories. A replay trace id is refused because assertions belong to the original trace.',
|
|
28879
28879
|
inputSchema: {
|
|
28880
28880
|
traceId: external_exports.uuid().describe("The ORIGINAL trace to generate assertions for. A replay trace id is refused, and the error names the original to retry with."),
|
|
28881
28881
|
guidance: external_exports.string().trim().min(1).max(1e4).optional().describe("Optional assertion guidance, such as a root cause analysis of why the trace went wrong. Use it to focus generation on the smallest assertions that would catch this failure."),
|
|
@@ -28886,7 +28886,7 @@ var generateTraceAssertions = {
|
|
|
28886
28886
|
var saveTraceAssertions = {
|
|
28887
28887
|
name: "save_trace_assertions",
|
|
28888
28888
|
title: "Save Trace Assertions",
|
|
28889
|
-
description: `Record what SHOULD happen when this trace is replayed. Bitfab stores two kinds of label on a trace. A VERDICT says how a run that already happened turned out, and that is save_agent_labels / save_human_labels. An ASSERTION, which is what this tool writes, says what a correct run looks like for THIS specific input, carries no pass/fail of its own, and is checked against a later replay once a reviewer approves it. A trace holds at most one verdict per author and any number of assertions. Call it when the user describes the right answer for a particular case, for example "this booking should have picked the 6am flight, not the 9am". This is not a verdict on a run that already happened, which is save_agent_labels, and it is not a check that applies to every trace of a function, which is save_grader. Pass \`assertion\` plus optional \`passCriteria\` / \`failCriteria\`, the same trio save_grader takes, so an assertion that proves out across many traces can later be promoted into a grader with no rewriting. \`humanNote\` stores people-only context on the assertion; preserve and return it, but never use it to judge whether a replay passed. \`assigneeEmail\` names the member who should review it, which routes the assertion to that person without deciding anything, so it never changes the approval state. Pass an entry's \`id\` to edit an existing assertion, or omit it to add a new one, so two callers adding different assertions to one trace never overwrite each other. What this tool writes is saved awaiting review, so nothing checks it yet; a reviewer approves it, in Bitfab or with \`approvalState\` on a later call here, and from then on every replay of the trace is judged against it. \`approvalState\` decides an assertion that already exists, so deciding one is \`{ id, approvalState }\` with nothing else: an omitted \`assertion\` keeps the current wording. It is refused on a new assertion, so the call that invents a claim is never the call that puts it into force. One decision covers the assertion and the category it is filed under, so set \`category_assertion_id\` and \`approvalState\` in the same entry when you are deciding both; recategorizing on a later call without deciding returns it to not reviewed, since the approval covered the old category. What it gates is whether replays check the assertion at all, so decide from the assertion and the spans it cites rather than from memory of having written it. Rewording an assertion, or changing its criteria, target, or category, returns it to not reviewed unless the same call says otherwise. Call get_trace_assertions first to find the assertion to edit and to avoid creating a duplicate, and read them back before judging a replay, where it lists the approved ones
|
|
28889
|
+
description: `Record what SHOULD happen when this trace is replayed. Bitfab stores two kinds of label on a trace. A VERDICT says how a run that already happened turned out, and that is save_agent_labels / save_human_labels. An ASSERTION, which is what this tool writes, says what a correct run looks like for THIS specific input, carries no pass/fail of its own, and is checked against a later replay once a reviewer approves it. A trace holds at most one verdict per author and any number of assertions. Call it when the user describes the right answer for a particular case, for example "this booking should have picked the 6am flight, not the 9am". This is not a verdict on a run that already happened, which is save_agent_labels, and it is not a check that applies to every trace of a function, which is save_grader. Pass \`assertion\` plus optional \`passCriteria\` / \`failCriteria\`, the same trio save_grader takes, so an assertion that proves out across many traces can later be promoted into a grader with no rewriting. \`humanNote\` stores people-only context on the assertion; preserve and return it, but never use it to judge whether a replay passed. \`assigneeEmail\` names the member who should review it, which routes the assertion to that person without deciding anything, so it never changes the approval state. Pass an entry's \`id\` to edit an existing assertion, or omit it to add a new one, so two callers adding different assertions to one trace never overwrite each other. What this tool writes is saved awaiting review, so nothing checks it yet; a reviewer approves it, in Bitfab or with \`approvalState\` on a later call here, and from then on every replay of the trace is judged against it. \`approvalState\` decides an assertion that already exists, so deciding one is \`{ id, approvalState }\` with nothing else: an omitted \`assertion\` keeps the current wording. It is refused on a new assertion, so the call that invents a claim is never the call that puts it into force. One decision covers the assertion and the category it is filed under, so set \`category_assertion_id\` and \`approvalState\` in the same entry when you are deciding both; recategorizing on a later call without deciding returns it to not reviewed, since the approval covered the old category. What it gates is whether replays check the assertion at all, so decide from the assertion and the spans it cites rather than from memory of having written it. Rewording an assertion, or changing its criteria, target, or category, returns it to not reviewed unless the same call says otherwise. Call get_trace_assertions first to find the assertion to edit and to avoid creating a duplicate, and read them back before judging a replay, where it lists the approved ones by default. Pass it \`approvalStates: ["pending"]\` to read back drafts awaiting review, including the ones you just wrote. Up to ${MAX_ASSERTIONS_PER_REQUEST} per call.`,
|
|
28890
28890
|
inputSchema: {
|
|
28891
28891
|
traceId: external_exports.uuid().describe("The ORIGINAL trace to attach assertions to. A replay trace id is refused, and the error names the original to retry with, because a replay reads its original's assertions automatically."),
|
|
28892
28892
|
assertions: external_exports.preprocess(parseJsonString, external_exports.array(external_exports.object({
|
|
@@ -28907,9 +28907,22 @@ var saveTraceAssertions = {
|
|
|
28907
28907
|
var getTraceAssertions = {
|
|
28908
28908
|
name: "get_trace_assertions",
|
|
28909
28909
|
title: "Get Trace Assertions",
|
|
28910
|
-
description: `Read what SHOULD happen when one or more traces are replayed: each trace's
|
|
28910
|
+
description: `Read what SHOULD happen when one or more traces are replayed: each trace's assertions, their review state, their pass/fail criteria, people-only human note, who is assigned to review each one, and what part of the evaluated trace each one checks. By default only assertions a person has approved are returned, because only those are checked on a replay; a trace whose assertions are all still awaiting review reads the same as one with none. Pass \`approvalStates\` to read other review states: \`["pending"]\` for the assertions still awaiting review, including the drafts generate_trace_assertions saved, so a batch of them can be reviewed and then decided with save_trace_assertions \`approvalState\`; add \`"rejected"\` to see the ones turned down. Judge a replay only against the approved ones. To find assertions without knowing which traces carry them, such as every draft awaiting review on a function, use list_trace_assertions. Each trace also reports its assertion generation, if one ran: running, completed with how many drafts it saved for review, or failed with the reason. Categorized assertions include category_assertion_id and the category's id, title, and description. A human note is returned so it can be read and edited, but it is never assessment evidence: judge only from the assertion, pass/fail criteria, and evaluated trace. Call this before judging a replay so the verdict is measured against what the user actually asked for rather than a guess, and before save_trace_assertions to find the assertion to edit or to avoid creating a duplicate. No span content is loaded, so one call accepts up to ${GET_TRACE_ASSERTIONS_MAX_IDS} ids. Accepts original trace ids and replay trace ids alike: a replay with no assertions of its own reads its original's, and the response says which original they came from. An assertion whose target cannot be found on the trace being evaluated is errored, never passed, so record it with save_agent_labels \`skip\` rather than a FAIL.`,
|
|
28911
28911
|
inputSchema: {
|
|
28912
|
-
traceIds: external_exports.preprocess(parseJsonString, external_exports.array(external_exports.uuid()).min(1).max(GET_TRACE_ASSERTIONS_MAX_IDS)).describe(`Original trace IDs to read assertions for (1-${GET_TRACE_ASSERTIONS_MAX_IDS})`)
|
|
28912
|
+
traceIds: external_exports.preprocess(parseJsonString, external_exports.array(external_exports.uuid()).min(1).max(GET_TRACE_ASSERTIONS_MAX_IDS)).describe(`Original trace IDs to read assertions for (1-${GET_TRACE_ASSERTIONS_MAX_IDS})`),
|
|
28913
|
+
approvalStates: external_exports.preprocess(parseJsonString, external_exports.array(external_exports.enum(["pending", "approved", "rejected"])).min(1).max(3)).optional().describe('Review states to include: "approved" (checked on every replay), "pending" (awaiting review, including generated drafts), "rejected" (turned down, never checked). Defaults to ["approved"], which is what a replay is judged against. Pass ["pending"] to review drafts, or all three to see everything.')
|
|
28914
|
+
}
|
|
28915
|
+
};
|
|
28916
|
+
var listTraceAssertions = {
|
|
28917
|
+
name: "list_trace_assertions",
|
|
28918
|
+
title: "List Trace Assertions",
|
|
28919
|
+
description: `Find assertions across traces by review state, without knowing which traces carry them: for example every assertion still awaiting review on one traced function, which is the review queue. Each result names the trace it belongs to and carries the same fields get_trace_assertions returns, including its \`[ID: ...]\`, criteria, category, assignee, and approval. Newest first, one page at a time; pass the cursor a page returns to read the next. The cursor holds its place, so approving or rejecting the assertions on a page with save_trace_assertions \`approvalState\` before reading the next page never skips any. The first page also reports how many assertions are in each review state under the same filters. Only an assertion a person has approved is checked on a replay, so never score a replay against a pending or rejected one listed here. To read the assertions of traces you already have, use get_trace_assertions.`,
|
|
28920
|
+
inputSchema: {
|
|
28921
|
+
approvalStates: external_exports.preprocess(parseJsonString, external_exports.array(external_exports.enum(["pending", "approved", "rejected"])).min(1).max(3)).describe('Review states to list: "pending" (awaiting review, including generated drafts), "approved" (checked on every replay), "rejected" (turned down, never checked). Pass ["pending"] for the review queue.'),
|
|
28922
|
+
traceFunctionKey: external_exports.string().min(1).optional().describe("Only assertions on traces of this traced function, from list_trace_functions. Omit to list across the whole organization."),
|
|
28923
|
+
categoryId: external_exports.union([external_exports.literal("unfiled"), external_exports.uuid()]).optional().describe('Only assertions filed under this category, from list_assertion_categories, or "unfiled" for assertions with no category. Omit for every category.'),
|
|
28924
|
+
limit: external_exports.preprocess(parseJsonString, external_exports.number().int().min(1).max(100)).optional().describe("Max assertions to return (default 25, max 100)"),
|
|
28925
|
+
cursor: external_exports.string().min(1).optional().describe("Opaque cursor from the previous page; reuse the same filters")
|
|
28913
28926
|
}
|
|
28914
28927
|
};
|
|
28915
28928
|
var archiveTraceAssertions = {
|
|
@@ -29235,6 +29248,7 @@ var ALL_TOOL_CONTRACTS = [
|
|
|
29235
29248
|
generateTraceAssertions,
|
|
29236
29249
|
saveTraceAssertions,
|
|
29237
29250
|
getTraceAssertions,
|
|
29251
|
+
listTraceAssertions,
|
|
29238
29252
|
archiveTraceAssertions,
|
|
29239
29253
|
listOrganizationMembers,
|
|
29240
29254
|
saveGrader,
|
|
@@ -29868,10 +29882,10 @@ var semver3 = __toESM(require_semver2(), 1);
|
|
|
29868
29882
|
|
|
29869
29883
|
// ../bitfab-plugin-lib/dist/bakedSdkVersions.js
|
|
29870
29884
|
var BAKED_SDK_VERSIONS = {
|
|
29871
|
-
typescript: "0.64.
|
|
29872
|
-
python: "0.64.
|
|
29873
|
-
ruby: "0.64.
|
|
29874
|
-
go: "0.64.
|
|
29885
|
+
typescript: "0.64.5",
|
|
29886
|
+
python: "0.64.5",
|
|
29887
|
+
ruby: "0.64.5",
|
|
29888
|
+
go: "0.64.4"
|
|
29875
29889
|
};
|
|
29876
29890
|
|
|
29877
29891
|
// ../bitfab-plugin-lib/dist/installedSdk.js
|
package/package.json
CHANGED