Element details and decisions

Point at any element in a page preview and see exactly what your spec says about it — and what it still owes. · Recommended

The UI preview shows you the shape of a page. This panel answers the harder question: for this one button, field or list — specified where, by whom, against what data, and what's missing?

Every element a page renders carries a small contract. A button owes an interaction, a happy path and an error case. A dropdown owes an option source. A heading owes nothing at all. The Details panel shows that contract one element at a time, tells you which parts are settled, and gives you the controls to settle the rest.

Opening it

1. Open a page at its own URL — Pages → Sitemap, then a card's edit button (/project/<project>/pages/<page>).
2. The right rail has two tabs: Chat and Details. Open Details.
3. Move your pointer over the preview. The panel refills for whatever element you're pointing at.

Hovering is enough — you don't have to click. Click-to-pin latches the panel on one element so it stops following your pointer (see the Pin control in In-app UI preview); the close button on the panel clears the pin and goes back to hover-tracking.

Because it rides on the page preview, this needs the Pages step, so Starter or above. In the live demo the panel reads normally but the decision controls are hidden — a demo visitor can't complete a generation run, and a button that always fails is worse than no button.

The seven groups

The panel reads top-down, narrowest claim first:

An empty group is a finding, not a blank. "This element reads or writes no data" is a statement about your spec — so each group that has nothing says so, and says what would put content there. A group that silently vanished would read as not checked.

Codes like US-012 and AC-31 appear as small badges beside the sentences, never as the headline — the narrative and the Given/When/Then lines are the content. Each criterion also reserves space for a review verdict, which reads Not reviewed until a review has been run against the page.

What an element owes

The Element group names the control, classifies it, and then lists its contract — one line per slot, with a count above:

Export CSV · action
3/5 decided
  ● interaction        AC-31
  ● happy path         AC-31
  ◇ error case         AC-44
  ○ loading state
  ○ confirmation

The count is slots decided, not slots satisfied — declining a slot counts, because declining is an answer.

Not every element owes something. Text and decoration are classified as exempt by name, so the panel says "This element owes no specification" rather than showing nothing. An element with no gaps and an element you decided to ignore must not look alike. An element VibeMap genuinely can't classify reads as unclassified — also a visible state, never a silent guess.

The provenance marks

Each slot carries a mark saying where the answer came from. The panel prints a legend under the list:

Only assumptions ask anything of you. A slot the model assumed is marked unreviewed until you look at it, and the panel keeps a running count: "2 assumptions on this element have not been reviewed."

This distinction is the whole point of the panel. An LLM choosing between plausible candidates is a judgement call, and a spec that hides its judgement calls among the facts you stated is a spec you can't audit. The marks never rely on colour alone — each one has a text label a screen reader reads out.

Closing a gap

Four controls, each a different answer to "this slot is undecided":

• Specify — writes new acceptance criteria for the element. Use it when the behaviour genuinely isn't in your spec yet.
• Decide — resolves the element's open slots against rows that already exist, or declines them with a reason. Use it when the answer is somewhere in your spec and just isn't linked up.
• Not required — declares the slot doesn't apply to this element. It shows afterwards as none — your reason, not as a suppressed warning: a decline is a decision and reads like one. Require again puts it back.
• Accept — on an assumed (◇) slot, accepts the model's choice and clears it from the review queue.

Specify and Decide appear together under the slot list, and only when the element actually has an undecided slot. They're siblings on purpose — authoring new criteria and linking up existing ones are different jobs, and which one you want depends on whether the answer already exists.

Deciding a whole page

Working element by element is right for review; it's slow for a first pass. The page-level Decide everything runs the same engine across every element on the page in one sweep, settling what it can against your existing spec.

Everything it settles is marked ◇ assumed and lands in the review queue — a sweep is a head start, not a sign-off. The intended loop is: sweep the page, then walk the elements and Accept or correct what it chose.

⚠️ Decide isn't tier-limited today. Which plan buys the Decide engine is still an open pricing question, so right now it runs on any plan that can reach the Pages step. That may change — the panel's read-only tracing won't.

When it can't trace an element

Sometimes the panel says "Couldn't tie this element to a section". That's a lookup failure, not a verdict on your spec: you've pointed at page chrome, or at a layout wrapper the generator never tagged. There's nothing behind it to look up, so the panel reports the failure instead of showing seven empty groups and inventing seven findings out of one miss.

Point at something inside a generated section, or regenerate the page to refresh its section stamps.

⚡ Power-user hints

• Sweep, then review. Run Decide everything once, then use the unreviewed count on each element as your worklist. The marks turn the panel into a queue.
• Treat ○ and ◇ differently. A ○ means your spec is silent. A ◇ means your spec now says something you didn't write. The second one is the more dangerous of the two.
• "Not required" is a real answer. Don't leave slots open because they don't apply — an element at 5/5 with two declines is a finished element, and it stops showing up in sweeps.
• Discovery is pointer-driven. Hover is how you find elements. Once something is pinned, the Details tab behaves like any other tab.
• Gaps here feed the readiness signal. Elements you leave undecided are what Prepare for Dev reports as uncovered.

↔ The traditional way

Normally this trace lives in people's heads, or in a spreadsheet mapping tickets to screens that goes stale the first week. The expensive failure isn't a missing spec — it's a spec that looks complete because nobody can tell which parts someone decided and which parts got assumed in a hurry. Marking provenance on every slot is what makes the difference auditable instead of a matter of memory.

What's next

• Where these elements get rendered → In-app UI preview
• Where the criteria behind them come from → Acceptance criteria
• Turn a decided spec into a build-ready blueprint → Prepare for Dev