Greptile Summary

This PR introduces developer-level model association rules: a new layer of routing configuration that is configured once per model developer and automatically inherited by all models from that developer, with per-model opt-out support.

• Adds DeveloperModelSettings storage in SystemModelSettings, a new EffectiveModelAssociations function that merges developer-inherited rules with model-level rules, and replaces the JSON-based association cache signature with a faster FNV-64 hash.
• Extends the GraphQL schema and frontend dialogs (shared ModelsAssociationDialog now handles both model and developer modes), adds a disableDeveloperSettingsInheritance toggle per model, and surfaces developer rule counts in the model list.
• Adds backward-compat handling in the resolver so older clients omitting developerSettings do not clear the new field.

Confidence Score: 3/5

The developer-association save path drops modelBlacklistRegex from the mutation payload, clearing it on every save for any user who has set that field.

The backend-inheritance logic, deep-copy, and FNV signature are well-written and covered by tests. However, the developer-mode save in models-association-dialog.tsx forwards all scalar settings from the loaded data but omits modelBlacklistRegex. Because the GraphQL field is nullable and the Go struct field is a plain string, the absent field arrives as "", overwriting any previously configured blacklist regex every time a developer rule is saved.

frontend/src/features/models/components/models-association-dialog.tsx — specifically the updateModelSettings.mutateAsync call in the developer-mode submit path

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Incoming Request: model ID] --> B[EffectiveModelAssociations]
    B --> C{DisableDeveloperInheritance?}
    C -- Yes --> D[Model-level rules only]
    C -- No --> E[developerAssociationsForDeveloper]
    E --> F[inheritDeveloperAssociationsForModel\nfill ModelID from request model]
    F --> G[mergeInheritedModelAssociations\npriority sort: model rules first at equal priority]
    D --> G
    G --> H[resolveAssociations\nFNV cache lookup / fill]
    H --> I{Cache hit?}
    I -- Yes --> J[Return cached candidates]
    I -- No --> K[Match channels / tags]
    K --> L[Store in associationCache]
    L --> J
    J --> M[filterResolvedCandidatesForRequest\napply When conditions]
    M --> N[ChannelModelsCandidate list]

_{Reviews (4): Last reviewed commit: "fix: satisfy errcheck for association si..." | Re-trigger Greptile}

已处理本轮检视意见：

• cloneModelAssociation 现在会深拷贝 When 和嵌套 Condition，并补了回归测试。
• modelAssociationSignature 已从每请求 json.Marshal 改为字段级 FNV 签名，并补了嵌套条件变化的签名测试。
• 修正了继承测试中 developer 与 model ID 不匹配的测试数据。
• UpdateSystemModelSettings 的兼容保护保留现有 last-writer-wins 语义，并在注释中明确并发边界。这里暂不引入 CAS/version，因为这会改变系统设置整对象写入协议，超出本 PR 的开发者规则机制范围。

验证：

• PATH=/usr/local/go/bin:$PATH go test ./internal/server/biz ./internal/server/orchestrator ./internal/server/gql
• PATH=/usr/local/go/bin:$PATH go test ./...
• git diff --check

感谢 pr ，代码有点冲突了。

是否可以看下截图，大概是怎么个交互。

@looplj 已经解决冲突并补充了交互截图，整体交互如下。

开发者级模型渠道规则说明

本次功能的目标是减少同一开发者下多个模型的重复渠道配置。原来每个模型都要单独配置自己的渠道规则；现在可以先在开发者层配置一组通用规则，下面的模型默认继承这些规则，同时仍然保留模型自己的单独配置能力。

主界面入口

进入“模型”页面后，模型会按开发者分组展示。每个开发者分组的操作区新增了“开发者规则”入口，旁边的数字表示这个开发者当前配置了几条规则。

在截图中，Anthropic 分组下有 2 个模型，右侧显示 开发者规则 1，表示该开发者已经配置了 1 条开发者级规则。点击这个入口会打开开发者规则配置窗口。

开发者规则配置

开发者规则窗口用于配置同一开发者下所有模型共享的渠道选择规则。

这里的关键点是：开发者规则只选择“渠道”或“渠道标签”，不选择具体模型 ID。

例如配置一条“渠道标签”规则后，系统会在实际路由时为每个继承该规则的模型自动填入自己的模型 ID。也就是说，同一条开发者规则可以同时服务该开发者下的多个模型，而不会把某一个具体模型固定写死。

右侧“预览”区域会展示当前规则能匹配到的渠道，便于确认规则是否能命中预期渠道。

默认继承关系

同一个 developer 下的模型默认继承开发者规则。继承后，请求路由会基于“有效规则”工作，有效规则由两部分组成：

• 开发者规则：开发者层配置的通用规则。
• 模型规则：模型自己单独配置的规则。

合并规则时遵循两个原则：

• 优先级数字越小，越先执行。
• 同优先级时，模型自己的规则优先于开发者规则。

因此，开发者规则适合放通用渠道策略，模型规则适合放少数模型的特殊覆盖策略。

模型级配置窗口

从某个模型行的操作菜单进入“管理关联”，会打开模型自己的关联配置窗口。

截图中的模型自己没有单独配置规则，但因为存在对应开发者规则，右侧预览仍然能看到继承来的渠道。这个预览展示的是模型实际会使用的有效规则，而不是只展示模型自身保存的规则。

不继承开发者配置

模型关联窗口新增了“不继承开发者配置”开关。打开后，这个模型只使用自己单独配置的规则，开发者规则不会再应用到它。

截图中打开“不继承开发者配置”后，因为该模型本身没有配置独立规则，右侧预览变为空。

实际验证结果：

• 关闭继承前，两个同开发者模型都继承开发者规则，关联渠道数都是 1。
• 其中一个模型打开“不继承开发者配置”后，它的关联渠道数变为 0。
• 另一个同开发者模型没有打开该开关，仍然继承开发者规则，关联渠道数保持 1。

生效范围

开发者规则继承后的有效规则已经统一应用到主要模型关联路径：

• 请求路由时选择候选渠道。
• 模型列表中的关联渠道数量统计。
• 模型关联窗口中的渠道预览。
• 已配置模型和未关联渠道相关判断。
• 开发者分组上的规则数量展示。

这保证了界面展示、预览结果和实际请求路由使用的是同一套规则语义。

兼容性

该功能对老版本配置保持兼容：

• 旧系统配置中没有 developerSettings 时，会按空列表处理。
• 旧模型配置中没有 disableDeveloperSettingsInheritance 时，默认值为 false，也就是继续继承开发者规则。
• 老客户端更新系统模型设置但不传 developerSettings 时，会保留已有开发者规则，避免升级过程中被意外清空。

推荐用法

建议把稳定、通用的渠道策略放到开发者规则里，例如某个开发者统一走一组带标签的渠道。

当单个模型需要特殊处理时，再进入模型自己的“管理关联”窗口追加模型规则。如果这个模型完全不应该继承开发者规则，则打开“不继承开发者配置”。