@ryuxdsgn/design-intelligence 2.9.3 → 2.11.0

package/dist/intelligence/content.js

@@ -71,7 +71,7 @@ export const RULES = [
             notWhen: "This rule is not a reason to drop content the brief implies or to leave a screen looking unfinished: sample content is RX-AS-03, design assumptions are yours to make.",
             why: "Invented facts turn into promises and bugs that someone has to unwind; a screen trimmed to the brief's literal words reads unfinished and hides what still needs confirming.",
             basis: `${RUN}: an unconstrained agent invented a 30-day trial and user counts; ryux visual benchmark 2.6 human rater, 2026-10-13: RYUX screens lost on a missing receipt action`,
-            check: "review",
+            check: "compare every product fact on the screen (features, prices, fees, policies, names, integrations) with the brief, DESIGN.md, docs, or repo; each is sourced or labelled as an assumption; fails on one shown as fact without a source",
         },
         {
             num: 3,
@@ -83,7 +83,7 @@ export const RULES = [
             notWhen: "Monitoring and configuration screens (dashboards, settings) need a clear goal but not a single dominant action; do not invent one to satisfy this rule.",
             why: "A single clear path shortens the decision and the task.",
             basis: "Hick's law (Hick 1952; Hyman 1953): more options, longer decisions; NNGroup visual hierarchy",
-            check: "review",
+            check: "name the screen's goal and its primary action, then count the controls styled as primary in the main state; fails when two compete at the same weight",
         },
         {
             num: 4,
@@ -196,6 +196,18 @@ export const RULES = [
             check: "heuristic_eval H-06",
             formerly: ["RX-H-06"],
         },
+        {
+            num: 10,
+            title: "Change what is broken, keep what works",
+            notWhen: "a new product or screen with nothing to keep, or a brief that asks to replace the whole design",
+            tradeoff: "a redesign can look less new; the gain is in fewer regressions and less relearning",
+            level: "required",
+            do: "Before changing an existing screen or flow, list what works today (from Analyze, the user, or analytics) and keep it. Every significant change names the problem it fixes and its evidence (a Critique finding, a user report, a metric); a pattern with no named problem stays as it is. Report what was kept as well as what changed.",
+            dont: "Replace a working layout, component, or interaction for novelty; restyle parts the brief did not ask to change; or treat \"more modern\" as a problem by itself.",
+            why: "A redesign that throws away what people already know costs them relearning and can make the product worse while looking newer.",
+            basis: "ryux design principle (owner, 2026-10-19); Jakob's law (people expect a product to work like the ones they already know); ryux run: judge and motion benchmarks 2026-10-18; written for RYUX",
+            check: "the change list, each with its problem and evidence; the kept list; review",
+        },
     ]),
     ...skill("interaction", [
         {
@@ -209,7 +221,7 @@ export const RULES = [
             dont: "Ship an action whose in-progress, result, or failure behavior is undefined.",
             why: "Undefined behavior becomes inconsistent behavior once it is implemented.",
             basis: "Nielsen heuristics 1 and 9; peak-end rule (Kahneman et al. 1993): people judge an experience largely by its most intense moment and its end; ryux interaction model",
-            check: "review",
+            check: "for each async action, point to its before, during, result, and recovery states in the render or the design file; fails on any that is missing",
         },
         {
             num: 2,
@@ -703,11 +715,11 @@ export const RULES = [
             title: "A point of view on expressive surfaces",
             level: "contextual",
             when: "the surface is expressive: a hero, landing page, onboarding, empty state, or brand moment, or the brief asks for a new look or more personality",
-            do: "Before designing, make three directions, each with a name, a concept taken from the product's own idea (for a tool about evidence: receipts, citations, marks of proof), and a signature element (type, composition, imagery, or motion). Render them as frames of the main state with the same content, different on at least two structural axes (information order, layout model, interaction model, type class, colour temperature), rate each against criteria taken from the brief, recommend one (RX-PR-09), and let the user choose; then make the rest of the design serve the chosen signature and put its concept in the Visual Brief.",
-            dont: "Show three directions that differ only in colour or copy, choose for the user without showing them, or let the signature be the category's default (for developer tools a terminal or agent-session panel; for SaaS a dashboard screenshot; copy on the left and product on the right), or relabel that default as a concept. A product screen can support the signature, not be it.",
+            do: "Before designing, make three directions, each with a name, a concept taken from the product's own idea (for a tool about evidence: receipts, citations, marks of proof), and a signature element (type, composition, imagery, or motion). Render them as frames of the main state with the same content, different on at least two structural axes (information order, layout model, interaction model, type class, colour temperature), rate each against criteria taken from the brief, recommend one (RX-PR-09), and let the user choose; then make the rest of the design serve the chosen signature and put its concept in the Visual Brief. When the brief names reference products, read each one before it shapes the direction: the principle you borrow, what stays theirs (colours, mascot, signature features), and where you use it.",
+            dont: "Show three directions that differ only in colour or copy, choose for the user without showing them, or let the signature be the category's default (for developer tools a terminal or agent-session panel; for SaaS a dashboard screenshot; copy on the left and product on the right), or relabel that default as a concept. A product screen can support the signature, not be it. Turn a named reference into adjectives (\"calm, white, soft\") or copy what belongs to its brand.",
             why: "Users remember a product by its idea; a correct but generic surface is forgotten and could belong to any competitor.",
             basis: "brand and art direction practice; RX-UI-05 layout from content; rendered variants on named axes, compared side by side, chosen by the user: pattern also in emilkowalski/skills (MIT) prototype; written for RYUX",
-            notWhen: "task UI such as forms, tables, settings, and checkout, where restraint and convention win",
+            notWhen: "task UI such as forms, tables, settings, and checkout, where restraint and convention win: skip the three directions and keep structure and interaction conventional. A new product's brand layer may still carry one signature from the product's own domain (a mark, the type voice, or one brand moment in the flow), never a layout change and never decoration without a job (RX-AS-05)",
             tradeoff: "a strong idea takes a decision someone may disagree with; keep it honest and on brand",
             check: "the swap test (RX-AS-09); review",
         },
@@ -717,7 +729,7 @@ export const RULES = [
             level: "contextual",
             when: "the design needs photos, illustration, 3D, icons, logos, or video",
             do: "Pick each asset's source in this order: real product screens or the brand's own assets; a licensed library (one icon set, photos whose license you can name); a custom or generated asset made from the Visual Brief and labeled illustrative; otherwise a placeholder that looks like one (RX-AS-03). Record where each asset came from.",
-            dont: "Draw or imitate another company's logo, mix icon sets, use a photo you cannot license, or fill a gap with a generic stock scene.",
+            dont: "Draw or imitate another company's logo, invent the product's own mark (RX-AS-11), mix icon sets, use a photo you cannot license, or fill a gap with a generic stock scene.",
             why: "Assets carry claims about the product and its users; an unsourced or borrowed asset is a claim nobody can back.",
             basis: "licensing and trademark practice; RX-UI-07; RX-AS-02",
             notWhen: "a wireframe or internal prototype where placeholders are expected",
@@ -759,7 +771,7 @@ export const RULES = [
             dont: "Create a near-duplicate component or pattern for one screen.",
             why: "Duplicates drift apart, multiply maintenance, and break consistency.",
             basis: "Design-system practice",
-            check: "review",
+            check: "for each new component or token, name the existing ones searched and why none fits; fails on a new one that duplicates an existing one",
         },
         {
             num: 2,
@@ -830,7 +842,7 @@ export const RULES = [
             dont: "Build pointer-only actions, or remove focus outlines without an accessible replacement.",
             why: "Keyboard and switch users navigate and act by focus.",
             basis: "WCAG 2.2 SC 2.1.1, 2.4.3, and 2.4.7; WAI-ARIA APG dialog pattern",
-            check: "review",
+            check: "tab through the render from the top: every control is reached in reading order and shows a visible focus indicator (3:1 against its background); fails on a skipped control, a focus trap, or an invisible focus",
             formerly: ["RX-H-13"],
         },
         {
@@ -842,7 +854,7 @@ export const RULES = [
             dont: "Build structure or controls from styled divs, or ship unlabeled icon buttons.",
             why: "Assistive technology navigates by semantics and announces unlabeled buttons as just \"button\"; native controls bring keyboard and platform behavior for free.",
             basis: "WCAG 2.2 SC 1.1.1, 1.3.1, and 4.1.2",
-            check: "review",
+            check: "read the accessibility tree (a Playwright accessibility snapshot, or the design file's layer types): every control is a native element or has a role, and every one has a name; headings are in order; fails on an unnamed control or a div acting as a button",
         },
         {
             num: 6,
@@ -962,7 +974,7 @@ export const RULES = [
             dont: "Hard-code business rules or API behavior nobody specified.",
             why: "Invented logic ships as real behavior.",
             basis: "ryux product principle (see RX-PR-02)",
-            check: "review",
+            check: "list each rule the UI code computes (fees, limits, eligibility, rounding, dates) and its source (API, spec, brief); fails on any computed from a guess",
         },
         {
             num: 5,
@@ -1092,7 +1104,7 @@ export const RULES = [
             dont: "Invent \"48.000+ users\", \"4,8★\", or \"+12%\".",
             why: "Invented numbers are false claims, however polished the page.",
             basis: `${RUN}: pen.dev landing without ryux`,
-            check: "review",
+            check: "list every number on the screen with its source (brief, docs, data, or a sample label); fails on any number without one",
             formerly: ["RX-C-03"],
         },
         {
@@ -1104,7 +1116,7 @@ export const RULES = [
             dont: "Make up testimonials, reviewers, or customer photos.",
             why: "Fake people are fake endorsements.",
             basis: "ryux anti-slop principle",
-            check: "review",
+            check: "list every person, quote, review, and customer logo on the screen with its source or its sample label; fails on any shown as real without a source",
             formerly: ["RX-C-04"],
         },
         {
@@ -1128,7 +1140,7 @@ export const RULES = [
             dont: "Write \"only 2 left\", \"offer ends tonight\", or fake countdowns with nothing behind them.",
             why: "Manufactured pressure erodes trust once users notice.",
             basis: `NNGroup credibility research; ${RUN}: WhatsApp promo`,
-            check: "review",
+            check: "find every timer, deadline, stock count, and 'only N left'; each comes from the brief or real data; fails on any without a source",
             formerly: ["RX-N-09", "RX-C-10"],
         },
         {
@@ -1151,7 +1163,7 @@ export const RULES = [
             dont: "Add settings, sections, abstractions, or packages \"for later\", or features because similar products have them.",
             why: "Unneeded complexity costs every user and every future change.",
             basis: "Nielsen heuristic 8; Tesler's law of conserved complexity (Tesler, 1980s): some complexity cannot be removed, only moved; clean-code practice",
-            check: "review",
+            check: "list each element, option, state, and dependency the work added and the need it serves; fails on any without one",
             formerly: ["RX-K-05"],
         },
         {
@@ -1184,7 +1196,7 @@ export const RULES = [
             dont: "Treat a tidy, generic layout as done because it passes every other gate; generic restraint is slop too.",
             why: "Removing slop is the floor, not the ceiling; interchangeable design makes the product forgettable.",
             basis: "ryux delivery principle; Critique Design Read: specificity",
-            notWhen: "task UI, where familiarity is the point",
+            notWhen: "task UI, where familiarity is the point: the structure stays familiar; on a new product, ask the swap question of the brand layer only (RX-UI-12)",
             tradeoff: "takes a design decision, not only removals",
             check: "swap test; review",
         },
@@ -1193,12 +1205,24 @@ export const RULES = [
             title: "Count before handoff",
             level: "required",
             gate: "lock",
-            do: "Before handing off, count on the render or in the design file's variables, and report the counts: accent hues 1 (status colors, and secondary colors the brand defines, are named and excluded); grey families 1; corner radii only from the scale, matching the shape lock; display sizes per screen 1; icon sets 1, in the chosen icon style; emoji in interface chrome 0; gradients without a brand reason 0; labels for the same intent 1. A count over its limit fails unless the brief or DESIGN.md gives the reason.",
+            do: "Before handing off, count on the render or in the design file's variables, and report the counts: accent hues 1 (status colors, and secondary colors the brand defines, are named and excluded); grey families 1; corner radii only from the scale, matching the shape lock; display sizes per screen 1; icon sets 1, in the chosen icon style; emoji in interface chrome 0; invented logos or app icons 0 (RX-AS-11); gradients without a brand reason 0; labels for the same intent 1. A count over its limit fails unless the brief or DESIGN.md gives the reason.",
             dont: "Judge consistency by eye only, or hand off a screen with five accent hues, mixed icon sets, or two labels for one action because it looks fine.",
             why: "Counts are harder to talk past than impressions; a design that passed a by-eye review still shipped five hues and the wrong tab icons.",
             basis: `isolation effect (von Restorff 1933): several accents cancel each other out; pattern also in ${AP}, anti-slop counts; written for RYUX; owner review 2026-10-17: withryux.pen passed RYUX with 5+ hues and wrong tab icons`,
             check: "count on the render or the design file's variables; report in the Delivery Gate",
         },
+        {
+            num: 11,
+            title: "The product's own mark",
+            level: "required",
+            gate: "hard",
+            when: "the design has a logo, wordmark, app icon, or favicon",
+            do: "Use the brand's own file wherever the product's mark appears: look in the repo (public/, assets/, the app icon and favicon), DESIGN.md, the design file's components, and what the user attached, and name the file you used. With no file, set the product name in plain text in the brand's type, or leave a visible [LOGO] placeholder, and list the mark as missing in the handoff.",
+            dont: "Stand in for the mark with initials in a circle, an emoji, a generic shape, an invented SVG, a letter cut into a tile, or the name typeset to look like a logo; generate a favicon or app icon the user did not ask for; or redraw the brand's mark instead of using its file. Designing a mark is its own task, done only when the user asks for it.",
+            why: "An invented mark looks finished and is the first thing a team has to throw away; it also passes for a decision nobody made.",
+            basis: `pattern also in superdesign-skill (MIT), logo invariant; RX-UI-13 asset provenance; ryux owner review 2026-10-18 (the logo and favicon are the owner's to make); written for RYUX`,
+            check: "list every mark slot and the file it uses, or the placeholder; fails on a slot filled by an invented mark",
+        },
     ]),
 ];
 // Rules retired in rules 1.3: merged into another rule, or moved into a skill's guide as guidance.
@@ -1290,10 +1314,10 @@ export const QUALITY_LOCKS = [
 // Contextual activation: load only what the task needs (core is always loaded).
 export const ACTIVATION = [
     { task: "UI implementation", skills: ["product", "ux", "ui", "design-system", "frontend", "visual-qa", "anti-slop"] },
-    { task: "Form implementation", skills: ["product", "ux", "forms", "interaction", "accessibility", "edge-cases", "content"] },
+    { task: "Form implementation", skills: ["product", "ux", "forms", "interaction", "accessibility", "edge-cases", "content", "ui", "anti-slop"] },
     { task: "Mobile UI", skills: ["ux", "ui", "responsive", "accessibility", "anti-slop"] },
-    { task: "Checkout or payment", skills: ["product", "interaction", "forms", "content", "edge-cases"] },
-    { task: "Data-heavy view (list, table, dashboard)", skills: ["ux", "edge-cases", "responsive", "design-system", "frontend"] },
+    { task: "Checkout or payment", skills: ["product", "interaction", "forms", "content", "edge-cases", "ui", "anti-slop"] },
+    { task: "Data-heavy view (list, table, dashboard)", skills: ["ux", "edge-cases", "responsive", "design-system", "frontend", "ui", "anti-slop"] },
     { task: "Frontend logic or utilities (formatting, state, data shown to users)", skills: ["frontend", "content", "edge-cases"] },
     { task: "Copy only (UI text, chat, announcements)", skills: ["content", "anti-slop"] },
     { task: "Visual refinement", skills: ["ui", "design-system", "visual-qa", "anti-slop"] },

package/dist/intelligence/guides.js

@@ -67,7 +67,8 @@ export const DESIGN_BODY = `# RYUX Design
    questions alone, most consequential first, at most three, in one message, before designing.
    A product rule that changes which states or actions the screen has (refunds, fees, what happens
    on failure) is a major decision. When the prompt and DESIGN.md disagree, the prompt wins for
-   this task; say so.
+   this task; say so. A DESIGN.md written for a different product (another name, domain, or
+   audience than this brief) sets no direction for this task: say so, and treat direction as unset.
    **Direction is the user's call:** when neither the prompt nor DESIGN.md sets the UI direction
    (character, or brand colour and type) or the motion direction, ask for it in that message (it
    counts toward the three) instead of choosing it yourself. **No DESIGN.md and no product docs is the
@@ -84,14 +85,21 @@ export const DESIGN_BODY = `# RYUX Design
 2. **Understand what exists.** When there is a screen, product, or design system already, read its
    analysis or run Analyze first (capabilities/analyze.md). Existing screens, components, and any
    screenshot or reference provided are your examples: read them before choosing patterns, take
-   their principles, and never copy their facts. Understand before you design.
-3. **Decide with evidence.** For consequential choices, compare two or three patterns, using
+   their principles, and never copy their facts. Understand before you design. When the task
+   redesigns or improves what exists, list what works and keep it; change only what has a named
+   problem (RX-UX-10).
+3. **Read the modules the task needs** from the task table before deciding anything, for example ux,
+   interaction, forms, and content for a form, or ui and responsive for a layout; for any surface
+   with a visual direction, ui and anti-slop as well. The rules shape the first idea, not only the
+   review of it.
+4. **Decide with evidence.** For consequential choices, compare two or three patterns, using
    reference screens when the ryux MCP is connected (RX-PR-09), and rate the evidence (RX-PR-10).
    On a complex or ambiguous surface (a new flow, a dashboard, a multi-step form), name the primary
    task, the one thing that must be seen first, and two or three UX approaches (structure and
    interaction model) before any visual work, and choose by the task; a small change skips this.
-4. **Direction.** Write the Design Direction below. On task UI, follow conventions and the design
-   system. On an expressive surface (hero, landing, onboarding, empty state, brand moment), or when
+5. **Direction.** Write the Design Direction below. On task UI, follow conventions and the design
+   system; a new product's brand layer may carry one signature from its own domain, never a layout
+   change (RX-UI-12, Not when). On an expressive surface (hero, landing, onboarding, empty state, brand moment), or when
    the brief asks for a new look or more personality, explore on the canvas before choosing (RX-UI-12):
    - Render three directions as frames side by side: the main state only, the same content and
      sample data in each, each labelled with a name and a one-line concept.
@@ -106,8 +114,6 @@ export const DESIGN_BODY = `# RYUX Design
    - Then stop and let the user choose. Build only the chosen one into the full design (states,
      widths, Visual Direction, RX-UI-10) and mark the others on the canvas as not chosen. When the
      user has already said to pick for them, continue with the recommendation and say so.
-5. **Read the modules the task needs** from the task table, for example ux, interaction, forms, and
-   content for a form, or ui and responsive for a layout.
 6. **Design in the tool.** Use the Figma MCP or the pen.dev MCP. System first: look for the design
    system that exists (DESIGN.md, a tokens or theme file in the repo, the design file's variables and
    components, a linked library) and build from it. Create only what is missing: variables for color
@@ -118,7 +124,7 @@ export const DESIGN_BODY = `# RYUX Design
 7. **Render and inspect.** Screenshot what you made, check it against the direction and the rules,
    fix, and render again (capabilities/qa.md). Count the values still literal (color, spacing,
    radius, type size) and turn each into a variable or name the exception, then run the counts of
-   RX-AS-10 (accent hues, grey families, radii, display sizes, icon sets, emoji, gradients, labels
+   RX-AS-10 (accent hues, grey families, radii, display sizes, icon sets, emoji, invented marks, gradients, labels
    per intent) and report them in the gate. Run the four hierarchy
    checks from Critique (control beside its data, primary action that reads as an action, not a tab, no fact
    twice, grouped by what the user checks together), fix what fails, render again, and check each fix. List where
@@ -539,7 +545,7 @@ or a cut (RX-A11Y-08).
 | Photography | the brand's own shoot | a licensed library you can name | a stranger presented as a customer |
 | Illustration and 3D | the brand's system | custom or generated from the brief, labeled | a generic character or blob unrelated to the product |
 | Icons | the project's set | one set that matches the chosen icon style (for example Tabler, Iconoir, Phosphor, or Material Symbols), or a custom set drawn to that style | mixed sets, or one-off icons outside the style |
-| Logos | official files from each owner | the name in plain text | a redrawn or imitated logo |
+| Logos | official files from each owner; the product's own file (RX-AS-11) | the name in plain text, or [LOGO] | a redrawn, imitated, or invented logo; initials or an emoji as a mark; a generated favicon or app icon |
 | Video | real product footage | a screen recording of the real product | stock footage implying use |
 | Missing | a placeholder that looks like one (RX-AS-03) | | an invented stand-in |
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ryuxdsgn/design-intelligence",
-  "version": "2.9.3",
+  "version": "2.11.0",
   "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": {