---
title: "Worked examples — The Complete Flow Law"
source: "/reference/layr-002-complete-flow/examples"
description: "Four tasks, each traced from the requested surface to the states a real path reaches."
---
# Worked examples

Part of [LAYR-002 — The Complete Flow Law](/__layr/pages/reference/layr-002-complete-flow.md). The complete rule and agent contract live in the full Markdown representation.

## 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:

```text
/invoices/:id
/invoices/:id/edit
downloadInvoice()
deleteInvoice()
```

Existing table exposes:

```text
Open
Edit
Download
Delete
```

A complete interpretation considers:

```text
ENTRY
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:

```text
[ Delete ]
```

Then immediately:

```text
DELETE /api/invoices/1042
```

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:

```text
Delete
→ remove
→ Undo
```

High-cost irreversible action:

```text
Delete
→ clear confirmation
→ pending
→ success
```

No universal modal requirement exists.

The law requires a deliberate safety-and-recovery strategy.

---

## Example — Edit form

Weak:

```text
Edit
→ form
→ Save
→ API
```

Complete:

```text
entry
→ populated form
→ validation
→ pending
→ success
```

Failure:

```text
server/network failure
→ preserve values
→ explain problem
→ retry
```

Cancel:

```text
return without mutation
```

Unsaved-change warning should exist only when losing the work is meaningful.

---

## Example — Long-running import

Literal implementation:

```text
Upload CSV
[ Import ]
```

then:

```text
Importing...
```

Complete flow may require:

```text
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.

---