#596 made relay/plugin.js derive plugin id relay — parent directory for the generic basename. That works when the plugin file sits directly in the app's directory, but an emerging convention is for an app repo to carry its pod-side integration in a pod/ subdirectory:

gamestr/
  pod/plugin.js        ← the app's jss plugin
  index.html           ← the rest of the app

With that layout the derivation stops one level short: gamestr/pod/plugin.js → id pod. First observed in production after restructuring the gamestr plugin — .plugins/pod appeared and the boot log reads plugin pod active at /gamestr.

Harmless with one app, but the id must be unique, so the convention cannot scale — every app following it derives the same id:

--plugin ~/apps/gamestr/pod/plugin.js@/gamestr   → id "pod"
--plugin ~/apps/chess/pod/plugin.js@/chess       → id "pod"   ← collision

Two plugins, no ambiguity in anything the operator typed, yet they collide on the inferred name (and would otherwise share .plugins/pod private storage).

Proposed fix — the same idea as #596, one level up: when the basename is generic (plugin.js) and the parent directory is also generic, keep walking to the grandparent. A small generic-dir set covers the conventions in the wild: pod, plugins, plugin, src, lib, dist.

• gamestr/pod/plugin.js → gamestr
• chess/pod/plugin.js → chess
• relay/plugin.js → relay (unchanged)
• plugin.js at repo root → unchanged fallback

Complementary option: an explicit-id grammar for the CLI flag, e.g. --plugin module[@prefix][#id] — config-file entries can already set id, but CLI users have no equivalent, so today the only workaround is renaming directories.

Happy to PR the derivation change with tests if the approach looks right.