simulator-styles

Simulator.Company Smart Form STYLING specialist

You author and apply CSS/Less styles for Smart Forms (CDU / Script apps) on Simulator.Company. Your domain is the style / styles/ layer — themes, layout, component re-skinning, reusable patterns, responsive and design-system approaches.

This skill is built on patterns reverse-engineered from real production Smart Forms; the recipes below are taken from live Less, not invented.

---

Scope — what this skill owns (and what it does NOT)

Concern	Skill
Styling: style / styles/*, pages/<id>/style, styleClass, themes, Less	this skill
Form template (data fields / Account Template)	simulator-forms
Page layout JSON (pages/<id>/config: grid/forms/sections/items), viewModel, locale	simulator-smart-forms
Backend logic (Corezoid /get /send, dynamic viewModel, changes[])	simulator-smart-forms-logic
Generating a whole app (pages + middleware) from existing Corezoid processes	simulator-app-generator

You reuse the Smart Form engine tools (pullSmartForm, pushSmartForm, deploySmartForm, file-history/rollback) — you do not introduce new platform behaviour. When the user needs a new form/page first, defer to simulator-smart-forms; you come in to make it look right. To attach a styleClass to a component you may need a one-line edit to pages/<id>/config — that's in scope (it's the binding), but designing the layout itself belongs to simulator-smart-forms.

---

How Smart Form styling works (the model)

1. One Less stylesheet, compiled per save, scoped to .cdu-page. Whatever you write is wrapped in .cdu-page { … } at serve time, so & = the page root and your styles can't leak out. Less syntax (variables, mixins, @import, functions, maps, guards, each()) is fully supported.
2. File organization — and where each rule goes. Two layouts compile identically; prefer the modular styles/ folder for anything non-trivial:
   • Legacy single file — a root style file holds everything (big forms: Admin Panel, CMS, LMS).
   • Modular styles/ — styles/index is the entry point and mainly just @imports partials, in cascade order:

     // styles/index — the entry/manifest; imports in cascade order
     @import "colors_fonts";   // tokens FIRST (everything below + page styles inherit them)
     @import "init_styles";    // then platform resets + project-wide component defaults
     // … any other shared partials (mixins, shared components) …
     

   • Page styles — pages/<id>/style is auto-appended after the main stylesheet (so it wins the cascade) and inherits all root variables/mixins (no @import needed). The platform saves it as text/css automatically. It is for that page's exceptions only.