CCA Winter Patrol App

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. Data: Patrol access is new data. CCA MySQL has no patroller list or role (user_level is only Member, Executive or Admin), so the app would hold it, for example on the Clerk account.

Split into what is usable offline and what is still coming, so a patroller can judge whether to leave the dock. Data: 330 is the real 2026 patrol set: Full or Honorary members with a 2026 payment.

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.

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.

Decision needed: whether the fallback is the device passcode, an app PIN, or a forced online sign-in. Drawn as a device passcode placeholder only.

Proposed help screen, reachable from unlock and from Settings. Unlock, session, upload and email delivery stay four separate ideas.

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. Data: Pins come from the text gps field, filled for 329 of 330. The latitude and longitude columns are empty.

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. G. Fontaine has no coordinates and is reachable only here. The row says so. Data: Rows lead with member name and place (cottlong). A place is shared by up to 16 properties and is blank for 52 of 330, so the 911 address (911location) is what tells them apart.

One field searches member name, place and 911 address. Partial entries accepted, so there is little to type.

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. Data: Past visits carry a date, comment and photos, but no patroller name. The database records only a device ID. There is no mobile field, only cottage and home phone.

Established: a property without coordinates stays usable. Searchable, scannable, reportable. Data: One of the 330 has no gps. Its 911 address and map grid code are still on record.

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. Data: The label encodes users.id, which runs 2 to 3017.

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.

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.

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.

Decision needed: video length cap, resolution and total attachment size per report. All three affect upload over marina LTE. Not invented here.

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. Data: Photos fit the existing checkin_pics table, which already takes several per visit. Video has nowhere to go today: checkin_pics stores base64 JPEG text.

Shown only after the write to the device succeeds. The three lines keep local save, upload and member email separate.

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. Data: Recorded-by and the scan-or-manual source are new fields. The database has no column for either; each check-in stores only a device ID.

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.

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.

Completion is stated as what reached the CCA. Member email is credited to the office, not claimed by the app. Data: Email delivery to members is not recorded anywhere in the database today.

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. Data: Patroller name and email come from the Clerk account, not CCA MySQL.

Drawn without a "Sign out anyway" button until the recovery policy is decided. The frame asks the question instead of answering it.