@ryuxdsgn/design-intelligence 2.7.1 → 2.8.0

package/dist/intelligence/content.js

@@ -710,11 +710,11 @@ export const RULES = [
             title: "Tokens over one-off values",
             level: "preferred",
             gate: "lock",
-            do: "Use tokens or variables for color, spacing, radius, elevation, and type.",
-            dont: "Hard-code one-off values for things the system already defines.",
-            why: "Tokens keep changes consistent and reviewable.",
-            basis: "W3C Design Tokens Community Group",
-            check: "review",
+            do: "Use tokens or variables for color, spacing, radius, elevation, and type. First look for the ones that exist (DESIGN.md, a tokens or theme file in the repo, the design file's variables and components, a linked library) and use them. When the project has none, define them before the first frame: color roles, a spacing scale, a radius scale, and a type scale (sizes, and font families). In a design tool, create them as the tool's variables and reference them in every value, and make anything that repeats (a row, a button, a bar) a component. After rendering, count the values that are still literal, by kind, and turn each into a token or name why it is an exception.",
+            dont: "Hard-code one-off values for things the system already defines, or define tokens for color only and leave spacing, radius, and type size literal.",
+            why: "Tokens keep changes consistent and reviewable; values that are not tokens drift from frame to frame and state to state.",
+            basis: "W3C Design Tokens Community Group; ryux four-problems baseline 2026-10-16: in all 12 runs, with or without RYUX, spacing, radius, and font size were 100% literal",
+            check: "count literal values after render; review",
         },
         {
             num: 5,

package/dist/intelligence/guides.js

@@ -94,11 +94,17 @@ export const DESIGN_BODY = `# RYUX Design
    Direction (RX-UI-12, RX-UI-10). On task UI, follow conventions and the design system.
 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. Design every state that matters
-   (empty, loading, error) and every width you claim, and source assets on purpose (RX-UI-13).
+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
+   roles, spacing, radius, and type sizes and families before the first frame, and components for
+   repeated elements (RX-DS-03). Building the system does not replace the states: design every
+   state that matters (empty, loading, error, including content that fails to load) and every width
+   you claim, and source assets on purpose (RX-UI-13).
 7. **Render and inspect.** Screenshot what you made, check it against the direction and the rules,
-   fix, and render again (capabilities/qa.md). 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
+   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. 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
@@ -524,8 +530,11 @@ Does not cover: component reuse and tokens (see ryux-design-system).`,
 **Quality Locks** to keep across the product: spacing, typography, color roles, terminology,
 components, interaction patterns and states, responsive behavior, and visual hierarchy.
 
-If the project has no system yet, define the smallest token set the screen needs and use it
-consistently. Do not introduce a component library the project does not use.`,
+Look for the existing system before defining one: DESIGN.md, a tokens or theme file in the repo, the
+design file's variables and components, or a linked library. If the project has no system yet, define
+the smallest token set the screen needs and use it consistently: color roles, a spacing scale, a
+radius scale, and a type scale, not color alone. After rendering, count the literal values left and
+convert them (RX-DS-03). Do not introduce a component library the project does not use.`,
     accessibility: `Accessibility is product quality, not an enhancement. Check:
 
 - **Semantics**: real headings, landmarks, lists, buttons, links, labels.

package/package.json

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