knowledge: frontend visual-design ingest — anti-slop methodology + HTML-in-Canvas (new design category)

[choiyounggi]

Knowledge ingest — frontend visual design (2 new pages, new frontend/design category)

User-directed ingest (2026-08-20 session): the personal knowledge base (~/llm-wiki) is being
retired; its design-methodology knowledge moves into the plugin wiki so every session and
worker consuming dev-loop routes to it. 2 new pages, 1 new category (frontend/design),
frontend/index.md routing updated, log.md appended.

Verified best-practice

1. frontend/design/anti-slop-visual-design → field-tested

Claim: generated UI reads as "AI-made" primarily through structural repetition
(shared hero → 3-feature-grid → CTA rhythm, genre-blind nav/footer shapes), not color
choice — so structure decisions must precede visual styling, and colors/fonts must flow
through locked :root tokens (OKLCH, one accent ≤3% of viewport, no pure #000/#fff).
Includes the named-tells table (gradient heroes, equal 3-column icon grids, 100vh centered
heroes, redrawn browser/phone chrome, lazy-loaded LCP, eyebrow-label decoration, fabricated
metrics) with fixes, the 8-state interactive floor, and the responsive hard floor
(320/375/414/768px, one-line clickable text, minmax(0, 1fr) image tracks).

How verified / provenance: distilled this session from the locally installed hallmark
skill v1.1.0 (anti-AI-slop design skill — SKILL.md plus its anti-patterns and color
references read in full), which itself encodes Anthropic's frontend-design skill, the
Claude cookbook on frontend aesthetics, and the 2026 "tactile rebellion" consensus. Rated
field-tested, not verified: the rules are a curated practice consensus applied in real
builds, not mechanism claims reproducible against a spec. The one mechanism-shaped claim
carried over (lazy-loaded LCP ≈ 2× worse p75 paint) is kept qualitative ("roughly doubles").

2. frontend/design/html-in-canvas → verified

Claim: the WICG HTML-in-Canvas draft lets real HTML render as live canvas pixels while
staying interactive in the DOM — <canvas layoutsubtree> opts children into layout and hit
testing; drawElementImage (2d) / texElementImage2D (WebGL) / copyElementImageToTexture
(WebGPU) paint the element; a paint event fires on embedded-HTML changes; and the
transform returned by drawElementImage must be applied to element.style.transform or
clicks land where the element is not. Progressive-enhancement-only: draft API, Chromium
behind chrome://flags/#canvas-draw-element since Chrome 138 (Dec 2025), Origin Trial since
Chrome 148 (May 2026).

How verified: API surface (all four primitives, the opt-in attribute's
stacking-context/containment effects, the returned-transform contract) and trial status
checked this session against the WICG explainer repo and the blink-dev Intent-to-Experiment
thread; effect patterns cross-checked against the Codrops walkthrough. The originating
source (a third-party video describing the API as "Canary flag only") was corrected
during verification — the feature has since advanced to an Origin Trial; the page carries
the verified newer status.

Sources checked (opened this session): github.com/WICG/html-in-canvas,
groups.google.com/a/chromium.org/g/blink-dev/c/t_nGEmJ_v4s,
tympanus.net/codrops/2026/05/13/exploring-the-html-in-canvas-proposal/.

Existing-layer check

Pages read: frontend-structure-component-composition, frontend-accessibility-interactive-elements

Checked wiki/frontend/ end-to-end (index routing tables plus category listings): the 11
existing pages cover state, structure/composition, rendering performance, data fetching,
performance, forms (validation timing), security, auth, agent-interfaces, and
accessibility — no existing page covers visual/aesthetic design decisions (color,
typography, layout structure, motion styling) or canvas effect layers; git grep -i "oklch\|aesthetic\|anti-slop\|drawElementImage" wiki/ returns nothing outside the new
pages. Nearest-neighbor overlap is frontend/accessibility/interactive-elements (focus
visibility and keyboard operability vs the new page's 8-state styling floor) — linked via
related: from both new pages rather than merged, since that page owns semantics/focus
mechanics and the new page owns visual state styling; a reciprocal related: entry was
added to interactive-elements pointing at the new page. The two new pages cross-reference
each other (related: both ways; the effect-layer page routes back to the base-design page
for its "shader over slop" edge case).

Open-PR check

gh pr list --state open → zero open PRs at ingest time (checked this session,
2026-08-20). No open knowledge branch touches wiki/frontend/, so no consolidation or
rebase conflict is pending.

Routing decision

Target: frontend domain, NEW category design (wiki/frontend/design/). Rationale:
both pages answer "how should this web UI look/behave visually" — squarely frontend, but no
existing frontend category owns visual/styling decisions (structure = composition
mechanics, rendering = performance, accessibility = operability). A new sibling category
mirrors precedent (PR #111's agent-interfaces). frontend/index.md gets a ## design
section with load-when rows for both pages, and the domain intro's "Route here for" line is
extended with visual-design scope so the router reaches the new category. Page ids follow
the path rule (frontend-design-anti-slop-visual-design, frontend-design-html-in-canvas).

Gates

• wiki-lint-prohibitions.js: directives 71 → 71 (no new directive units; bats
  hardcoded count untouched), 0 violations.
• wiki-structure-checks.js: 244 pages / 13 indexes / 0 findings.
• tests/wiki-lint-prohibitions.bats + tests/wiki-structure-checks.bats: 17/17 ok locally.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TfnWBYHtT5rh4VhoTSRyZq