@mmmbuto/nexuscrew 0.9.76 → 0.9.77

package/CHANGELOG.md

@@ -2,6 +2,11 @@
 
 All notable changes to NexusCrew are tracked here.
 
+## 0.9.77 — 2026-10-19
+
+- **An engine that exposes no model listing still gets its known ids and their catalog defaults.** The discovery proposal is now composed for every engine, not only those with an HTTP listing: the ids the operator declared, the profile backup, and — when it is the only known id — the engine's own active model are merged with the public catalog, so an engine whose client owns its own endpoint — the `pi` family included — shows its models with the same field-by-field sources, the same default badge and the same edit/confirm actions. The API layer is explicitly unavailable in that case: `supported` and `source: unsupported` stay truthful, no collector and no request are invented, the authentication diagnosis reports no attempt and no cause, and `inApi` is absent rather than false because no API answered. The precedence is unchanged (user, then API, then the public catalog, then the backup); an explicit user `false` still wins, no model id is ever added from the catalog, and with no known id the snapshot is not fetched at all. The missing-data dialog also works on this proposal, so a default can be confirmed into a user value without any automatic write.
+- **A `pi` profile with a resolved transport is interrogated through the collector of that transport, not its name.** The endpoint follows the launcher's precedence (normalized spec, generated provider extension, profile), and the wire name is normalized across its hyphenated and underscored spellings: OpenAI-compatible endpoints use the OpenAI-compatible collector, Ollama uses the native Ollama listing, and Anthropic Messages uses its own. Native or login flows (`pi_native`), including Z.AI through the client's own login, remain unsupported unless an explicit listing contract exists — an endpoint alone is not proof of a listing API. Credentials are only the ones the node is already authorized to resolve for that profile and endpoint, in memory; the client's own auth store is never read, and when only delegated authentication exists the listing can be unavailable while the client stays configured, with no false prompt to repair a login. The public snapshot remains the fixed keyless URL, and nothing about an engine's endpoint, model names or keys is sent to it.
+
 ## 0.9.76 — 2026-10-19
 
 - **A listing that refuses the request now says why, without guessing about the key.** The model listing in the engine editor carries a curated diagnosis built from facts the node already has: the credential's resolution state (none, configured, missing, unreadable), whether the credential header was actually applied to the request that failed, and whether a fresh cache answered instead of a request. The causes are fixed strings: a 401 without a credential is a missing key (naming the environment variable only when it is already public in the editor); a 401 with the header applied is a key the server did not accept, never a claim that the key is wrong or expired; a 403 is access denied with or without a key, because permissions and policy can produce it; an unreadable credential is unavailable, not missing; a network or timeout failure is an unreachable endpoint; any other status or an invalid response is a provider error; and a successful anonymous listing says the listing came back without a key, not that the endpoint never asks for one. A fresh cache answer makes no claim at all. The line stays visible with stale or backup data and with an empty list, and credential values never leave the node — not in the route, not in the cache, not in an error.