daily-report

name	daily_report
description	当用户要根据 Codex 对话历史和相关 Git 仓库改动生成中文工作日报或完整今日行为清单时触发，例如“日报”“生成今日日报”“今日行为”“根据今天的问题和改动写日报”。它从当天 session 提取问题、需求、报错和完成摘要，并由 session 启动目录反推 Git 项目确认真实改动；不用于执行提交、修改代码、生成 commit message 或生成周报/月报。

Daily Report

适用场景

• 用户说“日报”“今日日报”“根据今天的问题和改动写日报”。
• 用户要求按今天或指定日期的 Codex 对话历史和 Git 改动整理工作内容。
• 用户要求“完整今日行为”“完整行为记录”“今天全部做了什么”等完整清单。
• 用户要中文工作日报，而不是提交代码或生成 commit message。

核心原则

• 日报是给老板看的，老板关心：今天解决了什么问题 / 完成了什么需求 / 修复了什么缺陷，然后才是大致怎么解决的。
• 技术实现细节（如类名、方法名、配置拆分）不是重点，除非是重大技术攻克。

处理流程

• 先确定日报日期：默认使用本机当前日期；如果用户指定日期，使用用户指定日期。
• 优先读取当天对话历史：查找 ~/.codex/sessions/$(date +%Y/%m/%d)/*.jsonl 以及 ~/.gemini/antigravity-cli/*.jsonl。
• 指定日期时按对应 YYYY/MM/DD 目录查找。
• 从对话历史中提取用户当天输入的问题、需求、报错、改动意图，以及 assistant 最终完成的任务摘要；日报不要把完整对话逐条复述。
• 从每个 session 的 session_meta.payload.cwd 提取会话启动目录，并对每个 cwd 执行 git -C "$cwd" rev-parse --show-toplevel 反推 Git 仓库根目录。
• 如果 session_meta.payload.cwd 不存在或不能反推仓库，可辅助使用 turn_context.payload.cwd、event_msg.payload.cwd；仍无法确认仓库时，该 session 只作为问题/过程来源。
• 对反推出的 Git 仓库去重后，逐个读取 Git 改动确认项目真实变化：
  • 当天提交：git log --since="00:00" --name-status --pretty=format:"%h%x09%an%x09%ad%x09%s" --date=iso-local
  • 指定日期：按该日期 00:00 到次日 00:00 查询。
  • 工作区改动：必要时查看 git status --short、git diff --name-status、git diff --cached --name-status。
• Git 改动可能包含用户手动修改和 Codex 修改。
• 用“对话里遇到的问题和意图”作为日报问题来源，用“Git 改动”作为完成成果来源，交叉印证后合并相近事项。
• 如果对话历史不存在或没有相关内容，再根据 Git 改动自行分析总结，并明确标注这是根据改动归纳得出的内容。
• 如果对话历史和 Git 改动都没有有效信息，直接说明今天没有查到可生成日报的内容，并给出空日报或简短说明。
• 如果用户明确要求“完整今日行为”：
  • 不设置人为条数上限，必须尽量扫描当天所有可读取 session 和相关 Git 仓库。
  • 在日报摘要之外追加“完整今日行为”部分，按时间或会话顺序列出用户需求、报错、执行结果、代码/配置/文档改动、提交和未提交改动。
  • 可以合并重复轮次和无结果的中间尝试，但不要漏掉独立需求、失败问题、被用户打断或改方向的事项。
  • 如果内容过长，分段输出并明确说明“第 x 部分 / 共 y 部分”；不要因为篇幅主动删减事项。

写作规则（强约束）

• 日报不是 commit 摘抄，也不是技术架构说明。
• 每一条必须回答两个问题：
  1. 今天解决了什么问题？
  2. 为了解决这个问题，完成了什么改动？
• 优先写“已完成的事情”，不要写“看起来很高级的技术名词堆砌”。
• 禁止大量使用以下空话，除非后面有明确对象或结果：
  • 完善
  • 优化
  • 规范
  • 升级
  • 重构
  • 增强
  • 全面接入
• 如果只是代码层面的整理，没有直接业务结果，要明确降级表述为：
  • 说明这次整理支撑了哪个具体功能，后续扩展会更方便，且不影响现有行为。
  • 说明可读性或维护性提升具体体现在哪里。
• 不要把“DTO、配置拆分、拦截器、解码器、常量”单独写成一条日报，除非它直接支撑了某个明确问题的解决。
• 同类提交必须合并。
• 如果无法从对话历史和 Git 改动中判断真实业务背景，允许写“归纳”。
• 日报正文应合并同类事项。
• 最终结果必须像人写的工作日报，不能像代码目录说明。

输出格式

• 说人话：输出要像真实工作日报，非技术人员能看懂，同时能体现工作成果和处理难度。
• 不要套固定句式，使用代码块包裹日报正文。用 Markdown 输出。
• 正文用自然语言 bullet，每条围绕一个成果写清楚“做了什么、解决了什么问题或有什么价值”。
• 按改动量和业务重要性从大到小排序；相近事项合并成一条。
• 可以适度保留关键技术名词，但需要服务于成果说明，不能写成文件清单或 commit 列表。
• 不提供可套用模板或占位示例；必须根据当天真实事项重新组织语言。
• 每条日报可以用一句话概括成果，再用冒号后补充关键改动和价值；是否使用这种句式由内容决定，不能机械重复。
• 语言风格参考真实日报的表达质感，但不要参考具体句子结构、业务对象或技术名词。 语气要自然、具体、像人在汇报。 写法可以口语化；让读者感觉事情被推进了、问题被处理了、后续工作有基础。
• 多个零散改动应合成一条完整成果，说明它们共同解决了什么问题，而不是逐个罗列文件、脚本或配置。
• 一个比较好的语言风格, 不参考句子结构, 而是语言风格

• 5.28 日报

  - 今天核心是把客户标签 benchmark 框架搭起来：新增了客户聊天数据读取、长文本切分、标签处理、指标计算、模型注册、训练运行、结果输出等基础链路，为后续比较不同算法效果打底。
  - 补了多套可对比的客户分类模型方案：包括 LightGBM、MLP、Hierarchical Transformer、CrossEncoder、Prototype Contrastive、SetFit、Teacher Student 等，让客户标签识别不再只靠单一方案判断。
  - 处理了 BiRefNet 背景替换报错：排查到 CUDA 可用但模型和输入数据类型不一致，修正推理输入类型对齐问题，并保留“没有 CUDA 就直接报错”的要求。
  - 围绕数据准备、标签文件、依赖安装、模型运行入口和文档说明，把原来会中断训练的几个问题逐个处理掉