pastilhas
19e94129a0
The dropdown was listing "connections" — a row per adapter + model + key — which made choosing a model an act of configuration, put a key icon and a bin inside a menu item, and showed five accounts nobody had created. A provider is now a vendor Officer curates. Every one is listed, set up or not, because a vendor you have no key for is exactly what you need to see in order to add one. The model is chosen per generation, from that provider's entry in the catalogue, beside it. With the model off the row, all that remained of a "provider" was the key for OpenAI — and Officer already stores keys: one active value per purpose, 0600 inside a 0700 directory, outside the backup tarball, created on first use so nothing needs provisioning. So `atelier_providers` is dropped, along with `generations.provider_id` that pointed into it. `provider` and `model` stay as text on each generation, which were always the historical fact rather than a pointer to configuration. `getSecret`, never `getKey`: this is a foreign credential, and getKey mints a random value for a purpose it cannot find — which for someone else's API key means authenticating with something invented. Resolution follows: a request names a model, and the catalogue says whose it is, rather than a database being asked which stored row served it. A model nobody in the catalogue claims is still accepted — the catalogue is advisory, and a model released today should work before we ship a file that mentions it. Two routes replace five: PUT and DELETE on /providers/:name/key. Deleting a key that came from the environment is refused rather than faked — it belongs to the install, not to this screen.
19 lines
1.2 KiB
TypeScript
19 lines
1.2 KiB
TypeScript
// The plugin's tables, where the platform looks for them.
|
|
//
|
|
// `scripts/gen-plugin-schemas.ts` writes `plugin-schemas.gen.ts` from every plugin's `db/schema.ts`, and
|
|
// that generated barrel is what `bun db:push` reads. So this file exists to be FOUND — the definitions
|
|
// themselves live beside the code that queries them, in `sidecar/db/`, and are re-exported here rather
|
|
// than duplicated.
|
|
//
|
|
// Two tables, not three: `atelier_providers` is gone. A provider is a curated vendor plus a key in the
|
|
// platform's secret store, so there is no provider state in Postgres to keep — see
|
|
// sidecar/providers/credentials.ts.
|
|
//
|
|
// Everything is `atelier_`-prefixed and lives in officer_db, exactly like every other plugin. The
|
|
// extraction originally kept Atelier's own `atelier` database, on the reasoning that its tables already
|
|
// had rows. That was reversed on 2026-08-20: the plugin starts EMPTY here, and the standalone service's
|
|
// data is migrated deliberately afterwards, with someone watching. A plugin that behaves differently
|
|
// from every other plugin is a plugin nobody can reason about.
|
|
export * from '../sidecar/db/collections/schema';
|
|
export * from '../sidecar/db/generations/schema';
|