Support referencing existing `rule_set` inside inline/headless logical rules

Problem

When writing complex routing logic, it is currently possible to reference a rule_set from route.rules, but not from inside inline/headless logical rules.

For example, this is valid at the top-level route rule layer:

{
  "rule_set": "special-targets",
  "action": "route",
  "outbound": "proxy"
}

But this kind of composition is not supported inside logical rules:

{
  "type": "logical",
  "mode": "and",
  "rules": [
    {
      "wifi_ssid": [
        "AWiFi",
        "BWiFi",
        "CWiFi"
      ]
    },
    {
      "rule_set": "special-targets"
    }
  ],
  "action": "route",
  "outbound": "preferred-proxy"
}

This fails because rule_set is not allowed inside headless/inline rule items.

Why this matters

This makes some real-world routing policies unnecessarily hard to maintain.

A common use case is:

• define one reusable target set, such as special-targets
• use it normally with one outbound, for example proxy
• override the outbound under some contextual condition, for example a specific Wi-Fi SSID

In my case, the desired policy is:

• normally: special-targets -> default-proxy-group
• on specific SSIDs: wifi_ssid AND special-targets -> preferred-proxy

Right now, since rule_set cannot be referenced inside logical rules, the only practical option is to duplicate the whole target definition twice:

• once for the normal branch
• once for the SSID-specific branch

This increases maintenance cost and makes configs much harder to read.

Expected behavior

It would be very helpful if inline/headless logical rules could reference an existing rule_set, for example:

{
  "type": "logical",
  "mode": "and",
  "rules": [
    {
      "wifi_ssid": ["AWifi", "Bwifi", "Cwifi"]
    },
    {
      "rule_set": "special-targets"
    }
  ],
  "action": "route",
  "outbound": "preferred-proxy"
}

Or any equivalent syntax that allows composition of:

• contextual conditions such as wifi_ssid
• reusable target groups defined as rule_set

Benefits

• avoids duplicating large target lists
• improves config readability
• makes advanced policies easier to express
• keeps rule_set truly reusable across different routing branches

Environment

• sing-box version: 1.13.1
• use case: route override based on Wi-Fi SSID while reusing an existing target rule set

Thanks for considering this.

Start by tracing how routing rules handle existing rule_set references and how inline/headless logical rule items are validated or evaluated. Reproduce the provided Wi-Fi SSID and special-targets configuration, then verify that the reusable rule set can be composed inside the logical rule and that both normal and overridden routing branches behave as expected.