I design interfaces,
then I build them
and find out I was wrong.

I prototype in the browser when the question is about behaviour. How a table reacts to a filter, what a bulk action does at scale, what an interface should do when a model returns nonsense. A click-through can't answer any of those, so I stopped pretending it could.

Everything derives from one state object. Nothing is stored twice, so a count can't disagree with itself, which is the entire trust argument of the collections console.

The Copilot posts to a local model with a strict JSON contract. The schema is the design decision: the model is allowed to return no recommendation, and has to name what's missing when it does. Most of the product falls out of that one shape.

Vanilla JS and no build step for throwaway prototypes, because the tooling costs more than it returns at this size. For anything with a second contributor or a real component library I'd reach for React and typed props, and I'd expect to be slower for a fortnight.

// the contract that lets the model decline
{
  "recommendation": "convert_to_emi" | null,
  "confidence":     "high" | "low",
  "evidence": ["dpd_47_in_band", …],
  "missing":   ["last_contact", …],
  "policy":    "4.2"
}

// null is a first-class answer, not an error
if (!r.recommendation) render('insufficient', r.missing);

// one source of truth, everything derived
const visible = rows.filter(matches(filters));
const selected = sel.size;         // page-scoped
bar.textContent = `${selected} selected · this page`;