Separate the problem from the proposed solutions before you choose

A complaint lands in the channel and, almost immediately, three fixes land with it. The temptation is to paste the whole pile into Claude Code or Codex and ask which solution to build. The model will treat a proposed fix as if it were a description of the problem. The cheaper work is earlier, and it is visual: put what actually happened on one side of the board, and the solutions already being offered on the other, before you ask anyone to choose.

This is a different step from unpacking a fog until you can name a question, from lining up options against a checklist, from separating a quote from a leap, or from sorting facts, assumptions, and open questions. Here the complaint already has answers attached to it. The risk is that a solution has already been filed as if it were the problem.

"Sharing is too hard"

Say a local-first desktop notes app is getting this complaint in the channel. Around it, people have already collected what actually happened:

• Someone emailed a Markdown file to a coworker who does not use the app. The coworker asked for a PDF or a link.
• In a standup, a note would not appear on the conference-room TV without installing the desktop app on that machine. The meeting moved on after five minutes of trying.
• Two teammates edited separate copies of the same note over the weekend and spent Monday merging them by hand. No one was locked out; they just did not know the other person had a copy.

Those are problems. They do not yet say what to build. Next to them, the channel already has proposals:

• Add a public share link that opens in a browser, so someone without the app can still read the note.
• Add a Send a copy button that emails a PDF.
• Add real-time multiplayer so two people can edit the same note at once.

The share-link story is tidy, and it may well be the right first fix for the coworker and the meeting room. It does nothing for the weekend merge. The multiplayer story is tidy too, and it is aimed at a different failure. If you paste the complaint and the three proposals into one prompt, you will get a fluent recommendation that mixes two problems and three fixes as if they were one decision.

Two piles, not one brief

Open the project folder in BaseHalf. Each file becomes a card. Write short notes, one idea each:

• context.md: the complaint as it arrived, and nothing more: not a diagnosis, and not a plan.
• The problem: problem-coworker-no-app.md, problem-meeting-projector.md, problem-two-editors.md. What people ran into. No “so we should add a share link” on these cards.
• Proposed solutions: sol-share-link.md, sol-email-copy.md, sol-realtime-multiplayer.md. Each is explicitly a proposed fix, not a restatement of the problem.
• ask.md: the question you are finally willing to put to an agent, for example: “The coworker-without-the-app case and the meeting-room TV case look like the same problem: someone who does not have the app cannot see the note. The weekend merge is a different problem. Which of the proposals on the board even address the first one, and which should wait until that problem is named?”

Drag them the way you would scraps on a whiteboard. Context at the top. Problems in a pile on the left. Proposed solutions in a pile on the right. The ask at the bottom, under the problem cards that might actually belong to it. A short label card at the head of each pile helps your eyes keep the two kinds of sentence apart. That arrangement is for your eyes. Card places and sizes live under .bh/ and stay out of git through BaseHalf's own ignore file (it never touches your .gitignore), so you can keep sliding the piles around without turning a seating plan into a merge conflict.

Your eyes can now see what a pasted prompt hides: three proposals across from three failures, and only two of those failures even look like the same problem.

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

Once the board looks like a diagram, three moves are easy to mix up.

Sitting together is a way to look. It is not a semantic relation, and not a claim that every card in the left pile is solved by every card in the right. BaseHalf does not sort problems from solutions for you. You move them until the two kinds of sentence stop occupying the same space.

Draw a line only when A should keep feeding B. Once ask.md exists, connect the coworker note and the meeting-room note into it if that is the problem this question is about. A Markdown note stores that list in its frontmatter, under upstream:. Leave the weekend-merge note and the multiplayer proposal unconnected if they are not what this ask is about. Sitting in the left pile is a hunch that a card is a problem. A line is a claim that context flows.

Select the slice, not the whole board

You are not asking “how should we fix sharing.” You are asking which sharing failure you are actually solving first, and which of the proposals even address that one.

Select that ask card plus the two problem cards that belong to it. Leave the weekend merge and the three proposals out of this pass if you want the model to name the problem before it ranks the fixes. A dragged box or a Shift-click builds the set; the rest of the board can stay visible without being poured into the prompt. Selection is what Claude Code or Codex can see for this ask in the Agent Area. BaseHalf is not itself an agent.

Then ask. Not “which solution should we ship.” Ask the model whether those two failures are the same problem, and which proposals on the board even speak to it.

What to keep after the answer

Keep the named question, the problem cards that actually belonged together, and a short note on which proposals survived that framing. If they should keep traveling together, leave or adjust the upstream list. A proposal that was aimed at a different failure can stay on the board, in its own pile, for a later ask. Do not promote the whole left pile into permanent links just because the failures sat near each other.

Limits

Separating the piles does not make the problem list complete, or the proposals the right ones to consider. If the coworker already had a working export and the real pain was the weekend merge, you will pressure-test a neat wrong frame and the model will answer it fluently. The canvas makes the mix-up visible. You still have to decide which failure is actually on the table.

Put the problem on one side and the proposed solutions on the other before you choose. Write upstream only for the slice that should stick to the named question. Select that slice, and then ask the agent.