@ryuxdsgn/design-intelligence 2.11.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",
@@ -370,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", [
         {
@@ -476,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"],
         },
         {
@@ -689,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",
@@ -719,7 +732,7 @@ export const RULES = [
             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: 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)",
+            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",
         },
@@ -807,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", [
         {
@@ -1196,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: the structure stays familiar; on a new product, ask the swap question of the brand layer only (RX-UI-12)",
+            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.`;
@@ -127,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}
@@ -272,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).`;
@@ -729,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.11.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": {