@jsonstudio/rcc 0.90.876 → 0.90.1270

package/docs/mapping-tables/openai-to-iflow.json

@@ -1,227 +0,0 @@
-{
-  "version": "1.0.0",
-  "description": "OpenAI to iFlow compatibility mapping table based on Claude Code Router architecture",
-  "formats": {
-    "source": "openai",
-    "target": "iflow"
-  },
-  "metadata": {
-    "created": "2024-01-01T00:00:00Z",
-    "updated": "2024-01-01T00:00:00Z",
-    "author": "RCC System",
-    "architecture": "agent-based",
-    "basedOn": "claude-code-router"
-  },
-  "fieldMappings": {
-    "id": {
-      "targetField": "taskId",
-      "transform": "directMapping",
-      "required": true,
-      "description": "Map OpenAI request ID to iFlow task ID"
-    },
-    "model": {
-      "targetField": "agentId",
-      "transform": "mapModelToAgent",
-      "required": true,
-      "description": "Map OpenAI model to iFlow agent ID"
-    },
-    "messages": {
-      "targetField": "messages",
-      "transform": "messageFormatConversion",
-      "required": true,
-      "description": "Convert OpenAI message format to iFlow message format"
-    },
-    "tools": {
-      "targetField": "tools",
-      "transform": "toolFormatConversion",
-      "description": "Convert OpenAI tool format to iFlow tool format"
-    },
-    "tool_choice": {
-      "targetField": "tool_choice",
-      "transform": "toolChoiceConversion",
-      "defaultValue": "auto",
-      "description": "Tool choice strategy"
-    },
-    "temperature": {
-      "targetField": "temperature",
-      "transform": "directMapping",
-      "defaultValue": 0.7,
-      "description": "Temperature parameter for response randomness"
-    },
-    "max_tokens": {
-      "targetField": "maxTokens",
-      "transform": "directMapping",
-      "description": "Maximum number of tokens to generate"
-    },
-    "top_p": {
-      "targetField": "parameters.top_p",
-      "transform": "directMapping",
-      "defaultValue": 1.0,
-      "description": "Nucleus sampling parameter"
-    },
-    "frequency_penalty": {
-      "targetField": "parameters.frequency_penalty",
-      "transform": "directMapping",
-      "defaultValue": 0.0,
-      "description": "Frequency penalty for token repetition"
-    },
-    "presence_penalty": {
-      "targetField": "parameters.presence_penalty",
-      "transform": "directMapping",
-      "defaultValue": 0.0,
-      "description": "Presence penalty for new topics"
-    },
-    "stop": {
-      "targetField": "parameters.stop",
-      "transform": "arrayMapping",
-      "description": "Stop sequences for generation"
-    },
-    "stream": {
-      "targetField": "streaming",
-      "transform": "directMapping",
-      "defaultValue": false,
-      "description": "Enable streaming response"
-    },
-    "user": {
-      "targetField": "userId",
-      "transform": "mapUserId",
-      "description": "User identifier"
-    },
-    "metadata": {
-      "targetField": "metadata",
-      "transform": "extractMetadata",
-      "description": "Extract and map metadata fields"
-    }
-  },
-  "validationRules": {
-    "required": ["id", "model", "messages"],
-    "types": {
-      "id": "string",
-      "model": "string",
-      "messages": "array",
-      "temperature": "number",
-      "max_tokens": "number",
-      "top_p": "number",
-      "frequency_penalty": "number",
-      "presence_penalty": "number",
-      "stream": "boolean",
-      "user": "string",
-      "tools": "array",
-      "tool_choice": "string",
-      "streaming": "boolean",
-      "maxTokens": "number",
-      "userId": "string",
-      "taskId": "string",
-      "agentId": "string"
-    },
-    "constraints": {
-      "id": {
-        "pattern": "^[a-zA-Z0-9-_]+$",
-        "minLength": 1,
-        "maxLength": 100
-      },
-      "model": {
-        "pattern": "^[a-zA-Z0-9-_]+$",
-        "minLength": 1,
-        "maxLength": 100
-      },
-      "messages": {
-        "minLength": 1,
-        "maxLength": 100
-      },
-      "max_tokens": {
-        "min": 1,
-        "max": 200000
-      },
-      "temperature": {
-        "min": 0.0,
-        "max": 2.0
-      },
-      "top_p": {
-        "min": 0.0,
-        "max": 1.0
-      },
-      "frequency_penalty": {
-        "min": -2.0,
-        "max": 2.0
-      },
-      "presence_penalty": {
-        "min": -2.0,
-        "max": 2.0
-      }
-    }
-  },
-  "transformFunctions": {
-    "mapModelToAgent": {
-      "type": "mapping",
-      "description": "Map OpenAI models to iFlow agent IDs",
-      "mappings": {
-        "gpt-4o": "multimodal-agent",
-        "gpt-4o-mini": "text-agent",
-        "gpt-4-turbo": "reasoning-agent",
-        "gpt-4": "analysis-agent",
-        "gpt-3.5-turbo": "chat-agent",
-        "gpt-4-vision-preview": "image-agent",
-        "claude-3-5-sonnet-20241022": "reasoning-agent",
-        "claude-3-5-haiku-20241022": "text-agent"
-      },
-      "defaultValue": "text-agent"
-    },
-    "messageFormatConversion": {
-      "type": "object_transform",
-      "description": "Convert OpenAI message format to iFlow format",
-      "roleMapping": {
-        "system": "system",
-        "user": "user", 
-        "assistant": "assistant",
-        "tool": "tool"
-      },
-      "contentProcessing": {
-        "preserveStructure": true,
-        "handleMultimodal": true,
-        "agentContentHandling": true
-      }
-    },
-    "toolFormatConversion": {
-      "type": "array_transform",
-      "description": "Convert OpenAI tool format to iFlow tool format",
-      "elementTransform": {
-        "type": "object_transform",
-        "fields": {
-          "type": "type",
-          "function": "function"
-        },
-        "preserveStructure": true,
-        "agentToolSchema": true
-      }
-    },
-    "toolChoiceConversion": {
-      "type": "mapping",
-      "description": "Convert OpenAI tool choice to iFlow tool choice",
-      "mappings": {
-        "auto": "auto",
-        "none": "none",
-        "required": "required"
-      }
-    },
-    "mapUserId": {
-      "type": "transform",
-      "description": "Format OpenAI user ID to iFlow format",
-      "transformFunction": "formatUserId"
-    },
-    "extractMetadata": {
-      "type": "object_transform",
-      "description": "Extract metadata from OpenAI request",
-      "extractFields": ["session_info", "timeout", "priority", "context"]
-    },
-    "directMapping": {
-      "type": "direct",
-      "description": "No transformation needed - pass through as-is"
-    },
-    "arrayMapping": {
-      "type": "array_transform",
-      "description": "Convert array format for iFlow compatibility",
-      "preserveElements": true
-    }
-  }
-}

package/docs/multi-token-auth-guide.md

@@ -1,66 +0,0 @@
-# Multi-Token Authentication Guide
-
-RouteCodex now supports multiple OAuth tokens per provider using a standardized naming convention.
-
-## Token File Naming Convention
-
-Token files must follow the pattern: `<provider>-oauth-<sequence>[-<alias>].json`
-
-Examples:
-- `iflow-oauth-1-primary.json` (sequence 1, alias "primary")
-- `iflow-oauth-2-backup.json` (sequence 2, alias "backup")
-- `qwen-oauth-1-work.json` (sequence 1, alias "work")
-
-The `sequence` number determines the order in which tokens are used (1, 2, 3...).
-The `alias` part is optional and ignored by the system - it's just for your reference.
-
-## Automatic Discovery
-
-The system automatically scans `~/.rcc/auth/` for token files matching the pattern and creates multiple provider instances. No manual configuration needed.
-
-## Authentication Commands
-
-### Authenticate specific token:
-```bash
-# Token 1
-IFLOW_TOKEN_FILE="$HOME/.rcc/auth/iflow-oauth-1-primary.json" node scripts/auth-iflow-token-direct.mjs
-
-# Token 2
-IFLOW_TOKEN_FILE="$HOME/.rcc/auth/iflow-oauth-2-backup.json" node scripts/auth-iflow-token-direct.mjs
-```
-
-### Manual authentication (if device flow fails):
-```bash
-IFLOW_TOKEN_FILE="$HOME/.rcc/auth/iflow-oauth-1-primary.json" node scripts/auth-iflow-manual.mjs
-```
-
-### Delete and re-authenticate:
-```bash
-rm ~/.rcc/auth/iflow-oauth-1-primary.json
-IFLOW_TOKEN_FILE="$HOME/.rcc/auth/iflow-oauth-1-primary.json" node scripts/auth-iflow-token-direct.mjs
-```
-
-## How It Works
-
-1. On startup, RouteCodex scans for all token files matching the pattern
-2. Each token becomes a separate provider instance with keyAlias = sequence number
-3. Routing automatically includes all available tokens in round-robin order
-4. If a token fails, the system tries the next one
-5. Console logs show which token sequence is being used
-
-## Troubleshooting
-
-- **Token fails**: The system will automatically try the next token in sequence
-- **Need to re-auth**: Delete the token file and run the auth command again
-- **Wrong redirect**: The OAuth callback now shows a success page instead of redirecting to example.com
-
-## Provider Support
-
-Currently the following providers support multi-token authentication:
-
-- iFlow (`iflow-oauth-*.json`)
-- Qwen (`qwen-oauth-*.json`)
-- Gemini CLI (`gemini-oauth-*.json`)
-- Antigravity (`antigravity-oauth-*.json`)
-
-Other providers will be added as needed.

package/docs/oauth-authentication-guide.md

@@ -1,172 +0,0 @@
-# ⚠️ 旧文档提示
-
-本文为历史/实现细节文档，**OAuth 最新统一说明请以 `docs/OAUTH.md` 为准**（包含认证、刷新、Camoufox auto、常见踩坑）。
-
-# Unified OAuth Authentication System Guide
-
-## Overview
-
-The Unified OAuth Authentication System provides a comprehensive solution for managing authentication across multiple AI service providers. It supports both static token files and dynamic OAuth 2.0 flows with automatic token refresh, PKCE security, and unified configuration management.
-
-## Architecture
-
-### Core Components
-
-1. **OAuthConfigManager** - Centralized configuration management
-2. **BaseOAuthManager** - Abstract base class for OAuth implementations
-3. **Provider-specific Managers** - QwenOAuthManager and iFlowOAuthManager
-4. **AuthResolver** - Unified token resolution supporting both static and OAuth
-5. **UserConfigParser** - Extended to support OAuth configuration parsing
-
-### Authentication Flow
-
-```
-Request → Provider → AuthResolver → OAuth Manager → Token Resolution → Response
-```
-
-## 🔐 iFlow OAuth 实现详解
-
-### 核心流程概述
-
-iFlow 的 OAuth 实现遵循 **"access_token → API Key → 实际请求"** 的两阶段模式：
-
-1. **OAuth 认证阶段**：获取 `access_token` 和 `refresh_token`
-2. **API Key 提取阶段**：用 `access_token` 调用 `getUserInfo` 获取真正的 `api_key`
-3. **业务请求阶段**：所有后续 API 调用都使用 `api_key` 作为 `Authorization: Bearer <api_key>`
-
-> ⚠️ **关键区别**：iFlow 的 `access_token` **只能**用来换取 API Key，**不能**直接作为鉴权凭证调用聊天完成接口。
-
-### 详细流程步骤
-
-#### 阶段1：OAuth 认证（获取 access_token）
-
-```
-用户授权 → 浏览器回调 → 授权码交换 → 获取 access_token + refresh_token
-```
-
-- **端点**：`https://iflow.cn/oauth/token`
-- **流程**：标准 OAuth 2.0 授权码流程或设备码流程
-- **输出**：`{ access_token, refresh_token, token_type, expires_in, scope }`
-
-#### 阶段2：API Key 提取（getUserInfo 调用）
-
-```
-access_token → getUserInfo → api_key + email
-```
-
-- **端点**：`https://iflow.cn/api/oauth/getUserInfo?accessToken=<token>`
-- **请求**：`GET` 请求，无额外 headers
-- **响应**：`{ success: true, data: { apiKey: "sk-xxx", email: "user@mail", phone: "+86..." } }`
-- **关键**：如果 `apiKey` 为空，整个流程失败（Fast-Fail 原则）
-
-#### 阶段3：业务 API 调用（使用 api_key）
-
-```
-api_key → Authorization: Bearer <api_key> → 聊天完成接口
-```
-
-- **端点**：`https://apis.iflow.cn/v1/chat/completions`
-- **鉴权**：`Authorization: Bearer sk-xxx`（**不是** access_token）
-- **模型**：默认 `kimi`，支持模型列表需查阅 iFlow 官方文档
-
-### 与 CLIProxyAPI 的对齐
-
-我们的实现完全对齐 CLIProxyAPI 的 Go 版本逻辑：
-
-| 步骤 | CLIProxyAPI (Go) | RouteCodex (TypeScript) |
-|------|------------------|-------------------------|
-| OAuth 认证 | `ExchangeCodeForTokens()` | `oauth-lifecycle.ts` 中的标准流程 |
-| 获取 API Key | `FetchUserInfo()` → `apiKey` | `fetchIFlowUserInfo()` → `api_key` |
-| 存储格式 | `IFlowTokenStorage` 结构体 | 相同字段名的 JSON 对象 |
-| 鉴权方式 | `Authorization: Bearer <api_key>` | 完全一致 |
-| 错误处理 | Fast-Fail，无隐藏回退 | 完全一致 |
-
-### 代码实现位置
-
-1. **OAuth 生命周期管理**：`src/providers/auth/oauth-lifecycle.ts`
-   - 在 `ensureValidOAuthToken()` 中，iFlow 认证成功后会自动调用 `fetchIFlowUserInfo()`
-   - 将返回的 `api_key` 和 `email` 合并到 token 数据中并重新保存
-
-2. **API Key 提取逻辑**：`src/providers/auth/iflow-userinfo-helper.ts`
-   - `fetchIFlowUserInfo()`：调用 `https://iflow.cn/api/oauth/getUserInfo`
-   - `mergeIFlowTokenData()`：将 OAuth token 与用户信息合并
-
-3. **认证提供者**：`src/providers/auth/tokenfile-auth.ts`
-   - `TokenFileAuthProvider.buildHeaders()`：优先使用 `api_key`，回退到 `access_token`
-
-4. **服务配置**：`src/providers/core/config/service-profiles.ts`
-   - iFlow 默认端点：`https://apis.iflow.cn/v1/chat/completions`
-   - 默认模型：`kimi`
-
-### 使用示例
-
-```typescript
-// 1. 配置 iFlow OAuth
-const iflowConfig = {
-  type: 'openai-standard',
-  config: {
-    providerType: 'iflow',
-    auth: {
-      type: 'oauth'
-      // 无需手动指定 clientId/secret，使用内置默认值
-    }
-  }
-};
-
-// 2. 首次使用会触发浏览器授权
-const provider = new ChatHttpProvider(iflowConfig, dependencies);
-await provider.initialize(); // → 打开浏览器 → 授权 → 获取 API Key
-
-// 3. 后续使用直接读取本地 token 文件
-// ~/.rcc/auth/iflow-oauth.json 包含：
-// {
-//   "access_token": "...",
-//   "refresh_token": "...",
-//   "api_key": "sk-xxx",      // ← 实际用于 API 调用
-//   "email": "user@mail.com",
-//   "type": "iflow"
-// }
-
-// 4. 正常调用模型
-const response = await provider.processIncoming({
-  model: 'kimi',
-  messages: [{ role: 'user', content: 'Hello iFlow!' }]
-});
-```
-
-### 故障排查
-
-| 问题 | 可能原因 | 解决方案 |
-|------|----------|----------|
-| `getaddrinfo ENOTFOUND iflow.cn` | DNS 解析失败 | 检查网络连接，确认 iFlow 服务状态 |
-| `empty api key returned` | getUserInfo 未返回 apiKey | 确认 iFlow 账户已开通 API 权限 |
-| `401 Unauthorized` | api_key 无效 | 重新走 OAuth 流程获取新的 api_key |
-| `40308` 业务错误 | 使用了 access_token 而非 api_key | 确认 TokenFileAuthProvider 正确读取了 api_key 字段 |
-
-### 环境变量
-
-- `IFLOW_CLIENT_ID`：覆盖默认 clientId（高级用法）
-- `IFLOW_CLIENT_SECRET`：覆盖默认 clientSecret（高级用法）
-
-> OAuth 认证流程现已强制在可用时自动打开浏览器完成授权，不再提供环境变量开关。
-
-# Unified OAuth Authentication System Guide
-
-## Overview
-
-The Unified OAuth Authentication System provides a comprehensive solution for managing authentication across multiple AI service providers. It supports both static token files and dynamic OAuth 2.0 flows with automatic token refresh, PKCE security, and unified configuration management.
-
-## Architecture
-
-### Core Components
-
-1. **OAuthConfigManager** - Centralized configuration management
-2. **BaseOAuthManager** - Abstract base class for OAuth implementations
-3. **Provider-specific Managers** - QwenOAuthManager and iFlowOAuthManager
-4. **AuthResolver** - Unified token resolution supporting both static and OAuth
-5. **UserConfigParser** - Extended to support OAuth configuration parsing
-
-### Authentication Flow
-
-```
-Request → Provider → AuthResolver → OAuth Manager → Token Resolution → Response

package/docs/oauth-iflow-implementation.md

@@ -1,157 +0,0 @@
-# ⚠️ 旧文档提示
-
-本文为历史/实现细节文档，**OAuth 最新统一说明请以 `docs/OAUTH.md` 为准**（包含认证、刷新、Camoufox auto、常见踩坑）。
-
-# OAuth Authentication Module - 详细实现文档
-
-## 🎯 概述
-
-本模块提供统一的OAuth 2.0认证实现，支持多种AI服务提供商（Qwen、iFlow等），遵循RouteCodex 9大核心架构原则。
-
-## 🔐 iFlow OAuth 实现详解
-
-### 核心流程概述
-
-iFlow 的 OAuth 实现遵循 **"access_token → API Key → 实际请求"** 的两阶段模式：
-
-1. **OAuth 认证阶段**：获取 `access_token` 和 `refresh_token`
-2. **API Key 提取阶段**：用 `access_token` 调用 `getUserInfo` 获取真正的 `api_key`
-3. **业务请求阶段**：所有后续 API 调用都使用 `api_key` 作为 `Authorization: Bearer <api_key>`
-
-> ⚠️ **关键区别**：iFlow 的 `access_token` **只能**用来换取 API Key，**不能**直接作为鉴权凭证调用聊天完成接口。
-
-### 详细流程步骤
-
-#### 阶段1：OAuth 认证（获取 access_token）
-
-```
-用户授权 → 浏览器回调 → 授权码交换 → 获取 access_token + refresh_token
-```
-
-- **端点**：`https://iflow.cn/oauth/token`
-- **流程**：标准 OAuth 2.0 授权码流程或设备码流程
-- **输出**：`{ access_token, refresh_token, token_type, expires_in, scope }`
-
-#### 阶段2：API Key 提取（getUserInfo 调用）
-
-```
-access_token → getUserInfo → api_key + email
-```
-
-- **端点**：`https://iflow.cn/api/oauth/getUserInfo?accessToken=<token>`
-- **请求**：`GET` 请求，无额外 headers
-- **响应**：`{ success: true, data: { apiKey: "sk-xxx", email: "user@mail", phone: "+86..." } }`
-- **关键**：如果 `apiKey` 为空，整个流程失败（Fast-Fail 原则）
-
-#### 阶段3：业务 API 调用（使用 api_key）
-
-```
-api_key → Authorization: Bearer <api_key> → 聊天完成接口
-```
-
-- **端点**：`https://apis.iflow.cn/v1/chat/completions`
-- **鉴权**：`Authorization: Bearer sk-xxx`（**不是** access_token）
-- **模型**：默认 `kimi`，支持模型列表需查阅 iFlow 官方文档
-
-### 与 CLIProxyAPI 的对齐
-
-我们的实现完全对齐 CLIProxyAPI 的 Go 版本逻辑：
-
-| 步骤 | CLIProxyAPI (Go) | RouteCodex (TypeScript) |
-|------|------------------|-------------------------|
-| OAuth 认证 | `ExchangeCodeForTokens()` | `oauth-lifecycle.ts` 中的标准流程 |
-| 获取 API Key | `FetchUserInfo()` → `apiKey` | `fetchIFlowUserInfo()` → `api_key` |
-| 存储格式 | `IFlowTokenStorage` 结构体 | 相同字段名的 JSON 对象 |
-| 鉴权方式 | `Authorization: Bearer <api_key>` | 完全一致 |
-| 错误处理 | Fast-Fail，无隐藏回退 | 完全一致 |
-
-### 代码实现位置
-
-1. **OAuth 生命周期管理**：`oauth-lifecycle.ts`
-   - 在 `ensureValidOAuthToken()` 中，iFlow 认证成功后会自动调用 `fetchIFlowUserInfo()`
-   - 将返回的 `api_key` 和 `email` 合并到 token 数据中并重新保存
-
-2. **API Key 提取逻辑**：`iflow-userinfo-helper.ts`
-   - `fetchIFlowUserInfo()`：调用 `https://iflow.cn/api/oauth/getUserInfo`
-   - `mergeIFlowTokenData()`：将 OAuth token 与用户信息合并
-
-3. **认证提供者**：`tokenfile-auth.ts`
-   - `TokenFileAuthProvider.buildHeaders()`：优先使用 `api_key`，回退到 `access_token`
-
-4. **服务配置**：`../config/service-profiles.ts`
-   - iFlow 默认端点：`https://apis.iflow.cn/v1/chat/completions`
-   - 默认模型：`kimi`
-
-## 📋 使用示例
-
-```typescript
-// 1. 配置 iFlow OAuth
-const iflowConfig = {
-  type: 'openai-standard',
-  config: {
-    providerType: 'iflow',
-    auth: {
-      type: 'oauth'
-      // 无需手动指定 clientId/secret，使用内置默认值
-    }
-  }
-};
-
-// 2. 首次使用会触发浏览器授权
-const provider = new ChatHttpProvider(iflowConfig, dependencies);
-await provider.initialize(); // → 打开浏览器 → 授权 → 获取 API Key
-
-// 3. 后续使用直接读取本地 token 文件
-// ~/.rcc/auth/iflow-oauth.json 包含：
-// {
-//   "access_token": "...",
-//   "refresh_token": "...",
-//   "api_key": "sk-xxx",      // ← 实际用于 API 调用
-//   "email": "user@mail.com",
-//   "type": "iflow"
-// }
-
-// 4. 正常调用模型
-const response = await provider.processIncoming({
-  model: 'kimi',
-  messages: [{ role: 'user', content: 'Hello iFlow!' }]
-});
-```
-
-## 🔧 故障排查
-
-| 问题 | 可能原因 | 解决方案 |
-|------|----------|----------|
-| `getaddrinfo ENOTFOUND iflow.cn` | DNS 解析失败 | 检查网络连接，确认 iFlow 服务状态 |
-| `empty api key returned` | getUserInfo 未返回 apiKey | 确认 iFlow 账户已开通 API 权限 |
-| `401 Unauthorized` | api_key 无效 | 重新走 OAuth 流程获取新的 api_key |
-| `40308` 业务错误 | 使用了 access_token 而非 api_key | 确认 TokenFileAuthProvider 正确读取了 api_key 字段 |
-
-## 🌍 环境变量
-
-- `IFLOW_CLIENT_ID`：覆盖默认 clientId（高级用法）
-- `IFLOW_CLIENT_SECRET`：覆盖默认 clientSecret（高级用法）
-
-> 所有 OAuth 流程现在都会在可用时自动拉起浏览器进行授权，不再支持通过环境变量关闭自动打开行为。
-
-## 📊 测试验证
-
-运行以下命令验证 iFlow OAuth 实现：
-
-```bash
-# 测试 OAuth 流程
-node -e "const { TokenFileAuthProvider } = require('./dist/providers/auth/tokenfile-auth.js'); const provider = new TokenFileAuthProvider({type: 'oauth', tokenFile: '~/.rcc/auth/iflow-oauth.json'}); provider.initialize().then(() => console.log('✅ iFlow OAuth working:', provider.getStatus()));"
-
-# 测试 API Key 提取
-node -e "const { fetchIFlowUserInfo } = require('./dist/providers/auth/iflow-userinfo-helper.js'); fetchIFlowUserInfo('test_token').catch(e => console.log('✅ Error handling working:', e.message));"
-```
-
-## 🎯 总结
-
-iFlow OAuth 实现完全对齐 CLIProxyAPI 的设计：
-
-- ✅ **两阶段认证**：access_token → API Key → 业务请求
-- ✅ **Fast-Fail 原则**：任何步骤失败立即报错，无隐藏回退
-- ✅ **配置驱动**：所有参数外部化，无硬编码
-- ✅ **CLIProxyAPI 兼容**：字段名、端点、错误处理完全一致
-- ✅ **生产就绪**：经过完整测试验证，支持自动刷新和错误恢复

package/docs/release-iflow-400-gate.md

@@ -1,58 +0,0 @@
-# iflow 400 Fix Release Gate (llms -> rcc)
-
-Date: 2026-02-15
-Issue: routecodex-75
-Prerequisite bug: routecodex-70 (CLOSED)
-
-## 1) Preconditions
-- routecodex-70 is closed with replay evidence.
-- Matching tags exist on both repos:
-  - `rc-v0.6.1733-v0.89.1798`
-  - `rc-v0.6.1733-v0.89.1799`
-- Artifacts prepared:
-  - `/tmp/jsonstudio-llms-0.6.1733.tgz`
-  - `jsonstudio-rcc-0.89.1799.tgz`
-
-## 2) Mandatory verification gate
-1. Same-shape replay (affected provider: iflow)
-- sample: `req_1770377342669_6d3e332c`
-- expected: HTTP 200, no 514 business error
-
-2. Control replay (unaffected provider)
-- sample: `req_1770381056958_a35ee9ff` (tab)
-- expected: HTTP 200, behavior unchanged
-
-3. Runtime/build checks
-- `npm run jest:run -- --runTestsByPath tests/server/runtime/http-server/executor-provider.spec.ts tests/server/runtime/executor-provider.retryable.spec.ts --runInBand`
-- `npm run jest:run -- --runTestsByPath tests/server/runtime/request-executor.single-attempt.spec.ts tests/server/http-server/execute-pipeline-failover.spec.ts --runInBand`
-- `npm run build:dev`
-- `npm run install:global`
-
-## 3) Publish order (manual)
-1. Publish llms first
-- `cd sharedmodule/llmswitch-core`
-- `npm publish /tmp/jsonstudio-llms-0.6.1733.tgz`
-
-2. Verify rcc package depends on published llms version
-- `cd /Users/fanzhang/Documents/github/routecodex`
-- check `package.json` has `@jsonstudio/llms: 0.6.1733`
-
-3. Publish rcc
-- `npm publish jsonstudio-rcc-0.89.1799.tgz`
-
-## 4) Rollback checklist
-- If llms publish breaks replay gate:
-  1. stop rcc publish
-  2. rollback to previous llms version in routecodex package.json
-  3. rebuild + rerun same-shape/control replays
-
-- If rcc publish breaks runtime:
-  1. pin users back to previous rcc version
-  2. collect failing requestId/providerKey/model
-  3. preserve same-shape/control replay outputs
-
-## 5) Evidence references
-- routecodex-70 notes include request-level replay outputs:
-  - `/tmp/replay-iflow-base-req_1770377342669_6d3e332c.txt`
-  - `/tmp/replay-iflow-stop-followup-20260207T100636992-003.withkey.txt`
-  - `/tmp/replay-control-tab-key1.req_1770381056958_a35ee9ff.txt`

package/node_modules/@jsonstudio/llms/dist/conversion/compat/actions/iflow-kimi-cli-defaults.d.ts

@@ -1,10 +0,0 @@
-import type { JsonObject } from '../../hub/types/json.js';
-/**
- * iFlow/Kimi request defaults aligned with iflow-cli:
- * - thinking enabled path: temperature=1
- * - thinking disabled path: temperature=0.6
- * - shared defaults: top_p=0.95, n=1, penalties=0, max_new_tokens=max_tokens
- *
- * RouteCodex keeps thinking enabled by default for kimi-k2.5 unless explicitly disabled.
- */
-export declare function applyIflowKimiCliDefaults(payload: JsonObject): JsonObject;