pastilhasandClaude Opus 5
282a64a637
the rest of the mechanism, and it works end to end. against a real server, with
no restart at any point:
/api/example/ping BEFORE install 404
AFTER install 200 {"plugin":"example","ok":true}
AFTER disable 404
AFTER enable 200
AFTER uninstall 404
core route throughout 200
plugin_installs is a new table rather than a reuse of sidecar_installs. that one
belongs to the app store's model, where installing means provisioning a
container or pointing at a remote instance, and it carries mode, compose_dir and
completed_steps to say so. a plugin install has none of those, and reusing it
would have meant a `mode` that lies about every plugin. the two models coexist
until the app store is rebuilt on this one.
the row is needed because presence is not installation: plugins live in the
repository, so a developer writing one has the directory there and has installed
nothing. the tree says what could run, the table says what does.
mount.ts joins the two and rebuilds. an install row whose directory has gone is
dropped from the snapshot rather than reported — but the row is left in the
database, because deleting it there would turn "somebody moved the checkout"
into silent data loss. a plugin whose router will not load stays unmounted and
says why, rather than taking the other nine down with it.
/api/plugins is owner-only in its own right, like /api/app-store, and its
capability guards the MANAGEMENT surface only — a plugin's own permissions come
from its manifest, so a member can hold one at read without being able to
install anything.
plugins/example is the reference implementation and is meant to be read: the
smallest thing that is still a real plugin, with the directory layout as its own
documentation.
not wired yet, and marked [open] in the router: the schema push and the
sidecar's pm2 entry. a plugin with db/schema.ts or sidecar/ needs both before it
works end to end.
full suite: 719 pass, same 10 pre-existing failures.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
30 lines
1.2 KiB
TypeScript
30 lines
1.2 KiB
TypeScript
import type { PluginManifest } from '@@/plugins/manifest';
|
|
|
|
// The reference plugin. Not a fixture — this is what a plugin author reads first, and it is deliberately
|
|
// the smallest thing that is still a real one: a manifest and one route.
|
|
//
|
|
// Everything structural is convention, so this directory IS the documentation:
|
|
//
|
|
// manifest.ts you are here — only what a directory listing cannot say
|
|
// api/router.ts exports `router`; mounted at /api/example
|
|
// db/schema.ts tables, if it had any (every name prefixed `example_`)
|
|
// sidecar/index.ts a process, if it needed one (.mjs instead means node)
|
|
// web/Router.tsx a frontend, if it had one
|
|
//
|
|
// `appName` is not declared anywhere: it is the directory name, so the id cannot disagree with where the
|
|
// code sits.
|
|
export const manifest: PluginManifest = {
|
|
publisher: 'officerdev',
|
|
version: '1.0.0',
|
|
platform: '>=1.0.0',
|
|
|
|
label: 'Example',
|
|
summary: 'The reference plugin — one route, nothing else',
|
|
icon: 'Puzzle',
|
|
color: '#94a3b8',
|
|
|
|
// Empty is meaningful: this plugin gates nothing of its own and is reachable by anyone who can reach
|
|
// the platform. A plugin with a surface worth protecting declares a permission here instead.
|
|
permissions: [],
|
|
};
|