Major updates, authentication, multi-users

README.md

@@ -4,19 +4,28 @@ FlockPal is a Dockerized TypeScript app for tracking flock health with a clean,
 
 ## Current scope
 
+- Passwordless authentication only
+- Magic-link email sign-in
+- OAuth-ready login flow for Google, Microsoft, and Apple
+- Multi-workspace model with `standard` household and `rescue` modes
+- Shared workspace member management for both households and rescues
+- Separate per-workspace billing plan foundation with `rescue_free`, `household_basic`, and `household_plus`
 - Bird profiles with name, tag ID, and species
+- Bird DOB and gotcha day fields
 - Daily weight recordings
 - 30-day weight graph
+- Vet visit history with notes
 - Postgres-backed storage
 - React frontend and Express backend
 - Security-minded defaults like Helmet, CORS allow-listing, rate limiting, and input validation
 
 ## Planned next steps
 
-- Vet visit history
 - Medication and care reminders
-- Accounts, authorization, and role-based rescue access
-- Billing and plan management for paid organizations with a free rescue tier
+- Invitation acceptance and onboarding polish for workspace members
+- Stripe or equivalent billing integration for paid household tiers
+- Scheduled reminder delivery for birthdays, gotcha days, and care events
+- Audit logging for workspace access changes and bird transfers
 
 ## Run locally
 
@@ -30,6 +39,43 @@ docker compose up --build
 3. Open `http://localhost:3000`.
 4. The API health check is available at `http://localhost:5000/api/health`.
 
+## Auth and workspace notes
+
+- One user can belong to multiple workspaces.
+- A rescue member can also keep their own household flock in a separate workspace.
+- Billing should attach to the household workspace, not the user account.
+- Rescue workspaces stay on the free plan.
+- Shared access is controlled by workspace roles like `owner`, `manager`, `staff`, and `viewer`.
+- FlockPal no longer stores local passwords.
+- Authentication now happens through magic links or external identity providers.
+
+## OAuth environment
+
+Set these in Docker or your `.env` file if you want provider login enabled:
+
+- `FRONTEND_URL`
+- `BACKEND_URL`
+- `GOOGLE_CLIENT_ID`
+- `GOOGLE_CLIENT_SECRET`
+- `MICROSOFT_CLIENT_ID`
+- `MICROSOFT_CLIENT_SECRET`
+- `APPLE_CLIENT_ID`
+- `APPLE_CLIENT_SECRET`
+
+## Magic-link email environment
+
+Set these if you want magic links delivered by email instead of logged as a preview URL during local development:
+
+- `SMTP_HOST`
+- `SMTP_PORT`
+- `SMTP_SECURE`
+- `SMTP_USER`
+- `SMTP_PASS`
+- `SMTP_FROM_EMAIL`
+- `SMTP_FROM_NAME`
+
 ## Notes for monetization and security
 
-This starter keeps the data model and deployment simple, but it is intentionally shaped so we can add authentication, organization scoping, audit trails, reminders, and Stripe-style billing later without redesigning the whole app.
+This starter now includes the account and workspace foundation for monetization, but it still needs production-grade session hardening, invitation verification, billing integration, audit logging, and background reminder delivery before launch.
+
+For account design, `standard` vs `rescue` is best treated as a workspace type, not as a user role. If paid plans are added later, a separate `admin account mode` is usually less flexible than workspace roles such as `owner`, `manager`, `staff`, and `viewer`. That lets the same underlying account system work for both households and rescues without splitting product logic into unrelated account classes.