84 lines
4.0 KiB
Markdown
84 lines
4.0 KiB
Markdown
# 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.
|