@ryuxdsgn/design-intelligence 2.11.0 → 2.13.0

package/dist/intelligence/analyze.js

@@ -7,7 +7,8 @@ export const ANALYZE_BODY = `# RYUX Analyze
 > What is actually in this interface?
 
 Analyze answers "what exists?" and nothing more: it describes an existing design so that the next
-decision (design, build, or critique) starts from facts. It is not screenshot-to-code, and it does not judge quality; that is
+decision (design, build, or critique) starts from facts; it is the Understand stage of the core
+workflow (SKILL.md) on its own. It is not screenshot-to-code, and it does not judge quality; that is
 \`ryux-critique\`. When the ryux MCP is connected, comparable Indonesian screens back the patterns
 you name (\`search_screens\`, \`get_local_pattern\`).
 

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",
@@ -714,12 +727,12 @@ export const RULES = [
             num: 12,
             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. 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.",
+            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; on a new product's task UI, the brand layer only (see Not when)",
+            do: "Before designing, make two or 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 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: the alternatives come from Explore (capabilities/design.md, step 3) as structure hypotheses, and the conventions that must hold stay fixed. 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", [
         {
@@ -1191,12 +1217,12 @@ export const RULES = [
             num: 9,
             title: "Clean is not the same as designed",
             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",
+            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; on a new product's task UI, the brand layer only (see Not when)",
             do: "Run the swap test honestly: replace the name and logo with a competitor's in the same category. If the layout, the visual, and the headline would still work for them, the surface has no point of view yet; give it one (RX-UI-12). Report the answer in the Delivery Gate.",
             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/critique.js

@@ -9,7 +9,9 @@ export const CRITIQUE_BODY = `# RYUX Critique
 Critique answers "does this interface make sense, and what should change first?" It judges
 decisions; it is not Analyze (what exists) or QA (does the build match its design). It is an
 orchestrator, not a pile of rules: it analyzes the design, reasons with the RYUX knowledge modules,
-pulls evidence from RYUX Knowledge, and reports findings someone can act on.
+pulls evidence from RYUX Knowledge, and reports findings someone can act on. In the core workflow
+(SKILL.md) it runs Understand and the critique half of Build and critique; a finding that
+contradicts a chosen design is a reason to Reconsider it (capabilities/design.md, step 4).
 
 \`\`\`
 Critique

package/dist/intelligence/guides.js

@@ -9,7 +9,7 @@ generator, an anti-slop framework, a design system, or a prompt library.
 **Understand before you design. Don't design from imagination when evidence is available.**
 
 \`\`\`
-Analyze → Design → Build → Critique → QA → Anti-Slop (final gate) → done
+Understand → Frame → Explore → Evaluate and select → Build and critique → Verify and deliver → done
 \`\`\``;
 export const CORE_CAPABILITIES = `Tell RYUX what you are doing; RYUX decides what it needs to know. Pick the entry point, read its
 file, then read only the knowledge modules the task needs (task table below). Paths are relative
@@ -28,31 +28,31 @@ design-system, accessibility, responsive, frontend, and anti-slop. Evidence come
 project, product data, standards, and the ryux MCP when connected; none is required. Every entry point ends at the quality gates: the Hard
 Gates below and the Delivery Gate, with anti-slop as the last check, never the starting point.
 
-Keep the capabilities apart; do not collapse them into one generic "design" answer:
-
-| Capability | Answers | Example |
-| --- | --- | --- |
-| Analyze | What exists? | "The screen uses a 24px horizontal container." (observed) |
-| 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,
+Keep the capabilities apart, never one generic "design" answer: Analyze says what exists, Design what
+to do and why, Critique whether a decision is right, QA whether the build matches the intent.`;
+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.`;
-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, 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.
-5. **Reason**: decide with evidence (RX-PR-09, RX-PR-10); on expressive surfaces, set a point of
-   view first (RX-UI-12).
-6. **Produce**, then render and inspect what you made.
-7. **Run the gates**: Hard Gates and the Delivery Gate, with honest claims.
-
-Skip steps that do not apply, but never go from "generate" straight to "done".`;
+export const CORE_WORKFLOW = `One workflow, six stages; each entry point runs the stages it needs.
+
+1. **Understand**: who, what task, which product and market (RX-PR-01). Read the 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. Separate facts, assumptions, and unknowns
+   (RX-PR-02); ask and record direction as in capabilities/design.md, step 1. DESIGN.md is
+   direction, not evidence. Read the entry point's file and only the modules the task table lists.
+2. **Frame**: the user's task, the flow, what must be seen first, the primary action, and three to
+   five success criteria from the brief, written before any alternative exists.
+3. **Explore**: on a new or complex surface, two or three alternatives that differ in hypothesis and
+   structure, not paint; reference screens through the ryux MCP when connected. A small change skips it.
+4. **Evaluate and select**: rate the alternatives against the Frame criteria with evidence
+   (RX-PR-09, RX-PR-10); the user picks; write the Decision Receipt.
+5. **Build and critique**: design or implement the choice, render, inspect, and fix; Reconsider an
+   unchosen alternative when a finding contradicts the choice, and say why.
+6. **Verify and deliver**: Hard Gates and the Delivery Gate, with honest claims.
+
+Analyze runs 1. Design runs 1-6. Build runs 1, 5, and 6 (2-4 through Design when no design exists).
+Critique runs 1 and the critique half of 5. QA runs 6. Never go from "generate" straight to "done".`;
 export const DESIGN_BODY = `# RYUX Design
 
 > What should we design, and why? Design is the bridge between Analyze and Build. It works without
@@ -60,7 +60,9 @@ export const DESIGN_BODY = `# RYUX Design
 
 ## Workflow
 
-1. **Context.** Who, what task, which product and market, and the design intent
+The six stages of the core workflow (SKILL.md), as Design runs them.
+
+1. **Understand.** 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.
    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
@@ -82,63 +84,85 @@ export const DESIGN_BODY = `# RYUX Design
    (\`- **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
+   **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. 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,
+   **Modules.** 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
    review of it.
-4. **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.
-5. **Direction.** Write the Design Direction below. On task UI, follow conventions and the design
-   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.
+2. **Frame.** Name the primary task, the flow, the one thing that must be seen first, and the
+   primary action. Write three to five success criteria from the brief (the user's main task, what
+   must be seen first, the brief's character words, conventions that must hold) before any
+   alternative exists; Explore and Evaluate use these, and they do not change after you see the
+   alternatives. For consequential choices, list the two or three patterns to compare, using
+   reference screens when the ryux MCP is connected (RX-PR-09).
+3. **Explore.** On a new screen or flow, a complex or ambiguous surface, or a brief that asks for a
+   new look, render two or three alternatives 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 hypothesis.
+   - Each alternative is a hypothesis about what this user needs, not a style: on task UI, for
+     example, task-first (status and the next action lead), editorial (type and composition carry
+     the hierarchy), or expressive-brand (the brand layer leads without slowing the task). Choose
+     hypotheses that fit this product; never force three.
    - Make them differ in structure, not paint: every two of them differ on at least two of
-     information order (what comes first), layout model, interaction model (where the main action
-     lives), type class, and colour temperature. The same layout in new colours is the same
-     direction; replace it.
-   - Judge them against the brief, not taste: take three to five criteria from the context (the
-     user's main task, what must be seen first, the brief's character words, conventions that must
-     hold), rate each direction Strong, Adequate, or Weak with one reason each, and recommend one
-     with a Decision Receipt. "It looks better" is not a reason.
-   - Then stop and let the user choose. Build only the chosen one into the full design (states,
-     widths, Visual Direction, RX-UI-10) and mark the others on the canvas as not chosen. When the
-     user has already said to pick for them, continue with the recommendation and say so.
-6. **Design in the tool.** Use the Figma MCP or the pen.dev MCP. System first: look for the design
+     hierarchy, information order, composition or layout model, navigation or interaction model
+     (where the main action lives), and brand expression (type class, colour temperature). The same
+     layout in new colours is the same alternative; replace it. Conventions that must hold stay fixed
+     in all of them (RX-UX-08).
+   - On task UI the brand layer carries one signature from the product's own domain, never a layout
+     change for its own sake (RX-UI-12); on an expressive surface the signature can lead.
+   - A small change, or a screen inside a fixed design system, skips Explore: say so and continue.
+4. **Evaluate and select.** Rate each alternative against the Frame criteria, Strong, Adequate, or
+   Weak with one reason each, rate the evidence (RX-PR-10), and recommend one with a Decision Receipt.
+   "It looks better" is not a reason. Then stop and let the user choose. Build only the chosen one
+   into the full design (states, widths, Visual Direction, RX-UI-10), write the Design Direction
+   below, and mark the others on the canvas as not chosen. When the user has already said to pick for
+   them, continue with the recommendation and say so.
+   **Modes after the choice.** Refine improves the chosen alternative without losing its hypothesis.
+   Reconsider returns to an unchosen alternative when a later finding or new evidence contradicts the
+   choice: name the finding, show the alternative again, and let the user decide.
+5. **Design in the tool, then critique it.** 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,
+   **Render and inspect.** Screenshot what you made, check it against the direction and the rules,
    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, then run the counts of
    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 Frame (step 2). 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
+6. **Verify and deliver.** Check every product fact on the canvas (tool and command names,
+   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}
@@ -217,12 +241,15 @@ export const BUILD_BODY = `# RYUX Build
 
 > Implement or change the interface in code, faithfully and in the repo's own stack.
 
+Build runs Understand (steps 1-3), Build and critique (4-6), and Verify and deliver (7) of the core
+workflow (SKILL.md); Frame, Explore, and Evaluate happen in Design.
+
 1. **Read the repo first**: the stack, components, tokens, conventions, the architecture already
    used (where components, state, pure logic, and data access live), and the test runner
    (knowledge/frontend.md, knowledge/design-system.md). Reuse before creating.
 2. **Find the design source**: the Design Direction, a Figma or pen.dev design, a DESIGN.md, or an
-   approved mockup; it is the spec. If there is none, run Design first (capabilities/design.md)
-   instead of inventing one in code.
+   approved mockup; it is the spec. If there is none, run Design's Frame, Explore, and Evaluate
+   first (capabilities/design.md, steps 2-4) instead of inventing one in code.
 3. **Read the modules the task needs** from the task table: for example accessibility, responsive,
    and edge-cases for any UI, and forms and content for a form. When the build adds motion or
    transitions, read knowledge/ui.md (RX-UI-11) before writing any: how often the surface is seen
@@ -230,7 +257,8 @@ export const BUILD_BODY = `# RYUX Build
 4. **Implement faithfully.** Use semantic elements, existing components, and real data paths.
    Build must not invent business rules, prices, or limits; API behavior or response shapes; or
    data presented as real (RX-FE-02, RX-PR-02). It must not silently change a design decision: a
-   change goes back to Design as a new Decision Receipt. Mark every assumption in the code. Give
+   change goes back to Design as a new Decision Receipt, and when the code shows the chosen design
+   cannot work (data, platform, performance), say so and send it back to Reconsider. Mark every assumption in the code. Give
    each piece of logic one home in the repo's existing layers, never a copy (RX-FE-13).
 5. **Test what can break.** Unit tests for new or changed pure logic, edge cases included;
    integration tests for critical flows such as checkout, payment, and form submit. Use the
@@ -272,7 +300,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).`;
@@ -486,7 +514,7 @@ focal point, hierarchy, negative space, relation to the copy, and balance (RX-UI
 **Expressive surfaces** (hero, landing, onboarding, empty states, brand moments). Restraint keeps
 task UI usable; on expressive surfaces it is only the floor. Work concept, then signature, then
 system:
-1. **Concept**: write three directions first (name, concept, signature), then choose one. The idea
+1. **Concept**: write two or three directions first (name, concept, signature), then choose one. The idea
    comes from the product itself, not from the category: a tool about evidence might use receipts,
    citations, and marks of proof; a calm finance app might use the ledger. The category default
    (a terminal panel for developer tools, a dashboard screenshot for SaaS) is never the signature.
@@ -649,7 +677,7 @@ Check the stated viewport and the smallest supported width. No horizontal page s
    in the repo's own runner. Run them before claiming the work is done.
 
 Does not cover: visual decisions (see ryux-ui) or component reuse decisions (see ryux-design-system).`,
-    "visual-qa": `Visual QA asks one question: **did the implementation match the intended design?** Whether the
+    "visual-qa": `As an entry point, Visual QA is the Verify and deliver stage of the core workflow (SKILL.md) for a build; Design and Build also use its loop in Build and critique. It asks one question: **did the implementation match the intended design?** Whether the
 design itself is good is Critique's question (ryux-critique).
 
 **With a reference** (a Figma or pen.dev frame, DESIGN.md, or an approved screenshot):
@@ -694,7 +722,7 @@ widths) or NOT VERIFIED (why); motion read only from code is NOT VERIFIED.
 
 **Rank issues by impact**: blocks the task, misleads (wrong numbers, unclear action), adds friction,
 polish.`,
-    "anti-slop": `Anti-slop runs last, after design, build, critique, and QA; it is the final quality gate, never the
+    "anti-slop": `Anti-slop runs in Verify and deliver, after design, build, critique, and QA; it is the final quality gate, never the
 starting point. Anti-slop is the floor, not the ceiling: a tidy, generic surface still fails on expressive
 surfaces (RX-AS-09), and the point of view comes from RX-UI-12. Anti-slop is not a list of banned
 styles. It has three parts.
@@ -729,6 +757,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,10 +37,12 @@ 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`);
+                : a === "EDGE CASES"
+                    ? `${a.padEnd(width)}PASS | FAIL | NOT VERIFIED | N/A  · one-line reason · then the view × state matrix (RX-EC-01)`
+                    : `${a.padEnd(width)}PASS | FAIL | NOT VERIFIED | N/A  · one-line reason`);
     return `\`\`\`\n${lines.join("\n")}\n\`\`\``;
 }
 function routerBody() {

package/package.json

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