BaseHalf
All posts

Leave the rejected option on the board, with the reason you dropped it

We planned a 30-minute review of a teammate's canvas folder on a BaseHalf board, left the rejected zip-and-chat option visible with the reason it was dropped, and had Claude Code write a checklist from only the chosen path.

A 30-minute review has more plausible ways to do it than it has time. The useful whiteboard move is to leave the option you dropped where you can see it, with the reason it was dropped, and to send only the path you actually chose.

A teammate asked for a 30-minute review of their canvas folder. By the end of the slot I wanted to have walked the cards with them, checked that the connections matched what they meant, and left written comments they could reopen in the same folder. I already had access to that folder. One option was to review it in place: open the same folder in BaseHalf, talk while looking at the cards and the lines, and write comments as notes there before the slot ended. The other was to ask them to zip the documents, send the archive in chat, and leave comments in the thread.

The zip is not a topic I postponed. It is the option I am not using for this slot. A zip of the documents people usually commit can include the notes and the upstream lists inside those files, but it often leaves out .bh/, where the card places are kept and which is left out of git. I would get the files, and maybe the connections, and still not see the arrangement they had on the board. Comments in chat would also leave the review outside the folder.

I opened a folder in BaseHalf 0.6.1 and spread those pieces as cards: the goal, the constraints that actually bind, the in-place option, the zip option, a rejection note, and a briefing for the choice. I wrote the zip option into the rejection note's upstream list, so the dropped option stays attached to the reason it was dropped. I wrote the goal, the constraints, the in-place option, and the rejection note into choice.md. I did not connect the zip option to the briefing. Sitting next to something is not the same as being its source. Card places are saved under .bh/ and stay out of git. The lines are the upstream lists in the files.

A BaseHalf canvas of the review-in-place folder: constraints, goal, and the in-place option in a left column, the zip option at the bottom of that column with a short line into the rejection note beside it, and the choice briefing on the right with lines from the goal, the constraints, the in-place option, and the rejection, but not from the zip option itself.

I selected the choice card. The status bar showed that agents could see choice. In the Agent Area I started Claude Code and asked it to read that briefing and only the files listed in its upstream, then write review-checklist.md in the same folder: a timed checklist a teammate and I could follow, with minute marks that add up to 30. The dropped option should appear only as a single note, that it was rejected and why, not as a step in the review. I told it not to edit the existing notes.

The first request in this window failed after a second, at 18:18 Asia/Shanghai, with an API error from Cloudflare. I sent the same request again in the same session.

The same canvas with the choice card selected, and the request typed into Claude Code in the Agent Area: read only the upstream of choice.md, and write review-checklist.md without editing the existing notes.

After 48 seconds, at 18:21 Asia/Shanghai, the file was there. It appeared in the sidebar and as a new card on the canvas. I opened it and read it myself. The checklist uses the times that fit the slot: three minutes to open the same folder, ten to walk the cards, eight to check the connections, seven to write comments as notes in that folder, and two to confirm those comments are there before the slot ends. The steps add up to 30. It tells us to look at the cards and the lines, not at a list of file names, and to write the comments in the folder so they are still there after the call. The zip option is mentioned once, in a closing note, and is not named as a step. Claude Code loaded the BaseHalf skill, listed the directory, and wrote the new file. No existing note was changed.

The same canvas after review-checklist.md appeared under the zip option, with Claude Code in the Agent Area showing that it wrote the checklist and loaded the BaseHalf skill.

The board is still a folder of ordinary files. The rejected option stays visible, attached to the reason it was dropped, so I can see why it is not in today's plan. The connections record which context should stick. The agent wrote a new file into that same folder, from the chosen path, and I checked it. It does not decide the rejection for you, and it does not hide the option you left out. If you connect the dropped option into the briefing, it will treat that option as in scope too. The useful part is that the rejection is still on the board, and the checklist is a file you can reopen after the session ends.