# Payments, Refunds, Customers, Reviews, Commissions, Reports Prompts

Goal: build the operational money and customer system like a real marketplace.

## Prompt M.1 Money Operations 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


Task:
Audit all money and operations flows before implementation.

Do not edit files.

Check:
1. Booking lifecycle
2. Order lifecycle
3. Payment lifecycle
4. Refund lifecycle
5. Commission lifecycle
6. Payout lifecycle
7. Review lifecycle
8. Customer profile and lookup
9. Customer movement or reassignment between bookings/providers
10. Dashboard reports
11. Provider reports
12. Finance reports
13. Audit logs
14. Data exports
15. Demo data risks

Output:
1. Current readiness
2. Missing models
3. Missing APIs
4. Missing dashboard screens
5. Missing reports
6. Risks
7. Exact implementation order
```

## Prompt M.2 Booking Lifecycle State Machine

```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/booking-lifecycle-state-machine

Task:
Create or normalize the booking lifecycle state machine.

Scope:
1. Inspect existing Booking and Order status enums.
2. Define lifecycle:
   DRAFT
   PENDING_PAYMENT
   PAYMENT_FAILED
   CONFIRMED
   PROVIDER_PENDING
   PROVIDER_CONFIRMED
   IN_PROGRESS
   COMPLETED
   CANCEL_REQUESTED
   CANCELLED
   REFUND_REQUESTED
   REFUNDED
   NO_SHOW
   FAILED
3. Add transition guard service.
4. Add AuditLog for every status change.
5. Add reason field where needed.
6. Add tests for allowed and blocked transitions.
7. Do not break existing screens. Add compatibility mapping if needed.

Acceptance criteria:
1. Booking statuses are consistent.
2. Invalid transitions are blocked.
3. Audit logs are written.
4. Tests pass.

Run:
pnpm typecheck
pnpm lint
pnpm test api

Final report:
1. Files changed
2. State machine added
3. Tests run
4. Risks
5. Rollback plan
```

## Prompt M.3 Customer 360 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/customer-360-dashboard

Task:
Build Customer 360 foundation in dashboard.

Scope:
1. Add dashboard route for customers.
2. Search customers by name, email, phone, booking reference.
3. Customer detail should show:
   profile
   bookings
   payments
   refunds
   saved items
   reviews
   support tickets if model exists
   audit trail link if allowed
4. Add RBAC:
   customer.read.assigned
   customer.read.all
5. Add loading, empty, error, and permission denied states.
6. Do not expose sensitive payment data.

Acceptance criteria:
1. Support/admin can find customers.
2. Customer history is visible based on permission.
3. Sensitive fields are redacted.
4. UI supports support workflow.

Run:
pnpm typecheck
pnpm lint
pnpm test affected

Final report:
1. Files changed
2. Screens added
3. Permissions used
4. Risks
5. Rollback plan
```

## Prompt M.4 Move Or Reassign Customer Booking

```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/booking-move-reassign

Task:
Add safe booking move or reassignment capability.

Scope:
1. Add API operation to move or reassign a booking only if business rules are clear.
2. Supported actions:
   reschedule booking date/time
   move booking to another provider listing if compatible
   reassign responsible support agent
   reassign provider staff if model exists
3. Require reason.
4. Require permission:
   booking.move.assigned
   booking.move.all
5. Validate compatibility before move.
6. Write AuditLog with before and after values.
7. Notify customer/provider if notification system exists. Otherwise create notification task record.
8. Add dashboard action with confirmation modal.
9. Add tests.

Acceptance criteria:
1. Unsafe moves are blocked.
2. Reason is required.
3. Audit logs exist.
4. Dashboard confirms before action.
5. Tests pass.

Run:
pnpm typecheck
pnpm lint
pnpm test affected

Final report:
1. Files changed
2. Endpoint added
3. Dashboard action added
4. Tests run
5. Risks
6. Rollback plan
```

## Prompt M.5 Reviews And Ratings Foundation

```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/reviews-ratings-foundation

Task:
Build review and rating foundation.

Scope:
1. Add Review model if missing.
2. Reviews attach to booking, listing, provider, and user.
3. Only completed bookings can be reviewed.
4. Add status:
   PENDING
   PUBLISHED
   HIDDEN
   FLAGGED
5. Add endpoints:
   POST /v1/reviews
   GET /v1/listings/:id/reviews
   GET /v1/admin/reviews
   PATCH /v1/admin/reviews/:id/status
6. Add RBAC for moderation.
7. Add AuditLog for moderation changes.
8. Add dashboard moderation screen.
9. Add tests.

Acceptance criteria:
1. Users can review completed bookings only.
2. Admin can moderate.
3. Listing rating can be calculated.
4. Audit logs exist.
5. Tests pass.

Run:
pnpm typecheck
pnpm lint
pnpm test affected

Final report:
1. Files changed
2. Endpoints added
3. Dashboard added
4. Tests run
5. Risks
6. Rollback plan
```

## Prompt M.6 Reports Foundation

```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/reports-foundation

Task:
Build first reporting foundation for CEO, admin, and partners.

Scope:
1. Add reporting service or module if missing.
2. Create dashboard reports:
   GMV
   bookings count
   conversion if telemetry exists
   refund amount
   commission amount
   partner payout amount
   top categories
   top providers
   failed payments
   pending refunds
3. Partner users can see only their own business data.
4. Super Admin can see all data.
5. Add export CSV endpoint if safe.
6. Add RBAC:
   report.read.own
   report.read.all
   report.export.own
   report.export.all
7. Add tests for scope isolation.

Acceptance criteria:
1. Reports show scoped data.
2. Super Admin sees all data.
3. Partner sees own business only.
4. Export respects scope.
5. Tests pass.

Run:
pnpm typecheck
pnpm lint
pnpm test affected

Final report:
1. Files changed
2. Reports added
3. Scope tests run
4. Risks
5. Rollback plan
```