The Support page was a single static line plus a mailto link. There is no public
ticket backend (only the internal ops console), so rather than simulate ticket
submission, improve the page truthfully:
- Add an FAQ grounded in features that actually ship (offline recording/sync,
billing + 2FA managed in the mobile app, GPX/CSV export, session revocation,
radar live-presence rules, public vs authenticated group rides).
- Add a validated contact form (name/email/topic/message) that opens a prefilled
email in the visitor's own client. It never claims a ticket was filed and states
plainly that the message is not sent until the visitor sends it.
- Keep support@motorsignal.app as the real, working fallback channel.
- Preserve the existing public-page visual system (content-page / eyebrow / faq-section).
Tests: FAQ + real mailto render; invalid input shows validation errors and no
submission claim; valid input opens a mailto (no simulated ticket) with the topic
and email encoded.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
When a club has no curated routes or a chat channel has no messages, the data layer
returned fixture content with no indication it was sample data, so riders could mistake
MotorSignal's "Coastal Marshes" route or canned chat messages for their club's real data.
Flag fixture-sourced content and label it in the UI:
- Add isExample to ClubRoute and ChatMessage; set it on every fixture fallback path
(empty Firestore collection/channel and the dev demo preview).
- Founder Routes: amber "Examples" count, an explanatory banner, and a per-card "Example"
badge when the routes shown are samples.
- Founder Chat: an "Example thread" pill (instead of "Live Connected") and a banner when
the only messages are examples, so the header never claims a live conversation that
does not exist.
Tests: example-labelled routes render the banner/badge/count; example-labelled chat
renders the banner and "Example thread" pill and does not claim "Live Connected".
Existing route/chat tests (real data, no isExample) remain green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The account page asserted several things that were not backed by real state:
- Two-Factor Authentication was hardcoded to "ENABLED" for every signed-in user.
Now derives from the real Firebase multiFactor enrollment and shows "NOT ENABLED"
(enroll in the mobile app) unless a factor is actually enrolled.
- "App Connections & Sync" showed a hardcoded connected iOS app (iPhone 16 Pro, v4.1.0,
"14m ago") and a paired "Cardo Packtalk Edge". Replaced with truthful states: real
Google account link, authenticated-device count from the real /api/account/sessions
data, and an honest "Unavailable on web" for Bluetooth comms/accessories (a browser
cannot observe hardware pairing). Header status reflects real sign-in state.
- Dashboard metrics initialised to fabricated totals (12,480 mi / 184 rides / 56.4 deg).
Now initialise to zero; AppCloudData replaces them with the rider's real ride totals.
- Dead controls fixed: "Manage Devices" and "Review active sessions" now anchor the real
Active Device Sessions panel; the telemetry-privacy control no longer presents an
unverified setting with a no-op "Change" button (managed in the mobile app).
Also adds the Phase 1 website feature audit matrix (docs/).
Tests: account-truthful-states asserts no fabricated device/pairing/sync claims render
and that 2FA is never shown as ENABLED without a real enrolled factor.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The Ranks & Roles "Operational Permission Matrix" previously waited ~400ms and
showed a "Saved" state without persisting anything. No Firestore document, API
route, or security rule stores or enforces a per-rank capability matrix; club
authorization is role-based (Owner/Admin via getPortalPermissions). Persisting
the matrix would require frozen security-rule changes and would create an
unenforced permission model that misleads owners.
Make the control truthful instead of faking success:
- Render the matrix as a read-only reference of the standard governance model
by default (persistenceAvailable=false): no Save/Reset controls, disabled
toggles, a "View-only reference" indicator, and a notice stating that access
is enforced by Owner/Admin roles and per-rank customization is planned.
- Remove the fake setTimeout save handler and the unconditional success state.
- Retain a forward-compatible editable path behind persistenceAvailable for
when a backend contract ships.
- Document the precise backend contract required to enable persistence.
Tests: read-only matrix renders no Save control, reports no save, and does not
mutate permissions even for Owner/Admin; editable path still fires toggle/save
/reset when persistenceAvailable=true.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Fixed Zyla request accounting to record each actual upstream HTTP attempt exactly once, eliminating double-counting when body parsing, JSON decoding, or normalization fails
- Fix RenderFlex overflow at short landscape breakpoint (640x320) by scaling center controls in ResponsiveDashboardLayout and clamping LeanAngleIndicator bounds
* feat(clubs): enable admin group ride governance
* feat(clubs): add secure member ride discovery
* fix(clubs): protect meeting location in ride discovery
* feat(group-rides): secure club join moderation
* test(clubs): update ride discovery expectations
* test(founder-portal): update rides governance expectations
* fix(group-rides): resolve pre-merge findings on join moderation and discovery
- Block participant hard deletes for accepted status and organizer role for all callers
- Support atomic accessUids removal on invitation decline in firestore.rules
- Restrict mutual-block checks to approvals in GroupRideService, allowing decline of blocked requests
- Implement cursor-paginated candidate scanning with block filtering in website discovery API
- Add comprehensive emulator, vitest, and unit tests covering all 5 findings
* fix(discovery): page candidates until 30 eligible rides collected or query exhausted
- Remove artificial 150 candidate scan ceiling in club rides discovery route
- Continue cursor pagination until 30 unblocked eligible rides are collected or upcoming schedule query is exhausted
- Add test verifying pagination continues past 150 blocked rides to collect all 30 eligible rides
---------
Co-authored-by: Developer <dev@example.com>
Developer
Billie Ponder