ccqa 1.31.2 → 1.31.4

package/dist/bin/ccqa.mjs

@@ -15579,10 +15579,11 @@ async function runRecord(specPath, opts) {
 	let sealed = true;
 	let tracingStep;
 	let abortCause;
+	let traceFailureNote;
 	const teardown = createRunTeardown();
 	teardown.onFinalize(async () => {
 		if (!push) return;
-		sealed = await sealRecordPush(push, featureName, specName, recorded, abortCause !== void 0 ? abortNote(abortCause, tracingStep) : void 0);
+		sealed = await sealRecordPush(push, featureName, specName, recorded, abortCause !== void 0 ? abortNote(abortCause, tracingStep) : traceFailureNote);
 	});
 	const disposeSignalHandlers = installTeardownSignalHandlers(teardown, (sig) => {
 		abortCause = `terminated by signal (${sig})`;
@@ -15609,6 +15610,7 @@ async function runRecord(specPath, opts) {
 				}
 			});
 			tracingStep = void 0;
+			if (traceResult.status !== "passed") traceFailureNote = "trace finished FAILED — a step did not complete, so the recording does not demonstrate the spec";
 			blank();
 			await learnFromTrace({
 				enabled: opts.learnHubTracePrompt === true,
@@ -15633,14 +15635,17 @@ async function runRecord(specPath, opts) {
 		} finally {
 			await releaseLock();
 		}
-		recorded = generated;
+		recorded = generated && traceFailureNote === void 0;
 	} finally {
 		if (deadline !== void 0) clearTimeout(deadline);
 		await teardown.run();
 		disposeSignalHandlers();
 	}
 	if (!sealed) process.exit(2);
-	if (!recorded) process.exit(1);
+	if (!recorded) {
+		if (traceFailureNote !== void 0) error(traceFailureNote);
+		process.exit(1);
+	}
 }
 /** `--timeout <seconds>`: a positive whole number of seconds. */
 function parseTimeoutSeconds(raw) {
@@ -15898,6 +15903,21 @@ For a \`mode: live\` spec there is no generated surface, so always \`spec\`.
 
 ${surfaceAxisAside("`TEST_DRIFT`")}
 
+## What the \`replay-unstable\` comments are
+
+Generated code may carry \`// [warn] replay-unstable: ...\` comments. These are
+observations from the one validation replay run right after recording — a
+selector that did not appear within its timeout *in that run*, on that day's
+data and load. They are diagnostic breadcrumbs, not part of the test, and a
+slow environment produces them on selectors that are perfectly correct.
+
+Judge the selector the comment sits on like any other: find its string in the
+source. If it is there, the comment alone is **not** drift evidence — do not
+cite a \`replay-unstable\` comment as your evidence for TEST_DRIFT. If the
+string is genuinely absent from the source, the finding stands on that
+absence, with the source as the citation, whether or not a comment happens to
+sit nearby.
+
 ## Earning each answer
 
 - **No drift is a claim, not a default.** Make it after picking the concrete strings from *every* surface you were given — the spec's \`expected\` and the generated code's selectors alike — and finding each of them in the source. Clearing the test case because one surface checked out is the most common way to miss a real finding. If you never looked, the honest answer is UNKNOWN.

package/dist/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ccqa",
-  "version": "1.31.2",
+  "version": "1.31.4",
   "type": "module",
   "description": "Browser test recorder powered by Claude Code and agent-browser",
   "repository": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ccqa",
-  "version": "1.31.2",
+  "version": "1.31.4",
   "type": "module",
   "description": "Browser test recorder powered by Claude Code and agent-browser",
   "repository": {