What Type of UI Chrome Does Hallmark Reject? Re‑Drawn Chrome Explained

Hallmark rejects any “re‑drawn” UI chrome—hand‑crafted HTML, CSS, or SVG imitations of native browser, operating‑system, device, or IDE chrome—and enforces this via Slop‑Test gate 47.

The Nutlope/hallmark design system explicitly forbids re‑drawn UI chrome from appearing in its projects. Instead of fabricating browser bars, phone frames, or IDE window dressing with code, Hallmark requires real screenshots or no chrome at all. This architectural rule is codified in the “Re‑drawn UI chrome” anti‑pattern and enforced automatically during the build pipeline.

Types of UI Chrome Hallmark Rejects

According to references/anti-patterns.md, Hallmark identifies four specific categories of re‑drawn chrome as strong signals of AI‑generated content. Because a user already owns real browser, device, and IDE chrome, any page‑level imitation is both visually inaccurate and architecturally unnecessary.

Fake Browser Bars

These are DOM‑constructed address bars that include a URL pill and traffic‑light dots. Hallmark treats these as prohibited re‑drawn UI chrome because they attempt to mimic the native browser shell inside the browser itself.

Fake Phone Frames

Rounded rectangles with notches and speaker slits wrapped around mobile mock‑ups constitute re‑drawn device chrome. Hallmark refuses these frames in favor of unadorned screenshots that show the actual device boundary.

Fake Code‑Block Windows

Mock title bars with close, minimize, and maximize dots wrapped around <pre> elements are forbidden. These fabricate an OS window where none exists, violating the anti‑pattern defined in references/anti-patterns.md.

Fake IDE Chrome

File tabs, activity bars, and sidebars drawn around editor screenshots are rejected. Adding counterfeit IDE chrome distracts from the content and introduces visual inaccuracies.

Why Hallmark Rejects Re‑Drawn Chrome

The design system’s refusal is grounded in four architectural principles, documented in the refusal heuristics in references/study.md and the anti‑pattern reference files.

1. Authenticity – Real screenshots preserve the exact look of the user’s environment, avoiding mismatched UI elements such as wrong URLs or incorrect OS‑specific controls.

2. Consistency – By relying on existing chrome, Hallmark maintains a clean visual hierarchy where the page’s content, not a fabricated frame, becomes the focal point.

3. Accessibility – Native browser and OS chrome already provides built‑in accessibility features like focus outlines and keyboard navigation. Custom‑drawn chrome often neglects these, degrading the experience.

4. Performance – Eliminating extra DOM and CSS for faux chrome reduces layout shift and paint work, improving load times and Core Web Vitals.

Code Examples: Correct vs. Incorrect Implementation

✅ Correct: Real Screenshot Wrapped in <figure>

<figure class="hero-screenshot">
  <img src="screenshots/product-dashboard.png"
       alt="Dashboard UI – live screenshot"
       loading="lazy">
  <figcaption>Our dashboard in the browser.</figcaption>
</figure>

No custom chrome is added; the image shows the actual browser window.

❌ Incorrect: Fake Browser Chrome

<div class="mock-browser">
  <header class="mock__chrome"><span></span><span></span><span></span></header>
  <img src="screenshots/product-dashboard.png" alt="Dashboard UI">
</div>

The <header class="mock__chrome"> draws a fictitious address bar, violating gate 47.

✅ Minimal Hairline Border (Allowed)

figure.hero-screenshot {
  border: 1px solid var(--color-rule);
}

A subtle hairline border is permissible; it does not constitute re‑drawn chrome.

Enforcement in the Hallmark Pipeline

Hallmark does not merely document this rule; it automates detection. The Slop‑Test gate 47 defined in references/slop-test.md fails the build when re‑drawn UI chrome is detected. Early‑stage refusal heuristics in references/study.md scan for these violations before final rendering, and SKILL.md summarizes the prohibition under “Re‑drawn chrome forbidden” with pointers back to the authoritative anti‑pattern reference. When the pipeline encounters counterfeit browser bars, phone frames, code‑block windows, or IDE chrome, it treats them as structural defects and halts progression until they are removed or replaced with real screenshots.

Summary

• Hallmark rejects re‑drawn UI chrome: any HTML, CSS, or SVG imitation of native browser, OS, device, or IDE shells.
• Prohibited patterns include fake browser bars, fake phone frames, fake code‑block windows, and fake IDE chrome.
• Real screenshots wrapped in a <figure> with at most a hairline border are the required alternative.
• Enforcement is handled by Slop‑Test gate 47, refusal heuristics in references/study.md, and the anti‑pattern specification in references/anti-patterns.md.

Frequently Asked Questions

Does Hallmark allow any borders around screenshots?

Yes. Hallmark permits a minimal hairline border, such as 1px solid var(--color-rule) on a <figure>, because this does not imitate functional UI chrome. It is purely decorative and does not draw address bars, buttons, or device frames.

Why does Hallmark treat re‑drawn chrome as a signal of AI‑generated content?

Re‑drawn chrome is considered a strong indicator of AI‑generated output because it serves no functional purpose for the end user, who already has real browser, OS, and IDE chrome. Fabricating these elements is visually inaccurate and architecturally unnecessary, making it a reliable marker of low‑value slop.

Where is the re‑drawn UI chrome rule defined in the Hallmark repository?

The rule is defined in references/anti-patterns.md under the section “Re‑drawn UI chrome,” enforced by references/slop-test.md at gate 47, summarized in SKILL.md, and supported by refusal heuristics in references/study.md.

What happens if re‑drawn chrome is detected during the build?

The Hallmark pipeline fails the build. Slop‑Test gate 47 triggers a refusal, and the heuristics in references/study.md block progression until the counterfeit chrome is removed and replaced with a real screenshot or eliminated entirely.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}