Bridge

Handling ambiguity

Every idea worth building has gaps. Your notes say "works offline" but not whether that means strictly local-only or merely offline-tolerant. They mention storing emails but not whether the demo should encrypt them. A coding agent that hits one of these gaps either guesses silently or stalls — and a silent guess you don't catch is the expensive kind.

Bridge handles this inside Build Plan generation, not as a separate step you have to clear first. There's no approval gate, no inbox sweep, no list of questions to answer before you can generate. You tap Start a venture, the generator runs, and ambiguity gets resolved in the plan itself.

What the generator does with a gap

Build Plan generates in two passes. The first drafts the eight files and marks every unresolved ambiguity inline with a [NEEDS CLARIFICATION: ...] marker. The second resolves each marker from the material it has — your notes, their expansions, the constellation theme, and what Bridge has learned about how you work.

For most gaps, the second stage can make a defensible call. When your notes lean clearly one way ("works on planes," "no account," "just a calculator"), the generator picks the stronger signal, commits to it, and records the decision as an explicit constraint in the relevant file rather than burying it. You see what it decided and where, instead of finding out when the prototype behaves wrong.

When a gap genuinely can't be resolved from your notes, the marker stays in the file:

## Authentication

[NEEDS CLARIFICATION: notes mention "user accounts" but never specify
whether the demo needs real auth or a single hardcoded user. Assuming
single hardcoded user for the prototype — change this note and
regenerate if real auth is in scope.]

The marker names the gap, states the assumption the generator made so the plan is still runnable, and tells you how to override it.

The kinds of gaps it watches for

The generator pays special attention to four categories, because these are the ones that silently corrupt a prototype if guessed wrong:

  • Scope — conflicting feature ideas, unclear MVP boundaries. Two notes describe the input as CSV upload vs. manual form entry. The generator picks one and states it in 07_scope.md.
  • Security — credentials, PII, health or financial data, third-party API access, storage choices. Notes mention storing user emails. The generator chooses a posture (e.g. "no PII stored in the demo") and records it in 07_scope.md and 03_architecture.md.
  • License — references to libraries or services with license implications. Notes reference an LGPL library. The generator names the license target and picks compatible dependencies in 03_architecture.md.
  • Conflict — direct contradictions between notes. The generator surfaces the contradiction rather than silently averaging it.

Where these land in the spec set is covered in Build Plan output files — 07_scope.md is the file to read first for compliance and scope constraints.

How you resolve what's left

Two paths, depending on your tier.

Add a note and regenerate (any plan-tier)

The durable fix. Capture a note that settles the question — "The converter is single-user, no accounts, no auth" — and tap Build Plan again on the venture. The new run picks up the added note, and the marker resolves. The old version stays in the Plan tab archive.

This is the right path when the answer is a real decision about the project: you want it captured as a note so it informs future ventures too, not just patched into one plan.

Ask chat to change it (Refine tier)

The fast fix. Scope a chat to the plan, point at the marker, and ask for the change directly: "Resolve the authentication marker in 03_architecture.md — single hardcoded user, no real auth." The AI proposes the edit as an inline diff; you approve it; the plan file updates. See Refining a plan.

This is the right path for plan-local tightening you don't need to remember at the note level.

Why it works this way

The earlier design floated a separate questionnaire you'd clear before generating. In practice that front-loaded friction onto the moment you were most eager to just see the plan — and most of the questions had an obvious answer the generator could have made itself. Resolving ambiguity inside the plan, with a visible marker wherever a real judgment call happened, keeps the friction proportional: zero when the answer is clear, one visible marker when it isn't, and a one-line fix to override.

Next

← Back to DocsPre-order Bridge