Repository navigation
Staff guide
"Staff" on the Hub does not mean "people with an admin panel". There isn't one. This guide is for the people who keep the platform honest — verifying accounts, reviewing appeals, running provisioning, answering "why can't this person do X" — using the tools that actually exist: the staff API endpoints, terminal scripts, and the database itself.
Staff capability comes from authority_records like everyone else's — a platform-scoped mandate, a team participation, a body seat. There is no isAdmin flag that unlocks the world. The /api/member/team/* and /api/member/admin/* endpoints check capabilities the same way member endpoints do; see Organisation and permissions for the model. When staff access stops working, the cause is almost always a record that ended or was never granted — not a bug in the gate.
Verifying and managing accounts. POST /api/member/team/membership/accounts/:id/verify confirms a registration; /status and /terminate handle the harder cases. Appeals land under /member/team/membership/appeals/:id with /review and /proof for the evidence trail.
Records. A member's authority records are visible at /api/member/admin/accounts/:id. Ending one is POST /api/member/team/membership/accounts/:id/records/:rid/end. Granting happens through provisioning scripts or the service layer — never a raw insert.
Review queues. Partnerships (/member/team/partnerships), recognition nominations, conflicts of interest, safeguarding cases and privacy requests each have a review endpoint with the same shape: list → inspect → /review or /respond with a decision. The audit trail records every transition with who made it.
Notifications. The API endpoints /api/member/admin/notifications/send, /preview and /outbox dispatch a manual notice, render a template, and show what is queued and delivered.
The heavyweight work — seeding, migrations, backfills, one-off fixes — runs through the Payload local API in tsx scripts. The pattern is:
# Always against the database you intend — check twice
DATABASE_URL="postgres://localhost:5433/youngo_dev" \
npx tsx scripts/seed.tsScripts in scripts/ are the maintained entry points; scripts/setup/generate-vapid-keys.mjs provisions web-push keys for a new environment. For anything bespoke, write a throwaway tsx script that calls getPayload() — you get the full typed local API with access control intact, which is strictly safer than hand-editing SQL for anything but inspection.
/api/member/admin/audit is the system-wide transition log: who changed what, when, through which path. When a member disputes a moderation decision or a record ends unexpectedly, the audit trail is the first stop — the answer is usually there before anyone needs to touch the database.
Operating without an admin panel only stays safe if staff respect the same boundaries the code does: use the endpoints and scripts, let the service layer lock and validate, and treat direct SQL as a read tool. The moment a write bypasses authorityService or an endpoint's checks, the audit trail goes silent exactly where it matters most.