Bug Fix Loop

一套把修 bug 从一次性动作变成天天积累的循环方法。用久了，经验库越攒越多，越用越准。

一句话说明

修 bug 难在判断，不在跑流程。拿单、下日志、搜代码、提交这些步骤谁都会，难的是判断症状属于哪一层，以及证据够不够下结论。这个 skill 的活就是判断，下根因、给结论、提修法。三条硬纪律管的是判断的方式，证据不扎实不许下结论。最终拍板的是使用者。

复盘按需做。有昨天的分析才对账，没有或用户只要新单，就直接分析。对账比两样东西，缺陷单里别人的解决结论，和 skill 上次给的分析结论。
结论等级看证据撑不撑得住，不由已经做了多少分析步骤决定。适用的检查动作至少做一半，这是保底；少数动作给出相互印证的硬证据，够自信也能下确定结论；动作全做但证据互相矛盾，一样下不了。
经验在对账时记，分析前读。每次复盘把两样结论的差距写进经验库，分析新单之前先扫一眼偏差表，命中的直接按验证路径走。

还没有 project-config.md 的时候，不管用户说什么，先走初始化，不要直接分析。用户说"帮我看看这个 bug"，也要先配环境再分析，不配环境就分析等于在瞎猜。

读 references/bootstrap.md，探测环境，问清楚六件事，写进 project-config.md。六样东西是代码仓库、缺陷系统、每天从哪里拉单、运行证据、业务类型、参考资料。
问清楚每天从缺陷系统的哪里拉待分析的单。这个位置每家系统叫法不一样，Jira 叫筛选器，GitHub 叫搜索或列表，看板叫列。要一个能打开的具体东西，保存的筛选器名、搜索链接、列表地址都行，原样记进配置。不许 AI 自己编一个，不知道就问用户。注意，要筛选器或搜索链接，不要给一个看板或 dashboard 页面，dashboard 是展示用的，拉不了单。
跑一遍 scripts/adapters/example_api.py --demo，确认脚本本身能用，再照着样板接项目的缺陷系统。
初始化完成后，告诉用户这个 skill 能干什么、怎么用。能单条分析一条 bug，也能跑完整的每日循环。说"分析 bug"或"拉今天的单"触发循环，说"帮我看看 BUG-xxx"分析单条。

读 references/loop.md。先复盘昨天，再拉今天的单，逐条分析，需要的话修复提交，最后把结论和教训写进文件。

文档	作用	什么时候读
`references/loop.md`	每天怎么走	每天开始
`references/depth-gate.md`	证据够不够的检查	每分析一条 bug
`references/runtime-evidence.md`	运行证据怎么拿，机制无关的坑	拿日志附件前
`references/retrospective.md`	复盘怎么复盘	每天复盘
`references/principles/debugging-principles.md`	调试的基本原则	分析时对照
`references/bootstrap.md`	第一次用，认识环境	首次使用
`references/cold-start.md`	冷启动，先学一遍历史	第一次部署
`references/lessons.md`	经验库怎么写	复盘完
`references/autonomy-ladder.md`	修复和提交分级	要改代码时
`references/pack-authoring.md`	项目类型适配怎么写	想给一种新项目类型做适配时
`scripts/`	可用脚本	做机械动作时
`en/`	英文版文档，language=en 时使用	英文环境

project-config.md 的 language 字段选 zh 或 en，默认 zh。选 en 时，按 en/references/ 下对应的英文文档执行，状态和报告用英文，脚本加 --lang en。

待分析 → 信息不足 / 无法定论 / 确定结论 → 已修复

判定规则看 references/depth-gate.md。