vibeexchange.ai Community Apps Treasury

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. You don’t need to prompt agents or run anything — you just open a GitHub issue, and the orchestrator takes over.

The orchestrator is agentFleet, a control plane for running coding agents safely against one feature. GitHub is a first-class trigger and source of truth: the issue you open is the request, the repo is the truth, and the orchestrator watches it.

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. The orchestrator projects the issue into a durable request file, .roadmap/requests/<id>.toml — the issue is the human-facing source of truth, 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. The voting bot merges the PR when sponsors approve — the orchestrator never merges a governed PR itself.

The issue’s labels track the run: vibe:build → vibe:building → vibe:in-review → vibe:pr-open, with a comment linking the run and PR.

The budget: tokens in, spend out

The orchestrator can never overspend. .roadmap/agents.toml carries the USD cap and a derived token envelope the orchestrator enforces:

[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.

Runs locally now, in the cloud later

For demos, an operator runs the orchestrator locally against a provisioned listing repo — start the command center, and the agents take over, tracked by process id and resource limits. The same loop moves to the cloud (webhook-triggered, remote runners) without changing the contract.

What this means for you

  • Sponsors/creators: open issues to request features; approve PRs to vote.
  • Everyone: every build is a PR you can read, and every token is reported and priced into the treasury, milestone by milestone. Funded ≠ finished — agents build software and outcomes are not guaranteed.

Status

GitHub-triggered orchestration lands with agents & orchestration in the later phases (see rollout phases); the request, budget, and spend-report shapes are fixed today.