Pro Placement — Player Hub

The private app where a signed player keeps everything about himself: his match footage, and (from stage 3) his passport, CV, finished highlight reel, measured numbers and documents.

It is not the public page and it is not the portal. Three surfaces, one job each:

Surface	What it is	Who sees it
This app — the Player Hub	what the player gives us	the player and admins, nobody else
proplacement.cloud/p/<slug> — the proof page	what clubs see	anyone with the link
proplacement.cloud/portal — the campaign portal	what is happening now: DMs to send, club replies, trials	the player

Give / show / do.

---

Layout

firestore.rules          THE SECURITY OF THE APP. Read this before changing anything.
firebase.json            So `firebase deploy --only firestore:rules` works if the CLI is installed.
MIGRATION.md             The console steps to switch sign-in on and close the database.
rules-tests/             93 tests that PROVE firestore.rules does what it says. `npm test`.
AUDIT_2026-09-08.md      Where this all came from: what was broken and what is planned.
frontend/
  dev.mjs                Starts Vite with the right working directory (the path has spaces).
  src/
    services/firebase.js   The Firebase handles + the on-device cache that makes it work offline.
    services/auth.js       WHO the user is. Passwords never come near our database.
    services/db.js         The player's RECORD. Found by authUid, never by email.
    context/AuthContext     The signed-in user, from Firebase on every load.
    context/PlayerContext   The record, kept live with onSnapshot, saved one section at a time.
    hooks/useOnlineStatus   Whether to tell him he is offline. Never used to decide what to save.
    utils/catalog.js        Positions, skill categories, photo types. ONE source of truth.
    utils/completion.js     ONE completion formula + the single "do this next" instruction.
    utils/activity.js       When he last added something, and when he last just looked.
    utils/export.js         The link sheet for the editor, and his raw data.
    utils/links.js          Link tidying and the mistakes we can actually catch.
    pages/                  Login, SignUp, ForgotPassword, Dashboard, Account, Admin*
    utils/hubCatalog.js     Every question the hub asks: countries, consents, platforms, slots.
    utils/hubCompletion.js  What "done" means for the five sections about the player.
    utils/nested.js         Reading and writing `identity.passportOne.country` safely.
    services/files.js       The four uploads. Shrunk on the phone, stored in Firestore.
    components/dashboard/   The five footage sections + next-step card, phone nav, shell, row
    components/hub/         The five sections about the player + the coach's readiness panel
    components/ui/          Buttons, inputs, cards, modal, brand marks

Running it

cd frontend
npm install
npm run dev

Then http://localhost:5173. (npm run dev and node dev.mjs do the same thing; the second one works from any directory.)

Build: npm run build. Lint: npm run lint. Deploying the frontend is a push to main — Vercel builds frontend/.

Rules are not deployed by a push. They live in the Firebase console. See MIGRATION.md.

The plan this runs on

Firebase Spark, the free one. Nothing in this app needs billing and nothing should be added that does. That rules out Firebase Storage, Cloud Functions and scheduled jobs. If a feature seems to need one of them, look for the version that does not before you look at the invoice.

Testing the rules

cd rules-tests
npm install
npm test

Starts the Firestore emulator (needs Java), runs firestore.rules against 93 cases and exits non-zero if any of them lets something through. Run this before changing the rules and after. The rules are the only thing standing between a signed-in player and everyone else's data; a comment saying they work is not evidence.

The two rules that matter when you change anything

1. The security is firestore.rules, not the React code. Any check written only in the browser is a suggestion. If a player must not be able to do something, the rules must be what stops him. Before this was true, the whole database was readable by anyone on the internet.
2. Videos are links, documents are uploads. Full games, clips and photos stay as Google Drive or YouTube links — they are gigabytes, and the editor needs to open them in Drive anyway. Passports, CVs and headshots are real uploads into Firebase Storage, because an identity document must never be a public URL.

Three things that look odd until you know why

• updatedAt and profile.lastSeenAt are separate. The first means he added something, the second that he opened the app. "He looks every day and adds nothing" and "he has vanished" are different problems and the admin list distinguishes them. Opening the app must never count as progress.
• profile.lastSeenAt lives inside profile. It would read better as a top-level field, but the rules only let a player write the named sections — a new top-level key would be refused. Nested keeps it legal without redeploying rules.
• Files live in Firestore, not Firebase Storage, and that is on purpose. Storage needs the paid plan, which this project does not have. It is also the weaker option: a Storage download link carries its own access token and keeps working for anyone who ever sees it. A Firestore document has no link, so the rules are consulted on every read of a passport. Photos are shrunk on the phone to fit the 1 MiB document ceiling; a PDF that will not fit asks for a link instead.
• A file is stored under a fixed slot, never a name the player chose. Exactly four: passportOne, passportTwo, cv, headshot, in playerFiles/<uid>__<slot>, one document each so the coach's list never drags a passport photo along with a row of names.
• authEmail is not the same field as profile.email, and the difference matters. The player writes profile.email; authEmail can only be written to the address Firebase says he is signed in as and has confirmed. Anything that decides who gets access to what — carrying an old record across, above all — must use authEmail. Matching on the one he can type is how one player ends up with another player's footage.
• Changing an email uses verifyBeforeUpdateEmail, not updateEmail. The confirmation goes to the new address, so a typo cannot lock a player out of his own account. It is also the only variant that still works with email-enumeration protection switched on.

What the player actually sees

Two tabs. My footage is the five sections of links he sends us. About me is the five about him: who he is, his numbers, how we reach him, his finished work, and where he is already online. Ten sections in one scroll is a wall, and a wall is where a sixteen year old on a phone gives up.

Every word he reads is written short and plain, on purpose. Assume it is being read on a phone, at night, by someone tired. No em dashes anywhere in rendered text.

Who is an admin

Whoever has a document at admins/{their Firebase Auth uid}. That collection is writable by nobody — only the Firebase console can create one. There is no admin password and no admin login screen: an admin signs in like everyone else and the app notices.