feat(pipe): release v0.6.2 - full-lifecycle file agent support

.github/copilot-instructions.md

@@ -481,6 +481,60 @@ async def get_user_language(self):
 
 **注意**: 即使插件有 `Valves` 配置，也应优先尝试自动探测，提升用户体验。
 
+### 8. 智能代理文件交付规范 (Agent File Delivery Standards)
+
+在开发具备文件生成能力的智能代理插件（如 GitHub Copilot SDK 集成）时，必须遵循以下标准流程，以确保文件在不同存储后端（本地/S3）下的可用性并绕过不必要的 RAG 处理。
+
+#### 核心协议：三步交付法 (The 3-Step Delivery Protocol)
+
+1.  **本地写入 (Write Local)**:
+    - 代理必须在当前执行目录 (`.`) 下创建文件。
+    - **严禁**使用系统临时目录（如 `/tmp`）存放待发布的文件，因为这些路径在隔离的工作空间外不可见。
+2.  **显式发布 (Publish)**:
+    - 必须调用内建工具 `publish_file_from_workspace(filename='name.ext')`。
+    - 该工具负责将文件迁移至 Open WebUI 正式存储（自动适配 S3），并注入 `skip_rag` 元数据以防止触发向量化流程（RAG Bypass）。
+3.  **呈现链接 (Display Link)**:
+    - 获取工具返回的 `download_url`（正确格式为 `/api/v1/files/{id}/content`）。
+    - **必须**以 Markdown 链接形式（如 `[点击下载报告](url)`）展示给用户。
+
+#### 路径语义 (Path Semantics)
+- 代理应始终将“当前目录”视为其受保护所在的私有工作空间。
+- `publish_file_from_workspace` 的参数 `filename` 仅需传入相对于当前目录的文件名。
+
+### 9. Copilot SDK 插件工具定义规范 (Copilot SDK Tool Definition Standards)
+
+在为 GitHub Copilot SDK 开发自定义工具时，为了确保大模型能正确识别参数（避免生成空的 `properties` Schema），必须遵循以下定义模式：
+
+#### 显式参数模型 (Explicit Parameter Schema)
+**禁止**仅依赖函数签名和类型提示。**必须**定义一个继承自 `pydantic.BaseModel` 的类来描述参数，并在 `define_tool` 中通过 `params_type` 显式引用。
+
+```python
+from pydantic import BaseModel, Field
+from copilot import define_tool
+
+# 1. 定义参数模型
+class MyToolParams(BaseModel):
+    query: str = Field(..., description="搜索关键词")
+    limit: int = Field(default=10, description="返回结果数量限制")
+
+# 2. 实现工具逻辑
+async def my_custom_search(query: str, limit: int) -> dict:
+    # ... 逻辑实现 ...
+    return {"results": []}
+
+# 3. 注册工具（关键：使用 params_type）
+my_tool = define_tool(
+    name="my_custom_search",
+    description="在特定数据源中执行搜索",
+    params_type=MyToolParams,  # 显式传递参数模型以生成正确的 JSON Schema
+)(my_custom_search)
+```
+
+#### 关键要点 (Key Requirements)
+1.  **params_type**: 必须在 `define_tool` 中使用此参数。这是防止大模型幻觉认为工具“无参数”的唯一可靠方法。
+2.  **Field 描述**: 在 `BaseModel` 中使用 `Field(..., description="...")` 为每个参数提供详细的描述信息。
+3.  **Required vs Optional**: 明确标注必填项（无默认值）和可选项（带 `default`）。
+
 ---
 
 ## ⚡ Action 插件规范 (Action Plugin Standards)
@@ -928,10 +982,19 @@ Filter 实例是**单例 (Singleton)**。
 - Update README/README_CN to include What's New section
 - Migration: default TITLE_SOURCE changed to chat_title
 
-### 4. 🤖 Git Operations (Agent Rules)
+#### 发布信息生成准则 (Release Summary Generation)
+当准备提交时，必须向用户展示以下格式的“发布草案”：
+1. **Commit Message**: 符合 Conventional Commits 的英文标题及摘要。
+2. **变更列表 (Bilingual Changes)**: 
+   - 英文: Clear descriptions of technical/functional changes.
+   - 中文: 清晰描述用户可见的功能改进或修复。
+3. **核查状态 (Verification)**: 确认版本号已在相关 8+ 处位置同步更新。
 
-- **允许**: 直接推送到 `main` 分支并发布。
-- **允许**: 创建功能分支 (`feature/xxx`)，推送到功能分支。
+### 4. 🤖 Git 提交与推送规范 (Git Operations & Push Rules)
+
+- **核心原则**: 默认仅进行**本地文件准备**（更新代码、READMEs、Docs、版本号），**严禁**在未获用户明确许可的情况下自动执行 `git commit` 或 `git push`。
+- **允许 (需确认)**: 只有在用户明确表示“发布”、“Commit it”、“Release”或“提交”后，才允许直接推送到 `main` 分支或创建 PR。
+- **功能分支**: 推荐在进行大规模重构或实验性功能开发时，创建功能分支 (`feature/xxx`) 进行隔离。
 
 ### 5. 🤝 贡献者认可规范 (Contributor Recognition)