长时间无人值守任务中保留可审查决策日志

为长时间或多阶段运行的工作维护一份 TSV 决策日志，让审查者能信任结果。

适用场景

解决思路

1. 维护一份唯一的规范日志：单个 TSV 文件，每行一条决策，单元格保持单行，evidence 是链接或路径而非散文。
2. 复制 `references/decision-log-template.tsv`（表头行）来开始一份干净的日志。列包括：ts（ISO8601 时间戳）、phase（阶段或工作流）、decision（选择或做了什么，一行）、why（用平实语言说明原因，若由某原则驱动就直说，不要用术语标签）、evidence（能证明它的链接或路径：commit SHA、PR 编号、`file:line`、或 artifact/trace/screenshot 路径，绝不用段落）、result（结果或谓词状态：`tests green`、`reverted`、`pixel-diff 0`、`INCONCLUSIVE`、`open`）。
3. 写每条记录时像告诉队友你做了什么：平实语言、具体动作，不要 AI 腔或抽象术语（unslop 技能同样适用于日志文本）。
4. 使用辅助脚本 `scripts/log.sh <logfile> <phase> <decision> <why> <evidence> <result>`：它会打上 `ts`、首次使用时写入表头、去掉多余的 tab/换行，并对以 `=`、`+`、`-`、`@` 开头的单元格加单引号前缀。直接用 `printf` 追加一行也可以，但若单元格来自生成或用户提供的文本，同样要注意这些字节。
5. 只记录决策点和检查点，不是每个动作：选择的分叉、完成并带验证结果的单元、带触发原因的转向或回滚、暴露的阻塞、修复的关卡。循环运行每轮一行。跳过琐碎和显而易见的内容。
6. 默认日志是工作产物，不提交。放在工作目录的 `decisions.tsv`，或多个任务并行时放在 `.audit/<task-slug>.tsv`，并排除在 git 之外。
7. 仅当工作足够宏大、审查者需要这条轨迹才能信任结果时才提交它。
8. 只追加。错误决定用新行取代它，绝不编辑或删除历史。
9. 优先使用由已提交脚本产生的证据，而非手工一次性产物（encode-lessons-in-structure 原则技能）。
10. 运行结束、交付前，对照 transcript 审计日志：读取当前工作区 `agent-transcripts/` 目录下本次运行的 transcript（系统提示中会给出路径），不要用 glob 扫 `~/.cursor/projects/*/`，那会读到无关的私人聊天。逐行核对日志与实际发生的事。
11. 审计时：每行都对应真实动作，删掉编造或空想的条目；每行的 evidence 能解析并证明该行所声称的内容；影响工作的分叉、转向或放弃的方案若未记录就是缺口，补上；删掉填充内容。
12. 修正日志，而不是修正故事。如果工作偏离了某行所声称的，那行就是错的。
13. 交付前，在不同模型家族上启动一个子代理（与做工作的模型不同）对轨迹做跨模型审查。自我审查不能替代。子代理读取审计轨迹和本次运行的 transcript，然后标出用户应关注的点——不是重做工作，而是扫描次优或有风险之处。
14. 跨模型审查要标记：证据薄弱或缺失的决策；被跳过或声称验证但 transcript 中无证据的验证步骤；事后看有风险的选择（过早、范围蔓延、掩盖症状）；用户随意浏览时会漏掉的缺口。
15. 每次产生轨迹的运行，回复末尾都要有 “Attention” 部分：先单独一行写审查者模型（`reviewed by <model>`），然后列出每个标记并指向具体行或时刻。“No flags” 是合法值，模型名不是。
16. 审查轨迹时：从上到下读，跟随 evidence 指针，抽查。GitHub 会把提交的 TSV 渲染成表格；终端里用 `column -s$'\t' -t decisions.tsv` 渲染。
17. 组合此技能时：其他技能把审计轨迹路由到这里，而不是自创一套。按名称引用它，让它拥有格式，不要重述列。

适用边界 · 注意事项

• 短小、自明、无需审查者信任轨迹的工作。
• 日志会包含敏感信息且无法安全存放或提交时。
• 没有 transcript 或无法访问 transcript 可供审计时。