Docs Cleanup

docs/ARCHITECTURE-OVERVIEW.md

@@ -41,12 +41,6 @@ MotoVaultPro is a single-tenant vehicle management application built with a **6-
          +------------------+                        +--------------------+
               (frontend network)                          (backend network)
                                                               |
-                                                              v
-                                                     +-------------------+
-                                                     |    Platform       |
-                                                     | Python + FastAPI  |
-                                                     |   Port: 8000      |
-                                                     +-------------------+
                                                               |
                             +---------------------------------+
                             |                                 |
@@ -103,14 +97,12 @@ MotoVaultPro is a single-tenant vehicle management application built with a **6-
 7. Backend → Response → Frontend
 ```
 
-### Backend to Platform Flow
+### Backend Platform Flow
 ```
-1. Backend Feature → HTTP Request → Platform Service
-   - URL: http://mvp-platform:8000
-   - Headers: Authorization: Bearer <API_KEY>
-2. Platform → Query PostgreSQL (vehicles schema)
-3. Platform → Check/Update Redis Cache
-4. Platform → Response → Backend
+1. Backend Feature → Calls platform domain services (TypeScript in-process)
+2. Platform module → Query PostgreSQL (vehicles schema)
+3. Platform module → Check/Update Redis cache
+4. Platform response → Returned to caller (vehicles, frontend proxies, etc.)
 ```
 
 ### Data Access Flow
@@ -196,53 +188,51 @@ MotoVaultPro is a single-tenant vehicle management application built with a **6-
   - Session storage (future)
   - Rate limiting (future)
 
-### Platform (Vehicle Data Service)
-- **Technology**: Python 3.11 + FastAPI
-- **Build**: Custom Dockerfile from `mvp-platform-services/vehicles/`
-- **Port**: 8000 (internal)
-- **Networks**: backend, database
-- **Dependencies**: PostgreSQL, Redis
-- **Health Check**: `wget http://localhost:8000/health` (30s interval)
+### Platform Module (Vehicle Data)
+- **Technology**: TypeScript feature capsule inside `backend/src/features/platform/`
+- **Runtime**: Shares the `mvp-backend` Fastify container
+- **Dependencies**: PostgreSQL, Redis (accessed via backend connection pool)
+- **Deployment**: Bundled with backend build; no separate container or port
+- **Health**: Covered by backend `/health` endpoint and feature-specific logs
 - **Configuration**:
-  - `/app/config/production.yml` - Service config
-  - `/app/config/shared.yml` - Shared config
+  - `backend/src/features/platform/domain/*.ts` - Business logic
+  - `backend/src/features/platform/data/*.ts` - Database + vPIC integration
 - **Secrets**:
-  - `postgres-password` - Shared database access
+  - Reuses backend secrets (PostgreSQL, Auth0, etc.)
 - **Purpose**:
   - Vehicle make/model/trim/engine data
   - VIN decoding (planned)
   - Standardized vehicle information
 
-## Platform Service Integration
+## Platform Module Integration
 
 ### Current Architecture
-The Platform service is a **separate Python container** that provides vehicle data capabilities to the backend. This separation exists for:
-- **Technology Independence**: Python ecosystem for data processing
-- **Specialized Caching**: Year-based hierarchical caching strategy
-- **Resource Isolation**: Independent scaling and monitoring
+Platform capabilities now run **in-process** within the backend as a feature capsule. This delivers:
+- **Shared Language & Tooling**: TypeScript across the stack
+- **Centralized Caching**: Reuses backend Redis helpers for year-based lookups
+- **Simplified Operations**: No extra container to build, scale, or monitor
 
 ### Shared Infrastructure
-- **Database**: Both Backend and Platform use `mvp-postgres`
-- **Cache**: Both services share `mvp-redis`
-- **Network**: Connected via `backend` and `database` networks
-- **Secrets**: Share database credentials
+- **Database**: Uses the backend connection pool against `mvp-postgres`
+- **Cache**: Shares the backend Redis client (`mvp-redis`)
+- **Runtime**: Packaged with the `mvp-backend` container and Fastify plugins
+- **Secrets**: Relies on the same secret files as the backend (PostgreSQL, Auth0, etc.)
 
 ### Communication Pattern
-```javascript
-// Backend calls Platform via internal HTTP
-const response = await fetch('http://mvp-platform:8000/api/v1/vehicles/makes?year=2024', {
-  headers: {
-    'Authorization': `Bearer ${platformApiKey}`
-  }
+```typescript
+// Vehicles feature pulling platform data via domain services
+const platformService = new PlatformVehicleDataService({
+  db: postgresPool,
+  cache: redisClient
 });
+
+const makes = await platformService.getMakes({ year: 2024 });
 ```
 
-### Future Evolution
-**Planned**: Absorb Platform service into Backend as a feature capsule
-- Timeline: Post-MVP phase
-- Approach: Rewrite Python service in Node.js
-- Location: `backend/src/features/vehicle-platform/`
-- Benefits: Simplified deployment, shared codebase, reduced containers
+### Ongoing Work
+- Continue migrating remaining FastAPI utilities into TypeScript where needed
+- Expand `/api/platform/*` endpoints as new lookup types are added
+- Monitor backend logs for `platform` namespace entries to verify health
 
 ## Feature Capsule Architecture
 
@@ -255,7 +245,8 @@ backend/src/features/
 ├── fuel-logs/         # Fuel tracking
 ├── maintenance/       # Service records
 ├── stations/          # Gas station locations
-└── documents/         # Document storage
+├── documents/         # Document storage
+└── platform/          # Vehicle data + VIN decoding
 ```
 
 ### Feature Structure
@@ -372,7 +363,6 @@ The application uses Kubernetes-inspired configuration patterns:
 
 **Secrets** (File-based):
 - `/run/secrets/postgres-password` - Database credentials
-- `/run/secrets/platform-vehicles-api-key` - Service auth
 - `/run/secrets/auth0-client-secret` - OAuth credentials
 - `/run/secrets/google-maps-api-key` - External API keys
 
@@ -384,14 +374,13 @@ CONFIG_PATH: /app/config/production.yml
 SECRETS_DIR: /run/secrets
 DATABASE_HOST: mvp-postgres
 REDIS_HOST: mvp-redis
-PLATFORM_VEHICLES_API_URL: http://mvp-platform:8000
 ```
 
 ## Development Workflow
 
 ### Container Commands (via Makefile)
 ```bash
-make start          # Start all 6 containers
+make start          # Start all 5 containers
 make stop           # Stop all containers
 make restart        # Restart all containers
 make rebuild        # Rebuild and restart containers
@@ -407,12 +396,10 @@ docker ps
 
 # View specific service logs
 docker logs mvp-backend -f
-docker logs mvp-platform -f
 docker logs mvp-postgres -f
 
 # Test health endpoints
-curl http://localhost:3001/health  # Backend
-curl http://localhost:8000/health  # Platform
+curl http://localhost:3001/health  # Backend (includes platform module)
 ```
 
 ### Database Access

docs/PLATFORM-SERVICES.md

@@ -1,13 +1,13 @@
-# MVP Platform Service
+# MVP Platform Module
 
 ## Overview
 
-The MVP Platform service is an **integrated service** that provides platform capabilities to the MotoVaultPro application. This service is part of the simplified 6-container architecture.
+The MVP Platform module is fully integrated inside the MotoVaultPro backend container. It delivers all platform capabilities without requiring a separate service or container in the simplified five-container stack.
 
 ## Architecture
 
-The platform service is integrated into the main application stack:
-- **Service Container**: mvp-platform
+The platform module runs as part of the backend service:
+- **Runtime**: `mvp-backend` container (Fastify API)
 - **Shared Database**: Uses mvp-postgres
 - **Shared Cache**: Uses mvp-redis
 
@@ -37,18 +37,17 @@ The platform provides vehicle data capabilities including:
 
 **Start All Services**:
 ```bash
-make start  # Starts all 6 containers
+make start  # Starts the five-container stack
 ```
 
-**Service Logs**:
+**Backend Logs (includes platform module)**:
 ```bash
-make logs  # All service logs
-docker logs mvp-platform
+make logs-backend
 ```
 
-**Service Shell Access**:
+**Backend Shell (platform code lives here)**:
 ```bash
-docker exec -it mvp-platform sh
+make shell-backend
 ```
 
 ### Database Management
@@ -66,10 +65,10 @@ make db-shell-app
 ## Deployment Strategy
 
 ### Integrated Deployment
-The platform service deploys with the main application:
+The platform module deploys with the main application:
 - Same deployment pipeline
 - Shares database and cache
-- Deployed as part of 6-container stack
+- Deployed as part of the five-container stack
 
 ## Integration Patterns
 
@@ -85,7 +84,7 @@ Application features access platform data through shared database:
 
 **Service Discovery Problems**:
 - Verify Docker networking: `docker network ls`
-- Check container connectivity: `docker exec -it mvp-platform sh`
+- Check backend container connectivity: `docker compose exec mvp-backend sh`
 
 **Database Connection Issues**:
 - Verify mvp-postgres is healthy
@@ -93,19 +92,19 @@ Application features access platform data through shared database:
 
 ### Health Checks
 
-**Verify Platform Service**:
+**Verify Backend Service (contains platform module)**:
 ```bash
-docker ps | grep mvp-platform
+docker compose ps mvp-backend
 ```
 
 ### Logs and Debugging
 
 **Service Logs**:
 ```bash
-docker logs mvp-platform --tail=100 -f
+docker compose logs -f mvp-backend
 ```
 
 **Database Logs**:
 ```bash
-docker logs mvp-postgres --tail=100 -f
+docker compose logs -f mvp-postgres
 ```

docs/PROMPTS.md

@@ -14,11 +14,11 @@ MotoVaultPro uses a 4-agent team for optimal development velocity and quality en
 - Platform service integration
 - Backend tests and migrations
 
-**Platform Service Agent** - Independent microservices
-- Building new platform services in `mvp-platform-services/{service}/`
-- FastAPI microservice development
-- ETL pipelines and service databases
-- Platform service tests and deployment
+**Platform Feature Agent** - Integrated platform module
+- Enhancing `backend/src/features/platform/`
+- Vehicle lookup + VIN decoding logic
+- Redis/SQL performance tuning for platform endpoints
+- Platform module tests and documentation
 
 **Mobile-First Frontend Agent** - Responsive UI/UX
 - React components in `frontend/src/features/{feature}/`
@@ -45,10 +45,10 @@ Task: "Build responsive UI for {feature}. Read backend API docs and implement mo
 Test on 320px and 1920px viewports."
 Agent: Mobile-First Frontend Agent
 
-# Platform microservice
-Task: "Create {service} platform microservice with FastAPI.
-Implement API, database, and health checks with tests."
-Agent: Platform Service Agent
+# Platform module work
+Task: "Enhance platform feature capsule (backend/src/features/platform).
+Implement API/domain/data changes with accompanying tests."
+Agent: Platform Feature Agent
 
 # Quality validation
 Task: "Validate {feature} quality gates. Run all tests, check linting, verify mobile + desktop.
@@ -109,11 +109,12 @@ Agent: Quality Enforcer Agent
 - Database: `backend/src/features/{feature}/data/`
 - After changes: `make rebuild` then check logs
 
-### Platform Service Changes (Python)
-**Agent**: Platform Service Agent
-- Service: `mvp-platform-services/{service}/`
-- API: `mvp-platform-services/{service}/api/`
-- After changes: `make rebuild` then check service health
+### Platform Module Changes (TypeScript)
+**Agent**: Platform Feature Agent
+- Feature capsule: `backend/src/features/platform/`
+- API routes: `backend/src/features/platform/api/`
+- Domain/data: `backend/src/features/platform/domain/` and `data/`
+- After changes: `make rebuild` then verify platform endpoints via backend logs/tests
 
 ### Database Changes
 - Add migration: `backend/src/features/{feature}/migrations/00X_description.sql`
@@ -159,12 +160,12 @@ Agent: Quality Enforcer Agent
 4. Ensure touch targets are 44px minimum
 5. Validate keyboard navigation on desktop
 
-### Add Platform Service Integration
-**Agents**: Platform Service Agent + Feature Capsule Agent
-1. Platform Service Agent: Implement service endpoint
-2. Feature Capsule Agent: Create client in `external/platform-{service}/`
-3. Feature Capsule Agent: Add circuit breaker and caching
-4. Test integration with both agents
+### Add Platform Integration
+**Agents**: Platform Feature Agent + Feature Capsule Agent
+1. Platform Feature Agent: Implement/update platform endpoint logic
+2. Feature Capsule Agent: Update consuming feature client (e.g. `external/platform-vehicles/`)
+3. Feature Capsule Agent: Adjust caching/circuit breaker strategies as needed
+4. Joint testing: run targeted unit/integration suites
 5. Quality Enforcer Agent: Validate end-to-end
 
 ### Run Quality Checks
@@ -188,9 +189,9 @@ Code is complete when:
 
 ## Architecture Quick Reference
 
-### Hybrid Platform
-- **Platform Microservices**: Independent services in `mvp-platform-services/`
-- **Application Features**: Modular monolith in `backend/src/features/`
+### Application Stack
+- **Backend Feature Capsules**: Modular monolith in `backend/src/features/`
+- **Platform Module**: Vehicle data + VIN decoding in `backend/src/features/platform/`
 - **Frontend**: React SPA in `frontend/src/`
 
 ### Feature Capsule Pattern
@@ -206,29 +207,21 @@ backend/src/features/{feature}/
 └── tests/                 # Unit + integration tests
 ```
 
-### Platform Service Pattern
-Each service is independent:
-```
-mvp-platform-services/{service}/
-├── api/                   # FastAPI application
-├── database/              # SQLAlchemy models + migrations
-└── tests/                 # Service tests
-```
 
 ## Important Context
 
 - **Auth**: Frontend uses Auth0, backend validates JWTs
 - **Database**: PostgreSQL with user-isolated data (user_id scoping)
-- **Platform APIs**: Authenticated via API keys (service-to-service)
+- **Platform APIs**: Exposed via `/api/platform/*`, secured with Auth0 JWTs
 - **Caching**: Redis with feature-specific TTL strategies
-- **Testing**: Jest (backend/frontend), pytest (platform services)
+- **Testing**: Jest (backend + frontend)
 - **Docker-First**: All development in containers (production-only)
 
 ## Agent Coordination Rules
 
 ### Clear Ownership
 - Feature Capsule Agent: Backend application features
-- Platform Service Agent: Independent microservices
+- Platform Feature Agent: Platform capsule inside backend
 - Mobile-First Frontend Agent: All UI/UX code
 - Quality Enforcer Agent: Testing and validation only
 
@@ -264,4 +257,4 @@ mvp-platform-services/{service}/
 - Testing: `docs/TESTING.md`
 - Context Loading: `.ai/context.json`
 - Development Guidelines: `CLAUDE.md`
-- Feature Documentation: `backend/src/features/{feature}/README.md`
+- Feature Documentation: `backend/src/features/{feature}/README.md`

docs/README.md

@@ -22,5 +22,58 @@ Project documentation hub for the 5-container single-tenant architecture with in
 ## Notes
 
 - Canonical URLs: Frontend `https://motovaultpro.com`, Backend health `http://localhost:3001/health`.
-- Hosts entry required: `127.0.0.1 motovaultpro.com`.
 - Feature test coverage: Basic test structure exists for vehicles and documents features; other features have placeholder tests.
+
+
+## Cleanup Notes
+> Documentation Audit
+
+  - Documented commands make test/make test-frontend appear across README.md:12-17, backend/README.md:20-38, docs/TESTING.md:24-49, AI-INDEX.md:8, and frontend/
+  README.md:8-28; the Makefile only advertises them in help (Makefile:11-12) with no corresponding targets, so the instructions currently break.
+  - README.md:27 and AI-INDEX.md:19 point folks to http://localhost:3001/health, but docker-compose.yml:77-135 never exposes that port, meaning the reachable
+  probe is https://motovaultpro.com/api/health via Traefik.
+  - docs/TESTING.md:11-99,169-175 commit to full per-feature suites and fixtures such as vehicles.fixtures.json, yet backend/src/features/fuel-logs/tests and
+  backend/src/features/maintenance/tests contain no files (see find output), and backend/src/features/vehicles/tests/fixtures is empty.
+  - Backend fuel-log docs still describe the legacy contract (gallons, pricePerGallon, mpg field) in backend/src/features/fuel-logs/README.md:20-78, but the
+  code now accepts/returns dateTime, fuelUnits, costPerUnit, efficiency, etc. (backend/src/features/fuel-logs/domain/fuel-logs.service.ts:17-320).
+
+  Security & Platform
+
+  - docs/VEHICLES-API.md:35-36 and 149-151 still require an API key, while the platform routes enforce Auth0 JWTs via fastify.authenticate (backend/src/
+  features/platform/api/platform.routes.ts:20-42); there’s no API key configuration in the repo.
+  - docs/VEHICLES-API.md:38-41 promises 1-hour Redis TTLs, but PlatformCacheService stores dropdown data for six hours and successful VIN decodes for seven days
+  (backend/src/features/platform/domain/platform-cache.service.ts:27-110).
+  - docs/SECURITY.md:15-16 claims “Unauthenticated Endpoints – None,” yet /health and /api/health are open (backend/src/app.ts:69-86); docs/SECURITY.md:25-
+  29 also states Postgres connections are encrypted even though the pool uses a plain postgresql:// URL without SSL options (backend/src/core/config/config-
+  loader.ts:213-218; backend/src/core/config/database.ts:1-16).
+  - docs/SECURITY.md:21-23 references the old FastAPI VIN service, but VIN decoding now lives entirely in TypeScript (backend/src/features/platform/domain/vin-
+  decode.service.ts:1-114).
+
+  Feature Guides
+
+  - backend/src/features/vehicles/README.md:15-108 still references an implemented dropdown proxy, a platform-vehicles client folder, and a platform-
+  vehicles.client.test.ts, yet the service methods remain TODO stubs returning empty arrays (backend/src/features/vehicles/domain/vehicles.service.ts:165-193)
+  and there is no such client or test file in the tree.
+  - docs/VEHICLES-API.md:58-97 says the frontend consumes /api/vehicles/dropdown/*, but the current client hits /platform/* and expects raw arrays (frontend/
+  src/features/vehicles/api/vehicles.api.ts:35-69) while the backend responds with wrapped objects like { makes: [...] } (backend/src/features/platform/api/
+  platform.controller.ts:48-94), so either the docs or the code path needs realignment.
+  - backend/src/features/fuel-logs/README.md:150-153 advertises a fuel-stats:vehicle:{vehicleId} Redis cache and response fields like totalLogs/averageMpg, but
+  getVehicleStats performs fresh queries and returns { logCount, totalFuelUnits, totalCost, averageCostPerUnit, totalDistance, averageEfficiency, unitLabels }
+  with no caching (backend/src/features/fuel-logs/domain/fuel-logs.service.ts:226-320).
+  - backend/src/features/documents/README.md:4,23-25 describes S3-compatible storage and a core/middleware/user-context dependency; in reality uploads go to
+  the filesystem adapter (backend/src/core/storage/storage.service.ts:1-48; backend/src/core/storage/adapters/filesystem.adapter.ts:1-86) and there is no user-
+  context module in backend/src/core.
+  - docs/DATABASE-SCHEMA.md:109-111 asserts station caching happens in Redis, but Station data is persisted in Postgres tables such as station_cache
+  (backend/src/features/stations/data/stations.repository.ts:11-115), and docs/DATABASE-SCHEMA.md:155-157 mentions “RESTRICT on delete” even though
+  migrations use ON DELETE CASCADE (backend/src/features/fuel-logs/migrations/001_create_fuel_logs_table.sql:18-21; backend/src/features/maintenance/
+  migrations/002_recreate_maintenance_tables.sql:21-43).
+
+  Questions
+
+  - Do we want to add the missing make test / make test-frontend automation (so the documented workflow survives), or should the documentation be rewritten to
+  direct people to the existing docker compose exec ... npm test commands?
+  - For the vehicles dropdown flow, should the docs be updated to call out the current TODOs, or is finishing the proxy implementation (and aligning the
+  frontend/client responses) a higher priority?
+
+  Suggested next steps: decide on the build/test command strategy, refresh the security/platform documentation to match the Auth0 setup and real cache
+  behaviour, and schedule a pass over the feature READMEs (vehicles, fuel logs, documents) so they match the implemented API contracts.

docs/VEHICLES-API.md

@@ -3,10 +3,10 @@
 This document explains the end‑to‑end Vehicles API architecture after the platform service rebuild, how the MotoVaultPro app consumes it, how migrations/seeding work, and how to operate the stack in production‑only development.
 
 ## Overview
-- Architecture: MotoVaultPro Application Service (Fastify + TS) consumes the MVP Platform service (FastAPI) with shared Postgres and Redis.
+- Architecture: MotoVaultPro backend (Fastify + TypeScript) includes an integrated platform module that shares Postgres and Redis with the rest of the stack.
 - Goal: Predictable year→make→model→trim→engine cascades, production‑only workflow, AI‑friendly code layout and docs.
 
-## Platform Vehicles Service
+## Platform Vehicles Module
 
 ### Database Schema (Postgres schema: `vehicles`)
 - `make(id, name)`
@@ -20,12 +20,12 @@ This document explains the end‑to‑end Vehicles API architecture after the pl
 Idempotent constraints/indexes added where applicable (e.g., unique lower(name), unique(model_id, year), guarded `CREATE INDEX IF NOT EXISTS`, guarded trigger).
 
 ### API Endpoints (Bearer auth required)
-Prefix: `/api/v1/vehicles`
-- `GET /years` → `[number]` distinct years (desc)
-- `GET /makes?year={year}` → `{ makes: { id, name }[] }`
-- `GET /models?year={year}&make_id={make_id}` → `{ models: { id, name }[] }`
-- `GET /trims?year={year}&make_id={make_id}&model_id={model_id}` → `{ trims: { id, name }[] }`
-- `GET /engines?year={year}&make_id={make_id}&model_id={model_id}&trim_id={trim_id}` → `{ engines: { id, name }[] }`
+Prefix: `/api/platform`
+- `GET /api/platform/years` → `[number]` distinct years (desc)
+- `GET /api/platform/makes?year={year}` → `{ makes: { id, name }[] }`
+- `GET /api/platform/models?year={year}&make_id={make_id}` → `{ models: { id, name }[] }`
+- `GET /api/platform/trims?year={year}&make_id={make_id}&model_id={model_id}` → `{ trims: { id, name }[] }`
+- `GET /api/platform/engines?year={year}&make_id={make_id}&model_id={model_id}&trim_id={trim_id}` → `{ engines: { id, name }[] }`
 
 Notes:
 - `make_id` is maintained for a consistent query chain, but engines are enforced by `(year, model_id, trim_id)`.
@@ -41,14 +41,13 @@ Notes:
 - **Configurable**: Set via `CACHE_TTL` environment variable in seconds
 
 ### Seeds & Specific Examples
-Seed files under `mvp-platform-services/vehicles/sql/schema/`:
-- `001_schema.sql` – base tables
-- `002_constraints_indexes.sql` – constraints/indexes
-- `003_seed_minimal.sql` – minimal Honda/Toyota scaffolding
-- `004_seed_filtered_makes.sql` – Chevrolet/GMC examples
-- `005_seed_specific_vehicles.sql` – requested examples:
-  - 2023 GMC Sierra 1500 AT4x → Engine L87 (6.2L V8)
-  - 2017 Chevrolet Corvette Z06 Convertible → Engine LT4 (6.2L V8 SC)
+Legacy FastAPI SQL seed scripts covered:
+- Base schema (`001_schema.sql`)
+- Constraints/indexes (`002_constraints_indexes.sql`)
+- Minimal Honda/Toyota scaffolding (`003_seed_minimal.sql`)
+- Chevrolet/GMC examples (`004_seed_filtered_makes.sql`)
+- Targeted sample vehicles (`005_seed_specific_vehicles.sql`)
+Contact the data team for access to these archival scripts if reseeding is required.
 
 Reapply seeds on an existing volume:
 - `docker compose exec -T mvp-postgres psql -U mvp_user -d mvp_db -f /docker-entrypoint-initdb.d/005_seed_specific_vehicles.sql`
@@ -133,22 +132,18 @@ VIN/License rule
 
 ### Rebuild a single service
 - Frontend: `docker compose up -d --build frontend`
-- Backend: `docker compose up -d --build backend`
-- Platform API: `docker compose up -d --build mvp-platform`
+- Backend (includes platform module): `docker compose up -d --build backend`
 
 ### Logs & Health
-- Backend: `/health` – shows status/feature list
-- Platform: `/health` – shows database/cache status
-- Logs:
-  - `make logs-backend`, `make logs-frontend`
-  - `docker compose logs -f mvp-platform`
+- Backend: `/health` – shows status/feature list, including platform readiness
+- Logs: `make logs-backend`, `make logs-frontend`
 
 ### Common Reset Sequences
 - Platform seed reapply (non‑destructive): apply `005_seed_specific_vehicles.sql` and flush Redis cache.
 - Platform reset (WARNING - DESTRUCTIVE to shared resources):
   - `docker compose rm -sf mvp-postgres mvp-redis`
   - `docker volume rm motovaultpro_postgres_data motovaultpro_redis_data`
-  - `docker compose up -d mvp-postgres mvp-redis mvp-platform`
+  - `docker compose up -d mvp-postgres mvp-redis mvp-backend`
   - Note: This will destroy ALL application data, not just platform data, as database and cache are shared
 
 ## Security Summary
@@ -169,9 +164,9 @@ VIN/License rule
   - Ensure Postgres is up; the runner now waits/retries, but confirm logs.
 
 ## Notable Files
-- Platform schema & seeds: `mvp-platform-services/vehicles/sql/schema/001..005`
-- Platform API code: `mvp-platform-services/vehicles/api/*`
+- Platform schema & seeds: maintained by database admins (legacy FastAPI scripts available on request)
+- Platform API integration: `backend/src/features/platform/api/*`
 - Backend dropdown proxy: `backend/src/features/vehicles/api/*`
-- Backend platform client: `backend/src/features/vehicles/external/platform-vehicles/*`
+- Backend platform module: `backend/src/features/platform/*`
 - Backend migrations runner: `backend/src/_system/migrations/run-all.ts`
 - Frontend vehicles UI: `frontend/src/features/vehicles/*`