Component responsibilities

A component’s role determines what it can do and what evidence it must display. Keep inquiry, command and setup responsibilities clear.

Inquiry components

Situation, Coming, People and Insights components explain read models. They present currency, period and evidence rather than assembling a new financial truth from incomplete client lists.

Financial commands

Activity’s quick recording dialog asks what happened: spending, receiving, transfer, card repayment or conversion. These commands need visible pending states, duplicate-submission protection and a recovery path for an uncertain response.

A preview, opening a dialog or completing a guide’s informational step does not authorize money recording.

Setup components

Settings manages accounts, cards, income sources, people, plans, vocabulary, imports, sessions and tokens. Creating a label or plan does not create money. Account creation and its dated balance statement must retain their separate success/failure outcomes.

Shared primitives

Use existing buttons, fields and dialog primitives for labels, focus behavior and keyboard interaction. Guidance inside a modal belongs inside its dialog content; a separate focus-owning coach should not fight the modal’s focus scope.

Review a component change

Check its actual API calls, disabled/pending paths, success receipts and failure text. Verify empty, unavailable and different-account behavior. An attractive component with a hidden financial effect violates the responsibility boundary.

Use the design system and destructive controls for the corresponding review.