Deploy v11.7.0

.all-contributorsrc

@@ -14240,6 +14240,52 @@
       "contributions": [
         "maintenance"
       ]
+    },
+    {
+      "login": "kafeelraza",
+      "name": "kafeelraza",
+      "avatar_url": "https://avatars.githubusercontent.com/u/193384171?v=4",
+      "profile": "https://github.com/kafeelraza",
+      "contributions": [
+        "code",
+        "tool"
+      ]
+    },
+    {
+      "login": "akegaviar",
+      "name": "Ake",
+      "avatar_url": "https://avatars.githubusercontent.com/u/10195782?v=4",
+      "profile": "https://ake.gg",
+      "contributions": [
+        "tool"
+      ]
+    },
+    {
+      "login": "escottalexander",
+      "name": "Elliott Alexander",
+      "avatar_url": "https://avatars.githubusercontent.com/u/22101475?v=4",
+      "profile": "https://github.com/escottalexander",
+      "contributions": [
+        "tutorial"
+      ]
+    },
+    {
+      "login": "Emgevorgyan",
+      "name": "Emgevorgyan",
+      "avatar_url": "https://avatars.githubusercontent.com/u/26285829?v=4",
+      "profile": "https://github.com/Emgevorgyan",
+      "contributions": [
+        "tool"
+      ]
+    },
+    {
+      "login": "ricardo-jtg",
+      "name": "Ricardo Gonçalves",
+      "avatar_url": "https://avatars.githubusercontent.com/u/35004742?v=4",
+      "profile": "https://github.com/ricardo-jtg",
+      "contributions": [
+        "tool"
+      ]
     }
   ],
   "contributorsPerLine": 7,

.claude/commands/review-release.md

@@ -1,20 +1,23 @@
 ---
 description: Review a release/deploy PR by checking key changes on staging with a browser
-allowed-tools: Bash, Read, Glob, Grep, Agent, Skill, AskUserQuestion
-argument-hints: [<pr-number> (auto-detects latest deploy PR)]
+allowed-tools: Bash, Read, Glob, Grep, Agent, Skill
+argument-hints: [<pr-number>] [--post-comment]
 ---
 
 # Review Release
 
 Review a release/deploy PR by fetching its description, identifying the most important changes, and verifying them on the staging deploy using the browser.
 
-## Arguments
+This command NEVER approves or requests changes on the PR. By default it only prints the summary in the terminal. Pass `--post-comment` to additionally post the summary as a comment on the PR (informational, not a review).
 
-`$ARGUMENTS` may contain the PR number to review. If empty, auto-detect the latest deploy PR:
+## Arguments
 
-```bash
-gh pr list -B master -H staging -s open -S "Deploy" --json number -q ".[0].number" -L 1
-```
+`$ARGUMENTS` may contain:
+- A PR number to review. If omitted, auto-detect the latest deploy PR:
+  ```bash
+  gh pr list -B master -H staging -s open -S "Deploy" --json number -q ".[0].number" -L 1
+  ```
+- `--post-comment` flag. If present, after producing the summary, post it as a PR comment via `gh pr comment`. Without this flag, the summary is only printed to the terminal.
 
 ## Workflow
 
@@ -57,24 +60,26 @@ Present a summary table with:
 |------|--------|-------|
 | Page name | Pass/Fail | What was checked and confirmed |
 
-Flag any issues found. If everything looks good, confirm the deploy is ready to ship.
+Flag any issues found. If everything looks good, note that the deploy looks ready to ship.
 
-### Step 5: Submit Review
+### Step 5: Optionally Post as PR Comment
 
-After presenting results, ask the user if they want to submit a review on the PR. Offer two options:
+If `--post-comment` was passed in `$ARGUMENTS`, post the summary table as a PR comment:
 
-1. **Approve** — if all checks passed
-2. **Request changes** — if issues were found
+```bash
+gh pr comment <PR_NUMBER> --repo ethereum/ethereum-org-website --body "$(cat <<'EOF'
+## /review-release summary
 
-Ask the user which action to take (or skip). If they choose to submit, post the summary table as the review body using:
+<summary table here>
 
-```bash
-gh pr review <PR_NUMBER> --repo ethereum/ethereum-org-website --approve --body "..."
-# or
-gh pr review <PR_NUMBER> --repo ethereum/ethereum-org-website --request-changes --body "..."
+_Informational only — this is not a PR review. Approval and merge remain manual._
+EOF
+)"
 ```
 
-Do NOT submit a review without explicit user confirmation.
+If `--post-comment` is NOT present, do nothing further — the terminal output is the only artifact.
+
+This command must NEVER call `gh pr review --approve` or `gh pr review --request-changes`. Approval and merge stay with humans.
 
 ## Tips
 

.claude/skills/design-system/SKILL.md

@@ -32,6 +32,7 @@ When the existing primitive doesn't quite fit, the answer is usually "add a vari
 8. **`useRtlFlip()` for directional icons** (right-pointing arrows/chevrons). Or use `ChevronNext`/`ChevronPrev` from `@/components/Chevron`.
 9. **Markdown content goes through `MdComponents`.** The legacy `@/components/Card` (default export) is reserved for markdown shortcodes -- never import it from app code; use `@/components/ui/card`.
 10. **Storybook stories ship with new UI components.** No automated unit tests; Storybook + Chromatic + types are the verification layer.
+11. **Don't add new layouts.** There are six canonical layouts (`TopicLayout`, `StaticLayout`, `DocsLayout`, `TutorialLayout`, `ContentLayout`, `BaseLayout`). New sectioned content goes in `src/data/topics/<key>.ts` as a `TopicLayout` config -- not a new layout component. See `references/layouts.md`.
 
 ## Highest-Value Gotchas (read these now)
 
@@ -80,7 +81,7 @@ Don't add more. Use `numberFormat()`.
 | Anchor (CTA with arrow) | `import { LinkWithArrow } from "@/components/ui/Link"` |
 | Page hero | `import { ContentHero, SimpleHero, HubHero, MdxHero } from "@/components/Hero"` |
 | Inline alert | `import { Alert, AlertContent, AlertDescription } from "@/components/ui/alert"` |
-| Top-of-page banner | `import BannerNotification from "@/components/Banners/BannerNotification"` |
+| Top-of-page banner | `import { Alert } from "@/components/ui/alert"` then `<Alert variant="banner">` |
 | Big numeric display | `import BigNumber from "@/components/BigNumber"` |
 | Layout | `import { Stack, HStack, VStack, Flex, Center } from "@/components/ui/flex"` |
 | Number formatting | `import { numberFormat } from "@/lib/utils/numbers"` |
@@ -105,6 +106,7 @@ Pull these in only when the trigger applies. Don't read them all upfront.
 - **`references/a11y.md`** -- Load when adding interactive elements (modals, dropdowns, custom click targets), building forms, or working with images and headings.
 - **`references/card-walkthrough.md`** -- Load when starting any card-shaped UI work; an end-to-end worked example.
 - **`references/page-hero-walkthrough.md`** -- Load when starting a new page that needs a hero; an end-to-end worked example.
+- **`references/layouts.md`** -- Load when you're tempted to create a new layout, when adding a new topic-hub section, or when refactoring a one-off `src/layouts/md/<Section>Layout` file. The canonical inventory plus the rule that new layouts are very rare.
 - **`references/new-component-checklist.md`** -- Load before opening a PR for a new component. The pre-merge checklist.
 
 ## Other Project Skills That May Apply

.claude/skills/design-system/references/a11y.md

@@ -33,7 +33,11 @@ Without it, screen readers announce nothing meaningful for the button.
 
 ### `<aside>` is for tangentially-related content
 
-`<aside>` is being used for site-wide ribbons in `Banners/BannerNotification.tsx:15` and `TranslationBanner.tsx:57`. For announcement banners, `role="status"` (non-urgent) or `role="alert"` (urgent) is more appropriate.
+`<aside>` is the right element for content that sits beside the main flow -- top-of-page ribbons, side callouts, supplementary explainers. In this codebase that includes `UpgradeStatus`, `CalloutBanner`/`CalloutSSR`, `CallToContribute`, `StakingHierarchy`, `TranslationBanner`, and `<Alert variant="banner">`. None of these should be `<section>` or `<article>`.
+
+What `<aside>` does NOT imply is a live-region role. If the content is announced dynamically (form result, async status change), pair the `<aside>` with `role="status"` (polite) or `role="alert"` (assertive). Static editorial banners can stay role-less and shouldn't announce on page load.
+
+`<Alert variant="banner">` is the canonical pattern for "tangential ribbon that may need to announce" -- it already renders `<aside>` and accepts `role` as a plain HTML pass-through. `TranslationBanner/index.tsx:56` still rolls its own `<aside>`; if you touch it, prefer migrating to `<Alert variant="banner">` to inherit the pattern.
 
 ### Image `alt` text
 
@@ -85,6 +89,18 @@ For dynamic content that should be announced:
 <div role="alert" aria-live="assertive">{urgentMessage}</div>  // Urgent: "Error"
 ```
 
+`role="status"` and `role="alert"` carry implicit `aria-live` and `aria-atomic` values, so the explicit `aria-live` is usually redundant.
+
+When the announcement lives inside an `Alert`, pass the role directly -- it's a plain HTML pass-through, no custom prop:
+
+```tsx
+<Alert variant="warning" role="status">
+  <AlertContent>{t("no-results")}</AlertContent>
+</Alert>
+```
+
+The `Alert` primitive intentionally applies **no** ARIA role by default -- variant names like `error`/`warning` are visual emphasis on this editorial site, not runtime UI state. Opt in only when the alert is genuinely dynamic. See the `Alert` entry in `references/components.md`.
+
 ## One `<h1>` Per Page
 
 `MdxHero` and `HubHero` both render `<h1>`. Most React-page heroes do. Most markdown layouts also auto-render the page `title` from frontmatter as the `<h1>`.

.claude/skills/design-system/references/canonical-imports.md

@@ -185,22 +185,49 @@ import PageHero from "@/components/PageHero"
 
 ## Banners / Callouts / Alerts
 
-### Inline message in content area: `Alert`
+### Inline notice AND top-of-page ribbon: `Alert`
 
 ```tsx
 import { Alert, AlertContent, AlertDescription } from "@/components/ui/alert"
 ```
 
-Variants: `info | error | success | warning | update`. Optional `size: "full"` for borderless full-width.
+One primitive covers both shapes via `variant`:
 
-### In-content / top-of-page callout: `Callout`
+| Use case | Variant |
+|---|---|
+| In-prose notice | `info` `error` `success` `warning` `update` |
+| Full-bleed top-of-page ribbon (white-on-primary) | `banner` |
+
+```tsx
+// Top-of-page ribbon:
+<Alert variant="banner">{t("page-roadmap-banner-notification")}</Alert>
+
+// In-content warning:
+<Alert variant="warning">
+  <AlertContent>
+    <AlertDescription>{t("warning-text")}</AlertDescription>
+  </AlertContent>
+</Alert>
+```
+
+`variant="banner"` renders `<aside>` (tangential to main content); other variants render `<div>`. No ARIA role by default -- pass `role="status"` for polite dynamic announcements (e.g. filter result counts) or `role="alert"` for genuine assertive errors. See `references/components.md` for the full parts inventory.
+
+### Do NOT import `BannerNotification`
+
+```tsx
+// DON'T -- file deleted May 2026:
+import BannerNotification from "@/components/Banners/BannerNotification"
+```
+
+The `Banners/` subdirectory is gone. Use `<Alert variant="banner">` for top-of-page ribbons.
+
+### Card-shaped in-content callouts: `Callout` family
 
-> **Migration in progress.** A unified server-renderable `Callout` component is being built that absorbs the current `Callout`/`CalloutSSR`/`CalloutBanner`/`CalloutBannerSSR`/`BannerNotification`/`DismissableBanner` set into a single primitive with variants. Tracked in a dedicated issue.
+> **Migration in progress.** A unified server-renderable `Callout` component is being built to absorb `Callout`/`CalloutSSR`/`CalloutBanner`/`CalloutBannerSSR`/`DismissableBanner` into a single primitive with variants. (`BannerNotification` was previously on this list but was absorbed into `Alert` as `variant="banner"` ahead of the broader consolidation.) Tracked in a dedicated issue.
 
 Until the unified `Callout` lands:
 - For **in-content** callouts with image + heading: use `CalloutBannerSSR` (NOT `CalloutBanner.tsx`). Server-renderable; uses `cva` with `large | medium | small` sizes.
 - For **big ornamental section dividers** with image overlap: use `CalloutSSR` (NOT `Callout.tsx`). Server-renderable.
-- For **top-of-page site-wide stripes**: use `BannerNotification` (`@/components/Banners/BannerNotification`). Will be absorbed as a `notification` variant on the unified `Callout`.
 - Avoid `Callout.tsx` and `CalloutBanner.tsx` (client-only thunks; superseded by their SSR siblings and ultimately by the unified component).
 
 ## Tabs / Tab Navigation

.claude/skills/design-system/references/cleanup-playbook.md

@@ -247,6 +247,53 @@ import { ContentHero } from "@/components/Hero"
 
 The shapes are different; you may need to restructure the page slightly. `PageHero` is on the deprecation track.
 
+## `BannerNotification` -> `Alert variant="banner"`
+
+```tsx
+// Before (file no longer exists -- import is broken):
+import BannerNotification from "@/components/Banners/BannerNotification"
+<BannerNotification shouldShow={isPageIncomplete}>
+  <Translation id="page-developers-docs:banner-page-incomplete" />
+</BannerNotification>
+
+// After:
+import { Alert } from "@/components/ui/alert"
+{isPageIncomplete && (
+  <Alert variant="banner">
+    <Translation id="page-developers-docs:banner-page-incomplete" />
+  </Alert>
+)}
+```
+
+`BannerNotification` was deleted in May 2026; if you find the import in stale code, this is the replacement. The `shouldShow` prop has no equivalent on `Alert` -- gate at the JSX level (`{condition && <Alert>...</Alert>}`).
+
+`BugBountyBanner` (a thin one-off wrapper around `BannerNotification`) was deleted in the same pass with no replacement file -- inline `<Alert variant="banner">` at the call site.
+
+## Inline `<strong>` lead-in inside `Alert` -> `AlertTitle` + `AlertDescription`
+
+```tsx
+// Before:
+<Alert variant="info">
+  <AlertContent>
+    <p className="mt-0"><strong>Heads up</strong></p>
+    <p className="mt-4">Some description text...</p>
+  </AlertContent>
+</Alert>
+
+// After:
+import { AlertTitle, AlertDescription } from "@/components/ui/alert"
+<Alert variant="info">
+  <AlertContent>
+    <AlertTitle>Heads up</AlertTitle>
+    <AlertDescription>
+      <p>Some description text...</p>
+    </AlertDescription>
+  </AlertContent>
+</Alert>
+```
+
+`AlertTitle` is the canonical "bold standard-font-size lead-in line" for an Alert -- use it whenever an alert needs a bold opening line. `AlertDescription` normalizes paragraph spacing internally, so no `mt-`/`mb-` classes are needed on the body paragraphs. The Alert sub-components are designed so callers don't apply manual typography or spacing inside the Alert.
+
 ## Arbitrary z-index -> named z scale
 
 ```tsx
@@ -287,3 +334,46 @@ import { Stack } from "@/components/ui/flex"
 ```
 
 (Stack already defaults to `flex-col gap-2`, so often you can drop the className entirely.)
+
+## Per-section `src/layouts/md/<Section>Layout` -> `TopicLayout` config
+
+```tsx
+// Before -- a section gets its own layout file that duplicates 90% of every other section's layout:
+// src/layouts/md/Staking.tsx
+export const StakingLayout = ({ children, frontmatter, slug, ... }) => {
+  const { t } = useTranslation("page-staking")
+  const dropdownLinks = { text: t("..."), items: [ /* ... */ ] }
+  const heroProps = { ...frontmatter, breadcrumbs: { slug, startDepth: 1 }, heroImg: { ... } }
+  return <ContentLayout dropdownLinks={dropdownLinks} heroSection={<ContentHero {...heroProps} />}>{children}</ContentLayout>
+}
+
+// After -- the data lives in a config file, no layout component needed:
+// src/data/topics/staking.ts
+import type { TopicConfig } from "."
+export const staking: TopicConfig = {
+  translationNs: "page-staking",
+  dropdown: {
+    textKey: "page-staking-dropdown-staking-options",
+    ariaLabelKey: "page-staking-dropdown-staking-options-alt",
+    matomoCategory: "Staking dropdown",
+    items: [
+      { textKey: "page-staking-dropdown-home", href: "/staking/", matomoEvent: "clicked staking home" },
+      // ...
+    ],
+  },
+  heroImage: { width: 800, height: 605 },
+}
+
+// src/layouts/index.ts
+export const layoutMapping = {
+  // ...
+  staking: TopicLayout,  // was: StakingLayout
+}
+```
+
+After the move:
+- Keep the section's MDX component bundle (`stakingComponents`) in `src/layouts/md/<key>.tsx`; only the layout export goes away.
+- Delete any per-section heading overrides (`Heading1`/`Heading2`/etc. with extra className). The defaults in `MdComponents` are the baseline.
+- If the section needs a swap-in component (HubHero on a specific slug, content after the markdown), use `config.hubHero` or the `afterContent` prop -- don't fork a new layout.
+
+See `references/layouts.md` for the full inventory and `docs/topic-layout-refactor.md` for the worked migration.