@ryuxdsgn/design-intelligence 2.6.5 → 2.8.0

package/dist/cli/index.js

@@ -6,7 +6,7 @@ import * as p from "@clack/prompts";
 import pc from "picocolors";
 import { AGENT_TARGETS, AGENTS_MD_INLINE, LEGACY_CURSOR_RULES_DIR, LEGACY_SKILL_DIRS, } from "../adapters.js";
 import { ALL_INSTALLABLE_IDS } from "../intelligence/content.js";
-import { CLI_CMD, CONTEXT_END, CONTEXT_FILE, CONTEXT_START, MARK_START, MCP_LOCAL_ADD_CMD, MCP_STATUS, VERSION } from "../product.js";
+import { CLI_CMD, CONTEXT_END, CONTEXT_FILE, CONTEXT_START, MARK_START, MCP_STATUS, VERSION } from "../product.js";
 import { validateBundle } from "../validate.js";
 import { renderAgentsBlock, renderBundle, renderPointerBlock, SKILL_NAME } from "../render.js";
 import { hasBlock, readIfExists, rel, removeBlock, removePath, upsertBlock, writeFileEnsured } from "./fsutil.js";
@@ -359,7 +359,7 @@ const CONTEXT_FIELDS = [
     },
     { label: "Brand and design system", hint: "" },
     { label: "Product docs", hint: "paths RYUX reads for product facts, for example docs/prd.md:" },
-    { label: "Evidence sources", hint: `RYUX MCP (hosted server not live yet; local: ${MCP_LOCAL_ADD_CMD}), Figma files, reference URLs:` },
+    { label: "Evidence sources", hint: "RYUX MCP (not available yet), Figma files, reference URLs:" },
     {
         label: "Constraints", hint: "platforms, accessibility target (for example WCAG 2.2 AA), what must not change:",
         ask: { flag: "constraints", group: "Project", question: "What must RYUX keep or support?", multi: true, options: [

package/dist/intelligence/content.js

@@ -646,10 +646,10 @@ export const RULES = [
             title: "Motion earns its level",
             level: "contextual",
             when: "the design adds motion or transitions",
-            do: "Classify each motion: L1 state feedback, L2 component transition, L3 page transition, L4 storytelling, L5 decorative. The higher the level, the stronger the reason it needs. Then weigh how often people see it: a surface opened many times a day (command palette, shortcut, core navigation, list selection) appears and closes without movement, at most a fade too short to notice; standard transitions belong to occasional surfaces (modal, drawer, toast), and expression to rare or first-time moments. Take timing and easing from one motion personality, define them once as motion tokens, animate transform and opacity rather than layout properties, and honor reduced motion (RX-A11Y-08).",
-            dont: "Animate everything, give a surface people open many times a day an entrance they must sit through, use one generic duration and easing (transition: all 0.3s) everywhere, or let decorative motion delay content or input.",
+            do: "Classify each motion: L1 state feedback, L2 component transition, L3 page transition, L4 storytelling, L5 decorative. The higher the level, the stronger the reason it needs. Then weigh how often people see it: a surface opened many times a day (command palette, shortcut, core navigation, list selection) appears and closes without movement, at most a fade too short to notice; standard transitions belong to occasional surfaces (modal, drawer, toast), and expression to rare or first-time moments. Take timing and easing from one motion personality, define them once as motion tokens, animate transform and opacity rather than layout properties, and honor reduced motion (RX-A11Y-08). Anything that opens and closes (menu, popover, dialog, drawer) uses transitions that can reverse halfway, so a close or reopen mid-animation turns back from where it is, and it closes no slower than it opened.",
+            dont: "Animate everything, give a surface people open many times a day an entrance they must sit through, play an open-only keyframe animation on something people can close or reopen at any moment, use one generic duration and easing (transition: all 0.3s) everywhere, or let decorative motion delay content or input.",
             why: "Motion directs attention; unearned motion steals it from the task and can make some people unwell.",
-            basis: `NNGroup animation and usability guidance; WCAG 2.3.3 animation from interactions; frequency check: pattern also in ${EK} find-animation-opportunities, written for RYUX`,
+            basis: `NNGroup animation and usability guidance; WCAG 2.3.3 animation from interactions; frequency check: pattern also in ${EK} find-animation-opportunities; reversible open and close: pattern also in ${EK} animate; both written for RYUX`,
             notWhen: "L1 feedback on standard controls that follows the platform defaults",
             tradeoff: "fewer flourishes on marketing pages",
             check: "review; reduced-motion test",
@@ -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,
@@ -758,10 +758,10 @@ export const RULES = [
             title: "Keyboard and visible focus",
             level: "required",
             gate: "hard",
-            do: "Make actions operable from the keyboard (path-based input such as drawing excepted), show a visible focus indicator, and keep focus order the same as the visual order.",
+            do: "Make actions operable from the keyboard (path-based input such as drawing excepted), show a visible focus indicator, and keep focus order the same as the visual order. When a dialog, menu, or popover closes, put focus back on the element that opened it, or on the nearest sensible element if that one is gone.",
             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",
+            basis: "WCAG 2.2 SC 2.1.1, 2.4.3, and 2.4.7; WAI-ARIA APG dialog pattern",
             check: "review",
             formerly: ["RX-H-13"],
         },
@@ -976,7 +976,7 @@ export const RULES = [
             num: 1,
             title: "Render, inspect, fix, render again",
             level: "required",
-            do: "Render the result at the target viewport (browser, screenshot, or design-tool export), inspect the main state, one empty or error state, and the smallest supported width, rank issues by impact, fix from the top, and render again; if no render tool is available, say so in the report.",
+            do: "Render the result at the target viewport (browser, screenshot, or design-tool export), inspect the main state, one empty or error state, and the smallest supported width, look for the defects source code hides (misaligned edges, type or spacing off the scale, density wrong for the task, overflow and clipping, a component that looks different from its siblings, a control that does nothing), rank issues by impact, fix from the top, and render again; name the widths and states you inspected, and if no render tool is available, say so in the report. Whether the design itself is right or intentional is Critique's call; QA reports what it can verify.",
             dont: "Claim visual quality for a layout you have only seen as code, or fix by guesswork without checking the result.",
             why: "Overlaps and clipping are invisible in source and obvious on screen; the loop turns a draft into a reviewed result.",
             basis: `${RUN}: two runs shipped overlaps they never saw`,

package/dist/intelligence/critique.js

@@ -32,15 +32,24 @@ findings
 3. **Evidence over taste.** Every finding names its source; severity 3 or more needs a real
    comparison \`screen_id\` when the ryux MCP is connected.
 4. **Honest scope.** A static frame shows no hover, focus, loading, or narrow widths. Say what was
-   not tested, and lower the confidence of anything inferred.
+   not tested, and lower the confidence of anything inferred. Missing from the artifact is not
+   missing from the product: a frame without a loading state shows the frame, not the build.
 5. **Concise and prioritized.** At most 12 findings; the ones that hurt users most come first.
+   At equal severity, the higher layer (step 5) comes first: a flow problem before a spacing one.
+6. **A preference is not a defect.** A taste (rounder corners, another typeface, more white space)
+   becomes a finding only when the brief, evidence, a requirement, or a stated context reason makes
+   it one; otherwise list it under "Optional ideas" or leave it out.
 
 ## Steps
 
 ### 1. Context
 
 Who the user is, what task happens on this screen, the platform, and the point in the flow. If the
-request does not say, infer it from the design and list it as an assumption.
+request does not say, infer it from the design and list it as an assumption. Name the surface type,
+because it decides which Design Read dimensions weigh most: **task UI** (settings, tables, checkout:
+Clarity, Efficiency, Recoverability), **flow or form** (Confidence, Recoverability), or **expressive
+surface** (hero, landing, onboarding, app home with a personality brief: Specificity and
+Coherence weigh more).
 
 ### 2. Analyze first
 
@@ -58,11 +67,11 @@ Rate each dimension **Strong**, **Adequate**, or **Weak**, with one sentence of
 | --- | --- |
 | Clarity | Can the user understand what this screen is for? |
 | Hierarchy | Can the user identify what matters first? |
-| Coherence | Does it feel like part of the same product? |
+| Coherence | Does it feel like part of the same product, and does it keep the decisions already stated (DESIGN.md, an earlier Design Direction)? |
 | Density | Is the information density right for how often and how carefully it is used? |
 | Confidence | Does the user have enough information to act safely (cost, consequence, status)? |
 | Efficiency | Can the task be done without unnecessary work? |
-| Specificity | Does it feel designed for this product, or could it belong to any generic SaaS app? |
+| Specificity | Does it feel designed for this product, or could it belong to any generic app? Use the swap test (RX-AS-09). |
 | Recoverability | Can users recover from mistakes and failures? |
 | Accessibility | Can people with different abilities and input methods operate and understand it? |
 
@@ -79,6 +88,12 @@ Read the knowledge modules that apply and walk the design with their rules. [Req
 gate, [Preferred] rules need a reason when broken, and [Contextual] rules count only when their
 situation is present. Use their "Not when" lines so a rule is not applied mechanically.
 
+Walk the layers in the table's order, from purpose down to detail: what the screen is for, then
+structure and flow, then interaction and usability, then hierarchy, then type, spacing, density,
+and color, then components and the design system, then accessibility and responsive behavior, then
+edge cases and feedback. A problem in a higher layer often explains the ones below it (a weak
+hierarchy is often an unclear goal); report the cause once, not each symptom.
+
 | Category | Skill | Look for |
 | --- | --- | --- |
 | Product | ryux-product | stated purpose, one primary action, invented facts |
@@ -116,21 +131,37 @@ RYUX rule in \`issue\`:
 The tool rejects major findings without valid evidence, caps the list at 12, and returns PASS or
 FAIL. Without the MCP, say the evidence comes from the design and standards alone.
 
-### 7. Report
+### 7. Validate before reporting
+
+Check every candidate finding before it reaches the report:
+
+- **Can the source show it?** A screenshot supports hierarchy, contrast, and copy; it cannot prove
+  that a button is broken or that a state is missing from the product.
+- **Does the criterion apply** to this surface type and this brief?
+- **Is it a duplicate** of another finding, or a symptom of one?
+- **Is there a reasonable other reading** (a deliberate choice the brief explains)?
+- **Does the fix address the cause** you observed, not just the symptom?
+
+A finding that fails moves to "Not verifiable from this source" or is dropped. Fewer, true findings
+beat a long list.
+
+### 8. Report
 
 Each finding uses this schema:
 
 | Field | Content |
 | --- | --- |
 | ID | C-01, C-02, ... |
-| Severity | 0 not a problem · 1 cosmetic · 2 minor · 3 major · 4 catastrophic |
+| Severity | 4 critical (blocks the task, loses money or data, excludes users) · 3 high (major) · 2 medium (minor) · 1 low (cosmetic) · 0 not a problem |
 | Category | one of the categories above |
 | Finding | where it is and what the problem is |
 | Evidence | what you saw: the capture, a measured value, a comparison screen |
-| Impact | who is affected, in which task, and how badly |
-| Recommendation | a concrete fix |
+| Status | Confirmed (the source shows it) · Hypothesis (likely, not shown) · Not verifiable from this source |
+| Impact | who is affected and in which task; a predicted consequence is worded as one ("may") |
+| Recommendation | the smallest concrete change that removes the cause; name a larger redesign only when no small change can |
 | Confidence | High (seen directly), Medium (partly seen, such as one width), Low (inferred) |
 | Source | the RYUX rule ID, plus a screen_id, a standard (WCAG SC), or "this design" |
+| Verify by | how a revision would show it is fixed: re-render and check X, measure Y, test Z |
 
 \`\`\`
 Verdict: one sentence (what works, the biggest risk)
@@ -146,12 +177,20 @@ Design Read
   (all nine)
 
 Findings (most severe first, at most 12)
-  C-01 · severity 3 · Interaction · confidence High
-    Finding:         Payment confirmation shows no status while verifying
-    Evidence:        no loading or progress element in the frame (Observed)
+  C-01 · severity 3 high · Interaction · confidence Medium · Hypothesis
+    Finding:         The design shows no status while the payment verifies
+    Evidence:        no loading or progress element in any frame provided (Observed in the
+                     frames; the build was not tested)
     Impact:          buyers paying by QRIS may tap twice and pay twice
     Recommendation:  show status with a time estimate; disable the button while verifying
     Source:          RX-IX-02; scr_demo_001
+    Verify by:       a verifying-state frame exists and the button reads as disabled in it
+
+Not verifiable from this source
+  - ...
+
+Optional ideas (preferences, not defects)
+  - ...
 
 What works (keep it)
   - ...
@@ -166,6 +205,10 @@ Fix priorities
 - Don't edit the source file while reviewing.
 - Don't give a finding without a location, a source, and a reason.
 - Don't raise severity to major without evidence, or claim "app X does this" without a \`screen_id\`.
-- Don't mark an inferred issue High confidence.
-- Don't paste generic advice ("modernize", "add white space") without a real problem.
+- Don't mark an inferred issue High confidence, or call a Hypothesis Confirmed.
+- Don't claim a behavior was tested when you saw only a static image.
+- Don't report a preference as a defect (principle 6).
+- Don't paste generic advice ("modernize", "cleaner", "improve the spacing", "more hierarchy"):
+  name the element, the problem, its impact, and the change.
+- Don't turn a finding into an unrelated redesign; fix what the finding names.
 - Don't call the result "fully accessible" or "UX optimized"; say what was checked.`;

package/dist/intelligence/guides.js

@@ -64,6 +64,9 @@ export const DESIGN_BODY = `# RYUX Design
    Read the product docs first (the router, step 1). Ask only when a missing answer materially
    affects the user flow, what the product can do, or whether the content is correct, those
    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.
    **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
@@ -78,20 +81,35 @@ export const DESIGN_BODY = `# RYUX Design
    with those two fields. Change only those field lines; leave every other line as it is. Your own
    assumptions do not go into DESIGN.md.
 2. **Understand what exists.** When there is a screen, product, or design system already, read its
-   analysis or run Analyze first (capabilities/analyze.md). Understand before you design.
+   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
    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 an expressive surface (hero, landing,
    onboarding, empty state, brand moment), write three directions, choose one, and fill the Visual
    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). 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. Generated images and illustrations arrive
+   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
    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,
@@ -191,7 +209,9 @@ export const BUILD_BODY = `# RYUX Build
    integration tests for critical flows such as checkout, payment, and form submit. Use the
    repo's runner; with none, propose one and ask before adding it (RX-FE-14).
 6. **Render and verify.** Run it and the tests, check every width and state, and fix deviations
-   from the design (capabilities/qa.md).
+   from the design (capabilities/qa.md). When changing an existing screen, also check that what
+   you did not mean to change still works: neighbouring screens, shared components, and the flow
+   around the change.
 7. **Close with the Delivery Gate.** CODE QUALITY and VISUAL QA need real checks (typecheck,
    tests, render), or say what was not run.`;
 export const CORE_EVIDENCE = `Say where every claim comes from:
@@ -227,12 +247,12 @@ export const CORE_HONESTY = `Report what was checked, how, and what was not avai
 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).`;
-export const GATE_RULES = `- Each area is PASS, FAIL, NOT VERIFIED (it applies, but the evidence was not available: name what is missing), or N/A (it does not apply: say why).
+export const GATE_RULES = `- Each area is PASS, FAIL, NOT VERIFIED (it applies, but the evidence was not available: name what is missing), or N/A (it does not apply: say why). Scale the gate to the task: a copy fix or a one-component change marks the areas it cannot affect N/A, one line each.
 - An area FAILS when a [Required] rule in its skills fails without a written exception.
 - A Hard Gate failure cannot be excepted: fix it before declaring the work complete.
-- VISUAL QA without a render is NOT VERIFIED; say which render tool was used.
+- VISUAL QA without a render is NOT VERIFIED; a PASS names the render tool, the widths, and the states inspected.
 - CODE QUALITY is NOT VERIFIED while changed logic has no test run; say which checks ran (typecheck, tests).
-- FINAL is FAIL if any area fails, NOT VERIFIED if none fails but one is not verified, else PASS. PASS means the checked criteria were met, not that the design is good.`;
+- FINAL is FAIL if any area fails, NOT VERIFIED if none fails but one is not verified, else PASS. PASS means the checked criteria were met, not that the design is good or was validated with users ("not tested with users" unless it was).`;
 export const GUIDES = {
     product: `Answer these before any layout exists. Write the answers down; they are the brief.
 
@@ -434,7 +454,8 @@ The states themselves (waiting, result, recovery) are defined in ryux-interactio
 RX-IX-02); motion only makes them visible, and it never compensates for weak UX. Decide the trigger,
 duration, easing, distance, opacity or scale, and how several elements are choreographed. Define
 duration and easing once as motion tokens, and animate transform and opacity rather than layout
-properties (width, height, top, margin), which cause jank.
+properties (width, height, top, margin), which cause jank. What opens and closes should be able to
+reverse halfway: use transitions, not an open-only keyframe animation.
 
 | Level | Examples | Needs |
 | --- | --- | --- |
@@ -509,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.
@@ -623,5 +647,10 @@ run the purpose gate; keep it when the answer is real, as in the last column.
 | A small badge above the headline that repeats it | a label that adds no information | cut it, or say something the headline does not | it carries real status: beta, new version, date |
 | Endless floating, looping, or scroll-triggered motion | decorative motion with no reason, competing with the task | a single L4 moment with a message, or none (RX-UI-11) | it shows state, continuity, or the product's idea once |
 | 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 |`,
+| 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 |
+| 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 |
+| A landing-page layout for a product screen | hero, feature rows, and a closing CTA on an app screen, a settings page, or a tool | the structure the task needs: list, detail, form, or workspace (RX-UI-05) | the surface really is marketing |`,
 };

package/dist/product.js

@@ -4,10 +4,10 @@ const pkg = createRequire(import.meta.url)("../package.json");
 /** The RYUX product version (npm package, skill, plugins, and rules share it). */
 export const VERSION = pkg.version;
 export const MCP_NAME = "ryux";
-/** Until the hosted MCP is live, every surface says so instead of printing a dead connect command. */
-export const MCP_LOCAL_ADD_CMD = `claude mcp add --transport http ${MCP_NAME} http://localhost:8787/mcp`;
+/** Until the hosted MCP is live, every surface says so. No connect URL is printed or written into files
+ *  the agent reads: self-hosting steps live only in apps/mcp/README.md. */
 export const MCP_STATUS = "The hosted ryux MCP is not live yet. RYUX works without it and rates evidence None. " +
-    `To run the server yourself, see https://github.com/ryuxdsgn/design-intelligence/tree/main/apps/mcp, then: ${MCP_LOCAL_ADD_CMD}`;
+    "To run the server yourself, see https://github.com/ryuxdsgn/design-intelligence/tree/main/apps/mcp.";
 export const CLI_CMD = "npx @ryuxdsgn/design-intelligence";
 export const MARK_START = "<!-- ryux-rules:start -->";
 export const MARK_END = "<!-- ryux-rules:end -->";

package/package.json

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