Data rooms and proposals, as plugins

Two weeks ago the client-engagement workflow shipped as a sample workspace: a data_room object type, a data-rooms skill, a Proposal Writer, a proposal-document skill with the house sheet framework, and a surfaces: [proposals] line that switched on the Proposals app. It worked. It also had a smell: the one real instance using it had copied all five files byte-for-byte into its own workspace, because that was the only way to get them.

Copies drift. With Vocion 2.117 the five files are gone from both places. They live in two plugins, and the instance says plugins: [proposals].

Data rooms

A room is the collection around one entity — a deal, a project, an engagement: every transcript, thread and shared document filed to it with a weight, every artifact written from it, the rules the agent reads first, the notes it keeps, a dated timeline, the highlights worth keeping for the case study, and the open items a person works from Review. A sales room persists into delivery; the stage moves, the collection stays.

The data-rooms plugin brings:

• the data_room object type and the data-rooms skill — how to file, weight, log a decision, keep status and open items, read a room before writing from it;
• the Room keeper, an operational agent with a weekday mission: file what landed that the collector left as a question, refresh each active room's status and timeline, file highlights, put what only a person can decide on the queue;
• the Data rooms row in the sidebar — a plugin-owned row, present only while the plugin is on — and the after-sync collector, now gated on the plugin: a clear match files with its score (undo on the room), a plausible one asks, a deal reaching Proposal stage opens its own room;
• the data-rooms team, graded on rooms opened and sources filed — two new measure sources over rows Vocion already keeps.

Proposals

A proposal is a document artifact: US-Letter sheets in the house framework, self-contained HTML that prints to the PDF the client reads, and not done until the render-verify receipt reads clean. The engine renders with real Chromium, measures every sheet, audits footers and overflow, counts PDF pages, and can look at the render.

The proposals plugin brings:

• the Proposal Writer — reads the room first, builds with render_document, fixes what the receipt names sheet by sheet, verifies with the look, exports the PDF. It shadows the base pack's brief-only Proposal Writer; a workspace patches either with extends: core;
• the proposal-document skill: framework CSS, component vocabulary, structure and language rules, the verify loop;
• the Proposals surface under GTM, switched on by the plugin's surfaces: [proposals];
• a Monday mission: every Proposal-stage room has a verified current document, or an open item saying exactly what is missing;
• the proposals team, graded on documents rendered and documents that verified clean — a measure over rows: artifacts narrowed by kind, playbook and verified state.

It depends on data-rooms; turning it on turns that on.

What the sample workspace became

# templates/workspaces/client-documents/workspace.yaml
lead: proposal-writer
plugins: [proposals]

Plus brand.yaml and a logo. Everything else composes in from the two plugins, and the E2E that replays the proposal loop against a scripted model runs against exactly that.

The instance that had copied the files deletes them and keeps its one real override — the Proposal Writer patched onto a Sonnet-class model with a bigger output cap and its own prompt — as agents/proposal-writer.yaml with extends: core. Same slug, layered on the plugin's version instead of the base pack's.

Why this shape

The design principles say anything true of one seller is a concretion and never enters core, and that the next kind should cost a descriptor, not a subsystem. A plugin is the rung between: core ships the room noun, the document engine, the tools and the surface registry; the plugin ships the agent, the cadence, the measures and the rules; the workspace ships the brand and its overrides.

A room keeper that runs every weekday and a writer that verifies every Monday are the part that matters. A capability that is on is a capability that is already working, being measured, and learning from what people correct.

Data rooms docs · Proposals docs · Artifacts