8. Appendix |

Errors & diagnostics

Build errors and diagnostics are emitted to the terminal and surfaced through the language server (LSP) for editor tooling.
Running compilation in watch mode enables live diagnostics: errors and warnings are updated in the terminal as files change.

Local symbolic-classes (single $) must be unique within the declaring file.
Global symbolic-classes ($$) must be unique across the entire project workspace.
Neither local nor global symbolic-classes should collide with symbolic-classes generated by libraries; library-derived symbolic-classes are considered a separate namespace and collisions will produce warnings or errors during compilation.

On init, if a proxymap entry specifies a target folder that does not exist, the target will be cloned from the source to create a working proxy folder.
During compilation, the target (proxy) folder is used as the compilation source. The compiler reads the target files and writes compiled artifacts into the source folder; treat target as a local source copy watched by the tool.

Dependency resolution is automated. The compiler traverses the attachment tree for symbolic-class @--attach/~ links and deploys all interconnected dependencies together after symbolic classes are composed.
staple snippets are replaced with the <staple /> placeholder at compile time; ensure your attached staple snippets are present where expected to avoid missing assets.

Class names that start with an underscore (_) are reserved for compiler-generated identifiers.
The hashing/name generation uses a continuous counter encoded in base62 (0-9, A-Z, a-z) to produce short, deterministic names, and uses different method in different builds commands. This approach ensures compact identifiers while remaining deterministic across runs when the input and library ordering are unchanged.

Hoisting is a default behavior: assigned (@--assign / =) and attached (@--attach / ~) styles are pulled toward the top during compilation. Variables are promoted to an even higher preface level.
Under a single scope, a variable may only have a single effective value; later overrides declared in the same scope replace earlier ones during hoisting.
Prefer declaring state-affecting variables in the base class declaration and rely on compound selectors to update variables.

Source maps are not provided. Because the tool operates on plain text files and is intentionally language-independent, there is no meaningful source-map mapping to generate for generic text inputs.
Vendor prefixes and compatibility data are fetched from external sources at build or release time so the tool can adapt to platform changes without embedding large datasets.
Rarely-used color palettes will be provided additional fall back to literal hex codes.

No runtime integration or API/plugins required
The compiler produces a static stylesheet artifact which can be included in your app like any other CSS file.

The compiler binary is intentionally a closed distribution for runtime execution: contributions to the binary itself are not expected. The tool is a structural processor and does not validate or understand CSS properties or values — it operates on document structure and symbolic classes.
Extending the system: users can add CSS files to the xtyles/libraries folder to create custom libraries/frameworks; the six-level inheritance model allows rapid propagation of changes across a project.
Conditional definitions (media queries, custom at-rules, container-dependent variants, etc.) are generated using wrapper-attributes. hashrules provide reusable snippets for wrapper attributes.
Users may fork or clone the repository, personalize their own variants, and distribute them as needed. For detailed guidance on customization, refer to the Flavourize documentation. Be sure to review the EULA for any usage constraints and legal requirements associated with redistribution and modification.