bitfab-cli 0.2.405 → 0.2.407

package/dist/index.js

@@ -24697,10 +24697,10 @@ var semver3 = __toESM(require_semver2(), 1);
 
 // ../bitfab-plugin-lib/dist/bakedSdkVersions.js
 var BAKED_SDK_VERSIONS = {
-  typescript: "0.62.7",
-  python: "0.62.6",
-  ruby: "0.62.6",
-  go: "0.62.6"
+  typescript: "0.63.0",
+  python: "0.63.0",
+  ruby: "0.63.0",
+  go: "0.63.0"
 };
 
 // ../bitfab-plugin-lib/dist/installedSdk.js
@@ -28623,6 +28623,9 @@ var FRAMEWORK_VARIABLES = {
   }
 };
 
+// ../bitfab-plugin-lib/dist/flows/replayFlags.js
+var SKIP_ASSERTION_JUDGING_FLAG = `**Add \`--skip-assertion-judging\` when the installed replay command accepts it.** Run the SDK-installed \`bitfab-replay --help\` once per workspace and SDK version, with the same package runner as the replay itself. When its options list \`--skip-assertion-judging\`, add it to every replay command in this step. Newer SDKs otherwise have the server judge each replay's approved assertions as it finishes, which would write a second set of verdicts beside the ones this flow writes and pay for both. Older SDKs reject the flag, so leave it off when \`--help\` does not list it.`;
+
 // ../bitfab-plugin-lib/dist/flows/assistant.js
 var FAN_OUT_JUDGING = `{{#claude}}**Scale the judging with fan-out when there are many items.** Per-item judging is embarrassingly parallel: each verdict depends only on that one item's own artifacts (plus the fixed rubric and any shared context you gather once below), never on the other items, and the judge only reasons and returns JSON, it never edits files. So pick serial or fan-out by the item count:
 
@@ -30184,7 +30187,7 @@ The schema is flat, every file object is exactly \`{ path, before, after }\`. Do
 
 **Check the \`supportsCodeChanges\` flag** (from \`detect-replay-capabilities\`). If false, skip writing the code-change JSON file and omit \`--code-change\` from the invocation. The replay itself is unaffected; only the code-change metadata is missing from the experiment viewer.
 
-**Automatic fallback capture.** If you do not pass \`--code-change\`, a recent SDK auto-captures the branch's diff **against trunk** (the merge-base with \`origin/main\`) inside \`replay()\` itself and attaches it, so even a run where you did not hand-write a payload still shows a diff, as long as the SDK is new enough (\`supportsCodeChanges\`), you are in a git repo, and the working tree carries the change. This fallback is **cumulative** (whole branch vs trunk), not per-experiment. The precise per-experiment before/after still comes from writing the \`--code-change\` payload above, which always wins over the fallback, so keep doing that in \`make-change\`; the trunk diff is a last resort, not a reason to skip it.
+**Automatic fallback capture.** If you do not pass \`--code-change\`, a recent SDK auto-captures the **uncommitted** working-tree diff against \`HEAD\` inside \`replay()\` itself and attaches it, so even a run where you did not hand-write a payload still shows a diff, as long as the SDK is new enough (\`supportsCodeChanges\`), you are in a git repo, and the change is not yet committed. Older SDKs diff against the merge-base with trunk instead, which covers the whole branch. The precise per-experiment before/after still comes from writing the \`--code-change\` payload above, which always wins over the fallback, so keep doing that in \`make-change\`; the automatic diff is a last resort, not a reason to skip it.
 
 **Check the \`supportsExperimentGroups\` flag** (from \`detect-replay-capabilities\`). If true and an \`experimentGroupId\` exists, pass \`--experiment-group-id <experimentGroupId>\` (from \`open-experiments-before-replay\`) so the experiment is tagged with the group. This includes the initial \`fixReplayScope = "single-trace"\` pass. If false, skip the flag; the post-replay Bitfab inspection can fall back to \`experimentId\` when available.
 
@@ -30195,6 +30198,8 @@ The schema is flat, every file object is exactly \`{ path, before, after }\`. Do
 - **Initial \`fix\` pass (\`fixReplayScope = "single-trace"\`)**: pass \`--trace-ids <targetTraceId>\` (the trace ID held from Phase Fix \`resolve\`) and do NOT pass \`--dataset-id\`. This is the user's requested targeted replay. It proves the bug turned green before anything is added to a dataset or the rest of the dataset is run.
 - **Full dataset runs**: check the \`supportsDatasetId\` flag (from \`detect-replay-capabilities\`). When true, this is the **preferred way to replay the dataset**: pass \`--dataset-id <datasetId>\` (the dataset id held in working context: from \`pick-dataset\` in \`experiment\` / \`cost-optimize\` / \`benchmark\` modes, or from \`fix-add-to-dataset\` in \`fix\` mode, which skips \`pick-dataset\`) and **omit \`--trace-ids\` entirely**. The server replays exactly the dataset's traces and durably attributes the experiment to the dataset, so it shows under the dataset's experiments even when trace lineage can't be reconstructed, and you don't have to enumerate the dataset's trace IDs by hand. Only when \`supportsDatasetId\` is false do you fall back to \`--trace-ids <the dataset's resolved trace ids>\` (attribution then relies on the derived trace-lineage join). If the installed SDK lacks \`--dataset-id\`, prefer upgrading it (see \`upgrade-replay-script\`) over the trace-ids fallback.
 
+${SKIP_ASSERTION_JUDGING_FLAG}
+
 **Run the replay through \`{{command:replayProgress}}\` in the background, then relay the progress lines it prints.** Before starting, choose a unique run directory for this replay, for example \`.bitfab/replays/<experimentN>-<timestamp>-<short-random>\`, pass it with \`--run-dir\`, and hold that path in context; do not use a shared \`--events-log\` path. A foreground run blocks you for the whole replay and the user just sees "a shell is running" with no detail. \`{{command:replayProgress}}\` runs the replay, turns the SDK's per-trace \`@@bitfab:progress\` events into one self-contained line per trace on its stdout (a header, then for each trace as it finishes a pass/fail glyph, the running \`n/total\`, and that trace's duration, with the error reason inline on failure, plus a liveness heartbeat line when a slow trace goes quiet so the run never looks frozen, then a final summary with total + average time), and writes a small JSONL event log at \`<run-dir>/events.jsonl\`: \`type: "progress"\` rows as items finish, then a final \`type: "complete"\` row. Large per-item payloads are written atomically under \`<run-dir>/items/\` and referenced by \`item.itemPath\` / \`items[].itemPath\`, so outputs are not duplicated in the event log. It also tees every human line to \`<run-dir>/progress.log\`, so the user can \`tail -f\` it in a separate terminal for a live view that never collapses the way a tool card does. The wrapper writes \`<run-dir>/run.json\`; once the server experiment ID is known it also writes \`<parent-of-run-dir>/by-experiment/<experimentId>/run.json\` pointing back to the run directory. If the replay finishes no traces at all (an \`@bitfab/sdk\` too old to carry the lifecycle reporter, or an SDK too old to emit installed-command lifecycle events), it closes with a \`\u26A0 done \xB7 replay finished but reported no progress\` line instead of ending silently, so a missing stream of per-trace lines never reads as a hang, fix it via \`upgrade-replay-script\` and re-run. If the replay command exits 0 but its local \`ReplayResult\` capture is unavailable, the wrapper also exits 0, emits a \`\u26A0 unverified\` capture warning, and records \`status: "unverified"\` with \`resultCaptured: false\` in \`run.json\`: this prevents the host and metadata consumers from falsely reporting either failure or completion. Progress lines alone do not verify the result. Treat the outcome as unverified until the server experiment status resolves it; then explicitly report the server-confirmed outcome. You do NOT decide what or when to print: it does the formatting; you just show each new line.
 
 With a current replay-capable SDK, the event log also contains \`type: "started"\` lifecycle rows. These identify historical trace IDs that have entered a worker but have not necessarily settled; they are diagnostic only and must not be evaluated as completed items.
@@ -30984,7 +30989,7 @@ ${REPLAY_SAFETY_CHECK}
           toolCalls: ["bash"],
           title: "Run replay against the single trace",
           emit: "Running replay",
-          body: `**Run the replay against the one trace ID. No user interaction, no extra flags.** Invoke the SDK-installed executable with the registry and pipeline located in \`setup\`:
+          body: `**Run the replay against the one trace ID. No user interaction, and no extra flags beyond the one below.** Invoke the SDK-installed executable with the registry and pipeline located in \`setup\`:
 
 \`\`\`bash
 # TypeScript: cd <project-dir> && pnpm exec bitfab-replay --registry <registry-path> <pipeline> --trace-ids <trace-id>
@@ -30992,6 +30997,8 @@ ${REPLAY_SAFETY_CHECK}
 # Ruby:       cd <project-dir> && bundle exec bitfab-replay --registry <registry-path> <pipeline> --trace-ids <trace-id>
 \`\`\`
 
+${SKIP_ASSERTION_JUDGING_FLAG}
+
 This is a single-trace, in-chat path: run the replay directly, no progress-bar wrapper (one item has nothing to track). Do **not** pass \`--code-change\` or \`--experiment-group-id\`, this minimal path skips code-change payloads and experiment groups (persisting the verdict in the next step needs neither). Capture the full replay-result JSON and exit code, and from it hold the run's experiment ID (\`experimentId\` in TS, \`experiment_id\` in Python/Ruby; older SDKs print \`testRunId\` / \`test_run_id\`) and the completed item's trace id (\`traceId\` in TS, \`trace_id\` in Python/Ruby). **In the final replay result this trace id is already the SERVER replay trace id** (the SDK's \`completeReplay\` overwrites the local id with the server row id before returning), so the verdict step persists against it directly, no \`get_replay_status\` mapping. **If it is \`null\`, persistence is impossible this run** (an old server/SDK that returns no server-trace-id mapping), note that so the verdict step falls back to an in-chat-only verdict.
 
 **Quick health check.** If the replay crashed (non-zero exit, no items) or the single item has \`item.error\` set, hold the error for the verdict step. Otherwise hold the completed item's new output alongside the original output you read in \`setup\`.`,
@@ -31435,7 +31442,7 @@ When the project keeps local environment files, list the NAMES each required sec
           toolCalls: ["bash", "read", "ask"],
           body: `Validate workflow syntax (actionlint when available) and run the installed SDK CLI with --cloud --help. GitHub must have registered the workflow before it can be dispatched, and merging it to the default branch once registers it. After that, each replay dispatches the workflow as it is in that replay's snapshot, so later workflow edits apply on the next replay without merging, and the SDK only requires that the workflow is registered and enabled. Explain the required commit/merge for the first registration. Do not push, merge, change repository permissions, or set secrets without authorization.
 
-After the setup files are tracked (until then, pass each one with --cloud-include; the helper names any that are missing), run bitfab-replay --cloud <pipeline> --trace-ids <real-trace-uuid> --cloud-dry-run using the selected SDK command. It reports changed tracked files and omitted new files. Include new source files explicitly with repeated --cloud-include <repository-relative-file>. Review the entire snapshot for credentials. Filename screening is not a secret scanner. Then, once the workflow is merged and the secrets are set, run the same command with --cloud-check in place of --cloud-dry-run, when remote runs are authorized. It dispatches a real run that replays nothing: the runner stops with the names of any configured secrets that are empty (GitHub turns a secret that does not exist into an empty string), runs checkCommand, and resolves the traces with the replay's --dry-run, which loads the registry and proves the Bitfab key reaches the traces. Fix what it reports before the first replay, and read the Replay step log it links when it fails. Then, only when remote replay is authorized, run without --cloud-check. Any replay option the user would pass locally, such as --name, --dataset-ids in place of --trace-ids, --attempts, --judge-assertions, or --resume, goes after the pipeline and is passed to the replay on the runner as given; --params and --code-change files must be in the snapshot. --registry comes from cloud.json, and --dry-run and seeding stay local. Add --fail-on-error when a script should exit 1 on errored items. When items error, the runner prints each item's error, shortened, in the step log and the job summary. The helper creates a commit through an isolated index, pushes bitfab-replay/<UUID>, dispatches that branch, waits, retrieves the test-run identity, and deletes the branch with an exact-SHA lease. HEAD, staged changes, and working files stay untouched. Never reset or undo the user's work.
+After the setup files are tracked (until then, pass each one with --cloud-include; the helper names any that are missing), run bitfab-replay --cloud <pipeline> --trace-ids <real-trace-uuid> --cloud-dry-run using the selected SDK command. It reports changed tracked files and omitted new files. Include new source files explicitly with repeated --cloud-include <repository-relative-file>. Review the entire snapshot for credentials. Filename screening is not a secret scanner. Then, once the workflow is merged and the secrets are set, run the same command with --cloud-check in place of --cloud-dry-run, when remote runs are authorized. It dispatches a real run that replays nothing: the runner stops with the names of any configured secrets that are empty (GitHub turns a secret that does not exist into an empty string), runs checkCommand, and resolves the traces with the replay's --dry-run, which loads the registry and proves the Bitfab key reaches the traces. Fix what it reports before the first replay, and read the Replay step log it links when it fails. Then, only when remote replay is authorized, run without --cloud-check. Any replay option the user would pass locally, such as --name, --dataset-ids in place of --trace-ids, --attempts, --skip-assertion-judging, or --resume, goes after the pipeline and is passed to the replay on the runner as given; --params and --code-change files must be in the snapshot. --registry comes from cloud.json, and --dry-run and seeding stay local. Add --fail-on-error when a script should exit 1 on errored items. When items error, the runner prints each item's error, shortened, in the step log and the job summary. The helper creates a commit through an isolated index, pushes bitfab-replay/<UUID>, dispatches that branch, waits, retrieves the test-run identity, and deletes the branch with an exact-SHA lease. HEAD, staged changes, and working files stay untouched. Never reset or undo the user's work.
 
 Use --cloud-detach to return immediately; always detach from an agent session, since a replay can run for hours and, once GitHub shows the run, the wait has no local limit (it gives up only when GitHub shows no run for a dispatch within 10 minutes). Pass --cloud-timeout <minutes> (1..7200) to stop one replay early: the runner stops it cleanly and finished traces stay saved as an interrupted experiment. The generated job sets no timeout, so GitHub's 6-hour limit for its own runners applies; longer replays need a self-hosted runner with timeout-minutes set on the job. Explain --cloud-status, --cloud-watch, --cloud-cancel, and --cloud-cleanup with the printed execution UUID. Records live under this worktree's Git directory. Interrupted/lost-response submissions must be recovered, not blindly dispatched again. Cancel requests do not imply the job stopped. Watch/status confirms completion before deleting the branch. Detached jobs do not automatically clean themselves without a later local lifecycle command. Report separately whether files are generated, secrets configured, workflow merged, dry-run verified, cloud check passed, and an actual remote replay completed. Never call a mock smoke run a real replay.`,
           next: "cleanup/finish"

package/package.json

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