The previous flat data/rules/ flattened a real distinction:
- data/rules/modpack/ mirrors of upstream modpack-author-bundled
sorting_rules.txt (HellDrinx). Update when
upstream publishes; don't unilaterally edit.
- data/rules/curated/ sortof-operator-authored rules for individual
mods whose authors didn't declare load order
in their mod.info (RV Interior Expansion).
The loader stays provenance-agnostic; trigger values in _RULES_TRIGGERS
are paths relative to data/rules/ ("modpack/helldrinx.txt" etc.).
File headers in each rules file declare the provenance category and
edit policy.
The directory was misnamed — these are wsid-triggered sorting-rule
overlays, not modpack-specific. HellDrinx happens to be a modpack but
RV Interior Expansion isn't; both use the same generic mechanism.
Renames:
data/modpack_rules/ → data/rules/
_MODPACK_RULES_* → _RULES_*
_modpack_rules_for → _auto_rules_for
_parse_rules_with_modpacks → _parse_rules_combined
_emit_modpack_rules_warnings → _emit_rules_applied_warnings
warning tag "modpack-rules-applied" → "rules-applied"
Bug fix: /api/resort was passing {} rules to sort_mods, silently
dropping every auto-injected rule. The frontend runs an automatic
resort after each /api/sort (driven by localStorage branchSelections),
so the user always saw the resort output — where rv_expansion.txt's
loadAfter chain wasn't taking effect. Now resort goes through
_parse_rules_combined and emits rules-applied warnings the same way
/api/sort does.
