#Worked flow examples
Four tasks, each traced from the requested surface to the states a real path reaches.
#Example — Invoice card
Prompt:
Add invoice cards to the billing page.
Repository already contains:
- /invoices/:id
- /invoices/:id/edit
- downloadInvoice()
- deleteInvoice()
Existing table exposes:
- Open
- Edit
- Download
- Delete
A complete interpretation considers:
Billing page
DISCOVERY
Card clearly opens invoice
Secondary actions follow existing pattern
ACTION
Open
Edit
Download
Delete
SYSTEM STATE
Collection loading
Delete pending
Download pending if needed
OUTCOME
Edited invoice updates
Deleted invoice disappears
Download behavior is clear
FAILURE
Load failure
Edit/save failure
Delete failure
Download failure
RECOVERY
Retry
Preserve invoice when delete fails
CONTINUATION
Return to billing context
Preserve useful filters/position
CONTEXT
Mobile
Keyboard
Permissions
Long customer names
No new invoice capability was invented.
#Example — Destructive action
A delete button alone is not a complete destructive flow.
Weak:
Then immediately:
Complete Flow asks:
- Is deletion reversible?
- How severe is the consequence?
- Is confirmation appropriate?
- Would undo be better?
- What happens while pending?
- What happens if it fails?
- Is optimistic removal safe?
Low-cost reversible action:
- Delete
- → remove
- → Undo
High-cost irreversible action:
- Delete
- → clear confirmation
- → pending
- → success
No universal modal requirement exists.
The law requires a deliberate safety-and-recovery strategy.
#Example — Edit form
Weak:
- Edit
- → form
- → Save
- → API
Complete:
- entry
- → populated form
- → validation
- → pending
- → success
Failure:
- server/network failure
- → preserve values
- → explain problem
- → retry
Cancel:
Unsaved-change warning should exist only when losing the work is meaningful.
#Example — Long-running import
Literal implementation:
then:
Complete flow may require:
- select
- → validate
- → upload
- → accepted
- → processing
- → progress
- → partial failure
- → completion
- → result summary
- → retry failed items
- → re-entry after navigation
For long work, loading is not a spinner problem.
It is a workflow problem.