Unknown Dirty 时先切到安全资产
心跳式 Agent 经常会遇到上一段计划指向某个项目，但唤醒后该项目已经出现一批未知归属的 dirty path。此时最容易犯的错，是为了“延续计划”继续改同一个 repo，最后把用户、其他 agent 或验证副作用混进本轮提交。
这张卡的目标是把“不能接管目标项目”转化为一次仍然有价值、可提交、可验证的小推进：先保留目标项目的接力点，再切到 clean repo 中沉淀可复用资产或完成低风险旁路任务。
适用信号
优先使用这张卡，而不是继续原计划，通常满足这些条件：
- 上一段计划指向的 repo 出现启动前未知 dirty path，且本轮无法证明这些 path 属于自己。
- dirty path 涉及代码、配置、测试或 lockfile，继续验证可能生成更多副作用。
- 当前 workspace 还有 clean repo 可以承载资产沉淀，例如
docs/、books/、summaries/。 - 上一段已经留下清晰接力点，本轮不需要靠修改目标 repo 才能保存上下文。
不适合切走的情况：
- dirty path 明确是本轮刚生成的验证副作用，且可以安全清理或提交。
- 用户明确授权接管这些 path，或者仓库内已有清晰任务说明把它们纳入当前范围。
- 目标项目有线上阻断或安全修复，等待归属确认的成本高于隔离提交风险。
决策顺序
- 先记录目标项目状态：只写相对路径和简要类别，例如
study-buddy/frontend/web/package.json、study-buddy/frontend/web/src/dev/，不要猜测作者。 - 判断是否可接管：能证明属于本轮或有明确授权，才继续；否则标记为
unknown dirty。 - 保留原接力点：把上一段要做的第一条动作写成下一段优先项，而不是把它删除。
- 选择 clean repo 小任务：优先选能服务原接力点的资产，例如教程、书稿卡片、验证模板或 preflight 清单。
- 只提交本轮 owned path：提交前用 path-limited
git diff --check -- <owned paths>和git status --short复核。
可复制 notebook 句式
上一段接力点是 <target task>；但启动快照显示 <repo> 已有 unknown dirty：<relative paths>。
本轮不接管这些 path，避免混入其他会话改动。
改为在 clean repo <repo> 推进 <safe asset>，服务于下一次回到 <target task> 时的判断/验证。
下一段若 <target repo> clean，优先继续 <first command or first file>；若仍 dirty，继续只读分诊或选择其他 clean repo。验证方式
- 对目标 dirty repo 只做只读
git status --short，不要运行会改写缓存、构建产物或 lockfile 的命令。 - 对本轮 clean repo 运行该 repo 的最小 proof，例如 markdown link checker、catalog checker、书稿 verifier 或单文件测试。
- 提交后读回 commit hash 和 subject，最终报告同时列出“实际推进”和“未接管边界”。
常见坑
- 把上一段计划当成授权：计划只能说明方向，不能证明当前 dirty path 归属。
- 在 dirty repo 跑重型验证：构建、E2E、格式化可能扩大未知 diff，让后续更难分诊。
- 只写 summary 不产出资产：如果有 clean repo 和清晰小任务，应实际推进；summary 只是记录，不是成果本身。
- 最终报告隐去排除项：用户需要知道哪些 path 没被接管，否则下一轮会误以为全部已处理。
下一段接力标准
切走不是放弃原任务。下一段优先按下面顺序恢复：
- 复核目标 repo 是否 clean。
- 若 clean，执行上一段保留的第一条具体动作。
- 若仍 dirty，先判断是否已有新提交或任务说明解释这些 path。
- 若仍不能接管，继续选择 clean repo 小任务，并把目标任务压缩成更明确的第一条命令。
这能让无人值守的 Agent 在真实多会话 workspace 中持续产出，而不是在未知 dirty 和机械延续之间摇摆。