Xicar Changelog

Product updates

What's new
at Xicar

A clear record of product improvements, fixes, and operational updates, with the reason each change matters.

Browse updates

Latest updates

September 2026

Ride-hailing improves discounts, rating prompts, and production delivery

Ride-hailing now applies the single best eligible location discount to a fare instead of combining competing promotions. The selected discount is reflected consistently in customer and attendant quotes and bookings, usage limits are rechecked during booking creation, and attribution is preserved for admin reporting.

The booking transition to normalized route stops was also hardened for mixed-version deployments. Customer and attendant booking creation temporarily keep legacy endpoint fields synchronized with booking_stops, reads can fall back safely when older rows do not yet have stop records, and the migration path avoids requiring manual production SQL during the cutover.

Rating experience

Customer rating prompts are less intrusive and more predictable. The home screen only prompts once per app run for the most recent eligible completed ride, while ride history now opens the rating sheet immediately and loads any missing driver details in the background. This avoids repeated prompts and removes the wait before a customer can start rating from history.

Attendant Android production distribution

The attendant Android production build is now prepared for Firebase App Distribution instead of Google Play Internal Testing. The workflow builds a production-signed APK, derives the Firebase app ID from the production configuration, and temporarily disables attendant production iOS while leaving other mobile production delivery paths unchanged.

Admin discount management

The admin location-discount form now explains maximum discount and usage-limit fields more clearly. API validation or save errors stay visible in the open modal instead of silently closing it, while true network failures continue to use the existing offline queue behavior.

References

Ride-hailing backend removes unused GraphQL surface and hardens trip completion

The ride-hailing backend removed its unused Lighthouse and GraphQL scaffold, leaving the service focused on its existing REST and WebSocket interfaces.

The removed layer only exposed the default GraphQL hello query and was not used by ride-hailing business operations or mobile clients. Removing it also drops the associated Composer dependencies, schema validation step, configuration, environment settings, resolver, and GraphQL-specific tests.

A regression test now verifies that the backend does not expose a /graphql endpoint or GraphQL route name. No database migration, REST contract, or WebSocket contract changed as part of this cleanup.

Safer trip completion and booking-stop rollout

Trip completion now protects against delayed retries accidentally closing a driver’s newer ride. When a booking ID is supplied to the end-trip request, that booking is validated and takes precedence over the driver’s current Redis assignment.

Recovery handling was also strengthened so pending driver benefits can be retried independently of driver cleanup. Campaign redemption failures now keep the durable recovery marker active instead of being acknowledged as completed, allowing the reconciler to retry benefit publication safely.

Completed trips now keep route-stop progress synchronized during settlement, and scheduled-booking details remain restricted to the intended driver while preserving the expected pre-acceptance flow for immediate bookings.

The rollout of the normalized booking_stops model was made safer for mixed-version deployments. Legacy pickup and drop-off columns are retained for a compatibility release, new writes keep both representations synchronized, reads can fall back to legacy endpoint data when stop rows are missing, and Redis search state is rebuilt through the same compatibility accessors. A repair migration restores and backfills legacy endpoint columns in environments where they were already removed.

References

Backend containerization, service hardening, and private image registry preparation

We prepared the backend deployment path for container-based builds and future image publishing.

A Zot container registry is now available at registry.xicar.net. This gives the platform a private registry endpoint that can be used by upcoming backend image build and deployment workflows.

The ride-hailing, wallet, and affiliate backends also merged their new production Docker implementations. The updated container setup standardizes the Laravel services around production-ready images, with role-specific runtime targets where applicable and serialized startup migrations to avoid competing schema changes during concurrent container starts.

The ride-hailing backend additionally merged updated development and production environment templates for the wallet and affiliate integrations. The documented contract now includes the required wallet service key and affiliate service settings, while keeping those service credentials backend-only.

Ride-hailing booking and attendant safeguards

Customer-visible driver details are now tied more strictly to the driver actually persisted on a booking. Before acceptance, offer recipients are hidden from the customer, and cached driver metadata is only used when it matches the accepted booking owner. Reassignment also clears stale driver and tracking state so the customer experience follows the latest booking ownership.

The attendant application now requires explicit API and WebSocket runtime configuration instead of silently falling back to defaults. Local setup is consolidated around the example environment contract, reducing the chance that a build points at an unintended backend.

Affiliate backend cleanup

The affiliate service removed unused Node.js, Vite, and Tailwind scaffolding from its Laravel backend and replaced the stock browser welcome page with a JSON service-status response. API routes, Swagger support, and the existing health endpoint remain intact while the runtime and development setup no longer depend on unnecessary frontend tooling.

References

Driver ratings, ride-service restrictions, and wallet backend cleanup

Administrative driver rating and ride-service restriction controls are now available end to end, with the matching ride-hailing backend enforcement merged alongside the admin interface work.

Driver ratings and service-level restrictions

The admin interface now shows driver ratings by ride service, including rating source and author attribution, and allows administrators to add ratings tied to either Xiclo two-wheel service or Xicar four-wheel service.

Administrators can also restrict a driver from a specific ride service without disabling the driver’s access to the other service. Restrictions can record a reason and optional supporting rating, and the admin interface supports reinstatement plus review of driver appeals.

Trusted Cloudflare Access identity is forwarded to the backend for these actions so administrative ratings and restriction decisions can be attributed to the authenticated administrator.

The ride-hailing backend now stores the added rating metadata, supports service-specific restriction records and driver appeals, and enforces active restrictions when drivers go online, receive offers, or attempt to accept bookings.

Wallet backend cleanup

The wallet service removed unused Node.js, Vite, and Tailwind scaffolding from the Laravel backend. Its development and container setup is now PHP-only, reducing unnecessary build dependencies while keeping the existing API, JSON status route, health endpoint, and wallet runtime behavior unchanged.

References

Attendant access, booking, and admin workflow improvements

This update brings tighter attendant access controls together with a smoother admin experience for managing day-to-day operations.

Attendant access and registration

Attendant registration now supports explicit pending, active, inactive, and archived account states. New attendants remain in an approval-pending flow until an administrator grants access, while disabled or archived attendants are prevented from continuing service operations.

The attendant app also rechecks account access while it is in use, so administrative changes can take effect without relying on a fresh sign-in. On the backend, duplicate phone checks are normalized, administrative attendant actions are HMAC-protected, and archived attendants retain their historical booking records.

Attendant booking and dashboard workflows

Attendant-created bookings now remain available for matching instead of being automatically cancelled when the normal driver retry budget is exhausted. The app surfaces driver acceptance notifications, keeps active booking status synchronized through WebSocket updates and targeted REST reconciliation, and shows a single completion or cancellation result even when duplicate lifecycle updates arrive.

The attendant home screen now uses a compact dashboard feed for pending, accepted, and trip-started booking counts plus online-driver availability. Booking history shows customer details while withholding assigned-driver information until acceptance, and booking cards expose the booking ID so attendants can match notifications to the correct trip.

Shared WebSocket subscriptions now track ownership per screen, preventing one screen from accidentally disconnecting another screen that is watching the same booking. The backend also batches online-driver session reads to reduce repeated Redis round trips during the dashboard’s periodic refresh.

Admin attendant management

The admin interface now supports editing attendant profiles, enabling or disabling access, archiving accounts, and restoring archived attendants. Booking filters can load the complete attendant list, including archived attendants where historical records need to remain identifiable.

Admin data views also gain clearer loading states, debounced search behavior, client-side sidebar navigation that preserves scroll position, and skeleton placeholders across major dashboard screens.

Scheduling, notifications, and exports

Notification schedules can now be edited, cancelled, and deleted with stronger schedule timing and app validation. Delivery failures are reported with partial fan-out retry details, while status refreshes provide clearer feedback.

Admin date and time rendering is standardized on Manila time, list searches are normalized and debounced, and full booking PDF exports now expose progress and can be cancelled. The admin Docker Compose default database is also updated to xicaradmin.

References

Introducing the Xicar changelog

Xicar now has one place to follow meaningful product and operational changes.

Each update pairs what changed with why it matters, giving the team a shared, business-friendly record of progress without losing the technical details needed for traceability.

Infrastructure
Hugo-powered changelog site

The changelog site now runs on Hugo instead of the custom Python static-site generator. The existing design remains intact, while daily Markdown files, automatic date ordering, month grouping, and the static public/ output make ongoing publishing simpler and more consistent.

The migration also adds Hugo-based smoke checks pinned to version 0.147.7, preserving the site’s JavaScript-free output and validation of links, dates, headings, and security-sensitive content. Cloudflare Pages preview validation passed; production deployment status is not separately verified here.

References

Admin fare controls add service filtering and safer surge validation

The admin fare tools now make service-specific pricing and zone management easier to operate.

Location-discount analytics, location-discount maps, and surge-zone maps can now be filtered by service type, with each view remembering the selected filter. The “All service types” option is handled consistently across the discount and surge-zone flows so administrators can manage rules that apply across both Xiclo and Xicar.

Fare settings also now validate the fallback surge multiplier before saving. Values below 1.0 are rejected with an inline error instead of being silently coerced, while 1.0 remains the supported way to disable fallback surge outside configured zones.

These changes reduce ambiguity when reviewing service-specific fare rules and help prevent invalid fallback surge values from being submitted.

References