Found while following the skill on a Jmix 3.0.1 project.
Problem: silent — the instructions give no branch for this case.
Task
Adding a second enum next to an existing sibling enum, both describing which fields of a form are shown and required.
Where
The "Forbidden" section, specifically the bullet banning ordinal() or enum .name() persistence, together with the "Enum Template" that hardcodes a private id field.
What happened
The codebase already has a shared base interface, implemented by every enum in it, whose getId() default returns name(); the sibling enum being mirrored uses it, and the ids are already persisted that way. The skill forbids .name() outright and offers no branch for joining an existing family, so following it literally would have introduced a second, inconsistent id scheme for two enums serialized side by side into the same column. The project convention was followed instead. Nothing in the skill says how to decide, and no gate would have flagged either choice. Caught in code review.
Suggested fix
Add a step before "Create the enum": look for an existing EnumClass base interface or convention in the project and match it. State that the .name() prohibition is about not introducing that scheme, and that an established project-wide scheme should be matched rather than split, with the tradeoff (renaming a constant becomes a data migration) noted in the code.
Found while following the skill on a Jmix 3.0.1 project.
Problem: silent — the instructions give no branch for this case.
Task
Adding a second enum next to an existing sibling enum, both describing which fields of a form are shown and required.
Where
The "Forbidden" section, specifically the bullet banning
ordinal()or enum.name()persistence, together with the "Enum Template" that hardcodes a privateidfield.What happened
The codebase already has a shared base interface, implemented by every enum in it, whose
getId()default returnsname(); the sibling enum being mirrored uses it, and the ids are already persisted that way. The skill forbids.name()outright and offers no branch for joining an existing family, so following it literally would have introduced a second, inconsistent id scheme for two enums serialized side by side into the same column. The project convention was followed instead. Nothing in the skill says how to decide, and no gate would have flagged either choice. Caught in code review.Suggested fix
Add a step before "Create the enum": look for an existing
EnumClassbase interface or convention in the project and match it. State that the.name()prohibition is about not introducing that scheme, and that an established project-wide scheme should be matched rather than split, with the tradeoff (renaming a constant becomes a data migration) noted in the code.