tool inputs badger

Author: spoons-and-mirrors

lib/prompts/compress.md

@@ -61,7 +61,7 @@ WHERE TO PICK STRINGS FROM (important for reliable matching):
 - The user's own words in their messages
 - Tool result output text (distinctive substrings within the output)
 - Previous compress summaries
-- Tool input string values (individual values, not whole serialized objects)
+- Tool input string values (LEAST RELIABLE - only single concrete field values, not keys or schema fields, may be transformed by AI SDK)
 
 NEVER USE GENERIC OR REPEATING STRINGS:
 
@@ -83,6 +83,9 @@ WHERE TO NEVER PICK STRINGS FROM:
 - Strings that span across message or part boundaries
 - Entire serialized JSON objects (key ordering may differ - pick a distinctive substring within instead)
 
+CRITICAL: AVOID USING TOOL INPUT VALUES
+NEVER use tool input schema keys or field names as boundary strings (e.g., "startString", "endString", "filePath", "content"). These may be transformed by the AI SDK and are not reliable. The ONLY acceptable use of tool input strings is a SINGLE concrete field VALUE (not the key), and even then, prefer using assistant text, user messages, or tool result outputs instead. When in doubt, choose boundaries from your own assistant responses or distinctive user message content.
+
 PARALLEL COMPRESS EXECUTION
 When multiple independent ranges are ready and their boundaries do not overlap, launch MULTIPLE `compress` calls in parallel in a single response. Run compression sequentially only when ranges overlap or when a later range depends on the result of an earlier compression.
 

lib/prompts/nudge.md

@@ -35,6 +35,9 @@ If you are performing a critical atomic operation, do not interrupt it, but make
 
 BE VERY MINDFUL of the startString and endString you use for compression for RELIABLE boundary matching. NEVER use generic tool outputs like "Edit applied successfully." or generic status message as boundaries. Use unique assistant text or distinctive content instead with enough surrounding context to ensure uniqueness.
 
+CRITICAL: AVOID USING TOOL INPUT VALUES AS BOUNDARIES
+NEVER use tool input schema keys or field names. The ONLY acceptable use of tool input strings is a SINGLE concrete field VALUE (not the key), and even then, prefer assistant text, user messages, or tool result outputs instead.
+
 Ensure your summaries are inclusive of all parts of the range.
 If the compressed range includes user messages, preserve user intent exactly. Prefer direct quotes for short user messages to avoid semantic drift.
 </instruction>

lib/prompts/system.md

@@ -31,6 +31,7 @@ NEVER use generic tool status messages as boundaries (e.g. "Edit applied success
 RESPECT THE CHRONOLOGY OF THE RANGE
 STARTSTRING MUST ALWAYS BE ABOVE ENDSTRING
 ENDSTRING MUST ALWAYS BE BELOW STARTSTRING
+DO NOT USE A TOOL SCHEMA FIELD FOR START OR END STRING.
 
 THE SUMMARY STANDARD
 Your summary MUST be technical and specific enough to preserve FULL understanding of what transpired, such that NO ambiguity remains about what asked, found, planned, done, or decided - yet noise free