@ryuxdsgn/design-intelligence 2.10.0 → 2.12.0

package/dist/intelligence/content.js

@@ -100,7 +100,7 @@ export const RULES = [
             num: 5,
             title: "The product's market first",
             level: "required",
-            do: "Start from how users in the product's own market pay, sign in, write addresses, and read money and dates; check a pattern from another market before reusing it. Take the market from the brief or the codebase, and ask when it is unclear.",
+            do: "Start from how users in the product's own market pay, sign in, write addresses, and read money and dates; check a pattern from another market before reusing it. Take the market from the brief or the codebase, and ask when it is unclear. When the brief does not name payment methods (or another market-standard capability), show the market's standard set as unconfirmed capabilities, labeled as proposed in Assumptions, rather than leaving them out: a market's table stakes are not \"for later\" (RX-AS-06). Ask when the set would change the flow.",
             dont: "Import one market's checkout, currency, language, or tax rules into a product built for another market.",
             why: "Payment, address, and trust habits differ by market (local payment rails, address formats, messaging channels).",
             basis: "ryux taxonomy of local patterns",
@@ -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", [
         {
@@ -358,6 +370,19 @@ export const RULES = [
             basis: `Apple HIG playing haptics; pattern also in ${AP}; written for RYUX`,
             check: "review the interaction spec",
         },
+        {
+            num: 17,
+            title: "Choices that change the price sit with the price",
+            level: "preferred",
+            when: "a screen shows a total that the user's choices change: payment method, insurance, delivery or service tier, add-ons",
+            do: "Show each price-changing choice with its current value and its cost inline on the screen that shows the total, so the user sees what they pay for before they confirm.",
+            dont: "Hide a choice that changes the price behind a list row or a later screen, or show the total without the choices that make it up.",
+            why: "People check a total against the choices behind it; a cost they cannot see next to the total reads as a surprise fee.",
+            basis: "ryux run: blind review of a delivery checkout 2026-10-20; NNGroup visual hierarchy; written for RYUX",
+            notWhen: "a single fixed price with no choices on the screen",
+            tradeoff: "a longer checkout screen; group the choices so the total stays visible",
+            check: "review the checkout render: every price-changing choice visible next to the total",
+        },
     ]),
     ...skill("forms", [
         {
@@ -464,7 +489,7 @@ export const RULES = [
             dont: "Ship only the filled, happy-path screen.",
             why: "Users meet the other states often, and they are where trust is lost.",
             basis: "Nielsen heuristics 1 and 9",
-            check: "audit_ui",
+            check: "write a matrix in the Delivery Gate: each data view or action × loading / empty / error / success → frame name, or \"cannot happen: reason\"; a blank cell is a FAIL; audit_ui when the ryux MCP is connected",
             formerly: ["RX-H-14"],
         },
         {
@@ -677,7 +702,7 @@ 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 (objective, concept, composition, color, material, lighting, motion, avoid) before designing an expressive surface or generating images, 3D, or motion.",
+            do: "Derive the art direction from the brand, the audience, the product context, and reference screens, and write it as a Visual Brief (objective, concept, composition, color, material, lighting, motion, avoid) before designing an expressive surface or generating images, 3D, or motion. 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.",
             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",
@@ -703,11 +728,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 must carry one signature from the product's own domain (a mark, the type voice, a colour temperature, or one brand moment in the flow), never a layout change and never decoration without a job (RX-AS-05). Record it in the Delivery Gate UI line",
             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",
         },
@@ -795,6 +820,19 @@ export const RULES = [
             basis: `pattern also in ${AS} R-21, R-34; written for RYUX`,
             check: "render each theme; contrast check",
         },
+        {
+            num: 6,
+            title: "The component sheet is a spec",
+            level: "preferred",
+            gate: "lock",
+            do: "Lay out each component as a labeled grid: one row per property, one column per state (default, hover on web, pressed, disabled, loading, error), each cell labeled with its variant name, and one line of usage under each component; no overlapping or clipped variants. Render and inspect the sheet like a screen.",
+            dont: "Leave variants scattered, unlabeled, or cut off at the frame edge.",
+            why: "Developers build from the component sheet; a variant they cannot find or read gets rebuilt or guessed.",
+            basis: "ryux run: blind review of a delivery flow 2026-10-20; design-system practice; written for RYUX",
+            notWhen: "a single screen with no shared components",
+            tradeoff: "takes time to lay out; pays back at handoff",
+            check: "render the sheet; every variant visible and labeled",
+        },
     ]),
     ...skill("accessibility", [
         {
@@ -1184,7 +1222,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: keep the structure familiar, but run the swap test on the brand layer (palette, type, surfaces, iconography, map styling) and report the answer. On a new product, \"only the logo would change\" is a FAIL (RX-UI-12)",
             tradeoff: "takes a design decision, not only removals",
             check: "swap test; review",
         },

package/dist/intelligence/guides.js

@@ -36,7 +36,7 @@ Keep the capabilities apart; do not collapse them into one generic "design" answ
 | Design | What should we do, and why? | "Keep 24px: it matches the existing layout system." |
 | Critique | Is this decision right? | "24px leaves the table too sparse at 1440 for daily use." |
 | QA | Does the build match the intent? | "The build uses 16px where the design says 24px." |`;
-export const CORE_PRINCIPLE = `Do not optimize for visual novelty. Optimize for clarity, usability, consistency, product fit,
+export const CORE_PRINCIPLE = `Novelty is not a goal; a recognisable brand layer is: familiar structure, distinct surface. Optimize for clarity, usability, consistency, product fit,
 accessibility, and intentional decisions. Understand the context before deciding; separate observed
 facts from assumptions; prefer evidence over aesthetic preference; do not invent requirements;
 explain meaningful decisions with their trade-off; validate before claiming.`;
@@ -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,7 +85,9 @@ 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.
+   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
@@ -95,7 +98,8 @@ export const DESIGN_BODY = `# RYUX Design
    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.
 5. **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
+   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.
@@ -123,18 +127,32 @@ export const DESIGN_BODY = `# RYUX Design
    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
+   twice, grouped by what the user checks together), fix what fails, render again, and check each fix.
+   Weight ranking: list the screen's blocks in order of visual weight (size × contrast × surface) and
+   compare it with the priority order from step 4. If two blocks of different priority render with the
+   same heading style and container, change one. On a checkout or order screen, the choice that sets
+   the price and the total rank first and second. A width check is a test, not a deliverable: list
+   what broke at each width (wrap, truncation, overflow), fix it or record why it is acceptable, and
+   render again; RESPONSIVE PASS names the findings and their fixes. List where
    the render differs from the Design Direction (hierarchy, states, widths) and fix or record each one. Check the result against the Liveliness you set, and
    put each prominent or decorative element through the purpose gate (RX-AS-05: purpose,
    contribution, necessity); on calm task UI, deliberate restraint is a valid answer. Then judge the main state as a
    reviewer would, not as a checklist: rate Clarity, Hierarchy, and Specificity from the Design Read
    (capabilities/critique.md), plus Craft (type steps, spacing rhythm, alignment, detail), Strong,
-   Adequate, or Weak with one reason each, and fix anything Weak before the gate. Generated images and illustrations arrive
+   Adequate, or Weak with one reason each, and fix anything Weak before the gate. Reference check:
+   put the main state beside two or three reference apps (named in the brief, from the Reference Read,
+   or comparable screens from the ryux MCP) and write, per reference, what holds up and what reads
+   weaker or more generic in yours (surface, hierarchy, brand layer, assets); no score. Fix what reads
+   weaker for the task, and say so when no reference was available. Generated images and illustrations arrive
    asynchronously: wait until each one has landed and render again before exporting or closing the
    gate. Never finish with an asset still pending.
 8. **Fact check, then the gate.** Check every product fact on the canvas (tool and command names,
-   integrations, platforms, pages, numbers) against the brief or the repo (RX-PR-02), then close
-   with the Delivery Gate, saying what was not designed, such as other widths or states. If you
+   integrations, platforms, pages, numbers) against the brief or the repo (RX-PR-02). Canvas copy is
+   for the team, not for RYUX: annotations, state captions, and labels on the canvas use plain
+   language ("Shown while prices load; button disabled"); rule IDs, gate results, and Decision
+   Receipts go in the Design Direction or the final message, never in frames meant for review or
+   handoff. A handoff frame annotates, in plain language, the interaction behaviour, the truncation
+   rule for each text that can overflow, and each component's code name. Then close with the Delivery Gate, saying what was not designed, such as other widths or states. If you
    wrote DESIGN.md, say so in the final message: which file and which fields.
 
 ${UNTRUSTED_CONTENT}
@@ -268,7 +286,7 @@ Optional sources (the ryux MCP, Figma, a browser, screenshots, other reference l
 evidence when connected; none is required.`;
 export const CORE_HONESTY = `Report what was checked, how, and what was not available. Do not claim "pixel perfect",
 "fully accessible", "production ready", "senior-level", or "UX optimized" without evidence. Say
-"Keyboard and focus checked by hand; no automated accessibility test was available" instead.`;
+"Keyboard and focus checked by hand; no automated accessibility test was available" instead. Rule IDs and gate results belong in your report, never on the design itself.`;
 export const CORE_DECISION_RECORD = `For consequential choices (RX-PR-09) and deviations, write **Decision**, **Options** compared, **Evidence**,
 **Trade-off**, and **Choice**. Evidence is Strong (2+ comparable screen_ids), Thin (one, or another context),
 or None (no screen_id: a judgment call). With None on a consequential choice, show options or ask (RX-PR-10).`;
@@ -725,6 +743,10 @@ run the purpose gate; keep it when the answer is real, as in the last column.
 | Glass, glow, and blur on every layer | decoration without a job that also lowers contrast | one surface treatment with a purpose (RX-AS-05, RX-A11Y-01) | one overlay needs to show what is behind it |
 | Stock teamwork or handshake photos | borrowed people implying endorsement | real people with consent, or no people (RX-AS-02, RX-UI-13) | never as evidence of customers |
 | Cards inside cards, surfaces on surfaces | every nesting level costs a border, a radius, and padding, and the grouping stops meaning anything | one container per real group; separate inside it with spacing or a divider (RX-UI-01) | the inner surface is a distinct object the user acts on, such as a selectable option |
+| Every group boxed in the same white bordered card | the stack of equal boxes flattens priority and reads as a template | one container for the decision the user makes; other groups flat, with a heading and a divider (RX-UI-01) | each box is a selectable option the user compares |
+| One "safe" accent on white with neutral grey everything | the default palette of generated UI; nothing in it is the brand's | colour temperature and surface tone chosen from the product's character (RX-UI-10) | the brand already defines it |
+| A placeholder-grey illustrated map | reads as unfinished, and the map is the product's core visual | a styled map with streets, labels, and the route rendered in the brand palette | wireframe stage, labeled as such |
+| Question headings by default ("Where to?", "What are you sending?") on every step | a generated voice once it repeats; the step's label says less than a plain noun would | a plain label for the field or step; a question only where it is clearest | it is the market's convention, with an observed screen (RX-PR-04) |
 | One record split into a grid of cards | details that are read together (an order, a profile, a transaction) are scattered into equal boxes | one block with labeled rows or a table (RX-UI-05) | each card is a separate item the user compares or acts on |
 | A dashboard of KPI tiles and charts that answer no question | decoration in place of the decision the screen supports | lead with what needs attention and the next action; dense tables where people scan (RX-UI-01, RX-UX-01) | each tile drives a decision and links to its detail |
 | Display-size headings on task UI | a hero-sized title pushes the data and the action below the fold | a heading sized for its rank in the page (RX-UI-01, RX-UI-03) | it is the single message of a marketing or brand page |

package/dist/render.js

@@ -37,7 +37,7 @@ export function deliveryGateTemplate() {
     const lines = [...GATE_AREAS, "FINAL"].map((a) => a === "FINAL"
         ? `${a.padEnd(width)}PASS | FAIL | NOT VERIFIED`
         : a === "UI"
-            ? `${a.padEnd(width)}PASS | FAIL | NOT VERIFIED | N/A  · one-line reason · point of view: <concept> | task UI`
+            ? `${a.padEnd(width)}PASS | FAIL | NOT VERIFIED | N/A  · one-line reason · point of view: <concept> | task UI, signature: <signature>`
             : a === "PRODUCT"
                 ? `${a.padEnd(width)}PASS | FAIL | NOT VERIFIED | N/A  · one-line reason · evidence Strong | Thin | None`
                 : `${a.padEnd(width)}PASS | FAIL | NOT VERIFIED | N/A  · one-line reason`);

package/package.json

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