Voter — a WithVibe plugin

Turn any WithVibe env into a team-voted workspace. When this plugin is enabled, the AI doesn't apply a prompt straight away — it opens a proposal the team votes on, and only an approved proposal gets built. Enable it on any env and that env becomes a vote-gated sandbox.

You (in chat):  "add a dark-mode toggle"
        │
        ▼
   voter_propose_change ──────►  Proposal #7 opens (10-min vote)
        │                           👍 👎  team votes in the panel
   voter_await_decision  ◄───────  APPROVED ✅  /  REJECTED ✗
        │
        ▼  (only if approved)
   agent makes the change  ──►  voter_record_change  ──►  shows up in History

It's content-agnostic — it knows nothing about what the env contains. Whatever the env is (an app, a doc, a 3D scene, a config), enabling Voter makes every change go through the team first. Multiple envs = multiple independent boards.

How the gate works (and why it's just a plugin)

WithVibe auto-injects an enabled plugin's MCP tools into the agent's turn. Voter uses that to gate prompts without any change to WithVibe core:

1. voter_propose_change(prompt) — opens a proposal and tells the agent to not touch anything yet.

2. voter_await_decision(proposal_id) — long-polls the vote. The platform's MCP bridge caps a single tool call at 60s, so this returns after ~45s with STILL_VOTING and the agent simply calls it again until it's terminal.

3. On APPROVED, the agent makes the change and calls voter_record_change. On REJECTED / EXPIRED it makes no change.

Meanwhile every teammate votes in the plugin's own UI panel — independent of the agent. The gate is agent-cooperative (enforced via tool instructions), which is the right trade-off for a friendly workflow; hardening it to be unbypassable is a later option that would need a small core hook.

Related MCP server: jt-mcp-server

MCP tools

State

Four tables in the plugin's isolated Postgres schema (shared-postgres storage): settings (vote window + thresholds), proposal, vote, feed_event.

Resolution rule: a proposal passes when approvals reach the threshold, fails when rejections reach the threshold, and at the deadline the majority wins (ties expire). Defaults: 600s window, 1 approval / 1 rejection — tune them in the panel.

Architecture

manifest.yaml ──► WithVibe spawns one container per env (scope: env)
       │
   server.js (express)
   ├── /health      platform health probe
   ├── /mcp         agent's MCP endpoint            ─► mcp.js  (the gate)
   ├── /ui          htmx voting panel               ─► ui.js
   └── /ui/version  cheap freshness check (live updates)
                │
              db.js (pg) ─► shared-postgres, per-env schema

Build

docker build -t local/voter:0.1 .

For the marketplace this is published multi-arch as ghcr.io/withvibe/voter:<version>.

Install in WithVibe

1. Workspace admin → Plugins → Install plugin (or Marketplace once listed).

2. Paste manifest.yaml (or 1-click install from the catalog).

3. Open any env → enable Voter → that env is now a vote-gated workspace.

Local development

docker build -t local/voter:0.1 .
docker run --rm -p 8080:8080 \
  -e DATABASE_URL="postgres://user:pass@host.docker.internal:5432/withvibe_plugins" \
  -e PGSCHEMA="voter_dev" \
  local/voter:0.1
# open http://localhost:8080/ui  — two browsers = two voters

Repository layout

manifest.yaml   WithVibe plugin manifest (install input)
Dockerfile      runtime image
package.json    deps (express, pg, @modelcontextprotocol/sdk, zod)
server.js       express entry — HTTP + MCP routes + vote handling
db.js           pg pool, schema, proposal/vote/resolution helpers
mcp.js          the gate: propose / await / record MCP tools
ui.js           htmx voting panel + dark theme

License

Apache License 2.0. See NOTICE for attribution.