Merge branch 'main' into fix/result-idle-timeout

Author: lishuceo

.claude/skills/maker-chats/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: maker-chats
+description: "根据 Maker App ID 拉取该应用的 chat 列表，并生成可直接打开的 maker/fuping URL 表格。当用户提供 Maker App ID（UUID 形式，如 99b00f3e-e64a-455a-b000-9ec2c95297d7）并想查看该应用下所有 chat 会话、复盘历史对话、获取带 bypassAuth 的直达链接时使用。默认先查生产，生产无数据时回落到 fuping；也可显式指定 prod/fuping/both。"
+argument-hint: "<app_id> [prod|fuping|both]"
+---
+
+# Maker Chats
+
+根据 Maker App ID 拉取生产或 fuping 环境的 chat 列表，输出包含直达链接、标题、最后活跃时间的表格。
+
+## API
+
+| 环境 | API URL | 直达链接 base |
+|------|---------|---------------|
+| prod | `https://maker.taptap.cn/api/v1/gmtools/apps/<app_id>/chats` | `https://maker.taptap.cn/app/<app_id>?chatId=<chat_id>&bypassAuth=true` |
+| fuping | `https://fuping.agnt.xd.com/api/v1/gmtools/apps/<app_id>/chats` | `https://fuping.agnt.xd.com/app/<app_id>?chatId=<chat_id>&bypassAuth=true` |
+
+**分页参数**：`?limit=<N>&offset=<M>`。响应顶层 `hasMore: true` 表示还有下一页。默认页大小 `limit=20`。
+无需鉴权，直接 GET。响应示例：
+
+```json
+{
+  "appId": "99b00f3e-e64a-455a-b000-9ec2c95297d7",
+  "limit": 20,
+  "offset": 0,
+  "hasMore": false,
+  "chats": [
+    {
+      "id": "6825614d-1ad0-4084-9cb0-6acc7212e285",
+      "title": "类似霓虹深渊的游戏...",
+      "lastActivity": "2026-05-11T13:12:19.062Z"
+    }
+  ]
+}
+```
+
+## 执行步骤
+
+### 1. 解析输入
+
+从 `$ARGUMENTS` 或用户消息中提取：
+
+- `app_id`：UUID 格式（必须）。如未提供则询问用户。
+- 环境：`prod` / `fuping` / `both`。**未指定时默认行为：先查 prod，命中则只展示 prod；prod 无数据（chats 为空、404 Not Found 或请求失败）时再查 fuping。** 用户显式指定时按指定执行（`both` 才并行两个环境）。
+
+### 2. 查询 chats（按需翻页）
+
+**单次只拉一页**。接口虽支持分页，但一页通常足够使用，不要循环抓取——等用户明确要下一页时再翻。
+
+**默认（fallback）**：先单独查 prod 第一页，若无数据则查 fuping 第一页。
+
+```bash
+curl -s 'https://maker.taptap.cn/api/v1/gmtools/apps/<app_id>/chats?limit=20&offset=0'
+# 若响应为 {"error":"Not Found"} / 网络失败 / chats 为空 → 再查 fuping
+curl -s 'https://fuping.agnt.xd.com/api/v1/gmtools/apps/<app_id>/chats?limit=20&offset=0'
+```
+
+**显式 `both`**：并行调两个环境的第一页。
+
+**显式 `prod` / `fuping`**：只调对应环境第一页，不回落。
+
+判断"无数据"：响应非 JSON、缺少 `chats` 字段、`chats` 为空、HTTP 非 2xx。
+
+**翻页**：当用户说"下一页"、"再来 N 条"、"翻到第 X 页"等时，复用上次命中的环境与 `limit`，按 `offset += limit` 调用：
+
+```bash
+curl -s '<base>/api/v1/gmtools/apps/<app_id>/chats?limit=<limit>&offset=<next_offset>'
+```
+
+跨轮记住：当前环境、`limit`、下一个 `offset`。如果用户切换 app_id，重置状态。
+
+### 3. 输出结果
+
+每个查询的环境输出一张表格。链接 base 必须**与查询环境一致**（fuping 的 chat 不能用 maker.taptap.cn 链接，反之亦然）。
+
+```markdown
+## Maker Chats — `<app_id>`
+### Production (`maker.taptap.cn`) — 第 1 页 (offset 0, N 条)
+
+| URL | Title | Last Activity |
+|-----|-------|---------------|
+| https://maker.taptap.cn/app/<app_id>?chatId=<chat_id>&bypassAuth=true | <title> | <lastActivity> |
+| ... | ... | ... |
+
+### Fuping (`fuping.agnt.xd.com`) — 第 1 页 (offset 0, N 条)
+
+| URL | Title | Last Activity |
+|-----|-------|---------------|
+| https://fuping.agnt.xd.com/app/<app_id>?chatId=<chat_id>&bypassAuth=true | <title> | <lastActivity> |
+| URL | Title | Last Activity |
+|-----|-------|---------------|
+| https://fuping.agnt.xd.com/app/<app_id>?chatId=<chat_id>&bypassAuth=true | <title> | <lastActivity> |
+```
+
+排序：按 `lastActivity` 倒序（最近活跃在前）。
+
+### 4. 注意事项
+
+- `lastActivity` 保留 API 返回的原始 ISO 字符串，不做时区转换。
+- 表格表头显示**当前页条数**与分页位置，例如 `Production (maker.taptap.cn) — 第 1 页 (offset 0, 20 条)`。
+- 若 `hasMore=true`，在该环境表格下方追加一行提示：`> 还有更多 chat（hasMore=true），告诉我"下一页"继续翻。`
+- 翻页结果同样按上述格式输出，标明当前 offset。
+- 仅输出表格与必要说明，不要追加"是否需要还原项目"等额外建议（用户需要时会显式触发 `restore-project` 等技能）。

.claude/skills/pr-fixup/SKILL.md

@@ -141,7 +141,23 @@ gh run view RUN_ID --log-failed 2>&1 | tail -100
 
 ### Step 3: 获取未解决的 Review 评论
 
-通过 GraphQL 获取所有 review threads：
+Review 反馈分布在三个地方，必须**都检查**，不能只看 inline review threads：
+
+1. **Inline review threads** — reviewer 在具体代码行上的评论（GraphQL `reviewThreads`）
+2. **PR 顶层 issue comments** — review bot 经常把发现的问题汇总成一条整体评论发到 PR 主时间线（`gh pr view --json comments`）
+3. **PR description** — 部分 review bot 会把 summary 写进 PR description 而非 comment
+
+先获取 PR 作者、body、head SHA，以及最后一次推送对应的 commit 时间：
+
+```bash
+gh pr view PR_NUMBER --json author,body,headRefOid -q '{author: .author.login, body: .body, sha: .headRefOid}'
+# 用 GitHub 上 head commit 的 committer date 作为"最后一次 push 时间"的近似值
+# 不要用本地 git log（rebase/amend 后本地时间和 GitHub 上不一致）
+HEAD_SHA=$(gh pr view PR_NUMBER --json headRefOid -q .headRefOid)
+LAST_PUSH=$(gh api repos/OWNER/REPO/commits/$HEAD_SHA --jq .commit.committer.date)
+```
+
+**3a. Inline review threads**（GraphQL）：
 
 ```bash
 gh api graphql -f query='{
@@ -158,6 +174,7 @@ gh api graphql -f query='{
               author { login }
               path
               line
+              createdAt
             }
           }
         }
@@ -167,19 +184,45 @@ gh api graphql -f query='{
 }'
 ```
 
-先获取 PR 作者：`gh pr view PR_NUMBER --json author -q .author.login` → `PR_AUTHOR`
-
 过滤条件：
 - `isResolved == false`（未解决）
-- 发起评论（第一条 comment）的 `author.login` **不是** PR 作者（排除自己的评论，处理所有 reviewer 的反馈，包括 bot 和人类 reviewer）
+- 第一条 comment 的 `author.login` **不是** PR 作者
+
+**3b. PR 顶层 issue comments**：
+
+```bash
+gh pr view PR_NUMBER --json comments -q '.comments[] | select(.author.login != "PR_AUTHOR") | {id, body, author: .author.login, createdAt}'
+```
+
+过滤条件：
+- `author.login` 不是 PR 作者
+- `createdAt` 在最后一次 push 之后（处理新增反馈，忽略已被旧 commit 处理的历史评论）
+
+**3c. PR description**：
+
+检查 PR body 中是否包含 review summary。判定标准（避免把普通 PR 说明误判为 review）：
+
+- **强信号**（出现任一即可判定）：`## Review Summary`、`### Issues Found`、`## Review Notes`、`Suggested Action`
+- **弱信号**（需同时出现 ≥2 个才算）：`🟡`、`🔴`、`nit`、`confidence`、`severity`
+
+满足上述任一规则的，把 review summary 段落里的条目当作待处理 review feedback，与 3a/3b 一起进入 Step 4。
+
+**去重（重要）**：3a 靠 `isResolved` 去重、3b 靠 `createdAt > LAST_PUSH` 去重，但 PR description 是静态的，Claude 修完代码 push 后 description 内容并不会变。为避免同一 `/pr-fixup` 调用内同一条 3c 条目被反复处理，必须做以下两件事之一：
 
-如果没有 CI 失败（Step 2 已全部通过）且没有未解决的非作者评论 → 输出 "✅ 所有 CI checks 通过，PR review 无阻塞问题" 并结束循环。
+- **本轮内存记录**：在当前 `/pr-fixup` 执行流程中维护一个集合（如条目正文的前 50 字符 hash），处理过的 3c 条目下一轮直接跳过
+- **镜像到顶层 comment**：处理完 3c 条目后调用 `gh pr comment` 写一条 "Addressed (3c): <条目摘要>" 到 PR 主时间线，让后续轮次靠 3b 的 `LAST_PUSH` 过滤自动跳过
+
+推荐第一种（更便宜，不污染 PR 时间线）。
+
+如果没有 CI 失败（Step 2 已全部通过）且 3a/3b/3c 都没有未处理的反馈 → 输出 "✅ 所有 CI checks 通过，PR review 无阻塞问题" 并结束循环。
 
 ### Step 4: 分析并处理 Review 评论
 
-对于每个未解决的评论：
+对于每个未解决的评论（来自 3a inline、3b issue comment、3c PR description summary）：
 
-1. **读取完整源文件**：用 Read 工具读取评论所在的 `path` 文件
+1. **读取相关源文件**：
+   - inline 评论：用 Read 工具读取评论所在的 `path` 文件
+   - issue comment / PR description summary：从 body 中解析出涉及的文件路径（通常是 `src/foo.ts:123` 格式），逐个 Read
 2. **理解评论内容**：仔细阅读 `body` 中指出的具体问题
 3. **结合上下文判断**：评论是否正确？
 
@@ -200,11 +243,19 @@ gh api graphql -f query='{
 - 回复评论确认修复：
 
 ```bash
+# inline review comment（来自 3a）
 gh api repos/OWNER/REPO/pulls/PR_NUMBER/comments/COMMENT_DATABASE_ID/replies \
   -f body="Fixed — <简述修改内容>"
+
+# PR 顶层 issue comment（来自 3b）— 没有 thread，直接在 PR 主时间线新增一条
+# 回复链接用完整 URL（GitHub 不会把 #COMMENT_ID 解析成 comment 跳转）
+gh pr comment PR_NUMBER --body "Fixed — <简述修改内容>（回复 [评论](https://github.com/OWNER/REPO/pull/PR_NUMBER#issuecomment-ISSUE_COMMENT_ID)）"
+
+# PR description summary 条目（来自 3c）— 同样在 PR 主时间线回复
+gh pr comment PR_NUMBER --body "Addressed — <简述修改内容>"
 ```
 
-- Resolve 该 thread：
+- Resolve 该 thread（仅 inline review thread 适用，issue comment 和 description summary 无 thread 可 resolve）：
 
 ```bash
 gh api graphql -f query='mutation {
@@ -219,11 +270,15 @@ gh api graphql -f query='mutation {
 1. 回复评论说明原因：
 
 ```bash
+# inline review comment（来自 3a）
 gh api repos/OWNER/REPO/pulls/PR_NUMBER/comments/COMMENT_DATABASE_ID/replies \
   -f body="Not an issue — <具体解释，引用代码说明 reviewer 的判断为什么不适用于此场景>"
+
+# PR 顶层 issue comment / description summary（来自 3b/3c）
+gh pr comment PR_NUMBER --body "Not an issue — <具体解释>"
 ```
 
-2. Resolve 该 thread：
+2. Resolve 该 thread（仅 inline review thread 适用）：
 
 ```bash
 gh api graphql -f query='mutation {
@@ -246,10 +301,12 @@ gh api graphql -f query='mutation {
 - 输出 "🔄 第 N 轮：修复 X 个 CI 问题 + Y 个 review 问题，反驳 Z 个误报，等待新一轮 checks..."
 - 回到 Step 1
 
-**如果只有误报被 resolve（无代码修复）且 CI 全部通过：**
-- 输出 "✅ 第 N 轮：反驳 Y 个误报并 resolve，所有 CI checks 通过"
+**如果本轮所有 review 反馈都已处理（inline 已 reply+resolve、3b/3c 已 reply）且无代码修复且 CI 全部通过：**
+- 输出 "✅ 第 N 轮：处理 Y 个 review 反馈（含 Z 个反驳），所有 CI checks 通过"
 - 结束循环
 
+> 注意：3b/3c 没有 thread 可以 resolve，"已处理"的标准是已经发出 `gh pr comment` 回复。不要因为"没有 resolve 动作"就误判为未处理而陷入死循环。
+
 ---
 
 ## 完成汇总

.env.example

@@ -20,6 +20,10 @@ ALLOWED_USER_IDS=
 # 为空时自动将首个发消息的用户设为管理员
 OWNER_USER_ID=
 
+# === Session Fork 配置 (Plan 8) ===
+# /fork 命令开关,默认开启。设为 false 可关闭
+# FORK_ENABLED=false
+
 # === Claude Code 配置 ===
 # Anthropic API Key (Claude Code 需要)
 ANTHROPIC_API_KEY=sk-ant-xxxxxxxx

.github/workflows/claude-comment.yml

@@ -56,6 +56,8 @@ jobs:
         run: bun install --frozen-lockfile
 
       - uses: anthropics/claude-code-action@v1
+        env:
+          ANTHROPIC_BASE_URL: https://llm-proxy.tapsvc.com
         with:
           anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
           trigger_phrase: "@claude"

.github/workflows/pr-review.yml

@@ -40,6 +40,8 @@ jobs:
         run: bun install --frozen-lockfile
 
       - uses: anthropics/claude-code-action@v1
+        env:
+          ANTHROPIC_BASE_URL: https://llm-proxy.tapsvc.com
         with:
           anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
           github_token: ${{ github.token }}

.gitignore

@@ -1,6 +1,7 @@
 node_modules/
 dist/
 data/
+!src/cron/holidays/data/
 logs/
 .env
 *.log

CLAUDE.md

@@ -72,6 +72,7 @@ Feishu User → Feishu Platform → Bridge Server → Claude Agent SDK → Claud
 - **`settingSources: ['project']`** loads `.claude/settings.local.json` from cwd, including `permissions.allow` whitelist. This whitelist is checked *before* `canUseTool`, so unlisted tools (including MCP) get blocked. Currently `canUseTool` with proper `updatedInput` overrides this.
 - **Skills require `allowedTools: ['Skill']`** — SDK 默认不启用 Skill 工具。仅有 `settingSources: ['project']` 不够，还需在 `allowedTools` 中显式包含 `'Skill'`，否则 `.claude/skills/` 中的 SKILL.md 不会被加载。
 - **Feishu rich text breaks URLs** — `github.com:user/repo` gets auto-linked by Feishu as `[github.com:](http://github.com/)user/repo`. The `workspace/manager.ts` `normalizeRepoUrl()` handles SSH shorthand normalization.
+- **`options.env` 完全替换子进程环境(SDK 0.3.x)** — 一旦传入 `env`,子进程**不再继承**父进程环境,必须自行展开:`{ ...process.env, ANTHROPIC_BASE_URL: ... }`。否则会丢失 `ANTHROPIC_API_KEY` / `PATH` / `HOME`,导致 Claude Code 返回 `Not logged in · Please run /login`。仅在配了代理 `ANTHROPIC_BASE_URL` 时才需要传 `env`(见 `claude/executor.ts`)。注意 0.2.x 是**合并**语义(`{...process.env, ...你的}`),升级到 0.3.x 时这是隐蔽的破坏性变更。
 
 ## Configuration
 
@@ -104,6 +105,7 @@ Loaded via dotenv (see `.env.example`):
 ## Deployment
 
 - 部署方式取决于运行环境（PM2、systemd、Docker 等），服务启动时自动检测进程管理器类型（见 `src/utils/runtime.ts`）。
+- **升级/拉取后必须跑 `npm install`** — `@anthropic-ai/claude-agent-sdk` 0.3.x 起,Claude Code CLI 二进制改为通过 `optionalDependencies` 按平台分发(`@anthropic-ai/claude-agent-sdk-<platform>`,约 240MB)。只 `git pull` + 重新 `npm run build` + 拷 `dist/` **不会**拉到该二进制,服务会起不来。`npm install` 会按 OS/CPU/libc 自动选包(glibc/musl、x64/arm64 均有)。同理,`@anthropic-ai/sdk` 与 `@modelcontextprotocol/sdk` 在 0.3.x 是 peerDependencies,已提为本仓库的直接依赖。
 - **自重启须在对话最后一步执行** — Claude 是服务的子进程，使用 `sleep 5 && <restart command> &` 脱离当前进程，避免 kill 自己的父进程导致对话中断。
 
 ## Tech Stack