every plugin route renders a workspace, and it is not a rule you can forget

an exclusionary rule, made structural. a plugin does not render a screen: it
contributes panels and says how they are arranged, and the shell renders
WorkspaceView around them.

    web/panels.ts   appRegistryMetas — at least one panel
    web/layout.ts   defaultLayout — how they are arranged

both required the moment web/ exists, and missing either is refused at discovery
by name and with the reason. tested:

    probeplug: has a web/ directory but is missing web/layout.ts.
    Every plugin route renders a Workspace: contribute panels and a layout,
    not a screen.

there is deliberately no way to export a component. one that could would be free
to render a bare div, a full-page form, or its own navigation, and the platform
would become a shell hosting strangers' layouts rather than one application.
non-compliance is not so much refused as unrepresentable — there is nowhere to
put a screen.

the shell registers <prefix> and <prefix>/:section, exactly as the core screens
do, so a plugin's sections stay addressable and cmd-clickable, and panels read
useParams independently rather than passing state between themselves.
appTypes.allowed is pinned to that plugin's own keys, so a persisted layout
naming something else falls back instead of rendering another plugin's panel
inside this screen.

the example plugin is rebuilt to model it — two panels, a layout, one of them
calling its own /api/example/ping through useClient — because the reference
implementation is what everyone copies.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/apps/officer-web/Screens/Dashboard/PluginScreen.tsx

@@ -0,0 +1,38 @@
+import type { LayoutNode, AppRegistryMeta } from 'officerdev';
+import { WorkspaceView } from 'officerdev';
+import { useDashboardState } from 'state/useDashboardState';
+
+// The screen every plugin route renders. THE PLUGIN DOES NOT RENDER A SCREEN.
+//
+// ── The rule, and why it is shape rather than policy ──
+//
+// Every plugin route renders a Workspace with at least one panel. A plugin that exported a component
+// could render anything at all — a bare div, a full-page form, its own navigation — and the platform
+// would be a shell hosting strangers' layouts rather than one application. So a plugin does not get to
+// render the screen: it contributes panels and says how they are arranged, and this renders the
+// Workspace around them.
+//
+// Non-compliance is therefore not refused, it is unrepresentable. There is nowhere to put a screen.
+//
+// `locked`, like every core screen: a plugin's layout is its author's design, not a workspace the user
+// rearranges — and `appTypes.allowed` pins it to that plugin's own panels, so a persisted layout naming
+// something else falls back rather than rendering another plugin's panel inside this one.
+export function PluginScreen({
+  appName,
+  panels,
+  layout,
+}: {
+  appName: string;
+  panels: AppRegistryMeta[];
+  layout: LayoutNode;
+}) {
+  // Per-user and per-plugin, so two plugins never share a layout and a user's arrangement is their own.
+  const workspace = useDashboardState<LayoutNode>(`screens/plugin/${appName}`, layout);
+  const allowed = panels.map((panel) => panel.key);
+
+  return (
+    <div className="h-full w-full pt-2">
+      <WorkspaceView workspace={workspace} locked appTypes={{ allowed, fallback: allowed[0] ?? '' }} />
+    </div>
+  );
+}