Cloud theme · Interface conformance report

1Scope and source of truth

Cloud is the design system FLYER publishes at roadmap.flyer.vn/cloudtheme, adopted as the default interface of Trường Số CRM. The specification fixes five purple shades, a neutral set, four status colours, the display density, and the shape of the basic components. Its stated mandatory principle is that the theme changes presentation only, leaving icons, navigation order, feature names and task flows untouched.

The specification fully describes the sidebar, cards, tables, buttons, status labels, tabs and the modal dialog. Several components are absent: dropdown menus, toasts, tooltips, drawers, the command palette, switches, progress bars and callout boxes. For these, the document treats enterprise.flyer.vn/app as the reference, since it is a running product built on the same system.

2Deviations found

The first pass applied Cloud at the token layer and across the shared components. That reached the product shell, but most of the business interface is written directly in Tailwind utility classes and therefore never received the theme's tokens. A count over the codebase shows 2,010 hard-coded palette utilities, 1,423 of them in the slate ramp — a blue-leaning grey the Cloud system does not contain.

3How it was handled

Editing 2,010 uses across roughly sixty files is laborious and easy to get wrong. Tailwind version 4 resolves every palette class through a --color-<ramp>-<shade> variable, so the chosen approach was to redefine those variables within the Cloud theme's scope. The interface code is untouched; the colours are redirected at the token layer.

Utilities that carry an opacity suffix are inlined by Tailwind as literal colours rather than read through the variable, so the ones the codebase actually uses are restated separately with color-mix. Every rule sits inside the html.cloud scope, so the other themes are unaffected.

4Token conformance

The "measured" column was taken with getComputedStyle on a running build. The "result" column separates what is already live on dev from what is still held in PR #66.

5Six screens, before and after

Captured at 1440 px wide, on the same sample data, through the same harness. The "before" images were built from the exact commit running on dev; the "after" images from the feat/cloud-theme-ui branch.

Dashboard

/vi/dashboard/cloudtheme

BeforeAfter

• The Top Sales ranking listed the weakest seller first, because the charting library lays category axes bottom-up; it is now inverted so the leader is on top, using the purple ramp rather than three medal colours.
• The "pipeline value" and "open deals" figures sat on grey inset boxes with 10 px uppercase labels; they now use the same tile as the five KPI tiles above them.
• The "sample data" badge repeated nine times, once per card, breaking the KPI labels onto two lines; it is now stated once beneath the page title.
• The won and lost series take the system's status colours; the funnel axis rounds up to a clean tick instead of ending on an odd value that collided with the neighbouring label.
• Hovering a list row turns grey; the purple fill is kept for the selected state.
• Chart text used to render in the browser's default face: charts draw to canvas, where ctx.font has no cascade and so discards inherit. The theme's font stack is now passed to the chart directly. The mismatch was clearest on hover, because the tooltip is a DOM node and did inherit correctly, appearing right beside axis labels that did not.
• The sidebar is renamed School OS · Trường Số and carries the official logo.

Customer list

/vi/crm/customers

BeforeAfter

• The blue-leaning grey ramp moves onto the system's neutrals across all secondary text, borders and fills.
• Status labels change from pills to 6 px rounded rectangles in the four conventional colours.

Customer detail

/vi/crm/customers/<id>

BeforeAfter

• Form fields become white, bordered #d4d4d8, 36 px tall, with a purple border and halo on focus.
• The opportunity value tile moves from a green fill to the brand's soft purple; green is reserved for the "good" status.
• Activity type labels take the 6 px radius and the four conventional colours; the stage band becomes one flat colour, dropping its gradient and shadow.

Export dialog

Customer list · Export

BeforeAfter

• 14 px radius, a #fafafa footer separated by a rule, Cancel rendered flat at the far left, and the action pair to the right.
• The overlay uses exactly rgba(24,24,27,.45) and does not blur what sits behind it.

Command palette

Command K

BeforeAfter

• A 620 px box, a 50 px borderless input separated by a rule, and a results list inset 6 px with each row on an 8 px radius.

Toast

/vi/account

BeforeAfter

• One toast style for every type: a #1b1b1f ground, white text, 10 px radius, bottom right.
• The account header band drops its gradient and shadow for a single flat colour.

6Per-component rules

The table below extends the specification: for each component it does not cover, the document records the values applied, so later work has one consistent reference.

7Verification and open items

Verification results: the grey variable resolves to #71717a; status labels measure 6 px; no element still carries a utility shadow; the overlay no longer blurs; menus sit on a 10 px radius; the toast ground is #1b1b1f; and every field in the drawer is 36 px, white, bordered #d4d4d8. Type checking, linting and the production build all pass with no new findings.