@probelabs/probe 0.6.0-rc264 → 0.6.0-rc265

package/build/agent/ProbeAgent.js

@@ -2771,6 +2771,7 @@ Follow these instructions carefully:
       * For rewriting entire functions/classes/methods, use the symbol parameter instead (no exact text matching needed).
       * For editing specific lines from search/extract output, use start_line (and optionally end_line) with the line numbers shown in the output.${this.hashLines ? ' Line references include content hashes (e.g. "42:ab") for integrity verification.' : ''}
       * For editing inside large functions: first use extract with the symbol target (e.g. "file.js#myFunction") to see the function with line numbers${this.hashLines ? ' and hashes' : ''}, then use start_line/end_line to surgically edit specific lines within it.
+      * IMPORTANT: Keep old_string as small as possible — include only the lines you need to change plus minimal context for uniqueness. For replacing large blocks (10+ lines), prefer line-targeted editing with start_line/end_line to constrain scope.
     - Use 'create' for new files or complete file rewrites.
     - If an edit fails, read the error message — it tells you exactly how to fix the call and retry.
     - The system tracks which files you've seen via search/extract. If you try to edit a file you haven't read, or one that changed since you last read it, the edit will fail with instructions to re-read first. Always use extract before editing to ensure you have current file content.` : ''}

package/build/agent/index.js

@@ -9553,6 +9553,11 @@ Example: <extract><targets>${displayPath}</targets></extract>`;
             if (!replace_all && occurrences > 1) {
               return `Error editing file: Multiple occurrences found - the old_string appears ${occurrences} times in ${file_path}. To fix: (1) Set replace_all=true to replace all occurrences, or (2) Include more surrounding lines in old_string to make the match unique (add the full line or adjacent lines for context).`;
             }
+            const oldLines = matchTarget.split("\n").length;
+            const newLines = new_string.split("\n").length;
+            if (oldLines >= 20 && newLines < oldLines * 0.5) {
+              return `Error editing file: Edit scope too large \u2014 replacing ${oldLines} lines with ${newLines} lines risks accidental content deletion. To fix: (1) Use line-targeted editing (start_line/end_line) instead to constrain scope, or (2) Split into smaller, focused edits that each target only the lines you intend to change.`;
+            }
             let newContent;
             if (replace_all) {
               newContent = content.replaceAll(matchTarget, new_string);
@@ -47588,7 +47593,7 @@ function validateFlowchart(text, options = {}) {
         const byLine = /* @__PURE__ */ new Map();
         const collect = (arr) => {
           for (const e of arr || []) {
-            if (e && (e.code === "FL-LABEL-PARENS-UNQUOTED" || e.code === "FL-LABEL-AT-IN-UNQUOTED" || e.code === "FL-LABEL-QUOTE-IN-UNQUOTED")) {
+            if (e && (e.code === "FL-LABEL-PARENS-UNQUOTED" || e.code === "FL-LABEL-AT-IN-UNQUOTED" || e.code === "FL-LABEL-QUOTE-IN-UNQUOTED" || e.code === "FL-LABEL-SLASH-UNQUOTED")) {
               const ln = e.line ?? 0;
               const col = e.column ?? 1;
               const list = byLine.get(ln) || [];
@@ -47671,6 +47676,7 @@ function validateFlowchart(text, options = {}) {
                 const hasAt = seg.includes("@");
                 const hasQuote = seg.includes('"');
                 const isSingleQuoted = /^'[^]*'$/.test(trimmed);
+                const hasLeadingSlash = lsp === "/" || lsp === "\\";
                 if (!covered && !isQuoted && !isParenWrapped && hasParens) {
                   errs.push({ line: ln, column: startCol, severity: "error", code: "FL-LABEL-PARENS-UNQUOTED", message: "Parentheses inside an unquoted label are not supported by Mermaid.", hint: 'Wrap the label in quotes, e.g., A["Mark (X)"] \u2014 or replace ( and ) with HTML entities: &#40; and &#41;.' });
                   existing.push({ start: startCol, end: endCol });
@@ -47681,6 +47687,11 @@ function validateFlowchart(text, options = {}) {
                   existing.push({ start: startCol, end: endCol });
                   byLine.set(ln, existing);
                 }
+                if (!covered && !isQuoted && !isSlashPair && hasLeadingSlash) {
+                  errs.push({ line: ln, column: startCol, severity: "error", code: "FL-LABEL-SLASH-UNQUOTED", message: "Leading / or \\ inside an unquoted label is treated as a shape marker by Mermaid.", hint: 'Wrap the label in quotes, e.g., F["/dev/tty unavailable"], or use &#47; / &#92; for literal slashes.' });
+                  existing.push({ start: startCol, end: endCol });
+                  byLine.set(ln, existing);
+                }
                 if (!covered && !isQuoted && !isSlashPair && hasQuote && !isSingleQuoted) {
                   errs.push({ line: ln, column: startCol, severity: "error", code: "FL-LABEL-QUOTE-IN-UNQUOTED", message: "Quotes are not allowed inside unquoted node labels. Use &quot; for quotes or wrap the entire label in quotes.", hint: 'Example: C["HTML Output: data-trigger-visibility=&quot;true&quot;"]' });
                   existing.push({ start: startCol, end: endCol });
@@ -50689,7 +50700,7 @@ function computeFixes(text, errors, level = "safe") {
       }
       continue;
     }
-    if (is("FL-LABEL-PARENS-UNQUOTED", e) || is("FL-LABEL-AT-IN-UNQUOTED", e)) {
+    if (is("FL-LABEL-PARENS-UNQUOTED", e) || is("FL-LABEL-AT-IN-UNQUOTED", e) || is("FL-LABEL-SLASH-UNQUOTED", e)) {
       if (level === "safe" || level === "all") {
         if (patchedLines.has(e.line))
           continue;
@@ -71984,6 +71995,7 @@ If the solution is clear, you can jump to implementation right away. If not, ask
 - Avoid implementing special cases when a general approach works
 - Never expose secrets, API keys, or credentials in generated code. Never log sensitive information.
 - Do not surprise the user with unrequested changes. Do what was asked, including reasonable follow-up actions, but do not refactor surrounding code or add features that were not requested.
+- When editing files, keep edits focused and minimal. For changes spanning more than a few lines, prefer line-targeted editing (start_line/end_line) over text replacement (old_string) \u2014 it constrains scope and prevents accidental removal of adjacent content. Never include unrelated sections in an edit operation.
 - After every significant change, verify the project still builds and passes linting. Do not wait until the end to discover breakage.
 
 # After Implementation
@@ -71994,11 +72006,33 @@ If the solution is clear, you can jump to implementation right away. If not, ask
 
 # GitHub Integration
 - Use the \`gh\` CLI for all GitHub operations: issues, pull requests, checks, releases.
-- To create a pull request: commit your changes, push the branch, then use \`gh pr create --title "..." --body "..."\`.
 - To view issues or PRs: \`gh issue view <number>\`, \`gh pr view <number>\`.
 - If given a GitHub URL, use \`gh\` to fetch the relevant information rather than guessing.
 - Always return the pull request URL to the user after creating one.
-- When checking GitHub Actions, only read logs of failed jobs \u2014 do not waste time on successful ones. Use \`gh run view <run-id> --log-failed\` to fetch only the relevant output.`,
+- When checking GitHub Actions, only read logs of failed jobs \u2014 do not waste time on successful ones. Use \`gh run view <run-id> --log-failed\` to fetch only the relevant output.
+
+# Pull Request Creation
+- Commit your changes, push the branch, then use \`gh pr create --title "..." --body "..."\`.
+- **PR title**: Keep it short (under 72 characters). Use imperative mood describing the change (e.g. "Add retry logic for API calls", "Fix race condition in cache invalidation"). Prefix with the type of change when useful: \`fix:\`, \`feat:\`, \`refactor:\`, \`docs:\`, \`test:\`, \`chore:\`.
+- **PR body**: MUST follow this structure:
+
+\`\`\`
+## Problem / Task
+<What problem is being solved or what task was requested. If there is a linked issue, reference it with #number. Be specific about the root cause or motivation.>
+
+## Changes
+<Concise list of what was actually changed. Describe each meaningful change \u2014 files modified, logic added/removed, and why. Do NOT just list filenames; explain what each change does.>
+
+## Testing
+<What tests were added, modified, or run. Include:
+- New test names and what they verify
+- Whether existing tests still pass
+- Manual verification steps if applicable
+- Commands used to validate (e.g. \`make test\`, \`npm test\`)>
+\`\`\`
+
+- If the task originated from a GitHub issue, always reference it in the PR body (e.g. "Fixes #123" or "Closes #123") so the issue is automatically closed on merge. If it originated from an external ticket system (Jira, Linear, etc.), include the ticket ID and link in the Problem / Task section (e.g. "Resolves PROJ-456").
+- Do not leave the PR body empty or vague. Every PR must clearly communicate what was done and why so reviewers can understand the change without reading every line of diff.`,
       "support": `You are ProbeChat Support, a specialized AI assistant focused on helping developers troubleshoot issues and solve problems. Your primary function is to help users diagnose errors, understand unexpected behaviors, and find solutions using the provided code analysis tools.
 
 When troubleshooting:
@@ -85264,6 +85298,7 @@ Follow these instructions carefully:
       * For rewriting entire functions/classes/methods, use the symbol parameter instead (no exact text matching needed).
       * For editing specific lines from search/extract output, use start_line (and optionally end_line) with the line numbers shown in the output.${this.hashLines ? ' Line references include content hashes (e.g. "42:ab") for integrity verification.' : ""}
       * For editing inside large functions: first use extract with the symbol target (e.g. "file.js#myFunction") to see the function with line numbers${this.hashLines ? " and hashes" : ""}, then use start_line/end_line to surgically edit specific lines within it.
+      * IMPORTANT: Keep old_string as small as possible \u2014 include only the lines you need to change plus minimal context for uniqueness. For replacing large blocks (10+ lines), prefer line-targeted editing with start_line/end_line to constrain scope.
     - Use 'create' for new files or complete file rewrites.
     - If an edit fails, read the error message \u2014 it tells you exactly how to fix the call and retry.
     - The system tracks which files you've seen via search/extract. If you try to edit a file you haven't read, or one that changed since you last read it, the edit will fail with instructions to re-read first. Always use extract before editing to ensure you have current file content.` : ""}

package/build/agent/shared/prompts.js

@@ -87,6 +87,7 @@ If the solution is clear, you can jump to implementation right away. If not, ask
 - Avoid implementing special cases when a general approach works
 - Never expose secrets, API keys, or credentials in generated code. Never log sensitive information.
 - Do not surprise the user with unrequested changes. Do what was asked, including reasonable follow-up actions, but do not refactor surrounding code or add features that were not requested.
+- When editing files, keep edits focused and minimal. For changes spanning more than a few lines, prefer line-targeted editing (start_line/end_line) over text replacement (old_string) — it constrains scope and prevents accidental removal of adjacent content. Never include unrelated sections in an edit operation.
 - After every significant change, verify the project still builds and passes linting. Do not wait until the end to discover breakage.
 
 # After Implementation
@@ -97,11 +98,33 @@ If the solution is clear, you can jump to implementation right away. If not, ask
 
 # GitHub Integration
 - Use the \`gh\` CLI for all GitHub operations: issues, pull requests, checks, releases.
-- To create a pull request: commit your changes, push the branch, then use \`gh pr create --title "..." --body "..."\`.
 - To view issues or PRs: \`gh issue view <number>\`, \`gh pr view <number>\`.
 - If given a GitHub URL, use \`gh\` to fetch the relevant information rather than guessing.
 - Always return the pull request URL to the user after creating one.
-- When checking GitHub Actions, only read logs of failed jobs — do not waste time on successful ones. Use \`gh run view <run-id> --log-failed\` to fetch only the relevant output.`,
+- When checking GitHub Actions, only read logs of failed jobs — do not waste time on successful ones. Use \`gh run view <run-id> --log-failed\` to fetch only the relevant output.
+
+# Pull Request Creation
+- Commit your changes, push the branch, then use \`gh pr create --title "..." --body "..."\`.
+- **PR title**: Keep it short (under 72 characters). Use imperative mood describing the change (e.g. "Add retry logic for API calls", "Fix race condition in cache invalidation"). Prefix with the type of change when useful: \`fix:\`, \`feat:\`, \`refactor:\`, \`docs:\`, \`test:\`, \`chore:\`.
+- **PR body**: MUST follow this structure:
+
+\`\`\`
+## Problem / Task
+<What problem is being solved or what task was requested. If there is a linked issue, reference it with #number. Be specific about the root cause or motivation.>
+
+## Changes
+<Concise list of what was actually changed. Describe each meaningful change — files modified, logic added/removed, and why. Do NOT just list filenames; explain what each change does.>
+
+## Testing
+<What tests were added, modified, or run. Include:
+- New test names and what they verify
+- Whether existing tests still pass
+- Manual verification steps if applicable
+- Commands used to validate (e.g. \`make test\`, \`npm test\`)>
+\`\`\`
+
+- If the task originated from a GitHub issue, always reference it in the PR body (e.g. "Fixes #123" or "Closes #123") so the issue is automatically closed on merge. If it originated from an external ticket system (Jira, Linear, etc.), include the ticket ID and link in the Problem / Task section (e.g. "Resolves PROJ-456").
+- Do not leave the PR body empty or vague. Every PR must clearly communicate what was done and why so reviewers can understand the change without reading every line of diff.`,
 
   'support': `You are ProbeChat Support, a specialized AI assistant focused on helping developers troubleshoot issues and solve problems. Your primary function is to help users diagnose errors, understand unexpected behaviors, and find solutions using the provided code analysis tools.
 

package/build/tools/edit.js

@@ -448,6 +448,13 @@ Parameters:
           return `Error editing file: Multiple occurrences found - the old_string appears ${occurrences} times in ${file_path}. To fix: (1) Set replace_all=true to replace all occurrences, or (2) Include more surrounding lines in old_string to make the match unique (add the full line or adjacent lines for context).`;
         }
 
+        // Guard against over-scoped text edits (replacing large blocks with tiny replacements)
+        const oldLines = matchTarget.split('\n').length;
+        const newLines = new_string.split('\n').length;
+        if (oldLines >= 20 && newLines < oldLines * 0.5) {
+          return `Error editing file: Edit scope too large — replacing ${oldLines} lines with ${newLines} lines risks accidental content deletion. To fix: (1) Use line-targeted editing (start_line/end_line) instead to constrain scope, or (2) Split into smaller, focused edits that each target only the lines you intend to change.`;
+        }
+
         // Perform the replacement
         let newContent;
         if (replace_all) {

package/cjs/agent/ProbeAgent.cjs

@@ -37025,6 +37025,11 @@ Example: <extract><targets>${displayPath}</targets></extract>`;
             if (!replace_all && occurrences > 1) {
               return `Error editing file: Multiple occurrences found - the old_string appears ${occurrences} times in ${file_path}. To fix: (1) Set replace_all=true to replace all occurrences, or (2) Include more surrounding lines in old_string to make the match unique (add the full line or adjacent lines for context).`;
             }
+            const oldLines = matchTarget.split("\n").length;
+            const newLines = new_string.split("\n").length;
+            if (oldLines >= 20 && newLines < oldLines * 0.5) {
+              return `Error editing file: Edit scope too large \u2014 replacing ${oldLines} lines with ${newLines} lines risks accidental content deletion. To fix: (1) Use line-targeted editing (start_line/end_line) instead to constrain scope, or (2) Split into smaller, focused edits that each target only the lines you intend to change.`;
+            }
             let newContent;
             if (replace_all) {
               newContent = content.replaceAll(matchTarget, new_string);
@@ -74627,7 +74632,7 @@ function validateFlowchart(text, options = {}) {
         const byLine = /* @__PURE__ */ new Map();
         const collect = (arr) => {
           for (const e5 of arr || []) {
-            if (e5 && (e5.code === "FL-LABEL-PARENS-UNQUOTED" || e5.code === "FL-LABEL-AT-IN-UNQUOTED" || e5.code === "FL-LABEL-QUOTE-IN-UNQUOTED")) {
+            if (e5 && (e5.code === "FL-LABEL-PARENS-UNQUOTED" || e5.code === "FL-LABEL-AT-IN-UNQUOTED" || e5.code === "FL-LABEL-QUOTE-IN-UNQUOTED" || e5.code === "FL-LABEL-SLASH-UNQUOTED")) {
               const ln = e5.line ?? 0;
               const col = e5.column ?? 1;
               const list2 = byLine.get(ln) || [];
@@ -74710,6 +74715,7 @@ function validateFlowchart(text, options = {}) {
                 const hasAt = seg.includes("@");
                 const hasQuote = seg.includes('"');
                 const isSingleQuoted = /^'[^]*'$/.test(trimmed);
+                const hasLeadingSlash = lsp === "/" || lsp === "\\";
                 if (!covered && !isQuoted && !isParenWrapped && hasParens) {
                   errs.push({ line: ln, column: startCol, severity: "error", code: "FL-LABEL-PARENS-UNQUOTED", message: "Parentheses inside an unquoted label are not supported by Mermaid.", hint: 'Wrap the label in quotes, e.g., A["Mark (X)"] \u2014 or replace ( and ) with HTML entities: &#40; and &#41;.' });
                   existing.push({ start: startCol, end: endCol });
@@ -74720,6 +74726,11 @@ function validateFlowchart(text, options = {}) {
                   existing.push({ start: startCol, end: endCol });
                   byLine.set(ln, existing);
                 }
+                if (!covered && !isQuoted && !isSlashPair && hasLeadingSlash) {
+                  errs.push({ line: ln, column: startCol, severity: "error", code: "FL-LABEL-SLASH-UNQUOTED", message: "Leading / or \\ inside an unquoted label is treated as a shape marker by Mermaid.", hint: 'Wrap the label in quotes, e.g., F["/dev/tty unavailable"], or use &#47; / &#92; for literal slashes.' });
+                  existing.push({ start: startCol, end: endCol });
+                  byLine.set(ln, existing);
+                }
                 if (!covered && !isQuoted && !isSlashPair && hasQuote && !isSingleQuoted) {
                   errs.push({ line: ln, column: startCol, severity: "error", code: "FL-LABEL-QUOTE-IN-UNQUOTED", message: "Quotes are not allowed inside unquoted node labels. Use &quot; for quotes or wrap the entire label in quotes.", hint: 'Example: C["HTML Output: data-trigger-visibility=&quot;true&quot;"]' });
                   existing.push({ start: startCol, end: endCol });
@@ -77728,7 +77739,7 @@ function computeFixes(text, errors, level = "safe") {
       }
       continue;
     }
-    if (is("FL-LABEL-PARENS-UNQUOTED", e5) || is("FL-LABEL-AT-IN-UNQUOTED", e5)) {
+    if (is("FL-LABEL-PARENS-UNQUOTED", e5) || is("FL-LABEL-AT-IN-UNQUOTED", e5) || is("FL-LABEL-SLASH-UNQUOTED", e5)) {
       if (level === "safe" || level === "all") {
         if (patchedLines.has(e5.line))
           continue;
@@ -99023,6 +99034,7 @@ If the solution is clear, you can jump to implementation right away. If not, ask
 - Avoid implementing special cases when a general approach works
 - Never expose secrets, API keys, or credentials in generated code. Never log sensitive information.
 - Do not surprise the user with unrequested changes. Do what was asked, including reasonable follow-up actions, but do not refactor surrounding code or add features that were not requested.
+- When editing files, keep edits focused and minimal. For changes spanning more than a few lines, prefer line-targeted editing (start_line/end_line) over text replacement (old_string) \u2014 it constrains scope and prevents accidental removal of adjacent content. Never include unrelated sections in an edit operation.
 - After every significant change, verify the project still builds and passes linting. Do not wait until the end to discover breakage.
 
 # After Implementation
@@ -99033,11 +99045,33 @@ If the solution is clear, you can jump to implementation right away. If not, ask
 
 # GitHub Integration
 - Use the \`gh\` CLI for all GitHub operations: issues, pull requests, checks, releases.
-- To create a pull request: commit your changes, push the branch, then use \`gh pr create --title "..." --body "..."\`.
 - To view issues or PRs: \`gh issue view <number>\`, \`gh pr view <number>\`.
 - If given a GitHub URL, use \`gh\` to fetch the relevant information rather than guessing.
 - Always return the pull request URL to the user after creating one.
-- When checking GitHub Actions, only read logs of failed jobs \u2014 do not waste time on successful ones. Use \`gh run view <run-id> --log-failed\` to fetch only the relevant output.`,
+- When checking GitHub Actions, only read logs of failed jobs \u2014 do not waste time on successful ones. Use \`gh run view <run-id> --log-failed\` to fetch only the relevant output.
+
+# Pull Request Creation
+- Commit your changes, push the branch, then use \`gh pr create --title "..." --body "..."\`.
+- **PR title**: Keep it short (under 72 characters). Use imperative mood describing the change (e.g. "Add retry logic for API calls", "Fix race condition in cache invalidation"). Prefix with the type of change when useful: \`fix:\`, \`feat:\`, \`refactor:\`, \`docs:\`, \`test:\`, \`chore:\`.
+- **PR body**: MUST follow this structure:
+
+\`\`\`
+## Problem / Task
+<What problem is being solved or what task was requested. If there is a linked issue, reference it with #number. Be specific about the root cause or motivation.>
+
+## Changes
+<Concise list of what was actually changed. Describe each meaningful change \u2014 files modified, logic added/removed, and why. Do NOT just list filenames; explain what each change does.>
+
+## Testing
+<What tests were added, modified, or run. Include:
+- New test names and what they verify
+- Whether existing tests still pass
+- Manual verification steps if applicable
+- Commands used to validate (e.g. \`make test\`, \`npm test\`)>
+\`\`\`
+
+- If the task originated from a GitHub issue, always reference it in the PR body (e.g. "Fixes #123" or "Closes #123") so the issue is automatically closed on merge. If it originated from an external ticket system (Jira, Linear, etc.), include the ticket ID and link in the Problem / Task section (e.g. "Resolves PROJ-456").
+- Do not leave the PR body empty or vague. Every PR must clearly communicate what was done and why so reviewers can understand the change without reading every line of diff.`,
       "support": `You are ProbeChat Support, a specialized AI assistant focused on helping developers troubleshoot issues and solve problems. Your primary function is to help users diagnose errors, understand unexpected behaviors, and find solutions using the provided code analysis tools.
 
 When troubleshooting:
@@ -112302,6 +112336,7 @@ Follow these instructions carefully:
       * For rewriting entire functions/classes/methods, use the symbol parameter instead (no exact text matching needed).
       * For editing specific lines from search/extract output, use start_line (and optionally end_line) with the line numbers shown in the output.${this.hashLines ? ' Line references include content hashes (e.g. "42:ab") for integrity verification.' : ""}
       * For editing inside large functions: first use extract with the symbol target (e.g. "file.js#myFunction") to see the function with line numbers${this.hashLines ? " and hashes" : ""}, then use start_line/end_line to surgically edit specific lines within it.
+      * IMPORTANT: Keep old_string as small as possible \u2014 include only the lines you need to change plus minimal context for uniqueness. For replacing large blocks (10+ lines), prefer line-targeted editing with start_line/end_line to constrain scope.
     - Use 'create' for new files or complete file rewrites.
     - If an edit fails, read the error message \u2014 it tells you exactly how to fix the call and retry.
     - The system tracks which files you've seen via search/extract. If you try to edit a file you haven't read, or one that changed since you last read it, the edit will fail with instructions to re-read first. Always use extract before editing to ensure you have current file content.` : ""}

package/cjs/index.cjs

@@ -36188,6 +36188,11 @@ Example: <extract><targets>${displayPath}</targets></extract>`;
             if (!replace_all && occurrences > 1) {
               return `Error editing file: Multiple occurrences found - the old_string appears ${occurrences} times in ${file_path}. To fix: (1) Set replace_all=true to replace all occurrences, or (2) Include more surrounding lines in old_string to make the match unique (add the full line or adjacent lines for context).`;
             }
+            const oldLines = matchTarget.split("\n").length;
+            const newLines = new_string.split("\n").length;
+            if (oldLines >= 20 && newLines < oldLines * 0.5) {
+              return `Error editing file: Edit scope too large \u2014 replacing ${oldLines} lines with ${newLines} lines risks accidental content deletion. To fix: (1) Use line-targeted editing (start_line/end_line) instead to constrain scope, or (2) Split into smaller, focused edits that each target only the lines you intend to change.`;
+            }
             let newContent;
             if (replace_all) {
               newContent = content.replaceAll(matchTarget, new_string);
@@ -60262,7 +60267,7 @@ function validateFlowchart(text, options = {}) {
         const byLine = /* @__PURE__ */ new Map();
         const collect = (arr) => {
           for (const e5 of arr || []) {
-            if (e5 && (e5.code === "FL-LABEL-PARENS-UNQUOTED" || e5.code === "FL-LABEL-AT-IN-UNQUOTED" || e5.code === "FL-LABEL-QUOTE-IN-UNQUOTED")) {
+            if (e5 && (e5.code === "FL-LABEL-PARENS-UNQUOTED" || e5.code === "FL-LABEL-AT-IN-UNQUOTED" || e5.code === "FL-LABEL-QUOTE-IN-UNQUOTED" || e5.code === "FL-LABEL-SLASH-UNQUOTED")) {
               const ln = e5.line ?? 0;
               const col = e5.column ?? 1;
               const list2 = byLine.get(ln) || [];
@@ -60345,6 +60350,7 @@ function validateFlowchart(text, options = {}) {
                 const hasAt = seg.includes("@");
                 const hasQuote = seg.includes('"');
                 const isSingleQuoted = /^'[^]*'$/.test(trimmed);
+                const hasLeadingSlash = lsp === "/" || lsp === "\\";
                 if (!covered && !isQuoted && !isParenWrapped && hasParens) {
                   errs.push({ line: ln, column: startCol, severity: "error", code: "FL-LABEL-PARENS-UNQUOTED", message: "Parentheses inside an unquoted label are not supported by Mermaid.", hint: 'Wrap the label in quotes, e.g., A["Mark (X)"] \u2014 or replace ( and ) with HTML entities: &#40; and &#41;.' });
                   existing.push({ start: startCol, end: endCol });
@@ -60355,6 +60361,11 @@ function validateFlowchart(text, options = {}) {
                   existing.push({ start: startCol, end: endCol });
                   byLine.set(ln, existing);
                 }
+                if (!covered && !isQuoted && !isSlashPair && hasLeadingSlash) {
+                  errs.push({ line: ln, column: startCol, severity: "error", code: "FL-LABEL-SLASH-UNQUOTED", message: "Leading / or \\ inside an unquoted label is treated as a shape marker by Mermaid.", hint: 'Wrap the label in quotes, e.g., F["/dev/tty unavailable"], or use &#47; / &#92; for literal slashes.' });
+                  existing.push({ start: startCol, end: endCol });
+                  byLine.set(ln, existing);
+                }
                 if (!covered && !isQuoted && !isSlashPair && hasQuote && !isSingleQuoted) {
                   errs.push({ line: ln, column: startCol, severity: "error", code: "FL-LABEL-QUOTE-IN-UNQUOTED", message: "Quotes are not allowed inside unquoted node labels. Use &quot; for quotes or wrap the entire label in quotes.", hint: 'Example: C["HTML Output: data-trigger-visibility=&quot;true&quot;"]' });
                   existing.push({ start: startCol, end: endCol });
@@ -63363,7 +63374,7 @@ function computeFixes(text, errors, level = "safe") {
       }
       continue;
     }
-    if (is("FL-LABEL-PARENS-UNQUOTED", e5) || is("FL-LABEL-AT-IN-UNQUOTED", e5)) {
+    if (is("FL-LABEL-PARENS-UNQUOTED", e5) || is("FL-LABEL-AT-IN-UNQUOTED", e5) || is("FL-LABEL-SLASH-UNQUOTED", e5)) {
       if (level === "safe" || level === "all") {
         if (patchedLines.has(e5.line))
           continue;
@@ -84658,6 +84669,7 @@ If the solution is clear, you can jump to implementation right away. If not, ask
 - Avoid implementing special cases when a general approach works
 - Never expose secrets, API keys, or credentials in generated code. Never log sensitive information.
 - Do not surprise the user with unrequested changes. Do what was asked, including reasonable follow-up actions, but do not refactor surrounding code or add features that were not requested.
+- When editing files, keep edits focused and minimal. For changes spanning more than a few lines, prefer line-targeted editing (start_line/end_line) over text replacement (old_string) \u2014 it constrains scope and prevents accidental removal of adjacent content. Never include unrelated sections in an edit operation.
 - After every significant change, verify the project still builds and passes linting. Do not wait until the end to discover breakage.
 
 # After Implementation
@@ -84668,11 +84680,33 @@ If the solution is clear, you can jump to implementation right away. If not, ask
 
 # GitHub Integration
 - Use the \`gh\` CLI for all GitHub operations: issues, pull requests, checks, releases.
-- To create a pull request: commit your changes, push the branch, then use \`gh pr create --title "..." --body "..."\`.
 - To view issues or PRs: \`gh issue view <number>\`, \`gh pr view <number>\`.
 - If given a GitHub URL, use \`gh\` to fetch the relevant information rather than guessing.
 - Always return the pull request URL to the user after creating one.
-- When checking GitHub Actions, only read logs of failed jobs \u2014 do not waste time on successful ones. Use \`gh run view <run-id> --log-failed\` to fetch only the relevant output.`,
+- When checking GitHub Actions, only read logs of failed jobs \u2014 do not waste time on successful ones. Use \`gh run view <run-id> --log-failed\` to fetch only the relevant output.
+
+# Pull Request Creation
+- Commit your changes, push the branch, then use \`gh pr create --title "..." --body "..."\`.
+- **PR title**: Keep it short (under 72 characters). Use imperative mood describing the change (e.g. "Add retry logic for API calls", "Fix race condition in cache invalidation"). Prefix with the type of change when useful: \`fix:\`, \`feat:\`, \`refactor:\`, \`docs:\`, \`test:\`, \`chore:\`.
+- **PR body**: MUST follow this structure:
+
+\`\`\`
+## Problem / Task
+<What problem is being solved or what task was requested. If there is a linked issue, reference it with #number. Be specific about the root cause or motivation.>
+
+## Changes
+<Concise list of what was actually changed. Describe each meaningful change \u2014 files modified, logic added/removed, and why. Do NOT just list filenames; explain what each change does.>
+
+## Testing
+<What tests were added, modified, or run. Include:
+- New test names and what they verify
+- Whether existing tests still pass
+- Manual verification steps if applicable
+- Commands used to validate (e.g. \`make test\`, \`npm test\`)>
+\`\`\`
+
+- If the task originated from a GitHub issue, always reference it in the PR body (e.g. "Fixes #123" or "Closes #123") so the issue is automatically closed on merge. If it originated from an external ticket system (Jira, Linear, etc.), include the ticket ID and link in the Problem / Task section (e.g. "Resolves PROJ-456").
+- Do not leave the PR body empty or vague. Every PR must clearly communicate what was done and why so reviewers can understand the change without reading every line of diff.`,
       "support": `You are ProbeChat Support, a specialized AI assistant focused on helping developers troubleshoot issues and solve problems. Your primary function is to help users diagnose errors, understand unexpected behaviors, and find solutions using the provided code analysis tools.
 
 When troubleshooting:
@@ -110620,6 +110654,7 @@ Follow these instructions carefully:
       * For rewriting entire functions/classes/methods, use the symbol parameter instead (no exact text matching needed).
       * For editing specific lines from search/extract output, use start_line (and optionally end_line) with the line numbers shown in the output.${this.hashLines ? ' Line references include content hashes (e.g. "42:ab") for integrity verification.' : ""}
       * For editing inside large functions: first use extract with the symbol target (e.g. "file.js#myFunction") to see the function with line numbers${this.hashLines ? " and hashes" : ""}, then use start_line/end_line to surgically edit specific lines within it.
+      * IMPORTANT: Keep old_string as small as possible \u2014 include only the lines you need to change plus minimal context for uniqueness. For replacing large blocks (10+ lines), prefer line-targeted editing with start_line/end_line to constrain scope.
     - Use 'create' for new files or complete file rewrites.
     - If an edit fails, read the error message \u2014 it tells you exactly how to fix the call and retry.
     - The system tracks which files you've seen via search/extract. If you try to edit a file you haven't read, or one that changed since you last read it, the edit will fail with instructions to re-read first. Always use extract before editing to ensure you have current file content.` : ""}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@probelabs/probe",
-  "version": "0.6.0-rc264",
+  "version": "0.6.0-rc265",
   "description": "Node.js wrapper for the probe code search tool",
   "main": "src/index.js",
   "module": "src/index.js",
@@ -80,7 +80,7 @@
     "@anthropic-ai/claude-agent-sdk": "^0.1.46",
     "@modelcontextprotocol/sdk": "^1.0.0",
     "@nyariv/sandboxjs": "github:probelabs/SandboxJS",
-    "@probelabs/maid": "^0.0.25",
+    "@probelabs/maid": "^0.0.26",
     "acorn": "^8.15.0",
     "acorn-walk": "^8.3.4",
     "adm-zip": "^0.5.16",

package/src/agent/ProbeAgent.js

@@ -2771,6 +2771,7 @@ Follow these instructions carefully:
       * For rewriting entire functions/classes/methods, use the symbol parameter instead (no exact text matching needed).
       * For editing specific lines from search/extract output, use start_line (and optionally end_line) with the line numbers shown in the output.${this.hashLines ? ' Line references include content hashes (e.g. "42:ab") for integrity verification.' : ''}
       * For editing inside large functions: first use extract with the symbol target (e.g. "file.js#myFunction") to see the function with line numbers${this.hashLines ? ' and hashes' : ''}, then use start_line/end_line to surgically edit specific lines within it.
+      * IMPORTANT: Keep old_string as small as possible — include only the lines you need to change plus minimal context for uniqueness. For replacing large blocks (10+ lines), prefer line-targeted editing with start_line/end_line to constrain scope.
     - Use 'create' for new files or complete file rewrites.
     - If an edit fails, read the error message — it tells you exactly how to fix the call and retry.
     - The system tracks which files you've seen via search/extract. If you try to edit a file you haven't read, or one that changed since you last read it, the edit will fail with instructions to re-read first. Always use extract before editing to ensure you have current file content.` : ''}

package/src/agent/shared/prompts.js

@@ -87,6 +87,7 @@ If the solution is clear, you can jump to implementation right away. If not, ask
 - Avoid implementing special cases when a general approach works
 - Never expose secrets, API keys, or credentials in generated code. Never log sensitive information.
 - Do not surprise the user with unrequested changes. Do what was asked, including reasonable follow-up actions, but do not refactor surrounding code or add features that were not requested.
+- When editing files, keep edits focused and minimal. For changes spanning more than a few lines, prefer line-targeted editing (start_line/end_line) over text replacement (old_string) — it constrains scope and prevents accidental removal of adjacent content. Never include unrelated sections in an edit operation.
 - After every significant change, verify the project still builds and passes linting. Do not wait until the end to discover breakage.
 
 # After Implementation
@@ -97,11 +98,33 @@ If the solution is clear, you can jump to implementation right away. If not, ask
 
 # GitHub Integration
 - Use the \`gh\` CLI for all GitHub operations: issues, pull requests, checks, releases.
-- To create a pull request: commit your changes, push the branch, then use \`gh pr create --title "..." --body "..."\`.
 - To view issues or PRs: \`gh issue view <number>\`, \`gh pr view <number>\`.
 - If given a GitHub URL, use \`gh\` to fetch the relevant information rather than guessing.
 - Always return the pull request URL to the user after creating one.
-- When checking GitHub Actions, only read logs of failed jobs — do not waste time on successful ones. Use \`gh run view <run-id> --log-failed\` to fetch only the relevant output.`,
+- When checking GitHub Actions, only read logs of failed jobs — do not waste time on successful ones. Use \`gh run view <run-id> --log-failed\` to fetch only the relevant output.
+
+# Pull Request Creation
+- Commit your changes, push the branch, then use \`gh pr create --title "..." --body "..."\`.
+- **PR title**: Keep it short (under 72 characters). Use imperative mood describing the change (e.g. "Add retry logic for API calls", "Fix race condition in cache invalidation"). Prefix with the type of change when useful: \`fix:\`, \`feat:\`, \`refactor:\`, \`docs:\`, \`test:\`, \`chore:\`.
+- **PR body**: MUST follow this structure:
+
+\`\`\`
+## Problem / Task
+<What problem is being solved or what task was requested. If there is a linked issue, reference it with #number. Be specific about the root cause or motivation.>
+
+## Changes
+<Concise list of what was actually changed. Describe each meaningful change — files modified, logic added/removed, and why. Do NOT just list filenames; explain what each change does.>
+
+## Testing
+<What tests were added, modified, or run. Include:
+- New test names and what they verify
+- Whether existing tests still pass
+- Manual verification steps if applicable
+- Commands used to validate (e.g. \`make test\`, \`npm test\`)>
+\`\`\`
+
+- If the task originated from a GitHub issue, always reference it in the PR body (e.g. "Fixes #123" or "Closes #123") so the issue is automatically closed on merge. If it originated from an external ticket system (Jira, Linear, etc.), include the ticket ID and link in the Problem / Task section (e.g. "Resolves PROJ-456").
+- Do not leave the PR body empty or vague. Every PR must clearly communicate what was done and why so reviewers can understand the change without reading every line of diff.`,
 
   'support': `You are ProbeChat Support, a specialized AI assistant focused on helping developers troubleshoot issues and solve problems. Your primary function is to help users diagnose errors, understand unexpected behaviors, and find solutions using the provided code analysis tools.
 

package/src/tools/edit.js

@@ -448,6 +448,13 @@ Parameters:
           return `Error editing file: Multiple occurrences found - the old_string appears ${occurrences} times in ${file_path}. To fix: (1) Set replace_all=true to replace all occurrences, or (2) Include more surrounding lines in old_string to make the match unique (add the full line or adjacent lines for context).`;
         }
 
+        // Guard against over-scoped text edits (replacing large blocks with tiny replacements)
+        const oldLines = matchTarget.split('\n').length;
+        const newLines = new_string.split('\n').length;
+        if (oldLines >= 20 && newLines < oldLines * 0.5) {
+          return `Error editing file: Edit scope too large — replacing ${oldLines} lines with ${newLines} lines risks accidental content deletion. To fix: (1) Use line-targeted editing (start_line/end_line) instead to constrain scope, or (2) Split into smaller, focused edits that each target only the lines you intend to change.`;
+        }
+
         // Perform the replacement
         let newContent;
         if (replace_all) {