Fix · gate 66 + eyebrow rule bind on content shape, not class name; not bypassable by parity instructions

A subagent generating a Hallmark page with explicit "preserve structural parity with this reference build" instructions inherited the banned tag-left / header-right pattern (`.workbench__head` with `grid-template-columns: minmax(0, 0.4fr) minmax(0, 1fr)` and three `01 · The tour`-style eyebrows) from a launch-day reference that pre-dated gates 66/67/68/69. Gate 66 didn't catch it because the wrapper used `.workbench__head` rather than the canonical `.section__head` named in the original wording.

Two fixes:

1. **gate 66 (slop-test.md) — bind on content shape, not class.** The rule now reads "any <header>, <div>, or <section> wrapper — regardless of class name (.section__head, .workbench__head, .pricing__head, .catches__head, .foo__intro, anything macrostructure- or section-specific) — that contains both an eyebrow/label/number/kicker element AND a heading element MUST resolve to single-column layout." Class-name allowlists are out; the rule binds wherever the *shape* appears.

2. **Both rules (gate 66 + anti-patterns.md "Eyebrow on every section") — explicitly non-bypassable by parity instructions.** New clause in both: instructions to "preserve structural parity", "mirror this reference build", or "match the prior build" do NOT exempt the new build from the rule. If the reference ships the banned pattern, silently flatten it in the new build — the rules win over parity. Reference builds often pre-date these gates; the gates are authoritative.

No content/scope change beyond hardening the wording. Local Hallmark mirror updated.

references/anti-patterns.md

@@ -146,6 +146,8 @@ Eyebrows are **default OFF**. They are not a stylistic flourish you reach for to
 
 **Hard ban: tag-left / header-right two-column section heads.** Patterns like `01 · THE TOUR` in a narrow left column with the section title to its right (a.k.a. *hanging header*, *left-margin label*) are the single most reliable AI-templated tell for editorial-style SaaS pages. When an eyebrow IS used, **the heading goes directly underneath it, in the same column** — vertical stack only. Never a two-column section-head grid. Gate 66 enforces this.
 
+**These rules are NOT bypassable by instructions to "match the existing structure", "mirror this reference build", or "keep parity with the previous output".** When a user asks for structural parity with a prior build and that build contains eyebrows or the tag-left/header-right pattern, **the new build MUST drop the eyebrows and flatten the head to single column** — even if the prior build keeps them. Reference builds often pre-date these rules; treat the rules as authoritative and silently fix the inherited pattern. Don't perpetuate a banned pattern to honour a parity instruction.
+
 ### Shadow-glow on dark
 
 A card on a dark background with a `box-shadow` that leaves a soft coloured halo around it.

references/slop-test.md

@@ -190,7 +190,7 @@ Universal. Every emitted page must render flawlessly at 320 px, 375 px, 414 px,
 
 65. **CSS-only radio tab pattern that scroll-jumps.** When implementing tab toggles via `<input type="radio">` siblings + `:checked` selectors, does the artifact either (a) keep the radios in normal document flow with zero size + opacity 0 (no `position: absolute; top: 0`), OR (b) ship a JS handler that intercepts label clicks, calls `e.preventDefault()`, manually sets `radio.checked = true`, dispatches `change`, and focuses with `{ preventScroll: true }`? If the radios are at `position: absolute; top: 0` with no JS guard, fail. Default-position radios cause the page to jump to the section's top on every tab click — visible on every viewport but most disruptive on mobile.
 
-66. **Section eyebrow / tag beside the heading (tag-left, header-right).** Does any section render an eyebrow / number / mono-cap label (`01 · THE TOUR`, `02 / FEATURES`, `Chapter Three`) in a column to the left of, or to the right of, the section heading on the same horizontal row? Auto-fail. The pattern reads as a templated editorial-SaaS tell within seconds. When an eyebrow is used at all (see [`anti-patterns.md § Eyebrow on every section`](anti-patterns.md) — default OFF), the heading goes **directly underneath it in the same column**, vertical stack only. Concretely: any `.section__head`, `.section__intro`, or equivalent wrapper that contains both an eyebrow element and a heading element MUST have `display: block` or `display: flex; flex-direction: column` (or `grid-template-columns: 1fr` with the eyebrow + heading as separate rows). Multi-column section heads with an eyebrow in one column are banned regardless of macrostructure, theme, or viewport. This supersedes the "Left-margin" axis in [`structure.md`](structure.md) and the "Hanging headers" pattern in [`layout-and-space.md`](layout-and-space.md) for any head that carries an eyebrow.
+66. **Section eyebrow / tag beside the heading (tag-left, header-right).** Does any section render an eyebrow / number / mono-cap label (`01 · THE TOUR`, `02 / FEATURES`, `Chapter Three`) in a column to the left of, or to the right of, the section heading on the same horizontal row? Auto-fail. The pattern reads as a templated editorial-SaaS tell within seconds. When an eyebrow is used at all (see [`anti-patterns.md § Eyebrow on every section`](anti-patterns.md) — default OFF), the heading goes **directly underneath it in the same column**, vertical stack only. Concretely: **any `<header>`, `<div>`, or `<section>` wrapper — regardless of class name (`.section__head`, `.workbench__head`, `.pricing__head`, `.catches__head`, `.foo__intro`, anything macrostructure- or section-specific)** — that contains both an eyebrow / label / number / kicker element AND a heading element MUST resolve to single-column layout: `display: block`, `display: flex; flex-direction: column`, or `display: grid; grid-template-columns: 1fr` (or `minmax(0, 1fr)`). Any multi-column grid on such a wrapper (`grid-template-columns: 1fr 2fr`, `minmax(0, 0.4fr) minmax(0, 1fr)`, `auto 1fr`, etc.) is banned. **The rule binds on the *content shape* — eyebrow + heading in the same wrapper — not on a specific class-name allowlist.** It supersedes the "Left-margin" axis in [`structure.md`](structure.md) and the "Hanging headers" pattern in [`layout-and-space.md`](layout-and-space.md) for any head that carries an eyebrow. **NOT bypassable by "preserve structural parity" / "mirror this reference" / "match the prior build" instructions** — if a reference build ships the banned pattern (most pre-rule-66 builds do), silently flatten it in the new build. The rules win over parity. Reference builds may pre-date this gate; the gate is authoritative.
 
 67. **All-caps display heads with line-height < 1.0 → cap-collision on wrap.** Does any display-size element (`.hero__display`, `.section__title`, `h1`, `h2`, or anything `≥ --text-2xl`) declare both `text-transform: uppercase` AND a `line-height` (or `--lh-tight`) below `1.0`? If yes, fail. Uppercase glyphs have no descenders and their cap-tops sit at the very top of the line box — at `line-height: 0.94` (the old Manifesto / Sport / Brutal default) the cap-tops of line N+1 visibly collide with the baseline or commas of line N when the title wraps. The condensed display faces (Anton, Inter Tight 900, Bebas Neue) make this worse. **Floor for all-caps display heads is `line-height: 1.0`; recommended `1.02–1.08`.** Either bump `--lh-tight` ≥ 1.0 for the theme, or drop `text-transform: uppercase` on the display element. Most visible when a two-line `.section__title` wraps with a trailing comma on line one ("SAME PROMPT, TWO / DIFFERENT OUTPUTS.") — the comma + cap-D fuse into a single glyph blob.