docs : 更新文档CLAUDE.md

CLAUDE.md

@@ -10,34 +10,16 @@
 - 处理业务时，需要同时考虑兜底机制和业务自定义错误捕获；
 - 所有设计思路、代码实现均需要考虑以上三个条件。
 
-# 架构约定
+# 相关文档说明
 
-## 任务状态轮询
-
-- **两层轮询 + Context 桥接**：`useTaskPolling`（批量轮询 `batchTaskStatus`）负责广度覆盖，`OutputPreview` 通过 `selectedTask.status` 变化检测终态转换后触发 `refetch()` 获取详情——二者通过 Context 同步，避免重复请求。
-- **非终态统一管理**：`POLLING_STATUSES = ['pending', 'submitted', 'processing']` 定义在 `task.ts`，所有轮询逻辑引用此常量。
-- **自适应间隔**：递归 `setTimeout`（非 `setInterval`）+ 服务端 `next_poll_ms`，本地 clamp 2s~30s，出错 10s 重试。
-- **useRef 打破闭包陷阱**：`mergedRef.current` 确保递归回调读到最新任务列表。
-
-## Token 刷新
-
-- **双轨刷新**：主动刷新（`scheduleProactiveRefresh`）在 JWT `exp` 的 75% 时间点通过 `setTimeout` 提前续期；被动刷新（`handle401` → `refreshHandler`）兜底。
-- **失败分级处理**：`refreshHandler` 永久失败（`RefreshTokenExpiredError`）→ throw → `handle401` 清 token + 弹登录；临时失败（网络超时）→ return null → 仅拒绝当前请求，不登出。
-- **JWT 解码驱动定时器**：从 `atob(token.split('.')[1])` 取 `exp` 声明，无需额外持久化 `expires_in`。
-- **刷新接口隔离**：`/api/v1/auth/refresh` 在 `request.ts` 中特殊处理（`isRefreshRequest`），防止 401→刷新→401 死循环。
-
-## 文件上传
-
-- **customRequest 集成模式**：`useFileUpload` hook 封装 `request.upload()`，返回 antd Upload 兼容的 `customRequest`——避免直接设 `action` 导致 Token 缺失，复用全局拦截器的认证和错误处理。
-- **beforeUpload 语义修正**：校验通过返回 `true`（放行至 `customRequest`），失败返回 `Upload.LIST_IGNORE`。
-
-## 表单提交
-
-- **两级防护**：防抖（2s 节流，"你点击的太快了"）+ 二次确认（`Modal.confirm`，"您已提交，确认要再次提交吗？"）。
-- **useRef 存储时序状态**：`lastClickTimeRef` / `submitCountRef` 避免不必要的重渲染。
-- **useAsyncMutation 返回值判空**：`execute()` 内部 catch 所有错误返回 `undefined`，调用方应检查返回值而非 try/catch。
-
-## GET 数组参数
-
-- **逗号拼接优于 bracket 序列化**：`task_ids=a,b,c` 比 `task_ids[]=a&task_ids[]=b` 更具跨框架兼容性，避免 axios 默认 `paramsSerializer` 的 PHP/Rack 风格。
+- 根目录下的文档包括：
+  - README.md（git中的README文档），
+  - WORKLOG.md（工作日志文档），
+  - UpdateA.md（热更新相关的文档），
+  - TODO.md（未完善、未来要做的文档，或者是在开发中遇到需要优化的地方），
+  - PROJECT.md（项目文档），
+  - CHANGELOG.md（版本更新文档），
+  - CLAUDE.md
+- 永远不要修改CLAUDE.md文档
+- 在各个文档中的更新需要保持精简。且职责划分保持严谨，除了架构、项目文档，已完成的事需要从TODO.md文档中移除。