vibeexchange.ai Fund the work that matters

Docs / Build requests & the orchestrator

stable updated 2026-06-06

Build requests & the orchestrator

Once a listing ignites, its repo is the place where work happens. In the current demo/live bridge, a funded listing provisions that repo, seeds the agent config, starts the Replicas/fleet supervisor, opens a PR, and shows build status back in VibeExchange.

The orchestrator is agentFleet, a control plane for running coding agents safely against one feature. GitHub issues are the intended human-facing request surface; the repo remains the durable build record.

The trigger: a vibe:build issue

  1. A sponsor (or the creator) opens an issue on the listing’s repo describing what to build, and labels it vibe:build.
  2. When the webhook/API bridge is configured, VibeExchange projects the issue into a durable request file, .roadmap/requests/<id>.toml, the issue is the human-facing request, the file is the working state.
  3. It runs the listing’s fleet on a feature branch, inside the budget (below).
  4. It opens a PR and links it back to the issue and milestone.
  5. Governed merge enforcement is staged behind the voting bot; the orchestrator opens PRs and does not act as the money authority.

The intended label flow is vibe:build → vibe:building → vibe:in-review → vibe:pr-open, with comments linking the run and PR as the bridge is configured.

The budget: tokens in, spend out

The orchestrator enforces token caps rather than writing dollar spend itself. .roadmap/agents.toml carries the USD cap and a derived token envelope:

[agents]
max_concurrent_agents = 3
max_spend_per_milestone_usd = 600   # our USD authority

[agents.budget]                     # the orchestrator enforces these token caps
max_tokens_per_milestone = 90000000
max_tokens_per_run = 30000000
halt_on_breach = true
halt = false                        # we flip true to stop instantly

When a run finishes, the orchestrator writes a token-only spend report to .treasury/runs/<run-id>.toml. It reports tokens; our treasury service prices them to USD and is the sole writer of the ledger. That clean split keeps the money auditable and the orchestrator provider-portable.

Current bridge

For demos and live bridge testing, the funded listing flow provisions the repo, seeds .roadmap/, .treasury/, .harness/, and .fleet/, starts Replicas/fleet supervision, opens a PR, and exposes status in VibeExchange. A sponsor can request work with vibe:build issues when the webhook/API bridge is configured; otherwise an operator can start the same contract manually against the provisioned repo.

What this means for you

  • Sponsors/creators: open issues to request features once repo/webhook access is configured; approve PRs as the governance path comes online.
  • Everyone: every build is a PR you can read, and every token is reported and priced into the treasury as treasury automation is enabled. Funded ≠ finished, agents build software and outcomes are not guaranteed.

Status

The D1-backed demo/live bridge exists today for funded listings. vibe:build issue projection is the current/intended skeleton when the webhook/API bridge is configured; voting bot enforcement, treasury pricing automation, and branch protection checks may still be staged per listing.