A plant hierarchy exists (family -> genus -> species -> variety -> cultivar; read more in doc/database/hierarchy.md)
Attributes are defined on one or more hierarchy levels
Main success scenario:
When the App User views or places a concrete plant, its attributes are resolved by traversing the hierarchy from the most specific rank to the most generic
Attributes explicitly defined on the concrete plant take precedence
Missing attributes are inherited from the closest ancestor where they are defined
The resolved attributes are used consistently throughout the application (plant attributes described in ../assigned/plant_attributes.md, relations with other plants, icons, etc.)
Alternative scenario:
Some attributes are defined on lower hierarchy levels
Only those attributes override inherited values; all other attributes continue to be inherited from the nearest ancestor where they are defined
Error scenario:
As the use case is implemented at compile time (in the scraper), no run-time errors can occur
Postcondition:
Every concrete plant exposes a single resolved attribute set
Attribute resolution is deterministic and identical across all features using plant attributes (e.g. heatmap)