技能介绍

接手项目时，为什么目录总会“长”出几个分身

接手一个陌生的代码仓库时，最常见的翻车现场不是编译报错，而是走错目录。物理路径 /opt/app 和 /home/user/app 可能同时存在，其中一个是从 ZIP 解压的死副本，另一个则是正在监听 8080 端口的活跃实例。更糟的是，git status 显示干净，但 HEAD 停留在三个月前，而真正的开发分支藏在另一个 worktree 里。本技能（Project Truth Detective）就是为了在动手改代码或执行 git pull 之前，把这些“薛定谔的副本”彻底测清楚。

四层隔离与只读审计机制

技能的核心原则是将项目的“真相”拆分为四个绝不混淆的维度：

物理目录：磁盘上真实存在的文件夹。
项目身份：该文件夹代表的产品或代码库逻辑实体。
仓库血缘：Git 的 root、remote、branch、HEAD、worktree 及克隆/解压关系。
活跃表面：当前真正在运行的进程、监听器、构建产物或部署 URL。

审计过程严格遵循只读（Read-only）边界，绝不执行 git checkout、reset、clean 或任何重启部署操作。它按特定顺序读取权威文件（如 SOURCE_OF_TRUTH.md、近期交接文档、AGENTS.md），运行内置的快照脚本，并对比 remote URL、commit 祖先关系和针对性哈希值。如果发现 main worktree 和一个未合并的 feature worktree 同时存在，技能会分别给出通用项目入口和特定功能延续点的双重决策，而不是强行选出一个“赢家”。

适用边界与证据分级

本技能不负责实施代码修改，也不替代 CI/CD 流水线。它的输出严格分级为 verified（已验证）、inferred（推断）、conflicting（冲突）或 unknown（未知）。当本地 remote-tracking 引用与网络真实状态可能不一致时，它会明确提示“仅证明最后一次 fetch 的状态”。遇到脏工作区或未知文件，技能会如实报告并保留现场，绝不擅自清理。在证据缺失时，直接回答“无法确认”，而不是靠直觉猜测权威目录。