Who Is Cancelling Our Trip?

APP NAME
Who Is Cancelling Our Trip?

APP IDEA
A comedy web toy that treats bailing on a group trip 36 hours before departure as an international travel crime. The group sends it to the friend who just texted "something came up"; the recipient enters a departures hall run by the International Authority of Bad Friends, identifies themselves among six high-risk passengers, faces their own enthusiastic planning history as evidence, tries to press a CANCEL THE TRIP button that keeps changing gates, and is finally issued a Trip Abandonment Invoice for their Airbnb share and the labor of cropping them out of 214 group photos.

CORE EXPERIENCE
The app opens directly inside an airport departures hall. A split-flap departure board clatters out "DEPARTURE IN 36 HOURS — ONE PASSENGER IS ABOUT TO CANCEL." Below the board, six passenger files are laid out as boarding passes, each with a procedurally drawn avatar and a risk profile. A suitcase mascot wearing sunglasses waits by the gate. The user can immediately tap the boarding pass that is clearly theirs.

INTERACTION AND STATE
The app is a single linear comedy flow with these phases, tracked by an explicit state machine:

1. IDENTIFY — the opening screen described above. Tapping one of the six profiles selects it, marks it "CONFIRMED", and advances to the evidence phase. This is the only action required to start.
2. EVIDENCE — the 5 personalized evidence lines below are revealed one at a time inside the themed evidence presentation. Each tap on the clearly visible "NEXT" control reveals the next line with its themed animation. After the last line, the app advances to the confirmation phase.
3. THE QUESTION — a serious confirmation screen asks: "Cancel the trip. 36 hours before departure. Really?" It shows exactly two choices: a stable, always-clickable free option labeled "FINE, I'LL START PACKING", and the provocative escaping button labeled "CANCEL THE TRIP". The free option never moves, is never obscured, and works at any moment from this phase onward.
4. ESCAPE — every attempt to tap "CANCEL THE TRIP" makes it dodge within the safe viewport, and each failed attempt shows the next escalating reaction from the list below (one per attempt, in order, looping if needed). The button slows down noticeably from attempt 5 and MUST be reliably clickable no later than attempt 8. Catching it advances to the invoice phase.
5. INVOICE — the second reveal: the itemized "TRIP ABANDONMENT INVOICE" prints line by line with a running total, ending at exactly $413.33, followed by a large PAY button and the parody disclaimer.
6. FAKE PAYMENT — tapping PAY opens the fictional provider sheet for "LayoverPay™" with the parody disclaimer visible, plays a fake loading state of about 2 seconds, then always fails with exactly this punchline: "PAYMENT FAILED — Your card also decided not to show up." A CONTINUE control then leads to the free ending. The payment sheet never contains any input field of any kind.
7. FREE ENDING AND RESULT — Free ending: the always-available "FINE, I'LL START PACKING" flips the departure board to BOARDING and prints the INVOLUNTARY BOARDING PASS (passenger: chosen profile name, class: GUILT CLASS, seat: MIDDLE, status: ATTENDING (UNDER PROTEST)). The fake payment failure also routes here.
8. RESULT SCREEN — shows the result summary and the 9:16 shareable result card described in OUTCOME, with Share, Replay and a download-card control visible before any optional detail. Replay fully resets state and returns to IDENTIFY. Refreshing the page at any point restarts cleanly at IDENTIFY with no broken or stuck state.

Choosing the free option "FINE, I'LL START PACKING" at any time from phase 3 onward skips directly to the free ending — it must never be blocked, hidden, moved or delayed.

VISUAL AND CONTENT DIRECTION
A named visual world: "The International Authority of Bad Friends" — an airport departures authority for flaky people. Palette: departures-hall navy #101820 background, split-flap amber #FFC72C for board text, boarding-pass off-white #F5F1E6 for documents, stamp red #D64545 for penalties and seals; cool white signage text. Typography roles: a condensed all-caps style for the split-flap board and signage, a ticket-style mono for boarding-pass fields and the invoice. Recurring object: a rolling suitcase mascot wearing sunglasses, drawn procedurally, who inches toward the gate every time the user fails to cancel. Theme components: passenger files as boarding passes with barcodes and luggage tags, evidence lines that clatter onto the split-flap board letter by letter, passport-stamp feedback on every action, and the invoice as a TRIP ABANDONMENT INVOICE printed on a long boarding-pass-style receipt. Motion: split-flap flip animations for every reveal, the escape button relocating with a "GATE CHANGED" flip, luggage tags swinging, a final boarding-pass print-out sliding up for the result. Airport chimes are suggested visually (a small speaker icon pulse) rather than required audio.

OUTCOME
After the fake payment fails, the user reaches the free resolution: the always-available "FINE, I'LL START PACKING" prints an INVOLUNTARY BOARDING PASS — passenger name from the chosen profile, class "GUILT CLASS", seat "MIDDLE", status "ATTENDING (UNDER PROTEST)". This boarding pass is the 9:16 result card, downloadable as an image. Replay restarts from the passenger files.

ONE-SENTENCE INSTRUCTION
Pick your passenger file, face the evidence, then try to catch the CANCEL button.

TASK-SPECIFIC REQUIREMENTS
PER-APP CONTENT (use this exact English copy; provide natural Simplified Chinese translations for the zh locale, keeping fictional brand names like "LayoverPay™" and dollar amounts unchanged):

Six profiles (name — subtitle):
1. The Expired Passport — Found out at check-in. Last time too.
2. The $14 Balance — Booked nothing. 'Will pay you back.'
3. The PTO Gambler — Never actually requested the days off.
4. The Permission Seeker — 'Waiting for partner approval' since March.
5. The Itinerary Tyrant — Planned 7 restaurants. Owns no luggage.
6. The Last-Minute Texter — 'Sooo excited!!' 24 hours before bailing.

Evidence lines, in order:
1. You voted for this Airbnb. Enthusiastically. With three exclamation marks.
2. You bought matching sunglasses for the group. They already shipped.
3. You spent 7 hours planning restaurants. Seven.
4. Yesterday, 8:42 PM: 'I literally can't wait.'
5. Today: 'hey so… something came up.'

Escalating failed-attempt reactions, in order:
1. GATE CHANGED. The button is now boarding elsewhere.
2. Your excuse has been downgraded to standby.
3. The group chat read your message. Nobody replied.
4. The matching sunglasses have arrived. All six pairs.
5. The button took the window seat. You got the middle.
6. FINAL CALL for CANCEL. The button is not at the gate.
7. The button has been rebooked. You have not.

TRIP ABANDONMENT INVOICE line items (item — amount; amounts are fictional and must render exactly as written):
- Your Airbnb share (non-refundable, obviously) — $187.33
- Airport transfer, booked for six — $14.50
- Restaurant research labor, 7 hours × $10.00 — $70.00
- Removing you from 214 group photos, 214 × $0.25 — $53.50
- Group chat emotional damages — $88.00
TOTAL: $413.33

Fictional payment provider: LayoverPay™
Payment failure punchline (English version, verbatim): PAYMENT FAILED — Your card also decided not to show up.

SHARE CARD: The 9:16 result card is the INVOLUNTARY BOARDING PASS itself: split-flap header, passenger name, GUILT CLASS, seat MIDDLE, status ATTENDING (UNDER PROTEST), barcode, the abandonment total $413.33, and the app name. Downloadable as an image.

ESCAPING BUTTON CONTRACT (the button is a joke, not a trap):
- It always stays fully inside the visible safe viewport and never covers the free option, the header or any critical text.
- It dodges on tap/pointer-down, slows down from attempt 5, and is reliably clickable by attempt 8 at the latest.
- When prefers-reduced-motion is enabled, it does not move at all; instead it requires a single press-and-hold of about 1.5 seconds with a visible progress ring as the accessible alternative.
- It is keyboard-focusable with a visible focus style, and activating it via keyboard counts as a caught press after 3 keyboard attempts.
- All touch targets in the app are at least 44x44 CSS pixels. The user can always exit, replay, or choose the free outcome.

FICTIONAL PAYMENT SAFETY (this is a parody app, not a payment app):
- Never process, request or imply real payment. Never show any input field for card, banking, contact or identity data anywhere in the app.
- Do not use, import or imitate any real payment provider or SDK, and do not integrate the platform payment system: the checkout is a purely visual joke that always fails.
- Show a clear parody disclaimer next to every payment action: EN "Parody — no real charge. Nothing is ever billed." / zh "纯属玩笑 — 不会产生任何真实扣款。"
- The fictional invoice must never be presented as an enforceable debt; the free route to the ending is always available.

PRIVACY AND SAFETY:
- All names, avatars, timestamps, statistics and evidence are fictional and hard-coded; the app never reads real messages, contacts, accounts or any personal data.
- The app never sends, posts or messages anyone automatically. Any generated message text is copy-to-clipboard only.
- All six avatars and the mascot are drawn procedurally in code (SVG or canvas). No photographic assets, no external images, no real people.

TESTABILITY (stable hooks for automated QA; add these data-testid attributes on the corresponding elements):
- "suspect-0" through "suspect-5" on the six profile cards, in display order.
- "evidence-next" on the evidence NEXT control.
- "escape-button" on the escaping button; "free-exit" on the stable free option.
- "invoice-pay" on the invoice PAY button; "payment-continue" on the control that leaves the failed payment for the free ending.
- "result-share" on the Share control; "result-replay" on Replay; "download-card" on the card download control; "lang-toggle" on the language toggle.

TECHNICAL CONSTRAINTS:
- Fully self-contained frontend experience: no external APIs, no AI calls, no third-party data/media/font services, no backend requirements, no account. All content is embedded in the app.
- All artwork is procedural (SVG/canvas/CSS): no image files, no photos, no emoji-only art for the mascot.
- The 9:16 result card is rendered in-app and downloadable as an image via a canvas export.
- Local state only; sessionStorage/localStorage may be used but a hard refresh must always land in a clean, working IDENTIFY phase.
- Respect prefers-reduced-motion for all decorative animation, not just the escaping button.

IMPLEMENTATION INSTRUCTIONS

Treat this specification as the final implementation brief and build the complete app now.

Open directly into the live app experience. Do not add a splash screen, opening cover, welcome page or separate onboarding flow.

Include exactly one concise sentence that explains how to play or use the app. Use the sentence provided under ONE-SENTENCE INSTRUCTION. Show it inside the live app interface, not on a separate opening screen.

Internationalization is required. Implement a lightweight built-in i18n layer supporting exactly two locales: English (en) and Simplified Chinese (zh). The app must always open in English and must never auto-detect or follow the browser, device or system language. Provide one clear EN / 中文 language toggle. Every user-facing string, including the one-sentence instruction and all loading, empty, success, error and result states, must have complete English and Chinese versions. Switching languages must update the entire interface without mixed-language text or untranslated fallback strings.

Let Eazo adapt the app to its actual host and available viewport. Do not hard-code or target a particular browser size, device size, viewport width or height, App frame size, root-height formula, or host-container CSS implementation. In the live preview, keep the current primary action easy to discover and usable without requiring an initial downward scroll; avoid horizontal overflow and avoid decorative layers blocking required controls. Optional detail may scroll. Keep active media and secondary copy compact enough that the next action remains visible. In result states, show the summary plus Replay and Share before optional detail. Do not eagerly render a large collection of full-size result images in one long page; use a compact summary, carousel, pagination, expansion, or virtualization. Use accessible touch targets.

Respect the host safe areas for iPhone notches, Dynamic Island, the status bar and the bottom home indicator in the initial implementation, before the first preview. Keep the header, language toggle, primary controls and result actions entirely inside the usable safe area. In the standard Eazo mobile host, use `padding-top: max(56px, env(safe-area-inset-top, 0px))` and `padding-bottom: max(34px, env(safe-area-inset-bottom, 0px))`, or Eazo's current official safe-area equivalent. These are safe-area insets only, not fixed viewport or App-frame dimensions; continue to let Eazo adapt the overall width and height. Make sure flex children can shrink inside the remaining usable area and that required controls are not covered or pushed off screen.

Use Eazo's built-in defaults and official platform capabilities. Do not add unrelated features or expand the scope beyond this specification.

When implementation is complete, provide a working preview for QA.