Start with the connected interface
The shared shell connects five tabs and uses Navigator for policy and incident pages. Typed demo records supply their content, while common cards, buttons and a Material theme keep related states consistent across features.
That is enough to represent an offline form in the interface, but not to make it usable offline. The record's offline-ready flag changes the card's presentation; it doesn't write a draft to the device or add a submission to an outbox.
Trace what the action actually does
The form button ends in a message explaining that there isn't a live renderer yet. Check-in and assistant actions also return placeholder feedback, and incident review has an empty callback. The route is connected, but the operation behind it hasn't been implemented.
Login follows the same pattern. It derives a display name from the entered email and switches to the shell without checking credentials or obtaining a session. Following the callback gives a more accurate account than reading the screen label alone.
Give saved and accepted work different states
The forms screen identifies a schema-driven renderer, local branching, an outbox and amendment history as future work. Implementing them needs a distinction between a draft saved on the device and a submission accepted by the server, including what happens after a retry or an offline edit. Those are storage and synchronization decisions, not additional labels for the same card.
Check-in similarly needs actual GPS, Wi-Fi, beacon or device signals and rules for accepting them. The current presentation doesn't collect or evaluate those signals. The included test only checks login labels, leaving navigation and feature behavior without demonstrated test coverage in this review.