pi-provider: no update path for a provider with hand-authored model fields #94

New issue

Closed

opened 2026-10-21 20:52:22 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-10-21 20:52:22 +01:00

pi-provider has no way to update an existing provider whose stored models carry fields outside discovery's translation allowlist (compat, thinkingLevelMap), so those catalogs are hand-edited even though the tool is the declared owner of provider updates.

Primary goals:

Give an update path — let an operator change the models of an existing provider that carries hand-authored fields, without retiring and re-adding its credential.
Keep the discovery boundary — discover-refresh still refuses fields discovery cannot regenerate; the update path is explicit, not a relaxed allowlist.
Stop pointing at a dead end — no diagnostic should recommend a command that refuses an existing provider.

Current state

discover-refresh refuses any stored model carrying a key outside api, contextWindow, id, input, maxTokens, name, reasoning (scripts/pi-provider:857). A provider using compat (developer-role control, adaptive thinking) or thinkingLevelMap therefore cannot refresh at all.

add and discover-add refuse whenever the provider already exists (scripts/pi-provider:835 and :996), so there is no in-place update path either. The only option left is editing the provider JSON by hand and relying on the catalog build check.

allod/nexus#34 kept compat/thinkingLevelMap refused and out-scoped turning add into an update command, which left this gap untracked. This issue is the tracked ask. The separate failure where the credential-registry validator rejects object-form targets is tracked by allod/nexus#36 and allod/secrets#16 and is not this issue's subject.

Scope

In scope: one explicit update path for a provider with hand-authored model fields. Smallest option: let add --models-file accept an existing provider and replace only its models, leaving the credential, targets, named tokens and provider-level fields alone. Alternative: have discover-refresh preserve the hand-authored keys it cannot regenerate.

Out of scope: relaxing the discovery allowlist generally; any change to discovery HTTP, bearer, transaction or recovery behavior (allod/nexus#32).

Validation

bash tests/pi-provider.sh
nix build .#checks.x86_64-linux.provisioning-contract

A fixture that updates a stored provider carrying compat and proves every other field survives, plus a refusal witness for the custom-name and unsupported-field cases.

`pi-provider` has no way to update an existing provider whose stored models carry fields outside discovery's translation allowlist (`compat`, `thinkingLevelMap`), so those catalogs are hand-edited even though the tool is the declared owner of provider updates. Primary goals: - **Give an update path** — let an operator change the models of an existing provider that carries hand-authored fields, without retiring and re-adding its credential. - **Keep the discovery boundary** — `discover-refresh` still refuses fields discovery cannot regenerate; the update path is explicit, not a relaxed allowlist. - **Stop pointing at a dead end** — no diagnostic should recommend a command that refuses an existing provider. ### Current state `discover-refresh` refuses any stored model carrying a key outside `api`, `contextWindow`, `id`, `input`, `maxTokens`, `name`, `reasoning` (`scripts/pi-provider:857`). A provider using `compat` (developer-role control, adaptive thinking) or `thinkingLevelMap` therefore cannot refresh at all. `add` and `discover-add` refuse whenever the provider already exists (`scripts/pi-provider:835` and `:996`), so there is no in-place update path either. The only option left is editing the provider JSON by hand and relying on the catalog build check. allod/nexus#34 kept `compat`/`thinkingLevelMap` refused and out-scoped turning `add` into an update command, which left this gap untracked. This issue is the tracked ask. The separate failure where the credential-registry validator rejects object-form targets is tracked by allod/nexus#36 and allod/secrets#16 and is not this issue's subject. ### Scope In scope: one explicit update path for a provider with hand-authored model fields. Smallest option: let `add --models-file` accept an existing provider and replace only its `models`, leaving the credential, targets, named tokens and provider-level fields alone. Alternative: have `discover-refresh` preserve the hand-authored keys it cannot regenerate. Out of scope: relaxing the discovery allowlist generally; any change to discovery HTTP, bearer, transaction or recovery behavior (allod/nexus#32). ### Validation ``` bash tests/pi-provider.sh nix build .#checks.x86_64-linux.provisioning-contract ``` A fixture that updates a stored provider carrying `compat` and proves every other field survives, plus a refusal witness for the custom-name and unsupported-field cases.

vnprc referenced this issue from a commit

2026-10-21 22:10:17 +01:00

pi-provider: let add --models-file replace an existing provider's models

allod-agent commented

2026-10-21 22:11:16 +01:00

Member

Landed on master in 8db259f: add <provider> --models-file <path> on an existing provider replaces only its models; discover-refresh refusals now name that path. Validated by bash tests/pi-provider.sh (364 assertions) and the provisioning-contract check.

Landed on master in 8db259f: `add <provider> --models-file <path>` on an existing provider replaces only its models; discover-refresh refusals now name that path. Validated by `bash tests/pi-provider.sh` (364 assertions) and the provisioning-contract check.

allod-agent closed this issue

2026-10-21 22:11:16 +01:00

allod-agent referenced this issue

2026-10-21 22:32:26 +01:00

pi-provider: give one machine its own bearer on a provider #95

allod-agent referenced this issue

2026-10-21 22:32:33 +01:00

Support per-target bearers in pi-provider #36