feat(rag): grep/glob/line-read + abort recovery + auto-unlock (1.8.1)

[Rippy1911]

Why

Device RAG was unusable for codebase questions: fuzzy hash-vector rag_search only, no path:line, no glob, no line-range read, tools locked behind combo-rag, and empty hits that looked like “code not found.” Separately, Play Console runs showed bare Error: The operation was aborted. with no recovery path, Stop looking like a fatal Error, failed tools chips marked done, and empty vision worker critiques soft-lied as success.

What changed

Code search

• rag_grep — literal/regex over the index → path:line + context; glob / maxMatches / caseInsensitive
• rag_glob — list paths by glob
• rag_read_file — startLine / endLine
• Auto-attach RAG tools when chunkCount > 0 (no skill_read required)
• Empty rag_search returns a hint to use rag_grep
• Skip lockfiles; truncated 2500-file walk → lastError

Error / vision surfacing

• Tool catch adds recovery hints for abort/timeout
• Sidepanel: AbortError → status Stopped (not Error: …)
• Tool chips: ok:false → status error
• Empty vision worker → explicit [VISION WORKER FAILED] message

Verification

Must ship	Evidence
Exact identifier → path:line	packages/core/src/rag/grep.test.ts
Glob / regex / dedupe / truncate	same
Abort recovery hint	packages/core/src/agent/errorRecovery.test.ts
Suite	642 passed / 6 skipped
Build Chrome+Firefox	yes, version 1.8.1

Test plan

• Grant Device RAG on a repo, rag_grep({pattern:"buildWorkoutPlan", glob:"**/*.ts"}) returns path:line
• Stop mid-run → status Stopped, no red Error bubble
• Force a capture abort → tool chip status error with recovery hint

Play Console walkthrough prompt (facts from due diligence): portfolio _memory/aironcoach-play-console-combo-prompt.md.

[nextsolutions-studio]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 4 🔵🔵🔵🔵⚪

🏅 Score: 78

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Wrong line numbers grepChunks reports line as the 1-based offset inside the chunk (li + 1), not the file. Multi-chunk files therefore cite near-start lines for every later chunk, so rag_read_file({ startLine, endLine }) from a grep hit opens the wrong range. Overlap dedupe keys only path + trimmed text, so identical lines at different file offsets collapse to one match. Trigger: any indexed file split across more than one chunk (normal for real sources). for (const [path, rows] of byPath) { rows.sort((a, b) => a.chunkIndex - b.chunkIndex); for (const row of rows) { const lines = row.content.split("\n"); for (let li = 0; li < lines.length; li++) { const lineText = lines[li]!; matcher.lastIndex = 0; const m = matcher.exec(lineText); if (!m) continue; // Line numbers are approximate: chunking is character-based, so we only // know the offset within the chunk. Dedupe on the matched text itself, // since the same source line appears at a different offset in the next // overlapping chunk. const key = `${path}:${lineText.trim()}`; if (seen.has(key)) continue; seen.add(key); matches.push({ path, line: li + 1, column: m.index + 1, text: lineText.trim().slice(0, 240), before: context > 0 ? lines.slice(Math.max(0, li - context), li).map((l) => l.trimEnd()) : [], after: context > 0 ? lines.slice(li + 1, li + 1 + context).map((l) => l.trimEnd()) : [], }); Inclusive endLine bug rag_read_file documents endLine as 1-based inclusive, but uses lines.slice(from, to) with to = endLine. Array slice excludes the end index, so the last requested line is dropped (e.g. startLine 3, endLine 3 yields empty content). Agents following grep hits will systematically miss the cited line. const startLine = typeof args.startLine === "number" ? Math.max(1, Math.floor(args.startLine)) : undefined; const endLine = typeof args.endLine === "number" ? Math.floor(args.endLine) : undefined; if (startLine != null || endLine != null) { const lines = file.content.split("\n"); const from = (startLine ?? 1) - 1; const to = endLine != null ? endLine : lines.length; const slice = lines.slice(from, to); result = { ok: true, path: file.path, startLine: from + 1, endLine: Math.min(to, lines.length), totalLines: lines.length, content: slice.join("\n"), truncated: file.truncated || to < lines.length, }; Full corpus load allChunks / allPaths always getAll() every IndexedDB chunk row into memory before filtering. On a maxed ~2500-file index this runs on each rag_grep / rag_glob, risking multi‑MB copies, GC pressure, and multi-second tool latency on weaker machines with no progressive limit or path index. /** Distinct indexed paths, unbounded — glob filtering happens in memory. */ async allPaths(): Promise<string[]> { await this.getDb(); const all = await idbReq<RagChunkRow[]>(this.store("chunks", "readonly").getAll()); return [...new Set(all.map((c) => c.path))].sort(); } /** Every chunk, for a literal scan. */ async allChunks(): Promise<RagChunkRow[]> { await this.getDb(); return idbReq<RagChunkRow[]>(this.store("chunks", "readonly").getAll()); } Abort hint over-match toolErrorRecovery treats any message containing "abort" as a cancelled capture/run. Benign tool errors that only mention abort in passing get the retry/wait playbook instead of the real error, and the bare { tool } fallback still omits error/message text for non-abort failures beyond the separate error field merge. export function toolErrorRecovery(tool: string, message: string): Record<string, unknown> { const lower = message.toLowerCase(); if (lower.includes("aborted") || lower.includes("abort")) { return { tool, hint: `${tool} was cancelled — the run was stopped, the tab was mid-navigation, or a screenshot ` + `raced another capture. This is not a result about the page. Wait for the tab to settle ` + `(wait), make sure it is focused, then retry ${tool} once. If it aborts again, move on and ` + `tell the user rather than retrying.`, }; } if (lower.includes("timeout") || lower.includes("timed out")) { return { tool, hint: `${tool} timed out — the page is slow or still loading. wait() for it to settle, then retry ` + `once with a narrower call (filter/offset) rather than the same broad one.`, }; } return { tool };

[nextsolutions-studio]

Suggestion: An empty pattern compiles to a zero-length regex and matches every line until maxMatches, so rag_grep({pattern:""}) returns a full page of junk hits marked ok: true. Reject blank patterns up front the same way invalid regexes already fail closed. [possible issue, importance: 6]

Suggested change

	let matcher: RegExp;
	try {
	matcher = opts.regex
	? new RegExp(opts.pattern, opts.caseInsensitive ? "gi" : "g")
	: new RegExp(
	opts.pattern.replace(/[.*+?^${}()|[\]\\]/g, "\\$&"),
	opts.caseInsensitive ? "gi" : "g",
	);
	} catch {
	return { matches: [], scannedFiles: 0, truncated: false };
	}
	if (!opts.pattern) {
	return { matches: [], scannedFiles: 0, truncated: false };
	}
	let matcher: RegExp;
	try {
	matcher = opts.regex
	? new RegExp(opts.pattern, opts.caseInsensitive ? "gi" : "g")
	: new RegExp(
	opts.pattern.replace(/[.*+?^${}()|[\]\\]/g, "\\$&"),
	opts.caseInsensitive ? "gi" : "g",
	);
	} catch {
	return { matches: [], scannedFiles: 0, truncated: false };
	}

[nextsolutions-studio]

Suggestion: When pattern is missing/blank, the handler still returns ok: true and the generic “No matches” hint, which steers the model to widen the query instead of fixing the call. Validate required input and fail with ok: false so the model retries with a real pattern. [possible issue, importance: 7]

Suggested change

	const out = grepChunks(chunks, {
	pattern: String(args.pattern ?? ""),
	regex: args.regex === true,
	caseInsensitive: args.caseInsensitive === true,
	glob: typeof args.glob === "string" ? args.glob : undefined,
	maxMatches: typeof args.maxMatches === "number" ? args.maxMatches : 50,
	context: typeof args.context === "number" ? args.context : 2,
	});
	result = {
	ok: true,
	...out,
	...(out.matches.length === 0
	? {
	hint:
	"No matches. Check the pattern (it is case-sensitive by default — try caseInsensitive:true), " +
	"widen the glob, or list candidates with rag_glob.",
	}
	: out.truncated
	? {
	hint: `Stopped at ${out.matches.length} matches. Narrow with glob:"<pattern>" or a more specific pattern.`,
	}
	: {}),
	};
	const pattern = String(args.pattern ?? "").trim();
	if (!pattern) {
	result = { ok: false, error: "pattern is required" };
	} else {
	const out = grepChunks(chunks, {
	pattern,
	regex: args.regex === true,
	caseInsensitive: args.caseInsensitive === true,
	glob: typeof args.glob === "string" ? args.glob : undefined,
	maxMatches: typeof args.maxMatches === "number" ? args.maxMatches : 50,
	context: typeof args.context === "number" ? args.context : 2,
	});
	result = {
	ok: true,
	...out,
	...(out.matches.length === 0
	? {
	hint:
	"No matches. Check the pattern (it is case-sensitive by default — try caseInsensitive:true), " +
	"widen the glob, or list candidates with rag_glob.",
	}
	: out.truncated
	? {
	hint: `Stopped at ${out.matches.length} matches. Narrow with glob:"<pattern>" or a more specific pattern.`,
	}
	: {}),
	};
	}

[nextsolutions-studio]

Suggestion: endLine is documented as inclusive, but when startLine > endLine or startLine is past EOF, this still returns ok: true with empty content, which the model can treat as an authoritative empty file range. Clamp/validate the range and return a clear error so the agent re-reads with corrected bounds. [general, importance: 5]

Suggested change

	if (startLine != null || endLine != null) {
	const lines = file.content.split("\n");
	const from = (startLine ?? 1) - 1;
	const to = endLine != null ? endLine : lines.length;
	const slice = lines.slice(from, to);
	result = {
	ok: true,
	path: file.path,
	startLine: from + 1,
	endLine: Math.min(to, lines.length),
	totalLines: lines.length,
	content: slice.join("\n"),
	truncated: file.truncated || to < lines.length,
	};
	if (startLine != null || endLine != null) {
	const lines = file.content.split("\n");
	const from = (startLine ?? 1) - 1;
	const to = endLine != null ? endLine : lines.length;
	if (from >= lines.length || (endLine != null && to < from + 1)) {
	result = {
	ok: false,
	error: `invalid range startLine=${startLine ?? 1} endLine=${endLine ?? lines.length} for ${file.path} (${lines.length} lines)`,
	totalLines: lines.length,
	};
	} else {
	const slice = lines.slice(from, to);
	result = {
	ok: true,
	path: file.path,
	startLine: from + 1,
	endLine: Math.min(to, lines.length),
	totalLines: lines.length,
	content: slice.join("\n"),
	truncated: file.truncated || to < lines.length,
	};
	}