ccqa 1.8.1 → 1.8.2

package/dist/bin/ccqa.mjs

@@ -3248,7 +3248,7 @@ function hashTriageUserPrompt(text) {
 */
 const CHANGED_FILE_DIFF_TOOL = "mcp__diff__changed_file_diff";
 function buildFailureAnalysisPrompt(input) {
-	const { script, specYaml, failureLog, liveTranscriptExcerpt, diffPatch, changedFiles, baseRef, baseSource = null, range = null, driftIssues, artifactsDir = null, outputLanguage = "auto", triageUserPrompt, customPrompt } = input;
+	const { script, specYaml, failureLog, liveTranscriptExcerpt, diffPatch, changedFiles, baseRef, baseSource = null, range = null, driftIssues, artifactsDir = null, outputLanguage = "auto", triageUserPrompt, customPrompt, baselineMissing = null } = input;
 	const lastGreen = baseSource === "last-green";
 	const triageUserPromptBlock = buildTriageUserPromptBlock(triageUserPrompt);
 	const customPromptBlock = buildCustomPromptBlock(customPrompt);
@@ -3257,7 +3257,13 @@ function buildFailureAnalysisPrompt(input) {
 	const baseLabel = lastGreen ? `this spec's last passing commit${baseRef && baseRef !== "last-green" ? ` (${baseRef})` : ""}` : baseRef ?? "base";
 	const rangeNote = range ? ` — spans ${range.commitCount} commit${range.commitCount === 1 ? "" : "s"} over ${range.days} day${range.days === 1 ? "" : "s"}` : "";
 	let diffBlock;
-	if (diffPatch === null) diffBlock = `## Source changes
+	if (baselineMissing) diffBlock = `## Source changes
+
+No baseline exists for this spec (${baselineMissing}), so there is no source diff. Work from the current repository state instead:
+- Grep for the exact selector / text / aria-label the failing step targets. Absent or renamed while the user-visible flow the spec describes still exists → the test is stale. The flow itself no longer implemented → the spec is stale.
+- Without a change window you cannot attribute the failure to a specific change — do not claim a change "introduced" it. State what the current source shows.
+`;
+	else if (diffPatch === null) diffBlock = `## Source changes
 
 No diff context is available (the base ref could not be resolved, or there are no changes). Classify from the failure log, the spec, and what you can read in the repository — and be correspondingly more conservative: prefer UNKNOWN over a confident SPEC_CHANGE/PRODUCT_BUG call without diff evidence.
 `;
@@ -3284,14 +3290,14 @@ A separate read-only audit compared the spec against the current source. Treat t
 
 ${driftIssues.map((i) => `- [${i.severity}] (${DRAFT_CATEGORY_LABEL[i.category]}${i.stepId ? `, step ${i.stepId}` : ""}) ${i.message}${i.detail ? ` — ${i.detail}` : ""}`).join("\n")}
 ` : "";
-	return `You are analyzing a failing E2E regression test against the source changes since a known-good baseline. Your job is a root-cause CALL, not a fix: decide which of three categories explains the failure, using the source diff as your primary context.
+	return `${baselineMissing ? `You are analyzing a failing E2E regression test. No known-good baseline exists for this spec yet, so there is no source diff: your primary context is the failure evidence plus the CURRENT state of the repository, which you can inspect with the read-only tools. Your job is a root-cause CALL, not a fix: decide which of three categories explains the failure.` : `You are analyzing a failing E2E regression test against the source changes since a known-good baseline. Your job is a root-cause CALL, not a fix: decide which of three categories explains the failure, using the source diff as your primary context.`}
 
 ${languageBlock}## The three categories
 
 The question that separates them: **is the behavior the spec describes still what the product intends?**
 
 1. TEST_DRIFT — what the spec verifies is unchanged; only the test code drifted from the source. Typical: a selector/aria-label/placeholder rename, a timing change, an over-tight assertion. The diff shows a change that is invisible to the user's intent but visible to the test.
-2. SPEC_CHANGE — the thing being verified itself changed: the UI flow, the layout, the feature's intended behavior. The diff deliberately changes what the spec asserts. You MUST cite the diff hunk (file + what changed) as evidence for this label.
+2. SPEC_CHANGE — the thing being verified itself changed: the UI flow, the layout, the feature's intended behavior. ${baselineMissing ? "The current source deliberately implements something other than what the spec asserts. You MUST cite the source file you read as evidence for this label." : "The diff deliberately changes what the spec asserts. You MUST cite the diff hunk (file + what changed) as evidence for this label."}
 3. PRODUCT_BUG — neither of the above: the failure is not explained by the diff nor by test staleness. The product regressed.
 
 If the evidence is too weak to choose, answer UNKNOWN — a wrong confident call is worse than an honest UNKNOWN, because humans grade these predictions to measure accuracy.
@@ -3303,19 +3309,24 @@ You can call \`Grep\`, \`Glob\`, and \`Read\` against the current repository (po
 - read the changed files in full when the truncated patch is not enough,
 - check whether the element/flow the spec describes still exists in the source.
 
-You can also call \`${CHANGED_FILE_DIFF_TOOL}\` with a file path to fetch that file's diff hunk for this run's base...HEAD range. The inline patch below is scoped to this spec's relatedPaths — files OUTSIDE that scope still appear in "Changed files (name-status)" but their hunks are not inlined. Before blaming (or ruling out) such a file, fetch its diff with this tool; Read only shows you its post-change state, not what changed.
+${baselineMissing ? `There is no diff range for this run, so the \`${CHANGED_FILE_DIFF_TOOL}\` tool has nothing to return — every conclusion must come from the current source state plus the failure evidence.` : `You can also call \`${CHANGED_FILE_DIFF_TOOL}\` with a file path to fetch that file's diff hunk for this run's base...HEAD range. The inline patch below is scoped to this spec's relatedPaths — files OUTSIDE that scope still appear in "Changed files (name-status)" but their hunks are not inlined. Before blaming (or ruling out) such a file, fetch its diff with this tool; Read only shows you its post-change state, not what changed.`}
 ${artifactsDir ? `\nThe test runner wrote this run's artifacts under \`${artifactsDir}\` (relative to the working directory). Read them for failure context the log tail above may not carry — e.g. a Playwright \`error-context.md\` holds the page's accessibility snapshot at the moment of failure, which often shows directly whether the awaited element was present. Do NOT open image/trace binaries.\n` : ""}
 You have **up to 12 tool turns**. Do NOT write, edit, run shell commands, or hit the network.
 
 ## Decision guidance
 
-${lastGreen ? `The baseline is the commit where THIS spec last passed, so the range strictly covers the window in which it broke: the cause is either inside these changes or outside the code entirely (flaky timing, environment, an external service, test data). The range may mix several unrelated merges — most of the diff is noise; what matters is the specific change you can tie to the failing step.` : `The baseline is a fixed ref (typically the PR base): the spec is NOT guaranteed to have passed there, so the range is not guaranteed to contain the cause.`}
+${baselineMissing ? `There is no baseline, so there is no "what changed" evidence at all. Classify from the failure signature checked against the current source:
+
+- The selector / text / attribute the failing step targets is absent or renamed in the current source, while the user-visible flow the spec describes still exists → TEST_DRIFT (cite the file:line where the renamed/replacement element lives).
+- The flow or feature the spec describes is no longer implemented — page gone, component removed, copy redefined, feature reworked → SPEC_CHANGE (cite the file you read that shows the new shape).
+- The flow exists and the test's selectors still match the source, but the observed behavior is wrong (error response, missing side effect, wrong data) → lean PRODUCT_BUG; FIRST rule out environment/data/timing causes (daemon not running, network down, missing credentials, stale test data) — those read as UNKNOWN with low confidence, not PRODUCT_BUG.
+- Without diff evidence, treat 0.7 as a practical confidence ceiling unless the current source alone is conclusive (e.g. the targeted selector is verifiably gone).` : `${lastGreen ? `The baseline is the commit where THIS spec last passed, so the range strictly covers the window in which it broke: the cause is either inside these changes or outside the code entirely (flaky timing, environment, an external service, test data). The range may mix several unrelated merges — most of the diff is noise; what matters is the specific change you can tie to the failing step.` : `The baseline is a fixed ref (typically the PR base): the spec is NOT guaranteed to have passed there, so the range is not guaranteed to contain the cause.`}
 
 - Diff touches only attributes/identifiers the test selects on (labels, testids, class names, timing) while the user-visible flow is intact → TEST_DRIFT.
 - Diff intentionally removes/reworks the UI or flow that a spec step verifies (component deleted, page restructured, copy redefined, feature flag flipped) → SPEC_CHANGE.
 - Diff UNINTENTIONALLY breaks behavior the spec still intends — e.g. a refactor that drops a side effect, an inverted condition, a regression hiding inside a cleanup commit — → PRODUCT_BUG, citing the diff hunk as evidence. A product bug is often introduced BY the diff; what separates it from SPEC_CHANGE is intent: does the change read as a deliberate redesign of what the spec verifies, or as collateral damage?
 ${lastGreen ? `- No change in the range explains the failing step (after checking the inline patch, the name-status list, and any hunks you fetched) → the cause is outside the code: answer UNKNOWN with low confidence and name the suspected external cause (flaky timing, environment, external service, test data). Do NOT default to PRODUCT_BUG here — under this baseline a product regression must be tied to an in-range change.` : `- Diff is unrelated to the failing step (or there is no relevant diff) and the test was passing before → lean PRODUCT_BUG; first rule out timing/data flakiness and infrastructure errors (daemon not running, network down, missing credentials) — those read as UNKNOWN with low confidence, not PRODUCT_BUG.`}${range ? `
-- This range spans ${range.commitCount} commit${range.commitCount === 1 ? "" : "s"} over ${range.days} day${range.days === 1 ? "" : "s"}. The wider the range, the more unrelated changes are mixed in: SPEC_CHANGE and TEST_DRIFT still require citing the specific hunk — do not infer intent from the bulk of a large diff, and lower confidence when the evidence is spread thin.` : ""}
+- This range spans ${range.commitCount} commit${range.commitCount === 1 ? "" : "s"} over ${range.days} day${range.days === 1 ? "" : "s"}. The wider the range, the more unrelated changes are mixed in: SPEC_CHANGE and TEST_DRIFT still require citing the specific hunk — do not infer intent from the bulk of a large diff, and lower confidence when the evidence is spread thin.` : ""}`}
 - The drift audit findings (when present) flag spec↔code mismatches; an ERROR there usually supports TEST_DRIFT or SPEC_CHANGE over PRODUCT_BUG.
 
 ## Sub-diagnosis vocabulary
@@ -3355,7 +3366,7 @@ Your **final** assistant message must start with \`{\` and end with \`}\` — a
 - 0.4-0.7: plausible but another category could explain it
 - < 0.4: answer UNKNOWN instead of guessing
 
-Evidence rules: TEST_DRIFT and SPEC_CHANGE require at least one concrete \`file\` reference (diff hunk or file:line you actually read). PRODUCT_BUG should cite the in-range change that unintentionally broke the behavior when one exists; ${lastGreen ? "under this last-green baseline, if no in-range change explains the failure, that is UNKNOWN (external cause), not PRODUCT_BUG" : "when no such change exists, explain why the diff does NOT account for the failure"}.
+Evidence rules: TEST_DRIFT and SPEC_CHANGE require at least one concrete \`file\` reference (diff hunk or file:line you actually read). ${baselineMissing ? "With no baseline there is no in-range change to cite: PRODUCT_BUG must instead explain why current-state inspection rules out test staleness and spec change." : `PRODUCT_BUG should cite the in-range change that unintentionally broke the behavior when one exists; ${lastGreen ? "under this last-green baseline, if no in-range change explains the failure, that is UNKNOWN (external cause), not PRODUCT_BUG" : "when no such change exists, explain why the diff does NOT account for the failure"}.`}
 
 ## Test Spec (spec.yaml)
 ${specYaml}
@@ -5767,10 +5778,6 @@ function createFailureAnalysisPass(deps) {
 			...fields,
 			analysisSkipped: ANALYSIS_DISABLED
 		};
-		if (!specDiffResult.ok) return {
-			...fields,
-			analysisSkipped: specDiffResult.skip
-		};
 		if (!deps.auth.ok) return {
 			...fields,
 			analysisSkipped: deps.auth.reason
@@ -5779,16 +5786,18 @@ function createFailureAnalysisPass(deps) {
 			...fields,
 			analysisSkipped: "no spec.yaml found for this spec"
 		};
-		info(`failure analysis: ${featureName}/${specName}`);
+		const baselineMissing = specDiffResult.ok ? null : specDiffResult.skip;
+		info(`failure analysis: ${featureName}/${specName}${baselineMissing ? " (no baseline — classifying from current source)" : ""}`);
 		const outcome = await analyzeFailure({
 			script: await input.readScript(),
 			specYaml: input.specYaml,
 			failureLog: input.failureLog,
-			diffPatch: specDiffResult.patch,
-			changedFiles: specDiffResult.nameStatus,
-			baseRef: specDiffResult.base.ref,
-			baseSource: specDiffResult.base.source,
-			range: specDiffResult.range,
+			diffPatch: specDiff?.patch ?? null,
+			changedFiles: specDiff?.nameStatus ?? null,
+			baseRef: specDiff?.base.ref ?? null,
+			baseSource: specDiff?.base.source ?? null,
+			range: specDiff?.range ?? null,
+			...baselineMissing ? { baselineMissing } : {},
 			driftIssues: input.driftIssues,
 			...input.artifactsDir ? { artifactsDir: input.artifactsDir } : {},
 			...deps.language ? { outputLanguage: deps.language } : {},
@@ -5797,7 +5806,7 @@ function createFailureAnalysisPass(deps) {
 		}, {
 			...deps.model ? { model: deps.model } : {},
 			cwd: deps.cwd,
-			getFileDiff: specDiffResult.fileDiff
+			getFileDiff: specDiff?.fileDiff ?? (() => null)
 		});
 		if (!printedHeader) {
 			printedHeader = true;
@@ -8244,26 +8253,24 @@ async function analyzeOneLiveFailure(r, diffProvider, driftForSpec, auth, opts,
 		failureLogExcerpt: null,
 		diffExcerpt: null
 	};
-	const specDiff = await diffProvider.forSpec({
+	const specDiffResult = await diffProvider.forSpec({
 		featureName: r.featureName,
 		specName: r.specName
 	});
-	if (!specDiff.ok) return {
-		analysis: null,
-		analysisSkipped: specDiff.skip,
-		failureLogExcerpt: excerpt,
-		diffExcerpt: null
-	};
-	if (specDiff.error) info(`failure analysis: source diff unavailable (${specDiff.error}) — analyzing without diff context`);
+	const specDiff = specDiffResult.ok ? specDiffResult : null;
+	const baselineMissing = specDiffResult.ok ? null : specDiffResult.skip;
+	if (baselineMissing) info(`failure analysis: no baseline (${baselineMissing}) — classifying from current source`);
+	else if (specDiff?.error) info(`failure analysis: source diff unavailable (${specDiff.error}) — analyzing without diff context`);
 	const customPrompt = resolveCustomPromptForTarget(opts.customPrompt, AGENT_BROWSER_TARGET);
 	const outcome = await analyzeFailure({
 		liveTranscriptExcerpt: excerpt,
 		specYaml: r.specYaml,
-		diffPatch: specDiff.patch,
-		changedFiles: specDiff.nameStatus,
-		baseRef: specDiff.base.ref,
-		baseSource: specDiff.base.source,
-		range: specDiff.range,
+		diffPatch: specDiff?.patch ?? null,
+		changedFiles: specDiff?.nameStatus ?? null,
+		baseRef: specDiff?.base.ref ?? null,
+		baseSource: specDiff?.base.source ?? null,
+		range: specDiff?.range ?? null,
+		...baselineMissing ? { baselineMissing } : {},
 		driftIssues: driftForSpec,
 		...opts.language ? { outputLanguage: opts.language } : {},
 		...opts.triageUserPrompt ? { triageUserPrompt: opts.triageUserPrompt } : {},
@@ -8271,7 +8278,7 @@ async function analyzeOneLiveFailure(r, diffProvider, driftForSpec, auth, opts,
 	}, {
 		...opts.model ? { model: opts.model } : {},
 		cwd,
-		getFileDiff: specDiff.fileDiff
+		getFileDiff: specDiff?.fileDiff ?? (() => null)
 	});
 	const pct = Math.round(outcome.analysis.confidence * 100);
 	const headline = outcome.analysis.headline.trim() || (outcome.analysis.reasoning.split("\n")[0] ?? "").trim();
@@ -8280,11 +8287,11 @@ async function analyzeOneLiveFailure(r, diffProvider, driftForSpec, auth, opts,
 		analysis: outcome.analysis,
 		analysisSkipped: null,
 		failureLogExcerpt: excerpt,
-		diffExcerpt: specDiff.patch,
-		analysisBase: {
+		diffExcerpt: specDiff?.patch ?? null,
+		...specDiff ? { analysisBase: {
 			ref: specDiff.base.ref,
 			sha: specDiff.base.sha
-		},
+		} } : {},
 		...customPrompt ? { customPromptVersion: customPrompt.customPromptVersion } : {}
 	};
 }
@@ -11069,7 +11076,7 @@ function buildReportEnvelope(args) {
 		},
 		model: opts.model ?? null,
 		language: opts.language ?? null,
-		promptVersion: "7",
+		promptVersion: "8",
 		customPromptVersion,
 		...triageUserPromptHash !== null ? { triageUserPromptHash } : {}
 	};
@@ -19472,7 +19479,7 @@ function createLearningWorker(deps) {
 		const prevCustomPrompt = await loadStoredCustomPrompt(storage, job.project);
 		const customPrompt = {
 			schemaVersion: 1,
-			basePromptVersion: "7",
+			basePromptVersion: "8",
 			customPromptVersion: `${generatedAt}-c${fallbackCases.length}`,
 			generatedAt,
 			guidance: fallbackGuidance ?? "",

package/dist/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ccqa",
-  "version": "1.8.1",
+  "version": "1.8.2",
   "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.8.1",
+  "version": "1.8.2",
   "type": "module",
   "description": "Browser test recorder powered by Claude Code and agent-browser",
   "repository": {