# Dashboard Provider And Third Party Integration Prompts

Goal: let Navi show all categories while allowing the dashboard to control which provider or third party API powers each category.

Important rule: dashboard must not store secrets. It should store configuration and vault secret references only.

## Prompt P.1 Provider Integration Architecture Audit

```text
You are operating on the Navi monorepo at:

/Users/start-tech/Documents/Claude/Projects/Navi

Navi is a UAE travel companion platform with a standalone iOS and Android mobile app, standalone public website, standalone admin and partner dashboard, and central API backend.

Repo structure:
apps/api
apps/mobile
apps/dashboard
apps/website
packages/ui
packages/types
packages/validators
packages/config
packages/api-client
docs

Tech direction:
API: NestJS, Fastify, Prisma, Postgres, Redis
Mobile: Expo Router, React Native, TypeScript
Dashboard: Next.js, TypeScript
Website: Next.js, TypeScript
Package manager: pnpm
Monorepo: turbo
Languages: English and Arabic
UI must support RTL.

Operating rules:
1. One focused task only.
2. Branch name must match the task.
3. Use conventional commits.
4. Do not delete code unless replacing it with a safer working version.
5. Never weaken auth, RBAC, validation, audit logs, rate limits, payment safety, or security.
6. Never commit secrets.
7. Do not touch unrelated files.
8. If you find conflicts or uncertainty, stop and report before making risky changes.
9. Follow existing repo patterns.
10. Keep mobile, dashboard, website, and API separated.
11. Business logic belongs in the API, not frontend screens.
12. Shared packages may contain only types, validators, config, API client, telemetry, money utilities, or design tokens.
13. All third party integrations must use provider interfaces and adapter classes.
14. Do not create fake production logic. Local demo mode is allowed only when isolated, clearly named, and impossible to enable in production by accident.
15. Every finished task must include summary, files changed, tests run, risks, rollback plan, and next recommended step.

Before editing files:
1. Run git status.
2. Inspect relevant folders.
3. Explain what you found.
4. Then implement only the requested task.

Finish format:
1. Summary
2. Files changed
3. Commands run
4. What works now
5. What is mocked or local only
6. What still needs real credentials or provider approval
7. Risks
8. Rollback plan
9. Next recommended prompt


Branch:
wave1/provider-integration-audit

Task:
Audit current provider and third party integration readiness.

Do not edit files.

Check:
1. Service category models
2. Business or Partner models
3. Listing models
4. Integration provider models
5. Current API client patterns
6. Current webhook patterns
7. Current credential storage risk
8. Dashboard settings screens
9. Provider health monitoring
10. Demo data usage

Output:
1. Current integration architecture
2. Missing provider registry pieces
3. Security risks
4. Dashboard gaps
5. API gaps
6. Recommended implementation order
7. Exact next prompt
```

## Prompt P.2 Provider Integration Registry API

```text
You are operating on the Navi monorepo at:

/Users/start-tech/Documents/Claude/Projects/Navi

Navi is a UAE travel companion platform with a standalone iOS and Android mobile app, standalone public website, standalone admin and partner dashboard, and central API backend.

Repo structure:
apps/api
apps/mobile
apps/dashboard
apps/website
packages/ui
packages/types
packages/validators
packages/config
packages/api-client
docs

Tech direction:
API: NestJS, Fastify, Prisma, Postgres, Redis
Mobile: Expo Router, React Native, TypeScript
Dashboard: Next.js, TypeScript
Website: Next.js, TypeScript
Package manager: pnpm
Monorepo: turbo
Languages: English and Arabic
UI must support RTL.

Operating rules:
1. One focused task only.
2. Branch name must match the task.
3. Use conventional commits.
4. Do not delete code unless replacing it with a safer working version.
5. Never weaken auth, RBAC, validation, audit logs, rate limits, payment safety, or security.
6. Never commit secrets.
7. Do not touch unrelated files.
8. If you find conflicts or uncertainty, stop and report before making risky changes.
9. Follow existing repo patterns.
10. Keep mobile, dashboard, website, and API separated.
11. Business logic belongs in the API, not frontend screens.
12. Shared packages may contain only types, validators, config, API client, telemetry, money utilities, or design tokens.
13. All third party integrations must use provider interfaces and adapter classes.
14. Do not create fake production logic. Local demo mode is allowed only when isolated, clearly named, and impossible to enable in production by accident.
15. Every finished task must include summary, files changed, tests run, risks, rollback plan, and next recommended step.

Before editing files:
1. Run git status.
2. Inspect relevant folders.
3. Explain what you found.
4. Then implement only the requested task.

Finish format:
1. Summary
2. Files changed
3. Commands run
4. What works now
5. What is mocked or local only
6. What still needs real credentials or provider approval
7. Risks
8. Rollback plan
9. Next recommended prompt


Branch:
wave1/provider-integration-registry-api

Task:
Build the provider integration registry API.

Scope:
1. Add IntegrationProvider model if missing.
2. Add IntegrationCredentialRef model if missing. Store vault path or secret reference only, never secret value.
3. Add ProviderCapability model if missing.
4. Add ProviderHealthCheckLog model if missing.
5. Add ProviderWebhookEndpoint model if missing.
6. Add ProviderMapping model for external field mapping.
7. Add statuses:
   DISABLED
   CONFIGURED
   SANDBOX
   LIVE
   ERROR
8. Add endpoints:
   GET /v1/admin/integrations/providers
   POST /v1/admin/integrations/providers
   GET /v1/admin/integrations/providers/:id
   PATCH /v1/admin/integrations/providers/:id
   POST /v1/admin/integrations/providers/:id/test-connection
   GET /v1/admin/integrations/providers/:id/health
9. RBAC:
   integration.provider.read.all
   integration.provider.write.all
   integration.provider.test.all
10. Write AuditLog for create/update/test.
11. Add validators.
12. Add tests.

Acceptance criteria:
1. Providers can be configured without storing secrets.
2. Connection test endpoint exists.
3. Health logs are tracked.
4. Audit logs are written.
5. Tests pass.

Run:
pnpm typecheck
pnpm lint
pnpm test api

Final report:
1. Files changed
2. Schema changes
3. Endpoints added
4. Tests run
5. Security notes
6. Rollback plan
```

## Prompt P.3 Provider Integration Dashboard

```text
You are operating on the Navi monorepo at:

/Users/start-tech/Documents/Claude/Projects/Navi

Navi is a UAE travel companion platform with a standalone iOS and Android mobile app, standalone public website, standalone admin and partner dashboard, and central API backend.

Repo structure:
apps/api
apps/mobile
apps/dashboard
apps/website
packages/ui
packages/types
packages/validators
packages/config
packages/api-client
docs

Tech direction:
API: NestJS, Fastify, Prisma, Postgres, Redis
Mobile: Expo Router, React Native, TypeScript
Dashboard: Next.js, TypeScript
Website: Next.js, TypeScript
Package manager: pnpm
Monorepo: turbo
Languages: English and Arabic
UI must support RTL.

Operating rules:
1. One focused task only.
2. Branch name must match the task.
3. Use conventional commits.
4. Do not delete code unless replacing it with a safer working version.
5. Never weaken auth, RBAC, validation, audit logs, rate limits, payment safety, or security.
6. Never commit secrets.
7. Do not touch unrelated files.
8. If you find conflicts or uncertainty, stop and report before making risky changes.
9. Follow existing repo patterns.
10. Keep mobile, dashboard, website, and API separated.
11. Business logic belongs in the API, not frontend screens.
12. Shared packages may contain only types, validators, config, API client, telemetry, money utilities, or design tokens.
13. All third party integrations must use provider interfaces and adapter classes.
14. Do not create fake production logic. Local demo mode is allowed only when isolated, clearly named, and impossible to enable in production by accident.
15. Every finished task must include summary, files changed, tests run, risks, rollback plan, and next recommended step.

Before editing files:
1. Run git status.
2. Inspect relevant folders.
3. Explain what you found.
4. Then implement only the requested task.

Finish format:
1. Summary
2. Files changed
3. Commands run
4. What works now
5. What is mocked or local only
6. What still needs real credentials or provider approval
7. Risks
8. Rollback plan
9. Next recommended prompt


Branch:
wave1/provider-integration-dashboard

Task:
Build dashboard screens for provider and third party API management.

Scope:
1. Add dashboard route:
   /integrations/providers
2. Add provider list.
3. Add provider detail.
4. Add create/edit provider form.
5. Add capability toggles:
   listing search
   availability
   booking creation
   payment collection
   refund
   webhook receive
   payout
   reviews
6. Add environment selector:
   sandbox
   live
7. Add vault secret reference fields, never secret value fields.
8. Add test connection button.
9. Add health status display.
10. Add audit history link if available.
11. Add empty, loading, error, and permission denied states.

Acceptance criteria:
1. Admin can manage provider configuration.
2. Secrets are never shown or stored.
3. UI clearly shows sandbox vs live.
4. Provider status is visible.
5. Unauthorized users cannot access.

Run:
pnpm typecheck
pnpm lint
pnpm test if available

Final report:
1. Files changed
2. Screens added
3. Screenshots if possible
4. Risks
5. Rollback plan
```

## Prompt P.4 Provider Adapter Interface Package

```text
You are operating on the Navi monorepo at:

/Users/start-tech/Documents/Claude/Projects/Navi

Navi is a UAE travel companion platform with a standalone iOS and Android mobile app, standalone public website, standalone admin and partner dashboard, and central API backend.

Repo structure:
apps/api
apps/mobile
apps/dashboard
apps/website
packages/ui
packages/types
packages/validators
packages/config
packages/api-client
docs

Tech direction:
API: NestJS, Fastify, Prisma, Postgres, Redis
Mobile: Expo Router, React Native, TypeScript
Dashboard: Next.js, TypeScript
Website: Next.js, TypeScript
Package manager: pnpm
Monorepo: turbo
Languages: English and Arabic
UI must support RTL.

Operating rules:
1. One focused task only.
2. Branch name must match the task.
3. Use conventional commits.
4. Do not delete code unless replacing it with a safer working version.
5. Never weaken auth, RBAC, validation, audit logs, rate limits, payment safety, or security.
6. Never commit secrets.
7. Do not touch unrelated files.
8. If you find conflicts or uncertainty, stop and report before making risky changes.
9. Follow existing repo patterns.
10. Keep mobile, dashboard, website, and API separated.
11. Business logic belongs in the API, not frontend screens.
12. Shared packages may contain only types, validators, config, API client, telemetry, money utilities, or design tokens.
13. All third party integrations must use provider interfaces and adapter classes.
14. Do not create fake production logic. Local demo mode is allowed only when isolated, clearly named, and impossible to enable in production by accident.
15. Every finished task must include summary, files changed, tests run, risks, rollback plan, and next recommended step.

Before editing files:
1. Run git status.
2. Inspect relevant folders.
3. Explain what you found.
4. Then implement only the requested task.

Finish format:
1. Summary
2. Files changed
3. Commands run
4. What works now
5. What is mocked or local only
6. What still needs real credentials or provider approval
7. Risks
8. Rollback plan
9. Next recommended prompt


Branch:
wave1/provider-adapter-interface

Task:
Create provider adapter interfaces for third party services.

Scope:
1. Create shared provider types in packages/types or packages/integrations if repo pattern allows.
2. Define interfaces:
   ListingSearchProvider
   AvailabilityProvider
   BookingProvider
   PaymentProvider
   RefundProvider
   ReviewProvider
   NotificationProvider
   TranslationProvider
   OcrProvider
   MapProvider
   SimProvider
   TaxiProvider
3. Add standard result type:
   success
   providerReference
   normalizedData
   rawReferenceId
   errorCode
   errorMessage
4. Add provider error categories:
   AUTH_FAILED
   RATE_LIMITED
   TIMEOUT
   BAD_RESPONSE
   VALIDATION_FAILED
   PROVIDER_DOWN
   UNSUPPORTED_CAPABILITY
5. Add tests for type exports if appropriate.
6. Do not implement vendor-specific adapters in this prompt.

Acceptance criteria:
1. Adapter contracts exist.
2. Types are shared safely.
3. Future providers can plug in without changing business logic.

Run:
pnpm typecheck
pnpm lint
pnpm test if available

Final report:
1. Files changed
2. Interfaces added
3. Usage example
4. Risks
5. Rollback plan
```

## Prompt P.5 Category Readiness Controls In Dashboard

```text
You are operating on the Navi monorepo at:

/Users/start-tech/Documents/Claude/Projects/Navi

Navi is a UAE travel companion platform with a standalone iOS and Android mobile app, standalone public website, standalone admin and partner dashboard, and central API backend.

Repo structure:
apps/api
apps/mobile
apps/dashboard
apps/website
packages/ui
packages/types
packages/validators
packages/config
packages/api-client
docs

Tech direction:
API: NestJS, Fastify, Prisma, Postgres, Redis
Mobile: Expo Router, React Native, TypeScript
Dashboard: Next.js, TypeScript
Website: Next.js, TypeScript
Package manager: pnpm
Monorepo: turbo
Languages: English and Arabic
UI must support RTL.

Operating rules:
1. One focused task only.
2. Branch name must match the task.
3. Use conventional commits.
4. Do not delete code unless replacing it with a safer working version.
5. Never weaken auth, RBAC, validation, audit logs, rate limits, payment safety, or security.
6. Never commit secrets.
7. Do not touch unrelated files.
8. If you find conflicts or uncertainty, stop and report before making risky changes.
9. Follow existing repo patterns.
10. Keep mobile, dashboard, website, and API separated.
11. Business logic belongs in the API, not frontend screens.
12. Shared packages may contain only types, validators, config, API client, telemetry, money utilities, or design tokens.
13. All third party integrations must use provider interfaces and adapter classes.
14. Do not create fake production logic. Local demo mode is allowed only when isolated, clearly named, and impossible to enable in production by accident.
15. Every finished task must include summary, files changed, tests run, risks, rollback plan, and next recommended step.

Before editing files:
1. Run git status.
2. Inspect relevant folders.
3. Explain what you found.
4. Then implement only the requested task.

Finish format:
1. Summary
2. Files changed
3. Commands run
4. What works now
5. What is mocked or local only
6. What still needs real credentials or provider approval
7. Risks
8. Rollback plan
9. Next recommended prompt


Branch:
wave1/category-readiness-controls

Task:
Allow admin dashboard to control category readiness and visibility.

Scope:
1. Add dashboard screen for service categories if missing.
2. Admin can set:
   visible in mobile
   visible in website
   booking enabled
   payment enabled
   inquiry only
   demo only
   provider required
   provider assigned
3. Add API endpoints if missing.
4. Add RBAC:
   category.read.all
   category.write.all
5. Add audit logs for every change.
6. Mobile and website should consume readiness state from API where already practical. If not practical, document integration ticket.

Acceptance criteria:
1. Admin can control category readiness.
2. Production cannot accidentally show demo checkout as live.
3. Audit logs exist.
4. UI explains readiness status clearly.

Run:
pnpm typecheck
pnpm lint
pnpm test affected

Final report:
1. Files changed
2. Controls added
3. Risks
4. Rollback plan
```