im0o
c3c0f56e56
用内核的 sub-rules 机制：listener 写 rule: 指向顶层 sub-rules 里的表 （listener/inbound/base.go:96，tunnel.go:713-721）。两个硬约束决定了 形态：proxy 优先级更高且完全短路规则匹配（tunnel.go:318-325），有附加 规则时 listener 只能写 rule；子规则表没命中时兜底是 DIRECT 而不是这一 路的出站（tunnel.go match 循环末尾），表底那条 MATCH,专属组 是承重的， 由 Patchbay 自动维护、界面上单独画不参与编辑。不变式：附加规则空 ⇔ proxy 直连专属组，非空 ⇔ rule 形态。 三处既有逻辑教会认 rule 形态：applySetup 不再无条件写 proxy（会把附加 规则静默短路掉）；referencesTo 扫 sub-rules 里的规则——表底 MATCH 是 rule 形态下专属组活着的唯一理由，不数它就会被当孤儿清掉；pruneGenerated 清理没有 listener 引用的生成表。panelGroups 和 syncGenerated 的「是否 由 Patchbay 接线」收敛成一个 managedWiring。 listener 的 rule 指向不存在的表时内核静默退回全局规则（getRules 的 else 分支），-t 和重载都不拦，自检里补上这条（vendor 本地改动，记入 ORIGIN.md）。界面：详情列新增附加规则区块，逐条增删改和排序复用 RuleForm，带内网直连预设；生成形状过了 mihomo -t 实测。
Patchbay
一个跑在服务器上的网页，用来编辑那台机器上 mihomo 的 config.yaml 并让改动生效。
核心动作是把某一路入站接到某一个出站上——名字取自录音棚的插线板。典型用途是给每个容器开一个端口，各自指定走哪条线路。
聚合订阅不在范围内（那是 Sub-Store 的活），安装升级内核也不在（那是 mihomo-up.sh 的活）。
术语以 CONTEXT.md 为准。为什么这么设计记在仓库外面的 docs/adr/。
跑起来
需要 Bun 1.3 以上。
bun install
cp .env.example .env # 按里面的注释填
bun run start # 打包前端并启动，默认 http://127.0.0.1:7580
首次启动会生成一个访问令牌，打印在控制台上，同时存到配置文件旁边的 .patchbay-token。
内核不在线也能用，只是看不到订阅里有哪些线路、也没法让改动立刻生效。这是有意的——配置写坏导致内核起不来的时候，正是最需要这个界面的时候。
开发
改代码的时候用这个，前后端都不用重启：
bun run dev:kernel # 终端 1：本地测试内核，开着不用管
bun run dev:all # 终端 2：后端 + 前端，改了自动生效
然后访问 http://localhost:5173（不是 7580）。后端代码改动由 Bun 的 --hot 重载，
界面改动由 Vite 直接更新浏览器。
bun run start 不具备这个能力——它把前端打成静态文件再由后端提供，代码一改就得重新
打包重启。那种方式适合最终验证和部署。
本地测试内核的配置由模板生成（dev/config.yaml 进 git，订阅地址从 .env 取，
生成的 dev/home/config.yaml 不进 git）：
bun run dev:reset # 第一次，或想把测试配置恢复成模板时
检查
bun test # 单元测试，不需要内核
bun run smoke # 接口冒烟测试，需要内核和后端都在跑
bun run typecheck
另有两个一次性脚本：scripts/roundtrip.ts 验证改一处配置之后 diff 里只出现那一处，scripts/safety-net.ts 验证配置写坏时能不能把用户救回来。
目录
server/ 后端。config-store.ts 是核心，那条保护链路在里面
web/ 前端。styles/tokens.css 顶部写着设计基调的三条规则
shared/ 两边共用的领域逻辑，纯函数，带测试
vendor/ 从别的项目复制来的代码，来源和本地改动记在各自的 ORIGIN.md
scripts/ 验证用的脚本，不参与打包
dev/ 本地测试内核的配置