0cf87b72ab
- authentication-methods: document completeAuth mode param ("redirect"|"json");
clarify add-passkey nudge (no dismiss mechanism, disappears on passkey add)
- journal-auth: session maxAge is 30 days; terms allow-list uses /legal/ prefix
matching (broader than fixed list of paths)
- session-notes: mark awareness isolation and UndoManager isolation as not yet
implemented (shared instances in current code)
- activity-feed: add fan-out scenario for visibility change to public
- explore: note that ?perPage is not yet implemented (hardcoded page size)
- multi-day-routes: add per-day GPX track split scenario (splitByDays option);
document overnight vs isDayBreak naming gap
- osm-poi-overlays: debounce is 800ms + 2000ms min interval (not 500ms);
retry is not automatic (fires on next viewport change)
- brouter-integration: rate limit corrected to 300/hour; add segment-cache
requirement (client caches per-pair segments)
- wahoo-route-push: OAuth state shape uses camelCase (returnTo, pushAfter
object) not snake_case with push_after boolean
- komoot-import: document noop adapter / ConnectedServiceManager bypass;
note four Komoot-specific routes that bypass the generic OAuth framework
- background-jobs: exponential backoff not wired (retryLimit only); add SIGINT
- connected-services: add revoked status; name ConnectionNotActiveError
- infrastructure: add INTEGRATION_SECRET and SENTRY_DSN to env var lists;
split secret decryption scenario by workflow (cd-apps vs cd-infra)
- secret-management: correct CD decryption — cd-apps only decrypts app.env;
cd-infra decrypts both
- transactional-emails: welcome email is async (pg-boss job); magic-link email
includes 6-digit numeric code
- journal-route-detail: websites are https: links (not mailto:); opening_hours
is also displayed
- local-dev-environment: add mobile app (Expo) dev commands
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
48 lines
2.3 KiB
Markdown
48 lines
2.3 KiB
Markdown
## Purpose
|
|
|
|
Transactional email sending with HTML and plain-text templates for magic links and welcome messages, using SMTP in production and console logging in dev.
|
|
|
|
## Requirements
|
|
|
|
### Requirement: Email sending interface
|
|
The system SHALL provide a provider-agnostic email sending function that supports HTML and plain-text content.
|
|
|
|
#### Scenario: Send email in production
|
|
- **WHEN** the system sends a transactional email in production
|
|
- **THEN** the email is delivered via Nodemailer with SMTP (configured via `SMTP_URL` connection string and `SMTP_FROM` env var) to the recipient
|
|
|
|
#### Scenario: Dev mode skips sending
|
|
- **WHEN** the system sends a transactional email in development
|
|
- **THEN** the email content is logged to console and no external API is called
|
|
|
|
### Requirement: Magic link email
|
|
The system SHALL send an email containing the magic link when a user requests passwordless login.
|
|
|
|
#### Scenario: Magic link delivered
|
|
- **WHEN** a user requests a magic link login
|
|
- **THEN** an email is sent with a clickable link that logs them in
|
|
|
|
#### Scenario: Email content
|
|
- **WHEN** a magic link email is sent
|
|
- **THEN** it includes: the clickable link, a prominently displayed 6-digit numeric code (for users who prefer copy-paste over clicking), expiry time (15 minutes), and a plain-text fallback
|
|
|
|
### Requirement: Welcome email
|
|
The system SHALL send a welcome email after successful registration. The welcome email is sent asynchronously via a pg-boss `send-welcome-email` job rather than inline during the registration request.
|
|
|
|
#### Scenario: Welcome on registration
|
|
- **WHEN** a user completes registration (passkey or magic-link)
|
|
- **THEN** a `send-welcome-email` job is enqueued and the email is delivered asynchronously to their registered email address
|
|
|
|
### Requirement: Email templates
|
|
Each email type SHALL have an HTML template with a plain-text fallback.
|
|
|
|
#### Scenario: Extensible template pattern
|
|
- **WHEN** a new email type is needed in the future
|
|
- **THEN** it can be added by creating a template function and calling sendEmail
|
|
|
|
### Requirement: Privacy disclosure
|
|
Email sending SHALL be documented in the privacy manifest.
|
|
|
|
#### Scenario: Privacy manifest updated
|
|
- **WHEN** transactional emails are enabled
|
|
- **THEN** the /privacy page documents: what emails are sent, that email addresses are shared with the email provider, and which provider is used
|