Compare options on a canvas before you ask the AI

When a decision has two or three real options, pasting the whole mess into Claude Code or Codex is the expensive way to think. You get a fluent answer that mixes your constraints with the model's defaults, and you still have to reconstruct the tradeoff later. On a BaseHalf canvas you can do the cheap part first: put the problem, the constraints, and each option where your eyes can compare them. Ask the agent only after the board already shows what matters.

A concrete tradeoff

Say you are adding offline drafts to a small desktop tool. Three storage shapes keep coming up:

1. One Markdown file per draft in a folder the user already owns.
2. A local SQLite database with a drafts table.
3. A single JSON document that the app rewrites on every save.

None of these is absurd. Each fails a different constraint. The job is not to “ask AI which is best.” The job is to see the options side by side against the same checklist, then ask the agent to pressure-test one slice.

Spread the problem as cards

Open the project folder in BaseHalf. Create short notes as cards, not essays:

• problem.md: one paragraph: offline drafts must survive a crash and stay inspectable without a special viewer.
• constraints.md: bullets that actually bind you: must work offline, prefer files the user can open in any editor, avoid a migration story in v1, keep the sync story boring.
• One card per option: option-markdown-files.md, option-sqlite.md, option-json-blob.md. Each holds the idea, the upside you already believe, and the failure mode you already fear.
• open-questions.md: what you still need answered (crash safety for half-written saves, how backups look, what a teammate diffs in git).

Drag them into space the way you would a whiteboard. Put the problem at the top. Constraints in a column on the left. Options in a middle row. Questions underneath the option they threaten. That arrangement is for you. Card places and sizes live under .bh/ and stay out of git, so rearranging while you think does not become a merge fight.

Layout is not the durable graph

Two different things are happening on that board.

Visual organization is where cards sit. It helps you group, compare, and notice a gap. It is seating for your eyes. It typically stays local under .bh/.

Upstream connections are the lines you draw so one card’s context flows into another. BaseHalf writes those as plain-text lists into the files (Markdown frontmatter, or a mirror under .bh/ for other file kinds). Git can see them. The next Claude Code or Codex session can see them. They are the context that should stick.

Do not treat every spatial grouping as a semantic link. Keeping the three options in one row does not mean they are upstream of each other. Draw a line only when context should actually flow, for example, constraints.md into each option note, and open-questions.md into the option you are about to test. A line means A feeds B. It is not a mind-map label, not an auto knowledge graph, and not a substitute for the prose inside the cards.

Compare with space, then narrow the ask

With the options in one row against the same constraints column, gaps show up fast. Markdown files win on inspectability and git diffs; you still owe yourself an answer on atomic writes. SQLite wins on crash-ish transactions; you owe yourself an answer on “can the user open a draft without our app.” The JSON blob looks simple until two writers and a half-written save show up in the questions card.

Pick the slice you want help with. Maybe it is only: “given these constraints, what breaks first if we choose Markdown files and the process dies mid-write?” Select that option card plus constraints.md and the relevant questions. Selection feeds the Agent Area so Claude Code or Codex sees the related content you chose, not the whole board and not a prompt you will forget to paste next week.

What to write down after the answer

Keep the parts that make next month cheaper: the decision, the reason, and which option you rejected. Put that in a short note and connect the constraints and the winning option into it with upstream. Leave the discarded brainstorm cards where they are, or delete them. Do not promote every spatial cluster into a permanent link.

Limits

This is a way to think with a folder before you spend a model call. It does not invent options for you, score them with fake metrics, or turn the canvas into an automatic decision tree. If your constraints are wrong, a neat board still leads to a neat wrong choice. The canvas makes the tradeoff visible; you still own the call.

Spread the problem first. Keep layout for your eyes. Write upstream only for context that should stick. Then select what the agent should see, and ask.