Conversation
A tag push forced MACOS_SIGN_RELEASE to true, so the release pipeline always demanded the five Apple Developer secrets. This fork owns none of them, and the guard in "Require macOS signing and notarization secrets" additionally pins APPLE_TEAM_ID to the upstream maintainer's team (DUV63RKYTW) while CSC_NAME is hardcoded to their certificate common name, so no certificate obtained by this repository can satisfy the check. Both macOS matrix legs then failed, the build job failed with them, and the publish job was skipped by needs, leaving a release workflow that could not produce a Release on this fork. Signing is now opt-in: a tag push builds unsigned installers, and setting the repository variable MACOS_SIGN_RELEASE=true restores the sign-always behaviour once this repository owns a Developer ID certificate. workflow_dispatch keeps honouring its own sign_macos input, so the existing debug lane is unchanged. Unsigned macOS artifacts lose only the Developer ID seal and the notarization ticket; installer layout, artifact names, the updater feeds, and the publish job are all independent of signing.
The ci-workflow contract test pinned the old MACOS_SIGN_RELEASE expression, in which a tag push always signs. That guard is exactly what the release workflow change had to relax, so leaving it would have kept the pipeline red: the verify job runs the unit tests before any build job, and its failure skips publish. The test now pins the new contract instead: the opt-in expression must be present, the tag-forced form must be absent, and the existing assertions covering both macOS lanes are unchanged. Verified in both directions — it passes against the new expression and fails when the workflow is reverted to the old one, so the guard is not vacuous.
A vendor subscription account had no enable switch on its service row, so the only way to stop an account's models from being offered was to remove the account and sign in again. Every layer below the row already treated a disabled provider the same way it treats an API service: `providers.list` with `includeDisabled=false` drops it from the model picker, session launch fails with `PROVIDER_DISABLED`, and the settings list still shows the row with a disabled badge so it can be turned back on. Only the UI entry point was missing, which made the account look like it could not be switched off. The switch decision moves into a pure `serviceRowToggle` helper next to the row's other rules, so which kinds get a switch — and which get a locked one — is covered by tests instead of by a condition in JSX. A plugin-declared row still has no switch, because the plugin owns that row and refreshes it from its manifest on every load; that is now stated in the spec rather than only in a comment. The source-text assertion in settings-general.test.mjs followed the old condition and is repointed at the helper call; the behavior it stood for is asserted directly in service-row-status.test.mjs. fixes vastsa#930
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
问题 / Problem
设置里的「AI 服务」列表中，厂商订阅账户（Claude Pro/Max、ChatGPT 等）那一行没有启用开关。用户想停用一个不再使用的订阅账户时，唯一办法是删除账户再重新登录。
参考 #930。
根因 / Root cause
行以下的每一层早已把「已停用的 provider」和「API 服务」同等对待：
list_providers(include_disabled=false)→WHERE enabled = 1（providers/repository.rs:73）session-launch.ts:271、plugin-services.ts:314传includeDisabled: falseuseComposerModelMenu.ts:124过滤candidate.enabledPROVIDER_DISABLED失败（spec §11）service-row-status.ts:81对 account 行同样生效也就是说：数据层、徽章、下游过滤全都支持，唯独 UI 入口被挡住了。
ServiceRow.tsx里的kind !== "account"条件让 account 行渲染不出开关，于是这个能力看起来根本不存在。改动 / Change
把开关的判定抽成纯函数
serviceRowToggle（放在service-row-status.ts，与该文件既有的「规则用纯函数保持可测」一致）：已停用的账户在设置列表中仍然可见（带「已禁用」徽章），因此可以重新打开；其模型会从模型选择器中移除。
未改动：host-core、持久化、协议、模型选择逻辑、i18n 文案（复用已有的
settings.enabledToggle）。验证 / Verification
service-row-status.test.mjs）：已验证在旧实现下失败（把 helper 改回kind !== "account"时 2 条用例 fail），新实现下 12/12 通过pnpm --filter @pi-desktop/desktop typecheck通过pnpm lint通过apps/desktop全量测试：3260 pass / 1 fail / 7 cancelled；与origin/main基线完全一致（基线为 3258 pass / 1 fail / 7 cancelled，差额即本次新增的 2 条用例）。剩余的 1 项失败与 7 项 cancelled（provider error 文案、websocket 套件）为改动前既有，已用git stash在干净origin/main上复现确认cargo test规范 / Spec
同步更新了中英文规范中「enable/disable provider」条目，明确 account 与 API 服务共用开关、plugin 行没有开关：
docs/spec/03-runtime/11-provider-model-system.mddocs/zh-CN/spec/03-runtime/11-provider-model-system.mdNote for maintainer
这是一个
feat类型 PR。按 §15 现行临时政策，无写权限的外部贡献者的feat不属于落地候选 —— 落地需要 maintainer 授权此分支（或由 maintainer cherry-pick7a0160387）。fixes #930