The final submission — demonstrate the full Pica and describe what you built.

What to submit:

1. A working app (video or a photo sequence). The full flow: QR → login → menu → cart → payment (Stripe test) → order history. With the Go backend running.
2. Proof of resilience: the menu offline (cache), the error state with no backend, empty states.
3. At least one challenge from step 3 (A, B or C) — implemented and shown.
4. A signed release (lesson 12): app-release.apk/.aab and proof the release build runs on a real device.
5. An architecture write-up (½–1 page): pick one operation (e.g. "place an order") and trace its journey through the layers — from the button tap (Event) to the server response and the UiState change. Name where AuthInterceptor attaches the token and where TableSession supplies the table.

Grading criteria:

Area	What's expected
Full flow	All 8 steps work end-to-end
States	Loading/Success/Empty/Error on every screen
Architecture	Clear layer directions, Koin DI, MVI
Extension	At least one challenge, using the same pattern
Release	Signed, R8, works in the release build

Where next — an honest signpost.

Pica is built as MVVM + repository + Koin DI. That's the right-sized choice, and you now know it end to end. The next step, when the app or team grows (the lesson-12 signpost): a use-case (interactor) layer — "Clean Architecture." It's inserted between the ViewModel and the repository once business rules start piling up in ViewModels. Pica doesn't need it — but now you know what it is and when to reach for it.

Natural extensions also remain: Google sign-in (8b — the same token contract), push notifications for order status, an admin screen.

Congratulations. From an empty Compose screen to a signed, payable, offline-capable app talking to a real backend — you built what restaurants actually use. That's the whole arc: UI → state → data → network → production.