Connect the pieces in one small feature
Follow one user action through the interface, app logic, stored data, and the back to the screen.
By the end, you can plan one complete feature across the app and name the checks for its success and failure paths.
Step 1: Follow one parcel
A complete feature follows one action: click → → identity/permission check → saved result → → screen. This is sometimes called a vertical slice. Like tracking a parcel, inspect each handoff instead of guessing from the final display.
Step 2: Specify each checkpoint
For a book , name the book identifier, verified member, availability rule, saved , and allowed fields. Ask which service and database receive the request. If the is missing, check the target environment, access rules, and read filters before concluding no save happened.
Step 3: Plan identity and uncertain outcomes
A is evidence of login. In the Supabase example, carry material to the next , where identity is verified. A browser flag saying loggedIn=true is not verified identity. After a lost save , check the outcome or repeat the same supported action ticket; do not invent success or blindly create another .
Step 4: Inspect the whole trip
Try missing input, unavailable books, denied actions, and a lost . Refresh after sign-in to check persistence. Trace the return-from-login handler, persistence, and next . Inspect redacted metadata, never raw tokens. Explain what is verified and what remains uncertain before adding another feature.
Interactive System Map
Trace one book request from tap to result
This fictional example connects a screen, application rules, saved data, and the response a person sees.
Request to borrow an available book
The feature is complete only when the saved result and the screen agree.
For one borrow , trace the screen action, , verified identity, availability claim, saved , , and updated screen. Show confirmed failure versus lost- behavior. In this Supabase example, also trace login return → → next verified . Propose one small change and checks before editing. Illustrative before / after (behavior, not ready-to-run code): - Click → immediately show Saved + Click → trace result → confirmed success / rejection / outcome check
This follows one through connected parts. It does not require memorizing every HTTP or authentication mechanism.
Picture it, then try it
Follow one request
Track a parcel through its checkpoints. A button starts the trip; it does not prove the parcel arrived.
Browser button → request: bookId + action → server: verify person + permission → database: save permitted result → reply: saved request ID → browser: show confirmed result
The page says Saved, but you cannot find the . Name two things to check before asking AI to recreate the database.
Compare your reasoning with the worked answer
Repeat one . Inspect its and which database/environment it targeted. Then check the read filter and account permissions. A missing in one view could mean a rejected save, the wrong environment, or a view that hides an existing result. Ask AI to report evidence at each checkpoint.
Picture it, then try it
Remembering data versus proving identity
is a notebook. A is evidence of who signed in; writing a name in the notebook is not a verified ID badge.
Supabase SSR example: login link → return handler → session cookie refresh → cookie sent → server verifies identity localStorage → local drafts; not proof of login
The page shows your account after login, but refresh signs you out. What checkpoints should AI inspect without printing tokens?
Compare your reasoning with the worked answer
Trace the return handler, whether material was persisted in , and what the next server verifies. Inspect redacted metadata and results, not raw credentials. A loggedIn=true flag cannot authorize server access. versus choices depend on the app's auth architecture; this example explicitly uses Supabase .
Picture it, then try it
A lost reply is not a rejected save
A shop may receive your order even if its confirmation call drops. Calling again with a new order can create two orders.
Rejected: request → refused → no saved result Confirmed: request → saved → reply received Unknown: request → may be saved → reply lost Safe next step: check result or reuse same supported ticket
A connection drops after Send. What message is truthful, and what must happen before a new save?
Compare your reasoning with the worked answer
Say We could not confirm the save and preserve the input. Check the existing result or retry the same intent with supported duplicate protection. Only say Save failed when evidence confirms rejection; only say Saved after reliable confirmation. Button disabling helps clicks in one tab, not every network retry.
Sources and further reading
The server explicitly rejects a borrow without saving it, but the AI’s screen still says sent. What should change?
Choose one answer.