First use needs a connection and an invited account. No registration, no guest access. Nothing about members or properties appears before authorization.
Clerk is backend only. This screen is ours: CCA type, 4px radii, Bay Blue primary, Shield Green focus ring. Built on Clerk's headless sign-in so email, password, code and MFA all post to the provider.
Same CCA screen family. Code entry and multi-factor both land here rather than on a provider page.
A never-authorized device holds no member data, so there is nothing to show. Better to say that than offer a retry which cannot work.
Signing in and being on the patrol list are two different things. A member account on its own never reaches property data.
→ F01 sign out
Split into what is usable offline and what is still coming, so a patroller can judge whether to leave the dock.
→ F06 ready for patrol
Established (3.1(g)): member data held on the device is encrypted at rest. Stated on the screen because it is a contracted security property. Proposed: this same five-line summary becomes the readiness strip at the top of the Patrol tab, so it is re-checkable mid-patrol.
→ F09 property map
Decision needed: what the fallback is when biometrics fail or aren't enrolled — device passcode, an app PIN, or a forced online sign-in. Drawn here as a placeholder only.
Proposed help screen, reachable from unlock and from Settings. Unlock, session, upload and email delivery stay four separate ideas.
→ F07 unlock
Coverage is pin colour. A bubbler pin is larger, carries a "B" and outranks coverage colour, so hazards read whatever the visit state. Sync sits in a strip above the map, not on it.
Proposed: results replace the map instead of floating over it. The three chips cover the questions patrollers actually ask.
Grouped by coverage, so "what is left" is the default reading. Mainland 07 has no coordinates and is reachable only here. The row says so.
One field searches member name and property ID. Partial entries accepted, so there is little to type.
→ F15 Mainland 07 detail
The sheet keeps the map visible for orientation. Bubbler is stated in words as well as colour. Create report is the one big action.
Proposed: recent visits shown read-only, for context. The bubbler flag belongs to the office. Patrollers cannot edit it here.
Existing Code 128B labels are scanned as they are. Manual lookup stays one tap away, because gloves and cold make a scan fail often. The row of small links is a prototype control.
"Barcode matched" appears only here, and on reports that began with a scan. Identity is drawn large enough to confirm before recording.
No property is named until one is read. The way out is as prominent as the retry.
Different from F18: the read succeeded, the lookup failed. Showing the raw code lets the office trace it later.
Proposed: a record missing from this device shouldn't waste a trip. The visit is recorded against the scanned ID and matched at the office.
The written-report path stays open. Android differs only in the deep-link label and the permanent-denial rule.
→ F22 manual lookup
Established (3.2(a)): the API exposes only Full or Honorary members with a current-year payment, so a label can scan cleanly and still sit outside the patrol list. Different from F19: there the record was missing. Here it exists, and eligibility is what fails.
Where the entry came from is recorded. Scan and manual lookup are carried onto the report and never merged.
→ F23 report form
The property header is pinned for the whole form. The master bubbler flag is read-only. "Barcode matched" is shown because the entry came from F17.
Quick phrases and dictation are both proposals, and both exist to cut typing. Neither replaces the written comment.
→ F25 capture media
Decision needed: video length cap, resolution and total attachment size per report. All three affect upload over marina LTE. Not invented here.
→ F26 review capture
Retake, use, or keep shooting, then return to the report. Captures are written to the device straight away.
No attachment cap is stated or implied. Local save and upload are described as two separate events.
Five states, each with a word as well as a colour: draft, saved locally, uploading, uploaded, retry needed. Reports and sync live in one tab.
"Barcode matched" persists on the record because this entry came from a scan. A manually entered report reads "entered manually" here instead.
→ F33 sync
The failure is scoped to the one file. The report is never described as lost, and the sent parts are marked sent.
Proposed: a look at the file before retrying, with its attempt history. Nothing is deleted quietly. Removal is explicit and confirmed.
Connection, queue and delivery are stated separately. Nothing here implies the member has been emailed.
→ F34 reconnected, sign-in required
Established copy, used verbatim. The second action proves the point: an expired session never blocks the patrol, and the queue survives.
Progress is per report, and the retried attachment resumes instead of restarting. Member email is named as a later step, done at the office.
→ F36 complete
Completion is stated as what reached the CCA. Member email is credited to the office, not claimed by the app.
→ F09 property map
Established (3.1(g)): on-device member data is encrypted at rest. Established (5.2): the previous known-good build stays installed as a fallback between seasons. Proposed: the departure checklist lives here permanently, so it can be re-run before every trip rather than only at first setup.