How Components and Rules Participate in Product Generation

Hi, I’m Fan Mihua. This article explains how AI selects components from a page task, follows project rules, implements real code, and verifies the final result.

Why can generation still drift with a component library?

A component library records what exists, and rules record how to use it. They do not automatically preserve the page’s primary task, visual hierarchy, or the reason behind a specific choice.

Where components and rules sit in the generation chain

The page emphasis can drift even when every component follows the rules

Start component selection from the page task

For an opportunity page, a kanban can own the progression task while a table remains a supporting high-density view. The task determines the structure before a concrete component is selected.

Turn a one-time choice into a stable decision

A machine-readable page contract preserves the primary task, primary and supporting views, critical actions, failure feedback, and acceptance checks. Implementations may change without losing the product decision.

Connect decisions to real components

Page responsibility	Implementation	Source
Layout and business regions	PageRow, SurfaceSection	System components
Metrics and status	KpiCard, StatusBadge	Project composition
Filtering and dense lists	FilterSelect, DataTable	Project composition
Progression and confirmation	Button, ConfirmActionDialog	System + project composition

Component responsibilities and provenance in a real opportunity page

Verify the generated result

Check	What must be true
Provenance	Every component is allowed and traceable
Structure	The primary and supporting views still match the task
Interaction state	Actions bind to real data and failures have recovery
Runtime result	The page opens, operates, responds, and completes the task

Components and rules become reliable only when the system can explain where they came from, why they were selected, and whether the running product satisfies the original task.