Qualify the trial app reminder loop before a demo

[raghubetina]

Parent: Ben/Jelani feedback decision tracker #43. Research recommendations remain pending unless a prior decision is explicitly identified.

Qualify the actual development reminder loop before demonstrating it

Research packet — 2026-09-19. Original finding 48. Keep this separate from the next general trial's already-approved demo-login scope. No real message was sent, application was started, shared database was touched, or external service was provisioned.

Suggested owner: application follow-up linked from Drawing Board #43 and Drawing Board #26. The exact trial repository can own implementation when assigned. Do not expand Service #504, which explicitly excludes notification/email delivery, into a universal reminder implementation project. General development-inbox adoption is the separate decision in Core #109.

What is proven

The original generated baseline contained the Reminder model, state transitions and timestamps. Its delivery request remained a disclosed gap. The gap-completion commit 8510df7 added:

• after_create_commit to enqueue ReminderDeliveryJob for scheduled_at;
• a mailer and destination configuration;
• the job that delivers the message and transitions the record to sent;
• ExpireSnoozedRemindersJob and a recurring schedule.

The September 13 audit reported 35 focused model/job/mailer tests / 182 assertions, plus passing post-repair hosted checks. Those used test-mode delivery and direct job execution. They do not establish an operational Codespaces reminder loop or actual email delivery. Current trial main remains 231f75783e9fca53daf984f3f9f7c11577253009; the relevant source still has these boundaries.

Current operational holes

Boundary	Source finding
Queue adapter	No development override to Solid Queue in config/application.rb or config/environments/development.rb; ordinary Rails development defaults to in-process async jobs.
Worker/scheduler	Procfile.dev starts web/JS/CSS only. Puma starts Solid Queue only when SOLID_QUEUE_IN_PUMA == "true". A normally started app does not automatically establish that durable worker.
Recurring task	config/recurring.yml declares the expiry task under production: only. Starting a worker alone is not proof that the development recurring task is selected.
Delivery	Development has no inbox delivery adapter; Action Mailer's default is SMTP and delivery errors are configured not to raise. Tests use test delivery. A successful request or state label is not delivery evidence.
Destination and URLs	The mailer expects an explicitly configured destination. Generic development URL options remain localhost:3000; forwarded browser links need an actual Codespaces-aware host when the message contains links.
Time	A 15-minute sweep approximates end-of-day expiry. The separate UTC/Chicago bug must be settled before end-to-end qualification.

Application jobs and mailer, recurring schedule, development configuration, Puma.

What ordinary Rails already provides

Pinned Rails 8.1.3.1 and Solid Queue 1.4.0 support development queue configuration, bin/jobs, the Puma plugin, delayed dispatch and recurring tasks. Async jobs live in the web process and can disappear when it stops; that is a documented development tradeoff, not a custom First Draft failure. Rails Active Job guide, pinned Solid Queue development instructions, recurring tasks.

Use the app's existing queue tables/database topology. Do not paste the upstream separate-database example over Core's deliberate single-database setup. Solid Queue already schedules the recurring work; no custom polling service, cron gem or job runner is needed. Version 1.4.0 is the actual trial/Core pin. Newer upstream scheduling options must not be assumed to exist in that version.

Rails' built-in mailer previews render examples but do not prove that the app's enqueue/delivery path ran. A development inbox can capture the message generated by the real action without sending to a real address. Mailer previews.

Options and provisional recommendation

1. Before a dedicated reminder demo, use normal Solid Queue in this app's development environment and capture mail locally — recommended. It demonstrates the actual job boundary and restart behavior, with a small conventional configuration change.
2. Keep async/manual execution and label it a component demonstration. Fine for building the feature incrementally, but do not describe it as automatic scheduled reminders.
3. Real email provider/deployment now. Not needed for the next general trial or for proving the local sequence, and outside existing authorization.

One owner question

For a future reminder demonstration, should we qualify the real Solid Queue development loop with a local inbox, rather than treating direct job tests or manual execution as an end-to-end preview?

Acceptance for that future lane

• With ordinary documented startup commands, create a near-future reminder through the UI and observe the actual worker produce one captured message and the intended state transition.
• Exercise the recurring scheduler with a due record and inspect the relevant job/result; direct perform_now alone does not satisfy this check.
• Restart the app/worker before a delayed job becomes due and verify the documented persistence behavior.
• Deliberately make local delivery fail and verify the job/state result honestly reflects the failure. Do not silently send external email as a fallback.
• Check the snooze/expiry path after settling the calendar-day rule, including the sweep tolerance.
• Verify that a captured link opens the correct private Codespaces application and retain exact source/config identities and timings.
• Keep provider delivery, deliverability, phone/native behavior and production scheduling as separately named unproved boundaries.

This packet does not request generic reminder generation, new FP notification syntax, a queue-version upgrade, or real email.