fix(landing): bento tile, mobile nav, hero acronym, visual polish

[jackgranatowski]

Summary

Follow-up fixes to the landing page draft, addressing review feedback:

• Bento featured tile looked odd: the color-ramp demo was anchored to the bottom of the 2×2-span card via margin-block-start: auto, leaving a large empty gap between the paragraph and the ramp. Added an alpha-ramp row + labels and centered the card's content as a group instead, so it fills the space.
• Header nav ugly / broken on mobile: text links wrapped into three cramped rows with oversized buttons on real mobile (confirmed with proper touch-device emulation, not just window-resizing). Split the text-link cluster from the CTA/theme-toggle cluster and drop the links below 48em instead of wrapping.
• Animated acronym shrunk on mobile: the any-hover-gated vw-based size cap could shrink the headline below the tagline on narrow hover-capable viewports, and touch devices got an unreachable hover-reveal interaction that wrapped into an ugly orphaned line ("/D" alone). Rethought for mobile: since there's no working hover affordance on touch, show the full manifesto words directly instead of hiding them behind a dead interaction. Desktop keeps the collapsed-letters hover-reveal, now sized off container-query units with a readable floor instead of raw viewport width.
• Zero oomph: subtle gradient wash behind the hero, a gradient top-edge on every card, dividers in the stats strip, a tinted band for the Philosophy section for visual rhythm — all composed from existing framework tokens (gradients, alpha colors), no raw values. Also dropped the emoji feature-card icons.

Type

• fix
• feat
• docs
• chore / tooling

Test plan

• Verified mobile layout with real device emulation (iPhone 13, any-hover: none), not just a resized desktop window
• Verified desktop hover-unfold interaction still works and fits on one line
• Verified dark mode
• Verified tablet breakpoint (~800px)

https://claude.ai/code/session_012kga5ydHSnFupfqph6vU73

[coderabbitai]

Warning

Review limit reached

@jackgranatowski, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 50 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: f80d3264-c684-4df1-9d9c-a3a2012702f7

📥 Commits

Reviewing files that changed from the base of the PR and between 5f34a8a and 09026ce.

📒 Files selected for processing (3)

• _config.yml
• copy-wip/github-pages-index.html
• copy-wip/github-readme.md

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/bento-ui-plugin-docs-865tpu

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[qodo-code-review]

PR Summary by Qodo

Stage rewritten README + landing-page drafts in copy-wip and exclude from Pages

📝 Documentation ⚙️ Configuration changes 🕐 40+ Minutes

AI Description

• Add rewritten README and landing-page draft copy under copy-wip/ for review.
• Fix stale project facts/links in the staged copy (tokens/layers, CDN/npm/plugin URLs).
• Prevent copy-wip drafts from being published by excluding copy-wip/ from the Jekyll build.

Diagram

graph TD
  A["Docs author"] --> B["copy-wip/ drafts"]
  A --> C["_config.yml"] --> D["GitHub Pages (Jekyll)"] --> E["Published site"]
  C -. "exclude copy-wip" .-> B

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Use Jekyll’s _drafts/ (or a non-rendered collection) instead of copy-wip/

• ➕ Conventional Jekyll workflow; drafts are naturally non-published
• ➕ Reduces need for explicit exclude rules and avoids accidental publication
• ➖ Requires reorganizing draft files and potentially adjusting site structure
• ➖ Drafts may be less discoverable for reviewers who browse repo folders

2. Keep drafts on a dedicated docs branch (no in-repo drafts)

• ➕ Zero risk of accidental publication on main branch
• ➕ Keeps repository tree cleaner for end users
• ➖ Harder to review alongside code changes in a single PR
• ➖ Less convenient to iterate on copy with code-adjacent context

3. Remove Jekyll front matter from drafts to prevent rendering

• ➕ No config change required; drafts won’t be treated as Jekyll pages
• ➖ Easier to accidentally reintroduce publishing later
• ➖ Loses the ability to preview drafts locally via Jekyll when desired

Recommendation: Current approach (stage in copy-wip/ and explicitly exclude it in _config.yml) is a pragmatic middle ground: reviewers can see the proposed copy in-repo while GitHub Pages is protected from publishing it. If drafts become long-lived, consider migrating to _drafts/ or a dedicated non-published collection to align with standard Jekyll conventions and reduce reliance on manual excludes.

Files changed (3) +870 / -0

Documentation (2) +869 / -0

github-pages-index.htmlAdd landing page draft rebuilt on SLASHED’s own CSS +678/-0

Add landing page draft rebuilt on SLASHED’s own CSS

• Introduces a full draft landing page (with Jekyll front matter) styled via the framework’s CDN bundle and minimal token-only overrides. Updates/embeds corrected product facts (685 tokens, 15 layers) and adds quick-start-first structure with install snippets and doc links.

copy-wip/github-pages-index.html

github-readme.mdAdd rewritten README draft emphasizing quick start and corrected facts +191/-0

Add rewritten README draft emphasizing quick start and corrected facts

• Adds a draft README with updated first-contact copy, corrected project metrics/links, and reorganized sections (quick install, philosophy, bundles, browser support, docs index). Clarifies staged layers/utilities status and updates the WordPress plugin repository link.

copy-wip/github-readme.md

Other (1) +1 / -0

_config.ymlExclude copy-wip/ from the GitHub Pages build +1/-0

Exclude copy-wip/ from the GitHub Pages build

• Adds copy-wip/ to Jekyll’s exclude list so draft pages aren’t rendered or published under the site root. This prevents accidental exposure caused by optional front matter rendering.

_config.yml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 11 rules

1. Docs rewrite not published 🐞 Bug ≡ Correctness

Description

This PR adds the rewritten landing page/README under copy-wip/ but also excludes copy-wip from
the Jekyll build, so the deployed Pages site will not include the new content. The published
homepage (index.md) therefore continues to ship stale facts (v0.6.19, 840 tokens, sixteen layers)
and the wrong npm package link.

Code

_config.yml[R8-13]

exclude:
  - node_modules
+  - copy-wip
  - configurator
  - configurator-archive
  - core

Relevance

⭐⭐⭐ High

Team fixes published Pages docs issues; Jekyll/landing updates in PR296 and broken-doc link fix
accepted in PR415.

PR-#296
PR-#415
PR-#420

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

copy-wip/ is explicitly excluded from Jekyll, and the Pages workflow builds the site via Jekyll
from the repo root; therefore the newly added copy-wip landing/README files will not appear in the
deployed _site. The existing index.md still contains the stale counts/version and the incorrect
npm link, so those remain user-visible after deployment.

_config.yml[8-18]
.github/workflows/deploy-configurator.yml[67-93]
copy-wip/github-pages-index.html[1-16]
copy-wip/github-readme.md[1-25]
index.md[123-193]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR adds updated “first-contact” copy as `copy-wip/github-pages-index.html` and `copy-wip/github-readme.md`, but `_config.yml` excludes `copy-wip` from the Jekyll build. The Pages deployment workflow builds the site via Jekyll using this config, so `copy-wip/` content will not be present in `_site/`.

As a result, `index.md` remains the deployed homepage and continues to contain stale/incorrect facts (token count, layer count, hardcoded release version, and the npm link).

## Issue Context
- GitHub Pages is built by `.github/workflows/deploy-configurator.yml` using `actions/jekyll-build-pages@v1`, which honors `_config.yml` exclusions.
- The new copy is currently only present under `copy-wip/`.

## Fix Focus Areas
- _config.yml[8-18]
- .github/workflows/deploy-configurator.yml[67-93]
- index.md[123-244]
- copy-wip/github-pages-index.html[1-40]
- copy-wip/github-readme.md[1-40]

## Suggested fix
- Move/port the rewritten landing page content into the actual published homepage (`index.md`), or otherwise update the Pages build so the new landing page is generated at `/`.
- Apply the rewritten README content to the repository’s actual `README.md` (or add an explicit build step that replaces it), instead of leaving it only in `copy-wip/`.
- If `copy-wip/` is intended to be published for review, remove it from `_config.yml` `exclude:` (or add an `include:`/copy step) and ensure the desired route is linked/served.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Unvalidated theme state 🐞 Bug ☼ Reliability

Description

github-pages-index.html loads slashed-home-theme from localStorage and, for any non-auto
value, writes it directly into <html data-theme>. If the stored value is anything other than
light/dark, the page stops matching the framework’s theme selectors (and stops following OS
scheme) until the user clicks to cycle back to a valid state.

Code

copy-wip/github-pages-index.html[R659-674]

+    (function () {
+      var btn = document.getElementById('theme-toggle');
+      var states = ['auto', 'dark', 'light'];
+      var current = 'auto';
+      try { current = localStorage.getItem('slashed-home-theme') || 'auto'; } catch (e) {}
+      function apply(state) {
+        if (state === 'auto') document.documentElement.removeAttribute('data-theme');
+        else document.documentElement.setAttribute('data-theme', state);
+        btn.textContent = state[0].toUpperCase() + state.slice(1);
+      }
+      apply(current);
+      btn.addEventListener('click', function () {
+        current = states[(states.indexOf(current) + 1) % states.length];
+        try { localStorage.setItem('slashed-home-theme', current); } catch (e) {}
+        apply(current);
+      });

Relevance

⭐⭐⭐ High

Repo repeatedly hardens/validates localStorage-persisted theme/state; accepted in PR323 (uiTheme
validation) and PR460.

PR-#323
PR-#460

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The script sets data-theme to arbitrary stored values, but the framework only defines theme
behavior for data-theme="light" and data-theme="dark" (and OS-following only when the attribute
is absent), so an unexpected value prevents correct theme activation.

copy-wip/github-pages-index.html[656-675]
core/themes.css[8-18]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The theme toggle reads a persisted string from `localStorage` and passes it into `apply()` without validating it against the supported state set. Any unexpected value causes the script to set an unsupported `data-theme` attribute value on `<html>`, preventing the framework’s `[data-theme="light"]` / `[data-theme="dark"]` selectors from applying.

## Issue Context
Framework theme switching is implemented via selectors for only `light` and `dark` values, and OS-following mode depends on the *absence* of the `data-theme` attribute.

## Fix Focus Areas
- copy-wip/github-pages-index.html[656-675]

## Suggested fix
- After reading `current` from `localStorage`, normalize it:
 - if `current` is not in `['auto','dark','light']`, set it to `'auto'`.
- Optionally guard against `btn` being null before dereferencing (`btn.textContent`, `btn.addEventListener`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

1. Docs rewrite not published 🐞 Bug ≡ Correctness

This PR adds the rewritten landing page/README under copy-wip/ but also excludes copy-wip from
the Jekyll build, so the deployed Pages site will not include the new content. The published
homepage (index.md) therefore continues to ship stale facts (v0.6.19, 840 tokens, sixteen layers)
and the wrong npm package link.

Agent Prompt

## Issue description
The PR adds updated “first-contact” copy as `copy-wip/github-pages-index.html` and `copy-wip/github-readme.md`, but `_config.yml` excludes `copy-wip` from the Jekyll build. The Pages deployment workflow builds the site via Jekyll using this config, so `copy-wip/` content will not be present in `_site/`.

As a result, `index.md` remains the deployed homepage and continues to contain stale/incorrect facts (token count, layer count, hardcoded release version, and the npm link).

## Issue Context
- GitHub Pages is built by `.github/workflows/deploy-configurator.yml` using `actions/jekyll-build-pages@v1`, which honors `_config.yml` exclusions.
- The new copy is currently only present under `copy-wip/`.

## Fix Focus Areas
- _config.yml[8-18]
- .github/workflows/deploy-configurator.yml[67-93]
- index.md[123-244]
- copy-wip/github-pages-index.html[1-40]
- copy-wip/github-readme.md[1-40]

## Suggested fix
- Move/port the rewritten landing page content into the actual published homepage (`index.md`), or otherwise update the Pages build so the new landing page is generated at `/`.
- Apply the rewritten README content to the repository’s actual `README.md` (or add an explicit build step that replaces it), instead of leaving it only in `copy-wip/`.
- If `copy-wip/` is intended to be published for review, remove it from `_config.yml` `exclude:` (or add an `include:`/copy step) and ensure the desired route is linked/served.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-code-review]

2. Unvalidated theme state 🐞 Bug ☼ Reliability

github-pages-index.html loads slashed-home-theme from localStorage and, for any non-auto
value, writes it directly into <html data-theme>. If the stored value is anything other than
light/dark, the page stops matching the framework’s theme selectors (and stops following OS
scheme) until the user clicks to cycle back to a valid state.

Agent Prompt

## Issue description
The theme toggle reads a persisted string from `localStorage` and passes it into `apply()` without validating it against the supported state set. Any unexpected value causes the script to set an unsupported `data-theme` attribute value on `<html>`, preventing the framework’s `[data-theme="light"]` / `[data-theme="dark"]` selectors from applying.

## Issue Context
Framework theme switching is implemented via selectors for only `light` and `dark` values, and OS-following mode depends on the *absence* of the `data-theme` attribute.

## Fix Focus Areas
- copy-wip/github-pages-index.html[656-675]

## Suggested fix
- After reading `current` from `localStorage`, normalize it:
  - if `current` is not in `['auto','dark','light']`, set it to `'auto'`.
- Optionally guard against `btn` being null before dereferencing (`btn.textContent`, `btn.addEventListener`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools