Problem

docs/configuration.md says the plugin loader (#206, landed in #589) works by declaring apps in config:

declare the apps in config and the server imports, mounts, and tears them down itself

But bin/jss.js passes an explicit allowlist of keys to createServer(...), and neither plugins nor appPaths (#582) is in it. loadConfig merges them from config.json fine — they just never reach createServer. So:

jss start -c config.json   # config.json contains a plugins: [...] array

boots a server with no plugins and no error — exactly the silent-missing-app failure mode src/plugins.js was designed to refuse ("a plugin that fails to load fails the boot loudly").

Practical consequence: the #206 loader is programmatic-only today. Anything that drives JSS through the CLI — including servejss — can't mount plugins at all.

Fix

Forward both keys in the createServer call in bin/jss.js:

appPaths: config.appPaths,
plugins: config.plugins,

(createServer already defaults both when undefined, so this is safe for configs that don't set them.)

Follow-ups (separate, if wanted)

1. --plugin <module[@prefix]> CLI flag (repeatable) so mounting an app doesn't require a config file — which would also let servejss forward it and gain servejss --plugin ./chat/plugin.js@/chat ./public.
2. pluginDataDir option: api.storage.pluginDir() resolves to <root>/.plugins/<id>. Under servejss, root is the directory the user pointed at, so a plugin using storage writes .plugins/ into the served tree — the same directory-pollution class --public mode seeds the server-root landing page into the served directory (namespace pollution for servejss / serve use case) #578 just fixed for seeding. An override letting operators park plugin data outside the data root would close it.