trails-cool/trails
1
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
trails/openspec/specs/transactional-emails/spec.md
Ullrich Schäfer 02939ca828
Update specs to match implementation 
Addresses spec drift items #3, 5, 6, 7, 8, 9, 10, 11, 12 from #147:

- transactional-emails: Resend → Nodemailer + SMTP
- infrastructure: CX21 → cx23
- secret-management: single secrets.env → split app/infra files
- brouter-integration: 5s failover delay → instant via clientID election
- brouter-integration: 2 profiles → 5 (trekking, fastbike, safety, shortest, car)
- observability: add version field to health response
- observability: add brouter_request_duration_seconds metric
- planner-session: remove 30-day max ceiling (not enforced)
- shared-packages: clarify map package scope vs planner-specific features

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-03 09:13:07 +01:00

1.9 KiB
Raw Blame History

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 link, expiry time (15 minutes), and plain-text fallback

Requirement: Welcome email

The system SHALL send a welcome email after successful registration.

Scenario: Welcome on registration

  • WHEN a user completes passkey registration
  • THEN a welcome email is sent 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