Plugins: capability you turn on

Every Vocion feature so far arrived one of two ways. Either it was core — TypeScript, a migration, a page — or it was a workspace — YAML and markdown a tenant authors. The middle was missing: a capability that is more than one workspace's opinion and less than a subsystem. A wiki. A data room. A proposal writer. Things a second seller would want on day one, that should compose from what core already runs, and that a workspace should be able to turn on without a fork.

Vocion 2.117 adds that middle: plugins.

# workspace.yaml
plugins: [wiki, data-rooms, proposals]

What a plugin is

A directory under templates/plugins/<slug>/ with a plugin.yaml and the same folders a workspace has: agents/, skills/, objects/, missions/, automations/, teams/, pages/, trust.yaml. The loader composes it as an inherited layer — above the base pack, under the workspace — exactly the way the base pack already works. Always active. Overridable by slug (extends: core to patch an agent, whole-file replace for a skill). Suppressible with disable:. Each plugin's version folds into the workspace sha, so a toggle is a new sha and the audit trail says what ran.

Core ships the mechanism — the artifact noun, the room noun, the render-verify engine, the tools, the page archetypes, the event bus, the trust ladder. A plugin ships the meaning — which agent, on what cadence, graded on what, with which pages. The workspace ships the concretion — its brand, its overrides, its own facts. Anything true of one seller stays in the workspace; anything two sellers would want becomes a plugin; core changes only when a seam is missing.

Three doors, one write

You can turn a plugin on from workspace.yaml, from the Marketplace, or from chat.

The Marketplace (/dashboard/marketplace) lists what this core can turn on, what each plugin adds — agents, skills, pages, automations, the team it is graded on — and when the chat will recommend it. Turn on edits workspace.yaml with its comments intact and applies it; the receipt is the new sha.

The chat door is the one we wanted most. Every agent now carries a short note about the plugins that are off and when each helps, written in the plugin's recommend.when in the words a person would use: "a person repeats a standing fact or rule they have said before", "a deal reaches a proposal stage and nothing is drafting the document". When a conversation matches, the agent recommends the plugin as a one-tap card. The card is a reversible plugin.enable action, so under the done-for-you default it runs above the confidence bar with Undo one move away. list_capabilities gives the agent the full read — every plugin, every connector, connected or not — so a gap becomes a recommendation instead of a workaround.

All three doors are the same edit to the same file. The workspace stays the source of truth.

The three that ship

Wiki — the workspace's long-term memory: the voice, the standing rules, who is who, the decisions that hold. Pages are markdown artifacts, so versions, restore, preview, share and citation came free. Every agent gets the index and the pages that fit in context each turn. The writer is the agent: write_wiki_page proposes with a confidence, and above the plugin's bar the page is written at once with Undo; below it a person decides on a Review card. Every save indexes for search. A curator consolidates the week every Friday. Its own post.

Data rooms — one room per engagement, the source of record a document is written from. The plugin brings the room type, the filing skill, the Room keeper and its weekday mission, the Data rooms row, and the after-sync collector that files clear matches with a score and asks about plausible ones.

Proposals — the Proposal Writer, the house sheet framework, the Proposals app over every engagement at Proposal stage, a Monday verify mission. Depends on data rooms. Both, in one post.

A plugin that improves itself

Every plugin ships a team with measures, read from rows Vocion keeps: rooms opened and sources filed; proposals rendered and proposals verified clean; wiki pages written by the curator and wiki edits a person had to decide (the fewer, the more trusted). Every plugin ships a mission on a schedule, so it works without being asked. Corrections in chat become learnings, room rules or wiki pages, and the trust ladder promotes what people keep approving.

That is the loop the design principles describe — outcome, work, measure, learn, improve, automate — inside one directory.

What changed in core to make it possible

The wiki needed four seams none of the plugins could ship as YAML, and each landed as a generic mechanism rather than a wiki feature:

• artifact.saved, an event every artifact save emits, plus an index-artifact job — so any folder of artifacts can be indexed for search with one automation.
• rows: artifacts as a measure source, narrowed by kind, folder, playbook or verified state — so a team can be graded on what was written.
• list_capabilities and the capabilities note — so the chat can recommend anything that is off.
• Agent proposals with a confidence are always judged by the ladder. Until now every registered action touched the outside world, so the permission gate and the done-for-you bar agreed. The first internal kinds exposed the gap — a wiki write at 0.45 confidence ran past a 0.6 bar — and the fix makes the rule explicit: an agent's confidence decides, never its autonomy alone.

Plus enabled_plugins on the project, plugin-owned nav rows, plugin pages beside workspace pages, and the docs/plugins.md guide to writing one.

Upgrading

Nothing changes for a workspace that names no plugins:. The client-documents sample workspace is now plugins: [proposals] plus a brand; a workspace that copied its files can delete the copies and add the line. workspace:check names anything that collides.