pastilhas
0de38f0b13
The five connections in the database were never configured by anyone — a migration minted one per model from the adapter's own list, so the table held five decisions nobody made. What that list actually is, is a CATALOGUE: what you can choose from, which is not the same kind of thing as what you chose. So it is a file. `sidecar/catalogue/shipped.ts` is the curated baseline, in git, reviewed; `$OFFICER_ROOT/data/atelier/catalogue.json` is what a refresh writes, and it wins where it has something to say. Data dir, not the plugin dir — a plugin directory is a clone an update replaces, which is the rule env.ts already states for images. Refresh runs in the sidecar, daily, and only on boot when the file is actually stale — this process has restarted twenty times in an afternoon and should not hit OpenAI twenty times for it. Two sources, unequal, and the code says so. `GET /v1/models` is authoritative and thin: ids and nothing else, so a model matching /^(gpt-image|dall-e)/ appears the day it ships without a release. Prices come off an HTML page because there is no pricing endpoint for any plan, and that parser is written to give up rather than guess — a guess gets written to disk and then believed. When it gives up it says so in the log; the durable replacement is handing the page to a model for structured output, which Officer can already do locally. Nothing a refresh cannot establish overwrites a curated value: fields merge one by one, not objects wholesale, so an id-only listing cannot wipe the sizes and prices that were written by hand. Retiring is decided by the merge, which can tell a complete listing from a request that failed halfway — and it marks `deprecated` rather than deleting, because the gallery labels 88 historical rows from this list. Per-model sizes, qualities and transparency now travel with each entry, which is what will let the form stop offering dall-e-2 a transparent background it cannot do. The catalogue is advisory throughout: validate.ts still refuses to enforce per-model rules, exactly as before.
Atelier
Image generation for an Officer server: a provider-shaped API over OpenAI's image endpoints, storing what it makes so every image has a durable reference — a gallery you can browse, collections you can organise, and a job an agent can poll rather than block on.
Atelier was a standalone service before this plugin existed
(~/officer-dev/dockers/officer-atelier, still running as officer-atelier, still what the mobile app
talks to). This plugin is a fresh extraction into Officer, not a replacement for it yet — see
PLUGIN.md before assuming the two are interchangeable.
What you get
- Generate — a prompt, a model, size/quality/background, and a job you watch settle.
nimages becomenindependently-tracked rows, so one failure out of four does not discard the three that worked. - Gallery — everything generated, newest first, with a lightbox: pan, zoom about the cursor, checkerboard/dark/light backdrops for telling a transparent background from an opaque one that only looks it.
- Collections — named sets of images. A generation request can name one by name and it is created on first use; the gallery and the lightbox can file an image into one after the fact.
- A provider-shaped backend. "OpenAI" is code, written once; a provider is a row — which model, whose key, on or off — and several can share one adapter. Today OpenAI is the only adapter; the point of the shape is that a second one is a new file, not a redesign.
- An OpenAI-compatible job API, for agents.
POST /api/atelier/images/generationsaccepts OpenAI's request body verbatim and answers202with a job id rather than blocking for the length of the generation — the caller pollsGET /api/atelier/images/generations/:id, optionally with?wait=to long-poll instead of retrying in a loop.
Requirements
- An Officer server, version 1.0.0 or later.
- A separate Postgres database, and its own environment variable:
OFFICERDEV_POSTGRES_URL. Atelier's tables (generations,collections,collection_items,providers) do not live inofficer_db— seePLUGIN.mdfor why, and set this before installing. There is no default. - An OpenAI API key, set with
bun run secret:set atelier-openai-key, or configured per-provider in Settings → Integrations → Atelier, or (for an install that predates the secret store) asOPENAI_API_KEYin.env.
Install
From the Officer marketplace: find Atelier, install. That mounts /api/atelier and /atelier, starts
the officer-atelier sidecar under PM2, and connects it to whatever OFFICERDEV_POSTGRES_URL points at —
which has to already have the schema (the standalone repo's own bun db:push creates it; this plugin
does not run migrations against a database it does not own the schema of).
Uninstalling stops the sidecar and unmounts the route. It never touches your database — Atelier's tables and rows are not this plugin's to drop, since it does not own the schema push for them either.
Permissions
One permission, atelier, grantable per role at read or write.
- Read lets an account use Generate, browse the Gallery and Collections, and see which providers are configured (never a key, in any form — not even masked).
- Write additionally lets an account add, edit or delete providers, including their API keys. A provider's key authorises real spend on someone's OpenAI account, so treat write here the way you would treat write on any billing-adjacent surface.
Providers is not a panel — it is a platform Settings screen (Settings → Integrations → Atelier), because
it is owner-level configuration rather than a working view. See PLUGIN.md for why.
Limitations, honestly
- Two Ateliers can exist at once. This plugin and the standalone service are independent — installing
this one does not migrate the standalone one's data, stop it, or repoint the mobile app. See
PLUGIN.md. - No per-user data. Every account with
readsees the same gallery and the same collections — there is no ownership model yet, the same simple shape offscale shipped with first. - The database is separate from
officer_db, which means Atelier's tables are not covered bybun db:push, are not part of the platform's usual backup story unless you back up the second database too, and need their own connection string. Migrating them in is real, tracked follow-up work — seePLUGIN.md.