# Refer2Earn: cPanel database migration foundation

## Current status

`schema.sql` creates a dedicated MySQL/MariaDB data model for accounts, referrers, candidate applications, referrals, milestone decisions, one-time account tokens, and audit events. It creates **no accounts or credentials**, and it does not connect the page to the database yet. The Refer2Earn page must remain fail-closed until the PHP API, real authentication, authorization, and production validation are implemented and tested.

## Important: Apps Script is still in use elsewhere

The existing Apps Script currently receives candidate applications, contact messages, and service inquiries. It also resolves the referral link token used by the Careers page. The Careers application is the source that must prove a candidate submitted a matching application; a separate Refer2Earn database cannot validate that until Careers application writes have been migrated or securely synchronized.

Do not remove or disable the Apps Script URLs yet. Doing so before replacing those endpoints would break submissions. The migration should move candidate application intake and server-side referral-token validation to PHP/MySQL first; contact and services forms can be migrated separately. Keep existing records available for a controlled, privacy-reviewed migration—do not copy them into a new database casually.

## cPanel tasks for the site owner

1. In cPanel, create a **new dedicated MySQL database** and a database user. Grant that user only the privileges the application needs; do not use the cPanel account's broad database credentials.
2. Confirm the hosting PHP version and that `PDO` plus `pdo_mysql` are enabled. Keep HTTPS enabled for the whole site.
3. Import `schema.sql` into the new database using cPanel's database import tool. This is only the table setup; it does not make the portal live.
4. Store database credentials and future encryption/HMAC keys in a PHP config file **outside `public_html`** (or an approved host secret store). Never put them in HTML, JavaScript, this repository, or chat. Do not expose `phpinfo()` or a public database test page.
5. Confirm with the host where private uploads can be stored outside `public_html`, how database backups are encrypted and restored, and which PHP error logs are available. Resumes and payout QR images must not be public URLs.
6. Keep demo data and real personal data separate. Do not import the page's sample candidates, payout details, or fake accounts as production records.

When the database is created, the only details needed to continue coding are the database type/version, whether PDO MySQL is available, and the server's safe config-file location—not the password or encryption key. Keep secrets on the server and configure them there.

## Backend work still required before launch

- Add PHP endpoints that use prepared PDO statements and server-side sessions; establish a one-time Admin provisioning process, referrer email verification, secure password hashing, session rotation, CSRF protection, rate limits, and recovery procedures.
- Enforce every role and record-ownership check on the server. Referrer queries must be scoped to the authenticated account, not a browser-supplied ID.
- Migrate the Careers application intake and referral-token lookup so the referral record is attached server-side to a verified application.
- Implement the workflow specification's duplicate/prior-application checks, former-employee review, candidate identity matching, three failed/declined incentives per referrer per Manila calendar month, rolling 180-day candidate outcome cap, payout approval rules, and immutable audit trail using database transactions.
- Encrypt payout details with a key stored outside the database and webroot. Restrict database-user privileges so audit events cannot be modified by the web application.
- Add protected resume/image upload handling, backup/restore tests, and operational monitoring. Test with synthetic data before any real applicants use it.

The current SQL is the foundation for that work, not a production-ready backend or a substitute for reviewing the deployed host's security and retention controls.
