Composition notes

• Open — the entity definition. This page treats a plugin as a harness extension that bundles skills, slash commands and MCP servers, installed per harness and present on an install when its synced config lists it (the world's proposed shape; no ruling exists — prior-art §7). Not yet decided: whether a plugin is harness-specific packaging (a Claude Code plugin manifest, a Codex extension), a distribution unit for skills (then Skills owns the story and this page collapses into a provenance column), or a vendor concept we should not model. The row stays so the question is visible, not buried.
• Question: what harness extensions are installed, and what do they bundle? — and the follow-up the world can answer: did a plugin drag in something nobody exercises or nobody reviewed. Structural clone of the Tools/Skills listing (execution-plan #12–14 share a shape).
• Verdict line from pluginsVerdict(world) in derived/plugins.ts: plugins on n of m installs across harnesses, what the most-installed plugin bundles, and the one thing wrong if there is one. It sharpens verdicts.plugins (a placeholder that is always clear) — fold in at Stage 5. Tone is attention when a bundled skill has never run or a bundled server is unreviewed; never warn.
• Framing band = four blocks: plugins (reset) · installs carrying a plugin of the fleet's installs (a plain claim — installs are not rows here) · bundled items, with the skills / commands / MCP split as its sub (a plain claim — every plugin bundles something, so a per-kind filter earned nothing) · one attention device: bundled items needing attention, which in the calm state prints 0 and says what was checked. The open entity definition sits under the band as one line, after the verdict — the greeting stays the greeting.
• Table is the raw UxTableList family so ?id= can pre-open a row. Rows from pluginRollup(world), ranked attention → installs → name; sorters on every column; search on the Plugin header matches name, harness, source and everything bundled. Installs print carrying / all installs of that harness so the denominator is on the row.
• Row attention device is the invocations column: the sub-line goes amber and names what is wrong ("1 of 2 skills never run", "1 server unreviewed"); the count itself stays content-colored — a healthy 41 is not the alarm. Everything else on the row is grey structure; the Bundles cell prints only the kinds a plugin actually bundles, no zero pills.
• Expand = header (harness chip → Agent Inventory, version, source, the of-m denominator, invocations, last invocation, and an honest "view details" stub — the protocol's plugin home is this page, so there is no detail page to link) · bundled contents as Phase1EntityChip rows (skills → Skills, MCP servers → MCP servers; commands as plain mono tags — no entity page, no telemetry) · installs carrying it (agent chip → Agent detail, person → User detail, device → Device detail, monitored pill, harness version, last seen).
• Derivation: which installs carry a plugin is read from instances[].pluginIds only; invocations sum the bundled skills' invocations30d; a plugin with no skills prints — rather than 0 because commands are not observed. Nothing hand-typed. Both states share the same rows and bundle counts — what a plugin bundles is a fact; whether it is exercised is the posture, and only that moves between attention and all-clear.
• Also open: the word for the technology level ("harness" here, "technology" on Agent Inventory — c21 left it open); whether a plugin's version drift across installs is worth a column once the world has more than one version of one plugin.