@reventlessdev/reventless-infra 3.0.0-alpha.154 → 3.0.0-alpha.155

package/CHANGELOG.md

@@ -3,6 +3,20 @@
 All notable changes to this project will be documented in this file.
 See [Conventional Commits](https://conventionalcommits.org) for commit guidelines.
 
+# 3.0.0-alpha.155 (2026-09-02)
+
+* feat(aws)!: the messaging sender is configuration, and a stack can choose to only log ([23b8b4b](https://github.com/ReventlessDev/reventless-core/commit/23b8b4bfe9c70555de4d74266ca686cb427485ca))
+
+### BREAKING CHANGES
+
+* `Capability_Messaging_Ses.make` is replaced by
+`Capability_Messaging.make(~name)`, which reads the transport and the address
+from config; the SES module keeps only `emailSender`. A deployment that named its
+sender in code must move it to `platform:messagingEmailSender` or the deploy is
+refused.
+
+
+
 # 3.0.0-alpha.154 (2026-09-01)
 
 **Note:** Version bump only for package @reventlessdev/reventless-infra

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@reventlessdev/reventless-infra",
-  "version": "3.0.0-alpha.154",
+  "version": "3.0.0-alpha.155",
   "description": "Infrastructure types for Reventless framework",
   "license": "Apache-2.0",
   "jest": {
@@ -17,9 +17,9 @@
     "sury-ppx": "11.0.0-rc.2",
     "uuid": "^13.0.0",
     "@reventlessdev/rescript-effect": "0.1.0-alpha.32",
-    "@reventlessdev/rescript-uuid": "2.0.0-alpha.0",
     "@reventlessdev/rescript-pulumi-pulumi": "2.3.0-alpha.19",
-    "@reventlessdev/reventless-spec": "3.0.0-alpha.126"
+    "@reventlessdev/rescript-uuid": "2.0.0-alpha.0",
+    "@reventlessdev/reventless-spec": "3.0.0-alpha.127"
   },
   "devDependencies": {
     "rescript": "12.3.0",

package/src/types/Platform.res

@@ -189,12 +189,33 @@ capability helper.
 `emailSender` is the verified address messages are sent *from* — a provider-side
 identity, not something an application picks per message, which is why it is a
 deploy-time handle rather than a field on `Messaging.message`. Absent when the
-deployment provisions no email channel.
+deployment provisions no email channel. It carries the whole `From:` header, so
+a deployment that configured a display name has it here rather than at the send.
 
 The channel set is derived from which senders are present rather than declared
 beside them, so a handle carrying no sender at all cannot claim a channel.
+
+`smsSender` is the origination number or sender id, on the same terms — with the
+difference that **no transport reads it yet**. It is carried so a stack can state
+the number where the other senders live, and so the field exists before the
+backend that needs it; the SMS channel appears when that backend does, not when
+this is set. A channel claimed ahead of its transport would collect preferences
+that silently deliver nothing, which is the failure the derived channel set above
+exists to prevent.
+
+`emailProvider` names the transport behind the email sender — the value a runtime
+reads to decide which backend to build. Per channel, like the senders themselves:
+an SMS transport is a separate choice, and one key for both would make choosing a
+mail sink also choose how texts go out. On the handle rather than resolved separately at
+each end, so the address and the thing that will send it are provisioned as one
+answer: a platform that read the choice from config itself could disagree with
+the helper that read the address.
 */
-type messagingSender = {emailSender?: Pulumi.Input.t<string>}
+type messagingSender = {
+  emailSender?: Pulumi.Input.t<string>,
+  smsSender?: Pulumi.Input.t<string>,
+  emailProvider?: Pulumi.Input.t<string>,
+}
 
 // Options for the shell's map view mode. Written to config.json flat, beside
 // `viewModes`, because that is where the shell reads them; carried on the arm