FN-6760: add built-in design workflow

Add a built-in workflow path for UI-heavy implementation work with a required design review gate.

- Register builtin:design as a selectable built-in workflow after implementation and before standard review/merge.
- Define design review criteria covering hierarchy, spacing, typography, design tokens, component reuse, responsiveness, and design-language fit.
- Add catalog coverage and update workflow documentation to list the new Design workflow.
- Add a minor changeset for the published Fusion package.

Files changed:
 .changeset/fn-6760-design-workflow.md              |  5 +++++
 docs/getting-started.md                            |  2 +-
 docs/workflow-editor.md                            |  4 ++++
 docs/workflow-steps.md                             |  1 +
 .../core/src/__tests__/builtin-workflows.test.ts   | 23 +++++++++++++++++++++
 packages/core/src/builtin-workflows.ts             | 24 ++++++++++++++++++++++
 6 files changed, 58 insertions(+), 1 deletion(-)

Fusion-Task-Id: FN-6760

Fusion-Task-Lineage: 2682ce3f-a89d-4237-b2cf-675439eea1d6

.changeset/fn-6760-design-workflow.md

@@ -0,0 +1,5 @@
+---
+"@runfusion/fusion": minor
+---
+
+Add a built-in Design workflow that gates UI-heavy work with a design/UX review before standard review and merge.

docs/getting-started.md

@@ -130,7 +130,7 @@ You can also use expanded board controls (Refine, Deps, Attachments, model overr
 
 Most tasks can use the default **Coding** workflow. When the workflow selector is visible on a task or board creation surface, choose a different workflow if the work needs a shorter path, extra review, stepwise execution, Compound Engineering skills, or a custom policy your project authored.
 
-Built-ins include task-selectable Coding, Quick fix, Review-heavy, plugin-gated Compound engineering, and Stepwise coding workflows, plus PR lifecycle fragments for workflow authors. For the full catalog and runtime behavior, see [Workflow Steps](./workflow-steps.md#workflow-overview). To inspect built-ins or author custom workflows, open the dashboard [Workflow Editor](./workflow-editor.md).
+Built-ins include task-selectable Coding, Quick fix, Review-heavy, plugin-gated Compound engineering, Stepwise coding, and Design workflows, plus PR lifecycle fragments for workflow authors. For the full catalog and runtime behavior, see [Workflow Steps](./workflow-steps.md#workflow-overview). To inspect built-ins or author custom workflows, open the dashboard [Workflow Editor](./workflow-editor.md).
 
 ## Understand the Task Lifecycle
 

docs/workflow-editor.md

@@ -132,7 +132,11 @@ Save is blocked by client-side issues such as unplaced nodes and blocking column
 Fusion ships built-in workflows as read-only references:
 
 - `builtin:coding` — the default coding lifecycle and fallback for tasks without a workflow selection.
+- `builtin:quick-fix` — a short path for trivial or no-commit/decision work.
+- `builtin:review-heavy` — a standard execute/review/merge path with an additional gated security review.
+- `builtin:compound-engineering` — a plugin-gated workflow for Compound Engineering skill lanes.
 - `builtin:stepwise-coding` — a graph variant that models per-step parse, execute, review, and rework structure.
+- `builtin:design` — a UI-heavy work path with a gated design/UX review before standard review and merge.
 
 Built-ins can be viewed, exported, and used as templates, but their graph, columns, field declarations, and setting declarations are not editable. Their per-project setting **values** are editable from the Settings panel's Values tab.
 

docs/workflow-steps.md

@@ -32,6 +32,7 @@ Decision-only or investigation tasks can also declare `noCommitsExpected` / `**N
 | Review-heavy | `builtin:review-heavy` | Standard execute/review/merge path with an additional gated security review. |
 | Compound engineering | `builtin:compound-engineering` | Plugin-gated workflow that invokes Compound Engineering skills for planning, work, review, PR/feedback, and learnings capture. |
 | Stepwise coding | `builtin:stepwise-coding` | Graph-executor workflow that models per-step parse/execute/review/rework explicitly. |
+| Design | `builtin:design` | UI-heavy work path that implements, runs a gated design/UX review, then performs the standard review and merge. |
 | PR lifecycle | `builtin:pr-workflow` | Reusable PR lifecycle graph fragment (create PR → await review → respond → gate → merge); it is a fragment, not directly selectable as a task workflow. |
 
 ### Custom workflow authoring

packages/core/src/__tests__/builtin-workflows.test.ts

@@ -150,6 +150,27 @@ describe("built-in workflows", () => {
     expect(ir.settings).toEqual(BUILTIN_WORKFLOW_SETTINGS);
   });
 
+  it("includes the design built-in with an ordered design review gate", () => {
+    const design = getBuiltinWorkflow("builtin:design");
+    expect(design).toBeDefined();
+    expect(design!.kind).toBe("workflow");
+    expect(() => parseWorkflowIr(design!.ir)).not.toThrow();
+    expect(() => compileWorkflowToSteps(design!.ir)).not.toThrow();
+
+    const authoredNodeIds = design!.ir.nodes.filter((node) => node.id !== "start" && node.id !== "end").map((node) => node.id);
+    expect(authoredNodeIds).toEqual(["execute", "design-review", "review", "merge"]);
+
+    const designReview = design!.ir.nodes.find((node) => node.id === "design-review");
+    expect(designReview?.kind).toBe("gate");
+    expect(designReview?.config?.name).toBe("Design review");
+    expect(designReview?.config?.gateMode).toBe("gate");
+    const prompt = String(designReview?.config?.prompt ?? "");
+    expect(prompt.length).toBeGreaterThan(100);
+    expect(prompt).toContain("visual hierarchy");
+    expect(prompt).toContain("design tokens");
+    expect(prompt).toContain("responsive behavior");
+  });
+
   it("repeated catalog reads and listings keep builtin:coding in the enabled order", () => {
     expect(getBuiltinWorkflow("builtin:coding")?.ir).toBe(BUILTIN_CODING_WORKFLOW_IR);
     expect(getBuiltinWorkflow("builtin:coding")?.ir).toBe(BUILTIN_CODING_WORKFLOW_IR);
@@ -159,9 +180,11 @@ describe("built-in workflows", () => {
         (workflow) => workflow.kind !== "fragment" && !isBuiltinWorkflowPluginGated(workflow.id),
       ).map((workflow) => workflow.id),
     );
+    expect(defaultEnabledBuiltinWorkflowIds()).toContain("builtin:design");
     expect(defaultEnabledBuiltinWorkflowIds()).not.toContain("builtin:compound-engineering");
     expect(defaultEnabledBuiltinWorkflowIds()).not.toContain("builtin:pr-workflow");
     expect(getBuiltinWorkflow("builtin:pr-workflow")!.kind).toBe("fragment");
+    expect(defaultEnabledBuiltinWorkflowIds().length).toBeGreaterThanOrEqual(4);
     expect(defaultEnabledBuiltinWorkflowIds().slice(0, 4)).toEqual([
       "builtin:coding",
       "builtin:quick-fix",

packages/core/src/builtin-workflows.ts

@@ -260,6 +260,30 @@ export const BUILTIN_WORKFLOWS: WorkflowDefinition[] = [
     createdAt: BUILTIN_TS,
     updatedAt: BUILTIN_TS,
   },
+  /**
+   * FNXC:Workflows 2026-06-20-00:00:
+   * Fusion needs a built-in design lane for UI-heavy work. Gate changes on the frontend-ux-design review criteria before the standard review and merge so visual hierarchy, spacing, typography, token consistency, component reuse, responsive behavior, and fit with the design language are checked without custom workflow assembly.
+   */
+  linear({
+    id: "builtin:design",
+    name: "Design (built-in)",
+    description: "Implement, then run a design/UX review gate before the standard review and merge — for UI-heavy work.",
+    nodes: [
+      { id: "execute", kind: "prompt", config: builtinPromptConfig("execute", "Execute") },
+      {
+        id: "design-review",
+        kind: "gate",
+        config: {
+          name: "Design review",
+          gateMode: "gate",
+          prompt:
+            "You are a UX design reviewer. Review frontend/UI changes for visual polish and consistency with existing UI patterns and design tokens. Check visual hierarchy and information flow; spacing, typography, margins, padding, gaps, and type scale; color and token consistency, including CSS custom properties/design tokens and no hardcoded colors; reuse of existing components instead of one-off styling or duplication; responsive behavior across viewports; and fit with the product design language, including border radius, shadows, transitions, and icon style. Block merge on real visual-quality regressions such as layout breaks, broken responsive behavior, hardcoded color/token violations, inconsistent component patterns, or design-language mismatches. Do not block or nit when the diff has no frontend/UI impact or no real design issue exists.",
+        },
+      },
+      { id: "review", kind: "prompt", config: builtinPromptConfig("review", "Review") },
+      { id: "merge", kind: "prompt", config: builtinPromptConfig("merge", "Merge boundary") },
+    ],
+  }),
   // The PR workflow (U9) — the unified PR-entity lifecycle wired end to end as
   // first-class graph nodes/edges: pr-create → await-review (hold) → pr-respond
   // (bounded rework loop) → auto-merge gate → pr-merge → end, with the await