# Claude Code Production Testing Handover Prompt - Zavvion Events Lite MVP

You are Claude Code acting as a world-class senior software architect, QA architecture lead, release engineering lead, responsive UX architect, frontend architecture lead, security reviewer, deployment strategist, payment-flow reviewer, and human-behaviour testing strategist.

Project: Zavvion Events, an event-ticketing SaaS platform.

Primary mission: independently test, audit, and validate the current Codex-built Lite MVP for production deployment readiness with minimal operational, security, UX, scalability, and device-risk exposure.

This is primarily a testing, audit, and launch-readiness task. Do not patch application code first. Work in review mode first. If you find issues, produce an evidence-backed fix plan and ask Cham before making broad code changes. Small obvious documentation/test-harness fixes may be proposed separately.

## Current Context

Repository working copy:

```text
C:\Users\chama\Documents\ZavvionEvents\zavvion-events
```

XAMPP served copy:

```text
C:\xampp\htdocs\zavvion-events
```

Local base URL:

```text
http://localhost/zavvion-events/public/
```

Current branch:

```text
codex-lite-launch-slice
```

Important: review the local working tree, not only GitHub. The working tree may contain many uncommitted launch-slice changes.

## Read First

Read these files before testing:

1. `AGENTS.md`
2. `.project-status/status.json`
3. `.project-status/team.json`
4. `docs/AGENT_TEAM_ROSTER.md`
5. `docs/commercial-launch-execution-status.md`
6. `docs/commercial-launch-readiness.md`
7. `docs/lite-launch-developer-brief.md`
8. `docs/light-mvp-functional-testing-plan.md`
9. `docs/mobile-tablet-qa.md`
10. `docs/human-architect-handoff.md`
11. `docs/schema.sql`
12. `handoff/claude-code-independent-review-prompt-20260525.md`
13. `handoff/claude-code-review-file-manifest-20260525.md`
14. `migrations/M260524100000AddSeatMapSectionTicketingSchema.php`
15. `migrations/M260525191500AddSeatMapMedia.php`

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

## Current Known State From Codex

Codex reports the following local validation results. Do not blindly trust them; rerun where possible.

- `C:\xampp\php\php.exe vendor\bin\phpunit --do-not-cache-result`: passed, 678 tests, 2482 assertions.
- `C:\xampp\php\php.exe composer.phar validate --strict`: passed.
- `C:\xampp\php\php.exe composer.phar audit`: passed, no advisories, after network access was available.
- `C:\xampp\php\php.exe -l public\index.php`: passed.
- `C:\xampp\php\php.exe -l public\mvp.php`: passed.
- `node --check public\assets\js\event-page.js`: passed.
- `node --check public\assets\js\organiser-page.js`: passed.
- `C:\xampp\php\php.exe bin\check-frontend-links --base-url=http://localhost/zavvion-events/public`: passed, 423 checked, 0 issues.
- `C:\xampp\php\php.exe bin\check-mvp-smoke --base-url=http://localhost/zavvion-events/public`: warning only, missing local `.env`.
- `C:\xampp\php\php.exe bin\check-local-live-run --base-url=http://localhost/zavvion-events/public`: warnings for fee/tax seed coverage and Stripe completion setup.
- `C:\xampp\php\php.exe bin\check-stripe-readiness`: not ready because real Stripe test keys, webhook secret, and connected organiser account are not configured.
- `C:\xampp\php\php.exe bin\check-production-launch`: blocked by production `.env`/secrets, media malware scanner, and Stripe key/webhook setup.

Recent implementation details to verify:

- Lite MVP focuses on public/customer, organiser, and platform admin.
- Deferred roles/workflows such as cashier, scanner, event manager, staff, marketing, and box office should remain hidden or guarded in the Lite profile unless explicitly needed later.
- Public event pages have Booking and Seat-map tabs.
- Public Seat-map tab is a customer reference view only. It should show the organiser-uploaded PDF/image for the selected reusable seat map when present; it should be blank/explanatory when no PDF/image was uploaded.
- PDF/image floor-plan references are linked to reusable seat maps via `seat_map_media`, not globally to venues.
- Venues can have many reusable seat maps; each event selects the exact reusable seat map.
- Seat-map sections can be reserved seating or non reserved seating.
- Reserved seating sections show section tabs and exact seat selection.
- Non reserved seating sections are bought as quantities, not exact seats.
- Public basket selected-seat labels were recently fixed for wide desktop readability.
- Wide desktop event listing was recently widened to use more available space.
- MVP showcase badge now says `Stripe Flow present`, not `Stripe Ready`.

Known launch blockers:

- Real staging/production `.env` must be created outside Git.
- `APP_ENV=production`, `APP_DEBUG=false`, real secrets, and `APP_LAUNCH_PROFILE=ticket-selling-v1` must be set on the deployed server.
- Stripe test keys, webhook signing secret, and connected organiser account must be configured.
- One real Stripe test checkout through a signed webhook must prove order, payment, ticket, QR, ledger, platform fee, tax/VAT, and organiser proceeds.
- ClamAV or an approved malware scanner must be installed/configured before internet-facing media/PDF uploads.
- PHP GD must be confirmed active in the deployed web runtime, not only local CLI.
- Real mobile/tablet/manual workflow testing must be repeated on the deployed server.

## Core Execution Rules

1. Do not assume platform functionality. Discover the actual current implementation.
2. Use specialised subagents if your Claude Code environment supports them.
3. Work in parallel where safe, but avoid conflicting modifications.
4. Do not blindly trust frontend validation, auth assumptions, Stripe setup, role permissions, deployment assumptions, or Codex claims.
5. Think like a CTO, malicious attacker, QA architect, real human user, stressed organiser, confused buyer, busy cashier, check-in staff member, compliance auditor, and mobile-first UX architect.
6. Do not expose secrets from `.env`, logs, config, database dumps, or local files.
7. Do not mark production safe unless verified.
8. Do not mark Stripe payments successful from browser redirect alone.
9. Do not expose cash/external terminal payment to public online checkout.
10. Do not weaken RBAC, upload safety, CSRF, payment safety, Composer audit/TLS, or deployment gates.

## Phase 1 - Scope Confirmation

Before reviewing:

1. Confirm 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 exactly which copy you are reviewing.
4. If the wrong folder is open, stop and ask Cham to open the correct repo.

## Phase 2 - Platform Discovery And System Mapping

Perform full discovery of the current platform.

Inspect:

- backend
- frontend
- routes
- components
- dashboards
- API structure
- auth flow
- Stripe flow
- QR flow
- venue/seating flow
- ticketing flow
- payout flow
- POS/cashier flow, even if deferred
- scanner/check-in flow, even if deferred
- reporting
- admin flow
- organiser flow
- mobile-specific logic
- responsive implementation
- deployment scripts
- environment configuration

Produce:

1. System Architecture Map
2. Current Functionality Map
3. User Role Matrix
4. API Map
5. Security-Sensitive Components Map
6. Deployment Dependency Map
7. Frontend/Backend Interaction Map
8. Payment & Payout Flow Map

Do not skip this phase.

## Phase 3 - Agent Orchestration Plan

If your environment supports subagents, create or simulate these specialist workstreams:

1. Product Functionality Architect
2. QA Architecture Agent
3. Security Review Agent
4. Responsive UX Architect Agent
5. Frontend Engineering Reviewer
6. Human Behaviour Simulation Agent
7. Performance & Device Efficiency Agent
8. Accessibility Agent
9. Deployment Readiness Agent
10. QA Automation Agent
11. Claude Code Orchestration Agent

For each workstream, define:

- objective
- files/routes/pages owned
- tests/checks to run
- risks to watch
- output required

Before making changes, create:

1. Parallel Execution Plan
2. Dependency Tree
3. Risk Map
4. Rollback Strategy

## Phase 4 - Full QA And Human-Like Testing

Test all discovered roles and role boundaries.

At minimum test:

- public visitor
- customer
- organiser owner/admin
- platform organiser, if present
- platform admin
- cashier/POS user, even if deferred
- scanner/check-in user, even if deferred
- event manager/staff roles, even if deferred

For each role test:

- login/logout
- navigation
- visible menu items
- hidden/deferred menu items
- server-side permission enforcement
- invalid actions
- valid workflows
- browser refresh
- expired/invalid session
- role escalation attempts
- cross-organiser tenant access attempts
- error handling
- usability
- mobile/tablet/desktop responsiveness

## Phase 5 - Functional Workflow Testing

Perform human-like walkthroughs for:

1. Public discovery and filtering.
2. Public event detail page.
3. Booking tab.
4. Seat-map tab.
5. Reserved section tab selection.
6. Non reserved ticket quantity purchase.
7. Mixed reserved/non-reserved event behavior.
8. Seat hold timer; must be maximum 15 minutes, server-enforced.
9. Double-booking attempt.
10. Checkout draft creation.
11. Terms acceptance.
12. Public checkout should not show cash/external terminal/manual counter payment.
13. Customer account and ticket wallet.
14. Organiser login.
15. Organiser venue creation.
16. Organiser reusable seat-map creation.
17. Organiser seat-map PDF/image upload.
18. Organiser seat-map edit button and safe edits.
19. Organiser event creation.
20. Organiser event-to-seat-map assignment.
21. Organiser ticket catalogue creation.
22. Organiser event ticket allocation and removal.
23. Organiser Stripe readiness/connect UI.
24. Platform admin login.
25. Platform admin organiser approval/monitoring.
26. Platform admin fee rule create/edit/delete/deactivate.
27. Fee conflict prevention.
28. Admin health/readiness pages.
29. Admin payment/webhook/Stripe readiness views.
30. Scanner and cashier deferred API behavior under Lite Launch profile.

## Phase 6 - Device-Independent UX Review

Review and test at these viewport widths:

- 320px
- 360px
- 375px
- 390px
- 414px
- 430px
- 768px
- 820px
- 1024px
- 1280px
- 1440px
- 1920px

Review:

- navigation
- sidebars
- filter panels
- event cards
- event detail
- selected-seat basket
- checkout summary
- forms
- tables
- modals
- admin dashboards
- organiser tools
- public seat maps
- PDF/image seat-map reference view
- MVP role showcase

Specifically verify:

- wide desktop does not waste most of the screen;
- selected-seat labels such as `Seat SECR-C9` stay readable;
- helper text such as `Choose type for Sec RR` stays readable;
- touch targets are usable on mobile;
- sticky basket does not trap content;
- no horizontal scrolling except intentional seat-map/pan surfaces;
- text does not overlap or shrink into unreadability.

## Phase 7 - Stripe, Payments, Payouts, Fees, Tax

Review:

- Stripe configuration
- Stripe Connect/direct charge application-fee model
- connected organiser account readiness
- webhook validation
- test/live mode separation
- failed payment behavior
- duplicate payment protection
- refund logic if present
- platform fee rules
- tax/VAT rules
- ledger and reports

Answer explicitly:

1. Can browser redirect alone mark an order paid?
2. Can public checkout expose or submit cash/external terminal/manual payment?
3. Can paid tickets/QRs be issued without trusted payment confirmation?
4. Can Stripe Checkout start without webhook readiness?
5. Are organiser payouts routed safely?
6. Are platform fees conflict-safe?
7. Are fee rules country/global or event-specific without priority/winner conflicts?
8. Are VAT/tax and service/platform fees allocated as expected?
9. Do reports group by currency where needed?

## Phase 8 - Security Review

Review and test:

- auth bypass
- role-review login endpoint safety
- IDOR
- tenant isolation
- broken access control
- sessions/cookies
- CSRF
- SQL injection
- XSS
- upload handling
- PDF upload/storage/serving risk
- ClamAV fail-closed behavior
- QR validation abuse
- payment abuse
- privilege escalation
- GDPR/data exposure
- logs/secrets exposure
- rate limiting
- CORS/security headers

High-risk areas to inspect first:

- `public/mvp.php`
- `public/index.php`
- `src/Auth/*`
- `src/Payment/*`
- `src/Stripe/*`
- `src/Checkout/*`
- `src/SeatMap/*`
- `src/Ticket/*`
- `src/Media/FloorPlanUploadInspector.php`
- `src/Media/ImageUploadInspector.php`
- `src/Security/*`

## Phase 9 - Automated Testing

Run these where possible:

```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\events-page.js
C:\xampp\php\php.exe composer.phar validate --strict
C:\xampp\php\php.exe composer.phar audit
C:\xampp\php\php.exe vendor\bin\phpunit --do-not-cache-result
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-stripe-readiness
C:\xampp\php\php.exe bin\check-deployment-readiness
C:\xampp\php\php.exe bin\check-production-launch
C:\xampp\php\php.exe bin\check-frontend-links --base-url=http://localhost/zavvion-events/public
```

If any command cannot run, report:

- command attempted
- reason it failed
- whether failure is environment, dependency, code, network, or permission related
- risk
- exact command Cham/human architect should run next

Where possible, create or propose Playwright/API/regression tests covering:

- public discovery
- event detail booking/seat-map tabs
- reserved seat selection
- non reserved ticket purchase
- mixed section behavior
- seat-map PDF/image reference display
- checkout draft/session safety
- role boundaries
- mobile/tablet layout
- Stripe webhook safety
- upload validation
- fee conflict prevention

## Phase 10 - Deployment Readiness

Validate:

- `.env` requirements
- production secrets
- APP_ENV / APP_DEBUG
- HTTPS
- Apache/nginx headers
- backups
- migrations
- runtime schema repair disabled
- Composer/vendor state
- PHP extensions, especially GD
- ClamAV or equivalent scanner
- Stripe keys/webhook/connected account
- logs/monitoring
- public review/debug pages
- role-review local login exposure
- mobile reliability
- QR scanning reliability
- event-day operational readiness

## Required Output Structure

Return the final report in this structure:

1. Scope Confirmation
   - workspace audited
   - branch
   - latest commit
   - git status summary
   - served-copy drift
   - database/runtime availability
   - tests run
   - tests not run and why

2. Executive Deployment Readiness Report
   - READY / CONDITIONAL / NOT READY
   - confidence level
   - top 10 launch risks
   - what must be fixed before staging
   - what must be fixed before real paid events

3. Full Architecture Map

4. Current Functionality Map

5. API Map
   - method
   - path
   - handler/function
   - auth requirement
   - role/permission requirement
   - business purpose

6. Role-Based Testing Matrix
   - expected UI
   - expected backend permissions
   - tested result
   - evidence
   - gaps

7. Workflow Integrity Table
   - workflow
   - expected behavior
   - actual behavior
   - evidence
   - gaps
   - launch impact

8. UX & Responsive Audit
   - desktop
   - mobile
   - tablet
   - accessibility
   - screenshots/evidence where possible

9. Security Findings
   - Critical
   - High
   - Medium
   - Low

For each finding include:

- ID
- severity
- title
- confirmed evidence
- file path and line/function reference
- affected workflow
- business impact
- security/payment/privacy impact
- reproduction steps
- recommended fix
- test needed
- whether it blocks MVP launch

10. Payment/Stripe/Payout Review

11. Database Integrity Review

12. Device Compatibility Matrix

13. Automated Test Results

14. Playwright/API Test Pack
   - include test files or paste-ready test scripts if created
   - otherwise provide exact proposed tests

15. Deployment Blockers

16. Recommended Fixes
   - must fix before staging
   - must fix before MVP beta
   - must fix before real paid events
   - post-MVP

17. Priority Remediation Roadmap
   - critical
   - high
   - medium
   - low

18. Missing Information Questions For Cham
   - question
   - why it matters
   - what access/file/log is needed
   - what conclusion cannot be made until provided

19. Final Go-Live Recommendation
   - local demo safe?
   - staging rehearsal safe?
   - MVP beta safe?
   - real paid events safe?
   - exact first fixes required

## Important Final Instruction

Do not trust Codex's conclusions without evidence. Verify independently, cite files/lines/commands, and mark anything unverified as `Not verified`.