用途：回答“这个仓库曾经装过什么”。git log 只显示当前分支，而被强制推送替换掉的提交对象仍留在主机上，主机活动日志还记录了每次 ref 状态变化（含 force-push、分支删除）。该技能用这两点找回被抹去的历史，并诚实说明哪些无法触达。
主要能力：合并四类来源——远端仍广播的 refs、已合并 PR/MR 的 head refs、可选的镜像备份、主机活动日志中的历史 ref 状态，以及本地 reflog/fsck 探到的从未推送的提交。所有来源按 SHA 相加并去重。
关键技巧：git fetch origin <sha> 能取到没有 ref 指向的提交，而 REST API 对同一 SHA 返回 422 No commit found。必须用 git update-ref 为每个恢复的 SHA 建 ref，否则对象只挂在 FETCH_HEAD 上，下一次 fetch 就丢失。
调用格式：/awesome-git-history-salvage <repository-url-or-path> [--level full|dedup|unique|all] [--out <file>] [--backup <path-to-mirror.git>] [--since <year>]。
三种报告级别：full 每（来源, sha）一行，看哪些来源持有该提交；dedup 每 sha 一行；unique 每个逻辑提交一行，按作者时间戳、作者邮箱和主题折叠改写前后的孪生副本。三者共用同一次抓取，仅组装方式不同。
限制：只读，绝不 push、不删 ref、不动用户检出的仓库，全部抓取落在一次性临时克隆。活动日志记录的是 ref 状态而非提交列表，只在分支中间存在、从未成为推送 tip 的提交无处可寻，报告会明确说明。无 gh/glab 时活动日志不可达，只能限于远端仍广播的 refs；GitLab 无活动端点，需用 events 端点且字段与保留范围可能不同；自建实例差异更大。Windows 上报告管道需在 Git Bash 中运行。若未提供目标，先询问目标；未指定 --level 时应询问用户而非默认假设。已有同名报告不可覆盖，需另取文件名并说明本次写入的文件。