[JacobStephens2]

Summary

email.always in the User config gives a Run its default Run notification ask, the same way merge.always gives it its default goal. The command's email / no-email wins over it.

 main
   args::parse
-    email: Option<Option<String>>            # Some only if --email
+    email: Option<NotificationAsk>           # Send(to) | Skip, from --email / --no-email
+    ask_once(..)                             # one rule for merge/no-merge and email/no-email:
+                                             #   same flag twice → repeated, opposite → can't be used together (exit 2)
   goal = goal.unwrap_or(config.default_goal())
+  ask  = email.unwrap_or(config.email.default_ask())   # email.always → Send(None), else Skip
   match ask
     Send(to) → RunNotification::new(to, ..)  # same preflight: address known, RESEND_API_KEY set
     Skip     → none

NotificationAsk lives in notification.rs next to RunNotification, so the User config doesn't depend on argument parsing. The help text and README document email.always and --no-email.

Evidence

• Before: on main, [email] always = true is an unknown key, so the Run stops with unknown key email.always, and --no-email is an unexpected argument.
  After: cargo test passes in full, including these new tests:
  • run_notification::email_always_makes_a_run_without_the_flag_send_one_notification_to_email_to
  • run_notification::no_email_skips_the_notification_email_always_asks_for (both no-email and --no-email, stand-in gets nothing)
  • run_notification::with_email_always_an_address_after_the_flag_still_wins
  • run_notification::email_always_without_an_address_or_a_key_stops_the_run_before_any_work
  • run_notification::without_email_always_a_run_without_the_flag_sends_nothing (unset and false)
  • command_surface::email_with_no_email_prints_an_error_and_the_help_to_stderr (exit 2, help, no session started)
  • command_surface::help_lists_the_email_settings now also checks for email.always and --no-email
  • config::tests::email_always_asks_for_a_notification_to_email_to, plus a type error for a non-boolean email.always

Merge Danger

Door: two-way

The change adds a config key and a flag. Without email.always, Runs behave exactly as before.

Blast Radius: small

A machine that sets email.always but has no email.to or RESEND_API_KEY now has every Run stop at preflight. That is the behaviour the issue asks for.

Unaddressed findings

Standards

• email.always is nested in EmailSettings while merge_always sits flat on UserConfig. Not changed: each follows its own TOML section's existing struct.
• config.email.default_ask() is a short message chain in main. Not changed: it reads the same as config.default_goal() and hides nothing worth wrapping.

Spec

• no-email given twice is a "repeated argument" error, which the spec doesn't mention. Kept: it matches how every other Run flag already works.
• A non-boolean email.always gets its own "must be true or false" error. Kept: it follows the User config's existing type validation, the same as merge.always.

Closes #115

🤖 Generated with Claude Code