@company-semantics/contracts 36.0.0 → 37.0.0

package/src/notifications/content.ts

@@ -144,10 +144,11 @@ export interface Signature {
  * `width`/`height` are the image's intrinsic pixel dimensions. They are optional
  * because a channel that can measure an image itself does not need to be told, and
  * requiring them would put a rendering constraint into channel-agnostic content.
- * But a channel MAY be unable to draw one without them: AMP's `<amp-img>` requires
- * explicit dimensions to reserve layout before the image loads, so the email
- * channel's AMP surface degrades to the `alt` text when they are absent
- * (ADR-CONTRACTS-089). Supplying them is what makes the image drawable everywhere.
+ * But a channel MAY be unable to draw one without them, and the constraint is real
+ * even though the surface that first raised it is gone: AMP's `<amp-img>` required
+ * explicit dimensions to reserve layout, and the email channel's AMP surface fell
+ * back to the `alt` text without them (retired in ADR-CONTRACTS-091). Supplying
+ * them is what makes the image drawable everywhere.
  */
 export interface HeroImage {
   type: "heroImage";

package/src/notifications/renderers/email/README.md

@@ -16,8 +16,8 @@ the markup. The strings are the same strings.
 | `render.ts`      | each `NotificationElement` → its class-only `<p>`/table markup, and spacing            |
 | `chat.ts`        | `chatUnit` → HTML bubbles and plain-text box art                                       |
 | `cta.ts`         | the `>> LABEL <<` button, shared by a standalone CTA and a chat one                    |
-| `shells.ts`      | `htmlShell` / `ampShell` / `textShell` — what makes one email three surfaces           |
-| `styles.ts`      | every declaration, as recipes — plus `inlineStyles` and `ampify`                       |
+| `shells.ts`      | `htmlShell` / `textShell` — what makes one email two surfaces                          |
+| `styles.ts`      | every declaration, as recipes — plus `inlineStyles`                                    |
 | `colors.ts`      | every colour, by role, in every scheme — and the dark stylesheet                       |
 | `constants.ts`   | typography and layout (`MONO_DECL`, `FONT_SIZE`, `SPACING`, `CTA_PAD`) + `COMPANY_URL` |
 | `escape-html.ts` | `escapeHtml`                                                                           |
@@ -27,38 +27,43 @@ before it was deleted. The brand NAME is deliberately not among them: it is
 `../../context`'s `COMPANY_NAME`, because it is the same answer on every channel
 and renderers read it from `context.brand`.
 
-## Three surfaces, one markup (ADR-CONTRACTS-089)
+## Two surfaces, one markup (ADR-CONTRACTS-089, -091)
 
-An email is a `multipart/alternative`: `text/plain`, `text/html` and
-`text/x-amp-html` are three presentations of ONE message, and `RenderedEmail`
-carries all three. AMP is not a fourth channel — a recipient gets one email.
+An email is a `multipart/alternative`: `text/plain` and `text/html` are two
+presentations of ONE message, and `RenderedEmail` carries both.
 
-The catch is that the two HTML-ish surfaces disagree about styling at the root.
-AMP4EMAIL forbids inline `style` attributes and `!important`; the html surface is
-built from both, deliberately (see Colour below). So **the markup belongs to
-neither**: `render.ts`, `cta.ts` and `chat.ts` emit CLASS-ONLY markup, and each
-shell spends `styles.ts` its own way —
-
-- `htmlShell` runs `inlineStyles`, which turns recipe classes back into the exact
-  inline styles this channel has always shipped;
-- `ampShell` runs `ampify` (the `<img>` → `<amp-img>` swap) and states the same
-  recipes as `<style amp-custom>`.
+`render.ts`, `cta.ts` and `chat.ts` emit CLASS-ONLY markup, and `htmlShell` runs
+`inlineStyles`, which turns recipe classes back into the exact inline styles this
+channel has always shipped.
 
 `EmailLine` gains no third field: `../../renderer.ts` warns against exactly that,
 and a surface is a way of SPENDING the lines rather than a thing a line carries.
-The cost is that `EmailLine.html` is now an intermediate representation —
-`render.ts` no longer reads as the bytes it emits, and the snapshot is where the
-real markup is legible.
+The cost is that `EmailLine.html` is an intermediate representation — `render.ts`
+does not read as the bytes it emits, and the snapshot is where the real markup is
+legible.
+
+### There was a third surface, and removing it is the point
+
+`text/x-amp-html` shipped in 36.0.0 and was retired in 37.0.0. The class-only split
+above exists BECAUSE of it — AMP forbids inline `style`, the html surface is built
+from it — and the split stays: the registry is now the single source for a recipe,
+and the markup is byte-identical either way (removing AMP changed the snapshot by
+1965 deletions and **zero** insertions).
 
-**What AMP is for:** `:hover`. ADR-CONTRACTS-088 bought a hover state that Gmail
-does not honour, and Gmail is most opens. AMP is where that rule reaches people.
+AMP bought `:hover` in Gmail. It cost Gmail iOS its dark mode, and we did not know
+that when we shipped it: **Gmail iOS inverts the html part and does NOT touch an AMP
+part**, so having one opts those readers out of the only dark scheme they get. That
+is measured, not argued — `company-semantics-backend/docs/dark-mode-probe.md`, and
+it is a fact the public record does not contain. A hover state is worth less than a
+legible email (ADR-CONTRACTS-091).
 
-**What AMP does not have:** dark. AMP4EMAIL disallows the `prefers-color-scheme`
-media feature outright. It costs nothing — see Colour.
+Two things we learned the expensive way, so nobody re-derives them:
 
-`pnpm validate:amp` runs the real AMP validator. `__tests__/amp.test.ts` asserts
-the constraints we KNOW on every run, which is not the same claim: it passed once
-while every fixture was invalid.
+- `prefers-color-scheme` in `<style amp-custom>` is a hard AMP4EMAIL validator
+  ERROR. Real, permanent, frozen since 2023.
+- The `media` ATTRIBUTE on an AMP element takes the same feature and PASSES the
+  validator — and Gmail's runtime ignores it entirely, rendering both a dark-gated
+  and a light-gated block. Validator-legal, runtime-inert. That door is closed.
 
 ## Colour — the thing this channel has and the others do not
 
@@ -148,29 +153,22 @@ expect to style it properly rather than trust the placeholder.
   `__tests__/colors.test.ts` fails on a raw hex anywhere else in the directory,
   including one in a comment, because a comment naming a literal goes stale the
   first time the palette is tuned.
-- On the HTML surface, light is inline and dark is the `<style>` block, and that is
-  the mechanism rather than duplication: one source each for two schemes, both from
-  `colors.ts`. Every dark declaration carries `!important` because the inline light
-  colour would otherwise win on specificity and dark would silently do nothing. On
-  the AMP surface there is no inline style, so the recipes carry light and source
-  order alone would resolve a cascade — which is moot, because AMP has no dark.
+- Light is inline and dark is the `<style>` block, and that is the mechanism rather
+  than duplication: one source each for two schemes, both from `colors.ts`. Every
+  dark declaration carries `!important` because the inline light colour would
+  otherwise win on specificity and dark would silently do nothing.
 - `:hover` is the one exception, because it has no inline form: BOTH schemes state
   it in the stylesheet (`BASE_STYLE` light, `DARK_STYLE` dark, resolved by source
-  order). On the HTML surface it is opportunistic — Apple Mail honours it, Gmail and
-  classic Outlook do not — and needs no fallback, because without it the button
-  simply rests. It is also the ONE rule the AMP surface shares, via
-  `hoverStyle(false)`; AMP forbids `!important`, which is why that template takes a
-  parameter and `DARK_STYLE` does not.
-- The AMP surface has NO dark scheme, and loses nothing by it. AMP4EMAIL disallows
-  the `prefers-color-scheme` media feature (checked against the AMP validator, with
-  and without `data-css-strict`), so it cannot. The audiences are disjoint: dark
-  reaches Apple Mail, iOS Mail and Outlook for Mac; AMP reaches Gmail, Yahoo and
-  Mail.ru — the force-inverting clients that never received our dark colours anyway.
-  AMP swaps a scheme its readers never got for a hover state they never got.
-- Role hooks ride the AMP surface unstyled (`cs-faint`, `cs-bubble`, `cs-cta`,
-  `cs-link`), because their only rules live in `DARK_STYLE`. Their colours arrive
-  via each recipe's `roleDecl`, so this is dead bytes rather than a bug — the price
-  of one markup. `.cs-cta-hover` is the exception: it is the feature.
+  order). It is opportunistic — Apple Mail honours it, Gmail and classic Outlook do
+  not — and needs no fallback, because without it the button simply rests.
+- **`DARK_STYLE` reaches Apple Mail, iOS Mail and Outlook for Mac, and nobody else.**
+  No Gmail client honours `prefers-color-scheme` on any surface; Yahoo rewrites the
+  query. A Gmail reader's dark mode is whatever their client does to our light
+  colours unaided: Gmail iOS inverts the html part, Gmail web does nothing at all.
+  Closing the Gmail-web gap means inversion-indifferent authoring HERE — mid-tones,
+  no pure `#ffffff`/`#000000` in large fields, solid-fill CTAs — not another surface.
+- Role hooks (`cs-faint`, `cs-bubble`, `cs-cta`, `cs-link`) carry their colours via
+  each recipe's `roleDecl`; their only stylesheet rules live in `DARK_STYLE`.
 - A hover hook goes on a CTA ONLY when it has an `href`. An unlinked label is a
   payload (an OTP code), and a hover state on it would promise a click that does
   not exist — the same invariant that keeps it a `<span>` rather than an `<a>`.

package/src/notifications/renderers/email/__tests__/styles.test.ts

@@ -19,7 +19,7 @@ import { describe, expect, it } from "vitest";
 import type { NotificationContent } from "../../../content";
 import type { RenderContext } from "../../../context";
 import { emailRenderer } from "../index";
-import { inlineOf, inlineStyles, ruleOf, STYLE_NAMES } from "../styles";
+import { inlineOf, inlineStyles, STYLE_NAMES } from "../styles";
 
 const CONTEXT: RenderContext = {
   brand: { name: "Company Semantics", copyrightYear: 2026 },
@@ -100,11 +100,11 @@ describe("the style registry", () => {
     expect(inlineStyles(plain)).toBe(plain);
   });
 
-  it("states each recipe as a rule and as an inline style, from one source", () => {
-    // The two surfaces' only difference is the shape, never the content — which is
-    // the claim that lets `ampShell` and `htmlShell` share this registry.
+  it("states every recipe as an inline style, from one source", () => {
+    // `ruleOf` — the same recipe as a CSS rule — went with the AMP surface
+    // (ADR-CONTRACTS-091). It had no other caller, and a rule nobody states is not
+    // a shape this registry needs to keep proving it can take.
     for (const name of STYLE_NAMES) {
-      expect(ruleOf(name)).toBe(`.csr-${name} { ${inlineOf(name)} }`);
       expect(inlineOf(name).endsWith(";")).toBe(true);
     }
   });

package/src/notifications/renderers/email/chat.ts

@@ -57,10 +57,11 @@ const CHAT_INDENT = "       ";
  * The gap under a chat row: 24px clears the bubbles, 16px hugs whatever the row
  * is introducing (a CTA, the dots).
  *
- * A recipe name rather than a margin string, because a margin cannot be inline on
- * the AMP surface (ADR-CONTRACTS-089) — and naming the two the layout actually has
- * is what makes a third one a deliberate addition to `./styles.ts` rather than a
- * new string appearing at a call site.
+ * A recipe name rather than a margin string. The AMP surface first forced this —
+ * a margin could not be inline there — and it earns its keep without that surface
+ * (ADR-CONTRACTS-091): naming the two the layout actually has is what makes a third
+ * one a deliberate addition to `./styles.ts` rather than a new string appearing at
+ * a call site.
  */
 type ChatRow = "chat-row-16" | "chat-row-24";
 

package/src/notifications/renderers/email/colors.ts

@@ -270,24 +270,27 @@ const dark = PALETTES.dark;
  * the LIGHT hover; the dark block follows it in the shell and overrides it, so
  * source order is what resolves them (same specificity).
  *
- * Whether any of it happens is the client's call, and this is the ONE role whose
- * reach the AMP surface changes. Apple Mail honours `:hover`, new Outlook for Mac
- * and Yahoo partially, Gmail and classic Outlook not at all — but Gmail is an AMP
- * client, and there this rule simply works. On the html surface there is no
- * fallback to write: without it the button rests, which is how it looks today.
- * Purely additive, like the dark path. See `./styles.ts` for the surface split.
+ * Whether any of it happens is the client's call. Apple Mail honours `:hover`, new
+ * Outlook for Mac and Yahoo partially, Gmail and classic Outlook not at all. There
+ * is no fallback to write: without it the button rests, which is how it looks
+ * today. Purely additive, like the dark path.
+ *
+ * Gmail never gets it, and that is now a settled trade rather than a gap. The AMP
+ * surface existed to reach exactly this one role in Gmail — and cost Gmail iOS
+ * readers their dark mode to do it, since Gmail leaves an AMP part un-inverted.
+ * A hover state is worth less than a legible email (ADR-CONTRACTS-091).
+ *
+ * `!important` is load-bearing: the light colour is inline, inline beats a
+ * stylesheet, and without it this rule silently loses. It used to be a parameter,
+ * because the AMP surface had no inline style to beat and AMP forbids the keyword.
+ * With that surface gone there is one caller, and a parameter with one caller is
+ * not a seam.
  *
  * `.cs-cta-hover` is present ONLY on a CTA that actually has an `href` — see
  * `./cta.ts`. An OTP code wears `.cs-cta` for its edge and never this, because a
  * hover state on something unclickable promises a click that will not happen.
  */
-export function hoverStyle(important: boolean): string {
-  const bang = important ? " !important" : "";
-  return `.cs-cta-hover:hover { background-color: ${light.ctaHover}${bang}; }`;
-}
-
-/** The html surface's hover block. See `hoverStyle` for why it is `important`. */
-export const BASE_STYLE = hoverStyle(true);
+export const BASE_STYLE = `.cs-cta-hover:hover { background-color: ${light.ctaHover} !important; }`;
 
 /**
  * The dark override.
@@ -301,15 +304,15 @@ export const BASE_STYLE = hoverStyle(true);
  * colour is inline, inline beats a stylesheet on specificity, and without
  * `!important` every rule here silently loses and dark quietly does nothing.
  *
- * **This block is the html surface's alone, and gives up nothing by being so.**
- * AMP4EMAIL disallows the `prefers-color-scheme` media feature outright — verified
- * against the AMP validator, with and without `data-css-strict` — so the AMP
- * surface cannot carry these rules in any form, and does not try
- * (ADR-CONTRACTS-089). It costs nothing, because the two audiences are disjoint:
- * this block is read by Apple Mail, iOS Mail and Outlook for Mac (see
- * `./shells.ts`), and AMP is read by Gmail, Yahoo and Mail.ru — clients that
- * force-invert and never honoured it. Unlike `hoverStyle`, there was no version of
- * this worth parameterizing.
+ * **Read by Apple Mail, iOS Mail and Outlook for Mac, and by nobody else.** No
+ * Gmail client honours `prefers-color-scheme` on any surface, and Yahoo rewrites
+ * the query rather than honouring it — so this block has never reached them and a
+ * Gmail reader's dark mode is whatever their client does to our light colours on
+ * its own. On Gmail iOS that is a post-delivery inversion of the html part; on
+ * Gmail web it is nothing at all, and a light email stays light in a dark client.
+ * Closing THAT gap is inversion-indifferent authoring here — mid-tones, no pure
+ * #ffffff/#000000 in large fields, solid-fill CTAs — not another surface. See
+ * `company-semantics-backend/docs/dark-mode-probe.md` and ADR-CONTRACTS-091.
  *
  * `.cs-faint` states both `color` and `border-top-color` because one role lands
  * on two properties — the `/* EOM *\/` span takes the first and ignores the

package/src/notifications/renderers/email/cta.ts

@@ -41,10 +41,8 @@ const CTA_BOX_PAD = 3;
  * it survives `inlineStyles` untouched — and its `!important` still beats the
  * inline padding, exactly as before.
  *
- * The AMP surface never composes it: Outlook's Word engine is not an AMP client,
- * `display: block` works natively in Gmail/Yahoo/Mail.ru, and AMP forbids both
- * conditional comments and `!important`. Nothing has to strip it — it lives in the
- * `<head>`, not in an `EmailLine`.
+ * It lives in the `<head>`, not in an `EmailLine`, which is why no surface ever had
+ * to strip it.
  */
 export const MSO_CTA_STYLE = `.cs-cta td { padding: ${CTA_PAD} !important; }
 .cs-cta a { padding: 0 !important; }`;
@@ -70,10 +68,10 @@ export function ctaButton(
 
   // The hover hook goes on ONLY when there is somewhere to go. An OTP code is a
   // box with no link in it, and lighting it up under the pointer would promise a
-  // click that does not exist. On the html surface `:hover` is opportunistic — see
-  // `./colors.ts`'s `hoverStyle` — so it adds a state in Apple Mail and changes
-  // nothing in Gmail; on the AMP surface it simply works, which is what that
-  // surface is FOR (ADR-CONTRACTS-089).
+  // click that does not exist. `:hover` is opportunistic — see `./colors.ts`'s
+  // `BASE_STYLE` — so it adds a state in Apple Mail and changes nothing in Gmail.
+  // Reaching Gmail with it was the AMP surface's whole purpose, and cost Gmail iOS
+  // its dark mode to do it (ADR-CONTRACTS-091).
   const boxClass = href
     ? styleClass(`cta-box-${margin}`, "cta", "ctaHover")
     : styleClass(`cta-box-${margin}`, "cta");

package/src/notifications/renderers/email/index.ts

@@ -25,17 +25,20 @@ import type { Renderer } from "../../renderer";
 
 import type { Spacing } from "./constants";
 import { renderElement } from "./render";
-import { ampShell, type EmailLine, htmlShell, textShell } from "./shells";
+import { type EmailLine, htmlShell, textShell } from "./shells";
 
 /**
  * One rendered email — the email channel's natural output type.
  *
- * Three bodies, because an email IS a `multipart/alternative`: one message, whose
- * parts a client chooses between. This is NOT three channels — a recipient gets one
- * email — which is why AMP lives here rather than behind a second `Renderer`
- * (ADR-CONTRACTS-089). Assembling the parts is delivery's job, and delivery is not
- * contracts': today the backend sends `text` and `html` over SES's simple send and
- * `amp` goes nowhere.
+ * Two bodies, because an email IS a `multipart/alternative`: one message, whose
+ * parts a client chooses between. Assembling the parts is delivery's job, and
+ * delivery is not contracts'.
+ *
+ * There was a third — `amp`, an AMP4EMAIL body — and it is gone
+ * (ADR-CONTRACTS-091). It bought `:hover` on the CTA for Gmail readers and cost
+ * them their dark mode: Gmail iOS inverts the html part and does NOT touch the AMP
+ * part, so an AMP part opts those readers OUT of the only dark scheme they receive.
+ * That is measured, not argued — `company-semantics-backend/docs/dark-mode-probe.md`.
  */
 export interface RenderedEmail {
   /** Subject line — the notification's `metadata.title`. */
@@ -44,11 +47,6 @@ export interface RenderedEmail {
   text: string;
   /** HTML body (`text/html`) — every kind is multi-output. */
   html: string;
-  /**
-   * AMP4EMAIL body (`text/x-amp-html`) — read by Gmail, Yahoo and Mail.ru, and
-   * the only surface where the CTA's `:hover` reaches most recipients.
-   */
-  amp: string;
 }
 
 /**
@@ -82,7 +80,6 @@ export const emailRenderer: Renderer<RenderedEmail> = {
       subject: content.metadata.title,
       text: textShell(lines),
       html: htmlShell(lines),
-      amp: ampShell(lines),
     };
   },
 };

package/src/notifications/renderers/email/render.ts

@@ -216,10 +216,8 @@ export function renderElement(
       ];
 
     case "heroImage": {
-      // Stated as attributes, not just style: they are the image's intrinsic
-      // size, every client uses them to reserve space before it loads, and
-      // `./styles.ts`'s `ampify` reads them to decide whether the AMP surface can
-      // draw an `<amp-img>` at all.
+      // Stated as attributes, not just style: they are the image's intrinsic size
+      // and every client uses them to reserve space before it loads.
       const dimensions =
         element.width !== undefined && element.height !== undefined
           ? ` width="${element.width}" height="${element.height}"`

package/src/notifications/renderers/email/shells.ts

@@ -6,6 +6,9 @@
  * composes ONE list of `EmailLine`s and both surfaces derive from it, so the two
  * can never disagree about what the email says.
  *
+ * There was a third shell — `ampShell` — retired in ADR-CONTRACTS-091. See
+ * `./index.ts`: the AMP part cost Gmail readers their dark mode.
+ *
  * INVARIANTS:
  * - Pure functions of their input lines. No clock, no environment, no I/O.
  * - These strings are the email's actual markup, and
@@ -13,16 +16,10 @@
  *   character-for-character.
  */
 
-import { BASE_STYLE, DARK_STYLE, hoverStyle } from "./colors";
+import { BASE_STYLE, DARK_STYLE } from "./colors";
 import type { Spacing } from "./constants";
 import { MSO_CTA_STYLE } from "./cta";
-import {
-  AMP_RECIPE_RULES,
-  ampify,
-  inlineOf,
-  inlineStyles,
-  styleClass,
-} from "./styles";
+import { inlineOf, inlineStyles } from "./styles";
 
 /**
  * One rendered line — both presentations of one thing the notification says,
@@ -48,11 +45,16 @@ export interface EmailLine {
  * protecting our colours, apply its dark background, and leave the inline LIGHT
  * text colour sitting on top of it. The two ship together or not at all.
  *
- * Only Apple Mail, iOS Mail and Outlook for Mac read any of this. Clients that
- * force-invert (Outlook.com, Windows Outlook, Gmail Android) ignore both metas
- * and rewrite the inline styles post-delivery — nothing here can stop that, which
- * is why the body still states an explicit background rather than trusting a
- * default.
+ * Only Apple Mail, iOS Mail and Outlook for Mac read any of this. No Gmail client
+ * honours `prefers-color-scheme` on any surface; what Gmail iOS does instead is
+ * invert this part post-delivery, which nothing here can stop — and which is why
+ * the body still states an explicit background rather than trusting a default.
+ * That inversion is not a fallback we tolerate, it is the ONLY dark mode a Gmail
+ * iOS reader gets, and preserving it is why the AMP surface was retired
+ * (ADR-CONTRACTS-091): Gmail leaves an AMP part alone, so having one would have
+ * turned this inversion off. Measured in
+ * `company-semantics-backend/docs/dark-mode-probe.md` — Gmail web, by contrast,
+ * recolours nothing at all.
  *
  * The `<!--[if mso]>` block is the mirror image: it is read ONLY by the Outlook
  * Word engine, and undoes the one layout that engine cannot render — a linked
@@ -85,71 +87,6 @@ ${inner}
 </html>`;
 }
 
-/**
- * Wrap rendered lines in the AMP4EMAIL shell (ADR-CONTRACTS-089).
- *
- * The third MIME part of the same email — `text/x-amp-html`, beside `text/html`
- * and `text/plain`. Gmail, Yahoo and Mail.ru read it; everyone else reads the
- * html part and never knows this existed. That is the point: `./colors.ts`'s
- * `hoverStyle` is absent in Gmail on the html surface, and here it simply works.
- *
- * Everything AMP forbids is absent BY CONSTRUCTION rather than by stripping:
- *
- * - **No inline `style`.** The lines are class-only; only `htmlShell` inlines them.
- * - **No `!important`.** `hoverStyle(false)` — there is no inline style to beat
- *   here, so nothing needs to win a specificity fight, and AMP forbids the keyword
- *   anyway.
- * - **No `<!--[if mso]>`.** `MSO_CTA_STYLE` lives in `htmlShell`'s `<head>`, never
- *   in a line, so nothing has to remove it. Outlook is not an AMP client, and
- *   `display: block` needs no correction in the three that are.
- *
- * **No dark scheme, and that is not an omission.** AMP4EMAIL disallows the
- * `prefers-color-scheme` media feature — verified against the AMP validator, with
- * and without `data-css-strict` — so `DARK_STYLE` cannot appear here in any form.
- * It costs nothing: that block is read by Apple Mail, iOS Mail and Outlook for Mac,
- * and this surface is read by Gmail, Yahoo and Mail.ru. The two sets are disjoint,
- * and the AMP clients force-invert rather than honour a stylesheet — so they were
- * never receiving our dark colours on the html surface either. What this surface
- * adds is `:hover`, which those clients DO honour and which the html surface cannot
- * reach them with. It trades nothing away.
- *
- * The boilerplate hides the body until the runtime unhides it — which is why an
- * AMP document that cannot run scripts shows nothing at all, rather than showing
- * an unstyled version of itself.
- */
-export function ampShell(lines: EmailLine[]): string {
-  const inner = ampify(
-    lines
-      .map((line) => line.html)
-      .filter(Boolean)
-      .join("\n"),
-  );
-  // `amp4email` rather than the `⚡4email` the spec also allows: both are valid,
-  // and one of them survives every editor, terminal and diff it will ever cross.
-  //
-  // `data-css-strict` opts into AMP's strict CSS validation. The validator warns
-  // when it is absent and says it "may become an error in the future"; our CSS
-  // passes with and without it, so taking it now costs nothing and means that
-  // future arrives already handled.
-  //
-  // The shell wears its own recipes as CLASSES, where `htmlShell` inlines them —
-  // that asymmetry is the whole surface split, and it means `body` and `frame`
-  // need no special case: `AMP_RECIPE_RULES` already states every recipe's rule.
-  return `<!DOCTYPE html>
-<html amp4email data-css-strict lang="en">
-<head><meta charset="utf-8">
-<script async src="https://cdn.ampproject.org/v0.js"></script>
-<style amp4email-boilerplate>body{visibility:hidden}</style>
-<style amp-custom>${AMP_RECIPE_RULES}
-${hoverStyle(false)}</style></head>
-<body ${styleClass("body")}>
-<div ${styleClass("frame")}>
-${inner}
-</div>
-</body>
-</html>`;
-}
-
 /**
  * Join rendered lines into the plain-text email — separated per each line's
  * spacing, with a trailing newline.

package/src/notifications/renderers/email/styles.ts

@@ -250,10 +250,16 @@ export const STYLE_NAMES = Object.keys(RECIPES) as StyleName[];
  *
  * This is the whole mechanism. A `cs-` role class is a HOOK: `darkStyle` needs it
  * in the shipped markup, so it survives. A `csr-` recipe class is a BUNDLE OF
- * DECLARATIONS: the html surface spends it and drops it, the AMP surface keeps it
- * and states its rule. One prefix test separates them — for `inlineStyles` below,
- * and for `__tests__/colors.test.ts`, which asserts every SHIPPED class has a dark
- * rule and would otherwise trip over every recipe class in this file.
+ * DECLARATIONS: the html surface spends it and drops it. One prefix test separates
+ * them — for `inlineStyles` below, and for `__tests__/colors.test.ts`, which asserts
+ * every SHIPPED class has a dark rule and would otherwise trip over every recipe
+ * class in this file.
+ *
+ * The registry once had a second consumer — the AMP surface kept these classes and
+ * stated their rules, and that opposition (html inlines, AMP does not) is why it
+ * exists. AMP is gone (ADR-CONTRACTS-091) and the registry stays: it is now the
+ * single source for a recipe, spent in one place, and the markup it produces is
+ * byte-identical either way.
  */
 const RECIPE_PREFIX = "csr-";
 
@@ -279,11 +285,6 @@ export function inlineOf(name: StyleName): string {
   return `${RECIPES[name].join("; ")};`;
 }
 
-/** `.csr-bubble-user { border-radius: 8px; … }` — one recipe, as a rule. */
-export function ruleOf(name: StyleName): string {
-  return `.${recipeClass(name)} { ${inlineOf(name)} }`;
-}
-
 /**
  * Class-only markup → the html surface's markup.
  *
@@ -316,46 +317,3 @@ export function inlineStyles(html: string): string {
       .join(" ");
   });
 }
-
-/**
- * Class-only markup → the AMP surface's markup.
- *
- * The mirror of `inlineStyles`, and the reason both exist: that one resolves the
- * surfaces' disagreement about STYLE, this one their disagreement about TAGS. AMP
- * keeps the classes (its stylesheet is what needs them), so all this has to do is
- * the one structural swap the surfaces cannot share.
- *
- * `<img>` → `<amp-img>`, which AMP requires and which needs explicit dimensions to
- * reserve layout before the image loads. `../../content.ts` makes them optional,
- * because a channel that can measure an image should not be told — so when they
- * are absent this surface CANNOT draw the image, and says the `alt` text instead.
- * That is a degradation, not a lie: `alt` is required exactly so a channel with
- * nothing else has something to say, and the html surface still draws the picture.
- *
- * This does not contradict `supports("heroImage") === true` — `../../renderer.ts`
- * puts `supports` on the RENDERER, and AMP is one of the email renderer's surfaces,
- * not a renderer. Email can depict a hero image. One of its three MIME parts is
- * plain text, which cannot, and that has never made the claim false.
- */
-export function ampify(html: string): string {
-  return html.replace(/<img ([^>]*)>/g, (_match, attrs: string) => {
-    const sized = /\bwidth="\d+"/.test(attrs) && /\bheight="\d+"/.test(attrs);
-    if (sized) return `<amp-img ${attrs} layout="intrinsic"></amp-img>`;
-    const alt = /\balt="([^"]*)"/.exec(attrs)?.[1] ?? "";
-    // Carry the image's own spacing over to the paragraph replacing it, so the
-    // gap below it does not change with the fallback.
-    const spacing = /\bcsr-hero-(\w+)\b/.exec(attrs)?.[1] ?? "normal";
-    return `<p class="${RECIPE_PREFIX}p-${spacing}">${alt}</p>`;
-  });
-}
-
-/**
- * Every recipe as a rule, for `<style amp-custom>`.
- *
- * ALL of them, always — not just the ones this email happens to use. Emitting the
- * used subset would make the stylesheet a function of the content, so two emails
- * would carry two different stylesheets and the snapshot would stop being a
- * statement about the channel. ~40 rules is about 4KB against AMP's 75,000-byte
- * budget, which `__tests__/amp.test.ts` holds us to.
- */
-export const AMP_RECIPE_RULES = STYLE_NAMES.map(ruleOf).join("\n");