# 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 ```text 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: ```text 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.