peterpan.id — Audited Domain Plan

Current Reality

• The implementation evidence already exists in the main Peterpan fansite project at peterpanband.com/.
• That stack is hybrid:
  • Node/SQLite origin app
  • static export path
  • Cloudflare functions/worker path
• peterpan.id should be planned as an alias or alternate entry surface of the same product family, not as a separate infrastructure stack.

Recommended Role

• Use peterpan.id as:
  • a redirect to the canonical Peterpan site, or
  • a country-specific entrypoint backed by the same build and data plane.

Cloudflare Rules

• Reuse the same Pages, Worker, D1, and media setup as the primary Peterpan deployment.
• Keep fan/community data centralized.
• Avoid duplicate content across domains without a clear canonical strategy.

Definition of Done

• The domain has a clear redirect or market-entry role.
• It depends on the same Cloudflare-native stack as the main Peterpan site.
• There is no separate origin app for this alias.

⚙ HARD CONSTRAINTS (enforced for all sites)

This domain MUST operate within these constraints — no exceptions:

• 100% Cloudflare serverless — Workers + D1 + R2 + KV + Workers AI + Vectorize. NEVER PM2, NEVER VPS, NEVER Docker in production path.
• 100% AI-automated — every customer interaction, every moderation decision, every transaction reconcile = AI. No manual queue, no live human chat support, no physical fulfillment.
• 1-operator solo — one person can run the entire operation from a phone. No team meetings, no shared inbox, no shift rotation.
• WhatsApp AI bot for all support (24/7, instant response, no SLA promises that need humans).
• Mayar QRIS for all Indonesian payments (subscription auto-renew, no manual invoicing).
• Indonesian UI primary — bahasa-first, English fallback only where unavoidable.
• Privacy — opt-in only, delete-on-request honored within 24h (cron-driven).
• No physical goods, no inventory — digital products + affiliate referrals only.

If the plan above describes any flow that violates these constraints, treat the plan as ASPIRATIONAL only and rework before building. The constraint trifecta wins.