State completeness

Not every component needs every state. It needs the states its own task can reach, which is a shorter and more specific list.

A useful candidate-state set:

Not every component needs every state.

Ask:

Which of these states can actually occur in this task?

Then design those.

Every meaningful action creates a loop:

The loop is incomplete when the user cannot tell what happened.

Examples:

• save succeeds but UI never updates,
• upload completes but file never appears,
• deletion succeeds but row remains,
• background job finishes invisibly.

Failure creates:

An error banner may explain failure but still leave the user stranded.

Batch work may produce:

Do not label that simply "success" or "failure."

A complete flow may need:

depending on task scale.

Users leave.

Connections fail.

Long tasks continue.

For significant-duration work ask:

• Can the user navigate away?
• Does work continue?
• Is status persisted?
• Can they return?
• Is completion discoverable?
• Can failure be revisited?

Not every short mutation needs this.

Long-running workflows often do.

Use three boundaries.

The minimum required for correct interaction.

Adds behavior clearly established by the product.

Adds a new capability.

Requires explicit product approval.