@ryuxdsgn/design-intelligence 2.6.2 → 2.6.3

package/dist/cli/index.js

@@ -358,6 +358,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: "Constraints", hint: "platforms, accessibility target (for example WCAG 2.2 AA), what must not change:",

package/dist/intelligence/content.js

@@ -53,7 +53,7 @@ export const RULES = [
             num: 1,
             title: "State the context first",
             level: "required",
-            do: "Before designing, write down the user, their task, the business goal, the design intent (what the user must understand, feel, and do), the information that matters, the primary action, the constraints, and what success looks like. Take what the prompt and DESIGN.md already give; ask only when a missing answer would change a major decision, at most three questions in one message (none when the context is complete), and write the rest as assumptions.",
+            do: "Before designing, write down the user, their task, the business goal, the design intent (what the user must understand, feel, and do), the information that matters, the primary action, the constraints, and what success looks like. Take what the prompt and DESIGN.md already give; ask only when a missing answer materially affects the user flow, what the product can do, or whether the content is correct, or when neither the prompt nor DESIGN.md sets the UI or motion direction, at most three questions in one message, most consequential first (none when the context is complete). Otherwise make the smallest reasonable assumption, write it down, and continue.",
             dont: "Start from a generic template with no stated user or task, or ask questions the prompt or DESIGN.md already answers.",
             why: "Without a task, design and review drift into taste.",
             basis: "ryux-critique playbook; NNGroup task-based evaluation",
@@ -64,10 +64,11 @@ export const RULES = [
             title: "Unknowns stay assumptions",
             level: "required",
             gate: "hard",
-            do: "List what you do not know as assumptions, and mark the matching UI with [REAL DATA] or a question. Product facts (feature and tool names, commands, integrations, supported platforms, page names) come only from the brief, the repo, or the product's own docs.",
-            dont: "Invent business rules, metrics, user data, permissions, pricing, requirements, or API behavior, or name a tool, command, integration, platform, or page the product does not have.",
-            why: "Invented facts turn into promises and bugs that someone has to unwind.",
-            basis: `${RUN}: an unconstrained agent invented a 30-day trial and user counts`,
+            do: "Sort what the brief does not say into three kinds. Design assumptions (low-risk visual or structural choices such as a merchant category icon or grouping by date): decide them from the context. Unconfirmed capabilities (an action or feature the category usually has, such as sharing a receipt): convention is not proof, so ask when it materially changes the flow or scope; otherwise you may propose it, listed as unconfirmed, never as a requirement. Facts, claims, and policies: take them only from the brief, the repo, or the product's own docs (feature and tool names, commands, integrations, platforms, pages, fees, timings, guarantees).",
+            dont: "Invent business rules, policies, guarantees, metrics, user data, permissions, pricing, requirements, or API behavior, or name a tool, command, integration, platform, or page the product does not have. Do not present an unconfirmed capability as a confirmed one.",
+            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",
         },
         {
@@ -1039,13 +1040,13 @@ export const RULES = [
         },
         {
             num: 3,
-            title: "Placeholders look like placeholders",
+            title: "Sample data is realistic and labeled; placeholders only for what is missing",
             level: "required",
             gate: "hard",
-            do: "Mark temporary content clearly: [REAL DATA], [LOGO], \"Contoh data\".",
-            dont: "Ship placeholder copy or data disguised as final.",
-            why: "Disguised placeholders ship by accident.",
-            basis: "ryux anti-slop principle",
+            do: "Fill mockups with realistic sample content consistent with the brief (names, merchants, amounts in the brief's currency, dates) and list it as sample data in the output. Keep a visible placeholder only for an asset that does not exist yet, such as [LOGO].",
+            dont: "Put [REAL DATA], XXX, or lorem text on the canvas where sample data would do, or ship sample data or placeholder copy as final. A sample-data label does not turn a fee, policy, or claim into a fact (RX-PR-02).",
+            why: "Bracketed values read as unfinished and hide the layout's real behavior; unlabeled sample data ships by accident.",
+            basis: "ryux anti-slop principle; ryux visual benchmark 2.5, 2026-10-09: [Brand] and XXX read as unfinished",
             check: "audit_copy C-01",
             formerly: ["RX-C-05"],
         },

package/dist/intelligence/guides.js

@@ -40,9 +40,9 @@ accessibility, and intentional decisions. Understand the context before deciding
 facts from assumptions; prefer evidence over aesthetic preference; do not invent requirements;
 explain meaningful decisions with their trade-off; validate before claiming.`;
 export const CORE_WORKFLOW = `1. **Understand the request**: who, what task, which product and market (RX-PR-01). Read the
-   RYUX project context in DESIGN.md first when it exists; do not guess what it leaves blank. Ask
-   only when the answer would change a major decision (at most three, usually none), and assume
-   the rest visibly. DESIGN.md answers are direction, not evidence of what users need.
+   RYUX project context in DESIGN.md, then the product docs (Product docs paths, else PRD.md,
+   docs/prd*, docs/product*, README), and name what you read. Ask and record direction as in
+   capabilities/design.md, step 1; assume the rest visibly. DESIGN.md is direction, not evidence.
 2. **Pick the entry point** and read its file.
 3. **Select knowledge**: read the modules the task table lists, and no others.
 4. **Gather evidence**: reference screens through the ryux MCP when connected; otherwise say so.
@@ -61,9 +61,20 @@ export const DESIGN_BODY = `# RYUX Design
 
 1. **Context.** Who, what task, which product and market, and the design intent
    (knowledge/product.md). Take it from the prompt, then DESIGN.md, then knowledge and evidence.
-   Ask only when a missing answer would change a major decision: those questions alone, at most
-   three, in one message, before designing. Complete context means no questions. Never ask what
-   the prompt or DESIGN.md already answers; write the rest down as assumptions (RX-PR-01).
+   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.
+   **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. Complete context means no questions. Never ask what the prompt, DESIGN.md, or the
+   product docs already answer. For the rest, make the smallest reasonable assumption, write it
+   down, and continue (RX-PR-01, RX-PR-02).
+   **Record direction answers.** When the user answers a UI or motion direction question, write the
+   answer into the UI direction or Motion direction field of the RYUX project context in DESIGN.md:
+   between \`<!-- ryux-context:start -->\` and \`<!-- ryux-context:end -->\`, one line per field
+   (\`- **UI direction**: Calm, trustworthy\`). If DESIGN.md or the block does not exist, create it
+   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.
 3. **Decide with evidence.** For consequential choices, compare two or three patterns, using
@@ -83,7 +94,8 @@ export const DESIGN_BODY = `# RYUX Design
    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.
+   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.
 
 Do not edit frames you were not asked to change. Do not hand off a design as "final" with
 placeholder or invented content.
@@ -120,7 +132,11 @@ Asset direction per asset: purpose, source, style, composition, context, consist
                avoid, provenance (observed, sourced, illustrative, generated, inferred)
 Responsive     what changes, stays, disappears, or stacks at each width
 
-Assumptions    everything guessed, visible
+Assumptions    kept apart, all visible:
+               design assumptions (low-risk choices made from context);
+               unconfirmed capabilities (actions or features on the canvas the brief did not
+               confirm; proposed, not requirements); sample data (realistic mockup content,
+               never a fact, RX-AS-03)
 Decisions      one Decision Receipt per major decision (below)
 \`\`\`
 
@@ -223,10 +239,13 @@ export const GUIDES = {
 5. **Primary action**: the one thing this screen exists for.
 6. **Constraints**: platform, data that exists, technical or legal limits.
 7. **Success**: how would you know the screen works?
-8. **Assumptions**: everything you had to guess. Keep them visible.
+8. **Assumptions**: everything you had to guess, kept visible and sorted into design assumptions,
+   unconfirmed capabilities, and sample data.
 
-Unknown facts stay assumptions. Do not invent business rules, metrics, user data, permissions,
-pricing, requirements, or API behavior; mark them [REAL DATA] or ask.
+Unknown facts stay assumptions. Do not invent business rules, policies, metrics, user data,
+permissions, pricing, requirements, or API behavior; ask when one materially affects the flow or
+correctness, otherwise leave it out. Mockup content is realistic sample data, labeled (RX-PR-02,
+RX-AS-03).
 
 Find evidence with the ryux MCP (\`search_screens\`, \`get_flow\`, \`get_local_pattern\`) and cite the
 \`screen_id\`, or call the decision a judgment call.

package/dist/render.js

@@ -134,7 +134,8 @@ ${GUIDES[s.id]}${extra}
 ${s.evidence} Without the ryux MCP, say the evidence comes from the design and standards alone.
 
 > Hard Gates always apply, whichever skills are loaded: no invented numbers, people, urgency, business
-> rules, or terms; no placeholder shipped as final; no missing critical states. See \`ryux-core\`.
+> rules, or terms; no placeholder shipped as final; no missing critical states. Labeled sample data is
+> not an invented number; an unconfirmed capability is never presented as confirmed. See \`ryux-core\`.
 
 ## Rules
 

package/package.json

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