studio-engine 0.47.1 → 0.47.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 90659c9a1e1cd62a432e47529501574cca5f7a217f48b6f0eaf0990198150636
-  data.tar.gz: 23435ace6999ecb78b5ad57c2a7c90cf8da64cee0415feb1d5a2fd82f65d4470
+  metadata.gz: 918309978020f15861f65e0a861325bb7ba93046b4d9039aa1aaa1ae6da22c95
+  data.tar.gz: 682e1529aeca6541d08ab5173028bd407b3538fed1e1b9dd3fb88b70b11e0145
 SHA512:
-  metadata.gz: 5c964c5081845ae99315fe62fe98fde0969255d779537524aeb0abbde5b8ceb5fab3ee98c5771471c992b3628021e35e6b42a5f91dc5909bbb3601fd9dabbe1d
-  data.tar.gz: 8c1e90e63006085ef8745ba6a5d1e06b004e09e4c74c523780be2ae9f7e024b3b426aa228dc22eeea683459820a3a9a079720d27e8c8905e90c4796999595d2d
+  metadata.gz: 3da6d45e75a8adcbb72b39117e416381b6c6962fe4b831ee2a90d4feddd9b60a4c63b969cc85d442780685d0a0c2916fe423e7dd11c1df392d2fa06a3f9267e4
+  data.tar.gz: 40e41ee896e9375ebeb9522afb78a9ed481c57c6f15f7a2681a9a51211cf861875a82125bdc52cc6a3b5b9d9820d46e72bd6b2b961822f46ee39367300564755

data/CHANGELOG.md

@@ -6,6 +6,55 @@ The format is [Keep a Changelog](https://keepachangelog.com/en/1.1.0/). This pro
 
 ### Changed
 
+- **No pre-registered email seeds a logo — `magic_link` was the last one, and it
+  seeded the Studio wordmark onto the SIGN-IN email.** `STANDARD`'s `magic_link`
+  entry carried `logo: "emails/logo-horizontal.png"`, and
+  `Studio::EmailCatalog.register` merges on `logo.presence` — an omitted key
+  **inherits**. So any host that registered this email for an unrelated reason (a
+  relabel, attaching a preview builder) inherited the McRitchie Studio wordmark
+  into its own branded sign-in email without ever naming it.
+
+  **ACTION REQUIRED — one consumer, and only one:**
+
+  | Consumer | Was it affected? | What to do |
+  |---|---|---|
+  | **mcritchie-studio** | **Yes.** Registers `magic_link` to attach a preview builder and names no logo, so it INHERITED the mark it owns. | Add `logo: "emails/logo-horizontal.png"` to the `register("magic_link", …)` call already in `config/initializers/studio_emails.rb`. Without it the sign-in banner loses the wordmark. |
+  | turf-monster | No. Registers `emails/turf-logo.png` of its own. | Nothing. |
+  | moms-app, mcritchie-industries, acquisition-studio | No — and they are who this is for. | Nothing. |
+
+  The asset still ships in this gem, so the hub's one-line opt-in resolves today.
+  The tidier end-state is the hub shipping its own copy of the file, since the
+  mark is its identity and not the engine's.
+
+  **This was an UPGRADE TRAP, not a live leak — worth stating precisely, because
+  it was first raised as an incident and is not one.** The three apps carrying no
+  email initializer pin 0.32.1 / 0.32.2 / 0.13.1, and
+  `app/services/studio/email_catalog.rb` does not exist in the gem they run —
+  verified by `git ls-tree` at each tag and against the installed gem. They
+  inherited nothing. The defect was that a routine dependency bump would have put
+  another brand's wordmark on three apps' most-sent email, silently, with no code
+  change of their own. Check reachability at the PIN, never from `main`: "HEAD
+  seeds it" and "the app registers nothing" are both true and together say nothing
+  about what that app RUNS.
+
+  **Why the whole seed and not just the one entry.** This mechanism has now been
+  fixed three times — turf-monster's `magic_link`, then `newsletter_subscribed`,
+  then this — because each fix pinned the instance and left the rule unwritten.
+  `test/lib/studio/email_catalog_test.rb` now reads `STANDARD` and fails on ANY
+  entry carrying a logo, so the next entry cannot repeat it. Artwork still rides
+  the gem, which is what gives a new app good-looking mail on day one; the line is
+  at branding, not at engine assets.
+
+  The asymmetry is what decides it: a host that wanted the mark and lost it sees a
+  missing logo — visible, one line to restore. A host that never asked inherits
+  another brand's identity into its inbox — invisible, and the ALT TEXT AGREES
+  WITH IT, because `Studio::Banner` sets `logo_alt` from `Studio.app_name`. turf's
+  read `alt="Turf Monster"` over the Studio wordmark for weeks.
+
+  On `/admin/emails`, "Standard" and "None" are now the same picture for an app
+  that registers no mark, so the page says so rather than offering a choice that
+  changes nothing.
+
 - **`email_change_confirmation` leaves the pre-registered set; `newsletter_subscribed`
   joins it.** `STANDARD` means "the emails EVERY Studio app sends", and only
   turf-monster sends an email-change confirmation — which it **already registers

data/README.md

@@ -456,17 +456,27 @@ this wrong silent:
 already had, `""` **clears** it, and a path **sets** it. So deleting a `logo: ""`
 line does not remove the logo — it restores the inherited one.
 
-What each `STANDARD` entry lends today:
+**No `STANDARD` entry seeds a logo** — not `magic_link`, not
+`newsletter_subscribed`, and not the next one added. A host that names no mark
+sends no mark, and there is nothing to opt out of.
 
-| Entry | Seeds a logo? |
-|---|---|
-| `newsletter_subscribed` | **No.** A host that names none sends none. |
-| `magic_link` | **Yes** — `emails/logo-horizontal.png`, the Studio wordmark. A host that has not registered its own mark inherits it. |
+That is an invariant, not a coincidence: `test/lib/studio/email_catalog_test.rb`
+reads `STANDARD` and fails on any entry carrying a logo, because this mechanism
+was fixed three times as an instance before it was fixed as a rule. Artwork still
+rides the gem, which is what gives a new app good-looking mail on day one.
 
-If you are **bumping this gem** into an app that registers no email entries, that
-second row is an upgrade trap: the app gains a Studio wordmark on its sign-in
-email without changing a line of its own. Register a `magic_link` logo your app
-ships — or `logo: ""` — in the same bump.
+**Adopting a mark** is one line, in an initializer or on `/admin/emails`:
+
+```ruby
+Studio::EmailCatalog.register("magic_link", logo: "emails/our-mark.png")
+```
+
+If you are **bumping this gem** ACROSS this change — that is, from any release
+that still seeded the mark, which is **every version up to and including
+0.47.0** — note what CHANGED rather than what to fear: `magic_link` used to seed
+the Studio wordmark, so an app that registered no logo inherited it. If your app
+WANTED that mark, it now has to name it — see the CHANGELOG entry, which lists
+who that affects.
 
 **Why layered rather than composited.** Drawing the text into the image gives
 pixel-exact brand typography everywhere, but it cannot have an ANIMATED

data/app/services/studio/email_catalog.rb

@@ -142,7 +142,13 @@ module Studio
         # top. default_asset above stays the flat <img> for a mailer that has not
         # adopted the layered banner.
         background: "emails/magic-link-background.gif",
-        logo: "emails/logo-horizontal.png",
+        # NO logo: KEY — the same rule newsletter_subscribed above follows, and
+        # for the same reason. It seeded "emails/logo-horizontal.png" (the
+        # McRITCHIE STUDIO wordmark) into every host that registers this email
+        # without naming a mark, because register() merges on `logo.presence`
+        # and an omitted key INHERITS. On the SIGN-IN email, which is the most-
+        # sent email most of these apps have. Full reasoning under NO DEFAULT
+        # LOGO below; the guards are in test/integration/magic_link_logo_test.rb.
         # The DEFAULT wording, overridable per app on /admin/emails. {name} is
         # filled from whoever the mailer says the recipient is.
         header: "Welcome {name}!",
@@ -199,10 +205,14 @@ module Studio
     ASPECT_RATIO = 2.0
     MAX_WIDTH = 1200
 
-    # NO DEFAULT LOGO, deliberately — on any route.
+    # NO DEFAULT LOGO, deliberately — on any route, for any entry.
     #
-    # There is no DEFAULT_LOGO constant here, and newsletter_subscribed above
-    # seeds no logo either. Same rule, learned twice, on two different routes.
+    # There is no DEFAULT_LOGO constant here, and NO entry in STANDARD seeds a
+    # logo. That is now an invariant over the whole seed rather than a fact about
+    # two entries that happen to be clean — asserted in
+    # test/lib/studio/email_catalog_test.rb, which reads STANDARD and fails on any
+    # entry carrying a mark. The instance kept coming back; the rule is what
+    # stops it.
     #
     # The constant went first (DEFAULT_FOOTER_LOGO). It was
     # emails/logo-horizontal.png — the white "McRITCHIE STUDIO" wordmark —
@@ -235,26 +245,47 @@ module Studio
     # (`Studio::EmailCatalog.register("newsletter_subscribed", logo: "emails/our-mark.png")`,
     # a path THAT APP ships) or on /admin/emails.
     #
-    # STILL OUTSTANDING, stated so nobody reads this as swept: magic_link above
-    # DOES still seed the wordmark, so a host that registers no mark of its own
-    # inherits it on the sign-in email. turf-monster registers emails/turf-logo.png
-    # and the Studio hub owns the mark, so both are covered.
-    #
-    # It is an UPGRADE TRAP rather than a live leak, which is the sharper shape.
-    # The apps carrying no email initializer are pinned far enough back that this
-    # file does not exist in the gem they run, so they inherit nothing today — but
-    # the routine dependency bump that brings one forward would put another
-    # brand's mark in its most-sent email, with no code change of its own and
-    # nobody looking for it.
+    # THE THIRD INSTANCE closed the question the first two left open: should
+    # STANDARD seed a logo AT ALL? It should not, and now none does.
+    #
+    # magic_link was the last holdout, and the sharpest — it seeded the wordmark
+    # onto the SIGN-IN email, the most-sent email most Studio apps have. Two
+    # narrow fixes (turf's magic_link, then newsletter_subscribed) had already
+    # been made, and the mechanism produced a third anyway. So the rule moved
+    # from the instance to the seed: a shared default may not carry anybody's
+    # identity, and the guard reads STANDARD rather than a list of keys, because
+    # the failure mode is the NEXT entry, written by someone who never read this.
+    #
+    # WHY THE ASYMMETRY DECIDES IT. A host that wanted the mark and lost it sees
+    # a missing logo — visible, and one line to restore. A host that never asked
+    # inherits another brand's identity into its own inbox — invisible, and the
+    # ALT TEXT AGREES WITH IT, because Studio::Banner sets logo_alt from
+    # Studio.app_name. turf's read "Turf Monster" over the Studio wordmark for
+    # weeks and no one reviewing that email could have seen it. Given one error
+    # to make, make the loud one.
+    #
+    # WHO PAID FOR THIS, named rather than left to be discovered: McRitchie
+    # Studio, the hub, registers magic_link to attach a preview builder and names
+    # no logo — so it INHERITED the mark it owns, and ships no copy of the file
+    # itself. It opts in with `logo: "emails/logo-horizontal.png"` on the
+    # register() call it already makes. The asset stays in this gem so that line
+    # resolves today; the hub shipping its own copy is the tidier end-state, as
+    # the mark is its identity and not the engine's. turf-monster names
+    # emails/turf-logo.png and was never affected.
+    #
+    # It was an UPGRADE TRAP rather than a live leak, which is the sharper shape
+    # and the reason this was worth fixing before anyone was hurt. The apps
+    # carrying no email initializer (moms-app, mcritchie-industries,
+    # acquisition-studio) are pinned far enough back — 0.32.1 / 0.32.2 / 0.13.1 —
+    # that this file does not exist in the gem they run, so they inherited
+    # nothing. The routine dependency bump that brought one forward would have
+    # put another brand's mark in its most-sent email, with no code change of its
+    # own and nobody looking for it.
     #
     # CHECK REACHABILITY AT THE PIN, never from main: `git ls-tree` at the tag the
     # app resolves, or read the installed gem. "HEAD seeds it" plus "the app
     # registers nothing" are both true and together say nothing about what that
     # app RUNS — a wrong conclusion this very comment was first drafted with.
-    #
-    # Tracked, with the design question it raises — should STANDARD seed a logo at
-    # all, or should hosts opt in? — at /tasks/guard-wordmark-on-engine-bump.
-    # Fixing magic_link alone leaves the next entry free to repeat this.
 
     # The footer band. Dark on purpose: it closes the white card, and a light
     # sign-off floating under body copy reads as part of the message rather than

data/app/views/studio/emails/show.html.erb

@@ -312,8 +312,15 @@
         </div>
 
         <%# THE LOGO — three states, because a URL box can only express two.
-            Standard inherits the shared mark, Custom is what this app uploaded,
-            Hidden is the deliberate "no logo" that blank cannot say. %>
+            Standard is the mark THIS APP registered, Custom is what it uploaded,
+            Hidden is the deliberate "no logo" that blank cannot say.
+
+            "Standard" is no longer a shared mark. No STANDARD entry seeds a logo
+            (the engine's wordmark riding the seed into a host's sign-in email
+            was the bug), so on an app that registered none, Standard and None
+            are the same picture — nothing. The note below says so, because a
+            control offering a choice that changes nothing is the failure this
+            page keeps producing. %>
         <div>
           <span class="text-sm text-muted block mb-1">Logo</span>
           <div class="flex flex-wrap items-center gap-2">
@@ -336,6 +343,13 @@
             <%= button_to "Back to the standard logo", admin_email_logo_path(@entry.key),
                   method: :patch, params: { remove: "1" },
                   class: "text-2xs text-muted underline underline-offset-2 mt-2" %>
+          <% elsif Studio::EmailCatalog.logo_url(@entry.key).blank? %>
+            <p class="text-2xs text-muted mt-2" data-logo-none-registered>
+              This app registers no mark for this email, so Standard shows none.
+              Upload one here, or name a file your app ships with
+              <code class="font-mono">logo:</code> in
+              <code class="font-mono">config/initializers/studio_emails.rb</code>.
+            </p>
           <% end %>
         </div>
 

data/lib/studio/version.rb

@@ -1,3 +1,3 @@
 module Studio
-  VERSION = "0.47.1"
+  VERSION = "0.47.2"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: studio-engine
 version: !ruby/object:Gem::Version
-  version: 0.47.1
+  version: 0.47.2
 platform: ruby
 authors:
 - Alex McRitchie