feat: support merging multiple subscriptions

README.md

@@ -46,9 +46,12 @@ ssm subscription set-url <name> <new-url>
 # show the URL for a subscription
 ssm subscription get-url <name>
 
-# activate a subscription
+# activate a subscription (additive — other active subscriptions stay active)
 ssm subscription activate <name>
 
+# deactivate a subscription
+ssm subscription deactivate <name>
+
 # list all subscriptions
 ssm subscription list
 
@@ -56,6 +59,8 @@ ssm subscription list
 ssm subscription storage
 ```
 
+More than one subscription can be active at the same time — `config apply` merges the proxies (and any proxy-groups a subscription bundles, like an "Auto"/"Proxy" group) from every active subscription into the generated config, prefixing each proxy and proxy-group name with its source subscription's name (e.g. `home-sub | HK 01`) so identically-named ones from different subscriptions don't collide. Any reference to a renamed proxy/group within that subscription's own groups *or* rules (e.g. `DOMAIN,example.com,Proxy`, `MATCH,Auto`) is rewritten to match, so nothing ends up pointing at a name that no longer exists.
+
 ### Hook Management
 ```bash
 # initialize hooks directory with template scripts
@@ -97,7 +102,47 @@ ssm config apply \
 **Options** (available on every `ssm config` subcommand):
 - `--config-file <config.yaml>`: Use a custom config file instead of the default.
 - `--output-file <output.yaml>`: Specify the output path for the generated config file.
-- `--subscription <subscription-name>`: Use a specific subscription (not just the active one) for config generation.
+- `--subscription <subscription-name>`: Use only this one specific subscription for config generation, overriding the active set entirely (even if multiple subscriptions are active).
+
+### Automation (`ssm:` block in core-config.yaml)
+
+`core-config.yaml` can carry an `ssm:` key — this tool's own automation config, applied when you run `config apply` and always stripped out of the generated config before it's written (mihomo never sees it). It supports three things:
+
+1. **`proxy-groups`** — build a new proxy-group from proxies matching a subscription and/or keyword filter.
+2. **`rate-filters`** — build a new proxy-group from proxies whose name encodes a rate/multiplier (e.g. `HK 01 | 1.5x`), extracted via a regexp and compared against a threshold.
+3. **`patches`** — append/prepend/replace an arbitrary value at any path in the generated config.
+
+```yaml
+ssm:
+  proxy-groups:
+    - name: "HK Nodes"
+      type: select                     # any extra clash proxy-group fields (url, interval, tolerance...) pass through as-is
+      match:
+        subscriptions: ["home-sub"]    # optional; omit to match proxies from any subscription
+        name-contains: ["HK", "Hong Kong"]  # optional; OR-matched, case-insensitive, matched against the proxy's original (pre-prefix) name
+
+  rate-filters:
+    - name: "Cheap Nodes"
+      type: select
+      pattern: '([\d.]+)x'             # regexp; its first capture group is parsed as the rate
+      operator: "<="                   # one of <, <=, >, >=, ==, !=
+      value: 1.0                       # proxies whose name doesn't match `pattern` at all are excluded
+      match:
+        subscriptions: ["home-sub", "work-sub"]
+
+  patches:
+    - path: dns.nameserver             # dot/bracket path: dots descend into maps, [N] indexes into lists
+      op: prepend                      # append | prepend | replace
+      value: ["1.1.1.1"]
+    - path: proxy-groups[0].proxies
+      op: append
+      value: ["DIRECT"]
+    - path: rules
+      op: replace
+      value: ["MATCH,PROXY"]
+```
+
+`proxy-groups` and `rate-filters` run before `patches`, so patches can reference or further adjust the groups they created (e.g. `proxy-groups[-1]`-style indexing isn't supported — use the group's actual index, or patch `proxy-groups` itself with `append`/`prepend`).
 
 ### Core Management
 ```bash