Code996

步骤 3 — 加班时段语义分析

基于步骤 2 的 JSON 数据，识别加班高峰窗口，对同一仓库执行 git log 获取实际 commit message，归纳「加班都在干什么」。

对每个仓库获取 commit hash、带时区的 ISO 时间和 commit message。执行前必须从该仓库对应的 JSON 中读取 meta.since 和 meta.until，作为 code996 实际采用的有效区间；不要继续使用用户原始口述值或未赋值的占位符。

正常默认区间和自定义区间使用：

git -C "<path>" log --no-merges --after="<meta.since>" --before="<meta.until>" --format="%H|||%cI|||%s" --max-count=500

若用户使用 --all-time，JSON 中的 meta.since 和 meta.until 会缺失，此时必须同时省略 --after、--before，不能传空字符串或保留字面占位符：

git -C "<path>" log --no-merges --format="%H|||%cI|||%s" --max-count=500

始终引用仓库路径，不依赖 POSIX 管道。

--no-merges 必须保留，使定性样本与 code996 定量分析默认排除合并提交的口径一致。

根据 %cI 中保留的提交本地日期、时间和时区进行筛选。先判断本次分析是否启用了中国节假日模式：显式使用 --cn 时直接视为启用；否则优先读取 JSON 的 holidayMode。旧版 JSON 缺少该字段时，再按分析区间内的非合并提交统计时区，将 %cI 的 +08:00 等偏移统一规范化为 +0800 格式，当 +0800 占比不低于 50% 时视为自动启用。

• 未启用中国节假日模式：周一至周五视为工作日，周六、周日视为休息日。
• 启用中国节假日模式：只使用宿主已有的可靠中国工作日日历，优先采用与 code996 相同的 holiday-calendar 数据。可靠意味着能够指出数据来源，并能区分数据中的 public_holiday 与 transfer_workday；会在失败时静默退回普通星期规则的 API 不算可靠。不要为了语义分析另行联网下载日历，除非用户明确同意。
• JSON 中 holidayMode: true 只表示模式已启用，不证明宿主已经取得可靠日历数据。若无法可靠取得日历：仍可分析不依赖日期类型的 23:00–05:59 样本；跳过工作日晚间与休息日日间语义归因，并在报告中明确说明该限制。不得把调休工作日当作周末加班，或声称已覆盖法定节假日样本。

按上述日期类型筛选，使语义样本与 code996 使用的提交时间口径保持一致：

• 工作日晚间提交：日期被判定为工作日，本地时间从 ceil(workTime.endHour) 起至 22:59，最多取最近 50 条。
• 休息日提交：日期被判定为休息日，最多取最近 50 条。
• 深夜及凌晨提交：本地时间为 23:00–05:59，最多取最近 50 条。
• 合并以上样本时按 commit 去重，避免同一条休息日深夜提交被重复计入。
• 若最近 500 条提交不足以覆盖分析区间中的加班样本，可按连续且无间隙的时间窗口分段查询；使用 %H 按 commit hash 去重，并核对去重后的提交总数是否与 JSON 的 core.totalCommits 一致。若不一致，说明语义样本未完整覆盖，不要把样本占比表述为全量占比。

多仓库时对每个仓库分别执行，再合并归纳。

根据 commit message 将加班内容分类（可能重叠）：

• 赶需求 / 功能开发：含 feat / add / implement / 新增 等
• 修线上 Bug：含 fix / hotfix / bug / 修复 / 紧急 等
• 重构 / 技术债：含 refactor / chore / clean / 优化 等
• CI/CD / 发版：含 release / deploy / ci / build 等
• 其他：不归入以上分类的

给出各类占比估算（基于 message 数量），并列举 2-3 个典型 commit message 作为例证。

步骤 4 — 综合解读，生成报告

参照 references/report-template.md 的章节骨架，将以下数据整合为叙事化报告：

• 定量数据：code996 JSON 中的所有指标
• 定性数据：步骤 3 的加班语义分类
• 人均/贡献者对比：team.contributors[] 中各人加班活动占比，只判断活动是否集中于少数贡献者，不推断“被迫加班”或真实工时
• 用户口述背景：团队规模、是否弹性制、约定工时——用于校准「这算不算过度加班」的基准
• 多仓库视图：基于每个仓库独立 JSON 的 core、team 等字段进行横向对比（若适用）

贡献者分析遵守以下边界：

• 将不同邮箱视为不同 Git 身份；除非用户提供映射，不自行合并同名身份。
• 发现 bot、release server、CI 等疑似自动化账号时，单独标注，不把它们纳入个人风险结论；需要重新排除后分析时，先征得用户同意再添加 --ignore-author。
• workingHours.isReliable 为 false 或置信度较低时，明确说明时间推测不可靠；不依据 intensityLevel 单独判断个人工作状态。

多仓库聚合只使用成功返回的仓库：

• 不计算或编造“综合 996 指数”，只横向展示各仓库的 core.index996。
• 如需一个总体加班比例，使用提交数加权估算：sum(core.totalCommits × core.overTimeRatio) / sum(core.totalCommits)，结果标注为“按提交数加权的估算值”。由于单仓库比例已经四舍五入，该值不是 code996 官方聚合指标。
• 若不需要总体数字，省略估算值，不临时发明其他聚合公式。

报告风格：有结论（先给定性判断）、有数据支撑（引用具体数字）、有建议（可操作的改进方向）。

步骤 5 — 选择输出形态

若用户已在请求或对话中指明输出格式，直接执行；否则默认在对话中展示完整报告，不再追问。

• 直接展示：在对话中输出完整报告。
• 保存为 Markdown：将报告写入 ./code996-report-<日期>.md，日期格式 YYYY-MM-DD。
• 保存为 HTML：生成自包含 HTML（内联 CSS，无外部依赖）并写入 ./code996-report-<日期>.html。建议样式：白色背景、系统字体、最大宽度 800px、关键数字高亮显示。

注意事项

• 仅当 lateNight.midnightRate 为 0、weekdayOvertime 周一至周五的提交数合计为 0，且 weekendOvertime.realOvertimeDays 为 0 时，才跳过加班语义分析步骤，说明「未发现明显加班痕迹」。
• 若 team 字段为 null（如开源项目或 --skip-user-analysis），跳过贡献者对比章节。
• 仅分析一个仓库时跳过多仓库视图；分析多个仓库时使用各自的独立 JSON 聚合，不依赖 multiRepo 字段。
• 报告语言始终与对话语言一致，--lang 参数确保 code996 数据标签语言对齐。
• 不要把 schemaVersion 暴露给用户——这是供报告渲染器校验兼容性的内部版本标识。