Correct builder item level scaling

docs/DESIGN_SYSTEM.md

@@ -776,11 +776,23 @@ calculates the ordinary level-40 curve value; never rebase level 40 as T2 level
 1. Slider bounds, direct-input validation, displayed bounds, and clamping must
 all enforce the same availability minimum.
 
-ISAC weapon-tier damage and core ranges are observations recorded at their
-explicit reference level. The progression curve still has a level-1 origin,
-but builder scaling must calculate the ratio between the target level and the
-stored observation's `reference_level`. Do not treat every stored endpoint as a
-level-1 value merely because the curve begins there.
+ISAC ranges that represent observed values retain their explicit reference
+level. The progression curve still has a level-1 origin, but builder scaling
+must calculate the ratio between the target level and the stored observation's
+`reference_level`. Do not treat every observed endpoint as a level-1 value
+merely because the curve begins there.
+
+Weapon damage is the exception to reference-observation scaling: each
+weapon-tier damage range is stored as a hidden base and must be multiplied
+directly by `weaponMultiplier(selectedLevel)`. Changing weapon level remaps the
+selected damage value into the newly calculated range. Shared core attributes
+remain level-50 reference profiles and use ratio scaling independently.
+
+Gear base Health and Armor follow the same hidden-base principle. Multiply
+their stored per-item endpoints directly by `gearMultiplier(selectedLevel)`,
+truncate only for display, and remap the user's selected value proportionally
+when gear level changes. Do not apply this rule to rolled Attributes or the
+shared core-allocation profile, which retain independent reference semantics.
 
 ### Shared core allocation