Separate what was decided from what is still open

A Friday launch thread ends with a wall of sentences. Some are commitments. Some are suggestions. One is a preference someone already agreed to live with. The cheap mistake is to paste the whole thread into Wednesday's recap and treat every sentence as if it had been decided. The cheaper work is earlier, and it is visual: put what was decided in one row, put what is still open in another, and leave a preference that is not work outside both rows, before you write the recap.

This is a different step from unpacking a fog until you can name a question, from lining up options against a checklist, from separating observations from interpretations, from sorting facts, assumptions, and open questions, from keeping a problem away from the fixes already being offered, from weighing evidence for and against, or from laying out the conditions for a yes. Here the launch date is already named. The risk is that a suggestion, or a preference, gets written as if it were already a decision.

What is decided for Wednesday's launch, and what is still open?

Say a small product team closed Friday's launch thread with this mix:

These are the decisions they can point to:

• The new billing page ships on Wednesday, 18 November. The thread agreed, with no dissent. That date is a decision, not a hope that the page will be ready.
• Maya writes the changelog. She replied yes at 16:12 on Friday. The changelog has an owner.
• The plan-page copy can slip; it is not a Wednesday blocker. The thread said it can wait if it has to. Letting it slip is an explicit decision, not an open question about whether it ships.

These are still open:

• The EU VAT case has not been checked. In the same message someone said "let's just hide it for now." Nobody confirmed the hide, and nobody has checked the case. A suggested hide is not a decision to hide VAT.
• The receipt email redo is only a suggestion. "I think we should also redo the receipt email" was not agreed, and it has no owner.

And then there is one sentence that is neither:

• "The banner color felt off, but we can live with it." That is a preference already accepted. It does not change Wednesday's launch, and it is not work to do.

On a BaseHalf canvas, those notes are ordinary Markdown files in one folder. The decided row and the still-open row are for your eyes. The preference card sits off to the side of the question, so it cannot pretend to be a decision or an open item.

A row is not a connection, and neither is a selection

Sitting in the decided row does not make a note part of the recap. A connection does. In BaseHalf, a line from A to B means A is upstream of B: A's context flows into B, and the list is saved in B, in the frontmatter of a Markdown note. The recap on this board is connected to the three decision notes and the two still-open notes. The open items are part of what the recap stands on. They are why the recap refuses to write the VAT hide, or the receipt email redo, as if they were decided.

The preference card stays outside both rows, without a line. Banner color may still matter to someone. The recap does not use it, so it is not declared as its upstream.

You can still point at a slice without changing those lists. A selection is temporary. It is what "this" can refer to if you later ask an agent. It is not written into the recap, and it does not force an agent to read only those files. A request that names something else still wins.

Select the slice the recap already named

For this board, the slice is the recap and the five notes it is connected to. The preference card stays visible on the board, and it stays out of the selection.

If you then ask Claude Code or Codex, ask about that slice. Not "summarize Friday's thread." Ask whether those five notes can support the hold the recap names: three decisions for Wednesday, two items still open, and no writing of the VAT hide or the receipt email redo as if they were decided.

What to keep after you write the recap

Keep the named question, the recap, and the upstream list that says which decisions and open items it rests on. Leave the preference parked, so it is not mistaken for a decision the next time someone opens the folder. When the EU VAT case is checked, or the receipt email gets an owner, update those open notes, and only then consider rewriting the recap. Do not connect a preference just because it sat nearby.

Limits

Two rows do not make the list complete, or the labels the right ones. If "the plan-page copy can slip" was never really agreed, or the changelog owner changed on Saturday, you will have a tidy board that still misses the failure. The canvas makes it visible which sentences you treated as decisions, which ones you left open, and which preference you refused to promote. You still have to check the open items.

Put what was decided in one row, and what is still open in another, before you write the recap. Write upstream only for the notes that recap actually uses, including open items that block a false sense of closure. Select that slice if you want to ask an agent about it.