It described a separate atelier Postgres database, providers as a section in
Officer's settings, and a BLOCKERS.md that was never committed here — none of
which is true. It is now what the code does, and why: the three words that are
not interchangeable, where keys live and why getSecret rather than getKey, the
catalogue's four rules, why refresh is a button, what a refresh can and cannot
learn, and the two ceilings the 240s poll sits under.
Written so that someone arriving cold can carry on from here.
Both masters already existed in OfficerIcons — the painter duck with the
beret and palette — so the plugin was showing a flat #f59e0b square for want
of a copy step, not for want of art.
The icon master is 1312x1199, not square, so it is trimmed to the artwork
before it is fitted to 256: resizing that canvas directly would have drawn the
duck at about four fifths the size everything else in the dock uses. Splash is
a straight 1254 -> 1024, and PLACEHOLDER.md goes with them.
the extraction kept atelier's own postgres database, because the brief said to
when the tables already had rows. the owner reversed it, and the reason is not
tidiness: a plugin that behaves differently from every other plugin is a
plugin nobody can reason about.
the separate database meant a second connection string to set before install,
a second thing to back up, a second thing to get wrong on a new machine, and
failure modes no other plugin shares — none of it bought anything except
avoiding a migration.
four tables now: atelier_collections, atelier_collection_items,
atelier_providers, atelier_generations. index and check constraint names carry
the prefix too — those are global in postgres and are the one thing that would
otherwise collide with another plugin.
db/schema.ts re-exports the definitions rather than duplicating them: they stay
beside the code that queries them in sidecar/db/, and that file exists to be
found by gen-plugin-schemas.
ATELIER_POSTGRES_URL is gone. db.ts reads OFFICERDEV_POSTGRES_URL ?? POSTGRES_URL,
which the platform already sets.
the standalone service's rows are NOT here and nothing depends on them being
here — the old service is still running against the old database, untouched,
and migrating is a separate watched step after this is proven on alpha.
generatePluginsModule + rebuildFrontend, called directly with a synthetic install state, exercises
the same Bun.build + Tailwind path a real install performs — no server running, no port bound. It
compiled cleanly: 3 outputs, 2.2s, zero errors. Stronger than tsgo alone (catches bundler-side module
resolution and JSX/CSS processing), but does not confirm the result renders correctly in a browser —
noted as still open.
PLUGIN.md is the record: what moved, what changed on the way (authenticated image serving, the
secret-store OpenAI key fallback, provider_settings left behind), what stays running untouched (the
standalone service the mobile app still talks to), why there is no db/ directory, and what verification
did and deliberately did not cover.
README.md is the marketplace shop window — what it does, what it needs (its own Postgres database,
an OpenAI key), and an honest limitations section: two Ateliers can exist side by side right now, and
there is no per-user data model yet.
pastilhas