fix: build.gradle 使用 npm 而非 npm.cmd

[Lin-wool]

User description

Summary

• 修复 build.gradle 中的命令，从 npm.cmd 改为 npm

Changes

• installWebviewDependencies 任务: npm.cmd → npm
• buildWebview 任务: npm.cmd → npm

Test plan

• 验证构建正常通过

---

PR Type

Enhancement

---

Description

• Add quota error detection in ChatService.kt for insufficient quota, billing, and payment-related errors

• Redesign ErrorBanner component with custom styled UI supporting config, quota, network, and runtime error types

• Add retry functionality that preserves user message and context for failed requests

• Introduce new CSS styling for error banner with distinct color schemes per error type

---

Diagram Walkthrough

flowchart LR
  A[ChatService] -->|quota error| B((Classify Error))
  B -->|type: quota| C[BridgeErrorPayload]
  C -->|display| D[ErrorBanner Component]
  D -->|action: retry| E[Retry with last message]
  D -->|action: openSettings| F[Open Settings]

Loading

File Walkthrough

Relevant files

Enhancement

ChatService.kt Add quota error detection in stream error classification  src/main/kotlin/com/github/codeplangui/ChatService.kt Add new quota error classification in classifyStreamError() for handling insufficient quota, billing, and payment-related errors Detects keywords like "insufficient_quota", "quota", "billing", "credit", "payment", and Chinese variations Returns BridgeErrorPayload with type "quota" and action "openSettings" +6/-0      App.tsx Add error action handling and retry logic                                webview/src/App.tsx Add lastUserMessageRef to store user message for retry functionality Update handleSend to properly set error type based on connection state Add handleErrorAction callback to handle openSettings and retry actions Pass onAction prop to ErrorBanner component +26/-2    ErrorBanner.tsx Redesign ErrorBanner with custom styling and actions          webview/src/components/ErrorBanner.tsx Completely redesign error banner with custom UI instead of using AntD Alert Add distinct icons and labels for config, quota, network, and runtime error types Add styled action buttons for "打开设置" (open settings) and "重试" (retry) Update component to accept optional onAction prop for handling button clicks +81/-20  bridge.d.ts Add quota error type to BridgeError interface                        webview/src/types/bridge.d.ts Add 'quota' as a new error type option in BridgeError interface Now supports: 'config' | 'quota' | 'network' | 'runtime' +1/-1      ErrorBanner.css Add custom CSS styles for error banner component                  webview/src/components/ErrorBanner.css Create new CSS file with custom styling for error banner Define distinct color schemes: amber for config, gold for quota, blue for network, red for runtime Add styles for icon container, header, message, close button, and action buttons Include hover effects and transitions for better UX +161/-0

---

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Retry missing send call In handleErrorAction (lines 164-173), when retrying, the code adds the user's message to the groups state but never actually calls window.__bridge?.sendMessage(). The message is displayed in the UI but won't be sent to the backend. The code at line 172 does call sendMessage, but the flow should be verified - currently it adds the message and immediately calls sendMessage, which may result in duplicate messages or the sendMessage using stale state. } else if (action === 'retry' && lastUserMessageRef.current) { const msg = lastUserMessageRef.current const userMsgId = uuidv4() setAppState(prev => ({ ...prev, groups: [...prev.groups, { type: 'human' as const, id: userMsgId, message: { id: userMsgId, content: msg.text } }], error: null, })) window.__bridge?.sendMessage(msg.text, msg.includeContext) }

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Add loading check to prevent duplicate retry requests When retrying a message, the user won't see any loading indicator since isLoading is not set to true. This can confuse users who might repeatedly click the retry button. Consider setting a loading state or disabling the retry button to prevent duplicate requests while the message is being sent. webview/src/App.tsx [160-174] const handleErrorAction = useCallback((action: 'openSettings' | 'retry') => { if (action === 'openSettings') { window.__bridge?.openSettings() setAppState(prev => ({ ...prev, error: null })) -} else if (action === 'retry' && lastUserMessageRef.current) { +} else if (action === 'retry' && lastUserMessageRef.current && !isLoading) { const msg = lastUserMessageRef.current const userMsgId = uuidv4() setAppState(prev => ({ ...prev, groups: [...prev.groups, { type: 'human' as const, id: userMsgId, message: { id: userMsgId, content: msg.text } }], error: null, + // Optionally set loading state here if needed })) window.__bridge?.sendMessage(msg.text, msg.includeContext) } -}, []) +}, [isLoading]) Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies that the retry functionality lacks a loading state check, which could lead to duplicate requests if users click retry multiple times. Adding !isLoading condition and [isLoading] dependency is a valid improvement for preventing race conditions.	Medium