MobilityOps — final acceptance evidence

Accepted implementation

Implementation under test: 5dda574 (master). The final evidence commit contains documentation only and does not change the accepted runtime.
Live URL: http://192.168.10.150:1236.
Deployment: Unraid, /mnt/user/appdata/mobilityops, Compose project mobilityops.
Data: deterministic, explicitly labelled synthetic demo data.
Database migration: f43d829ab610 (head).

Clean acceptance results — 2026-08-10

Backend, isolated PostgreSQL: 225 passed, 1 dependency deprecation warning (96.71 s)
Playwright, live production:   145 passed (4.4 min)
Ruff:                          clean
Mypy:                          clean
Frontend TypeScript/Vite:      production build passed
npm audit (prod and full):     0 vulnerabilities
Alembic:                       f43d829ab610 (head)

Backend tests ran through compose.yaml plus compose.test.yaml in the disposable mobilityops-test project. Its database, network and volume were removed afterward; no test process ran inside the live API container.

The single serial Playwright run covers 145 browser scenarios: both roles, protected routes, booking lifecycle and return, maintenance/release, user administration, data-quality scanning/assignment/resolution, audit, retryable automation, Knowledge Hub, the complete guided demo, keyboard accessibility and responsive layouts from 360 to 1440 px.

Live operational evidence

After acceptance, demo reset restored an internally checked hand-off state:

users 2 · customers 180 · vehicles 50 · bookings 254 · inspections 75
maintenance 40 · data-quality issues 33 · workflow runs 20
scenario_integrity.all_ready = true

Readiness returned ready with PostgreSQL up; API, database and web containers were healthy. A verified custom-format database backup was written to:

/mnt/user/appdata/mobilityops/backups/postgres/mobilityops-20260810T111913Z.dump

External integrations

n8n: MobilityOps uses the existing central server instance, not a second n8n. Dispatch is enabled and operational with 19 successful persisted runs, zero pending, zero unexpected failures and healthy heartbeat evidence for the vehicle-return and scheduled-quality workflows. One failed item is an explicitly labelled synthetic retry scenario and is excluded from incident counts.
RAGcore: live health returned available/ready for tenant northstar-mobility-demo, workspace mobilityops, collection internal-procedures. A live question returned a grounded answer in 5.1 seconds with three unique, collapsible procedure citations. The UI never substitutes a fabricated answer when evidence is insufficient or the provider is unavailable.
ITWorx MCP Hub: registration is enabled, the Hub is reachable and MobilityOps reports an audited real fleet_ops_get_operations_summary tool call. Tool endpoints are read-only, tenant-bound, client-identity validated, service-authenticated and emit correlation IDs.

Visual acceptance

The production UI was interactively inspected after the automated run. Desktop dashboard, mobile data-quality workbench, Integration Management and Knowledge Hub had no overlap or horizontal page overflow. Filters, SLA/assignment controls, integration states, citations, feedback controls, keyboard landmarks and mobile navigation remained visible and operable. Route-level lazy loading keeps the initial JavaScript chunk near 212 kB instead of the former 572 kB monolith.

Deliberate scope boundary

This is the completed locked MobilityOps PoC, not an unrestricted ERP. It intentionally does not add accounting, payments, public reservations, CRM, inventory, HR, a second RAG stack, a separate MCP server or autonomous write tools. Production deployment for real personal data would still require an organisation identity provider, secrets rotation, central observability/alerting, retention policy and an operated disaster-recovery schedule. Those are deployment-governance concerns, not dead or simulated product functions in the accepted scope.

4.0 KiB Raw Blame History