Running it locally

The current situation, stated plainly

There is no local database setup in this project yet.

supabase/config.toml exists but contains only a project identifier. It is the stub the Supabase CLI leaves behind after linking a project, not a working local configuration. Running supabase start against it will not give you a working environment.

This means that right now, running the application locally means pointing it at the live, production Supabase instance. Every contributor should understand what that implies:

• The data you see is real members' data.
• A profile you create or delete while testing is created or deleted for everyone.
• An announcement you publish appears on the live site immediately.

This is workable for one or two people who know the system well. It does not scale to a team, and closing this gap is the highest-priority piece of contributor tooling on the list. Until it is closed, treat local development as production access and behave accordingly.

Working safely against the shared instance

Until a local database exists, these rules keep testing from damaging real data.

Create your own account and your own profile. Sign up through the normal flow, the same way a member would. Test with that profile rather than editing someone else's.

Never test destructive actions on other people's rows. Deleting a profile, rejecting a profile, or removing an announcement affects the real directory. If you need to verify deletion works, delete something you created.

Do not test role changes casually. Changing a role writes an audit row and can remove someone's access. The function that changes roles refuses to leave the system with zero owners, but it will happily demote a working administrator.

Announcements are immediately public. There is no draft state. If you publish a test announcement, delete it as soon as you are finished, and expect that someone may have seen it.

What a proper local setup will look like

When this is built, the shape will be:

1. The Supabase CLI runs PostgreSQL, the auth service, and storage locally in Docker.
2. Every migration in supabase/migrations/ is applied to that local database, in order, giving an exact structural copy of production.
3. A seed script inserts obviously fake profiles and announcements, so the directory has content to work against without containing anyone real.
4. Your .env points at the local instance, whose keys are generated locally and are worthless anywhere else.

The important property is that a new contributor can be productive on day one without ever holding a production credential. If you are picking up this work, that is the goal to design against.

Connecting to the production database directly

Occasionally something genuinely requires querying production: confirming the shape of real data before writing a migration, or investigating a report that cannot be reproduced.

Access is through Supabase Studio, or through psql inside the database container over SSH. Both are restricted to the project owners, and that restriction is deliberate.

If you need something from production, ask an owner to run the query rather than asking for access. Read-only questions are usually answered in minutes, and this keeps the number of people holding production credentials as small as possible.