增量质检报告 — codescan/code-scan-insight @ v1.6.40

一、版本信息

---

二、变更概览

本次提交是评分体系 V3.1「架构驾驭维」的一个收口改动，主题为：给架构维补上「最少代码 push 数」适用门槛，并把该门槛参数暴露到设置页。

---

三、质量对比（工具数据 · codescan_issues_diff）

本章数据来自 codescan_issues_diff(base=f40e89c, head=636dbe1)，为本次增量分析的真实结论，未做任何人工增补。

问题对比结果：修复 0 条 / 新增 0 条（两版本质量无差异）

3.1 已修复问题（Fixed）= 0

本次提交未修复任何静态质检问题。

说明：本次改动属于「逻辑补全 + 元数据接线 + 单测同步」，改动行数少（净增约 20 行）、且集中在已有函数内部的一个布尔判定上，不触发原有告警的消除（如 computeRadarFromData 的长函数 / 高圈复杂度等存量问题在本版本依然存在，不构成"修复"）。

3.2 新增问题（Added）= 0

本次提交未引入任何新的静态质检问题。

改动文件在当前版本的存量告警（均系历史遗留、非本次引入，issues_diff 已判定为两版本无差异）：

结论：本次为「零新增问题」的干净提交，但同时也没有偿还任何存量技术债。

---

四、变更内容解读（人工代码走查）

4.1 改动实质：把「已定义但未生效」的阈值真正接上

• MIN_CODE_PUSHES 默认值（3）在 base 版本的 lib/scoring/constants.ts（ARCH.MIN_CODE_PUSHES: 3）与 lib/scoring/params.ts 的 ScoringParams.ARCH 接口中早已定义，constants.ts 的注释也已写明「代码 push < MIN_CODE_PUSHES → 维度不适用（null，Q 按其余维度均值回退）」。

• 但 base 版 radar.ts 的实际计算为 archScore = archW > 0 ? round2(archWeighted / archW) : null——只看权重和是否大于 0，完全没有读 MIN_CODE_PUSHES。即：只要窗口内有 1 个含代码域文件的 push，架构维就照常按 ~40% 权重进入 Q，产生「单个 push 决定 Q」的假分数（单测原断言 3.5 正是这一旧行为）。

• head 版改为：

  const archScore =
    qualifiedPushIds.size >= params.ARCH.MIN_CODE_PUSHES && archW > 0
      ? round2(archWeighted / archW)
      : null;
  

  语义：窗口内含代码域文件的 push 数 ≥ 阈值（默认 3）且有权重 才计算架构分；否则置 null。

4.2 下游影响链（已核对，行为自洽）

• archScore === null → 第 340 行 if (archScore != null) dimsForQ.push(archScore) 不纳入 Q 均值 → Q 回退到其余可用维度（需求打磨 / 规范）均值，再截断到 [FACTOR_Q.MIN=0.6, MAX=1.15]。
• 六维画像 horizontal.architecture 同步为 null；total = v*q*b 与 balance（仅对非空展示分求标准差）均按既有显式空值约定处理，无空指针/NaN 风险。
• 与同文件 qualifiedPushIds（第 275/280 行收集）口径一致：阈值统计的正是「含 ARCH.CODE_DOMAINS 文件且属于窗口提交」的 push 集合，纯文档 push 不计入，与既有「纯文档 push 排除」用例逻辑一致。

4.3 元数据 / 设置页接线

• params-meta.ts 新增 arch_min_code_pushes（min:1, step:1），设置页表单与装载层共用此单一映射源（ScoringParamsForm.tsx 按 SCORING_PARAM_FIELDS 动态渲染），无需改动 UI 组件即可出现该配置项；resolveScoringParams 的 deepSet 将 DB 值写入 ARCH.MIN_CODE_PUSHES，默认值经 constants fallback = 3。
• 新增键后键数由 37 → 38，params.test.ts 断言已同步（测试与实现一致）。

4.4 单测同步（逻辑与实现一致，已核算）

---

五、潜在风险与改进建议（人工审查发现，非工具检出）

以下为走查中发现的一致性/文档漂移类问题，不属于静态质检工具告警（故不计入第三章数据），建议在后续小版本顺手清理。

1. 参数键数量注释三处不一致（36 / 38 / 41 并存）

   • lib/scoring/params-meta.ts:33 头注释：V3.3.1 36 键（未随本次 +1 更新）。
   • lib/scoring/__tests__/params.test.ts:8 文件头注释：V3.3.1 36 键…（未更新，但第 85-86 行断言已改为 38）。
   • components/feature/ScoringParamsForm.tsx:21 与 :89、app/admin/settings/page.tsx:43 注释仍写 41 键。
   • 实际 SCORING_PARAM_FIELDS.length === 38。本次只更新了「架构 ×9 → ×10」与测试断言，其余陈旧注释未同步，易误导维护者与设置页文案。

2. 设计文档章节号引用漂移

   • constants.ts:85 标注 docs/10 §十三；本次新增注释（radar.ts:308）标注 docs/10 §12.1/12.3。同一模块引用两部不同章节号，提示代码与 docs/10 设计稿可能已脱节（该文档不在本仓库，无法核对）。建议统一为当前有效章节。

3. 外部 seed 同步风险（无法在本仓库验证）

   • constants.ts:8 明确要求「默认值两处需保持一致：constants.ts / docs/10 §六 seed」。本仓库不含 docs/、db/、seed SQL 等，故新增键 的外部 seed 是否已补默认值 无法核实。运行时依赖 fallback 不会出错，但若外部存在「键集一致性」校验，建议同步补 seed。

---

六、结论

1. 增量质检结论（工具口径）：修复 0 条 / 新增 0 条，本次提交未引入任何新的静态质量问题，也未修复存量问题。
2. 功能性判断：改动正确且闭合。 它修复的是 base 版本「常量 MIN_CODE_PUSHES 已定义却未被 radar.ts 消费 → 架构维阈值形同虚设、单个 push 即可按 ~40% 权重影响 Q」的隐性缺陷，属没有配套工单/告警标记的功能正确性修复（因此静态质检对比为空）。
3. 实现与测试自洽：阈值判定、Q 空值回退、元数据映射（第 38 键）、单测断言四者一致。
4. 风险等级：低。 唯一需要跟进的是注释/文档漂移（键数 36/38/41、章节号 §十三 vs §12.1/12.3）与外部 seed 同步，均为一致性问题，不影响运行时正确性。