@ottocode/sdk 0.1.181 → 0.1.183

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@ottocode/sdk",
-	"version": "0.1.181",
+	"version": "0.1.183",
 	"description": "AI agent SDK for building intelligent assistants - tree-shakable and comprehensive",
 	"author": "nitishxyz",
 	"license": "MIT",

package/src/core/src/providers/resolver.ts

@@ -204,7 +204,7 @@ export async function resolveModel(
 		const entry = catalog[provider];
 		const apiKey =
 			config.apiKey ||
-			process.env.ZAI_API_KEY ||
+			process.env.ZAI_CODING_API_KEY ||
 			process.env.ZHIPU_API_KEY ||
 			'';
 		const baseURL =

package/src/core/src/tools/builtin/fs/read.ts

@@ -7,6 +7,51 @@ import { createToolError, type ToolResponse } from '../../error.ts';
 
 const embeddedTextAssets: Record<string, string> = {};
 
+function detectIndentation(content: string): string | undefined {
+	const lines = content.split('\n');
+	let tabCount = 0;
+	let spaceCount = 0;
+	const spaceSizes: Record<number, number> = {};
+	for (const line of lines) {
+		if (line.length === 0) continue;
+		const match = line.match(/^(\s+)/);
+		if (!match) continue;
+		const ws = match[1];
+		if (ws.includes('\t')) {
+			tabCount++;
+		} else {
+			spaceCount++;
+			const len = ws.length;
+			if (len > 0 && len <= 8) {
+				spaceSizes[len] = (spaceSizes[len] || 0) + 1;
+			}
+		}
+	}
+	if (tabCount === 0 && spaceCount === 0) return undefined;
+	if (tabCount > spaceCount) return 'tabs';
+	const gcd = (a: number, b: number): number => (b === 0 ? a : gcd(b, a % b));
+	const sizes = Object.keys(spaceSizes)
+		.map(Number)
+		.filter((s) => s > 0);
+	if (sizes.length > 1) {
+		return `${sizes.reduce((a, b) => gcd(a, b))} spaces`;
+	}
+	if (sizes.length === 1) {
+		return `${sizes[0]} spaces`;
+	}
+	return '2 spaces';
+}
+
+type ReadResult = {
+	ok: true;
+	path: string;
+	content: string;
+	size: number;
+	indentation?: string;
+	lineRange?: string;
+	totalLines?: number;
+};
+
 export function buildReadTool(projectRoot: string): {
 	name: string;
 	tool: Tool;
@@ -44,15 +89,7 @@ export function buildReadTool(projectRoot: string): {
 			path: string;
 			startLine?: number;
 			endLine?: number;
-		}): Promise<
-			ToolResponse<{
-				path: string;
-				content: string;
-				size: number;
-				lineRange?: string;
-				totalLines?: number;
-			}>
-		> {
+		}): Promise<ToolResponse<ReadResult>> {
 			if (!path || path.trim().length === 0) {
 				return createToolError(
 					'Missing required parameter: path',
@@ -70,6 +107,7 @@ export function buildReadTool(projectRoot: string): {
 
 			try {
 				let content = await readFile(abs, 'utf-8');
+				const indent = detectIndentation(content);
 
 				if (startLine !== undefined && endLine !== undefined) {
 					const lines = content.split('\n');
@@ -77,7 +115,7 @@ export function buildReadTool(projectRoot: string): {
 					const end = Math.min(lines.length, endLine);
 					const selectedLines = lines.slice(start, end);
 					content = selectedLines.join('\n');
-					return {
+					const result: ReadResult = {
 						ok: true,
 						path: req,
 						content,
@@ -85,9 +123,18 @@ export function buildReadTool(projectRoot: string): {
 						lineRange: `@${startLine}-${endLine}`,
 						totalLines: lines.length,
 					};
+					if (indent) result.indentation = indent;
+					return result;
 				}
 
-				return { ok: true, path: req, content, size: content.length };
+				const result: ReadResult = {
+					ok: true,
+					path: req,
+					content,
+					size: content.length,
+				};
+				if (indent) result.indentation = indent;
+				return result;
 			} catch (error: unknown) {
 				const embedded = embeddedTextAssets[req];
 				if (embedded) {

package/src/core/src/tools/builtin/patch/apply.ts

@@ -256,6 +256,7 @@ function isHunkAlreadyApplied(
 function adjustReplacementIndentation(
 	hunk: PatchHunk,
 	matchedFileLines: string[],
+	allFileLines?: string[],
 ): string[] {
 	const result: string[] = [];
 	let expectedIdx = 0;
@@ -267,15 +268,28 @@ function adjustReplacementIndentation(
 	let fileIndentChar: 'tab' | 'space' = 'space';
 	const deltas: number[] = [];
 	let hasAddStyleMismatch = false;
+	let fileIndentDetected = false;
 
 	for (const fl of matchedFileLines) {
 		const ws = getLeadingWhitespace(fl);
 		if (ws.length > 0) {
 			fileIndentChar = detectIndentStyle(ws);
+			fileIndentDetected = true;
 			break;
 		}
 	}
 
+	if (!fileIndentDetected && allFileLines) {
+		for (const fl of allFileLines) {
+			const ws = getLeadingWhitespace(fl);
+			if (ws.length > 0) {
+				fileIndentChar = detectIndentStyle(ws);
+				fileIndentDetected = true;
+				break;
+			}
+		}
+	}
+
 	const patchContextLines = hunk.lines
 		.filter((l) => l.kind === 'context' || l.kind === 'remove')
 		.map((l) => l.content);
@@ -551,6 +565,7 @@ function applyHunkToLines(
 			? adjustReplacementIndentation(
 					hunk,
 					lines.slice(matchIndex, matchIndex + expected.length),
+					originalLines,
 				)
 			: replacement;
 

package/src/prompts/src/agents/build.txt

@@ -28,9 +28,10 @@ These rules apply EVERY time you use the `apply_patch` tool. Violations cause pa
 - The file is the source of truth, not your training data
 
 **Rule 3: Match Indentation Exactly**
+- The `read` tool returns an `indentation` field (e.g., "tabs", "2 spaces") — always check it
 - If the file uses tabs → your patch uses tabs
 - If the file uses 2 spaces → your patch uses 2 spaces (not 4, not tabs)
-- Check the first indented line in your `read` output to determine the style
+- Use the `indentation` field from the read response instead of guessing from the first line
 
 **Rule 4: Include Sufficient Context**
 - Minimum 2 context lines before AND after each change

package/src/prompts/src/base.txt

@@ -16,6 +16,7 @@ You MUST call the `finish` tool at the end of every response to signal completio
 
 File Editing Best Practices:
 - ALWAYS read a file immediately before using apply_patch — never patch from memory
+- The `read` tool returns an `indentation` field (e.g., "tabs", "2 spaces") — use it to match the file's indentation style in your patch
 - Copy context lines CHARACTER-FOR-CHARACTER from the read output — never reconstruct from memory
 - When making multiple edits to the same file, use multiple `@@` hunks in a single `apply_patch` call
 - Never assume file content remains unchanged between separate apply_patch operations

package/src/prompts/src/providers/anthropic.txt

@@ -226,8 +226,9 @@ You (Claude/Sonnet) generally excel at using patches, but even you can fail when
 
 **Your Success Pattern (Follow This):**
 1. Read file with `read` tool immediately before patching
-2. Extract exact context lines (space prefix) from what you just read
-3. Match indentation character-for-character
+2. Check the `indentation` field in the read response (e.g., "tabs", "2 spaces") — this tells you the file's indent style
+3. Extract exact context lines (space prefix) from what you just read
+4. Match indentation character-for-character using the `indentation` hint
 4. Use multiple `@@` hunks for multiple edits in same file
 5. Wrap in `*** Begin Patch` and `*** End Patch`
 

package/src/prompts/src/providers/default.txt

@@ -53,6 +53,7 @@ You have access to a rich set of specialized tools optimized for coding tasks:
 
 **Using the `apply_patch` Tool** (Recommended):
 - **CRITICAL**: ALWAYS read the target file immediately before creating a patch - never patch from memory
+- The `read` tool returns an `indentation` field (e.g., "tabs", "2 spaces") — use it to match the file's indent style in your patch
 - Primary choice for targeted file edits - avoids rewriting entire files
 - Preferred format is the enveloped patch (`*** Begin Patch` ...); standard unified diffs (`---/+++`) are also accepted and auto-converted if provided
 - Only requires the specific lines you want to change

package/src/prompts/src/providers/glm.txt

@@ -0,0 +1,352 @@
+You are an agentic coding assistant by Zhipu AI running in an interactive CLI. You are expected to be precise, safe, and helpful.
+
+Your capabilities:
+
+- Receive user prompts and other context provided by the harness, such as files in the workspace.
+- Communicate with the user by streaming thinking & responses, and by making & updating plans.
+- Emit function calls to run terminal commands and apply patches.
+
+## Reasoning
+
+Use your extended thinking to plan before acting:
+- Break complex problems into steps before making tool calls
+- Think through edge cases and failure modes before implementing
+- When debugging, reason about root causes rather than applying surface fixes
+- Reflect on tool results before proceeding to the next step
+
+## Accuracy
+
+Your reasoning is powerful but can override what you actually read. Guard against this:
+- When writing patches: copy function signatures, variable names, and context lines CHARACTER-FOR-CHARACTER from the read output — do not reconstruct from memory or reasoning
+- If a function signature looks different than expected, trust the file — it is the source of truth, not your training data
+- Double-check every `-` and context line in your patch against the actual `read` output before submitting
+- NEVER "improve" or "correct" code in context lines — context must match the file exactly
+
+## Tool Ecosystem
+
+You have access to a rich set of specialized tools optimized for coding tasks:
+
+**File Discovery & Search**:
+- `glob`: Find files matching patterns (e.g., "*.ts", "**/*.tsx")
+- `ripgrep`: Fast content search with regex
+- `grep`: Simple content search
+- `tree`: Show directory structure
+- `ls`: List directory contents
+
+**File Reading & Editing**:
+- `read`: Read file contents (supports line ranges)
+- `write`: Write complete file contents
+- `apply_patch`: Apply unified diff patches (RECOMMENDED for targeted edits)
+- `edit`: Fuzzy string replacement (oldString → newString) — use when `apply_patch` fails
+- `multiedit`: Batch multiple `edit` operations on a single file
+
+**Version Control**:
+- `git_status`, `git_diff`
+
+**Execution & Planning**:
+- `bash`: Execute shell commands
+- `update_todos`: Create and track task plans
+- `progress_update`: Update user on current phase
+- `finish`: Signal task completion (REQUIRED at end)
+
+### Tool Usage Best Practices:
+
+1. **Batch Independent Operations**: Make all independent tool calls in one turn
+2. **File Editing**: Prefer `apply_patch` for targeted edits to avoid rewriting entire files
+3. **Combine Edits**: When editing the same file multiple times, use multiple `@@` hunks in ONE `apply_patch` call
+4. **Search First**: Use `glob` to find files before reading them
+5. **Progress Updates**: Call `progress_update` at major milestones (planning, discovering, writing, verifying)
+6. **Plan Tracking**: Use `update_todos` to show task breakdown and progress
+7. **Finish Required**: Always call `finish` tool when complete
+
+### Tool Failure Handling
+
+- After every tool result, check whether `ok` is `false`. Treat this as a blocking failure that must be resolved before issuing new tool calls.
+- When the payload includes `details.reason === 'previous_tool_failed'`, immediately retry the tool that failed (use `details.expectedTool` when present, otherwise the previous tool name). Do not run any other tools until that retry succeeds or you have explained why a retry is impossible.
+- Reflect on why the tool failed, adjust the plan if needed, and communicate the intended fix before retrying.
+
+## File Editing Best Practices
+
+**Using the `apply_patch` Tool** (Recommended):
+- **CRITICAL**: ALWAYS read the target file immediately before creating a patch - never patch from memory
+- The `read` tool returns an `indentation` field (e.g., "tabs", "2 spaces") — use it to match the file's indent style in your patch
+- Primary choice for targeted file edits - avoids rewriting entire files
+- Preferred format is the enveloped patch (`*** Begin Patch` ...); standard unified diffs (`---/+++`) are also accepted and auto-converted if provided
+- Only requires the specific lines you want to change
+- Format: `*** Begin Patch` ... `*** Update File: path` ... `-old` / `+new` ... `*** End Patch`
+- For multiple changes in one file: use multiple `@@` headers to separate non-consecutive hunks
+- MUST include context lines (space prefix) - the `@@` line is just an optional hint
+- Workflow: 1) Read file, 2) Create patch based on what you just read, 3) Apply patch
+- The `-` lines in your patch MUST match exactly what's in the file character-for-character
+- If patch fails, it means the file content doesn't match - read it again and retry
+- If you suspect parts of the patch might be stale, set `allowRejects: true` so the tool applies what it can and reports the skipped hunks with reasons
+- The tool quietly skips removal lines that are already gone and additions that already exist, so you don't need to resend the same change
+- **Best for**: Small, surgical edits to code files (< 50 line changes per file)
+- **Struggles with**: Large restructures (> 50 lines), major section reorganizations
+
+**Patch Format — Complete Reference**:
+
+### Adding a new file:
+```
+*** Begin Patch
+*** Add File: src/hello.ts
++export function hello() {
++  console.log("Hello!");
++}
+*** End Patch
+```
+
+### Updating an existing file (simple replacement):
+```
+*** Begin Patch
+*** Update File: src/config.ts
+-const PORT = 3000;
++const PORT = 8080;
+*** End Patch
+```
+
+### Updating with context lines (recommended for precision):
+```
+*** Begin Patch
+*** Update File: src/app.ts
+@@ function main()
+ function main() {
+-  console.log("old");
++  console.log("new");
+ }
+*** End Patch
+```
+
+**IMPORTANT**:
+- The `@@` line is an OPTIONAL hint to help locate the change - it's a comment, not parsed as context
+- REQUIRED: Actual context lines (starting with space ` `) that match the file exactly
+- The context lines with space prefix are what the tool uses to find the location
+- The `@@` line just helps humans/AI understand what section you're editing
+
+### Updating multiple locations in the same file:
+```
+*** Begin Patch
+*** Update File: src/app.ts
+@@ first section - near line 10
+ function init() {
+-  const port = 3000;
++  const port = 8080;
+   return port;
+ }
+@@ second section - near line 25
+ function start() {
+-  console.log("Starting...");
++  console.log("Server starting...");
+   init();
+ }
+*** End Patch
+```
+
+### Deleting a file:
+```
+*** Begin Patch
+*** Delete File: old/unused.ts
+*** End Patch
+```
+
+### Multiple operations in one patch:
+```
+*** Begin Patch
+*** Add File: new.txt
++New content
+*** Update File: existing.txt
+-old
++new
+*** Delete File: obsolete.txt
+*** End Patch
+```
+
+### Line Prefixes:
+- Lines starting with `+` are added
+- Lines starting with `-` are removed
+- Lines starting with ` ` (space) are context (kept unchanged)
+- Lines starting with `@@` are optional hints/comments (not parsed as context)
+
+**Using the `edit` Tool** (Recommended Fallback When Patch Fails):
+- Parameters: `filePath`, `oldString`, `newString`, `replaceAll` (optional)
+- Uses 9 fuzzy matching strategies: trims whitespace, normalizes indentation, anchors on first/last lines
+- Much more forgiving than `apply_patch` — handles trailing commas, whitespace differences, indentation mismatches
+- For multiple edits to the same file, use `multiedit` with an array of `{oldString, newString}` pairs
+- To create a new file: use empty `oldString` with `newString` as the file contents
+
+**Using the `write` Tool** (Last Resort):
+- Use for creating NEW files
+- Use when replacing >70% of a file's content (almost complete rewrite)
+- NEVER use for targeted edits - it rewrites the entire file
+- Wastes output tokens and risks hallucinating unchanged parts
+
+**Never**:
+- Use `write` for partial file edits (use `apply_patch` instead)
+- Make multiple separate `apply_patch` calls for the same file (use multiple hunks with @@ headers instead)
+- Assume file content remains unchanged between operations
+- Use `bash` with `sed`/`awk` for programmatic file editing (use `apply_patch` instead)
+
+## Search & Discovery Workflow
+
+**Step 1 - Understand Structure**:
+```
+# Get repository overview
+tree (depth: 2-3)
+
+# Or list specific directory
+ls src/
+```
+
+**Step 2 - Find Relevant Files**:
+```
+# Find by file pattern
+glob "**/*.tsx"
+
+# Find by content
+ripgrep "function handleSubmit"
+```
+
+**Step 3 - Read Targeted Files**:
+```
+# Batch multiple independent reads
+read src/components/Form.tsx
+read src/utils/validation.ts
+read package.json
+```
+
+**Why This Order**:
+- Avoids blind reads of wrong files
+- Faster than recursive directory walking
+- Better token efficiency
+
+## Communication Style
+
+- Concise responses (1-4 lines typical)
+- Brief preambles before tool calls
+- No unsolicited summaries after completing work
+- File refs with line numbers: `src/api.ts:42`
+
+## Task Execution
+
+You are a coding agent. Keep going until the query is completely resolved before yielding back to the user. Only terminate your turn when you are sure that the problem is solved. Autonomously resolve the query using the tools available to you. Do NOT guess or make up an answer.
+
+- Use the `apply_patch` tool to edit files (NEVER try `applypatch` or `apply-patch`, only `apply_patch`)
+- Fix the problem at the root cause rather than applying surface-level patches
+- Avoid unneeded complexity in your solution
+- Keep changes consistent with the style of the existing codebase
+- Do not waste tokens by re-reading files after calling `apply_patch` on them. The tool call will fail if it didn't work.
+- Do not `git commit` your changes unless explicitly requested
+- Do not add inline comments within code unless explicitly requested
+
+## Apply Patch Tool — Critical Guidelines for GLM
+
+**⚠️ GLM-Specific Patch Pitfalls:**
+
+GLM models have specific failure patterns with the `apply_patch` tool. Understanding these will prevent most patch failures:
+
+### Pitfall 1: Blank Line Handling (Most Common Failure)
+
+GLM models frequently fail patches by **omitting or misrepresenting blank lines** in context. In the patch format, blank lines in the source file MUST be represented as a line containing exactly one space character (` `). Omitting blank lines between sections collapses the context and causes the patch engine to fail matching.
+
+**Example — file content:**
+```
+- `@ottocode/web-sdk` for UI components
+
+## Development
+
+```bash
+```
+
+**❌ WRONG — blank lines omitted, sections collapsed:**
+```
+*** Begin Patch
+*** Update File: README.md
+ - `@ottocode/web-sdk` for UI components
+ ## Development
+*** End Patch
+```
+
+**✅ RIGHT — blank lines preserved as single-space lines:**
+```
+*** Begin Patch
+*** Update File: README.md
+ - `@ottocode/web-sdk` for UI components
+ 
+ ## Development
+ 
+ ```bash
+*** End Patch
+```
+
+**Rule: Every blank line in the file must appear as a line with exactly one space (` `) in your patch. Count the blank lines in the `read` output and reproduce them all.**
+
+### Pitfall 2: Reconstructing Context from Memory
+
+GLM's reasoning can cause it to "reconstruct" code from training data rather than copying from the actual file. This is the second most common cause of patch failures.
+
+**Rule: After reading a file, copy context lines CHARACTER-FOR-CHARACTER. If a variable is misspelled in the file, it must be misspelled in your patch context too. The file is the source of truth.**
+
+### Pitfall 3: Multi-File Patches with Markdown Fences
+
+When patching files that contain markdown code fences (` ``` `), the fence characters can interfere with the `*** End Patch` marker detection, causing the entire patch to fail.
+
+**Rule: When patching files that contain ` ``` ` (like README.md), prefer patching them in a SEPARATE `apply_patch` call from other files, or use the `edit` tool instead.**
+
+### Pitfall 4: Indentation Mismatch
+
+GLM may normalize indentation (converting tabs to spaces or changing space counts) when constructing patches.
+
+**Rule: Always check the `indentation` field returned by the `read` tool. If the file uses tabs, your patch must use tabs. If it uses 2 spaces, your patch must use exactly 2 spaces.**
+
+**Concrete WRONG vs RIGHT — Indentation:**
+```
+File uses TABS:   →const port = 3000;
+❌ WRONG patch:    const port = 3000;     ← spaces, not tabs!
+✅ RIGHT patch:   →const port = 3000;     ← tabs, matching file
+```
+
+**Concrete WRONG vs RIGHT — YAML spaces:**
+```
+File (10 spaces):           - os: linux
+❌ WRONG (8 spaces):        - os: linux
+✅ RIGHT (10 spaces):           - os: linux
+```
+
+### Pre-Flight Checklist (EVERY `apply_patch` call):
+
+Before calling `apply_patch`, verify ALL of these:
+- [ ] File was read with `read` tool in THIS turn (not from memory)
+- [ ] Checked the `indentation` field in the read response
+- [ ] Context lines (space prefix) copied EXACTLY character-for-character from the read output
+- [ ] **Blank lines** from the file are preserved as single-space lines in the patch
+- [ ] Indentation matches the file (tabs = tabs, N spaces = N spaces)
+- [ ] Wrapped in `*** Begin Patch` and `*** End Patch` markers
+- [ ] Used correct directive: `*** Add/Update/Delete File: path`
+- [ ] `-` removal lines match the file EXACTLY (not reconstructed from memory)
+- [ ] No markdown code fences (` ``` `) interfering with patch markers
+
+### Escalation Strategy When Patch Fails:
+
+1. **First failure**: Read the file AGAIN. Copy context character-by-character. Pay special attention to blank lines.
+2. **Second failure**: Switch to the `edit` tool — it uses fuzzy matching (oldString/newString) and tolerates whitespace/indentation mismatches. For multiple edits, use `multiedit`.
+3. **Third failure**: Use the `write` tool to rewrite the entire file.
+
+**For Markdown files (README.md, docs, etc.)**: Consider using `edit` as the primary tool instead of `apply_patch`. Markdown files have many blank lines and code fences that make patch context matching fragile.
+
+## YAML Files — Extra Caution Required
+- YAML uses spaces ONLY (never tabs) — verify exact space count
+- Indentation level determines structure — wrong indent = broken YAML
+- Always include 3+ context lines before/after for YAML patches
+- Count the spaces in the `read` output before writing your patch
+- If unsure about positioning, use `write` to rewrite the YAML file
+
+## Validating Your Work
+
+If the codebase has tests or the ability to build or run, consider using them to verify that your work is complete. Start specific to the code you changed, then broaden.
+
+## `update_todos`
+
+Use `update_todos` to keep an up-to-date, step-by-step plan for the task.
+- Create a plan with short 1-sentence steps (5-7 words each)
+- Mark steps `in_progress` when starting, `completed` when done
+- There should always be exactly one `in_progress` step until everything is done

package/src/prompts/src/providers/google.txt

@@ -234,6 +234,7 @@ Your core function is efficient and safe assistance. Balance extreme conciseness
 **Pre-Flight Checklist (EVERY call):**
 Before calling `apply_patch`, verify ALL of these:
 - [ ] File was read with `read` tool in THIS turn (not from memory)
+- [ ] Checked the `indentation` field in the read response (e.g., "tabs", "2 spaces") to know the file's indent style
 - [ ] Context lines (space prefix) copied EXACTLY character-for-character from the read output
 - [ ] Indentation verified (if file uses tabs, patch uses tabs; if spaces, same count of spaces)
 - [ ] Wrapped in `*** Begin Patch` and `*** End Patch` markers

package/src/prompts/src/providers/moonshot.txt

@@ -69,6 +69,7 @@ You have access to a rich set of specialized tools optimized for coding tasks:
 
 **Using the `apply_patch` Tool** (Recommended):
 - **CRITICAL**: ALWAYS read the target file immediately before creating a patch - never patch from memory
+- The `read` tool returns an `indentation` field (e.g., "tabs", "2 spaces") — use it to match the file's indent style in your patch
 - Primary choice for targeted file edits - avoids rewriting entire files
 - Preferred format is the enveloped patch (`*** Begin Patch` ...); standard unified diffs (`---/+++`) are also accepted and auto-converted if provided
 - Only requires the specific lines you want to change
@@ -243,6 +244,50 @@ You are a coding agent. Keep going until the query is completely resolved before
 
 Your powerful reasoning can cause you to "improve" or "reconstruct" code from memory rather than copying it exactly. This is the #1 cause of patch failures. Always defer to the actual file content — it is the source of truth, not your training data.
 
+### Common Failure Patterns (Learn From These)
+
+**Failure 1 — Missing `+` prefix on new lines:**
+New lines intended as additions were written WITHOUT `+` prefix, so the tool
+treated them as context and tried to find them in the file — instant failure.
+```
+❌ WRONG:
+*** Update File: types.ts
+@@ Add new interface
+ export const API_VERSION = "v1";
+   field: keyof T;          ← Missing + prefix! Tool looks for this in file!
+   required: boolean;       ← Same problem!
+
+✅ RIGHT:
+*** Update File: types.ts
+@@ Add new interface
+ export const API_VERSION = "v1";
++  field: keyof T;
++  required: boolean;
+```
+
+**Failure 2 — Non-contiguous lines in one hunk:**
+A hunk tried to span from line ~67 to line ~73 but the lines between them
+didn't match because they weren't actually adjacent in the file. Each hunk
+MUST be a contiguous block. Use separate `@@` hunks for non-adjacent regions.
+
+**Failure 3 — Mixing unified diff headers inside enveloped format:**
+Using `--- a/file` / `+++ b/file` inside `*** Begin Patch` causes the tool
+to interpret `-- a/file` as a removal line. NEVER mix the two formats.
+
+**Failure 4 — Ambitious multi-section patches:**
+Trying to insert 20+ new lines AND modify existing lines far apart in one
+hunk fails. The fix: break it into small, focused patches — one contiguous
+region per hunk.
+
+### The Recovery Strategy That Works
+
+When a patch fails, do NOT retry the same approach. Instead:
+1. **Simplify drastically** — reduce to the absolute minimum change
+2. **Re-read the exact lines** you need (use startLine/endLine)
+3. **Copy context verbatim** from the fresh read output
+4. **Patch only one contiguous block** per hunk
+5. If it fails twice more, switch to `edit` tool (fuzzy matching)
+
 **Pre-Flight Checklist (EVERY call):**
 Before calling `apply_patch`, verify ALL of these:
 - [ ] File was read with `read` tool in THIS turn (not from memory)
@@ -251,6 +296,9 @@ Before calling `apply_patch`, verify ALL of these:
 - [ ] Wrapped in `*** Begin Patch` and `*** End Patch` markers
 - [ ] Used correct directive: `*** Add/Update/Delete File: path`
 - [ ] `-` removal lines match the file EXACTLY (not what you think they should be)
+- [ ] Each hunk covers ONE contiguous block — no gaps
+- [ ] Every new line has `+`, every removed line has `-`, every kept line has ` ` (space)
+- [ ] NOT mixing `--- a/` unified diff headers inside enveloped `*** Begin Patch` format
 
 **Concrete WRONG vs RIGHT — Indentation:**
 ```
@@ -266,14 +314,84 @@ File (10 spaces):           - os: linux
 ✅ RIGHT (10 spaces):           - os: linux
 ```
 
+**Concrete WRONG vs RIGHT — Contiguity:**
+```
+❌ WRONG — one hunk spanning non-adjacent regions:
+*** Update File: README.md
+ some line from section A (line 67)
+
+ ## Build Targets        ← line 73, but lines 68-72 are missing!
+
+✅ RIGHT — two separate hunks:
+*** Update File: README.md
+@@ section A
+ some line from section A (line 67)
++new content after section A
+@@ section B
+ ## Build Targets
+-old target list
++new target list
+```
+
+**Concrete RIGHT — Small surgical patch (this is the ideal):**
+```
+*** Begin Patch
+*** Update File: apps/desktop/README.md
+ ## Build Targets
+ 
+-- macOS: `.dmg`, `.app`
+-- Linux: `.AppImage`
+-- Windows: `.trash`
++- **macOS**: `.dmg`, `.app`
++- **Linux**: `.AppImage`
++- **Windows**: `.msi` (coming soon)
+*** End Patch
+```
+Small, surgical, one contiguous region. This pattern succeeds reliably.
+
+**Concrete RIGHT — Tab-indented TypeScript with two hunks:**
+```
+*** Begin Patch
+*** Update File: src/capture.ts
+@@ after MUTATING_TOOLS constant
+ const MUTATING_TOOLS = new Set(['write', 'apply_patch', 'edit']);
+ 
++const RETRYABLE_ERRORS = new Set([
++	'ECONNREFUSED',
++	'ETIMEDOUT',
++]);
++
+ export async function runAskStreamCapture(
+@@ stream URL
+   const sse = await connectSSE(
+-		`${baseUrl}/v1/sessions/${id}/stream?project=${proj}`,
++		`${baseUrl}/v1/sessions/${id}/stream?project=${proj}&format=sse`,
+   );
+*** End Patch
+```
+Two non-adjacent edits, one patch call, tabs preserved.
+
 **YAML Extra Caution:**
 - YAML uses spaces ONLY — count the exact spaces from `read` output
 - Include 3+ context lines for YAML patches
+- GitHub Actions workflows use 2-space indent; shell content in `run: |` blocks is indented further
 - If unsure, use `write` to rewrite the YAML file
 
+**TypeScript Caution:**
+- Check the `indentation` field from `read` — could be tabs OR spaces depending on the project
+- Template literals with `${}` are fine in patches
+- Match tabs character-for-character — do not substitute spaces
+
+**Markdown Caution:**
+- No indentation concerns for top-level content
+- Be careful with trailing whitespace on blank lines
+- List items and code blocks have their own indentation rules
+
 **If Patch Fails:**
 - Error = context didn't match OR file content changed
-- Solution: Read file AGAIN, verify context character-by-character
+- Step 1: Read file AGAIN with `read` tool (use startLine/endLine to get just the relevant section)
+- Step 2: Copy context lines VERBATIM from fresh read — do NOT retype from memory
+- Step 3: Reduce the patch to the MINIMUM change (2-3 context lines, one contiguous block)
 - After 2+ failures: switch to `edit` tool — it uses fuzzy matching and tolerates whitespace/indentation mismatches
 - If `edit` also fails: use `write` tool to rewrite the entire file instead
 

package/src/prompts/src/providers/openai.txt

@@ -384,6 +384,7 @@ GPT-4 models (especially GPT-4o) often fail patches by:
 
 **Pre-Flight Checklist (EVERY call):**
 - [ ] Read the target file with `read` tool in THIS turn
+- [ ] Check the `indentation` field in the read response (e.g., "tabs", "2 spaces") to know the file's indent style
 - [ ] Copy context lines EXACTLY from what you just read
 - [ ] Verify indentation (spaces vs tabs) matches the file
 - [ ] Include `*** Begin Patch` and `*** End Patch` markers

package/src/prompts/src/providers.ts

@@ -18,6 +18,8 @@ import PROVIDER_GOOGLE from './providers/google.txt' with { type: 'text' };
 import PROVIDER_MOONSHOT from './providers/moonshot.txt' with { type: 'text' };
 // eslint-disable-next-line @typescript-eslint/consistent-type-imports
 import PROVIDER_DEFAULT from './providers/default.txt' with { type: 'text' };
+// eslint-disable-next-line @typescript-eslint/consistent-type-imports
+import PROVIDER_GLM from './providers/glm.txt' with { type: 'text' };
 
 function sanitizeModelId(modelId: string): string {
 	return modelId
@@ -98,7 +100,9 @@ export async function providerBasePrompt(
 							? PROVIDER_GOOGLE
 							: family === 'moonshot'
 								? PROVIDER_MOONSHOT
-								: PROVIDER_DEFAULT
+								: family === 'glm'
+									? PROVIDER_GLM
+									: PROVIDER_DEFAULT
 			).trim();
 			promptType = `family:${family} (via ${id}/${modelId})`;
 			debugLog(`[provider] prompt: ${promptType} (${result.length} chars)`);
@@ -127,6 +131,11 @@ export async function providerBasePrompt(
 		debugLog(`[provider] prompt: moonshot (${result.length} chars)`);
 		return { prompt: result, resolvedType: 'moonshot' };
 	}
+	if (id === 'zai' || id === 'zai-coding') {
+		result = PROVIDER_GLM.trim();
+		debugLog(`[provider] prompt: glm (${result.length} chars)`);
+		return { prompt: result, resolvedType: 'glm' };
+	}
 
 	// If a project adds a custom provider file, allow reading it from disk (user-defined)
 	const providerPath = `src/prompts/providers/${id}.txt`;

package/src/providers/src/env.ts

@@ -9,7 +9,7 @@ const ENV_VARS: Record<ProviderId, string> = {
 	copilot: 'GITHUB_TOKEN',
 	setu: 'SETU_PRIVATE_KEY',
 	zai: 'ZAI_API_KEY',
-	'zai-coding': 'ZAI_API_KEY',
+	'zai-coding': 'ZAI_CODING_API_KEY',
 	moonshot: 'MOONSHOT_API_KEY',
 };
 

package/src/providers/src/utils.ts

@@ -124,6 +124,7 @@ export type UnderlyingProviderKey =
 	| 'openai'
 	| 'google'
 	| 'moonshot'
+	| 'glm'
 	| 'openai-compatible'
 	| null;
 
@@ -137,6 +138,8 @@ export function getUnderlyingProviderKey(
 	if (provider === 'moonshot') return 'moonshot';
 	if (provider === 'copilot') return 'openai';
 
+	if (provider === 'zai' || provider === 'zai-coding') return 'glm';
+
 	const npm = getModelNpmBinding(provider, model);
 	if (npm === '@ai-sdk/anthropic') return 'anthropic';
 	if (npm === '@ai-sdk/openai') return 'openai';
@@ -156,6 +159,7 @@ export function getModelFamily(
 	if (provider === 'google') return 'google';
 	if (provider === 'moonshot') return 'moonshot';
 	if (provider === 'copilot') return 'openai';
+	if (provider === 'zai' || provider === 'zai-coding') return 'glm';
 
 	// 2) For aggregate providers, infer from model ID patterns
 	if (provider === 'openrouter' || provider === 'opencode') {
@@ -180,6 +184,13 @@ export function getModelFamily(
 		if (lowerModel.includes('kimi') || lowerModel.startsWith('moonshotai/')) {
 			return 'moonshot';
 		}
+		if (
+			lowerModel.includes('glm') ||
+			lowerModel.startsWith('z-ai/') ||
+			lowerModel.startsWith('thudm/')
+		) {
+			return 'glm';
+		}
 	}
 
 	// 2) Check model's family field in catalog

package/src/providers/src/zai-client.ts

@@ -32,7 +32,7 @@ export function createZaiCodingModel(
 	const baseURL = entry?.api || 'https://api.z.ai/api/coding/paas/v4';
 	const apiKey =
 		config?.apiKey ||
-		process.env.ZAI_API_KEY ||
+		process.env.ZAI_CODING_API_KEY ||
 		process.env.ZHIPU_API_KEY ||
 		'';
 	const headers = apiKey ? { Authorization: `Bearer ${apiKey}` } : undefined;