代码扫描增量报告 · v1.0.46

• 项目：codescan/code-scan
• 分支：v1.0.46
• 基线（base）：13a5e8ab4d90477d92624cdd80169541a69d01b3
• 目标（head）：8c6499fadca165fef43a33a5125953b2493a10bc
• 结论速览：本次增量仅 1 个代码文件改动（scripts/verify-commit-attribution.py，归属验收脚本），其余为文档与 hub 子模块指针。质检层面："修复 2 条 / 新增 2 条"均为同一函数因行号漂移产生的位移，净效果为复杂度小幅上升（13→16）而非改善；无 Critical/High 级新增缺陷。

---

一、变更概览

git diff 显示 4 个变更单元，其中仅 1 个为可分析代码：

功能摘要（依据 CHANGELOG，非本次可 diff 代码）

• v1.0.44–v1.0.46 hub 侧：rescan push 分析时段闸豁免、跳过 Agent 领域复核（零 token）、修复 owner/owner/repo 项目命名、从 push.ref 解析分支、无 base 推导改用最早 commit 的 parent、非 refs/heads/* 取默认分支、派发重试 attempts 6→4/退避 8s→5s 软失败止血。
• 本仓脚本侧：新增身份归属巡检能力（未映射占比 / 机器人名单 / 按人零明细覆盖率，支持 --alert cron 退出码）。

可分析范围说明：hub 为子模块，父仓库快照中不暴露其内部文件（projects_files 返回 0 文件，对子模块 git_diff 返回 HTTP 500 Invalid revision range），因此 hub 内部 3 个版本的代码变更无法在本快照做逐行质量分析，仅能依据 CHANGELOG 描述；建议对 hub 子模块单独做一次扫描。

---

二、修复的问题（源自 issues_diff 真实数据）

⚠ 重要澄清（请勿误读为净改善）：上述 2 条"修复"是行号漂移假象。base 中 main() 位于第 105 行（84 行、复杂度 13）；本次在 main() 之前插入了约 63 行的 identity_audit()，把 main() 推到第 181 行。diff 工具按「位置 + 度量」比对，旧的 105 行实例消失被记为"修复"，同时 181 行同名同度量实例被记为"新增"（见下节）。同一函数、同一问题，并未真正修复，反而更严重。

本次真实的行为改进（非质量规则捕获，需人工确认）

• main() 中 --alert / --identity / --metrics 的分发改到 Gitea token 校验之前。base 里 --metrics 模式也会因缺少 GITEA_TOKEN 而直接 return 2，属真实缺陷；head 已修正（纯指标/巡检模式不再强依赖 Gitea token）。这是一处值得记录的正确性修复。

---

三、新增的问题（源自 issues_diff 真实数据）

补充：head 全量 quality_list 该文件另有一条既有（base 也在、仅行号 78→89 漂移，故不计入 diff 的新增/修复）：

• [Low/Maintainability] 行过长 @ scripts/verify-commit-attribution.py:89（超过 120 字符）

根因：main() 现同时承担「参数定义 + --alert/--identity/--metrics 三种模式分发 + 抽样 SQL 构造 + Gitea 逐 commit 比对 + 结果汇总」五类职责，分支数随新模式增加而上升（16 个分支点、93 行），是本文件唯一实质性的可维护性问题。

---

四、新增代码质量评估（identity_audit() 与 SQL 拼接）

• identity_audit()（约 63 行）本次未触发长度/复杂度阈值（未出现在质量地图），函数内聚度尚可（三块校验：未映射占比 / 机器人名单 / 按人覆盖率），结构清晰。
• SQL 构造方式：identity_audit() 与既有 metrics() 一致，使用 Python f-string 拼 SQL（BOT_EMAILS 常量、--repo/--employee 等入参）。这是本文件的既有风格，入参均来自可信来源（代码内常量集合 / 运维 CLI 参数），非外部不可信输入，实际注入风险低。
  • 说明：质量地图中的 sql_injection 规则存在已登记误报（known_false_positives，共 1 例，对应生产代码 codescan-cli/.../sqlite/query.go，不在本次 diff 内）。本脚本的 f-string 拼接不建议按 Critical 处理；若后续要接入外部输入，应改为参数化查询。

---

五、建议行动（按优先级）

1. [中] 拆分 main()：把「模式分发（--alert/--identity/--metrics）」「抽样 SQL 构造」「逐 commit 比对循环」「结果汇总」抽为独立函数，将复杂度 16 与 93 行降回阈值内，同时消除"位移式修复/新增"的反复。
2. [低] 修复第 89 行超长行：拆分该行以消除 Low 级行过长告警（既有问题，可顺手处理）。
3. [低/可选] SQL 拼接规范化：对脚本内 f-string SQL 增加入参白名单/转义或改用 psql 变量绑定，统一消除潜在 sql_injection 误报噪音。
4. [需单独执行] hub 子模块扫描：v1.0.43–v1.0.46 的 hub 功能改动量较大（重扫/派发/分支解析/身份映射），本快照不可 diff，建议对 hub 子模块按相同 base→head 单独出增量报告。

---

六、总体评估