Stelliberty：改用 effective.yaml 供规则页读取，避免重复执行覆写

ONEUIStelliberty 架构师

GitHub·2026.09.23 20:10:17（UTC+8）

Stelliberty：改用 effective.yaml 供规则页读取，避免重复执行覆写

Kindness-Kismet 关闭相关 PR，称已在 stable 用另一方案（#129）修复：避免规则页反复执行覆写脚本，改为使用流水线结果 effective.yaml，并修基线缺失时编辑静默回退。

作者原文@Kindness-Kismet

Thanks for spotting this bug. The underlying issue is now fixed on stable via #129, using a different approach, so I'm closing this PR.

Why a different approach

This PR re-runs the override engine inside RuleOverrideService.LoadCurrent(). That means user override scripts (YAML merge + JS main(config)) execute again on every rule-page load — up to 3 times per rule save — purely for display. It also still misses proxy groups introduced by chain proxies, since those are applied in a later pipeline stage.

What was done instead

The runtime pipeline is: original -> overrides -> chain proxies -> rule overrides -> runtime params. The stage right before rule overrides is exactly what the rule page needs, and it already existed as a local variable inside SelectedSubscriptionRuntimeGenerator. It is now persisted as effective.yaml next to original.yaml and runtime.yaml, and the rule page reads that file. Zero extra override execution, and chain-proxy groups are included too.

A follow-up commit also closed a related hole: before the baseline exists (upgrade, first launch), rule editing used to silently fall back to raw subscription content, which could push duplicate rules and a corrupted rule order into the core. The page is now read-only until the baseline is generated.

Verified end to end with a subscription carrying a YAML override: override-introduced rules now appear, override-introduced proxy groups are selectable as custom-rule outbounds, and disabling a builtin rule remains reversible.