@ryuxdsgn/design-intelligence 2.19.5 → 2.19.7

package/dist/intelligence/content.js

@@ -308,10 +308,10 @@ export const RULES = [
             notWhen: "reversible, low-impact actions where undo is enough",
             tradeoff: "one extra step versus irreversible loss",
             level: "required",
-            do: "Weigh each destructive or costly action: is it reversible, how big is the impact, how easy is recovery? Prefer undo for reversible actions; confirm with the specifics (amount, recipient, item) when it is irreversible and costly; skip confirmation when it only adds friction.\n  - A confirmation restates the request and its effect (\"Hapus 3 foto dari album Liburan? Foto tidak bisa dikembalikan.\"), and its buttons name the outcomes (\"Hapus foto\" and \"Batal\"), never Ya/Tidak or OK.\n  - Give a destructive confirmation no default button; ask for typing a word only for the rarest, most dangerous actions.",
-            dont: "Confirm every action by reflex, or use a bare \"Are you sure?\" before a payment.",
-            why: "Confirmation that appears everywhere gets dismissed by habit; specifics and undo catch real mistakes.",
-            basis: "Nielsen heuristic 5; NNGroup confirmation-dialog guidance",
+            do: "Weigh each destructive or costly action: is it reversible, how big is the impact, how easy is recovery? Prefer undo for reversible actions; confirm with the specifics (amount, recipient, item) when it is irreversible and costly; skip confirmation when it only adds friction.\n  - A confirmation restates the request and its effect (\"Hapus 3 foto dari album Liburan? Foto tidak bisa dikembalikan.\"), and its buttons name the outcomes (\"Hapus foto\" and \"Batal\"), never Ya/Tidak or OK.\n  - While a confirmation is open it is the only control for that action: the button that opened it steps aside, and the confirming button repeats the trigger's label (\"Publish changes\", not \"Publish now\").\n  - Give a destructive confirmation no default button; ask for typing a word only for the rarest, most dangerous actions.",
+            dont: "Confirm every action by reflex, use a bare \"Are you sure?\" before a payment, or leave the trigger beside its confirmation under another name.",
+            why: "Confirmation that appears everywhere gets dismissed by habit; specifics and undo catch real mistakes. Two buttons for one action, under two names, make people wonder whether they differ.",
+            basis: "Nielsen heuristic 5; NNGroup confirmation-dialog guidance; owner review of the RYUX editor, 2026-10-29: editing a published flow showed \"Publish changes\" and \"Publish now\" at once",
             check: "heuristic_eval H-05",
             formerly: ["RX-H-05", "RX-N-11"],
         },
@@ -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",
         },
         {

package/dist/intelligence/critique.js

@@ -104,7 +104,8 @@ 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 (a confirmation beside the button that opened it, under another
+  name), 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.5",
+  "version": "2.19.7",
   "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": {