Core-side work item for the add-on's R-07 risk: provider churn routing around sovereignty governance. The add-on repo tracks the risk (add-on #36); the enforcement lands here.
The risk: omp's builtin provider registry is at 57 ids on the pinned version and grows every bump (qianfan, alibaba-coding-plan, minimax-code-cn, xiaomi-token-plan-cn/-ams, zhipu-coding-plan, zai, deepseek, moonshot, kimi-code, qwen-portal, ...). Provider churn can route around sovereignty governance silently.
Current state: P-ENT.1 (ADR-0068) shipped the ManagedModels schema (allowed/denied substring lists + lock) and the pure modelAllowed() helper, and ADR-0217 wired fail-closed enforcement for the asksageOnly lock (enforceAsksageLock clamps the model before every turn). But modelAllowed has ZERO live call sites: the allowed/denied policy is schema-only, never enforced. And nothing watches omp's provider list for growth.
Scope (mirrors the ADR-0217 pattern exactly, no new machinery):
- Pure resolveGovernedModel(locked, models, current, options) in desktop/checker_model.ts: applies the AskSage lock first (existing resolveLockdownModel), then modelAllowed; picks the first option satisfying BOTH when the current model is denied; fail-closed error when nothing qualifies.
- acp_backend: enforceAsksageLock becomes enforceModelPolicy (same two call sites: session config sync + the authoritative pre-turn clamp); resolveAgentRunModel (built-agent runs) goes through the same resolver; accessibleModels applies the policy as a cosmetic picker filter with the same only-narrow-if-nonempty fail-safe the AskSage narrowing uses (the turn clamp stays authoritative).
- CI diff against omp's provider list: a test pinning the sorted CATALOG_PROVIDERS ids from @oh-my-pi/pi-catalog. A new provider on an omp bump fails the test with the list of additions and instructions (review against sovereignty allowlists / the add-on's governance packs, then re-pin). Removals surface too (they can break configured allowlists).
Non-goals: no pack parsing in core (signed-pack verification stays add-on-side; packs feed the managed-config models block through the existing ADR-0068/A010 channel). No UI changes (the lock/'Managed by org' plumbing already exists).
Done when: a managed models.allowed/denied policy actually constrains every turn and built-agent run fail-closed; the provider-catalog diff test pins the current ids and fails on drift; make test green.
Core-side work item for the add-on's R-07 risk: provider churn routing around sovereignty governance. The add-on repo tracks the risk (add-on #36); the enforcement lands here.
The risk: omp's builtin provider registry is at 57 ids on the pinned version and grows every bump (qianfan, alibaba-coding-plan, minimax-code-cn, xiaomi-token-plan-cn/-ams, zhipu-coding-plan, zai, deepseek, moonshot, kimi-code, qwen-portal, ...). Provider churn can route around sovereignty governance silently.
Current state: P-ENT.1 (ADR-0068) shipped the ManagedModels schema (allowed/denied substring lists + lock) and the pure modelAllowed() helper, and ADR-0217 wired fail-closed enforcement for the asksageOnly lock (enforceAsksageLock clamps the model before every turn). But modelAllowed has ZERO live call sites: the allowed/denied policy is schema-only, never enforced. And nothing watches omp's provider list for growth.
Scope (mirrors the ADR-0217 pattern exactly, no new machinery):
Non-goals: no pack parsing in core (signed-pack verification stays add-on-side; packs feed the managed-config models block through the existing ADR-0068/A010 channel). No UI changes (the lock/'Managed by org' plumbing already exists).
Done when: a managed models.allowed/denied policy actually constrains every turn and built-agent run fail-closed; the provider-catalog diff test pins the current ids and fails on drift; make test green.