@gitkraken/core-gitlens 0.2.0 → 0.3.0

package/src/plus/agents/types.ts

@@ -0,0 +1,277 @@
+import type { IpcHandler } from '../../ipc/ipcServer.js';
+import type { UnifiedDisposable } from '../../utils/disposable.js';
+import type { Event } from '../../utils/event.js';
+
+export const claudeCodeNonBlockingHookEvents = [
+	'SessionStart',
+	'SessionEnd',
+	'UserPromptSubmit',
+	'PreToolUse',
+	'PostToolUse',
+	'PostToolUseFailure',
+	'Notification',
+	'Stop',
+	'StopFailure',
+	'SubagentStart',
+	'SubagentStop',
+	'TeammateIdle',
+	'TaskCompleted',
+	'InstructionsLoaded',
+	'ConfigChange',
+	'WorktreeCreate',
+	'WorktreeRemove',
+	'PreCompact',
+	'PostCompact',
+	'Elicitation',
+	'ElicitationResult',
+	'PermissionDenied',
+	'CwdChanged',
+] as const;
+
+export const claudeCodeBlockingHookEvents = ['PermissionRequest'] as const;
+
+export type ClaudeCodeHookEvent =
+	| (typeof claudeCodeNonBlockingHookEvents)[number]
+	| (typeof claudeCodeBlockingHookEvents)[number];
+
+export type PermissionDecision = 'allow' | 'deny';
+
+export type AgentSessionStatus =
+	| 'thinking'
+	| 'tool_use'
+	| 'responding'
+	| 'waiting'
+	| 'idle'
+	| 'compacting'
+	| 'permission_requested';
+
+export type AgentSessionPhase = 'idle' | 'working' | 'waiting';
+
+export function getPhaseForStatus(status: AgentSessionStatus): AgentSessionPhase {
+	switch (status) {
+		case 'thinking':
+		case 'tool_use':
+		case 'responding':
+		case 'compacting':
+			return 'working';
+		case 'waiting':
+		case 'permission_requested':
+			return 'waiting';
+		case 'idle':
+			return 'idle';
+	}
+}
+
+/**
+ * Returns whether the given phase represents an agent that is actively doing work or
+ * awaiting input (as opposed to fully idle). Uses an explicit allowlist so new phases
+ * default to "not active" rather than being silently treated as live.
+ */
+export function isActiveAgentPhase(phase: AgentSessionPhase): boolean {
+	return phase === 'working' || phase === 'waiting';
+}
+
+export interface PermissionSuggestion {
+	readonly type: string;
+	readonly tool?: string;
+	readonly rules?: readonly { readonly toolName: string; readonly ruleContent?: string }[];
+	readonly destination?: string;
+}
+
+/** Classification of what the agent is awaiting input for. Drives kind-aware UI: action button
+ *  labels, phase wording, and which payload field carries the body. Detected at the provider
+ *  boundary from the tool name / event so webviews don't grow their own classifiers.
+ *  - `tool`: a regular tool permission (Bash, Edit, Read, …) — body is `toolDescription`.
+ *  - `plan`: ExitPlanMode — body is `planSummary`; `planFilePath` may link the written plan.
+ *  - `question`: AskUserQuestion — body is `questionText`; `questionCount` describes the batch.
+ *  - `elicitation`: MCP elicitation — body is just `toolName`; user must respond in-session. */
+export type PendingPermissionKind = 'tool' | 'plan' | 'question' | 'elicitation';
+
+export interface PendingPermission {
+	readonly kind: PendingPermissionKind;
+	readonly toolName: string;
+	readonly toolDescription: string;
+	readonly toolInputDescription?: string;
+	readonly suggestions?: readonly PermissionSuggestion[];
+	/** Plan-mode (`kind === 'plan'`): on-disk path of the plan markdown, when the agent wrote one. */
+	readonly planFilePath?: string;
+	/** Plan-mode: short summary extracted from the plan content (first heading or leading sentence). */
+	readonly planSummary?: string;
+	/** Question-mode (`kind === 'question'`): the leading question text. */
+	readonly questionText?: string;
+	/** Question-mode: total number of questions in the batch. */
+	readonly questionCount?: number;
+}
+
+export interface AgentSession {
+	readonly id: string;
+	readonly providerId: string;
+	readonly providerName: string;
+	readonly name?: string;
+	readonly status: AgentSessionStatus;
+	readonly phase: AgentSessionPhase;
+	readonly statusDetail?: string;
+	readonly worktreePath?: string;
+	/** Common (parent) repo path shared by every worktree in this session's repo. Set together
+	 *  with `worktreePath` by `resolveGitInfo` — equal to `worktreePath` for a default-worktree
+	 *  session, otherwise the parent repo's common path. Use this for "same repo" identity
+	 *  checks; {@link workspacePath} is the matched workspace folder, not repo identity.
+	 *
+	 *  `undefined` carries two meanings the host distinguishes internally (via the
+	 *  `gitInfoUnresolvable` bookkeeping flag) but consumers should treat identically: either
+	 *  "not yet resolved" (no probe completed) or "resolved but cwd is not inside any git repo".
+	 *  Either way, no repo identity is available — never attempt to `path.join`/`path.resolve`
+	 *  against it without an explicit `!= null` check. */
+	readonly commonPath?: string;
+	readonly pid?: number;
+	readonly lastActivity: Date;
+	readonly phaseSince: Date;
+	readonly isSubagent: boolean;
+	readonly parentId?: string;
+	readonly subagents?: readonly AgentSession[];
+	readonly pendingPermission?: PendingPermission;
+	/** The VS Code workspace folder containing the agent's cwd, or `undefined` if cwd is outside
+	 *  any open workspace folder. Used for `isInWorkspace` and "Open Folder" only — NOT for repo
+	 *  identity. For "what repo is this session in", use {@link commonPath}. */
+	readonly workspacePath?: string;
+	readonly cwd?: string;
+	readonly planFile?: string;
+	readonly isInWorkspace: boolean;
+	readonly lastPrompt?: string;
+	readonly firstPrompt?: string;
+	/** Absolute paths of files targeted by in-flight file-editing tool calls (Edit/Write/MultiEdit/
+	 *  NotebookEdit). Populated on PreToolUse, drained on PostToolUse/PermissionDenied, cleared on
+	 *  Stop/SessionEnd. Empty/undefined when no file-editing tool is active.
+	 *
+	 *  Mutable array form so `Shape<AgentSession>` projects it as `string[]` (the `Shape<>` type
+	 *  mangles `readonly T[]` into a mapped object that loses its iterator). Treat as immutable. */
+	currentFiles?: string[];
+	/** Absolute paths of files the agent recently *read* (Read/NotebookRead). Populated on
+	 *  PreToolUse, drained on PostToolUse/PermissionDenied with the same cooldown as
+	 *  `currentFiles`. Distinct from `currentFiles` which tracks write-class tools so consumers can
+	 *  visualize "looking at" vs "working on" differently. Treat as immutable. */
+	currentReads?: string[];
+	/** `true` when the session was discovered via peer IPC sync (i.e. another GitLens window hosts
+	 *  the agent's hook flow and Claude Code extension panel). Locally-owned sessions leave this
+	 *  unset. The dispatcher uses this to route opens through the peer's IPC route + an OS-level
+	 *  window focus, since calling `claude-vscode.editor.open` in *our* extension only opens an
+	 *  inert local view that isn't connected to the live session running in the peer.
+	 *
+	 *  Window-local: never serialized faithfully across the IPC wire. Each window decides locally
+	 *  based on how it received the session — `querySiblingWindowSessions` always overrides to
+	 *  `true` regardless of what the peer published. */
+	readonly isPeerOwned?: boolean;
+	/**
+	 * Titles discovered by tailing the Claude Code transcript JSONL at
+	 * `~/.claude/projects/<encoded-cwd>/<sessionId>.jsonl`. Populated by
+	 * `ClaudeCodeTranscriptReader`; used by `getSessionDisplayName` as a fallback when no
+	 * harness-supplied `name` is available. Last occurrence in the transcript wins per type.
+	 */
+	readonly transcriptTitles?: {
+		readonly custom?: string;
+		readonly ai?: string;
+		readonly agent?: string;
+	};
+}
+
+export interface AgentSessionProvider extends UnifiedDisposable {
+	readonly id: string;
+	readonly name: string;
+	readonly icon: string;
+
+	readonly onDidChangeSessions: Event<void>;
+	readonly sessions: readonly AgentSession[];
+
+	start(workspacePaths: string[]): void;
+	stop(): void;
+	updateWorkspacePaths?(workspacePaths: string[]): void;
+
+	/** Resolves a pending permission. Returns `true` when the resolve was routed (the local IPC
+	 *  owns the session's pending entry); `false` when no local entry exists (typically a peer-
+	 *  discovered session owned by another GitLens window). Callers use this to give the user
+	 *  feedback rather than a silent no-op. */
+	resolvePermission?(
+		sessionId: string,
+		decision: PermissionDecision,
+		updatedPermissions?: PermissionSuggestion[],
+	): boolean;
+
+	/** Asks the peer GitLens window that has `workspacePath` open (or any peer whose workspacePath
+	 *  contains, or is contained by, it) to open the given session in its Claude Code extension
+	 *  via the `agents/sessions/open` IPC route. Resolves to `true` when at least one peer claimed
+	 *  the workspace AND was reachable; `false` otherwise. Best-effort: never rejects. The boolean
+	 *  is currently a diagnostic signal only — the dispatcher fires this in parallel with
+	 *  `vscode.openFolder` and relies on VS Code's window-folder matching to focus the owning
+	 *  window (which works whether or not the peer runs GitLens). */
+	notifyPeerOpenSession?(workspacePath: string, sessionId: string): Promise<boolean>;
+}
+
+/**
+ * Host-supplied IPC service. The agents package registers handlers and publishes
+ * the agents discovery file via this interface so it doesn't depend on the host's
+ * IPC service directly.
+ *
+ * The agents package is the source of truth for the workspacePaths advertised in
+ * the agents discovery file — `publishAgents` takes them as an argument and the host
+ * is expected to re-publish whenever those paths change.
+ */
+export interface IpcRegistrar {
+	readonly port: number | undefined;
+	/** Directory scanned for peer-window agent discovery files. Omit to disable peer discovery (tests). */
+	readonly agentDiscoveryDir?: string;
+	registerHandler<Request = unknown, Response = unknown>(
+		name: string,
+		handler: IpcHandler<Request, Response>,
+	): UnifiedDisposable;
+	publishAgents(workspacePaths: string[]): Promise<void>;
+	unpublishAgents(): Promise<void>;
+}
+
+export interface AgentProviderCallbacks {
+	/** Host-supplied IPC service. Required for agents to receive hook events from the GK CLI. */
+	ipc: IpcRegistrar;
+
+	/** Report that an agent session started. No-op if the host has no telemetry. */
+	onSessionStarted?(provider: string): void;
+
+	/** Report that an agent session ended. No-op if the host has no telemetry. */
+	onSessionEnded?(provider: string): void;
+
+	/** Report that a permission request was resolved. No-op if the host has no telemetry. */
+	onPermissionResolved?(info: { provider: string; tool: string; decision: PermissionDecision }): void;
+
+	/** Notify the host that a branch has agent activity. */
+	onBranchAgentActivity?(cwd: string): void;
+
+	/**
+	 * Run the GK CLI with the given args. Returns stdout.
+	 *
+	 * Host responsibilities:
+	 * - Resolve the CLI executable path (e.g. via `resolveCLIExecutable`)
+	 * - Provide the default `cwd` if `options.cwd` is not set (e.g. `globalStorageUri.fsPath` in VS Code)
+	 * - Inject any environment-specific flags (e.g. `--insiders` when the host has insiders mode enabled)
+	 */
+	runCLICommand(args: string[], options?: { cwd?: string }): Promise<string>;
+
+	/**
+	 * Resolve git metadata for a session's cwd. Returns the stable worktree path; the worktree's
+	 * display name (branch name for branch-type worktrees) is intentionally NOT returned — it's
+	 * resolved live at serialization time so `git checkout` updates display without restarting.
+	 * Optional — if omitted, sessions won't have worktree metadata.
+	 */
+	resolveGitInfo?(cwd: string): Promise<
+		| {
+				repoRoot: string;
+				isWorktree: boolean;
+				worktreePath?: string;
+		  }
+		| undefined
+	>;
+
+	/**
+	 * Open a Claude Code session in the Claude Code VS Code extension. Invoked by the IPC handler
+	 * when a peer GitLens window asks this window to open a session on its behalf — the host wires
+	 * this to `claude-vscode.editor.open`. Throws if the extension isn't installed/active.
+	 */
+	openSessionInClaudeExtension?(sessionId: string): Promise<void>;
+}

package/src/plus/ai/errors.ts

@@ -10,6 +10,8 @@ export const enum AIErrorReason {
 	ServiceCapacityExceeded,
 	Unauthorized,
 	UserQuotaExceeded,
+	NoNetwork,
+	Unreachable,
 }
 
 export class AIError extends Error {
@@ -37,6 +39,12 @@ export class AIError extends Error {
 			case AIErrorReason.ServiceCapacityExceeded:
 				message = 'Service capacity exceeded';
 				break;
+			case AIErrorReason.NoNetwork:
+				message = 'Unable to reach the AI service. Please check your internet connection.';
+				break;
+			case AIErrorReason.Unreachable:
+				message = 'The AI service is temporarily unreachable.';
+				break;
 			case AIErrorReason.NoRequestData:
 				message = original?.message ?? 'No data was provided for the request';
 				break;
@@ -80,3 +88,35 @@ export class AINoRequestDataError extends AIError {
 		Error.captureStackTrace?.(this, new.target);
 	}
 }
+
+const noNetworkErrorCodes = new Set([
+	'ENOTFOUND',
+	'ECONNREFUSED',
+	'EAI_AGAIN',
+	'EHOSTUNREACH',
+	'ENETUNREACH',
+	'ENETDOWN',
+	'UND_ERR_CONNECT_TIMEOUT',
+]);
+
+const unreachableErrorCodes = new Set(['ECONNRESET', 'ETIMEDOUT', 'UND_ERR_SOCKET']);
+
+export function classifyNetworkError(ex: unknown): AIErrorReason.NoNetwork | AIErrorReason.Unreachable | undefined {
+	let current: unknown = ex;
+	let sawFetchFailed = false;
+	for (let depth = 0; depth < 5 && current != null; depth++) {
+		if (!(current instanceof Error)) break;
+
+		if (current.name === 'TypeError' && current.message === 'fetch failed') {
+			sawFetchFailed = true;
+		}
+		const code = (current as { code?: unknown }).code;
+		if (typeof code === 'string') {
+			if (noNetworkErrorCodes.has(code)) return AIErrorReason.NoNetwork;
+			if (unreachableErrorCodes.has(code)) return AIErrorReason.Unreachable;
+		}
+
+		current = (current as { cause?: unknown }).cause;
+	}
+	return sawFetchFailed ? AIErrorReason.NoNetwork : undefined;
+}

package/src/plus/ai/models/promptTemplates.ts

@@ -81,12 +81,14 @@ interface ReviewPullRequestPromptTemplateContext {
 interface ReviewChangesPromptTemplateContext {
 	diff: string;
 	message: string;
+	context?: string;
 	instructions?: string;
 }
 
 interface ReviewOverviewPromptTemplateContext {
 	files: string;
 	message: string;
+	context?: string;
 	instructions?: string;
 }
 
@@ -95,6 +97,14 @@ interface ReviewDetailPromptTemplateContext {
 	overview: string;
 	message: string;
 	focusArea: string;
+	context?: string;
+	instructions?: string;
+}
+
+interface AddressReviewFindingsPromptTemplateContext {
+	reviewMarkdown: string;
+	scopeLabel: string;
+	granularity: 'review' | 'focusArea' | 'finding';
 	instructions?: string;
 }
 
@@ -114,6 +124,7 @@ export type PromptTemplateType =
 	| 'review-changes'
 	| 'review-overview'
 	| 'review-detail'
+	| 'address-review-findings'
 	| 'start-review-pullRequest'
 	| 'start-work-issue';
 
@@ -144,6 +155,8 @@ export type PromptTemplateContext<T extends PromptTemplateType> = T extends 'gen
 	? ReviewOverviewPromptTemplateContext
 	: T extends 'review-detail'
 	? ReviewDetailPromptTemplateContext
+	: T extends 'address-review-findings'
+	? AddressReviewFindingsPromptTemplateContext
 	: T extends 'start-review-pullRequest'
 	? ReviewPullRequestPromptTemplateContext
 	: T extends 'start-work-issue'

package/src/plus/ai/prompts.ts

@@ -350,7 +350,7 @@ Available search operators:
 - 'commit:' - Search by a specific commit SHA (e.g. 'commit:4ce3a')
 - 'file:' - Search by file path (e.g. 'file:"package.json"', 'file:"*.ts"'); maps to \`git log -- <value>\`
 - 'change:' - Search by specific code changes using regular expressions (e.g. 'change:"function.*auth"', 'change:"import.*react"'); maps to \`git log -G<value>\`
-- 'type:' - Search by type -- supports stash and tip (e.g. 'type:stash', 'type:tip')
+- 'type:' - Search by type -- supports stash, tip, and wip (e.g. 'type:stash', 'type:tip', 'type:wip'). Use 'type:wip' for queries about work in progress, uncommitted changes, or pending changes across worktrees.
 - 'ref:' - Search for commits reachable by a reference (branch, tag, commit) or reference range. Supports single refs (e.g. 'ref:main', 'ref:v1.0'), two-dot ranges (e.g. 'ref:main..feature' for commits in feature but not in main), three-dot ranges (e.g. 'ref:main...feature' for symmetric difference), and relative refs (e.g. 'ref:HEAD~5..HEAD'); maps to \`git log <ref>\`
 - 'after:' - Search for commits after a certain date or range (e.g. 'after:2023-01-01', 'after:"6 months ago"', 'after:"last Tuesday"', 'after:"noon"', 'after:"1 month 2 days ago"'); maps to \`git log --since=<value>\`
 - 'before:' - Search for commits before a certain date or range (e.g. 'before:2023-01-01', 'before:"6 months ago"', 'before:"yesterday"', 'before:"3PM GMT"'); maps to \`git log --until=<value>\`
@@ -529,10 +529,14 @@ Now, proceed with your analysis and provide a comprehensive review of the PR. Re
 
 export const reviewChanges: PromptTemplate<'review-changes'> = {
 	id: 'review-changes',
-	variables: ['diff', 'message', 'instructions'],
+	variables: ['diff', 'message', 'context', 'instructions'],
 	template: `You are an expert code reviewer analyzing a set of code changes. Your goal is to identify meaningful issues — bugs, logic errors, security vulnerabilities, missing error handling, and potential regressions — while ignoring style preferences and linter-level concerns. Focus on problems a careful human reviewer would catch.
 
-Examine the following code changes in Git diff format:
+Examine the following code changes in Git diff format. Each non-header line inside a hunk has been annotated with its 1-based new-file line number in a \`[NNNNN]\` block placed immediately after the line-type marker (\` \`, \`+\`, or \`-\`):
+  \` [   42] context line\`     // context: exists in both old and new; number = new-file line
+  \`+[   43] added line\`        // added: only in new file; number = new-file line
+  \`-[     ] removed line\`      // removed: not in new file; brackets are blank
+  \`@@ -10,5 +12,7 @@ ...\`     // hunk header (no annotation; ignore for line citing)
 <~~diff~~>
 \${diff}
 </~~diff~~>
@@ -542,6 +546,9 @@ Author's description of the changes:
 \${message}
 </~~message~~>
 
+Related work items (known pull requests and issues for this change set). Use these for *intent*: what the change is trying to accomplish. They are not authoritative spec — if a finding contradicts the stated intent, flag it rather than defer to it. May be empty.
+\${context}
+
 Produce a structured review in the following XML format. Include ONLY the XML tags described — no other text:
 
 <overview>
@@ -565,7 +572,7 @@ Guidelines:
 - Group related findings into focus areas by theme, not by file
 - If changes look correct and well-structured, say so in the overview and include zero focus areas
 - 3-5 high-quality findings are better than 15 low-quality ones
-- Reference specific lines from the diff when possible
+- For \`lines="start-end"\`, copy the numbers from the \`[NNNNN]\` annotations of the specific lines your finding concerns. Do not count, infer, or estimate — use only the annotated numbers. Removed lines (blank brackets \`[     ]\`) cannot be cited; pick the nearest surrounding new-file line instead. Anchor the range tightly to the lines the finding actually concerns; do not span an entire hunk.
 - Do not flag style issues, naming preferences, or things a linter would catch
 - Base conclusions only on the code shown — do not speculate about unseen code
 
@@ -576,7 +583,7 @@ Review the changes and produce the structured XML output above.`,
 
 export const reviewOverview: PromptTemplate<'review-overview'> = {
 	id: 'review-overview',
-	variables: ['files', 'message', 'instructions'],
+	variables: ['files', 'message', 'context', 'instructions'],
 	template: `You are an expert code reviewer performing an initial assessment of a set of code changes. You are given a file manifest (not full diffs) — use the file paths, change types, and line counts to identify which areas deserve closer inspection.
 
 File manifest (JSON array of changed files):
@@ -589,6 +596,9 @@ Author's description of the changes:
 \${message}
 </~~message~~>
 
+Related work items (known pull requests and issues for this change set). Use these for *intent* — what the change is trying to accomplish — when ranking which areas deserve closer review. May be empty.
+\${context}
+
 Produce a structured assessment in the following XML format. Include ONLY the XML tags described — no other text:
 
 <overview>
@@ -613,9 +623,33 @@ Guidelines:
 Assess the changes and produce the structured XML output above.`,
 };
 
+export const addressReviewFindings: PromptTemplate<'address-review-findings'> = {
+	id: 'address-review-findings',
+	variables: ['reviewMarkdown', 'scopeLabel', 'granularity', 'instructions'],
+	template: `You are an AI coding agent tasked with addressing the issues identified in a code review. Your goal is to understand each finding and, where appropriate, propose or make the code changes needed to fix it.
+
+The review was performed against: \${scopeLabel}
+
+The findings are provided as structured markdown below. Each finding includes a severity (\`**[CRITICAL]**\`, \`**[WARNING]**\`, or \`**[SUGGESTION]**\`), a short title, a description of the problem, and (when available) a file path and line range. Focus areas group related findings and include a rationale explaining why they matter.
+
+<review>
+\${reviewMarkdown}
+</review>
+
+Guidelines:
+- Treat the findings as a working list. Prioritize critical issues, then warnings, then suggestions.
+- For each finding, locate the referenced file(s) in the workspace before proposing a fix. If the file or line range no longer matches the review (the code may have evolved), reconcile against the current state.
+- When making code changes, address the underlying problem the finding describes — do not just paper over symptoms.
+- Prefer minimal, focused edits that don't introduce unrelated changes.
+- If a finding is ambiguous, contradicts the surrounding code's intent, or is already addressed in the current state, say so explicitly rather than fabricating a fix.
+- If a finding is out of scope (touches unrelated systems, requires significant refactoring, or contradicts established patterns), surface that as a tradeoff rather than acting on it.
+
+\${instructions}`,
+};
+
 export const reviewDetail: PromptTemplate<'review-detail'> = {
 	id: 'review-detail',
-	variables: ['diff', 'overview', 'message', 'focusArea', 'instructions'],
+	variables: ['diff', 'overview', 'message', 'focusArea', 'context', 'instructions'],
 	template: `You are an expert code reviewer performing a detailed inspection of specific files that were flagged for closer review. You have the context from an initial overview assessment.
 
 Initial overview of the full changeset:
@@ -630,7 +664,14 @@ Author's description of the changes:
 \${message}
 </~~message~~>
 
-Code changes for the files in this focus area (Git diff format):
+Related work items (known pull requests and issues for this change set). Use these for *intent* — what the change is trying to accomplish. They are not authoritative spec; if a finding contradicts the stated intent, flag it. May be empty.
+\${context}
+
+Code changes for the files in this focus area (Git diff format). Each non-header line inside a hunk has been annotated with its 1-based new-file line number in a \`[NNNNN]\` block placed immediately after the line-type marker (\` \`, \`+\`, or \`-\`):
+  \` [   42] context line\`     // context: exists in both old and new; number = new-file line
+  \`+[   43] added line\`        // added: only in new file; number = new-file line
+  \`-[     ] removed line\`      // removed: not in new file; brackets are blank
+  \`@@ -10,5 +12,7 @@ ...\`     // hunk header (no annotation; ignore for line citing)
 <~~diff~~>
 \${diff}
 </~~diff~~>
@@ -646,7 +687,7 @@ Produce detailed findings in the following XML format. Include ONLY the XML tags
 
 Guidelines:
 - Severity: "critical" = bugs, security, data loss; "warning" = logic concerns, error handling, regressions; "suggestion" = improvements, maintainability
-- Reference specific line numbers from the diff
+- For \`lines="start-end"\`, copy the numbers from the \`[NNNNN]\` annotations of the specific lines your finding concerns. Do not count, infer, or estimate — use only the annotated numbers. Removed lines (blank brackets \`[     ]\`) cannot be cited; pick the nearest surrounding new-file line instead. Anchor the range tightly to the lines the finding actually concerns; do not span an entire hunk.
 - Be concrete — explain what the problem is and how to fix it
 - If the code in this area looks correct, return an empty <findings></findings> block
 - Do not flag style issues or things a linter would catch

package/src/plus/ai/utils/results.utils.ts

@@ -78,9 +78,11 @@ function parseSeverity(value: string | undefined): AIReviewSeverity {
 
 function parseLineRange(value: string | undefined): { start: number; end: number } | undefined {
 	if (!value) return undefined;
+
 	const parts = value.split('-');
 	const start = parseInt(parts[0], 10);
 	if (isNaN(start)) return undefined;
+
 	const end = parts.length > 1 ? parseInt(parts[1], 10) : start;
 	return { start: start, end: isNaN(end) ? start : end };
 }