fix: diagnostic issues

agents/ollama.ts

@@ -115,7 +115,8 @@ async function runOllamaLoop(ctx: AgentRunContext): Promise<AgentResult> {
     let response: Awaited<ReturnType<typeof ollama.chat>>;
     try {
       response = await retry(
-        () => ollama.chat({
+        () =>
+          ollama.chat({
             model,
             messages,
             tools,
@@ -127,7 +128,9 @@ async function runOllamaLoop(ctx: AgentRunContext): Promise<AgentResult> {
           delaysMs: [3_000, 8_000],
           shouldRetry: (err) => {
             const msg = err instanceof Error ? err.message : String(err);
-            return /unexpected EOF|XML syntax error|ECONNRESET|ETIMEDOUT|fetch failed/i.test(msg);
+            return /unexpected EOF|XML syntax error|ECONNRESET|ETIMEDOUT|fetch failed/i.test(
+              msg,
+            );
           },
           label: `Ollama turn ${iterations}`,
         },
@@ -138,12 +141,14 @@ async function runOllamaLoop(ctx: AgentRunContext): Promise<AgentResult> {
       return { success: false, error: `Ollama request failed: ${lastError}` };
     }
 
-    const promptTokens = (response as Record<string, unknown>).prompt_eval_count as number | undefined;
-    const evalTokens = (response as Record<string, unknown>).eval_count as number | undefined;
+    const promptTokens = response.prompt_eval_count;
+    const evalTokens = response.eval_count;
     if (promptTokens !== undefined) {
       const total = promptTokens + (evalTokens ?? 0);
       const pct = Math.round((total / 262144) * 100);
-      log.info(`  context: ${promptTokens} prompt + ${evalTokens ?? 0} eval = ${total} tokens (${pct}% of limit)`);
+      log.info(
+        `  context: ${promptTokens} prompt + ${evalTokens ?? 0} eval = ${total} tokens (${pct}% of limit)`,
+      );
     }
 
     const assistantMessage = response.message;

modes.ts

@@ -142,7 +142,7 @@ Inline comments are plain, no-frills anchors on the affected line:
 - **Optional \`<details><summary>Technical details</summary>...</details>\` collapsible** for findings whose technical context (longer file:line references, related-code snippets, suggested approach, regression-risk notes) would overwhelm the human-readable lead-in. Same plain-markdown bold-header shape as the body technical-details block — see *Inline technical details* above. Encouraged whenever the depth helps a downstream fix-agent; don't force one when the inline lead-in already says everything.
 - **Visible portion ≤ 2-3 sentences.** If you find yourself writing more, that's the cue to split the depth into the \`Technical details\` collapsible.
 - **Multi-site findings go inline too.** A finding that spans multiple files or multiple lines is still an inline comment — anchor it to the PRIMARY causal site (the place a developer would fix first), and list the other affected sites in the \`**Affected sites:**\` section of the technical-details block. "Spans multiple files" is NOT a reason to put a finding in the body.
-- **Anchor to the exact problem line.** Use the `| newLine |` column to find the specific line where the problematic symbol is **defined or first assigned** — not a nearby related line. If the symbol is `isAnyPending`, anchor to the line that defines `isAnyPending`, not a line that uses a different variable nearby.
+- **Anchor to the exact problem line.** Use the \`| newLine |\` column to find the specific line where the problematic symbol is **defined or first assigned** — not a nearby related line. If the symbol is \`isAnyPending\`, anchor to the line that defines \`isAnyPending\`, not a line that uses a different variable nearby.
 
 ## Body-wide rules