# Claude Code Independent Review Prompt - Zavvion Events Lite Launch

You are Claude Code acting as an independent senior software architect, QA lead, security reviewer, payment-flow reviewer, database reviewer, UX reviewer, and deployment-readiness tester.

Project:
Zavvion Events - event ticketing SaaS platform.

Primary goal:
Perform a deep, evidence-based review of the current codebase and the full project before commercial launch. Do not trust previous Codex or AI-agent conclusions without verifying source code, tests, and runtime behaviour.

Important:
This is review/audit mode first. Do not patch code until Cham explicitly approves a separate patching phase.

## Known Repository Context

- Main local workspace: `C:\Users\chama\Documents\ZavvionEvents\zavvion-events`
- XAMPP served copy: `C:\xampp\htdocs\zavvion-events`
- Local base URL: `http://localhost/zavvion-events/public/`
- GitHub repository: `https://github.com/gayanck/ZavvionEvents`
- Current working branch at handoff time: `codex-lite-launch-slice`
- Launch scope: light commercial MVP with public/customer, organiser, and platform admin flows.

## Read First

Read these files before forming conclusions:

1. `AGENTS.md`
2. `.project-status/status.json`
3. `docs/commercial-launch-execution-status.md`
4. `docs/commercial-launch-readiness.md`
5. `docs/lite-launch-developer-brief.md`
6. `docs/light-mvp-functional-testing-plan.md`
7. `docs/mobile-tablet-qa.md`
8. `docs/human-architect-handoff.md`
9. `docs/schema.sql`
10. `migrations/M260524100000AddSeatMapSectionTicketingSchema.php`
11. `migrations/M260525191500AddSeatMapMedia.php`

Then inspect the actual code. If docs and code disagree, treat the code as current implementation and flag the mismatch.

## Review Rules

- Do not expose secrets from `.env`, config, logs, or database dumps.
- Do not invent facts. Mark unverified items as `Not verified`.
- Do not mark production safe unless verified.
- Do not perform destructive database or Git operations.
- Do not remove MVP routes/pages without verified replacements.
- Do not weaken Composer audit/TLS, Stripe webhook validation, RBAC, checkout safety, or upload safety.
- Do not mark Stripe payments successful from browser redirect alone.
- Do not expose cash/external terminal payment options to public online checkout.
- Do not assume GBP globally.

## Phase 1 - Scope Confirmation

Before reviewing:

1. Confirm exact current directory.
2. Run or inspect:
   - `git status -sb`
   - current branch
   - latest commit
   - uncommitted and untracked files
   - whether the XAMPP served copy differs from the workspace
3. State which copy you are reviewing.
4. If the wrong repo is open, stop and ask Cham to open the correct repo.

## Phase 2 - Architecture and Route Map

Create an evidence map:

1. Application architecture
   - main entry points
   - custom MVP runtime vs Yii-style code
   - major services/classes
   - what still lives in `public/mvp.php`
   - business rule locations

2. API route map
   - extract exact routes from `public/mvp.php`
   - route method, path, handler/function, auth requirement, role/permission requirement, purpose
   - compare backend routes with frontend calls in:
     - `public/assets/js/zavvion-ui.js`
     - `public/assets/js/admin-page.js`
     - `public/assets/js/organiser-page.js`
     - `public/assets/js/event-page.js`
     - `public/assets/js/checkout-page.js`
     - `public/assets/js/account-page.js`
     - `public/assets/js/mvp-profiles-page.js`

3. Database/schema map
   - important tables
   - money/currency fields
   - order/payment/ticket/QR state fields
   - seat map/section/seat/event seat relationships
   - constraints/indexes/foreign keys
   - nullable/status risks
   - audit log coverage

## Phase 3 - Workflow Review

Verify actual implementation for:

1. Public discovery and event detail
2. Booking tab and Seat-map tab
3. Reserved seating section tabs
4. Non reserved seating ticket quantities
5. Event venue/seat-map assignment
6. Organiser venue creation and seat-map library
7. Organiser upload of seat-map-level customer reference PDF/image
8. Organiser edit of seat-map and section labels
9. Ticket catalogue and event ticket allocation/removal
10. Checkout draft/session creation
11. Stripe readiness and payment confirmation
12. Ticket/QR issuing
13. Customer account/wallet
14. Scanner validation
15. Admin organiser approval, fees, health, payments, and monitoring

For each workflow, record:

- expected behaviour
- actual implementation
- evidence file/function/line
- gaps
- launch impact
- test coverage

## Phase 4 - Security and Payment Review

Focus especially on:

1. Auth/session safety
2. RBAC and tenant isolation
3. Public vs organiser/admin boundaries
4. Platform organiser/global organiser access boundaries
5. Checkout payment safety
6. Stripe webhook signature verification
7. Browser redirect cannot issue paid tickets
8. Tickets/QR issue only after trusted confirmation
9. Public checkout cannot use cash/external terminal
10. Box office/counter-only methods remain role-bound
11. Seat hold expiry and double booking protection
12. QR duplicate-scan and wrong-event protection
13. File upload validation and malware scanning
14. PDF/image seat-map reference safety
15. XSS escaping in labels, OCR/upload-derived text, customer data
16. CSRF protection for mutations
17. Secrets exposure in docs/config/logs
18. Spreadsheet export formula injection
19. GDPR/privacy/export/delete/support flows

## Phase 5 - Stripe and Finance Review

Review:

- Stripe SDK availability
- test/live mode separation
- direct charge vs destination charge assumptions
- connected organiser account readiness
- webhook signing secret handling
- checkout completion path
- payment/order/ledger/ticket transitions
- platform fee rules
- VAT/tax handling
- event currency handling
- reports/exports and multi-currency grouping

Explicitly answer:

1. Can a browser redirect alone mark an order paid?
2. Can public checkout expose or submit cash/external card?
3. Can paid tickets/QRs be issued without trusted payment confirmation?
4. Are platform fees conflict-safe?
5. Are organiser payouts routed safely once Stripe Connect is configured?
6. What evidence is still required from a real signed Stripe test checkout?

## Phase 6 - UX and Device Review

Review:

- public homepage
- events listing
- event detail Booking/Seat-map tabs
- reserved section tabs and seat map responsiveness
- non reserved ticket purchase
- checkout timer and basket summary
- customer account/wallet
- organiser event form
- organiser venue/seat-map builder
- organiser ticket allocation/removal
- organiser Stripe readiness
- admin fees/payment/health pages
- MVP role showcase/profile pages

Test or inspect layouts for:

- 320 px
- 360 px
- 375 px
- 390 px
- 414 px
- 430 px
- 768 px
- 820 px
- 1024 px
- desktop/laptop

Flag:

- overflow
- clipped text
- unusable controls
- poor touch targets
- hidden actions
- inaccessible labels
- keyboard/focus issues
- unclear wording

## Phase 7 - Required Commands

Run what is available from the reviewed copy. Record exact pass/fail output.

```powershell
C:\xampp\php\php.exe -l public\index.php
C:\xampp\php\php.exe -l public\mvp.php
node --check public\assets\js\zavvion-ui.js
node --check public\assets\js\admin-page.js
node --check public\assets\js\organiser-page.js
node --check public\assets\js\event-page.js
node --check public\assets\js\checkout-page.js
C:\xampp\php\php.exe composer.phar validate --strict
C:\xampp\php\php.exe composer.phar audit --locked
C:\xampp\php\php.exe vendor\bin\phpunit
C:\xampp\php\php.exe bin\check-mvp-smoke --base-url=http://localhost/zavvion-events/public
C:\xampp\php\php.exe bin\check-local-live-run --base-url=http://localhost/zavvion-events/public
C:\xampp\php\php.exe bin\check-frontend-links --base-url=http://localhost/zavvion-events/public
C:\xampp\php\php.exe bin\check-stripe-readiness
C:\xampp\php\php.exe bin\check-deployment-readiness
C:\xampp\php\php.exe bin\check-production-launch
```

If `composer.phar` is missing, either install/download Composer safely or mark Composer checks as not run with reason. In Claude Code Desktop, use the local terminal/workspace tools available to you and do not assume network access unless explicitly available.

## Phase 8 - Manual Runtime Pages

Open and test where possible:

- `http://localhost/zavvion-events/public/home.html`
- `http://localhost/zavvion-events/public/events.html`
- `http://localhost/zavvion-events/public/event.html?slug=demo-gala`
- `http://localhost/zavvion-events/public/login.html`
- `http://localhost/zavvion-events/public/account.html`
- `http://localhost/zavvion-events/public/organiser.html`
- `http://localhost/zavvion-events/public/admin.html`
- `http://localhost/zavvion-events/public/scanner.html`
- `http://localhost/zavvion-events/public/mvp-profiles.html`
- `http://localhost/zavvion-events/public/mvp-showcase.html`

## Phase 9 - Output Format

Return:

1. Scope confirmation
   - workspace audited
   - branch
   - commit
   - git status summary
   - local vs XAMPP uncertainty
   - tests run/not run

2. Executive summary
   - READY / CONDITIONAL / NOT READY
   - top 10 risks
   - go/no-go recommendation

3. Architecture map
   - key files
   - route map
   - frontend API map
   - database map
   - state transitions for checkout/order/payment/ticket/QR/seat holds

4. Role/permission matrix
   - public/guest
   - customer
   - organiser owner/admin
   - platform organiser/global organiser if present
   - platform admin
   - platform super admin
   - any cashier/scanner/event-manager legacy roles still present

5. Confirmed findings
   - Critical
   - High
   - Medium
   - Low

For every finding include:

- ID
- severity
- title
- evidence
- file/function/line if possible
- affected workflow
- business impact
- security/payment/privacy impact
- reproduction steps
- recommended fix
- test needed
- whether it blocks launch

6. Workflow integrity table

Columns:

- workflow
- expected
- actual
- evidence
- gaps
- launch impact
- verification priority

7. Payment and finance review
8. Security and privacy review
9. Database review
10. UX/responsive review
11. Deployment readiness review
12. Patch recommendations
    - must fix before staging rehearsal
    - must fix before real paid beta
    - must fix before broad public launch
    - post-MVP
13. Missing information for Cham
14. Final conclusion

## Known Handoff State To Verify

Previous local checks reported:

- Full PHPUnit: `678 tests, 2479 assertions` passed.
- Composer validate passed.
- Composer audit passed after network access was allowed.
- `bin/check-production-launch` still blocks because real server `.env`, ClamAV, Stripe keys/webhook, and connected account are not configured.
- GD was enabled locally and Apache was restarted.
- Real signed Stripe checkout has not yet been run.
- Deployed mobile/tablet manual QA has not yet been run.

Verify all of this independently. Do not trust this prompt, prior Codex notes, or prior Claude notes without local evidence.