The proposals plugin
The client document written from its data room — proposals, scope documents, partnership updates — as print-ready sheets in the house framework that render-verify before a person sees them, are read as the sceptical buyer before the export will print them, and teach the writer a rule from every correction. What it is, who it is for, the line that turns it on, and what has changed since it shipped.
Status: shipped, at version 1.0.0 in vocion-core (packages/core/templates/plugins/proposals/).
Became a plugin on 2026-09-18 (vocion-core#451);
the red team, the twelve-sheet spine and the learning step are A proposal that reads itself as
the buyer (2026-09-19); a proposal budget per
agent is #660 (2026-09-24). Docs:
Proposals.
# workspace.yaml
plugins: [proposals] # loads data-rooms first
What it is
A proposal is a document artifact: US-Letter sheets in the house
framework, self-contained HTML that prints to the PDF the client reads, with the render-verify
verdict and the red-team reading stored on the exact version. The Proposal Writer reads the
data room first; its starred sources are what it writes from, and
anything it cannot trace to the room renders as an amber to be baselined chip — never an
invented number, never quietly dropped. It builds with render_document, fixes what the receipt
names sheet by sheet, verifies with the look, reads the document as the buyer, then exports.
Who it is for
A person who asks for a proposal, a scope document, a statement of work or a partnership update
for a client. A deal that reaches a proposal stage with nothing drafting the document. A document
being rewritten in chat as prose when the client will read it as a PDF. Those are the plugin's
recommend.when lines; it works better with the HubSpot and Drive connectors.
What turning it on adds
- The Proposal Writer agent, which shadows the base pack's brief-only writer.
- The
proposal-documentskill: the framework CSS, the component vocabulary, the twelve-sheet spine, when a sheet earns a visual, the structure and language rules, the verify loop, the red-team rubric. - The framework is injected, not copied.
framework.cssgoes into every document the render path renders, underneath whatever the model wrote, and is re-injected on every edit and verify — so a hand-typed copy can no longer drift from it. The receipt names every class used with no rule anywhere in the document. - The client's logo, fetched for real.
fetch_imagechecks from the bytes that a URL is an image, downscales it, and with aroom_idlands it on the room's brand, so every later document from that room uses the same mark. - Red team before send, enforced by the export.
red_team_documentreads the document as the sceptical operations lead — grounding, promised outcomes, placeholders, the client's words, scope, commercial clarity, register — and returns numbered findings by sheet, graded block, fix and consider.export_document_pdfwill not print a client document with a blocking finding, and runs the read itself if nobody has. - No sheet is a wall of text, checked without a model: the receipt names every sheet carrying none of the framework's component vocabulary, by number and label.
- It learns from every correction. The writer declares the
proposal-feedbacklearning step: a turn in which a person corrected the writer's work on a document has the standing rules in what they said drafted and put through the learning loop — adopted with Undo above the workspace's learning bar, a card below it. A red-team finding that recurs becomes a rule. - The Proposals app under GTM (
nav: {section: GTM}): every room at Proposal stage, its latest document and verify state, open items, and Draft. - A weekly mission — every Proposal-stage room has a verified current document, or an open item
saying what is missing — and the
proposalsteam, graded on documents rendered and documents that verified clean.
What has changed since it shipped
A proposal budget per agent (#660,
2026-09-24). An agent that proposes — cards, asks, page writes — now has a ceiling on open
proposals and on proposals per week (defaults.agentProposals: {openMax, weeklyMax} in
workspace.yaml), so a writer that is wrong about something cannot fill the review queue with it
before a person notices. A default applies when the workspace names none.
Review, rebuilt around the work (The work comes first, 2026-09-19). The screen where a person decides a writer's recommendation now opens with the thing being decided, rendered as the thing it is, and one bar to act on it. A proposal's review is where the writer's rules come from, so this is the plugin's most-used surface after the document itself.
What it measures
Documents rendered. Documents that verified clean. The gap between the two is the number the writer is graded on.
Where it fits
Depends on data rooms: a document is written from a room, and plugins: [proposals] loads
data-rooms first. The wiki holds the house voice the writer reads;
brand.yaml holds the palette and logos it reads with get_brand.
Customise it in the workspace: patch the writer with agents/proposal-writer.yaml + extends: core, replace the framework whole-file at skills/proposal-document/ — the injected CSS is read
through the same override path, so your framework.css ships in the document — and put your
palette, logos and voice in brand.yaml. Every fixture is fictional; Metacto is the seller.