add-coder 0.1.0

package/templates/core/prisma/add.prisma

@@ -0,0 +1,34 @@
+// add.prisma — ADD 治理模型（npm 包写入，不修改用户业务文件）
+// 前置条件：用户项目必须已有 User 模型（id: String），否则 prisma migrate 失败
+
+model DevOperation {
+  id          String   @id @default(cuid())
+  userId      String
+  user        User     @relation(fields: [userId], references: [id], onDelete: Cascade)
+  planKeyword String
+  action      String
+  targetType  String
+  targetId    String
+  beforeState Json?
+  afterState  Json?
+  reason      String?
+  createdAt   DateTime @default(now())
+
+  @@index([planKeyword])
+}
+
+model AuditLog {
+  id          String   @id @default(cuid())
+  userId      String
+  user        User     @relation(fields: [userId], references: [id], onDelete: Cascade)
+  action      String
+  targetType  String
+  targetId    String
+  traceId     String?
+  beforeState Json?
+  afterState  Json?
+  reason      String?
+  createdAt   DateTime @default(now())
+
+  @@index([traceId])
+}

package/templates/core/reports/REPORT-WORKFLOW.md

@@ -0,0 +1,250 @@
+# Report 工作流
+
+> Reports 目录的生成、消费、归档规范。遵循 [Runtime Reports ↔ 静态 Reports 边界划分](./boundary-runtime-report.md)。
+
+---
+
+## 目录结构
+
+```
+.qoder/reports/
+├── REPORT-WORKFLOW.md                ← 本文件
+├── boundary-runtime-report.md        ← Runtime Report ↔ 静态 Report 边界划分
+├── index.md                          ← Issue 注册表（由 gen-report-index.sh 每天自动生成，勿手动编辑）
+├── combined-report.md                ← 当前活跃的综合报告（模板: templates/report-template.md）
+├── {{projectName}}-runtime-report/        ← 运行时报告目录（按子系统分类）
+│   ├── gateway.md                    ← Gateway 边界合约断裂（appendRuntimeFinding 自动写入）
+│   ├── rag.md                        ← RAG 检索异常（未来）
+│   └── agent.md                      ← Agent Node 执行异常（未来）
+├── runtime-issue-{id}.md             ← Runtime Report 子系统自动生成的 Issue 草稿（人工 triage 后合并删除）
+├── suggestions.md                    ← 临时审查建议（合并后删除，内容已归入 combined-report.md）
+└── archive/                    ← 历史报告归档
+    └── combined-report-{YYYY-MM-DD}.md
+```
+
+---
+
+## Report 生命周期
+
+```
+                    ┌─────────────────┐
+                    │  触发方式        │
+                    └───────┬─────────┘
+                            │
+        ┌───────────────────┼───────────────────┐
+        ▼                   ▼                   ▼
+   全量代码扫描         增量审查            运行时异常
+   (定期/按需)        (合并前/发布前)     (Runtime Report 子系统自动)
+        │                   │                   │
+        ▼                   ▼                   ▼
+  新建 combined-        追加 Issue        生成 runtime-issue-{id}.md
+  report.md            到已有报告         (草稿，待人工 triage)
+        │                   │                   │
+        └───────────────────┼───────────────────┘
+                            │
+                            ▼
+                    ┌───────────────┐
+                    │  人工 Triage   │
+                    │  (协同同事)    │
+                    └───────┬───────┘
+                            │
+                ┌───────────┼───────────┐
+                ▼           ▼           ▼
+           确认为 Bug   环境问题      已知问题
+                │           │           │
+                ▼           ▼           ▼
+           分配优先级    关闭草稿     合并到已有
+           补充根因      (标注原因)    Issue
+                │
+                ▼
+        ┌───────────────┐
+        │  进入 Plan 流程 │
+        │  (ADD 范式)    │
+        └───────┬───────┘
+                │
+                ▼
+        ┌───────────────┐
+        │  修复 + 验证   │
+        └───────┬───────┘
+                │
+        ┌───────┴───────┐
+        ▼               ▼
+    标记 ✅          Runtime Report 运行时验证
+    (人工确认)       (自动: 请求路径跑通 → verified_at)
+        │               │
+        └───────┬───────┘
+                │
+                ▼
+        ┌───────────────┐
+        │  归档          │
+        │  阶段性完成后   │
+        │  移动到 archive/│
+        └───────────────┘
+```
+
+---
+
+## 何时创建新 Report
+
+| 场景 | 操作 | 说明 |
+|------|------|------|
+| 首次代码审查 | 新建 `combined-report.md` | 使用 [report-template.md](../templates/report-template.md) |
+| 定期全量扫描 | 旧报告 → `archive/`，新建 | 同上 |
+| 增量审查（合入前） | 追加 Issue 到已有报告 | 不新建，更新状态列 |
+| Runtime Report 新异常 | 生成 `runtime-issue-{id}.md` | 草稿，等待 triage |
+| 新建运行时报告子系统 | 新建 `{{projectName}}-runtime-report/{subsystem}.md` | 使用 [runtime-report-template.md](../templates/runtime-report-template.md) |
+| 发布前验证 | 基于已有报告生成 `fix-verification-report.md` | 使用 [fix-verification-template.md](../templates/fix-verification-template.md) |
+
+---
+
+## Issue 编号规范
+
+```
+RPT-{YYYYMMDD}-{seq}
+  │      │        │
+  │      │        └── 当日序号，从 01 开始
+  │      └─────────── 生成日期
+  └────────────────── 固定前缀 (Report)
+```
+
+示例：`RPT-20260701-03` = 2026年7月1日第3个 Issue
+
+Runtime Report 草稿使用 `RUNTIME-{YYYYMMDD}-{seq}` 前缀，合并后改为 `RPT-` 前缀。
+
+---
+
+## Triage → Plan 流程
+
+> Runtime Report 草稿经人工 triage 后，转入 ADD 范式 Plan 管线。
+
+```
+runtime-issue-{date}-{seq}.md
+       │
+       ▼ (人工 triage)
+   ┌───┴───┐
+   ▼       ▼
+真实 Bug  环境/测试
+   │       │
+   │       └── 删除草稿，标注关闭原因
+   │
+   ▼
+创建 runtime-fix-plan-v1.md
+   │  命名: {子系统}-runtime-fix-{关键词}-plan-v1.md
+   │  位置: .qoder/plans/{YYYY-MM}/{DD}/
+   │  模板: plan-template.md
+   │
+   ▼
+进入 ADD 范式（Step 0-9）
+   │
+   ├── Step 0: 方案设计
+   ├── Step 1-3: Spec + Checklist
+   ├── Step 4-7: 实施
+   ├── Step 8: 验收 → handoff + devlog
+   ├── Step 9: Report Closure（runtime-fix plan）→ gateway.md 追 `- [x]`
+   │
+   ▼
+修复完成后 → combined-report.md 标记 ✅
+```
+
+### Triage 判定标准
+
+| 判定 | 条件 | 操作 |
+|------|------|------|
+| **Plan 修复** | 真实 Bug，影响生产或有复发风险 | 创建 runtime-fix-plan → ADD 范式 |
+| **关闭** | 环境问题（已修复）、测试触发、不复现 | 删除 runtime-issue 草稿，gateway.md 中标注关闭原因 |
+| **合并** | 与已有 Report Issue 重复 | 合并到已有 RPT-{id}，删除草稿 |
+
+### 草稿关闭标记
+
+决定关闭的 runtime-issue 草稿，在 gateway.md 对应发现条目体末尾追加 checklist 标记（`check-boundary-report.ts` L58-60 通过解析 `- [x]` 行判断关闭状态）：
+
+```markdown
+- [x] Triage 结果: 已关闭 — {原因}
+```
+
+> **格式说明**：使用 `- [x]` checklist 格式而非 `**Triage 结果**` 粗体格式。
+> 完整 handoff 集成流程见 [report-handoff-template](../templates/report-handoff-template.md)。
+> runtime-fix plan 的 Step 9 Report Closure 负责统一关闭。
+
+---
+
+## 协作协议
+
+### 单人工作
+
+1. 新建 Report → 填充 Issue → 修代码 → 更新状态 → 归档
+
+### 多人协同
+
+1. **生成方**（扫描 / Runtime Report 子系统）: 创建 Report 或 Issue 草稿
+2. **Triage 方**（协同同事）: 阅读草稿，确认/关闭，分配优先级
+3. **修复方**（开发者）: 按优先级修复，更新 Issue 状态
+4. **验证方**（Runtime Report 子系统 / 人工）: 运行时验证或 E2E 验证，写回结果
+
+**冲突避免**:
+- 同一 Report 不要两人同时编辑
+- 用 Git 管理：`git pull` → 编辑 → `git commit` → `git push`
+- 或者拆分为独立 Issue 文件（`issues/RPT-{id}.md`），避免合并冲突
+
+---
+
+## 运行时反馈流程（Runtime Report → Reports）
+
+```
+1. Runtime Report 子系统捕获异常
+       │
+2. appendRuntimeFinding() 去重检查
+       ├── 已记录 → count++ → 不生成新草稿
+       └── 新异常 → 生成 runtime-issue-{id}.md
+              │
+3. 协同同事定期扫描 runtime-issue-*.md
+       │
+4. Triage:
+   ├── 真实 Bug → 分配 RPT-{id}, 转入 combined-report.md
+   ├── 环境问题 → 标注原因, 删除草稿
+   └── 已知问题 → 合并到已有 Issue, 更新 count
+```
+
+---
+
+## 验证反馈流程（Reports → Runtime Report）
+
+```
+1. combined-report.md 中 Issue 标记 ✅
+       │
+2. 验证方在 {{projectName}}-runtime-report/gateway.md 中增加验证条目:
+   ```
+   ### 验证: RPT-{id}
+   - 修复版本: commit {hash}
+   - 验证路径: {method} {pathname}
+   - 预期: {期望行为}
+   ```
+       │
+3. Runtime Report 子系统下次请求经过该路径:
+   ├── 成功 → {{projectName}}-runtime-report/gateway.md 追加 verified_at
+   └── 失败 → {{projectName}}-runtime-report/gateway.md 追加 regression_at → Issue 回退为 ❌
+```
+
+---
+
+## 归档规则
+
+| 条件 | 操作 |
+|------|------|
+| Report 中所有 Issue 标记 ✅ 或关闭 | 移动到 `archive/combined-report-{YYYY-MM-DD}.md` |
+| 新 Report 生成时 | 旧 Report 移动到 `archive/` |
+| 单次增量审查完成 | 不归档，持续追加到活跃 Report |
+| runtime-issue 草稿已 triage | 合并后删除草稿 |
+
+---
+
+## 关联文档
+
+| 文档 | 路径 | 用途 |
+|------|------|------|
+| 边界划分 | [boundary-runtime-report.md](./boundary-runtime-report.md) | Runtime Report ↔ 静态 Report 职责边界 |
+| Report 模板 | [report-template.md](../templates/report-template.md) | 综合审查报告模板 |
+| 运行时报告模板 | [runtime-report-template.md](../templates/runtime-report-template.md) | 子系统运行时报告模板 |
+| 修复验证模板 | [fix-verification-template.md](../templates/fix-verification-template.md) | 修复验证对照报告模板 |
+| 索引脚本 | [gen-report-index.sh](../../scripts/gen-report-index.sh) | 每日 2:10 AM 自动生成 index.md（cron: [crontab.report.txt](../../scripts/crontab.report.txt)） |
+| Plan 索引 | [index.md](../plans/index.md) | Plan 索引（Issue → Plan 关联） |

package/templates/core/reports/boundary-runtime-report.md

@@ -0,0 +1,134 @@
+# Runtime Reports ↔ 静态 Reports 边界划分
+
+> 定义 `{{projectName}}-runtime-report/`（运行时报告，按子系统分类写入）与 `reports/`（协同手工生成）的职责边界、数据流向和互操作协议。
+>
+> Runtime Report 包含多个业务域：gateway（边界合约断裂）、rag（检索异常）、agent（Node 执行）等。
+> 本文以 **gateway 子系统** 为示例说明边界划分逻辑，规则适用于全部 Runtime Report 子系统。
+
+---
+
+## 两条产线
+
+```
+┌─────────────────────────────────┐    ┌─────────────────────────────────┐
+│  Runtime Report（gateway 示例）   │    │  Reports 静态分析               │
+│  ({{projectName}}-runtime-report/gateway.md)  │    │  (reports/*.md)                 │
+├─────────────────────────────────┤    ├─────────────────────────────────┤
+│  触发: 运行时异常 / 合约断裂      │    │  触发: 代码扫描 / 人工 review     │
+│  作者: appendRuntimeFinding()   │    │  作者: 协同同事                   │
+│  格式: 自动追加 Markdown         │    │  格式: 结构化 Issue 列表          │
+│  去重: ❌ 无                     │    │  去重: ✅ 合并去重                │
+│  优先级: ❌ 无                   │    │  优先级: ✅ P0-P3                │
+│  关闭/修复: ❌ 无                │    │  关闭/修复: ✅ ✅⚠️❌ 逐条跟踪      │
+└─────────────────────────────────┘    └─────────────────────────────────┘
+         │                                      │
+         └──────────── 双向联动 ─────────────────┘
+              Runtime Finding ⇄ Report Issue
+```
+
+---
+
+## 职责边界
+
+### Runtime Report 子系统（以 gateway 为例）的职责
+
+| 职责 | 说明 | 不去做的事 |
+|------|------|-----------|
+| 捕获运行时异常 | 合约断裂、未处理错误、环境缺失 | 不做静态代码扫描 |
+| 去重聚合 | 同一 `source + path + errorMsg` 合并为一条 + 发生次数 | 不做优先级分类 |
+| 生成 Issue 草稿 | 首次出现的异常 → 在 `reports/` 下生成 `runtime-issue-{id}.md` | 不人工评估严重度 |
+| 验证修复状态 | Reports 标记 ✅ 后，下次请求路径跑通 → 自动写回 `verified_at` | 不自行关闭 Issue |
+
+### Reports 的职责（只做这些）
+
+| 职责 | 说明 | 不去做的事 |
+|------|------|-----------|
+| 静态代码审查 | 安全漏洞、死代码、架构重复、类型问题 | 不捕获运行时异常 |
+| 优先级分类 | P0（立即）/ P1（尽快）/ P2（计划）/ P3（债务） | 不自动生成 Issue |
+| 补充根因分析 | Runtime Report 子系统的草稿只含堆栈，Reports 补充业务影响和修复方案 | 不修改 Runtime Report 子系统写入的原始数据 |
+| 跟踪修复进度 | ✅ 已修复 / ⚠️ 部分修复 / ❌ 仍存在 | 不做运行时验证 |
+
+---
+
+## 数据流向
+
+```
+运行时异常发生
+       │
+       ▼
+appendRuntimeFinding() ─────────────────────────────┐
+       │                                             │
+       ├── 1. 写入 AuditLog (RUNTIME_ERROR)          │
+       │                                             │
+       ├── 2. 写入 {{projectName}}-runtime-report/gateway.md         │
+       │      └── 去重检查: 同 source+path+errorMsg   │
+       │           ├── 已存在 → count++              │
+       │           └── 新发现 → 追加 + 生成草稿       │
+       │                                             │
+       └── 3. 生成 reports/runtime-issue-{id}.md ────┘
+                    │
+                    ▼ (协同同事接手)
+              Reports 人工 triage
+                    │
+                    ├── 补充优先级、分类、修复建议
+                    ├── 合并到 combined-report.md
+                    └── 标记为 P1/P2 后 → Plan 流程
+                                              │
+                                              ▼ (修复完成后)
+                                    Reports 标记 ✅
+                                              │
+                                              ▼ (Runtime Report 运行时验证)
+                                   下次请求跑通同一路径
+                                   → {{projectName}}-runtime-report/gateway.md 写回 verified_at
+                                   → Issue 自动标记为 "已验证"
+```
+
+---
+
+## 互操作协议
+
+### 1. Runtime Report → Reports: Issue 草稿
+
+Runtime Report 子系统发现新异常时，在 `reports/` 下生成最小草稿：
+
+```markdown
+# RUNTIME-{YYYYMMDD}-{seq}
+
+- **来源**: Gateway 运行时 (`{{projectName}}-runtime-report/gateway.md`)
+- **首次发生**: {timestamp}
+- **发生次数**: 1
+- **错误**: {errorMsg}
+- **路径**: {method} {pathname}
+- **堆栈**: (见 {{projectName}}-runtime-report/gateway.md 对应条目)
+
+> 此草稿由 Gateway 自动生成，待人工 triage 后合并到 combined-report.md。
+```
+
+Reports 侧接收后：
+- 确认是否为真实 Bug（排除环境问题）
+- 分配优先级和分类
+- 补充业务影响描述
+- 合并入 `combined-report.md`，原草稿可删除
+
+### 2. Reports → Runtime Report: 验证请求
+
+Reports 中标记为 ✅ 的 Issue，Runtime Report 子系统在下次对应路径的请求中：
+- 请求成功 → 写入 `verified_at: {timestamp}` → Issue 自动标记 "已验证"
+- 请求仍失败 → 写入 `regression_at: {timestamp}` → Issue 自动回退为 ❌
+
+### 3. 双向引用格式
+
+- `{{projectName}}-runtime-report/gateway.md` 中每条发现增加 `report-issue: RUNTIME-{id}` 引用
+- `reports/combined-report.md` 中每条 Issue 增加 `runtime-finding: {{projectName}}-runtime-report/gateway.md#L{line}` 引用
+- 确保可双向追溯
+
+---
+
+## 现有问题
+
+| 问题 | 表现 | 修复方向 |
+|------|------|---------|
+| Runtime Report 无去重 | `{{projectName}}-runtime-report/gateway.md` 452 行，90% 是重复条目 | `appendRuntimeFinding()` 增加去重逻辑 |
+| Reports 三份文件重叠 | `suggestions.md` ⊆ `combined-report.md`，`fix-verification.md` 跟踪同一批 Issue | 合并为单一 Issue 注册表 + 每条 Issue 独立文件 |
+| 无双向引用 | 两份产物互不知晓对方存在 | 增加 `report-issue` / `runtime-finding` 交叉引用 |
+| Runtime Report 不感知 Reports 修复状态 | Reports 标记 ✅ 后 Runtime Report 不知道需要验证 | 增加验证请求协议 |

package/templates/core/reports/code-review-combined-report.md

@@ -0,0 +1,227 @@
+# {{projectName}} 项目代码审查综合报告
+
+> 生成时间：2026-06-29  
+> 来源：`code-review-suggestions.md`（历史审查）+ 本次全量代码审查  
+> 格式：合并去重，逐条验证当前代码状态
+
+---
+
+## 问题总览
+
+| 分类 | 数量 |
+|------|------|
+| 安全风险 | 2 |
+| 代码重复 / 架构问题 | 7 |
+| 健壮性 / 边界条件 | 5 |
+| 代码整洁 | 7 |
+| 基础设施 / 运维 | 3 |
+| **总计** | **24** |
+
+---
+
+## 一、安全风险
+
+### 1. JWT 硬编码默认密钥
+
+- **文件**: [src/lib/auth.ts:3](file://{{projectRoot}}/src/lib/auth.ts#L3)
+- **状态**: 仍存在
+- **描述**: `JWT_SECRET = process.env.JWT_SECRET || "dev-secret-key"`，生产环境若漏配环境变量将使用可预测的弱密钥
+- **建议**: 生产环境强制要求配置，缺失时直接拒绝启动（`throw new Error`）
+
+### 2. QWeather JWT 签名是占位符
+
+- **文件**: [src/lib/farm-server-client.ts:74-76](file://{{projectRoot}}/src/lib/farm-server-client.ts#L74-L76)
+- **状态**: 仍存在
+- **描述**: `createQWeatherJwt()` 中 EdDSA 签名写死为 `"PLACEHOLDER_SIGNATURE"`，注释说"实际迁移 co-agent 天气工具时会携带完整的 JWT 签名实现"，生产环境会导致认证失败
+- **建议**: 完成 JWT 签名实现，或在使用处增加强校验拦截
+
+---
+
+## 二、代码重复 / 架构问题
+
+### 3. LLM 模块重复（`llm.ts` vs `llm/index.ts`）
+
+- **文件**: [src/lib/llm.ts](file://{{projectRoot}}/src/lib/llm.ts) / [src/lib/llm/index.ts](file://{{projectRoot}}/src/lib/llm/index.ts)
+- **状态**: 仍存在
+- **描述**: 旧版 `llm.ts` 使用 `globalForLLM` 模式 + IIFE，新版 `index.ts` 使用 `AuditedLLM` 包装类。`agents/index.ts` 实际引用 `@/lib/llm/index`，旧文件成死代码。两个文件还各自定义了 `MultimodalContent` / `MultimodalMessage` 类型
+- **建议**: 删除 `src/lib/llm.ts`，统一使用 `src/lib/llm/index.ts`
+
+### 4. Chroma 客户端重复（`chroma.ts` vs `chroma-client.ts`）
+
+- **文件**: [src/lib/chroma.ts](file://{{projectRoot}}/src/lib/chroma.ts) / [src/lib/chroma-client.ts](file://{{projectRoot}}/src/lib/chroma-client.ts)
+- **状态**: 仍存在
+- **描述**: 两个 ChromaDB 客户端实现，一个用 `chromadb` npm 包，一个用原生 HTTP fetch，功能重叠
+- **建议**: 统一为一个客户端模块
+
+### 5. `extractTokenFromRequest` 重复定义
+
+- **文件**: [src/lib/auth.ts:27](file://{{projectRoot}}/src/lib/auth.ts#L27) / [src/caijuehub/strategies/auth-gateway.ts:59](file://{{projectRoot}}/src/caijuehub/strategies/auth-gateway.ts#L59)
+- **状态**: 仍存在
+- **描述**: 同一函数在 `auth.ts` 和 `auth-gateway.ts` 中各定义一次，注释说"避免循环依赖"，造成维护负担
+- **建议**: 提取到独立工具模块，或从 `auth.ts` 导出后由 `auth-gateway.ts` 引用
+
+### 6. 8+ 个日志模块共享相同代码模式
+
+- **文件**: `chat-persistence-logger.ts`、`stream-bus-logger.ts`、`audit-logger.ts`、`stream-chat-logger.ts`、`agent-gateway-dev-logger.ts` 等
+- **状态**: 仍存在
+- **描述**: 每个日志模块都有几乎相同的 `ensureLogDir()` / `writeToFile()` / `formatMessage()` 实现，大量重复代码
+- **建议**: 提取公共日志基础设施模块
+
+### 7. `agent-gateway-dev-logger.ts` 与 `agent-gateway-audit.ts` 行为不一致
+
+- **文件**: [src/lib/agent-gateway-dev-logger.ts:12](file://{{projectRoot}}/src/lib/agent-gateway-dev-logger.ts#L12) / [src/lib/agent-gateway-audit.ts](file://{{projectRoot}}/src/lib/agent-gateway-audit.ts)
+- **状态**: 仍存在
+- **描述**: `agent-gateway-dev-logger.ts` 仅在 `IS_DEV` 时输出日志，`agent-gateway-audit.ts` 始终输出。两个模块功能重叠但行为不一致
+- **建议**: 统一为一个网关审计模块
+
+### 8. `audit-log.ts` 内存存储审计日志
+
+- **文件**: [src/services/audit-log.ts:30](file://{{projectRoot}}/src/services/audit-log.ts#L30)
+- **状态**: 仍存在
+- **描述**: `auditLogs` 数组只存内存，进程重启全部丢失。与 `agent-audit-logger.ts` 的 DB 持久化方案不一致
+- **建议**: 统一使用 DB 持久化，或明确标注为仅开发环境使用
+
+### 9. `agents/index.ts` 职责过大（468 行）
+
+- **文件**: [src/agents/index.ts](file://{{projectRoot}}/src/agents/index.ts)
+- **状态**: 仍存在
+- **描述**: 同时包含 StateGraph 定义、ToolNode 包装器、审计包装器、`runAgent`/`streamAgent` 入口、Tracer 管理、`buildPartialState`
+- **建议**: 拆分为 `graph.ts`、`tool-node-wrapper.ts`、`audit-wrapper.ts`、`agent-runner.ts`
+
+---
+
+## 三、健壮性 / 边界条件
+
+### 10. LLM 单例竞态条件
+
+- **文件**: [src/lib/llm/index.ts:215-248](file://{{projectRoot}}/src/lib/llm/index.ts#L215-L248)
+- **状态**: 仍存在
+- **描述**: `setLLMConfig()` 会调用 `resetLLM()` 将 `llmInstance` 置为 `null`，并发请求携带不同 `modelConfig` 时，A 请求的重置可能影响 B 请求正在使用的实例
+- **建议**: 改为按请求/线程隔离的 LLM 实例，或使用请求级缓存
+
+### 11. `activeTracers` Map 潜在内存泄漏
+
+- **文件**: [src/agents/index.ts:239](file://{{projectRoot}}/src/agents/index.ts#L239)
+- **状态**: 仍存在
+- **描述**: 清理依赖 `endChainTrace()` 被调用。如果流式请求异常中断（客户端断开），`endChainTrace` 可能不会被调用，Map 持续增长
+- **建议**: 增加 TTL 过期机制或定期清理
+
+### 12. 审计日志静默吞错
+
+- **文件**: [src/lib/agent-audit-logger.ts:175-180](file://{{projectRoot}}/src/lib/agent-audit-logger.ts#L175-L180)
+- **状态**: 仍存在
+- **描述**: `writeAuditLog()` 的 catch 块只做 `console.error`，`ensureLogDir()` 的 catch 完全忽略。DB 不可用时所有审计记录静默丢失
+- **建议**: 增加失败计数器或 metric 上报
+
+### 13. 缺少请求体运行时校验
+
+- **文件**: [src/app/api/agent/chat/route.ts:17](file://{{projectRoot}}/src/app/api/agent/chat/route.ts#L17)
+- **状态**: 仍存在
+- **描述**: 直接 `await request.json()` 后做类型断言，没有用 Zod 或类似库做运行时校验。格式错误的请求体会在深层抛出不友好的异常
+- **建议**: 引入 Zod schema 进行请求体校验
+
+### 14. Model config 使用 `require()` 动态加载
+
+- **文件**: [src/lib/llm/index.ts:246-247](file://{{projectRoot}}/src/lib/llm/index.ts#L246-L247)
+- **状态**: 仍存在
+- **描述**: `require("@/lib/model-config-logger")` 动态加载，ESM 环境下可能不稳定。注释 `// Logger unavailable in server context` 说明有已知问题
+- **建议**: 改为静态 import 或明确的依赖注入
+
+---
+
+## 四、代码整洁
+
+### 15. 大量 `as any` / `as unknown as` 类型断言
+
+- **文件**: [src/agents/index.ts](file://{{projectRoot}}/src/agents/index.ts) 等多处
+- **状态**: 仍存在（约 119 处 `any` 使用）
+- **描述**: 消息类型转换、toolResults 赋值等大量绕过 TypeScript 类型检查
+- **建议**: 逐步用类型守卫或 zod schema 替代
+
+### 16. `knowledge-indexer.ts` 遗留调试日志
+
+- **文件**: [src/services/knowledge-indexer.ts:568-586](file://{{projectRoot}}/src/services/knowledge-indexer.ts#L568-L586)
+- **状态**: 仍存在
+- **描述**: `[RAG-DEBUG]` 前缀的 `console.log` 在生产环境也会输出，应改为条件日志
+- **建议**: 改为仅在 `NODE_ENV=development` 时输出
+
+### 17. 未完成的 TODO
+
+- **文件**: [src/agents/policy-update-loop.ts:149](file://{{projectRoot}}/src/agents/policy-update-loop.ts#L149)
+- **状态**: 仍存在
+- **描述**: `// TODO: 根据 pathMetrics 定制提示语——第 7 轮设计 reserve 但未实现`
+- **建议**: 完成实现或移除 TODO
+
+### 18. `AgentAuditPhase` 类型过于庞大（80+ 联合成员）
+
+- **文件**: [src/lib/agent-audit-logger.ts:15-143](file://{{projectRoot}}/src/lib/agent-audit-logger.ts#L15-L143)
+- **状态**: 仍存在
+- **描述**: 80+ 个联合成员，维护困难且容易拼写错误
+- **建议**: 按域拆分为多个子类型，或改为 `string` 类型 + 常量枚举
+
+### 19. 脚本目录过于庞大（60+ 文件）
+
+- **文件**: `scripts/` 目录
+- **状态**: 仍存在（实际 60+ 文件）
+- **描述**: 包含一次性迁移脚本（`backfill-projectId.ts`、`fix-knowledge-data.js`、`restore-from-dump.js`）、Windows `.bat` 和 Unix `.sh` 双份
+- **建议**: 将一次性脚本归档到单独目录
+
+### 20. Prisma 多文件 Schema 注释与实际路径不一致
+
+- **文件**: [prisma/schema.prisma:12-14](file://{{projectRoot}}/prisma/schema.prisma#L12-L14)
+- **状态**: 仍存在
+- **描述**: 注释说子文件在 `prisma/schema/` 目录下，但实际 `main.prisma` 和 `nongqing.prisma` 在 `prisma/` 根目录。且 `prisma/dev.db`（SQLite 文件）存在，说明开发环境可能混用了 SQLite 和 PostgreSQL
+- **建议**: 修正注释或移动文件，清理 `dev.db`
+
+### 21. 项目中大量 `console.log`（842+ 处）
+
+- **文件**: 全局
+- **状态**: 仍存在
+- **描述**: 大量 `console.log/warn/error` 散落在 100+ 个文件中，部分本应使用专用日志模块
+- **建议**: 逐步替换为结构化日志模块
+
+---
+
+## 五、基础设施 / 运维
+
+### 22. Chroma 端口未绑定 localhost
+
+- **文件**: [docker-compose.yml:50](file://{{projectRoot}}/docker-compose.yml#L50)
+- **状态**: 仍存在
+- **描述**: Chroma 端口映射为 `"8000:8000"`，没有绑定到 `127.0.0.1`，而 PostgreSQL 是 `"127.0.0.1:5433:5432"`。公网部署时 Chroma 8000 端口暴露在外
+- **建议**: 改为 `"127.0.0.1:8000:8000"`
+
+### 23. Docker Compose 资源限制被注释
+
+- **文件**: [docker-compose.yml:30-36](file://{{projectRoot}}/docker-compose.yml#L30-L36) / [docker-compose.yml:60-67](file://{{projectRoot}}/docker-compose.yml#L60-L67)
+- **状态**: 仍存在
+- **描述**: PostgreSQL 和 Chroma 的 `deploy.resources` 全部被注释，生产环境无资源限制
+- **建议**: 根据实际负载启用 resource limits
+
+---
+
+## 六、本次审查新增发现
+
+以下为本次审查独立发现、`code-review-suggestions.md` 未覆盖的问题：
+
+| # | 问题 | 文件 | 严重度 |
+|---|------|------|--------|
+| 25 | `extractTokenFromRequest` 重复定义 | [auth.ts](file://{{projectRoot}}/src/lib/auth.ts#L27) / [auth-gateway.ts](file://{{projectRoot}}/src/caijuehub/strategies/auth-gateway.ts#L59) | 中 |
+| 26 | Chroma 客户端双实现 | [chroma.ts](file://{{projectRoot}}/src/lib/chroma.ts) / [chroma-client.ts](file://{{projectRoot}}/src/lib/chroma-client.ts) | 中 |
+| 27 | 日志模块行为不一致 | [agent-gateway-dev-logger.ts](file://{{projectRoot}}/src/lib/agent-gateway-dev-logger.ts) vs [agent-gateway-audit.ts](file://{{projectRoot}}/src/lib/agent-gateway-audit.ts) | 中 |
+| 28 | 审计日志内存存储 vs DB 持久化不一致 | [audit-log.ts](file://{{projectRoot}}/src/services/audit-log.ts) | 中 |
+| 29 | `AgentAuditPhase` 类型 80+ 联合成员 | [agent-audit-logger.ts](file://{{projectRoot}}/src/lib/agent-audit-logger.ts) | 低 |
+| 30 | `knowledge-indexer.ts` RAG-DEBUG 日志遗留 | [knowledge-indexer.ts](file://{{projectRoot}}/src/services/knowledge-indexer.ts) | 低 |
+| 31 | 未完成 TODO | [policy-update-loop.ts](file://{{projectRoot}}/src/agents/policy-update-loop.ts) | 低 |
+| 32 | 大量 `console.log` 散落 | 全局 100+ 文件 | 低 |
+
+---
+
+## 修复优先级建议
+
+| 优先级 | 问题编号 | 说明 |
+|--------|---------|------|
+| P0 立即修复 | #1, #2 | 安全风险：JWT 弱密钥 + QWeather 占位签名 |
+| P1 尽快修复 | #10, #11, #12 | 健壮性：竞态条件、内存泄漏、审计静默吞错 |
+| P2 计划修复 | #3, #4, #5, #6, #7, #8, #9, #13, #14, #15 | 代码重复、架构问题、缺少校验 |
+| P3 技术债务 | #16, #17, #18, #19, #20, #21, #22, #23 | 代码整洁、基础设施 |