@jsonstudio/rcc 0.90.252 → 0.90.352

package/docs/pipeline-routing-report.md

@@ -80,7 +80,7 @@
 
 ## 配置情况
 
-- 用户 `~/.routecodex/config.json`（或 `ROUTECODEX_CONFIG_PATH` 指定的文件）由 `bootstrapVirtualRouterConfig` 直接解析，得到 `virtualRouter` + `targetRuntime`，HTTP 服务按该结果构造 Hub Pipeline 与 Provider。
+- 用户 `~/.rcc/config.json`（或 `ROUTECODEX_CONFIG_PATH` 指定的文件）由 `bootstrapVirtualRouterConfig` 直接解析，得到 `virtualRouter` + `targetRuntime`，HTTP 服务按该结果构造 Hub Pipeline 与 Provider。
 - OpenAI Router 中的 `targetUrl` 由构造参数/默认值直接决定，并非来自 `modules.json`：
   - `src/server/protocol-handler.ts:89`
 

package/docs/plans/manager-daemon/PLAN.md

@@ -12,7 +12,7 @@
 ## 模块划分
 
 - `TokenManager`（模块 id: `token`）
-  - 继承现有 token daemon 职责：监控 `~/.routecodex/auth/`、刷新 OAuth token、触发重新认证。
+  - 继承现有 token daemon 职责：监控 `~/.rcc/auth/`、刷新 OAuth token、触发重新认证。
   - API：供 CLI / HTTP server 查询 token 状态与触发刷新。
    - 通过 host 级 leader lock（基于 PID 的锁文件）保证 **全局仅有一个 Token 刷新器**（server 内置 TokenManager 与外部 `token-daemon` 互斥）。
 

package/docs/plans/provider-config-v2-plan.md

@@ -3,7 +3,7 @@
 ## 目标与约束
 
 - 将现有「virtualrouter 内联 providers + routing」改为：
-  - Provider 配置：按 provider 维度拆分到 `~/.routecodex/provider/<id>/config.v2.json`。
+  - Provider 配置：按 provider 维度拆分到 `~/.rcc/provider/<id>/config.v2.json`。
   - Routing 配置：保留在主配置（或单独 routing 文件）中，仅描述 route → pool → providerKey 关系。
 - v2 配置通过 `version: "2.0.0"` 与 v1 完全区分，不影响已有 v1 配置（`config.v1.json` / `config.json.virtualrouter.providers`）。
 - 正式运行路径**不做 v1/v2 兼容合并**：v2 模式只读 provider v2 配置；v1 配置仅供迁移脚本和回溯分析使用。
@@ -15,12 +15,12 @@
 
 1. 顶层 Provider 目录
 
-- 路径：`~/.routecodex/provider`
+- 路径：`~/.rcc/provider`
 - 启动行为：
   - 若目录不存在：启动时自动创建。
   - 若存在：每个子目录代表一个 provider 实例（`<providerId>` 或 `<providerId>-<profile>`）。
 
-2. 单个 Provider 目录结构（示例：`~/.routecodex/provider/antigravity`）
+2. 单个 Provider 目录结构（示例：`~/.rcc/provider/antigravity`）
 
 - 静态配置（v2）：
   - 文件：`config.v2.json`
@@ -35,7 +35,7 @@
       "auth": {
         "mode": "oauth",
         "oauthProviderId": "antigravity",
-        "tokenFile": "~/.routecodex/auth/antigravity-oauth-1-geetasamodgeetasamoda.json"
+        "tokenFile": "~/.rcc/auth/antigravity-oauth-1-geetasamodgeetasamoda.json"
       },
       "models": [
         {
@@ -91,7 +91,7 @@
 2. VirtualRouterInput 组合逻辑（v2 模式）
 
 - 启动时步骤：
-  1. 扫描 `~/.routecodex/provider`：
+  1. 扫描 `~/.rcc/provider`：
      - 如不存在则创建空目录。
      - 对每个子目录：若存在 `config.v2.json`：解析为 `ProviderConfigV2`；否则跳过（无隐式迁移）。
   2. 从 `config.json` / routing 文件读取 routing 配置。
@@ -130,7 +130,7 @@
 - 预览：
   - 在终端打印拟写入的 `config.v2.json`，高亮关键字段。
 - 确认：
-  - 用户确认后写入/覆盖 `~/.routecodex/provider/<id>/config.v2.json`。
+  - 用户确认后写入/覆盖 `~/.rcc/provider/<id>/config.v2.json`。
 
 3. list/delete 行为
 
@@ -139,7 +139,7 @@
 - delete：
   - 询问确认后：
     - 仅删除 `config.v2.json`（保留 runtime-state 调试），或
-    - 删除整个 `~/.routecodex/provider/<id>` 目录（可作为高级选项，默认不做）。
+    - 删除整个 `~/.rcc/provider/<id>` 目录（可作为高级选项，默认不做）。
 
 ---
 
@@ -152,7 +152,7 @@
    - 定义 `config.v2.json` 的 TypeScript 接口与基础校验逻辑。
 
 2. 阶段 2：Provider v2 loader（只读，不接入 runtime）
-   - 实现扫描 `~/.routecodex/provider` 的 ProviderConfigV2 loader（**只读取显式 `config.v2.json`**，不做自动迁移）。
+   - 实现扫描 `~/.rcc/provider` 的 ProviderConfigV2 loader（**只读取显式 `config.v2.json`**，不做自动迁移）。
    - 编写单元测试：确保 loader 对合法 v2 配置的读取行为稳定、可预期；迁移逻辑由单独脚本负责。
 
 3. 阶段 3：Routing loader 与 VirtualRouterInput 组合器

package/docs/plans/provider-runtime-manager-plan.md

@@ -71,10 +71,10 @@ interface ProviderRuntimeState {
   type ProviderRuntimeTable = Map<string, ProviderRuntimeState>; // key = providerKey
   ```
 - 磁盘持久化：
-  - 全局快照（可选）：`~/.routecodex/state/providers/<serverId>/providers.jsonl`
+  - 全局快照（可选）：`~/.rcc/state/providers/<serverId>/providers.jsonl`
   - 每 provider 本地状态（推荐）：
-    - `~/.routecodex/provider/<id>/runtime-state.json`
-    - `~/.routecodex/provider/<id>/events.jsonl`（ProviderErrorEvent / 手动操作日志）
+    - `~/.rcc/provider/<id>/runtime-state.json`
+    - `~/.rcc/provider/<id>/events.jsonl`（ProviderErrorEvent / 手动操作日志）
 - TTL 约束：
   - 所有 `cooldownExpiresAt` / `blacklistExpiresAt` 必须**硬性截断**在 24 小时以内：
     - 写入前：`expiresAt = min(now + requestedTtl, now + 24h)`。
@@ -179,7 +179,7 @@ Provider runtime 可以在发起请求前调用 `isRoutable` 做一次最终检
 
 1. Server 启动时：
    - ProviderRuntimeManager：
-     - 扫描 `~/.routecodex/provider/*/runtime-state.json`。
+     - 扫描 `~/.rcc/provider/*/runtime-state.json`。
      - 合并为全局 `ProviderRuntimeTable`，丢弃所有 `expiresAt <= now` 的条目。
    - Virtual Router Engine：
      - 通过注入的 `ProviderRuntimeView` 在首次构造时就能看到恢复后的状态。

package/docs/provider-analysis.md

@@ -39,7 +39,7 @@
    ▼
 ┌─────────────────────────────────────────────────────────────────┐
 │  3. Provider 配置生成 (writeProviderV2)                        │
-│     位置: ~/.routecodex/provider/{providerId}/config.v2.json  │
+│     位置: ~/.rcc/provider/{providerId}/config.v2.json  │
 │                                                                   │
 │  配置结构:                                                       │
 │  {                                                               │
@@ -59,7 +59,7 @@
    ▼
 ┌─────────────────────────────────────────────────────────────────┐
 │  4. 主配置生成 (buildV2ConfigObject)                            │
-│     位置: ~/.routecodex/config.json                              │
+│     位置: ~/.rcc/config.json                              │
 │                                                                   │
 │  配置结构:                                                       │
 │  {                                                               │
@@ -119,7 +119,7 @@ routecodex init --providers openai,qwen --default-provider qwen --force
 1. **创建 Provider 配置目录**:
 
 ```bash
-mkdir -p ~/.routecodex/provider/myprovider
+mkdir -p ~/.rcc/provider/myprovider
 ```
 
 2. **创建 config.v2.json**:
@@ -198,7 +198,7 @@ routecodex provider doctor myprovider
    - Provider 鉴权类型对照表
 
 2. **Provider 目录结构** (README.md 第 142-144 行):
-   - `~/.routecodex/provider/<providerId>/config.v2.json`
+   - `~/.rcc/provider/<providerId>/config.v2.json`
 
 3. **Provider 类型文档**:
    - `docs/PROVIDER_TYPES.md` - Provider 类型说明
@@ -264,7 +264,7 @@ routecodex provider validate myprovider
 
 #### A. Provider Catalog 扩展
 
-- [ ] 支持自定义 catalog 扩展 (`~/.routecodex/provider-catalog.json`)
+- [ ] 支持自定义 catalog 扩展 (`~/.rcc/provider-catalog.json`)
 - [ ] 支持从远程 URL 加载 catalog
 - [ ] catalog 版本管理和更新检查
 

package/docs/provider-quota-design.md

@@ -4,7 +4,7 @@
 
 ## 1. 文件结构
 
-- 根目录：`~/.routecodex/quota/`
+- 根目录：`~/.rcc/quota/`
   - `provider-quota.json`：当前生效的 quota 快照（virtual-router 只读）。
   - `provider-errors.ndjson`：错误事件流水（daemon 可选使用，用于恢复 / 调试）。
 
@@ -134,7 +134,7 @@
 ### Phase 4：virtual-router 接线（可通过 feature flag 控制）
 
 - 在 virtual-router 构建 provider 池时：
-  - 可选读取 `~/.routecodex/quota/provider-quota.json`：
+  - 可选读取 `~/.rcc/quota/provider-quota.json`：
     - 过滤 `inPool !== true` 或 `cooldownUntil/blacklistUntil > now` 的 provider。
     - 按 `priorityTier` 做 tier 调度。
 - 初期通过环境变量开启（例如 `ROUTECODEX_QUOTA_ENABLED=1`），待稳定后再作为默认路径。

package/docs/providers/antigravity-fingerprint-ua-warmup.md

@@ -8,7 +8,7 @@
 
 ## 0) 你需要知道的文件/目录/入口
 
-### 关键目录（默认都在 `~/.routecodex/`）
+### 关键目录（默认都在 `~/.rcc/`）
 
 - OAuth token：`auth/antigravity-oauth-*.json`
 - Camoufox profile：`camoufox-profiles/rc-gemini.<alias>/...`
@@ -54,7 +54,7 @@ RouteCodex 的版本号来源（从高到低）：
 1. `ROUTECODEX_ANTIGRAVITY_USER_AGENT` / `RCC_ANTIGRAVITY_USER_AGENT`（完全覆盖）
 2. `ROUTECODEX_ANTIGRAVITY_UA_VERSION` / `RCC_ANTIGRAVITY_UA_VERSION`
 3. 远程拉取（可通过 `ROUTECODEX_ANTIGRAVITY_UA_DISABLE_REMOTE=1` 禁用）
-4. `~/.routecodex/state/antigravity-ua-version.json`
+4. `~/.rcc/state/antigravity-ua-version.json`
 5. 兜底版本（仅保证“有值”，不保证不过期）
 
 ### 修复步骤
@@ -64,7 +64,7 @@ RouteCodex 的版本号来源（从高到低）：
    - `routecodex oauth antigravity-auto <token-selector-or-path>`
    - 或批量：`routecodex oauth reauth-required`
 3. 如果 Google 提示需要二次验证（账户风控页），用对应 alias 的 profile 打开浏览器完成验证（“养号/解封”）：
-   - `rcc camoufox ~/.routecodex/auth/antigravity-oauth-<alias>.json --url '<verify_url>'`
+   - `rcc camoufox ~/.rcc/auth/antigravity-oauth-<alias>.json --url '<verify_url>'`
 
 > 关键点：必须用 **同一个 alias 的 Camoufox profile** 打开验证页，否则容易造成“验证通过但指纹漂移 → 继续 403”。
 
@@ -105,7 +105,7 @@ RouteCodex 的版本号来源（从高到低）：
 - `chat:gemini` 不会跑 `gemini_cli_request_wrap`（因此不会做历史 `thoughtSignature` 注入）
 - Antigravity 必须用 `chat:gemini-cli`（Cloud Code Assist wrapper 对齐 + signature 注入）
 
-修复点：确保你的用户配置中（`~/.routecodex/config.json`）：
+修复点：确保你的用户配置中（`~/.rcc/config.json`）：
 
 ```jsonc
 {
@@ -143,7 +143,7 @@ RouteCodex 的版本号来源（从高到低）：
 > 这个验证不依赖“你是否真的有 quota”；只要 upstream 在某次响应里下发过 signature，后续注入就应当可见。
 
 ### 如何确认 compat profile 真的生效
-用 `--snap` 或 dev 默认快照（`~/.routecodex/codex-samples/...`）检查 pipeline stage8：
+用 `--snap` 或 dev 默认快照（`~/.rcc/codex-samples/...`）检查 pipeline stage8：
 - `chat_process.req.stage8.outbound.compat.json` 里必须出现 `chat:gemini-cli`
 - 如果你看到的是 `chat:gemini`，说明 profile 仍然配错（很容易复发“第一次 OK，第二次 429”）
 

package/docs/providers/antigravity-gemini-provider-compat.md

@@ -172,14 +172,14 @@ antigravity/<version> <os>/<arch>
 1. 显式 UA：`ROUTECODEX_ANTIGRAVITY_USER_AGENT` / `RCC_ANTIGRAVITY_USER_AGENT`（完全覆盖）
 2. 显式版本号：`ROUTECODEX_ANTIGRAVITY_UA_VERSION` / `RCC_ANTIGRAVITY_UA_VERSION`
 3. 远程拉取：`VERSION_URL`，失败时回退 `CHANGELOG_URL`（可用 `ROUTECODEX_ANTIGRAVITY_UA_DISABLE_REMOTE=1` 禁用）
-4. 本地磁盘 cache：`~/.routecodex/state/antigravity-ua-version.json`
+4. 本地磁盘 cache：`~/.rcc/state/antigravity-ua-version.json`
 5. 最后兜底：`KNOWN_STABLE_VERSION`（当前 `4.1.24`，对齐 Antigravity-Manager）
 
 ### 4.3 `<os>/<arch>` suffix 如何从指纹推断（并且为何禁 linux）
 
 实现位置：`src/providers/auth/antigravity-fingerprint.ts`
 
-- 指纹文件：`~/.routecodex/camoufox-fp/<profileId>.json`
+- 指纹文件：`~/.rcc/camoufox-fp/<profileId>.json`
 - 从 `CAMOU_CONFIG_1` 的 `navigator.*` 字段推断：
   - `windows|macos|linux`
   - `amd64|aarch64`
@@ -191,7 +191,7 @@ RouteCodex 约束：
 
 实现位置：`src/providers/core/config/camoufox-launcher.ts`
 
-- 每个 alias 都对应一个稳定 profileId（目录在 `~/.routecodex/camoufox-profiles/`）。
+- 每个 alias 都对应一个稳定 profileId（目录在 `~/.rcc/camoufox-profiles/`）。
 - `gemini-cli` 与 `antigravity` 共享同一“指纹家族（gemini）”，因此同 alias 在两者之间共享 profileId（避免一个账号跑出两套指纹）。
 - OS policy：对 `(providerFamily, alias)` 做稳定 hash，把不同 alias 分布到 `windows/macos`，并**严格禁止 linux**。
 

package/docs/providers/deepseek-web-provider-design.md

@@ -78,7 +78,7 @@
             {
               "alias": "1",
               "type": "deepseek-account",
-              "tokenFile": "~/.routecodex/auth/deepseek-account-1.json"
+              "tokenFile": "~/.rcc/auth/deepseek-account-1.json"
             }
           ]
         },

package/docs/providers/gemini-provider.md

@@ -42,7 +42,7 @@
 
 ```bash
 node dist/tools/provider-update/index.js \
-  --config /Users/you/.routecodex/provider/gemini/config.json \
+  --config /Users/you/.rcc/provider/gemini/config.json \
   --write --probe-keys --verbose
 ```
 

package/docs/providers/provider-composite-testing.md

@@ -77,8 +77,8 @@ test('protocol mismatch fails fast', async () => {
 ```
 npm run build
 node scripts/pipeline-dry-run.mjs \
-  --config ~/.routecodex/config.json \
-  --samples ~/.routecodex/codex-samples \
+  --config ~/.rcc/config.json \
+  --samples ~/.rcc/codex-samples \
   --out demo-results/pipeline-dryrun
 ```
 

package/docs/providers/tabglm-claude-code-compat.md

@@ -10,7 +10,7 @@ tabglm 的 Anthropic 入口会对请求做“官方客户端”校验；当 `sys
 
 ## 启用方式（推荐：只改 config）
 
-在 `~/.routecodex/config.json`（或你的自定义 config）里为 tabglm provider 开启 compat profile（必须显式配置，禁止推断）：
+在 `~/.rcc/config.json`（或你的自定义 config）里为 tabglm provider 开启 compat profile（必须显式配置，禁止推断）：
 
 - 推荐：`virtualrouter.providers.tabglm.compatibilityProfile = "anthropic:claude-code"`
 - 也支持：`virtualrouter.providers.tabglm.compatibilityProfile = "chat:claude-code"`

package/docs/replay-evidence-iflow-400.txt

@@ -6,13 +6,13 @@
 - Before fix: HTTP 400 business error 514
 - After fix: HTTP 200, successful response
 - Output saved: /tmp/replay-iflow-base-req_1770377342669_6d3e332c.txt (no longer available)
-- Verification command: `npm run replay:codex-sample -- --sample ~/.routecodex/codex-samples/openai-responses/iflow.1-186.kimi-k2.5/req_1770377342669_6d3e332c/client-request.json`
+- Verification command: `npm run replay:codex-sample -- --sample ~/.rcc/codex-samples/openai-responses/iflow.1-186.kimi-k2.5/req_1770377342669_6d3e332c/client-request.json`
 
 ### Sample 2: Stop_followup request (openai-responses-iflow.1-186...20260207T100636992-003_stop_followup)
 - Before fix: HTTP 400 business error 514
 - After fix: HTTP 200, successful response
 - Output saved: /tmp/replay-iflow-stop-followup-20260207T100636992-003.withkey.txt (no longer available)
-- Verification command: `npm run replay:codex-sample -- --sample ~/.routecodex/codex-samples/openai-responses/iflow.1-186.kimi-k2.5/.../client-request.json`
+- Verification command: `npm run replay:codex-sample -- --sample ~/.rcc/codex-samples/openai-responses/iflow.1-186.kimi-k2.5/.../client-request.json`
 
 ## Unaffected Provider (tab.gpt-5.3-codex) - Control Replay
 
@@ -20,7 +20,7 @@
 - Before fix: HTTP 200, unchanged
 - After fix: HTTP 200, unchanged
 - Output saved: /tmp/replay-control-tab-key1.req_1770381056958_a35ee9ff.txt (no longer available)
-- Verification command: `npm run replay:codex-sample -- --sample ~/.routecodex/codex-samples/openai-chat/tab.key1.gpt-5.3-codex/req_1770381056958_a35ee9ff/client-request.json`
+- Verification command: `npm run replay:codex-sample -- --sample ~/.rcc/codex-samples/openai-chat/tab.key1.gpt-5.3-codex/req_1770381056958_a35ee9ff/client-request.json`
 
 ## Summary
 All same-shape and control replays pass. The fix ensures:

package/docs/reports/routing-classification-report.json

@@ -13,12 +13,12 @@
     "vision"
   ],
   "sampleByCategory": {
-    "thinking": "/Users/fanzhang/.routecodex/codex-samples/openai-chat/req_1762999988376_zyns5xw9n_provider-request.json",
-    "longContext": "/Users/fanzhang/.routecodex/codex-samples/openai-chat/req_1763000100195_09q89vvi2_provider-request.json",
-    "tools": "/Users/fanzhang/.routecodex/codex-samples/openai-chat/req_1763002108961_i6ia6jndk_provider-request.json",
-    "webSearch": "/Users/fanzhang/.routecodex/codex-samples/openai-chat/req_1763002108961_k3ysf83dl_provider-request.json",
-    "coding": "/Users/fanzhang/.routecodex/codex-samples/openai-chat/req_1763002110308_iyj8j09zq_provider-request.json",
-    "default": "/Users/fanzhang/.routecodex/codex-samples/openai-chat/req_1763014458732_3yfsckrin_provider-request.json"
+    "thinking": "/Users/fanzhang/.rcc/codex-samples/openai-chat/req_1762999988376_zyns5xw9n_provider-request.json",
+    "longContext": "/Users/fanzhang/.rcc/codex-samples/openai-chat/req_1763000100195_09q89vvi2_provider-request.json",
+    "tools": "/Users/fanzhang/.rcc/codex-samples/openai-chat/req_1763002108961_i6ia6jndk_provider-request.json",
+    "webSearch": "/Users/fanzhang/.rcc/codex-samples/openai-chat/req_1763002108961_k3ysf83dl_provider-request.json",
+    "coding": "/Users/fanzhang/.rcc/codex-samples/openai-chat/req_1763002110308_iyj8j09zq_provider-request.json",
+    "default": "/Users/fanzhang/.rcc/codex-samples/openai-chat/req_1763014458732_3yfsckrin_provider-request.json"
   },
   "errors": []
 }

package/docs/reports/routing-classification-report.md

@@ -6,12 +6,12 @@
 
 ## Samples
 
-- thinking: /Users/fanzhang/.routecodex/codex-samples/openai-chat/req_1762999988376_zyns5xw9n_provider-request.json
-- longContext: /Users/fanzhang/.routecodex/codex-samples/openai-chat/req_1763000100195_09q89vvi2_provider-request.json
-- tools: /Users/fanzhang/.routecodex/codex-samples/openai-chat/req_1763002108961_i6ia6jndk_provider-request.json
-- webSearch: /Users/fanzhang/.routecodex/codex-samples/openai-chat/req_1763002108961_k3ysf83dl_provider-request.json
-- coding: /Users/fanzhang/.routecodex/codex-samples/openai-chat/req_1763002110308_iyj8j09zq_provider-request.json
-- default: /Users/fanzhang/.routecodex/codex-samples/openai-chat/req_1763014458732_3yfsckrin_provider-request.json
+- thinking: /Users/fanzhang/.rcc/codex-samples/openai-chat/req_1762999988376_zyns5xw9n_provider-request.json
+- longContext: /Users/fanzhang/.rcc/codex-samples/openai-chat/req_1763000100195_09q89vvi2_provider-request.json
+- tools: /Users/fanzhang/.rcc/codex-samples/openai-chat/req_1763002108961_i6ia6jndk_provider-request.json
+- webSearch: /Users/fanzhang/.rcc/codex-samples/openai-chat/req_1763002108961_k3ysf83dl_provider-request.json
+- coding: /Users/fanzhang/.rcc/codex-samples/openai-chat/req_1763002110308_iyj8j09zq_provider-request.json
+- default: /Users/fanzhang/.rcc/codex-samples/openai-chat/req_1763014458732_3yfsckrin_provider-request.json
 
 ## Errors
 

package/docs/reports/thinking-keywords-report.json

@@ -9,11 +9,11 @@
     "analyze": 12
   },
   "samplePerKeyword": {
-    "analysis": "/Users/fanzhang/.routecodex/codex-samples/openai-chat/req_1762999988376_zyns5xw9n_provider-request.json",
-    "思考": "/Users/fanzhang/.routecodex/codex-samples/openai-chat/req_1763002108523_9wlgh144y_provider-request.json",
-    "推理": "/Users/fanzhang/.routecodex/codex-samples/openai-chat/req_1763002108523_9wlgh144y_provider-request.json",
-    "分析": "/Users/fanzhang/.routecodex/codex-samples/openai-chat/req_1763002108523_9wlgh144y_provider-request.json",
-    "reasoning": "/Users/fanzhang/.routecodex/codex-samples/openai-chat/req_1763002387567_v2m2i4vc2_provider-request.json",
-    "analyze": "/Users/fanzhang/.routecodex/codex-samples/openai-chat/req_1763085298297_n028lwxea_provider-request.json"
+    "analysis": "/Users/fanzhang/.rcc/codex-samples/openai-chat/req_1762999988376_zyns5xw9n_provider-request.json",
+    "思考": "/Users/fanzhang/.rcc/codex-samples/openai-chat/req_1763002108523_9wlgh144y_provider-request.json",
+    "推理": "/Users/fanzhang/.rcc/codex-samples/openai-chat/req_1763002108523_9wlgh144y_provider-request.json",
+    "分析": "/Users/fanzhang/.rcc/codex-samples/openai-chat/req_1763002108523_9wlgh144y_provider-request.json",
+    "reasoning": "/Users/fanzhang/.rcc/codex-samples/openai-chat/req_1763002387567_v2m2i4vc2_provider-request.json",
+    "analyze": "/Users/fanzhang/.rcc/codex-samples/openai-chat/req_1763085298297_n028lwxea_provider-request.json"
   }
 }

package/docs/responses/README.md

@@ -3,9 +3,9 @@
 本节记录当前已经验证 **可以和 `https://www.fakercode.top/v1/responses` 正常通信** 的典型请求形状，方便后续实现 Responses provider 和 llmswitch-core 路由时参考。
 
 > 最新直通黄金样本：  
-> - `~/.routecodex/codex-samples/openai-responses/req_req-v2-1763955655135-2z91vfddh_request_1_validation_pre.json`（llmswitch 输入）  
-> - `~/.routecodex/codex-samples/openai-responses/req_1763955655139_mhw2j6ao_http-request.json`（/v1/responses 入口）  
-> - `~/.routecodex/codex-samples/openai-responses/req_1763955655143_24f5h9qsj_provider-request.json`（Responses Provider 直通）  
+> - `~/.rcc/codex-samples/openai-responses/req_req-v2-1763955655135-2z91vfddh_request_1_validation_pre.json`（llmswitch 输入）  
+> - `~/.rcc/codex-samples/openai-responses/req_1763955655139_mhw2j6ao_http-request.json`（/v1/responses 入口）  
+> - `~/.rcc/codex-samples/openai-responses/req_1763955655143_24f5h9qsj_provider-request.json`（Responses Provider 直通）  
 > 同一时间窗的前序样本（`req_1763955649860_832l5215_http-request.json`、`req_1763955649865_drd7xwttl_provider-request.json` 等）记录了相同请求在路由/Provider 侧的视角，可一起对照，`data` 或 `data.originalData` 即为发送给 FC 的最终载荷。
 
 ### 1. 已验证成功的请求形状（摘要）
@@ -100,7 +100,7 @@
 - **metadata 可以保留 RouteCodex 自己的统计字段**，对上游兼容无明显影响。  
 - **stream=true + SSE**：该请求在 FC 上下游是以 Responses SSE 事件流的形式返回（`response.created` / `response.output_text.delta` / `response.completed` 等事件）。
 - **工具结果配对只依赖 `call_id`**：OpenAI Responses 规范要求 `function_call` 与 `function_call_output` 仅通过同一 `call_id` 关联，并不会额外携带 `tool_call_id`。RouteCodex 在转换为 Chat 形状时会把 `call_id` 临时映射为 Chat 所需的 `tool_call_id`，但在发给上游或回传客户端前必须把结构还原为“只有 `call_id` 的官方形状”，否则像 c4m / Fai 这类严格实现会直接报 `Unknown parameter: input[].tool_call_id`。
-- **强制开启 streaming：在用户 Provider 配置（例如 `~/.routecodex/provider/fc/config.v1.json`）的 Responses 提供者下添加 `"responses": { "process": "passthrough", "streaming": "always" }`，这样 `ResponsesHttpProvider` 会通过 `responses.streaming` 判定为 `always`，即使入口是 Anthropic/Messages 也会对上游（如 Fai/c4m）以 SSE 模式发送请求。**
+- **强制开启 streaming：在用户 Provider 配置（例如 `~/.rcc/provider/fc/config.v1.json`）的 Responses 提供者下添加 `"responses": { "process": "passthrough", "streaming": "always" }`，这样 `ResponsesHttpProvider` 会通过 `responses.streaming` 判定为 `always`，即使入口是 Anthropic/Messages 也会对上游（如 Fai/c4m）以 SSE 模式发送请求。**
 
 ### 2. 失败的简化请求形状（对比）
 
@@ -122,7 +122,7 @@
 ```bash
 FC_API_KEY=... FC_MODEL=gpt-5.1 \
 node scripts/fc-responses-from-snapshot.mjs \
-  ~/.routecodex/codex-samples/openai-responses/req_req-v2-1763955655135-2z91vfddh_request_1_validation_pre.json
+  ~/.rcc/codex-samples/openai-responses/req_req-v2-1763955655135-2z91vfddh_request_1_validation_pre.json
 ```
 
 在成功场景下，SDK 报告的事件分布如下（节选）：

package/docs/responses-generic-provider.md

@@ -67,7 +67,7 @@ virtualRouter 期望（关键片段）
 - 工具链：`required_action.submit_tool_outputs` 原样透传，不文本化。
 
 落盘与回放
-- 目录：`~/.routecodex/codex-samples/responses-replay`。
+- 目录：`~/.rcc/codex-samples/responses-replay`。
 - 文件：`raw-request_req_*.json`、`provider-out-generic_*.json`、`sse-events-<RID>.log`。
 - 脚本（新增）：
   - `scripts/verify-responses-passthrough.mjs`：对比 raw-request 与 provider-out 正文字段一致（headers/trace 差异允许）。

package/docs/responses-passthrough-provider-design.md

@@ -6,7 +6,7 @@
 
 - 目标
   - 在 `/v1/responses` 下提供“真实 SSE 透传”能力：输入 Responses 请求，输出同规范 Responses 事件流。
-  - 使用配置驱动：`~/.routecodex/config.json` 中新增一个 `type: "responses-standard"` 的 provider；模型设为 `gpt-5.1`；将其设置为默认路由（`routing.default`）。
+  - 使用配置驱动：`~/.rcc/config.json` 中新增一个 `type: "responses-standard"` 的 provider；模型设为 `gpt-5.1`；将其设置为默认路由（`routing.default`）。
   - 与黑盒客户端无耦合：不需要客户端改代码即可稳定收到事件与字节。
   - 强可观测：保留请求/响应快照；增加服务端原始 SSE 字节 tee 日志。
 
@@ -75,7 +75,7 @@
 
 ## 4. 配置与选择
 
-- Provider 配置（示例，已按照你的要求生成到 `~/.routecodex/config.responses.json`）：
+- Provider 配置（示例，已按照你的要求生成到 `~/.rcc/config.responses.json`）：
   - `type`: `"responses-standard"`
   - `baseUrl`: `"https://www.fakercode.top/v1"`
   - `auth.type`: `"apikey"`
@@ -104,7 +104,7 @@
      - submit 路径新增对 `llmswitch-core` 的 `resumeResponsesConversation()` 调用，server 侧仅负责读取 `response_id` / `tool_outputs` 并交给核心缓存生成完整 payload，成功后再进 Hub Pipeline，失败返回 400（表示响应已过期或丢失）。
 
 4) 配置示例（你已要求，已生成在用户目录）：
-   - `~/.routecodex/config.responses.json`（不改仓库内默认 config）。
+   - `~/.rcc/config.responses.json`（不改仓库内默认 config）。
 
 ## 6. 测试与验收
 
@@ -114,8 +114,8 @@
   - 工具回路：收到 `required_action` 后，黑盒 `submit_tool_outputs`，再验证下一轮直到 `done`。
 
 - 服务端可观测：
-  - 原始 SSE 字节：`~/.routecodex/logs/sse/<reqId>_server.sse.log`
-  - 快照：`~/.routecodex/codex-samples/openai-responses/` 下的 `provider-request.json` / `provider-response.json` / `provider-error.json` 与 `*_sse_pre/post.json`
+  - 原始 SSE 字节：`~/.rcc/logs/sse/<reqId>_server.sse.log`
+  - 快照：`~/.rcc/codex-samples/openai-responses/` 下的 `provider-request.json` / `provider-response.json` / `provider-error.json` 与 `*_sse_pre/post.json`
 
 - 代理排查建议：
   - Nginx：`proxy_buffering off;` `proxy_http_version 1.1;` `proxy_set_header Connection '';` `chunked_transfer_encoding on;`；
@@ -144,7 +144,7 @@
 
 - 命令：`npm run verify:sse-loop`
   - 统一触发 Responses、Chat（LMStudio）和 Anthropic（GLM-Anthropic）的官方 SDK → RouteCodex 对比。
-  - 需要提前在 `~/.routecodex/provider/<providerId>/` 配置相应上游；RouteCodex 本地实例需已启动（默认 `http://127.0.0.1:5555/v1`）。
+  - 需要提前在 `~/.rcc/provider/<providerId>/` 配置相应上游；RouteCodex 本地实例需已启动（默认 `http://127.0.0.1:5555/v1`）。
 - 环境变量：
   - `RCC_LOOP_RESP_PROVIDER` / `RCC_LOOP_RESP_MODEL`
   - `RCC_LOOP_CHAT_MODEL`
@@ -157,7 +157,7 @@
 
 附：配置示例（已生成在用户目录）
 
-- `~/.routecodex/config.responses.json`（节选）
+- `~/.rcc/config.responses.json`（节选）
 
 ```
 {

package/docs/routing-instructions.md

@@ -166,7 +166,7 @@ RouteCodex 支持通过用户消息中的特殊指令 `<**...**>` 来动态控
 - 启用 / 更新自动续写：
   - `<**stopMessage:"继续"**>` → 默认最多自动续写 10 次；
   - `<**stopMessage:"继续",3**>` → 最多自动续写 3 次；
-  - `<**stopMessage:<file://stopMessage/message1.md>**>` → 读取 `~/.routecodex/stopMessage/message1.md` 作为 stopMessage 文案（设置时读取并缓存到内存）；
+  - `<**stopMessage:<file://stopMessage/message1.md>**>` → 读取 `~/.rcc/stopMessage/message1.md` 作为 stopMessage 文案（设置时读取并缓存到内存）；
 - 清理 stopMessage 状态：
   - `<**stopMessage:clear**>`
 

package/docs/token-daemon-preview.html

@@ -210,7 +210,7 @@
         <div class="scope-switch">
           <span class="dim">范围：</span>
           <span class="scope-pill active">当前 Server（local-5555）</span>
-          <span class="scope-pill">当前 Config（~/.routecodex/config.json）</span>
+          <span class="scope-pill">当前 Config（~/.rcc/config.json）</span>
           <span class="scope-pill">所有 Server</span>
           <span class="scope-pill">所有 Config</span>
         </div>
@@ -282,7 +282,7 @@
                 <span class="icon">📦</span>
                 <span class="mono">local-5520</span>
                 <span class="badge offline">offline</span>
-                <span class="dim mono">(~/.routecodex/config.json)</span>
+                <span class="dim mono">(~/.rcc/config.json)</span>
               </div>
               <ul>
                 <li class="tree-node">
@@ -319,7 +319,7 @@
                     <span class="mono">iflow</span>
                     <span class="tag">protocol=openai</span>
                     <span class="badge oauth">oauth</span>
-                    <span class="dim mono">tokenFile=~/.routecodex/auth/iflow-oauth-1-186.json</span>
+                    <span class="dim mono">tokenFile=~/.rcc/auth/iflow-oauth-1-186.json</span>
                   </div>
                   <ul>
                     <li class="tree-node">

package/docs/token-refresh-daemon-plan.md

@@ -2,11 +2,11 @@
 
 ## 概述
 
-后台守护进程，监控 `~/.routecodex/auth/` 目录下的 Token 文件，自动管理 Token 刷新和重新认证。
+后台守护进程，监控 `~/.rcc/auth/` 目录下的 Token 文件，自动管理 Token 刷新和重新认证。
 
 ## 核心职责
 
-1. **监控 Token 文件** - 监控 `~/.routecodex/auth/*.json` 变化
+1. **监控 Token 文件** - 监控 `~/.rcc/auth/*.json` 变化
 2. **检测过期** - 读取 `expires_at` 判断是否即将过期/已过期
 3. **自动刷新** - OAuth Token 提前30分钟自动刷新
 4. **触发认证（显式）** - 后台默认不弹窗；需要交互式修复时由用户运行 `rcc oauth --force <selector>` 或 `rcc oauth <provider>-auto <selector>`
@@ -14,7 +14,7 @@
 ## 目录结构
 
 ```
-~/.routecodex/auth/
+~/.rcc/auth/
 ├── iflow-oauth-1-work.json           # 账号: work@example.com
 ├── iflow-oauth-2-personal.json       # 账号: my@gmail.com
 ├── qwen-oauth-1-default.json         # 账号: dev@company.com
@@ -176,7 +176,7 @@ routecodex token-daemon stop
 ```
 🌙 Token Refresh Daemon 运行中
 PID: 12345
-📁 监控目录: ~/.routecodex/auth/
+📁 监控目录: ~/.rcc/auth/
 
 | 文件名              | 显示名称               | 状态   | 过期时间       | 剩余   |
 |---------------------|------------------------|--------|----------------|--------|
@@ -204,7 +204,7 @@ PID: 12345
          ▼                    ▼
 ┌──────────────────┐  ┌─────────────────────────────────┐
 │ 配置文件Watcher   │  │ 认证页面 (外部浏览器)             │
-│ ~/.routecodex/auth│  │ + 本地回调服务器 (localhost)     │
+│ ~/.rcc/auth│  │ + 本地回调服务器 (localhost)     │
 └──────────────────┘  └─────────────────────────────────┘
 ```
 
@@ -233,7 +233,7 @@ PID: 12345
 
 | 决策点 | 选择 | 理由 |
 |--------|------|------|
-| 监控目录 | `~/.routecodex/auth/` | 现有结构，保持兼容 |
+| 监控目录 | `~/.rcc/auth/` | 现有结构，保持兼容 |
 | 进程间通信 | Unix Domain Socket | 本机通信，安全 |
 | 配置文件监听 | chokidar | 跨平台，事件驱动 |
 | 浏览器 | 外部浏览器 | Google 禁止自动化登录 |
@@ -261,7 +261,7 @@ PID: 12345
 
 ## 待确认问题
 
-1. [x] 监控目录: `~/.routecodex/auth/`
+1. [x] 监控目录: `~/.rcc/auth/`
 2. [x] 提前刷新时间: 30分钟
 3. [x] 认证方式: 外部浏览器
 4. [x] 回调方式: 本地 HTTP 服务器

package/docs/verification/modelscope-verify.md

@@ -1,7 +1,7 @@
 # ModelScope 独立验证记录
 
 - 日期: 2025-09-26
-- 配置文件: `~/.routecodex/config/modelscope.json`
+- 配置文件: `~/.rcc/config/modelscope.json`
 - 监听端口: 5507（示例环境）
 
 ## 验证范围
@@ -54,6 +54,6 @@ curl -i -sS -H 'Content-Type: application/json' \
 ## 日志与追踪
 
 - 运行日志：`server-modelscope.log`
-- DebugCenter：`~/.routecodex/logs/debug-center.log`
+- DebugCenter：`~/.rcc/logs/debug-center.log`
 - 关联方式：使用响应头 `x-request-id` 在日志中检索对应请求链路
 

package/docs/verified-configs/README.md

@@ -24,10 +24,10 @@
 #### 使用方法
 ```bash
 # 启动 LM Studio 配置 (端口 5521)
-npx ts-node src/cli.ts start --config ~/.routecodex/config/lmstudio-5521-gpt-oss-20b-mlx.json --port 5521
+npx ts-node src/cli.ts start --config ~/.rcc/config/lmstudio-5521-gpt-oss-20b-mlx.json --port 5521
 
 # 启动 Qwen Provider 配置 (端口 5522)
-npx ts-node src/cli.ts start --config ~/.routecodex/config/qwen-5522-qwen3-coder-plus.json --port 5522
+npx ts-node src/cli.ts start --config ~/.rcc/config/qwen-5522-qwen3-coder-plus.json --port 5522
 ```
 
 ## 目录结构