# Wave 1B Commercial MVP Prompts

Goal: make one real commercial path work end to end, then expand safely.

## Prompt 1.8 Money 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/money-package

Task:
Create shared money utilities.

Scope:
1. Create packages/money.
2. Represent money using integer minor units.
3. AED = fils.
4. USD = cents.
5. Add helpers:
   parseMoney
   formatMoney
   addMoney
   subtractMoney
   multiplyMoney
   assertSameCurrency
6. Add tests for rounding and currency mismatch.
7. Do not refactor all app money usage yet. Only create the safe package.

Acceptance criteria:
1. Money arithmetic avoids floating point errors.
2. Tests cover AED and USD.
3. Package exports typed utilities.

Run:
pnpm typecheck
pnpm lint
pnpm test

Final report:
1. Files changed
2. Package usage example
3. Tests run
4. Risks
5. Rollback plan
```

## Prompt 1.9 Payment 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/payment-architecture-audit

Task:
Audit the current payment, booking, order, refund, commission, and payout structure before coding payment provider changes.

Do not implement payment code yet.

Check:
1. Payment models
2. Booking models
3. Order models
4. Refund models
5. Commission models
6. Payout models
7. Idempotency middleware
8. Webhook verifier
9. Audit log usage
10. Money arithmetic usage
11. Dashboard payment views
12. Mobile checkout screens
13. Provider interface readiness
14. Demo code risk

Output:
1. Current payment readiness
2. Missing models
3. Missing provider interfaces
4. Security risks
5. Where fake/demo logic exists
6. Required order of implementation
7. Exact next prompt

Do not change files.
```

## Prompt 1.10 Stripe Payment Intent 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/stripe-payment-intents

Task:
Implement Stripe payment intent foundation.

Scope:
1. Inspect existing PaymentProvider interface.
2. Add StripePaymentProvider.
3. Add POST /v1/payments/intent.
4. Require Idempotency-Key.
5. Never accept card number, CVV, or PAN on Navi servers.
6. Use hosted/payment-sheet compatible flow.
7. Persist PaymentIntent record.
8. Add audit log.
9. Add tests with mocked Stripe client.
10. Do not add Telr yet.

Acceptance criteria:
1. Payment intent can be created.
2. Idempotency key is required.
3. PaymentIntent is persisted.
4. AuditLog is written.
5. Tests pass.

Run:
pnpm typecheck
pnpm lint
pnpm test api

Final report:
1. Files changed
2. Endpoint added
3. Env variables needed
4. Tests run
5. Security notes
6. Rollback plan
```

## Prompt 1.11 Stripe Webhook Processing

```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/stripe-webhooks

Task:
Implement Stripe webhook handling through the queue.

Scope:
1. Verify HMAC/webhook verification pattern.
2. Add Stripe webhook route.
3. Verify signature synchronously.
4. Enqueue event to webhooks.inbound.
5. Worker processes:
   payment_intent.succeeded
   payment_intent.payment_failed
   charge.refunded
6. Update PaymentIntent and Booking status.
7. Write AuditLog.
8. Ensure idempotency on duplicate webhook events.
9. Add tests.

Acceptance criteria:
1. Webhook signature verified.
2. Duplicate webhooks do not double-update.
3. Booking status updates correctly.
4. AuditLog written.
5. Tests pass.

Run:
pnpm typecheck
pnpm lint
pnpm test api

Final report:
1. Files changed
2. Events supported
3. Tests run
4. Security risks
5. Rollback plan
```

## Prompt 1.12 Refunds 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/refunds-foundation

Task:
Implement refunds foundation.

Scope:
1. Add Refund model if missing.
2. Add refund state machine:
   REQUESTED
   APPROVED
   PROCESSED
   COMPLETED
   FAILED
3. Add endpoints:
   POST /v1/refunds
   GET /v1/refunds/:id
   PATCH /v1/refunds/:id/status
4. Add RBAC:
   booking:refund:assigned
   booking:refund:all
5. Prevent duplicate refunds per booking.
6. Write AuditLog on every transition.
7. Do not integrate full PSP refund processing unless safe. Stub provider call behind interface if needed.
8. Add tests.

Acceptance criteria:
1. Refund state machine works.
2. Duplicate refunds blocked.
3. Audit logs exist.
4. RBAC enforced.

Run:
pnpm typecheck
pnpm lint
pnpm test api

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

## Prompt 1.13 Commission And Payout 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/commission-payout-foundation

Task:
Build the real commission and payout foundation behind provider bookings.

Scope:
1. Inspect existing Business, Booking, PaymentIntent, Order, Refund, and payout models.
2. Add CommissionRule if missing.
3. Add CommissionLedger or PartnerLedger if missing.
4. Add PayoutBatch model if missing.
5. Commission calculation must use packages/money.
6. Commission rule types:
   percentage
   fixed fee
   hybrid percentage plus fixed
   category-specific
   partner-specific override
7. Add endpoints for admin to view commission calculations.
8. Add dashboard read-only commission and payout view.
9. Do not send real payout money in this task.
10. Write AuditLog for commission rule changes.
11. Add tests for commission math.

Acceptance criteria:
1. Commission can be calculated consistently.
2. Refund impact on commission is represented.
3. Payouts can be prepared as batches but not sent.
4. Audit logs exist.
5. Tests cover edge cases.

Run:
pnpm typecheck
pnpm lint
pnpm test

Final report:
1. Files changed
2. Schema changes
3. Commission rules added
4. Tests run
5. Risks
6. Rollback plan
```

## Prompt 1.14 Basic AI Trip Planner Provider

```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/ai-trip-planner-provider

Task:
Implement basic AI trip planner provider safely.

Scope:
1. Inspect existing trip planner module.
2. Add AiProvider interface if missing.
3. Add Claude provider behind environment flag.
4. Do not hardcode a model unless env-configurable.
5. Use structured JSON schema output only.
6. Add deterministic fallback planner.
7. Add UsageQuota model if missing.
8. Track token/cost estimate if available.
9. Redact PII before sending prompt.
10. Run through ai.trip queue if queue exists.
11. Add tests for fallback, quota exceeded, and provider timeout.

Acceptance criteria:
1. Trip planner can generate structured plan.
2. Fallback works.
3. Quota guard exists.
4. PII redaction exists.
5. AuditLog records generation attempt.

Run:
pnpm typecheck
pnpm lint
pnpm test api

Final report:
1. Files changed
2. Provider added
3. Env variables needed
4. Tests run
5. AI safety notes
6. Rollback plan
```

## Prompt 1.15 Mobile Checkout For One Category

```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/mobile-activity-checkout

Task:
Implement mobile checkout for one launch category only: ACTIVITY.

Scope:
1. Use existing mobile booking flow patterns.
2. Add checkout flow for ACTIVITY listings.
3. Generate client-side Idempotency-Key per checkout attempt.
4. Call API payment intent endpoint.
5. Add payment status screens:
   pending
   success
   failed
6. Add booking confirmation screen.
7. Add loading, error, retry, and cancel states.
8. Do not implement all ListingKind in this prompt.
9. Keep strategy pattern extensible for future kinds.

Acceptance criteria:
1. Activity checkout flow works through API contract.
2. Idempotency key is persisted per attempt.
3. Failure is handled clearly.
4. UI supports EN/AR keys or is ready for i18n.
5. No card data touches Navi server.

Run:
pnpm typecheck
pnpm lint
mobile test if available

Final report:
1. Files changed
2. Screens changed
3. API endpoints used
4. Test result
5. Screenshots if possible
6. Risks
7. Rollback plan
```

## Prompt 1.16 Wave 1 Close Report

```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/wave1-close-report

Task:
Create Wave 1 launch readiness report.

Do not change application code.

Create:
docs/release/wave1-launch-readiness.md

Include:
1. Features shipped
2. Commercial readiness
3. Payment readiness
4. Partner onboarding readiness
5. AI trip planner readiness
6. Mobile readiness
7. Website readiness
8. Dashboard readiness
9. Known gaps
10. Security risks
11. QA risks
12. What must happen before public launch
13. Go or no-go recommendation

Final report:
1. File created
2. Recommendation
3. Next wave prompt
```