arkaos 4.28.0 → 4.29.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (42) hide show
  1. package/THE-ARKAOS-GUIDE.md +1 -1
  2. package/VERSION +1 -1
  3. package/arka/skills/refine/SKILL.md +7 -0
  4. package/config/claude-agents/brand-director.md +1 -1
  5. package/config/claude-agents/design-ops-lead.md +1 -1
  6. package/config/claude-agents/frontend-dev.md +1 -1
  7. package/config/claude-agents/ux-designer.md +1 -1
  8. package/config/claude-agents/ux-strategist.md +1 -1
  9. package/config/claude-agents/visual-designer.md +1 -1
  10. package/config/claude-agents/wcag-auditor.md +1 -1
  11. package/config/skills-provenance.yaml +14 -2
  12. package/departments/brand/agents/brand-director.yaml +2 -0
  13. package/departments/brand/agents/design-ops/design-ops-lead.yaml +2 -0
  14. package/departments/brand/agents/design-ops/wcag-auditor.yaml +2 -0
  15. package/departments/brand/agents/ux-designer.yaml +2 -0
  16. package/departments/brand/agents/ux-strategist.yaml +2 -0
  17. package/departments/brand/agents/visual-designer.yaml +2 -0
  18. package/departments/brand/references/uiux-knowledge-and-tools.md +185 -2
  19. package/departments/brand/skills/design-review/SKILL.md +25 -0
  20. package/departments/brand/skills/design-review/references/anti-patterns.md +420 -0
  21. package/departments/brand/skills/design-review/references/critique-protocol.md +169 -0
  22. package/departments/brand/skills/design-review/references/design-registers.md +181 -0
  23. package/departments/brand/skills/design-review/references/genres/atmospheric.md +71 -0
  24. package/departments/brand/skills/design-review/references/genres/editorial.md +74 -0
  25. package/departments/brand/skills/design-review/references/genres/modern-minimal.md +73 -0
  26. package/departments/brand/skills/design-review/references/genres/playful.md +72 -0
  27. package/departments/brand/skills/design-review/references/hallmark.LICENSE +21 -0
  28. package/departments/brand/skills/design-review/references/impeccable.LICENSE +191 -0
  29. package/departments/brand/skills/design-review/references/impeccable.NOTICE +11 -0
  30. package/departments/brand/skills/design-review/references/slop-test.md +194 -0
  31. package/departments/brand/skills/ux-audit/SKILL.md +25 -4
  32. package/departments/dev/agents/frontend-dev.yaml +2 -0
  33. package/harness/codex/AGENTS.md +1 -1
  34. package/harness/copilot/copilot-instructions.md +1 -1
  35. package/harness/cursor/rules/arkaos.mdc +2 -2
  36. package/harness/gemini/GEMINI.md +1 -1
  37. package/harness/opencode/AGENTS.md +1 -1
  38. package/harness/zed/.rules +1 -1
  39. package/knowledge/agents-registry-v2.json +19 -5
  40. package/knowledge/skills-manifest.json +7 -3
  41. package/package.json +1 -1
  42. package/pyproject.toml +1 -1
@@ -0,0 +1,420 @@
1
+ # Anti-patterns — the named tells
2
+
3
+ > Derived from [hallmark](https://github.com/nutlope/hallmark) (MIT — see `hallmark.LICENSE` in this directory). Sanitized and adapted for ArkaOS.
4
+
5
+ The `/brand ux-audit` command flags these by name. Every one of these is a signature of AI-generated UI. Seeing one is a problem; seeing two in the same view is a confirmation.
6
+
7
+ Each entry: the tell, why it reads as AI-generated, and the fix.
8
+
9
+ ---
10
+
11
+ ## Critical (ships as slop)
12
+
13
+ ### The purple-gradient hero
14
+
15
+ A hero section with a background gradient from purple to blue or purple to pink, often with white centred text. This is the single most-recognised AI aesthetic.
16
+
17
+ **Fix.** Pick a single anchor hue. One accent. No gradient backgrounds on heroes. If you want warmth, tint the neutrals.
18
+
19
+ ### Inter-everywhere
20
+
21
+ Inter (or Roboto, or Open Sans) used as both display and body, with no pairing face. A one-font page is a template page.
22
+
23
+ **Fix.** Pair a distinctive display face with a refined body face. See the canonical reflex-reject list in `departments/brand/references/uiux-knowledge-and-tools.md` §11.
24
+
25
+ ### The 3-column feature grid
26
+
27
+ Three equal columns, each with an icon above a two-line heading above a three-line body. Usually spanned full-width with 24px gap. Every LLM emits this.
28
+
29
+ **Fix.** Break the grid. Vary column widths. Mix card heights. Remove one card and use negative space. Move the icons inline, not above. Or drop the cards entirely and use typographic rhythm.
30
+
31
+ ### Card-in-card
32
+
33
+ A bordered container with cards inside it. Or: a card containing another card containing a small "micro-card". Visual nesting with no semantic reason.
34
+
35
+ **Fix.** Pick one containment layer. Usually the outer one is the wrong one.
36
+
37
+ ### The gradient headline
38
+
39
+ A headline with `background-clip: text` fill set to a linear gradient (usually purple-to-pink or blue-to-cyan). Signals "AI generated" faster than almost anything else.
40
+
41
+ **Fix.** Solid ink. If you want the headline to feel alive, use weight or italic or a display face — not a gradient fill.
42
+
43
+ ### The side-stripe card
44
+
45
+ A card with a thick coloured border on one edge (usually left, 4–6px, purple or green). Very recognisable; very 2018-SaaS-AI.
46
+
47
+ **Fix.** Use a hairline border all around, or no border, or a small accent square beside the heading. Never an asymmetric thick stripe.
48
+
49
+ ### Full-viewport centred hero
50
+
51
+ `min-height: 100vh` (or `100dvh`), everything centred, one short sentence, one big CTA. The default LLM landing page.
52
+
53
+ **Fix.** Let the hero be the height of its content. Bias left or right. Put more than a sentence in it.
54
+
55
+ ### Pure black, pure white
56
+
57
+ `#000000` background or `#ffffff` surface. Both read as flat and synthetic.
58
+
59
+ **Fix.** Tint toward your anchor hue. See `color.md`.
60
+
61
+ ### Default-attractor sameness
62
+
63
+ Two consecutive outputs of this skill in the same project use the same macrostructure. The first emitted left-margin numbered labels + huge serif + asymmetric spans (Specimen); the second did exactly the same. The page looks redesigned only because copy changed.
64
+
65
+ **Why it fails.** This skill's whole point is that two pages for two briefs feel like *different sites*, not colour-swaps of one template. Repeating a macrostructure across outputs is the structural fingerprint of templating, which is the AI tell this skill exists to defeat.
66
+
67
+ **Fix.** Before writing code, look in the project's CSS for a `/* [arka:design-dna] macrostructure=<name> ... */` stamp (full format: squad reference §9). If one exists, your pick must be a different macrostructure — categorically different where possible (a serif-led editorial macrostructure paired with a sans-led grid one, not two editorial variants). See `macrostructures.md` for the twenty-one named choices.
68
+
69
+ ### Specimen fall-through
70
+
71
+ Producing the Specimen macrostructure (numbered left-margin labels like `01 — HELLO.` + huge serif display + asymmetric spans + hairline rules + typographic-only CTA + sometimes a hand-drawn SVG accent) when the brief did not explicitly request editorial / foundry / specimen energy. This is the single most-repeated output of this skill, and it's the reason the skill felt like it had one shape.
72
+
73
+ **Why it fails.** Specimen is a beautiful pattern when the brief is editorial. Applied to a SaaS pricing page, a developer tool, an e-commerce site, or a personal app, it looks like the AI defaulted — because it did.
74
+
75
+ **Fix.** The Specimen macrostructure is one of twenty-one in `macrostructures.md`, not a default. If the brief is vague, pick from the first ten in that file (Bento Grid, Long Document, Marquee Hero, Stat-Led, Workbench, Conversational FAQ, Manifesto, Photographic, Quote-Led, then Specimen). Reach for Specimen only when the brief explicitly says "editorial", "specimen sheet", "type foundry", or names the Specimen theme.
76
+
77
+ ### The AI nav
78
+
79
+ Wordmark hard-left, 4–5 inline text links (`Features · Pricing · Docs · Blog · About`) centred or right-grouped, a CTA button hard-right, full viewport width, sticky on scroll, white background, 1 px hairline border-bottom. This is the most-recognised AI nav fingerprint — every LLM emits it because every SaaS site that fed the training data shipped it.
80
+
81
+ **Why it fails.** The shape is genre-blind: it lands the same on a wedding photographer's portfolio, a bakery, a B2B SaaS, and a manifesto. When the nav can't tell you what kind of site you're on, the page is templated.
82
+
83
+ **Fix.** Pick from the routing table in `component-cookbook.md` § Navigation. The genre routes you to one of N5–N9: Floating pill (modern-minimal / atmospheric), Newspaper masthead (editorial), Brutal slab (playful), Terminal command (CLI), Edge-aligned minimal (luxury / quiet). Reach for N1 *only* when the page genuinely has 2 destinations and the routing table allows it. State the rationale in a one-line comment.
84
+
85
+ ### The AI footer
86
+
87
+ 4 columns of links (Product · Company · Resources · Legal), social-icon row beneath, copyright line at the very bottom, faint 1 px top-border, neutral grey background. Standard SaaS footer, identical across thousands of pages.
88
+
89
+ **Why it fails.** Same as the AI nav — the shape is genre-blind. A bakery doesn't have a "Resources" column. An editorial page doesn't have a four-link "Legal". The footer should *close the page*, not catalogue its absent sitemap.
90
+
91
+ **Fix.** Pick from the routing table in `component-cookbook.md` § Footers. Default to Ft1 Mast-headed, Ft2 Inline single line, Ft4 Dense colophon, Ft5 Statement, Ft6 Letter close, Ft7 Newsletter-first, or Ft8 Marquee scroll. Use Ft3 Index columns *only* on a genuine hub or docs root with a real sitemap — and even then, never with the social-icon row + tiny copyright tail.
92
+
93
+ ### Aurora-blob background
94
+
95
+ Flowing organic mesh blobs in purple-to-pink-to-cyan, layered behind hero text. Looks "premium" until you've seen it on every Dribbble shot since 2022.
96
+
97
+ **Why it fails.** It's the 2022–2023 generated-design default. Audiences pattern-match this in milliseconds: AI template.
98
+
99
+ **Fix.** Solid surface. Or a subtle two-stop CSS gradient + SVG `<feTurbulence>` grain at < 0.1 opacity. See `hero-enrichment.md` E7 for the recipe.
100
+
101
+ ### Floating-orb decoration
102
+
103
+ Ambient generic 3D spheres or blurred coloured circles drifting behind the hero, often added "for depth". They have no semantic role.
104
+
105
+ **Why it fails.** Generic 3D ambience is the new corporate-stock-photo. It implies "I needed something here, so I added something here."
106
+
107
+ **Fix.** Cut them. The hero doesn't need depth; it needs a strong typographic anchor.
108
+
109
+ ### Sound-on autoplay
110
+
111
+ A hero video that auto-plays with audio. Browsers block it anyway, but intent matters: a video element shipped without `muted` is a video that wanted to shout at the user.
112
+
113
+ **Why it fails.** Hostile to the audience. Accessibility fail. SEO penalty. Browser blocked.
114
+
115
+ **Fix.** `<video autoplay muted loop playsinline>` — always all four. A separate audio toggle button if sound is genuinely useful.
116
+
117
+ ### Lazy-loaded LCP
118
+
119
+ `loading="lazy"` on the hero image or hero video — the LCP element. The page waits to start downloading until the user scrolls to it, except they're already looking at it, so the page just sits there blank.
120
+
121
+ **Why it fails.** Tanks Largest Contentful Paint. Real-world data: lazy-loaded LCP images show p75 of 720 ms vs. 364 ms for preloaded — 2× slower, 4× more "poor" experiences.
122
+
123
+ **Fix.** `fetchpriority="high"` and `preload="metadata"` on the LCP element. Lazy-load only below-the-fold media.
124
+
125
+ ---
126
+
127
+ ## Major (looks AI-generated)
128
+
129
+ ### Bounce and elastic easing
130
+
131
+ Buttons that bounce in, icons that wobble on hover. These easings were trendy a decade ago.
132
+
133
+ **Fix.** Exponential ease-out. See `motion.md`.
134
+
135
+ ### Centred everything
136
+
137
+ Headline centred, body centred, button centred, section after section of centred columns.
138
+
139
+ **Fix.** Bias the layout. Wide left margin, narrow right. Or the reverse. Breaking symmetry once is enough.
140
+
141
+ ### Italic headers
142
+
143
+ A roman headline with one word flipped to italic — *"Built to think in real time"* — or an all-italic display face used on every heading. The italicised emphasis-word-in-a-header is among the most reliable AI tells: it reads as "trying to look editorial" and appears on a huge share of generated pages.
144
+
145
+ **Fix.** Headers are roman (`font-style: normal`). Carry emphasis with weight, an accent colour, or a drawn underline beneath the word. Keep italic for body-copy emphasis inside running paragraphs only.
146
+
147
+ ### Eyebrow on every section
148
+
149
+ Every section starts with an uppercase mono-cap eyebrow — `01 / EXAMPLES`, `02 / WHAT'S INSIDE`, `03 / INSTALL`, `01 · THE TOUR` — above (or worse, *beside*) its heading. The labels look like editorial chapters but read as a tic. The page becomes a list of *labelled lists.*
150
+
151
+ Eyebrows are **default OFF**. They are not a stylistic flourish you reach for to look editorial — they are an ordinal device, valid only when the section is genuinely numbered or chaptered. Used as decoration they erase the hierarchy they were meant to create; when every section is "chaptered," none of them are.
152
+
153
+ **Fix.** Ship the page with **zero eyebrows** unless either (a) the user explicitly asked for chapter / step / section numbering, OR (b) the macrostructure is **Long Document, Manifesto, or Catalogue numbered** AND the content is genuinely ordinal (steps you must do in order, chapters that build, items in a deliberate sequence). Even then: cap at 1–2 per page.
154
+
155
+ **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 54 enforces this.
156
+
157
+ **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.
158
+
159
+ ### Shadow-glow on dark
160
+
161
+ A card on a dark background with a `box-shadow` that leaves a soft coloured halo around it.
162
+
163
+ **Fix.** On dark surfaces, use elevation via *lightness* (brighter surface = higher), not shadow. If you must shadow, keep it tight and dark.
164
+
165
+ ### Icon-tile feature card
166
+
167
+ Rounded rectangle, icon in a coloured square at the top-left, heading below it, two lines of copy, optional "Learn more →" link. The universal template.
168
+
169
+ **Fix.** If you need these, let them be asymmetric — vary sizes, vary alignments, pull the icon inline with the heading, or drop the icon entirely.
170
+
171
+ ### Glassmorphism without purpose
172
+
173
+ Frosted-glass panels everywhere — usually layered over a gradient that you also shouldn't have.
174
+
175
+ **Fix.** Glassmorphism can work when it communicates depth (overlay over content). It cannot work as decoration.
176
+
177
+ ### Hover-only affordances
178
+
179
+ Hover reveals a menu; hover shows a delete button; hover triggers a tooltip that contains crucial information. Touch users get nothing.
180
+
181
+ **Fix.** Every hover affordance has a focus state and is accessible via tap/click on coarse pointers.
182
+
183
+ ### Tabular data without tabular-nums
184
+
185
+ A list of prices, dates, or metrics where the numbers don't align vertically because the font uses proportional figures.
186
+
187
+ **Fix.** `font-variant-numeric: tabular-nums;` on any container displaying columns of numbers.
188
+
189
+ ### Animate-on-scroll on everything
190
+
191
+ Every section fades in when it enters the viewport. Every list staggers. The page never settles.
192
+
193
+ **Fix.** Pick one orchestrated entrance. Let the rest just *be there*.
194
+
195
+ ### Mismatched icon sets
196
+
197
+ Material Icons in the navbar, Heroicons in the feature cards, Lucide in the footer, an emoji "✨" in a hero badge. Each library has its own stroke voice; mixing them is the icon-set tell.
198
+
199
+ **Why it fails.** Icons are typography. You wouldn't ship a page with three different body fonts; don't ship one with three different icon strokes.
200
+
201
+ **Fix.** Pick one library per project. Lucide is the default for SaaS, Phosphor when you need weight variants, Heroicons for Tailwind/shadcn projects. See `assets.md` for the canon.
202
+
203
+ ### AI-illustration look
204
+
205
+ Smooth-mesh-blob characters with no joint articulation, mid-2010s "modern flat" stock poses, unmistakably-Midjourney compositions with the symmetric default lighting. Hand-drawn SVG humans (the "doodle person with one eye larger than the other") fall under this — corporate-doodle is the late-2010s Slack/Figma marketing template, and the audience reads it as AI immediately.
206
+
207
+ **Why it fails.** It reads as AI in milliseconds. The 2026 audience pattern-matches this faster than any other tell.
208
+
209
+ **Fix.** Hand-build the illustration in pure CSS or SVG (Tier A or B in `hero-enrichment.md`). If you must generate, use the ArkaOS image pipeline (`/brand image-create`, ComfyUI) with reference images, asymmetric crop, and grain post-processing — never raw output. See `custom-craft.md` Tier E.
210
+
211
+ ### Invented metrics
212
+
213
+ A stat-led layout, comparison row, or proof bar carrying numbers the user never supplied — "10× faster", "saves 5 hours per week", "trusted by 50,000+ teams", "99.9 % uptime", "+47 % conversion". The model reached for a stat to fill a stat slot and made one up.
214
+
215
+ **Why it fails.** Audiences read invented stats as fast as they read invented testimonials. A page that lies on its proof bar can't be trusted on its claims either, and the AI tell is unmistakable: every fabricated number reads "this was generated, not written".
216
+
217
+ **Fix.** Three options, in order of preference: (1) replace the number with `—` and a labelled grey block ("metric to confirm" or "stat pending"); (2) ask the user for the real number and pause the run; (3) rebuild the section without the proof slot — a stat-led macrostructure with no real stats is the wrong macrostructure. The number-shaped hole is honest; the fabricated number is slop. *(Slop-test gate 46.)*
218
+
219
+ ### Generic emoji as feature icon
220
+
221
+ A feature card, value prop, step number, or pricing tier with `✨` `🚀` `⚡` `🔥` `🎯` `✅` rendered as the primary icon. The "sparkle hero" badge with a `✨` glyph beside the eyebrow. Emoji standing in for an icon library because the model didn't pick one.
222
+
223
+ **Why it fails.** Emoji are typography of a sort, but they are not part of the page's typographic system — they're rendered by the OS and look different on every device, they break the icon's stroke voice (you've now mixed a Phosphor-style line icon with a Twemoji blob), and the choice is recognisably the AI default. Sparkle-emoji-as-AI-shortcut is the cliché of the 2024–2025 era.
224
+
225
+ **Fix.** Pick a single icon library and ship it (`assets.md` names the canon). Or build a custom SVG mark. Or omit the icon entirely and lead with typography — most feature lists don't need icons. *(Slop-test gate 30.)*
226
+
227
+ ### Re-drawn UI chrome
228
+
229
+ A fake browser bar (URL pill + traffic-light dots) wrapping a screenshot. A fake phone frame (rounded rectangle + notch + speaker slit) around a mobile mockup. A fake code-block window (mock title bar + close/minimise dots) wrapping a `<pre>`. A fake IDE chrome (file tabs + activity bar) around an editor screenshot. All hand-built in HTML/CSS or SVG.
230
+
231
+ **Why it fails.** The user already has the chrome — their browser, their phone, their IDE all *are* chrome. Redrawing it in a page is like printing a photograph of a picture frame inside a real picture frame. The fakery is also bad: the URL is wrong, the dots aren't macOS dots, the notch is the wrong shape. Audiences pattern-match re-drawn chrome as "AI invented a UI that already exists" within a glance.
232
+
233
+ **Fix.** Use a real screenshot wrapped in `<figure>` (with a hairline border at most). For phone mockups, use a transparent-PNG device frame from a vendor or a real product photograph — never a CSS-drawn one. For code blocks, use the system `<pre>` with a typographic frame (top rule + label + bottom rule), not a faked window-chrome. The page's job is to show content, not to imitate the OS. *(Slop-test gate 47.)*
234
+
235
+ ### Mid-render token improvisation
236
+
237
+ A theme is selected at the top of the run, but the artifact contains inline colour values (`#5b6cff`, `oklch(74% 0.18 245)`, `rgb(...)`) or `font-family` declarations that aren't drawn from the token block. Or: the artifact ships with the theme's token set *plus* one extra hex tucked into a hover state, a focus ring, or a single border. The model picked the theme, then drifted.
238
+
239
+ **Why it fails.** Token discipline is the difference between a system and a freestyle. Once a theme is locked, every colour and every font in the file must reference a named token (`var(--color-accent)`, `font-family: var(--font-display)`). Inline values are how cohesion erodes — by the third edit pass, the page has eight colours instead of three, and the editorial restraint that made the theme work is gone. Audiences don't see the inline value, but they feel the looseness.
240
+
241
+ **Fix.** Every colour and every font in the artifact must come through `var(--token-name)`. If you need a value that doesn't exist as a token, add it to the token block first (`--color-accent-warm: oklch(...)`) and then reference it. Inline OKLCH or one-off hex values mid-render are not allowed. *(Slop-test gate 48. See also `departments/brand/references/uiux-knowledge-and-tools.md` §3, Design Tokens.)*
242
+
243
+ ### Wrap-to-two-lines clickable text
244
+
245
+ A button label, nav link, footer link, breadcrumb, or CTA reads on two lines because the viewport got narrow and the label was long. Visually, the affordance now looks broken — readers can't tell whether the line break is intentional. Worst case: the second line is one word ("free", "more", "started"), which reads as a styling error.
246
+
247
+ **Why it fails.** Clickable affordances are one-line objects. The reader scans the label, decides whether to click, moves on. A two-line label slows the scan, breaks the row's vertical rhythm (button height grows, sibling buttons stay the same), and signals "this page wasn't tested at this width". It's a responsive-discipline tell.
248
+
249
+ **Fix.** In order of preference: (1) shorten the label — *"Get started free" → "Start free"*; *"Read the documentation" → "Read docs"*. Most CTA labels are too long. (2) Set `white-space: nowrap` on the affordance and let the parent flex container reflow. (3) Drop a non-essential nav item at narrow widths via `hidden=until-found` or `display: none`. (4) Collapse the nav into a sheet/menu under a threshold. *Never* let a primary CTA or nav link wrap. *(Slop-test gate 49. See `responsive.md` § Clickable text — never wraps.)*
250
+
251
+ ### Lottie shortcut
252
+
253
+ Reaching for a LottieFiles community animation — the spinning logo, the checkmark draw, the loading spinner, the "loading dots" loop — when pure CSS or hand-built SVG would have produced it stronger and lighter.
254
+
255
+ **Why it fails.** Lottie pulls were an AI-tool shortcut throughout 2023–2024; the audience now reads them as one. The 50–500 KB JSON file plus the runtime cost is a tax on a job CSS does in zero bytes.
256
+
257
+ **Fix.** Build it custom. Spinning logo → CSS `@keyframes rotate`. Checkmark → SVG `stroke-dasharray` animated. Loading dots → CSS `@property` + `animation-delay`. Lottie is Tier F in the enrichment hierarchy — last resort, only for genuinely articulated character motion.
258
+
259
+ ### Three.js for a still object
260
+
261
+ A WebGL hero where the 3D doesn't earn its place by being interactive. A stationary spinning thing the user can't touch, can't reorient, can't customise — just a model rotating because someone wanted "3D".
262
+
263
+ **Why it fails.** The 100–300 KB Three.js bundle, the model, the textures, the GPU work — all for a thing that could be a static photograph or an SVG.
264
+
265
+ **Fix.** If the user can't manipulate it, it doesn't justify Three.js. Use a still photograph or a hand-built SVG.
266
+
267
+ ---
268
+
269
+ ## Microinteraction tells
270
+
271
+ These are the named tells of AI-generated *motion*. See `microinteractions.md` for the full catalogue and recipes.
272
+
273
+ ### `transition-all`
274
+
275
+ Every property animating, including ones that should be instant (visibility, focus rings).
276
+
277
+ **Fix.** Specify the properties. `transition: background-color var(--dur-short) var(--ease-out), transform 100ms var(--ease-out)`.
278
+
279
+ ### Universal `hover:scale-105`
280
+
281
+ Every card lifts on hover, with no shadow change, no easing specified, no purpose.
282
+
283
+ **Fix.** Pick one signal per element. A 1px translate, or a colour shift, or an underline thickening — never all four.
284
+
285
+ ### Bouncy overshoot easings on UI
286
+
287
+ `cubic-bezier(0.34, 1.56, 0.64, 1)` and friends on buttons, modals, tooltips. Tasteless throwback.
288
+
289
+ **Fix.** Reserve overshoots for genuine physical interactions (drag-and-drop release). For UI state, use `--ease-out` from `motion.md`.
290
+
291
+ ### Animated hover gradients
292
+
293
+ Background gradient slides through colour space on hover.
294
+
295
+ **Fix.** Cut. Or pick one colour shift, instant.
296
+
297
+ ### Cursor follower dots
298
+
299
+ A trailing dot that lags behind the pointer.
300
+
301
+ **Fix.** Cut.
302
+
303
+ ### Auto-rotating carousels with no pause
304
+
305
+ WCAG 2.2.2 failure.
306
+
307
+ **Fix.** Manual advance only, or pause-on-hover-and-focus, or autoplay disabled by default.
308
+
309
+ ### Celebratory success toasts
310
+
311
+ "Done!" when the user just saved a thing they can see was saved.
312
+
313
+ **Fix.** Silent success. Toasts only for failures, async actions whose effect isn't visible, and explicit confirmations the user will need.
314
+
315
+ ### Confirmation dialogs for reversible actions
316
+
317
+ "Are you sure you want to delete this?" before a one-row delete.
318
+
319
+ **Fix.** Optimistic delete + 5–10s Undo toast. Reserve the modal for irreversible destructive actions, and even then, type-the-name confirmation, not click-OK.
320
+
321
+ ### Tooltips with the same delay on hover and focus
322
+
323
+ Both delay 800ms.
324
+
325
+ **Fix.** Hover delay 800–1000ms. Focus delay 0ms. Different intents, different timing.
326
+
327
+ ### Focus rings that animate in
328
+
329
+ The ring fades in over 200ms — keyboard users have no indicator at the start of the transition.
330
+
331
+ **Fix.** Focus rings appear instantly. Always. Don't transition `outline` or `box-shadow` when the element gains focus.
332
+
333
+ ### Toasts that shift layout
334
+
335
+ New toast pushes content down; dismissed toast lets it spring back.
336
+
337
+ **Fix.** Stack at a viewport corner, fixed positioning. Existing toasts don't move when a new one arrives.
338
+
339
+ ### Universal scroll-triggered fade-up
340
+
341
+ Every section fades in on intersection. The page never settles.
342
+
343
+ **Fix.** One orchestrated entrance on first load. After that, content is just there.
344
+
345
+ ### Spinners that flash
346
+
347
+ A spinner appears for 50ms while a fast action completes.
348
+
349
+ **Fix.** Either delay-show the spinner (150ms before showing) or enforce a minimum visible duration (300ms once shown). Skeletons over spinners when the layout is known.
350
+
351
+ ---
352
+
353
+ ## Minor (small taste issues)
354
+
355
+ ### Straight quotes
356
+
357
+ `"Hello"` and `'word'` in rendered text. A sign nothing was proof-read.
358
+
359
+ **Fix.** Curly quotes: `"Hello"`, `'word'`.
360
+
361
+ ### Double-hyphen dashes
362
+
363
+ `--` in body copy where an em-dash belongs.
364
+
365
+ **Fix.** `—` (U+2014).
366
+
367
+ ### Three periods instead of ellipsis
368
+
369
+ `...` in body copy.
370
+
371
+ **Fix.** `…` (U+2026).
372
+
373
+ ### Placeholder names
374
+
375
+ "Jane Doe", "John Smith", "Example User".
376
+
377
+ **Fix.** Plausible placeholder names reflecting the audience, or pull from a seeded faker. "Maya Okonkwo", "Sam Tan", "Elena Ruiz".
378
+
379
+ ### Startup-cliché product names
380
+
381
+ "Acme", "Nexus", "Pulse", "Unleash", "Seamless", "Supercharge".
382
+
383
+ **Fix.** Name the thing concretely. If it's a demo, use a domain-specific placeholder — "Maple Weekly", "Ridgeline Inventory" — not abstract startup bingo.
384
+
385
+ ### `z-index: 9999`
386
+
387
+ Arbitrary large z-values.
388
+
389
+ **Fix.** Use the six-level named scale. See `layout-and-space.md`.
390
+
391
+ ### Every section padded the same
392
+
393
+ Top padding, bottom padding, horizontal padding — all equal across every section.
394
+
395
+ **Fix.** Vary. Tighten one, expand another.
396
+
397
+ ### 100vw widths
398
+
399
+ `width: 100vw` on anything. Breaks on scrollbar-visible desktops.
400
+
401
+ **Fix.** `width: 100%` with container padding.
402
+
403
+ ---
404
+
405
+ ## How `/brand ux-audit` should report
406
+
407
+ For each finding:
408
+
409
+ ```
410
+ [severity] Tell name — file:line
411
+ why it's a tell (one line)
412
+ → fix (one line)
413
+ ```
414
+
415
+ Then:
416
+
417
+ ```
418
+ Summary — N critical · M major · K minor
419
+ Verdict — [ships as slop | reads as AI-generated | close, fix the minors]
420
+ ```
@@ -0,0 +1,169 @@
1
+ # Critique Protocol — Isolated Dual-Review Design Critique
2
+
3
+ > Derived from [impeccable](https://github.com/pbakaus/impeccable) (Apache-2.0 — see `impeccable.LICENSE` and `impeccable.NOTICE` in this directory). Distilled and adapted for ArkaOS; changes from upstream are substantial (orchestration kept, CLI plumbing removed).
4
+
5
+ ## Purpose
6
+
7
+ Resolve one stable target (a source file path over a dev-server URL — ports drift, paths do not), run two independent assessments, and synthesize a design critique the way a design director would deliver it. The chat report is the deliverable.
8
+
9
+ ## Hard Invariants
10
+
11
+ - Assessment A (LLM design review) and Assessment B (deterministic detector + browser evidence) are BOTH required.
12
+ - A and B MUST run as two isolated subagents whenever dispatch is available. Running them inline is "possible" but NOT permitted — it is a degraded run. Inline is allowed only when no subagent dispatch exists.
13
+ - If you degrade for any reason, the report's FIRST line must be the banner: `⚠️ DEGRADED: single-context (<reason>)`. A silent degraded critique is a failed critique.
14
+ - Assessment A must finish before detector findings enter the synthesis context. Detector output is deterministic, but it still anchors judgment.
15
+ - A skipped detector is a failed critique run unless the detector is genuinely missing or crashes after a real attempt.
16
+ - Viewable targets require browser inspection when browser automation is available.
17
+ - Never claim a user-visible overlay or visual evidence exists unless the browser step actually produced it.
18
+
19
+ ## Orchestration — Two Isolated Subagents
20
+
21
+ Dispatch two isolated review subagents (quality dispatches are exempt from subagent-discipline caps — independent review context is a correctness requirement). They MUST NOT see each other's output; do not show findings to the user until synthesis.
22
+
23
+ - **Sub-agent A — Design review.** Reads relevant source files and visually inspects the live page when browser automation is available. Blind to detector output.
24
+ - **Sub-agent B — Deterministic evidence.** Runs the deterministic design-slop detector (QG check `design-slop`, Wave 3) plus browser evidence. Blind to A's judgment.
25
+
26
+ Rules of engagement:
27
+
28
+ - Spawn A and B in parallel whenever dispatch is available. "Unavailable" means exactly one thing: no subagent dispatch is exposed in this session. It does not mean inconvenient, and never "faster inline".
29
+ - If and only if dispatch is unavailable, fall back sequentially: finish and record Assessment A, then run Assessment B, then synthesize — and emit the degraded banner.
30
+ - Whichever path was taken, declare it in the report header (see provenance below). Skipping isolation without the banner is the most common failure of this protocol.
31
+ - If browser automation is available, each assessment opens its own fresh tab. Never reuse an existing tab, even if it is already at the right URL.
32
+
33
+ ## Assessment A: Design Review
34
+
35
+ Think like a design director. Evaluate:
36
+
37
+ - **AI slop** — would someone believe "AI made this" immediately? Apply the anti-slop doctrine and the register-specific slop tests (see `design-registers.md`).
38
+ - **Holistic design** — hierarchy, IA, emotional fit, discoverability, composition, typography, color, accessibility, states, copy, edge cases.
39
+ - **Cognitive load** — apply the working-memory rule and the 8-item checklist below; report checklist failures and any decision point with >4 visible options.
40
+ - **Emotional journey** — peak-end rule, emotional valleys, reassurance at high-stakes moments.
41
+ - **Nielsen heuristics** — score all 10 heuristics 0–4. Score against Nielsen's 10 heuristics — the squad's canonical source is [[Area 02 - Design]] and the ui-ux-pro-max plugin.
42
+
43
+ Return contract: AI slop verdict, heuristic scores, cognitive load result, emotional journey notes, 2–3 strengths, 3–5 priority issues, persona red flags, minor observations, provocative questions.
44
+
45
+ ## Assessment B: Detector + Browser Evidence
46
+
47
+ Run the deterministic design-slop detector (QG check `design-slop`, Wave 3) against the target markup, and gather browser evidence when the target is viewable and automation is available (fresh tab, screenshot, console/state observations on 3–5 representative pages for multi-view targets).
48
+
49
+ Return contract: detector findings with counts, rule names, and file locations; browser observations if applicable; suspected false positives; skipped or failed steps with concrete reasons. Reuse B's detector findings in synthesis — do not rerun the detector in the parent unless B failed, was truncated, or omitted counts, rule names, or locations.
50
+
51
+ ## Synthesis — Combined Critique Report
52
+
53
+ Synthesize both assessments into a single report. Do NOT concatenate. Weave the findings: note where the LLM review and the detector agree, where the detector caught issues the LLM missed, and where detector findings are false positives. Present the full structured critique in chat — never a summary plus a link.
54
+
55
+ ### Report header provenance
56
+
57
+ The report's first line MUST declare how the assessments ran, so a degraded run is never silent:
58
+
59
+ - Dual-agent: `Method: dual-agent (A: <agent-id> · B: <agent-id>)`
60
+ - Degraded: `⚠️ DEGRADED: single-context (<reason, e.g. no subagent dispatch exposed>)`
61
+
62
+ ### Design Health Score
63
+
64
+ Present the Nielsen scores as a table (canonical heuristics source: [[Area 02 - Design]] + ui-ux-pro-max):
65
+
66
+ | # | Heuristic | Score | Key Issue |
67
+ |---|-----------|-------|-----------|
68
+ | 1 | Visibility of System Status | ? | [specific finding or "n/a" if solid] |
69
+ | 2 | Match System / Real World | ? | |
70
+ | 3 | User Control and Freedom | ? | |
71
+ | 4 | Consistency and Standards | ? | |
72
+ | 5 | Error Prevention | ? | |
73
+ | 6 | Recognition Rather Than Recall | ? | |
74
+ | 7 | Flexibility and Efficiency | ? | |
75
+ | 8 | Aesthetic and Minimalist Design | ? | |
76
+ | 9 | Error Recovery | ? | |
77
+ | 10 | Help and Documentation | ? | |
78
+ | **Total** | | **??/40** | **[Rating band]** |
79
+
80
+ ### Report sections, in order
81
+
82
+ 1. **Anti-Patterns Verdict** — start here. Does this look AI-generated? Give the LLM assessment (aesthetic feel, layout sameness, generic composition, missed personality) AND the deterministic scan summary (counts, locations, false positives flagged).
83
+ 2. **Overall Impression** — gut reaction: what works, what doesn't, the single biggest opportunity.
84
+ 3. **What's Working** — 2–3 things done well, specific about why.
85
+ 4. **Priority Issues** — the 3–5 most impactful problems, ordered. Each tagged `[P0–P3]` with: **What** (name it), **Why it matters** (user/goal impact), **Fix** (concrete).
86
+ 5. **Persona Red Flags** — 2–3 personas from the selection table below; name the exact elements and interactions that fail each persona, never generic descriptions.
87
+ 6. **Minor Observations** — quick notes on smaller issues.
88
+ 7. **Questions to Consider** — provocative unlocks: "What if the primary action were more prominent?" "Does this need to feel this complex?" "What would a confident version of this look like?"
89
+
90
+ ## Scoring Mechanics (0–4)
91
+
92
+ Each heuristic scores 0–4: **0** = broken/absent, **1** = rare/mostly failing, **2** = partial with major gaps, **3** = good with minor gaps, **4** = genuinely excellent. Total out of 40:
93
+
94
+ | Score Range | Rating | What It Means |
95
+ |-------------|--------|---------------|
96
+ | 36–40 | Excellent | Minor polish only; ship it |
97
+ | 28–35 | Good | Address weak areas, solid foundation |
98
+ | 20–27 | Acceptable | Significant improvements needed before users are happy |
99
+ | 12–19 | Poor | Major UX overhaul required; core experience broken |
100
+ | 0–11 | Critical | Redesign needed; unusable in current state |
101
+
102
+ ## Honesty Rubric
103
+
104
+ - Be honest with scores. A 4 means genuinely excellent, not "good enough". Most real interfaces score 20–32.
105
+ - Be direct. Vague feedback wastes everyone's time.
106
+ - Be specific. "The submit button," not "some elements."
107
+ - Say what's wrong AND why it matters to users.
108
+ - Give concrete suggestions. Cut "consider exploring..." entirely.
109
+ - Prioritize ruthlessly. If everything is important, nothing is.
110
+ - Don't soften criticism. Builders need honest feedback to ship great design.
111
+
112
+ ## Issue Severity (P0–P3)
113
+
114
+ | Priority | Name | Description | Action |
115
+ |----------|------|-------------|--------|
116
+ | **P0** | Blocking | Prevents task completion entirely | Fix immediately; showstopper |
117
+ | **P1** | Major | Causes significant difficulty or confusion | Fix before release |
118
+ | **P2** | Minor | Annoyance, but workaround exists | Fix in next pass |
119
+ | **P3** | Polish | Nice-to-fix, no real user impact | Fix if time permits |
120
+
121
+ Tie-breaker: "Would a user contact support about this?" If yes, it's at least P1.
122
+
123
+ ## Cognitive Load — Working Memory Rule + Checklist
124
+
125
+ **Humans hold ≤4 items in working memory at once** (Miller's Law, revised by Cowan 2001). At any decision point, count distinct options/actions/facts the user must hold simultaneously: ≤4 manageable · 5–7 pushing the boundary (group or disclose progressively) · 8+ overloaded (users skip, misclick, abandon). Practical caps: ≤5 top-level nav items, ≤4 form fields per visual group, 1 primary + 1–2 secondary actions, ≤4 dashboard metrics without scrolling, ≤3 pricing tiers.
126
+
127
+ Checklist — evaluate all 8:
128
+
129
+ - [ ] **Single focus**: can the user complete the primary task without competing elements?
130
+ - [ ] **Chunking**: information in digestible groups (≤4 items per group)?
131
+ - [ ] **Grouping**: related items visually grouped (proximity, borders, shared background)?
132
+ - [ ] **Visual hierarchy**: immediately clear what's most important?
133
+ - [ ] **One thing at a time**: single decision at a time before moving on?
134
+ - [ ] **Minimal choices**: ≤4 visible options at any decision point?
135
+ - [ ] **Working memory**: no remembering info from a previous screen to act on this one?
136
+ - [ ] **Progressive disclosure**: complexity revealed only when needed?
137
+
138
+ Scoring: count failures. 0–1 = low load (good) · 2–3 = moderate (address soon) · 4+ = high (critical fix).
139
+
140
+ ## Persona-Based Design Testing
141
+
142
+ Test through 2–3 archetypes; each exposes failure modes a single design-director lens misses. Walk the primary user action as each persona and report specific red flags — exact elements, not generic concerns.
143
+
144
+ **1. Alex — Impatient Power User.** Expert with similar products; skips onboarding, hunts keyboard shortcuts, tries bulk/batch actions, abandons anything slow or patronizing. Red flags: forced tutorials or unskippable onboarding · no keyboard navigation for primary actions · slow unskippable animations · one-item-at-a-time workflows where batch would be natural · redundant confirmations for low-risk actions.
145
+
146
+ **2. Jordan — Confused First-Timer.** Never used this product type; reads everything, hesitates before unfamiliar clicks, takes labels literally, abandons rather than figures it out. Red flags: icon-only navigation with no labels · technical jargon without explanation · no visible help or guidance · ambiguous next steps after an action · no confirmation that an action succeeded.
147
+
148
+ **3. Sam — Accessibility-Dependent User.** Screen reader (VoiceOver/NVDA), keyboard-only, may use 200% zoom; needs 4.5:1 contrast, ARIA labels, heading structure, announced state changes. Red flags: click-only interactions with no keyboard alternative · missing or invisible focus indicators · meaning conveyed by color alone · unlabeled form fields or buttons · time-limited actions without extension · custom components that break screen-reader flow.
149
+
150
+ **4. Riley — Deliberate Stress Tester.** Pushes past the happy path: empty states, long strings, emoji/RTL input, refresh mid-flow, multiple tabs; documents gaps between what the UI promises and what happens. Red flags: features that appear to work but silently fail · error handling that exposes technical detail or bricks the UI · empty states with no guidance · workflows that lose data on refresh or navigation · inconsistent behavior between similar interactions.
151
+
152
+ **5. Casey — Distracted Mobile User.** One thumb, on the go, interrupted mid-flow, possibly on 3G; taps over typing, expects state preserved on return. Red flags: primary actions at the top of the screen (out of thumb zone) · no state persistence across interruptions · large text inputs where selection would work · heavy assets with no lazy loading · tiny or crowded tap targets (<44×44pt).
153
+
154
+ ### Persona selection table
155
+
156
+ | Interface Type | Primary Personas | Why |
157
+ |---------------|-----------------|-----|
158
+ | Landing page / marketing | Jordan, Riley, Casey | First impressions, trust, mobile |
159
+ | Dashboard / admin | Alex, Sam | Power users, accessibility |
160
+ | E-commerce / checkout | Casey, Riley, Jordan | Mobile, edge cases, clarity |
161
+ | Onboarding flow | Jordan, Casey | Confusion, interruption |
162
+ | Data-heavy / analytics | Alex, Sam | Efficiency, keyboard nav |
163
+ | Form-heavy / wizard | Jordan, Sam, Casey | Clarity, accessibility, mobile |
164
+
165
+ When the project carries real audience/brand context (project design system, brand descriptor), derive 1–2 project-specific personas from it — profile, behaviors, red flags. Never invent audience details; without real context, use only the 5 predefined personas.
166
+
167
+ ## After the Report
168
+
169
+ Ask 2–4 targeted questions grounded in actual findings (priority direction among the found issue categories, design intent on tonal mismatches, scope: top-3 vs all, off-limits areas). Never ask generic "who is your audience?" questions; offer concrete options. If findings are trivial (1–2 clear issues), skip questions and go straight to a prioritized action list mapped to the issues, ordered by the user's stated priorities, then impact.