Before writing or editing any code in this repository, read
CODING_CONVENTIONS.md and follow every rule in
it. The conventions cover naming, comments, code structure, Java idioms,
Vaadin form bindings, CSS organisation, persistence patterns, and CI.
In particular, recurring expectations:
- Identifiers use full, meaningful words — no single-letter or abbreviated names anywhere (variables, parameters, lambda captures, loop indices).
- Add a comment only when the code is not self-explanatory; explain why, never what. No section-divider comments.
- Keep view / orchestrator classes thin. Extract forms, charts, grids, and other distinct concerns into their own component classes with a focused public API.
- Colors live in
colors.cssas semantic tokens. Component CSS files reference them throughvar(--color-…); never inline raw hex / rgb / named colors. - Form bindings go through
Binder<T>withbind(getter, setter)and appropriate validators. UseValueChangeMode.LAZYfor live recalculation. - Mutable beans use Lombok (
@Getter @Setter @NoArgsConstructor @AllArgsConstructor). Spring Boot 4 / Jackson 3 imports come fromtools.jackson.*.
If a request would violate a convention, push back and propose the convention-compliant alternative before proceeding.
Re-read CODING_CONVENTIONS.md first. If a situation isn't covered, match
the style of the surrounding code and propose adding the new rule to the
conventions file.