增量代码质检报告：code-scan-insight v1.6.42

• 项目：codescan/code-scan-insight
• 分支：v1.6.42
• 对比区间：f935da3（base） → ab79aaf3（head）
• 主题：时区口径统一（UTC → 北京时间 Asia/Shanghai），附带「无明细」占位展示与相应测试补齐
• 变更规模：18 个文件（13 改 / 5 新增），无删除文件

说明：本报告「修复/新增问题」章节全部来自 codescan_issues_diff 的真实数据；对每条结论的真伪判定（是否由本次改动真实引入）为结合 base/head 逐文件问题清单与 diff 的复核结论。

---

一、变更概览

改动围绕一个明确的缺陷：会话时区恒为 UTC（lib/db.ts），此前大量 ::date / date_trunc('week'|'month', now()) / toISOString().slice(0,10) 均按 UTC 分桶，导致北京 00:00–08:00 的提交被算到前一天/上一周/上一月，且趋势图日期标签整体提前一天。本次统一为北京墙钟口径。

结论先行：这是一次方向正确、覆盖面广的口径统一改造，核心表达式已被单测/真库集成测试钉死，风险可控。本次未引入 Critical/High 级问题，新增问题集中为 Low/Medium 风格与既有复杂度告警；但存在若干注释与实现不一致的遗留文档问题值得一并清理。

---

二、修复的问题（issues_diff：修复 4 条）

即：真正被消除的只有 1 条（members-profile 高耦合）；其余 3 条是行号偏移导致的「假修复」，对应问题在 head 以「新增」形式重新出现（见下节）。这类按行号匹配的告警在本次「大范围插行」的改动中会产生系统性噪声，解读时需注意。

---

三、新增的问题（issues_diff：新增 9 条）

3.1 真实由本次改动引入（6 条）

3.2 行号漂移（3 条，实为 base 既有问题换行重现）

净评：本次真实新增 6 条（3 条测试风格 + 2 条命名误报 + 1 条耦合越线），其余 3 条为行号噪声，可与「修复」章节的 3 条假修复相互抵消。

---

四、深度缺陷分析（本次改动自引入 / 需关注）

以下为结合改动内容的复核发现，未被质检引擎收录，建议一并处理：

R1｜文档/注释与实现不一致（Low，易误导后续维护）

口径已统一为北京，但多处注释仍写「UTC」：

• lib/scoring/trend.ts 文件头：时区约定（docs/06 §七）：一律按 UTC 聚合 —— 与现在全线北京口径矛盾；
• lib/scoring/trend.ts:28 残留孤立注释 /** 本周一 00:00 UTC */（原 weekStart 已删除，注释未删）；
• lib/queries.ts getCodeOutput 文档：窗口（UTC，与 getDashboardStats 同口径）；
• lib/queries.ts LIST_MEMBER_RANKINGS_SQL 文档：窗口边界：date_trunc('week'/'month', now()) 自然窗口起点（SQL 已改北京）；
• lib/members-profile.ts DomainTimelinePoint 类型注释：month 'YYYY-MM' UTC。

建议：全局检索 UTC 注释，统一更新为「北京时间（Asia/Shanghai，无夏令时）」，避免与 docs 口径再次分叉。

R2｜集成测试 oracle 与被测实现不同源（Low，潜在脆弱用例）

lib/__tests__/daily-activity-date.test.ts 第二个用例注释宣称「与同一分桶表达式的 SQL 直算值一致」，但直算 SQL 用的是 c.authored_at::date（会话 UTC 日），而实现用的是 (c.authored_at AT TIME ZONE 'Asia/Shanghai')::date（北京日）。

• 二者仅在「该日无北京 0–8 点边界提交」时才相等，属于隐式依赖数据分布的断言，边界数据一出现即误报/漏报；
• 建议把直算改为 (c.authored_at AT TIME ZONE 'Asia/Shanghai')::date = DATE '2026-10-08'，与实现同源。

R3｜代码组织与重复魔数（Low）

• lib/queries.ts 将 const BJ_DAY/BJ_DAY_START/BJ_OFFSET_MS/BJ_WEEK_START/BJ_MONTH_START/BJ_TODAY_START 声明置于 import 语句之前（第 13–27 行），import 在第 29 行起——ESM 下语义合法但不符合常规可读习惯，建议移到 import 之后；
• 同文件 beijingTodayStr() 内联 8 * 3600 * 1000，未复用已定义的 BJ_OFFSET_MS，且 beijingTodayStr 之后存在多余空行。

R4｜正向评价：口径收敛与测试覆盖到位

• 分桶表达式抽为单一来源（BJ_* 片段被 queries 与 app/team/page.tsx 内联 SQL 共用），并用 beijing-sql-fragments.test.ts 钉死「不得回退为 UTC 写法」；
• 纯函数单测（beijing-day-key.test.ts）+ 真库集成测试（beijing-day-bucketing/week-month-window/daily-activity-date）覆盖「北京 0–8 点串天/串周/串月」关键边界，且带非空覆盖断言，属高质量回归防护；
• rankingWindowStart 与 LIST_MEMBER_RANKINGS_SQL、weeklyQualityClause 的窗口口径已与测试同步，口径一致性风险被有效收敛。

---

五、风险与建议

---

六、总体结论

本次改动为正确的时区口径统一（UTC → 北京），涉及查询层、评分层、页面层共 18 个文件，并配套补齐 5 个测试文件（含真库集成测试），核心表达式已被测试钉死，未引入 Critical/High 级缺陷。

质检增量结果中：

• 修复 4 条 → 仅 1 条（members-profile 高耦合）为真实修复，其余 3 条为行号漂移；
• 新增 9 条 → 6 条确由本次引入（其中 2 条为常量命名误报），3 条为行号漂移噪声；无高严重度新增。

主要遗留项为文档/注释与实现口径不一致（R1）与一处测试 oracle 不同源（R2），均属低风险、改动量小。建议在合并前顺手清理 R1/R2，即可获得一次干净的口径统一发布。