harness.config.json (1)

5-5: ⚡ Quick win

Verify remaining headroom against the new limit.

The limit has now been raised twice (60 hard default → 70 → 80). The gate's value as a regression guard depends on how tightly it tracks the actual count. If the build already lands at, e.g., 78–79 chunks, the next incremental change will trip it again. Knowing the exact post-build count (and baking it + a small buffer into the comment or a reason field here) would make future bumps more deliberate.

Run the following after a local pnpm build to see the real count and remaining headroom:

#!/bin/bash
# Description: Count .js chunks in the frontend build output and compare against the configured limit.
# Expects the frontend dist/assets directory to exist after a build.

ASSETS_DIR=$(fd -t d "assets" --search-path . | head -n 1)
if [ -z "$ASSETS_DIR" ]; then
  echo "Could not locate an assets directory. Run pnpm build first."
  exit 1
fi

COUNT=$(find "$ASSETS_DIR" -maxdepth 1 -name "*.js" -type f | wc -l)
LIMIT=$(python3 -c "import json,sys; print(json.load(open('harness.config.json'))['frontend']['chunkBudgets']['maxChunkCount'])")

echo "Actual JS chunk count : $COUNT"
echo "Configured limit      : $LIMIT"
echo "Remaining headroom    : $((LIMIT - COUNT))"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@harness.config.json` at line 5, Update the harness.config.json
frontend.chunkBudgets.maxChunkCount entry to include a documented reason and
realistic headroom: run a local pnpm build, count the produced .js chunks
(frontend assets) and record the measured count plus a small buffer in a new
"reason" field next to "maxChunkCount" (or in a comment in the file metadata if
comments are supported); ensure the value of maxChunkCount (currently 80) is set
to that measured count plus buffer so the gate has intentional headroom and
include the exact measured count and chosen buffer in the reason for future
reviewers.

packages/frontend/src/app/home/primitives/feature-glyph.tsx (1)

1-1: 💤 Low value

Consider exporting GlyphKind for downstream type safety.

GlyphKind is used in the exported component's prop but is not itself exported. Consumers that want to type their feature data arrays — like features-section.tsx — must use React.ComponentProps<typeof FeatureGlyph>['kind'] instead of the more readable GlyphKind.

♻️ One-word fix

-type GlyphKind = "reactive" | "formulas" | "embed" | "sync" | "io";
+export type GlyphKind = "reactive" | "formulas" | "embed" | "sync" | "io";

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/frontend/src/app/home/primitives/feature-glyph.tsx` at line 1, The
type alias GlyphKind is currently internal but used in the exported FeatureGlyph
props; export it so downstream consumers can import GlyphKind for typing instead
of deriving it via ComponentProps. Modify the declaration of GlyphKind (the type
alias named GlyphKind) to be exported (e.g., export type GlyphKind = ...) and
update any index/re-export barrels if this file's types are re-exported
elsewhere so consumers like features-section.tsx can import GlyphKind directly.

packages/frontend/src/app/home/primitives/ruler-backdrop.tsx (1)

28-113: ⚡ Quick win

Hardcoded SVG id will collide if two RulerBackdrop instances appear in the same document.

id="wb-ruler-pat" is a global DOM identifier. Although the two current call sites (hero-section.tsx and login/page.tsx) are on separate routes, a second instance in the same document (e.g., added to a shared layout or a multi-section page) would cause both fill="url(#wb-ruler-pat)" references to resolve against whichever <pattern> the browser encounters first, potentially applying the wrong tile dimensions. Use useId() (React 18+, available in this project's React 19 baseline) to generate a per-instance unique ID.

🔧 Proposed fix

-import { cn } from "@/lib/utils";
+import { useId } from "react";
+import { cn } from "@/lib/utils";

 export function RulerBackdrop({ className }: RulerBackdropProps) {
+  const patternId = useId();
   return (
     <div
       ...
     >
       <svg width="100%" height="100%">
         <defs>
           <pattern
-            id="wb-ruler-pat"
+            id={patternId}
             ...
           >
             ...
           </pattern>
         </defs>
-        <rect width="100%" height="100%" fill="url(`#wb-ruler-pat`)" />
+        <rect width="100%" height="100%" fill={`url(#${patternId})`} />

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/frontend/src/app/home/primitives/ruler-backdrop.tsx` around lines 28
- 113, Replace the hardcoded SVG id "wb-ruler-pat" with a per-instance unique id
using React's useId(); inside the RulerBackdrop component (function
RulerBackdrop) call useId(), build a patternId (e.g., `${id}-wb-ruler-pat`), set
the <pattern id={patternId}> and update every reference to that id (the rect
fill="url(#...)" and any other url(...) usages) to use the generated id string;
also add the import for useId from 'react' if missing.

packages/frontend/src/components/login-form.tsx (1)

3-3: 💤 Low value

WbButton is used outside app/home/ — consider relocating it to src/components/.

login-form.tsx lives in src/components/ (shared layer) but imports from src/app/home/primitives/ (page layer). Now that WbButton is consumed by a non-homepage route, it effectively belongs in the shared components layer alongside other design-system primitives.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/frontend/src/components/login-form.tsx` at line 3, WbButton is a
design primitive imported from app/home/primitives into a shared component
(login-form.tsx); move the WbButton component file (identified as WbButton) from
app/home/primitives into the shared components directory (e.g., src/components/
or the existing design-system primitives folder), update its module export if
needed, then update all imports that reference app/home/primitives/WbButton
(including in login-form.tsx) to the new shared path so the primitive is
accessible from non-page code.

packages/frontend/src/app/home/developer-section.tsx (1)

197-240: ⚡ Quick win

Missing ARIA tab pattern degrades screen-reader navigation.

The tab strip and code panel have no semantic tab role structure. Screen readers will announce them as plain buttons with no indication that they control the panel below.

♿ Proposed fix — add ARIA tab roles

  <div
-   className="flex items-center px-2 border-b"
+   role="tablist"
+   aria-label="Developer API examples"
+   className="flex items-center px-2 border-b"
    style={{ ... }}
  >
    {TABS.map((t) => (
      <button
        key={t.key}
        type="button"
+       role="tab"
+       id={`tab-${t.key}`}
+       aria-selected={tab === t.key}
+       aria-controls={`panel-${t.key}`}
        onClick={() => setTab(t.key)}
        ...
      >

- <pre className="m-0 px-6 md:px-8 py-7 overflow-x-auto font-code text-[14px] leading-7 whitespace-pre">
+ <pre
+   role="tabpanel"
+   id={`panel-${active.key}`}
+   aria-labelledby={`tab-${active.key}`}
+   className="m-0 px-6 md:px-8 py-7 overflow-x-auto font-code text-[14px] leading-7 whitespace-pre"
+ >

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/frontend/src/app/home/developer-section.tsx` around lines 197 - 240,
The tab strip and code panel need ARIA tab pattern markup: wrap the TABS.map
container div with role="tablist" (preserving its classes), render each button
(the one using key t.key, onClick setTab and checking tab === t.key) with
role="tab", an id like `tab-${t.key}`, aria-selected set to (tab === t.key),
aria-controls pointing to a matching panel id `panel-${t.key}`, and include
keyboard focusability as needed; then mark the code container (the pre that
renders highlightCode(active.code)) as role="tabpanel" with id
`panel-${active.key}` and aria-labelledby pointing to `tab-${active.key}`, and
set hidden (or aria-hidden) when it is not the active panel to ensure screen
readers know which tab is active.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

packages/frontend/src/index.css (1)

52-54: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Stylelint value-keyword-case errors on font-family names remain unresolved.

Georgia, SFMono-Regular, and Menlo are font-family names, not CSS keywords, so the errors are false positives — but they are still reported as [error] by stylelint and will break a lint gate. Adding inline disable/enable comments around the affected declarations is the standard suppression approach.

✏️ Proposed fix

+  /* stylelint-disable value-keyword-case */
   --font-display: "Fraunces", ui-serif, Georgia, serif;
   --font-body: "Inter", ui-sans-serif, system-ui, sans-serif;
   --font-code: "JetBrains Mono", ui-monospace, SFMono-Regular, Menlo, monospace;
+  /* stylelint-enable value-keyword-case */

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/frontend/src/index.css` around lines 52 - 54, The stylelint false
positives for font-family names are coming from the CSS custom properties
--font-display, --font-body, and --font-code in index.css; wrap those specific
declarations with inline stylelint suppression comments to disable and then
re-enable the value-keyword-case rule (i.e., add a /* stylelint-disable
value-keyword-case */ immediately before the three --font-... declarations and a
matching /* stylelint-enable value-keyword-case */ immediately after) so linting
ignores these font-family identifiers while leaving the rest of the file
checked.

packages/frontend/src/app/home/developer-section.tsx (1)

211-240: ⚡ Quick win

Arrow key navigation missing from the role="tablist" — the roving tabindex pattern is only half-implemented.

The tabIndex values are correctly set (0 for active, -1 for inactive), but without an onKeyDown handler for ArrowRight/ArrowLeft, keyboard users cannot cycle between tabs using the arrow keys. The WAI-ARIA Tab Panel pattern requires this. Instead they'd have to Tab out and back in, which breaks expected tab-widget behavior.

♻️ Proposed addition

Add a shared handler and pass it to each tab button:

+  const handleTabKeyDown = (e: React.KeyboardEvent, currentKey: TabKey) => {
+    const idx = TABS.findIndex((t) => t.key === currentKey);
+    let next: typeof TABS[number] | undefined;
+    if (e.key === "ArrowRight") next = TABS[(idx + 1) % TABS.length];
+    if (e.key === "ArrowLeft")  next = TABS[(idx - 1 + TABS.length) % TABS.length];
+    if (next) {
+      setTab(next.key);
+      // Move DOM focus to the newly active tab button
+      document.getElementById(`dev-tab-${next.key}`)?.focus();
+    }
+  };

  {TABS.map((t) => (
    <button
      key={t.key}
      type="button"
      role="tab"
      id={`dev-tab-${t.key}`}
      aria-selected={tab === t.key}
      aria-controls={`dev-panel-${t.key}`}
      tabIndex={tab === t.key ? 0 : -1}
      onClick={() => setTab(t.key)}
+     onKeyDown={(e) => handleTabKeyDown(e, t.key)}
      className={...}
    >

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/frontend/src/app/home/developer-section.tsx` around lines 211 - 240,
The tablist is missing ArrowLeft/ArrowRight keyboard support; implement an
onKeyDown handler (e.g., handleTabKeyDown) that listens for ArrowRight and
ArrowLeft, computes the next/previous index within TABS (wrapping at ends),
calls setTab(TABS[newIndex].key) and moves focus to the corresponding button
(use the button ids like `dev-tab-${key}` or refs), and attach this handler to
each tab button (the elements using role="tab" and tabIndex logic). Ensure the
handler prevents default for arrow keys and preserves the existing
aria-selected/tabIndex behavior so keyboard users can rove focus correctly.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes