feat: changes in database

AGENTS.md

@@ -14,9 +14,10 @@ Maintain a deliberately small, self-hosted rota application for a non-profit bar
 3. Saturday and Sunday rotations are independent, each with its own configuration page (`/admin/schedules/<id>`); the night schedule is fixed and repeats every month with a single configuration. `/admin/schedules` is the hub: it shows every schedule (kind, hours, next dates, rotation order or night pattern) and links to its configuration page. There is no public schedule page: `/`, the rota, is the only page open to signed-out visitors.
 4. Never silently rewrite an existing assignment when rotation membership/order changes.
 5. A swap/change request only applies if the requester still owns the assignment when it is accepted/approved.
-6. `email` and `phone` are optional. Signing in belongs to a `login_accounts` row (username, password, admin flag) that several people can share; a person with no login account is rota-only. A username is unique across accounts, not across people. The session stores the login account, and everything a member sees and controls is scoped to the people on it.
-7. Email failure must never roll back or block a rota change. Log failures in `notification_logs`.
-8. Past assignments cannot be offered for change through the member UI.
+6. A **team** (`teams`) is who works a shift; a **user** (`users`) is the login that signs in for it. Several teams can share one user, and a team without a user is rota-only. A username is unique across users. The session stores the user, and everything a member sees and controls is scoped to the teams assigned to it.
+7. `/admin/teams` only selects which user signs in for each team; `/admin/users` creates the users and assigns them to teams. Neither page creates the other's records.
+8. Email failure must never roll back or block a rota change. Log failures in `notification_logs`.
+9. Past assignments cannot be offered for change through the member UI.
 
 ## Stack
 
@@ -30,11 +31,11 @@ Maintain a deliberately small, self-hosted rota application for a non-profit bar
 
 ## Important files
 
-- `app/models.py` — database schema: people (`users`) and the login accounts they share (`login_accounts`).
+- `app/models.py` — database schema: the teams who work the rota (`teams`) and the users that sign in for them (`users`).
 - `app/scheduling.py` — recurrence and assignment generation. Treat changes here as high-risk.
 - `app/web.py` — HTTP routes and workflows.
 - `app/notifications.py` — SMTP delivery; should fail soft.
-- `app/bootstrap.py` — initial admin login account + person + three default schedules.
+- `app/bootstrap.py` — initial admin user + team + three default schedules.
 - `app/cli.py` — database/demo/reminder commands.
 - `docs/DOMAIN.md` — expected business behavior.
 
@@ -48,6 +49,7 @@ Maintain a deliberately small, self-hosted rota application for a non-profit bar
 - Do not commit `.env`, database files, credentials, or real member data.
 - Do not introduce a frontend package manager unless the UI requirements truly need it.
 - Schema changes go through Alembic. Edit `app/models.py`, then `make revision m="short description"`, review the generated file in `migrations/versions/`, and never rely on `create_all` (the app runs `alembic upgrade head` on start). `make check` fails if the migrations and the models drift apart.
+- The history is squashed into the single baseline revision `0001_initial`, so a new database is created in one step and an existing one is adopted with `alembic stamp head` instead of being upgraded. Add new revisions on top of the baseline; do not re-introduce per-change migrations for a test environment.
 
 ## Validation before handoff