# Navi Tech Leadership Audit - 2026-05-04

## 1. Executive Summary

Navi has the right high-level shape for the product: four separate apps under `apps/`, shared packages under `packages/`, a NestJS API, Prisma schema, Expo mobile app, Next.js dashboard, Next.js website, typed API client, Zod validators, design tokens, provider abstraction, RBAC scaffolding, audit scaffolding, and UAE seed data.

The current state is a foundation, not an MVP. The architecture direction is credible, but many user-facing flows remain shells or placeholders. The strongest current assets are the app separation, shared packages, docs, Prisma model coverage, API guard structure, mobile auth shell, locale groundwork, and local CI workflow. The highest risks are route-level dashboard authorization, partner isolation coverage, raw Prisma response mismatch with shared DTOs, payment readiness, real provider webhooks, missing migrations, no git repository, and low UI test coverage.

Latest verification snapshot:

- `./bin/bootstrap.sh` completed successfully on 2026-05-04.
- Verified gates passed through bootstrap: Prisma generate, DB push, seed, typecheck, lint, test, and build.
- API tests currently pass: 3 suites and 16 tests.
- App-level import separation is currently clean: apps depend on shared packages and the API client, not on each other.
- Dashboard permissions are now read from `GET /v1/users/me/access`; remaining dashboard risk is route/page action enforcement, not wildcard sidebar permissions.
- Local environment warning remains: active Node is v24.14.1 while `.nvmrc` requests Node 20.10.0.
- Mobile production build is still a placeholder that prints `use eas build`.

During this audit pass, foundation fixes were made in the correct order:

1. Strengthened API env validation and JWT secret wiring.
2. Implemented DB-backed refresh-token rotation.
3. Added a server-side `GET /v1/users/me/access` access contract.
4. Removed the dashboard `['*']` permission stub and resolved dashboard permissions from the API.
5. Extended the shared API client and shared types for the current access contract.
6. Extended dashboard session cookie duration to match refresh-token lifetime.

## 2. Critical Issues

1. `/Users/start-tech/Documents/Claude/Projects/Navi` is not a git repository. There is no commit history, no branch, no diff base, and no safe push process.
2. Dashboard pages are mostly placeholders; sidebar permissions now come from the API, but page/action authorization still needs explicit enforcement.
3. Auth still lacks production OTP request/verify/reset, logout-all, session revocation UX, and refresh lifecycle tests.
4. API env validation is now wired, but production secret rotation and environment promotion rules are still not documented.
5. API responses often return raw Prisma fields while shared types expect DTO money objects.
6. Partner-scoped endpoint coverage is incomplete.
7. Audit logs are present but not append-only protected, source-tagged, or consistently attached to all meaningful actions.
8. Webhook HMAC uses `JSON.stringify(body)`, not raw request bytes.
9. Idempotency is in-memory only.
10. No committed Prisma migrations or production migration flow are present.
11. Mobile OTP, forgot-password, booking checkout, trip-planner execution, saved flows, and settings subpages are incomplete.
12. Payment integration is mock-only and not ready for real booking payments, captures, refunds, reconciliation, or disputes.

## 3. Architecture Conflicts

1. Speed vs separation: Product wants fast MVP screens; CTO/Security require app/API boundaries first. Decision: protect separation now.
2. Dashboard UX gating vs server enforcement: Frontend wants simple sidebar filtering; Security/Backend require API enforcement. Decision: sidebar remains UX only, API remains authority.
3. Fast payment launch vs compliance: Release wants booking payments; Security/DevOps require real provider webhooks, idempotency, audit, refund controls, and secrets first. Decision: payment UI can be designed, but real money launch waits.
4. AI trip planner speed vs trust: Product wants AI itineraries; Security/Backend require prompt governance, provider abstraction, cost limits, and bookable inventory grounding. Decision: keep mock/guided AI until contracts and controls are ready.
5. Arabic launch quality vs MVP speed: Mobile/Website want bilingual from day one; VP Engineering wants narrower scope. Decision: English plus Arabic shells can continue, but every launch screen must pass RTL visual QA.

## 4. Must Fix Before Coding More

1. Initialize git or move this folder into the real repository.
2. Decide the source of truth for the current Navi repo and remove generated artifacts from source review scope: `apps/*/.next`, `apps/api/dist`, `*.tsbuildinfo`.
3. Create initial Prisma migration and stop treating `db push` as deploy strategy.
4. Add DTO mappers for money and public API response shapes.
5. Add DB-backed integration tests for auth refresh, partner isolation, bookings, payments, and audit logs.
6. Complete dashboard route-level permission map and deny states for each protected dashboard route.
7. Implement OTP request/verify/reset before treating signup/login as production-ready.
8. Persist idempotency and webhook events in Redis/Postgres.
9. Add raw-body capture for provider webhooks.
10. Add basic monitoring, structured logs, and release runbooks.

## 5. Can Continue Safely

1. Mobile shell work can continue if it consumes only `@navi/api-client` and shared validators.
2. Public website content and SEO work can continue if it does not pull dashboard/API business logic into the website.
3. Dashboard placeholder replacement can continue route by route, using server-side token forwarding.
4. Shared package expansion can continue for DTOs, validators, and formatters.
5. API module development can continue if every route declares permissions and uses scoped queries.

## 6. Should Wait Until Later

1. Real payment provider launch.
2. Real AI provider launch with user PII.
3. Production partner onboarding at scale.
4. Global country expansion beyond UAE.
5. Full hotel inventory integration.
6. Open partner self-service permissions.
7. Automated refunds or payouts.
8. In-app support chat with sensitive data.

---

# CTO Review

## 1. Role Perspective

The CTO owns investor technical confidence, platform architecture, app separation, security posture, scalability, and the long-term team operating model.

## 2. What This Role Would Check First

- `README.md`
- `pnpm-workspace.yaml`
- `turbo.json`
- `apps/api/src/app.module.ts`
- `apps/api/prisma/schema.prisma`
- `packages/types/src`
- `packages/validators/src`
- `packages/api-client/src`
- `docs/product/01-product-architecture.md`
- `docs/architecture/05-database-entity-map.md`
- `docs/operations/21-infrastructure-and-deployment.md`

## 3. Current Issues Or Likely Gaps

- Good separation exists: `apps/api`, `apps/mobile`, `apps/dashboard`, `apps/website`.
- Shared packages exist, but API responses are not yet contract-mapped.
- No git repository exists in the Navi folder.
- Generated build folders are present locally and can hide true source state.
- API env validation was present but not wired before this pass.

## 4. Missing Features Or Missing Architecture

- Initial migration and production migration deploy process.
- Contract tests that compare API JSON to shared DTO expectations.
- Real observability and release runbooks.
- ADRs for payment provider, AI provider, auth/session model, and country expansion.

## 5. Bugs Or Risks To Look For

- Raw Prisma fields reaching apps and breaking typed UI assumptions.
- Dashboard and mobile accidentally calling different API base URLs.
- Business logic leaking into mobile/dashboard because endpoints are incomplete.
- Local generated output being treated as source.

## 6. What Should Be Fixed Now

- Keep app separation strict.
- Add API access contract and dashboard server permission lookup.
- Wire API env validation.
- Implement refresh-token rotation.

## 7. What Can Wait

- Real provider-specific integrations.
- Multi-country rollout details.
- Advanced personalization.

## 8. Exact Implementation Recommendations

- Use `apps/api` as the only home for business logic.
- Keep `packages/types`, `packages/validators`, `packages/config`, `packages/ui`, and `packages/api-client` as shared-only packages.
- Add `docs/architecture/27-application-boundaries.md`.
- Add DTO mapper files such as `apps/api/src/common/dto/money.ts`, `apps/api/src/modules/listings/listing.mapper.ts`, and `apps/api/src/modules/bookings/booking.mapper.ts`.
- Add ADRs under `docs/architecture/adr/`.

## 9. QA Checks For This Role

- `corepack pnpm typecheck`
- `corepack pnpm lint`
- `corepack pnpm test`
- `corepack pnpm build`
- Verify no app imports another app directly.
- Verify apps only share through `packages/*`.

## 10. Conflict Points With Other Roles

- VP Engineering may want faster feature velocity.
- Product may want payment and AI demos before the foundation is ready.
- Security will block shortcuts around permissions and secrets.

---

# VP Engineering Review

## 1. Role Perspective

The VP Engineering owns delivery sequencing, release readiness, test gates, hiring, and execution discipline.

## 2. What This Role Would Check First

- `package.json`
- `turbo.json`
- `.github/workflows/ci.yml`
- `bin/bootstrap.sh`
- `docs/qa/12-qa-checklist.md`
- `docs/qa/13-development-task-list.md`
- `docs/qa/PROJECT_AUDIT_2026-05-04.md`

## 3. Current Issues Or Likely Gaps

- CI exists but cannot protect history if this folder is not a git repo.
- Mobile and dashboard tests are effectively absent.
- Several package test scripts are placeholders.
- Bootstrap is strong for local setup.

## 4. Missing Features Or Missing Architecture

- Release branch model.
- Required PR checks.
- Test ownership matrix.
- Definition of Done per module.
- Bug triage workflow.

## 5. Bugs Or Risks To Look For

- Teams closing tickets when only placeholders exist.
- Builds passing because tests say `echo 'no tests'`.
- Mobile `build` script is a placeholder.
- CI references Postgres but does not start a Postgres service.

## 6. What Should Be Fixed Now

- Create real test targets for dashboard and mobile.
- Add CI services for Postgres and Redis or make tests independent of them.
- Create `docs/qa/release-gates.md`.

## 7. What Can Wait

- Full e2e matrix across all booking providers.
- Advanced performance test suites.

## 8. Exact Implementation Recommendations

- Convert dashboard `test` script from placeholder to Vitest or Playwright component tests.
- Add API contract tests against DTO schemas.
- Add Expo route smoke tests for mobile.
- Add ticket templates: foundation, API, dashboard, mobile, security, QA.

## 9. QA Checks For This Role

- Quality gate must include typecheck, lint, tests, build, DB migration validation.
- Add "no placeholder test scripts" as a release blocker.

## 10. Conflict Points With Other Roles

- CTO wants long-term architecture; VP needs thin slices.
- QA wants wider regression gates; VP needs gates that do not freeze delivery.

---

# Backend Lead Review

## 1. Role Perspective

The Backend Lead owns service boundaries, NestJS modules, database shape, RBAC enforcement, audit logs, integrations, DTOs, and API standards.

## 2. What This Role Would Check First

- `apps/api/src/app.module.ts`
- `apps/api/src/common/guards/rbac.guard.ts`
- `apps/api/src/common/middleware/jwt-auth.middleware.ts`
- `apps/api/src/common/scope/prisma-scope.ts`
- `apps/api/src/common/interceptors/audit.interceptor.ts`
- `apps/api/src/modules/*`
- `apps/api/prisma/schema.prisma`
- `apps/api/prisma/seed.ts`

## 3. Current Issues Or Likely Gaps

- RBAC exists and is globally applied.
- Request context exists.
- Scoping helper exists and is tested.
- Several modules are public read-only or minimal.
- Partner assigned read endpoints are incomplete.
- Audit endpoint currently allows support-level read without assigned filtering.
- Payment/refund/provider lifecycle is incomplete.
- Webhook replay protection is not durable.

## 4. Missing Features Or Missing Architecture

- DTO mapper layer.
- Consistent module service layer.
- Categories, orders, payouts, reviews, tickets, feature flags, profile update.
- Payment confirm/capture/failure handling.
- Real webhook event table usage.
- Refresh-token rotation was missing before this pass.

## 5. Bugs Or Risks To Look For

- `bookings.create` accepts listing ID and trusts current listing price without availability checks.
- `payments.createIntent` can accept any amount/currency and optional booking ID without verifying booking ownership or amount matches booking total.
- `refunds.request` can request refund for any payment ID if user has `refund.create`.
- `audit-logs` does not scope for partner users.
- `translator.image` accepts base64 without size limits.

## 6. What Should Be Fixed Now

- Implement DTO mappers.
- Verify payment intent ownership and amount.
- Scope audit logs.
- Add validators for payments/refunds/translator.
- Add DB-backed tests.

## 7. What Can Wait

- Full provider integrations.
- Advanced search.
- Real inventory/channel manager integrations.

## 8. Exact Implementation Recommendations

- Add `apps/api/src/common/dto/money.ts`.
- Add `apps/api/src/modules/users/users.module.ts` access endpoint. Completed in this pass.
- Add `packages/types/src/identity.ts` `CurrentAccess`. Completed in this pass.
- Add `packages/validators/src/payment.ts` and `refund.ts`.
- Add `apps/api/src/modules/payments/payments.service.ts`.
- Move controller business logic into services as modules mature.

## 9. QA Checks For This Role

- Auth refresh happy path and replayed old refresh token rejection.
- Partner A cannot read Partner B bookings/listings/orders/refunds/audit.
- Payment amount mismatch is rejected.
- All mutation routes are audited.
- Webhook replay is rejected.

## 10. Conflict Points With Other Roles

- Frontend may want endpoint shortcuts; backend should require contracts.
- Release may want mock payments; backend must label them as non-production.

---

# Mobile Lead Review

## 1. Role Perspective

The Mobile Lead owns Expo architecture, navigation, API client use, performance, offline behavior, iOS/Android quality, deep links, and app-store readiness.

## 2. What This Role Would Check First

- `apps/mobile/app/_layout.tsx`
- `apps/mobile/app/(tabs)/_layout.tsx`
- `apps/mobile/app/(auth)/*`
- `apps/mobile/src/api/client.ts`
- `apps/mobile/src/state/auth.ts`
- `apps/mobile/src/state/locale.ts`
- `apps/mobile/src/i18n`
- `apps/mobile/app.json`

## 3. Current Issues Or Likely Gaps

- Auth state persists securely.
- Login and signup call the API.
- OTP and forgot-password remain stubs.
- Tabs are protected.
- Locale is persisted, but language reload UX is incomplete.
- Many routes are placeholders.
- Missing settings routes referenced in product docs.
- No real native/EAS build gate.

## 4. Missing Features Or Missing Architecture

- OTP verification and session completion.
- Offline network detection and retry queue.
- Booking checkout navigation.
- Real trip-planner form submission.
- Translator route.
- Payment-method screens.
- Accessibility and RTL device review.

## 5. Bugs Or Risks To Look For

- OTP screen routes to home without session.
- Access token expiry signs user out because refresh flow is not wired in client.
- Generated idempotency keys use random/time and are not stable per retry.
- RTL flips may require app reload but UI does not tell user clearly.

## 6. What Should Be Fixed Now

- Wire refresh endpoint into `@navi/api-client` and mobile unauthorized flow.
- Implement OTP endpoints before shipping signup.
- Add missing settings routes or remove links.

## 7. What Can Wait

- Rich animations.
- Deep personalization.
- Advanced offline booking.

## 8. Exact Implementation Recommendations

- Update `apps/mobile/src/api/client.ts` to refresh tokens before clearing session.
- Add `apps/mobile/src/network/offline.ts`.
- Add route smoke tests for every file in `apps/mobile/app`.
- Keep all business rules in API; mobile only renders and submits.

## 9. QA Checks For This Role

- iOS and Android login/signup/logout.
- Token expiry refresh.
- Arabic RTL switch and app restart behavior.
- Offline emergency screen fallback.
- Deep link to listing, booking, trip.

## 10. Conflict Points With Other Roles

- Mobile wants fast local fallbacks; Security wants PII and bookings server-authoritative.
- Product wants smooth OTP bypass in demos; Release must label bypass as non-production.

---

# Frontend Lead Review

## 1. Role Perspective

The Frontend Lead owns website and dashboard architecture, Next.js routing, shared UI usage, server-side route protection, RBAC UI, and visual quality.

## 2. What This Role Would Check First

- `apps/dashboard/src/middleware.ts`
- `apps/dashboard/src/app/(app)/layout.tsx`
- `apps/dashboard/src/lib/session.ts`
- `apps/dashboard/src/lib/permissions.ts`
- `apps/dashboard/src/components/Sidebar.tsx`
- `apps/website/src/app/[locale]/layout.tsx`
- `apps/website/src/components/Nav.tsx`
- `packages/ui/src`

## 3. Current Issues Or Likely Gaps

- Dashboard login writes HttpOnly cookie.
- Dashboard permission lookup previously returned `['*']`. Fixed in this pass.
- Dashboard pages are mostly static cards.
- Website locale routes exist but SEO metadata is incomplete.
- Website root `<html>` likely stays static outside locale layout.

## 4. Missing Features Or Missing Architecture

- Server-side dashboard API proxy.
- Dashboard page-level permission map.
- Data tables with loading/error/empty states.
- Website sitemap, robots, metadataBase, hreflang, Open Graph.
- Shared component primitives promoted into `@navi/ui`.

## 5. Bugs Or Risks To Look For

- Dashboard user can open protected page with cookie but no permissions and see empty sidebar; page content still renders.
- Dashboard placeholders can be mistaken for implemented features.
- Website Arabic visual layout can fail if CSS uses left/right instead of logical spacing.

## 6. What Should Be Fixed Now

- Add `requireDashboardPermission()` helper.
- Wire `/users`, `/roles`, `/permissions`, `/businesses`, and `/audit-logs` to API.
- Add website metadata and legal pages.

## 7. What Can Wait

- Rich marketing animations.
- Partner application wizard.
- Advanced dashboard analytics.

## 8. Exact Implementation Recommendations

- Create `apps/dashboard/src/lib/api.ts` for server-side API calls with session token.
- Create `apps/dashboard/src/lib/routePermissions.ts`.
- Add route-level deny state.
- Add `apps/website/src/app/sitemap.ts` and `robots.ts`.

## 9. QA Checks For This Role

- Dashboard unauthenticated redirect.
- Dashboard partner permissions hide global admin nav.
- Dashboard page denies without required permission.
- Website `/en` and `/ar` render correct `dir`.

## 10. Conflict Points With Other Roles

- Frontend wants visible UX quickly; Backend/Security require contract and permission checks first.

---

# DevOps Engineer Review

## 1. Role Perspective

The DevOps Engineer owns CI/CD, secrets, hosting, deploys, backups, monitoring, and reliability.

## 2. What This Role Would Check First

- `.github/workflows/ci.yml`
- `docker-compose.yml`
- `bin/bootstrap.sh`
- `apps/*/.env.example`
- `docs/operations/20-observability-and-slos.md`
- `docs/operations/21-infrastructure-and-deployment.md`
- `docs/operations/22-disaster-recovery.md`

## 3. Current Issues Or Likely Gaps

- Local bootstrap is useful.
- CI exists, but the Navi folder is not git-initialized.
- CI does not define Postgres/Redis service containers.
- No deploy workflow is present.
- No backups or environment promotion scripts are present.

## 4. Missing Features Or Missing Architecture

- Staging and production environment definitions.
- Secrets manager choice.
- Migration deploy job.
- Health checks and readiness checks.
- Log drain and alerting.
- Mobile EAS credentials and release tracks.

## 5. Bugs Or Risks To Look For

- CI green locally but impossible on GitHub because services are missing.
- Production boots with default secrets if validation is bypassed.
- Webhook secrets missing per provider.

## 6. What Should Be Fixed Now

- Initialize git and enforce CI.
- Add service containers to CI.
- Add API env validation. Completed in this pass.
- Add migration deploy checklist.

## 7. What Can Wait

- Full autoscaling.
- Multi-region deployment.
- Data warehouse.

## 8. Exact Implementation Recommendations

- Add GitHub Actions services for Postgres/Redis.
- Add `prisma migrate deploy` to deployment.
- Add `apps/api/Dockerfile`, `apps/dashboard/Dockerfile`, `apps/website/Dockerfile`.
- Add staging secrets inventory.

## 9. QA Checks For This Role

- Fresh clone bootstrap.
- CI from clean checkout.
- API `/v1/health`.
- DB migration rollback rehearsal.
- Restore-from-backup rehearsal.

## 10. Conflict Points With Other Roles

- DevOps may block releases until backups and monitoring exist; Release wants dates. Decision: no real payments without monitoring and rollback.

---

# Security Engineer Review

## 1. Role Perspective

The Security Engineer owns auth, authorization, secrets, PII, rate limits, privacy, auditability, and threat modeling.

## 2. What This Role Would Check First

- `apps/api/src/common/guards/rbac.guard.ts`
- `apps/api/src/common/middleware/jwt-auth.middleware.ts`
- `apps/api/src/modules/auth/auth.service.ts`
- `apps/api/src/common/interceptors/audit.interceptor.ts`
- `apps/api/src/common/security/hmac.ts`
- `apps/dashboard/src/lib/session.ts`
- `apps/dashboard/src/middleware.ts`
- `apps/api/prisma/schema.prisma`
- `docs/operations/19-security-and-compliance.md`

## 3. Current Issues Or Likely Gaps

- RBAC guard exists.
- Rate limiting exists globally.
- Refresh rotation was missing before this pass.
- Audit logs exist but do not yet cover every meaningful action.
- PII retention and deletion workflows are not implemented.
- Webhook raw-body verification is not production-ready.

## 4. Missing Features Or Missing Architecture

- Password reset and OTP security.
- Session revoke/logout-all.
- Role assignment audit.
- Permission assignment restrictions.
- PII field classification.
- Data deletion workflow.
- Secrets rotation process.

## 5. Bugs Or Risks To Look For

- Dashboard cookie stores refresh token in base64 JSON without signing/encryption. HttpOnly helps, but server-side session storage is stronger.
- Partner users may access placeholder pages that do not fetch data yet; real data endpoints must remain scoped.
- Translator image upload can contain passport/medical/PII and needs size/type/retention controls.
- Payment routes need ownership and amount validation.

## 6. What Should Be Fixed Now

- Refresh-token rotation. Completed in this pass.
- Remove dashboard `*` stub. Completed in this pass.
- Add payment/refund validators and ownership checks.
- Add audit source/status fields in schema.

## 7. What Can Wait

- SOC 2 evidence automation.
- Advanced anomaly detection.
- Fine-grained ABAC beyond partner scope.

## 8. Exact Implementation Recommendations

- Add `Session.revokedAt`.
- Add audit fields: `source`, `status`, `errorMessage`, `requestId`, `businessId`, `countryId`.
- Add `@Audited()` to auth refresh/logout, role/membership changes, payment/refund updates, content publish.
- Sign or store dashboard session server-side.

## 9. QA Checks For This Role

- Expired access token refreshes.
- Old refresh token cannot be reused.
- Suspended user token fails.
- Partner A cannot read Partner B.
- Dashboard with no permission cannot render protected content.

## 10. Conflict Points With Other Roles

- Security will block payment launch until provider webhooks, idempotency, audit, and ownership checks are complete.

---

# QA Lead Review

## 1. Role Perspective

The QA Lead owns release gates, regression strategy, device matrix, automation, bug prevention, and sign-off evidence.

## 2. What This Role Would Check First

- `apps/api/test`
- package `test` scripts
- `docs/qa/12-qa-checklist.md`
- `docs/qa/27-final-verification.md`
- `.github/workflows/ci.yml`
- mobile route map
- dashboard route map

## 3. Current Issues Or Likely Gaps

- API has two test files.
- Dashboard and website test scripts are placeholders.
- Mobile test script passes with no tests.
- No e2e tests.
- No device matrix evidence.

## 4. Missing Features Or Missing Architecture

- API integration tests against DB.
- Contract tests.
- Playwright dashboard/website tests.
- Expo route smoke tests.
- Manual QA checklist per flow.

## 5. Bugs Or Risks To Look For

- Placeholder pages passing as complete.
- Login/refresh edge cases.
- RTL layout breakage.
- Booking amount mismatch.
- Partner data leakage.
- Offline state missing.

## 6. What Should Be Fixed Now

- Add tests for the auth refresh lifecycle.
- Add dashboard permission test.
- Add route existence tests for mobile settings links.

## 7. What Can Wait

- Full load testing.
- Full marketplace search automation.

## 8. Exact Implementation Recommendations

- Add `apps/api/test/auth/refresh.spec.ts`.
- Add `apps/dashboard/src/__tests__/route-permissions.test.ts`.
- Add mobile route smoke tests.
- Add a "no placeholder page" audit before MVP sign-off.

## 9. QA Checks For This Role

- Auth, RBAC, booking, payment, refund, audit, translation, i18n, RTL, empty/error/offline, dashboards, website SEO.

## 10. Conflict Points With Other Roles

- QA will slow feature delivery if every placeholder must be proven. Use risk tiers: P0 for auth/RBAC/payment/booking, P1 for core mobile/partner dashboard, P2 for marketing polish.

---

# Release Manager Review

## 1. Role Perspective

The Release Manager owns app store release, API/dashboard/website deployment coordination, rollback, hotfixes, release notes, and launch gating.

## 2. What This Role Would Check First

- `.github/workflows/ci.yml`
- `apps/mobile/app.json`
- `apps/mobile/package.json`
- `docs/strategy/16-go-to-market.md`
- `docs/qa/27-final-verification.md`
- `docs/operations/21-infrastructure-and-deployment.md`

## 3. Current Issues Or Likely Gaps

- No git repo means no release branch or tags.
- No EAS config.
- Mobile build script is a placeholder.
- No deploy scripts.
- No rollback plan.
- Product is not MVP-complete.

## 4. Missing Features Or Missing Architecture

- Versioning policy.
- Changelog discipline.
- Release candidate checklist.
- Rollback playbook.
- Store screenshots and legal pages.

## 5. Bugs Or Risks To Look For

- Shipping app with OTP bypass.
- Shipping dashboard with placeholder super-admin assumptions.
- Payment provider mock reaching production.
- Missing privacy/terms content.

## 6. What Should Be Fixed Now

- Initialize git and release branches.
- Add real mobile build plan.
- Add staging deploy plan.
- Add release checklist.

## 7. What Can Wait

- Public marketing campaign.
- Global rollout.

## 8. Exact Implementation Recommendations

- Add `docs/release/01-release-process.md`.
- Add `eas.json`.
- Add environment matrix for local/staging/production.
- Define rollback for API, DB, website, dashboard, mobile.

## 9. QA Checks For This Role

- All P0 gates pass.
- Staging smoke verified.
- App store metadata ready.
- Legal pages approved.
- Payment provider in correct mode.

## 10. Conflict Points With Other Roles

- Release may want a demo; Security/QA can approve demo only if it is clearly labeled non-production and mock-money only.

---

# Conflict Review

## Conflict 1: CTO vs VP Engineering

- Conflicting roles: CTO and VP Engineering.
- CTO wants: architecture separation, contracts, migrations, auth/RBAC correctness.
- VP Engineering wants: feature velocity and visible progress.
- Why it matters: Navi can look impressive while hiding fragile boundaries.
- Best decision: keep foundation gates mandatory, ship thin vertical slices.
- Final recommendation: every new feature must include API contract, shared validator, server permission, UI state, and QA note.
- Must document: Definition of Done and app-boundary ADR.

## Conflict 2: Frontend Lead vs Security Engineer

- Frontend wants: sidebar filtering and fast dashboard pages.
- Security wants: server-enforced route/data permissions.
- Why it matters: UI hiding is not authorization.
- Best decision: dashboard uses permission UX, API remains authoritative.
- Final recommendation: add route-level dashboard permission checks and keep API checks mandatory.
- Must document: Dashboard permission model.

## Conflict 3: Mobile Lead vs Backend Lead

- Mobile wants: local fallbacks and smooth offline flows.
- Backend wants: server-authoritative bookings/payments/profile state.
- Why it matters: offline-created bookings or payments can mislead travelers.
- Best decision: offline can show emergency/static saved content; bookings/payments require server confirmation.
- Final recommendation: offline booking actions become drafts only, never confirmed bookings.
- Must document: Offline state rules.

## Conflict 4: Release Manager vs Security Engineer

- Release wants: payment launch and booking demos.
- Security wants: webhook, idempotency, audit, ownership, and provider controls.
- Why it matters: financial flows are high risk.
- Best decision: mock payment demo allowed; real money launch blocked.
- Final recommendation: separate demo readiness from production payment readiness.
- Must document: Payment go-live checklist.

## Conflict 5: Product/AI vs CTO/Security

- AI wants: trip planner with rich generation.
- CTO/Security wants: provider abstraction, prompt governance, PII controls, cost controls.
- Why it matters: AI can leak data, hallucinate bookings, or create unsupported promises.
- Best decision: AI output must be grounded in Navi inventory and labelled until booked.
- Final recommendation: AI trip planner generates suggestions; booking confirmation is separate.
- Must document: AI safety and provider policy.

---

# Combined Priority List

1. Initialize git and source-control hygiene.
2. Add app-boundary ADR.
3. Create initial Prisma migration.
4. Add DTO mappers for API responses.
5. Add DB-backed auth refresh tests.
6. Add partner-isolation integration tests.
7. Add dashboard route permission map.
8. Wire dashboard data through server API helpers.
9. Implement OTP request/verify/reset.
10. Wire mobile refresh-token flow.
11. Add payment/refund validators and ownership checks.
12. Persist idempotency.
13. Persist webhook events and raw body.
14. Add audit fields and coverage.
15. Wire booking checkout.
16. Wire trip planner generate flow.
17. Add website SEO and legal pages.
18. Add CI service containers.
19. Add release runbook.
20. Add mobile EAS build config.

# Top 20 Missing Items

1. Git repository.
2. Initial Prisma migration.
3. Production migration deploy.
4. DTO mapper layer.
5. `/auth/logout`.
6. `/auth/logout-all`.
7. OTP request/verify endpoints.
8. Password reset endpoints.
9. Dashboard API proxy helper.
10. Dashboard route permission map.
11. Mobile refresh-token handling.
12. DB-backed integration tests.
13. Payment amount ownership checks.
14. Provider webhook raw-body handling.
15. Durable idempotency.
16. Durable webhook replay protection.
17. Audit log source/status/error fields.
18. Website sitemap/robots/hreflang.
19. EAS config.
20. Release rollback plan.

# Top 20 Technical Risks

1. No git history.
2. Mock providers mistaken for production.
3. Raw Prisma response mismatch.
4. Cross-partner data leakage in future endpoints.
5. Payment intent amount spoofing.
6. Refund IDOR.
7. Webhook spoofing due raw-body gap.
8. In-memory idempotency loss.
9. Missing migrations.
10. Dashboard cookie not server-side session-backed.
11. Missing audit coverage.
12. PII stored without classification.
13. Translator image size/retention risk.
14. Weak test coverage.
15. CI missing services.
16. Mobile build placeholder.
17. RTL regressions.
18. OTP bypass.
19. AI hallucinated itinerary promises.
20. Missing monitoring and backup proof.

# Top 20 Product Gaps

1. Real booking checkout.
2. Payment capture.
3. Refund workflow.
4. Partner dashboard data tables.
5. Partner membership management.
6. Traveler booking detail.
7. Saved item UX.
8. Listing detail content.
9. Service category search/filter.
10. Trip planner real inputs.
11. Trip planner bookable output.
12. Translator route in mobile.
13. Emergency UX polish.
14. Profile/settings completion.
15. Contact/partner lead capture.
16. Privacy/terms final copy.
17. Arabic full copy coverage.
18. Website SEO.
19. Admin reports.
20. Support tickets.

# Top 20 Bugs To Test For

1. Reusing old refresh token after refresh.
2. Suspended user login/refresh.
3. Dashboard without access token.
4. Dashboard with partner token showing admin nav.
5. Partner A reading Partner B data.
6. Booking creates with suspended listing.
7. Booking amount changes after price update.
8. Payment intent with arbitrary amount.
9. Payment intent for another user's booking.
10. Refund for another user's payment.
11. Webhook replay accepted twice.
12. Webhook bad signature accepted as processed.
13. Translator base64 oversized payload.
14. Arabic RTL layout overflow.
15. Mobile OTP bypass.
16. Mobile token expiry signs out without refresh.
17. Website `/ar` metadata wrong.
18. Dashboard route content renders without permission.
19. Empty state missing for no bookings/listings.
20. Offline emergency fails without network.

# Exact Next Implementation Slice

Slice name: Foundation Contract and Access Hardening.

1. Add app-boundary ADR.
2. Add DTO mappers for `User`, `Listing`, `Booking`, `Trip`, and money.
3. Add API response schemas or mapper tests.
4. Add `GET /v1/users/me/access` and dashboard server permission lookup. Completed in this pass.
5. Add refresh-token rotation. Completed in this pass.
6. Add API env validation. Completed in this pass.
7. Add tests for refresh lifecycle.
8. Add dashboard route permission deny state.
9. Add initial Prisma migration.
10. Update CI services.

# Files And Folders To Inspect

- `package.json`
- `pnpm-workspace.yaml`
- `turbo.json`
- `.github/workflows/ci.yml`
- `bin/bootstrap.sh`
- `apps/api/prisma/schema.prisma`
- `apps/api/prisma/seed.ts`
- `apps/api/src/app.module.ts`
- `apps/api/src/common`
- `apps/api/src/modules`
- `apps/mobile/app`
- `apps/mobile/src/api`
- `apps/mobile/src/state`
- `apps/mobile/src/i18n`
- `apps/dashboard/src/app`
- `apps/dashboard/src/lib`
- `apps/dashboard/src/components`
- `apps/website/src/app`
- `packages/types/src`
- `packages/validators/src`
- `packages/api-client/src`
- `packages/ui/src`
- `docs`

# Files And Folders To Create Or Update

Updated in this pass:

- `apps/api/src/app.module.ts`
- `apps/api/src/modules/auth/auth.service.ts`
- `apps/api/src/modules/users/users.module.ts`
- `apps/dashboard/src/app/(app)/layout.tsx`
- `apps/dashboard/src/app/api/auth/login/route.ts`
- `apps/dashboard/src/lib/permissions.ts`
- `packages/api-client/src/endpoints/users.ts`
- `packages/types/src/identity.ts`
- `docs/qa/NAVI_TECH_LEADERSHIP_AUDIT_2026-05-04.md`

Create next:

- `docs/architecture/27-application-boundaries.md`
- `docs/release/01-release-process.md`
- `apps/api/src/common/dto/money.ts`
- `apps/api/src/modules/listings/listing.mapper.ts`
- `apps/api/src/modules/bookings/booking.mapper.ts`
- `apps/api/test/auth/refresh.spec.ts`
- `apps/dashboard/src/lib/api.ts`
- `apps/dashboard/src/lib/routePermissions.ts`
- `apps/website/src/app/sitemap.ts`
- `apps/website/src/app/robots.ts`
- `apps/mobile/eas.json`

# Recommended Tickets

1. Initialize Navi source control and clean generated artifacts.
2. Add app-boundary ADR and import-boundary lint rule.
3. Add Prisma initial migration and deploy checklist.
4. Add API DTO mappers and contract tests.
5. Add auth refresh lifecycle tests.
6. Add OTP request/verify/reset endpoints.
7. Wire mobile token refresh and OTP.
8. Add dashboard server API helper and route permission map.
9. Wire dashboard users/roles/permissions to API.
10. Add partner isolation DB integration tests.
11. Add payment validators and amount checks.
12. Add refund ownership and approval checks.
13. Persist idempotency in Redis/Postgres.
14. Persist webhook events and raw-body verification.
15. Expand audit schema and audit coverage.
16. Add website SEO and legal pages.
17. Add mobile EAS config and route smoke tests.
18. Add CI Postgres/Redis services.
19. Add release and rollback runbook.
20. Add MVP placeholder burn-down board.

# Final Go Or No-Go Decision

No-go for production or app-store release.

Go for foundation development and controlled local demo only, with mock payments and mock AI clearly labelled. The architecture direction is good enough to continue, but MVP work must proceed through foundation slices, not random feature pages.

# End-State Notes

## What Was Audited

The Navi monorepo shape, app boundaries, API modules, Prisma schema, RBAC, auth/session model, audit logs, payment/refund scaffolding, webhook scaffolding, dashboard route protection, mobile navigation/auth/i18n shell, website locale structure, CI/bootstrap, docs, and shared packages.

## What Was Changed

- API validates env during boot and uses configured JWT secrets.
- Refresh tokens are DB-backed, hashed, and rotated.
- API exposes current user access context.
- Dashboard no longer grants `*` permissions by default.
- Dashboard sidebar permissions now come from the API via the HttpOnly session token.
- Dashboard session cookie lifetime now matches refresh-token lifetime.
- Shared types and API client include current access.
- This audit document was updated with the latest verification snapshot and current risk wording.

## What Still Needs Fixing

Migrations, DTO mappers, auth tests, OTP endpoints, mobile refresh flow, dashboard data wiring, partner isolation integration tests, payment/refund ownership checks, webhook raw body/replay protection, durable idempotency, audit schema expansion, CI service containers, EAS config, website SEO/legal, and release runbook.

## Decisions Made

1. Preserve app separation.
2. Keep API as the authorization authority.
3. Do not treat dashboard sidebar filtering as security.
4. Block real payments until provider controls are production-grade.
5. Keep AI suggestions separate from booking confirmation.

## Commands To Run

```bash
./bin/bootstrap.sh
corepack pnpm --filter @navi/types typecheck
corepack pnpm --filter @navi/api-client typecheck
corepack pnpm --filter @navi/dashboard typecheck
corepack pnpm --filter @navi/api typecheck
corepack pnpm typecheck
corepack pnpm lint
corepack pnpm test
corepack pnpm build
```

## Recommended Next Prompt

Continue Navi foundation slice. Initialize git if needed, add app-boundary ADR, add API DTO mappers for User/Listing/Booking/Trip money shapes, add refresh-token lifecycle tests, and add dashboard route permission checks. Do not add new product features until these checks pass.