@ryuxdsgn/design-intelligence 2.19.4 → 2.19.6

package/dist/intelligence/content.js

@@ -618,10 +618,10 @@ export const RULES = [
             num: 3,
             title: "Specific, plain copy",
             level: "preferred",
-            do: "Lead with the point and cut words that add length without meaning; write labels as RX-CD-12 says; use sentence case and plain lists, with at most one emoji where the channel expects it.",
+            do: "Lead with the point and cut words that add length without meaning; write labels as RX-CD-12 says; use sentence case and plain lists, with at most one emoji where the channel expects it.\n  - When numbers are compared and lower is better (errors, invented policies, cost), say so beside the label (\"fewer is better\").",
             dont: "Use vague labels (\"Submit\", \"Learn more\", \"Get started\" when a specific action exists), hype words (\"unlock\", \"elevate\", \"seamlessly\", \"revolutionary\", \"next-generation\"), emoji bullets, ALL CAPS, or stacked exclamation marks.",
             why: "Specific, plain copy tells users what happens next; decoration on every line buries it and reads as generated.",
-            basis: `NNGroup 3 C's of informational microcopy (clarity, concision, character); NNGroup button and link-label guidance; ${RUN}: unconstrained WhatsApp copy`,
+            basis: `NNGroup 3 C's of informational microcopy (clarity, concision, character); NNGroup button and link-label guidance; ${RUN}: unconstrained WhatsApp copy; owner review of a benchmark video 2026-10-28: "8 vs 0, why does 0 look better?"`,
             check: "audit_copy",
             formerly: ["RX-C-06", "RX-C-10"],
         },
@@ -749,10 +749,10 @@ export const RULES = [
             tradeoff: "emphasizing one thing de-emphasizes the rest",
             level: "required",
             gate: "lock",
-            do: "Make the primary action and the key information the most prominent things in each area, with one clear focal point.\n  - Place each control next to the data it changes (a hide-balance toggle beside the balance it hides, not in the header).\n  - Make the primary action read as an action, not a place: its own button with an action label. It may sit in the center of a bottom bar when it is clearly different from the tabs (its own shape, color, and size, with room around it), but it is never styled as one of the tabs and never crammed between them.\n  - Use one display size per screen, for its single most important number or heading.",
-            dont: "Give everything equal weight, let decoration outrank content, park a control far from what it acts on, or make the main action look like one more tab.",
-            why: "Hierarchy is how users know what to read and do first; a control beside its data shows what it changes, and an action that looks like a tab reads as a place, not a task.",
-            basis: "NNGroup visual hierarchy; Gestalt proximity; Fitts's law (Fitts 1954) for the primary action's size and reach; ryux four-problems blind rating, rater 1 (product designer), 2026-10-16: a hide toggle far from the balance and a CTA crowding the bottom nav were reasons not to ship; explore-judge blind rating 2026-10-18: the same rater shipped a screen with a distinct centered pay button in the bottom bar",
+            do: "Make the primary action and the key information the most prominent things in each area, with one clear focal point.\n  - Place each control next to the data it changes (a hide-balance toggle beside the balance it hides, not in the header).\n  - Make the primary action read as an action, not a place: its own button with an action label. It may sit in the center of a bottom bar when it is clearly different from the tabs (its own shape, color, and size, with room around it), but it is never styled as one of the tabs and never crammed between them.\n  - Use one display size per screen, for its single most important number or heading.\n  - Show each fact and each action once per view. When an action needs two places (a header and a bottom bar), each appears only at the widths where the other is hidden. Show a state as text, not as a disabled button (\"Up to date\", \"All drafted\").",
+            dont: "Give everything equal weight, let decoration outrank content, park a control far from what it acts on, make the main action look like one more tab, or repeat a count or an action in the same view.",
+            why: "Hierarchy is how users know what to read and do first; a control beside its data shows what it changes, and an action that looks like a tab reads as a place, not a task. A fact shown twice makes users check whether the two agree, and a second button for one action, or a disabled button that only reports a state, takes the place of the next real step.",
+            basis: "NNGroup visual hierarchy; Gestalt proximity; Fitts's law (Fitts 1954) for the primary action's size and reach; ryux four-problems blind rating, rater 1 (product designer), 2026-10-16: a hide toggle far from the balance and a CTA crowding the bottom nav were reasons not to ship; explore-judge blind rating 2026-10-18: the same rater shipped a screen with a distinct centered pay button in the bottom bar; owner review of the RYUX editor, 2026-10-28 (\"no double information or double action\"): one personal-data count shown three times, Publish in both the header and the review card, and disabled \"Up to date\" and \"All drafted\" buttons that only reported a state",
             check: "visual QA",
         },
         {
@@ -800,10 +800,10 @@ export const RULES = [
             num: 10,
             title: "Visual language is chosen, not defaulted",
             level: "preferred",
-            do: "Derive the art direction from the brand, the audience, the product context, and reference screens, and write it as a Visual Brief (template in knowledge/imagery.md) (objective, concept, composition, color, material, lighting, motion, avoid) before designing an expressive surface or generating images, 3D, or motion.\n  - For a new product, decide the brand direction before the tokens, task UI included: palette, type, and shape follow from the product's character (fast, warm, trusted, and so on), not from the one accent that passes contrast.",
+            do: "Derive the art direction from the brand, the audience, the product context, and reference screens, and write it as a Visual Brief (template in knowledge/imagery.md) (objective, concept, composition, color, material, lighting, motion, avoid) before designing an expressive surface or generating images, 3D, or motion.\n  - For a new product, decide the brand direction before the tokens, task UI included: palette, type, and shape follow from the product's character (fast, warm, trusted, and so on), not from the one accent that passes contrast.\n  - With no visual direction in the brief or DESIGN.md, say before building that the result will look plain, and offer two or three directions.",
             dont: "Reach for the category cliché (coins, money rain, floating dashboards, or gradient blobs for fintech; generic 3D characters for any app), or write an image prompt without a brief (role, concept, composition).",
             why: "A default visual language makes the product interchangeable with its competitors.",
-            basis: "art direction practice; RX-AS-05 purpose gate",
+            basis: "art direction practice; RX-AS-05 purpose gate; owner review 2026-10-27: a food-delivery build \"too plain, no illustration\" from a DESIGN.md with no visual direction",
             notWhen: "an existing brand system already defines the visual language; follow it",
             tradeoff: "a brief takes time before any image exists",
             check: "the Visual Brief; review",
@@ -1071,10 +1071,10 @@ export const RULES = [
             title: "Readable contrast",
             level: "required",
             gate: "hard",
-            do: "Keep text contrast at least 4.5:1, and at least 3:1 for large text and component boundaries.",
+            do: "Keep text contrast at least 4.5:1, and at least 3:1 for large text and component boundaries.\n  - Over a photo, illustration, or gradient (a status bar on a full-bleed hero, a caption on an image), measure against the worst pixel behind the text or icon, not the average; fix it with a scrim or the bar's light or dark appearance.",
             dont: "Put light grey text on white or white text on a pale accent.",
             why: "Low contrast fails outdoors, on cheap screens, and for low vision.",
-            basis: "WCAG 2.2 SC 1.4.3 and 1.4.11",
+            basis: "WCAG 2.2 SC 1.4.3 and 1.4.11; ryux Figma pilot critique 2026-10-28: a dark status bar over a dark food photo (1.3:1), then a white one over a light grocery photo (2.7:1) until the scrim was darkened",
             check: "audit_ui",
             formerly: ["RX-H-11"],
         },
@@ -1083,10 +1083,10 @@ export const RULES = [
             title: "Readable text, reachable targets",
             level: "required",
             gate: "hard",
-            do: "Keep body text around 14 to 16px on mobile, and touch targets at least 24×24px, preferably 44×44px. The target is the hit area, not the glyph: a 20 to 24px icon sits inside a 44×44 button.",
+            do: "Keep body text around 14 to 16px on mobile, and touch targets at least 24×24px, preferably 44×44px. The target is the hit area, not the glyph: a 20 to 24px icon sits inside a 44×44 button. Measure it on the element or node; a name or comment that states a size is not a measurement.",
             dont: "Shrink body text or crowd small targets together.",
             why: "Small text and targets cause misreads and mis-taps.",
-            basis: "WCAG 2.2 SC 2.5.8 (24px minimum); Apple HIG 44pt; Material 48dp; Fitts's law (Fitts 1954): bigger and nearer targets are faster to hit",
+            basis: "WCAG 2.2 SC 2.5.8 (24px minimum); Apple HIG 44pt; Material 48dp; Fitts's law (Fitts 1954): bigger and nearer targets are faster to hit; ryux Figma pilot critique 2026-10-28: a layer named \"Close (44 pt tap)\" measured 24×44",
             check: "audit_ui",
             formerly: ["RX-H-12"],
         },
@@ -1335,10 +1335,10 @@ export const RULES = [
             num: 3,
             title: "No covered or colliding text",
             level: "required",
-            do: "Keep floating cards and mockups over empty space only, and keep navigation items clear of the logo and buttons.",
+            do: "Keep floating cards and mockups over empty space only, and keep navigation items clear of the logo and buttons.\n  - Labels in a row (steps, tabs, chips) stay visibly apart at the smallest width: at least twice a word space between two labels, or show only the current one.\n  - On a map, keep street and place labels clear of markers, chips, and the route.",
             dont: "Let a card cover prices or labels, or let nav items touch.",
-            why: "Covered text is lost information and looks broken.",
-            basis: `${RUN}: QRIS card over prices, colliding nav`,
+            why: "Covered text is lost information and looks broken; labels a word space apart read as one phrase.",
+            basis: `${RUN}: QRIS card over prices, colliding nav; ryux Figma pilot critique 2026-10-28: "On the way" and "Delivered" 6 pt apart at 360, a courier marker over street labels`,
             check: "screenshot",
             formerly: ["RX-H-14"],
         },
@@ -1346,10 +1346,10 @@ export const RULES = [
             num: 4,
             title: "Numbers agree",
             level: "required",
-            do: "Make line items add up to subtotals and totals, and show the same value the same way everywhere on the screen.",
-            dont: "Show sample numbers that contradict each other.",
-            why: "Readers check sums; one wrong total undermines everything else.",
-            basis: "ryux README checkout image (items Rp125.000, subtotal Rp1.200.000)",
+            do: "Make line items add up to subtotals and totals, and show the same value the same way everywhere on the screen.\n  - Times follow one timeline across a flow: the status-bar clock, timestamps, and estimates on each frame fit its stage.",
+            dont: "Show sample numbers or times that contradict each other.",
+            why: "Readers check sums and clocks; one wrong total or an arrival time already past undermines everything else.",
+            basis: "ryux README checkout image (items Rp125.000, subtotal Rp1.200.000); ryux Figma pilot critique 2026-10-28: a 7:31 clock on every frame beside a 7:38 last update and a 6:15 arrival window",
             check: "review",
         },
         {

package/dist/intelligence/critique.js

@@ -104,7 +104,7 @@ At the hierarchy layer, run four checks on every screen and report each failure
 - Does the primary action read as an action, not a place? If it is styled like a tab or crammed
   between tabs, that is a finding even when it is visible. A centered action button in the bottom bar
   is fine when its shape, color, size, and label set it clearly apart from the tabs.
-- Does any fact appear twice?
+- Does any fact or action appear twice, or does a disabled button only report a state?
 - Are the things the user checks together grouped?
 (RX-UI-01, RX-UX-01.) Look for them even on a screen that is otherwise tidy: they are the defects a
 clean layout hides best. Then ask what the user must read, remember, or decide that the product

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ryuxdsgn/design-intelligence",
-  "version": "2.19.4",
+  "version": "2.19.6",
   "description": "RYUX: design intelligence for AI agents and designers. One skill, five entry points: Analyze, Design, Build, Critique, and QA, for Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Cline, Copilot, and more.",
   "type": "module",
   "bin": {