update reload funtion

MEMORY.md

@@ -1,6 +1,71 @@
 # MEMORY.md
 
-## 2026-03-17 - GAIA_BL01 部署错误修复
+## 2026-03-17 - GAIA_BL01 部署错误修复（更新）
+
+### 遇到什么问题
+
+- 用户点击部署时，如果存在未修改的文件（status: "unchanged"），会报错：`[404] [GAIA_BL01] 指定したファイル（id: XXXXX）が見つかりません。`
+- **之前分析不够准确**：原匹配逻辑只用文件名匹配，如果存在同名文件会匹配到错误的 fileKey
+
+### 根本原因（更正）
+
+1. **匹配逻辑缺陷**：只用文件名匹配，同名文件会返回第一个匹配的错误 fileKey
+2. **类型守卫过于严格**：`isFileResource()` 要求 `fileKey` 存在才返回 true，可能导致有效文件被跳过
+3. Kintone Customization API 的正确用法：
+   - 从 `Get Customization` 获取的 fileKey 是实时有效的
+   - 只要文件附加到 Customization，fileKey 就永久有效
+   - 参考：https://docs-customine.gusuku.io/en/error/gaia_bl01/
+
+### 如何解决的
+
+修改 `src/main/ipc-handlers.ts` 中的匹配逻辑：
+
+1. **新增 `isFileType()` 类型守卫**：只检查 `type === "FILE"`，不要求 `fileKey` 存在
+2. **实现三级匹配策略**：
+   - 优先级 1：用前端传来的 `fileKey` 精确匹配（最可靠）
+   - 优先级 2：用 URL 精确匹配（针对 URL 类型）
+   - 优先级 3：用文件名匹配（fallback，同名文件可能出错）
+3. 添加详细调试日志和验证检查
+
+```typescript
+// 新增类型守卫
+function isFileType(resource): boolean {
+  return resource.type === "FILE" && !!resource.file;
+}
+
+// 三级匹配策略
+if (file.fileKey) {
+  matchingFile = currentFiles?.find(
+    (f) => isFileType(f) && f.file.fileKey === file.fileKey,
+  );
+}
+if (!matchingFile && file.url) {
+  matchingFile = currentFiles?.find(
+    (f) => isUrlResource(f) && f.url === file.url,
+  );
+}
+if (!matchingFile) {
+  matchingFile = currentFiles?.find(
+    (f) => isFileType(f) && f.file.name === file.fileName,
+  );
+}
+```
+
+### 以后如何避免
+
+1. **匹配逻辑优先使用唯一标识符**：不要只用名称匹配，优先使用 ID、key 等唯一标识
+2. **类型守卫要区分"类型检查"和"有效性验证"**：
+   - 类型检查：`type === "FILE"`
+   - 有效性验证：`fileKey` 是否存在
+   - 这两个应该分开处理
+3. **Kintone fileKey 的生命周期**：
+   - 用于 Customization：永久有效（只要附加到 App）
+   - 用于记录附件：3 天内必须使用
+4. **添加调试日志**：在复杂的匹配逻辑中添加调试日志，便于排查问题
+
+---
+
+## 2026-03-17 - GAIA_BL01 部署错误修复（初始记录 - 已过时）
 
 ### 遇到什么问题
 
@@ -27,7 +92,6 @@
 
 ---
 
-
 # MEMORY.md
 
 ## 2026-03-15 - CSS 模板字符串语法错误