被否决的方案留在白板上，并写上否决的理由
我们在 BaseHalf 画布上安排一次 30 分钟的文件夹复盘，把被否决的打包加聊天方案留在现场并写上理由，再让 Claude Code 只根据选定的路径写出清单。
30 分钟的复盘里，可行的做法往往比时间还多。白板上有用的一步，是把你否决的方案留在看得见的地方，并写上否决的理由，然后只把真正选定的那条路径送出去。
一位同事请我用 30 分钟复盘他们的画布文件夹。结束时，我希望已经和他们一起走过卡片，核对过连线是否符合他们的本意，并留下他们还能在同一个文件夹里打开的书面意见。我已经有这个文件夹的访问权限。一个办法是就地复盘：在 BaseHalf 里打开同一个文件夹，对着卡片和连线讨论，并在结束前把意见写成这个文件夹里的笔记。另一个办法是请他们把文档打成压缩包，在聊天里发过来，意见写在对话里。
压缩包不是我推迟到以后再做的题目。它是这次我不采用的方案。人们通常会提交的那些文档，打成压缩包后可以带上笔记，以及写在文件里的 upstream 列表，但常常不会带上 .bh/。卡片的位置就记在那里，而且它会被排除在 git 之外。我也许能拿到文件，甚至拿到连线，却仍然看不到他们当时在画布上的排布。聊天里的意见也会把复盘留在文件夹外面。
我在 BaseHalf 0.6.1 里打开一个文件夹，把这些部分摊成卡片：目标、真正起约束作用的条件、就地复盘的方案、打包加聊天的方案、一则否决说明，以及一份选择简报。我把打包方案写进否决说明的 upstream，这样被否决的方案会一直连着否决它的理由。我把目标、约束、就地复盘的方案和否决说明写进 choice.md。我没有把打包方案连到这份简报上。挨着放，并不等于它是来源。卡片的位置保存在 .bh/ 下，并且不会进 git。连线就是文件里的 upstream 列表。
我选中了选择简报这张卡片。状态栏显示，agents 能看到的是 choice。我在 Agent Area 里启动了 Claude Code，请它阅读这份简报，并且只读其 upstream 里列出的文件，然后在同一个文件夹里写出 review-checklist.md：一份同事和我都能跟着做的计时清单，各段分钟数加起来是 30。被否决的方案只应作为一条说明出现，写明它被否决以及原因，而不应成为复盘里的步骤。我告诉它不要改已有的笔记。
这个窗口里的第一次请求，在 Asia/Shanghai 时间 18:18 失败了，大约一秒后出现了来自 Cloudflare 的 API 错误。我在同一次会话里又发送了相同的请求。
48 秒后，也就是 Asia/Shanghai 时间 18:21，文件出现了。它出现在侧边栏里，也作为一张新卡片出现在画布上。我自己打开读过。这份清单按这个时段来安排：3 分钟打开同一个文件夹，10 分钟一起走过卡片，8 分钟核对连线，7 分钟把意见写成这个文件夹里的笔记，最后 2 分钟确认这些意见还在，再结束。各段加起来是 30 分钟。它提醒我们看卡片和连线，而不是只看文件名列表，并把意见写在文件夹里，这样通话结束后它们还在。打包方案只在文末的说明里出现了一次，没有被写成步骤。Claude Code 加载了 BaseHalf 的 skill，列出了目录，并写出了这个新文件。已有的笔记都没有被改动。
这块白板仍然是一个装着普通文件的文件夹。被否决的方案还留在看得见的地方，并连着否决它的理由，所以我能看见为什么它不在今天的计划里。连线记下的，是应该留下来的上下文。模型把一个新文件写进了同一个文件夹，依据的是选定的那条路径，我也核对过了。它不会替你做否决，也不会把你放下的方案藏起来。如果你把被否决的方案连进简报，它也会把那个方案当成范围内的事。有用的地方在于，否决仍然留在白板上，而这份清单是会话结束后还能打开的文件。