# Wave 2 Hardening Prompts

Goal: quality, security, compliance, accessibility, observability, and investor readiness.

## Prompt 2.0 Wave 2 Readiness 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 readiness for Wave 2 hardening.

Do not edit files.

Check:
1. Are Wave 1 reports complete?
2. Are payment flows stable?
3. Is partner onboarding stable?
4. Is AI trip planner stable?
5. Are tests available?
6. Is OpenAPI generated?
7. Is CI stable?
8. Are security scans present?
9. Are accessibility issues known?
10. Is mobile release config ready?
11. Are provider integrations isolated behind adapters?
12. Are demo and live modes impossible to confuse?

Output:
1. Wave 2 blockers
2. Hardening priority order
3. What should not be done yet
4. Recommended first Wave 2 prompt
```

## Prompt 2.1 Playwright 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:
wave2/playwright-foundation

Task:
Add Playwright foundation for website and dashboard.

Scope:
1. Create tests/e2e/web if missing.
2. Add tests for:
   website home loads
   English route loads
   Arabic route loads
   dashboard login page loads
   partner apply page loads
   provider integration registry page loads if it exists
3. Use seeded/mock environment only.
4. Do not create huge full flows yet.
5. Add docs/qa/e2e-playwright.md.

Acceptance criteria:
1. Playwright test project exists.
2. Basic smoke tests run.
3. CI can run Playwright or docs explain missing setup.

Run:
pnpm test:e2e if created
pnpm typecheck
pnpm lint

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

## Prompt 2.2 Maestro Mobile Smoke Tests

```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:
wave2/maestro-mobile-smoke

Task:
Add Maestro smoke test foundation for mobile.

Scope:
1. Add tests/e2e/mobile if missing.
2. Add flows:
   cold start
   onboarding
   guest discover
   saved screen
   emergency screen
   profile screen
3. Do not require real payment in this prompt.
4. Add docs/qa/mobile-maestro.md.

Acceptance criteria:
1. Mobile smoke flow files exist.
2. Instructions to run on iOS and Android exist.
3. Flow does not depend on production credentials.

Final report:
1. Files changed
2. Flows added
3. How to run
4. Risks
5. Rollback plan
```

## Prompt 2.3 Security Scan 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:
wave2/security-scans

Task:
Add supply-chain and security scan foundation.

Scope:
1. Add CodeQL workflow for TypeScript.
2. Add dependency scanning using GitHub security or Snyk if configured.
3. Add Trivy scan for API Docker image if Dockerfile exists.
4. Ensure gitleaks runs in CI.
5. Add docs/security/threat-model.md starter using STRIDE.
6. Do not block all merges on new tools until baseline is understood; document enforcement plan.

Acceptance criteria:
1. Security scans are configured.
2. Threat model starter exists.
3. Baseline findings are documented.

Final report:
1. Files changed
2. Scans added
3. Manual setup needed
4. Risks
5. Rollback plan
```

## Prompt 2.4 UAE PDPL And DSR 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:
wave2/pdpl-dsr-foundation

Task:
Create UAE PDPL and DSR foundation.

Scope:
1. Add docs/compliance/retention-policy.md.
2. Add docs/compliance/dpia-navi.md starter.
3. Add docs/compliance/sub-processors.md.
4. Add user data export endpoint design, then implement only if user data model is clear.
5. Add user delete request endpoint design, then implement only if soft delete is already stable.
6. Do not claim legal compliance is complete. Mark as product and engineering readiness draft for legal review.

Acceptance criteria:
1. Compliance docs exist.
2. Data categories are mapped.
3. DSR implementation status is clear.
4. Legal review needed is documented.

Final report:
1. Files changed
2. Endpoints added if any
3. Legal review items
4. Risks
5. Rollback plan
```

## Prompt 2.5 Accessibility And RTL 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:
wave2/accessibility-rtl-audit

Task:
Audit and fix critical accessibility and RTL issues.

Scope:
1. Check website, dashboard, and mobile UI patterns.
2. Add docs/design-system/accessibility-checklist.md.
3. Add docs/design-system/rtl-guidelines.md if missing.
4. Fix obvious critical issues:
   missing labels
   low contrast
   non logical left/right spacing where easy
   missing button labels
5. Do not redesign the whole app.

Acceptance criteria:
1. Checklist exists.
2. RTL guidelines exist.
3. Critical simple fixes are applied.
4. Remaining issues are listed.

Final report:
1. Files changed
2. Issues fixed
3. Issues remaining
4. Test results
5. Rollback plan
```

## Prompt 2.6 SLO And Observability Docs

```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:
wave2/slo-observability-docs

Task:
Define operational SLOs and observability plan.

Scope:
1. Create docs/operations/slos.md.
2. Define API availability target.
3. Define payment success target.
4. Define trip planner success target.
5. Define provider API health target.
6. Define mobile crash-free target.
7. Define alerting and dashboard needs.
8. Do not add paid observability tools unless already configured.

Acceptance criteria:
1. SLO doc exists.
2. Metrics are named.
3. Alert thresholds are proposed.
4. Provider health checks are included.

Final report:
1. Files changed
2. SLOs proposed
3. Manual setup needed
4. Risks
5. Rollback plan
```

## Prompt 2.7 Wave 2 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:
wave2/wave2-close-report

Task:
Create Wave 2 hardening report.

Do not change application code.

Create:
docs/release/wave2-hardening.md

Include:
1. Tests added
2. Security hardening
3. Compliance readiness
4. Accessibility status
5. Mobile resilience status
6. Observability status
7. Remaining investor/partner risks
8. Go or no-go for pilot launch
```