Boundaries

Club owns the fan-facing business — chat, PPV, broadcasts, the vault, revenue, payouts. It deliberately does not own everything around that business. This page is the map of what's next door.

Not Club	Lives in	Why it's not here
Domain/link registration, click-tracking	Link	The `Domain` and `Click` tables, and the public `/api/go` redirect that writes them, live entirely outside Club's product tree.
Streaming, scenes, overlays	Stream	No streaming code exists anywhere in Club's own tree.
Login, sessions, team-RBAC, platform connections	Account Platform	Auth, team-access grants, and the OnlyFans/Fansly connection flow all live in the shared `app/core`/`app/api` layer, not inside Club.
Support tickets, changelog, status page	Account Platform	The whole support surface — `core/support` — belongs there, even the part physically sitting inside Club's folder today.
Account/billing notifications	Account Platform	See below — this is a real split, not a blanket exclusion.

Domains, links, and clicks

A smart link resolves to a domain_source and lives on a Domain row — but Club doesn't own that row, and it doesn't own the click that got recorded on the way in. Domain is defined in app/core/models/config_domain.py, and every click is written by the public redirect (app/api/go.py) through a background flusher into the Click table (app/core/models/traffic_segments.py) — none of it inside Club's product tree. Club reads clicks for attribution (see Connections), but the domain and the click are Link's.

Streaming

Club has no code touching streaming, scenes, or overlays anywhere in its tree. That surface — cockpit, cam-site adapters, chat overlay — is a separate product.

Account, team access, and platform connections

Who can log in, what a team member's grant lets them see, and how an OnlyFans or Fansly account gets connected in the first place are all handled outside Club:

Auth and sessions — app/core/auth.py, app/api/auth.py.
Team-access grants (tabs, functions, money masking) — app/core/team_access.py. Club's own endpoints consume the grant (e.g. require_admin, team_source_scope in traffer_payouts.py), but the grant itself is defined and enforced elsewhere.
OnlyFans/Fansly account connection — the attach/reconnect flow (app/core/onlyfans/attached_reconnect_*.py, app/core/browser/) is entirely outside Club.

Support

Support — tickets, the public changelog, the status page, feedback, and idea moderation — is Account Platform's in full, including core/support itself, which today happens to sit physically inside Club's folder (app/products/club/core/support). Folder location isn't the signal here: don't document it as a Club feature.

Comms and email — a real split, not a blanket exclusion

Club's core/comms and core/email modules exist, but what's actually in them today is a platform-notification system, not fan correspondence: the event taxonomy (core/comms/events.py) is account registration, password resets, billing, an OnlyFans/Fansly connection status, incident/status updates, support-ticket replies, referral conversions — every one of them addressed to the workspace owner, delivered by email or Telegram through a shared Outbox dispatcher. None of it is a message to a fan. Fan correspondence is Club's inbox (core/inbox), a completely separate system covered in Connections and the Concepts section — not core/comms.

OnlyFans wall posting is Club's, not excluded

An earlier pass over this codebase left wall-posting undecided. It isn't: scheduling and dispatching OnlyFans posts (app/products/club/api/admin/posting.py, core/posting/) is Club's own feature — see Overview.

What's next

Connections — the specific places Club's code actually reaches across these boundaries today, cited to the file.