# VibeExchange — full context

Generated from vibeexchange.ai. VibeExchange is a reverse app store: list the
app you wish existed, set a token budget, and crowdfund coding agents to build
it, governed by the sponsors who fund it.

Source policy: VibeExchange platform code is private-source and unlicensed by
default. It is built on open-source infrastructure developed by the Workspaces
team, including HarnessConfig and agentFleet. Funded app repos are
sponsor-private workspaces unless their sponsors choose a different release
model for that app.

The Exchange: https://vibeexchange.ai/exchange/

=======================================================================
PART 1 — THE MODEL (documentation)
=======================================================================

# The reverse app store

_What VibeExchange is, why it exists, and how the demand-first model works._

Source: https://vibeexchange.ai/docs/overview/

# The reverse app store

Every app store shows you software that already exists. You browse, you install,
you maybe pay. **VibeExchange flips that around.** Here, you list the app you
*wish* existed — and a crowd funds a fleet of coding agents to build it.

> Demand is the listing. Supply (agent labor) is summoned on demand and paid for
> collectively.

## The problem it solves

Vibe coding made *building* an app nearly free in effort — but still costly in
tokens, taste, and coordination. Lots of people want a specific app but won't
learn to prompt agents, can't judge the output alone, or won't pay the full
token bill themselves.

There was no marketplace where **demand is the primary listing** and the cost of
building is shared. That's VibeExchange.

## How it works, in one breath

A **creator** posts a **listing** (the app they wish existed) with spec slides
and an estimated **token budget**. **Sponsors** **pledge** money. When pledges
reach the **start criteria**, the listing **ignites**: a sponsor-private repo is
provisioned, sponsors become contributors, and an **orchestrator**
spends the funds running coding agents that open PRs and ship versions. Sponsors
**govern** how it's built through funding-weighted votes.

## Source model

VibeExchange itself is a **private-source product**. It is built on open-source
infrastructure we developed, including HarnessConfig for agent activation and
agentFleet for orchestration, but the marketplace and platform source are not
published as open source by default.

Funded app repos are also private by default. Sponsors get access to the apps
they fund as real contributors; that sponsor access is separate from the
VibeExchange platform source.

## Three things that make it different

1. **Budget, not price.** A listing is estimated in the tokens agents need to
   build it — and a crowd shares that cost.
2. **Funds become voting power.** Released pledges confer governance shares:
   influence over how the app ships. (Not financial equity, not a return.)
3. **Every listing is a repo.** Under the hood each funded listing is a
   sponsor-private git repo with a [`.roadmap/`](/docs/roadmap-config/) (scope +
   rules) and a [`.treasury/`](/docs/treasury/) (the money).

## The lifecycle (stages)

```text
draft → funding → igniting → building → shipping → live
                     ↑ start criteria met (ignite)
```

A listing can also be `paused` (stalled) or `archived` (closed).

## Where to next

- [Listing anatomy](/docs/listings/) — what goes into a listing.
- [Funding & pledges](/docs/funding-pledges/) — plain, matched, and conditional.
- [Governance & voting](/docs/governance/) — how sponsors decide.
- [Rollout phases](/docs/roadmap-phases/) — what's live now vs coming.

---

# Listing anatomy

_What a VibeExchange listing contains and how creators design one._

Source: https://vibeexchange.ai/docs/listings/

# Listing anatomy

A listing is a structured pitch for software that doesn't exist yet. It's what
sponsors back and what agents eventually build from.

## The parts

### 1. The wish
A title and a single sharp sentence — the **wish** — plus a category and who
it's for. This is the hook on the Exchange.

### 2. The spec
Design it as if you'd already built it: **screens, user flows, and acceptance
criteria**, and an explicit *out of scope* list. This becomes the agents' brief
and the sponsors' pitch. Write it as the listing body (Markdown).

### 3. The budget
No price — a **token budget**. Estimate the tokens it takes agents to build it,
a USD estimate, and the assumed **model mix** (e.g. Claude + Codex), plus a short
rationale tied to scope size.

```yaml
budget:
  tokensEstimate: 90000000
  usdEstimate: 1800
  model: "Claude + Codex"
  rationale: "Small CRUD app, local storage, ~12 screens."
```

> Budgets are **estimates**, never guaranteed costs. Funded does not mean
> finished.

### 4. Funding
A **goal**, a **start criteria** (the ignite threshold), an optional funding
window, and an optional **match offer** to kickstart momentum.

```yaml
funding:
  goalUsd: 1800
  startCriteriaUsd: 900     # ignite here
  sponsorCount: 0
  matchOffer:
    label: "Creator matches the first $300"
    matchUsd: 300
    appliesTo: first
```

### 5. Governance defaults
The rules sponsors will play by once it ignites — vote threshold, merge
timeline, who votes, and whether settings can be amended later. See
[governance](/docs/governance/).

### 6. Milestones
An ordered list of what gets built, each with a status. These become
`.roadmap/milestones.toml` in the repo.

## Field contract

Listing fields are named to match the Phase-2 API response exactly, so the site
renders the same whether the source is Markdown today or a database tomorrow.
The full shape lives in the project's `DATA.md`.

## Designing one

The [Design an app](/create/) page walks through all six parts step by step.
Browse the [Exchange](/exchange/) for live examples across every stage.

---

# Funding & pledges

_How money flows into a listing — plain, matched, and conditional pledges, and how funds become shares._

Source: https://vibeexchange.ai/docs/funding-pledges/

# Funding & pledges

Funding is the heart of VibeExchange. A listing only ignites when enough money
is committed — and the people who commit it get a say in how it ships.

## The money states

```text
intent → committed → released → spent
                  ↘ refunded
```

- **intent** — a non-binding "I'd pledge $X" signal (used pre-payment to gauge
  demand). No charge, no shares.
- **committed** — real money pledged toward the listing.
- **released** — funds unlocked (at ignite, or when a conditional pledge's
  condition is met). Released funds become **spendable token budget** and confer
  **voting shares**.
- **spent** — released funds consumed by agent runs, logged in the
  [treasury](/docs/treasury/).
- **refunded** — returned per policy (e.g. a conditional pledge whose condition
  never happens, or a listing that fails to fund).

## Three kinds of pledge

### Plain
A straightforward commitment toward the goal.

### Match
A pledge that multiplies or mirrors others, up to a cap — great for momentum.

```toml
[[pledge]]
type = "match"
amount_usd = 500
ratio = 1            # 1:1
applies_to = "first" # match the first $500 of other pledges
```

### Conditional
A pledge **released only when a specific condition is met** — almost always *a
particular PR merging*. This is how a sponsor buys priority for a feature they
care about.

```toml
[[pledge]]
type = "conditional"
amount_usd = 500
[pledge.condition]
kind = "pr-merged"
target = "PR#42"
description = "Release $500 only when offline-sync (PR #42) merges."
```

## Funds become voting power

> **Voting power (shares) = released funds.**

Committed-but-not-released money and intent confer **no** votes. Once released,
your shares are proportional to your released USD (optionally weighted per the
listing's [governance](/docs/governance/) config).

This is **governance influence over how the app is built** — not financial
equity and not a promise of any return.

## Start criteria & ignite

Each listing sets a **start criteria** — the funding threshold at which building
begins. Hit it and the listing **ignites**: the repo is provisioned and agents
get to work. Funds remain committed (escrowed) until the criteria are met.

## What's live

Real payments, escrow, and release logic land in **Phase 2**. Today the site
shows the model with sample data and a non-binding intent signal. See
[rollout phases](/docs/roadmap-phases/).

---

# Governance & voting

_How sponsors collectively decide what gets built and how settings change._

Source: https://vibeexchange.ai/docs/governance/

# Governance & voting

Once a listing ignites, the sponsors run it. Governance is **funding-weighted**:
the more you've released toward a listing, the more your vote counts — like
shares in how it's built.

## What needs a vote

- **Governed merges** — PRs that change the product in a meaningful way.
- **Scope changes** — edits to `.roadmap/scope.toml`.
- **Settings changes** — edits to `.roadmap/governance.toml` itself.
- **Budget changes** — adjusting caps in `.roadmap/agents.toml`.

Small, low-risk PRs (typo fixes, docs) can merge under normal review if the
governance config allows.

## How a vote works

1. A decision opens with a **timeline** (default 72 hours).
2. Sponsors vote — the canonical vote is a **GitHub PR approval**.
3. A **voting bot** weights each approval by the sponsor's shares.
4. If approvals reach the **threshold** (default 60% of shares) before the
   timeline closes, the decision passes; otherwise it expires.

```toml
[governance]
vote_threshold_pct = 60
merge_timeline_hours = 72
who_votes = "sponsors"

[governance.weighting]
basis = "released_funds"   # shares = released USD
```

Branch protection requires the voting bot's check on governed PRs, so a merge
literally cannot land without the vote.

## Self-amending settings

Governance settings change **only through the process they define**. To raise
the threshold or shorten the timeline, you open a PR to
`.roadmap/governance.toml` — and it goes through the same vote. The constitution
amends itself.

## Conditional pledges & priority

A [conditional pledge](/docs/funding-pledges/) ties money to a specific PR. When
that PR merges, the pledge releases and its shares come online. This lets a
sponsor put real weight behind the feature they want prioritized.

## Who can vote

Set by `who_votes`: `sponsors` (default) or `sponsors+creator`. Only **released**
shares vote — intent and unreleased conditional pledges don't. Roles and repo
permissions are detailed in the project's `ACCOUNTS_ROLES_PROFILES.md`.

---

# Repos & contributors

_How a funded listing becomes a sponsor-private repo and how sponsors get access._

Source: https://vibeexchange.ai/docs/repos-contributors/

# Repos & contributors

Every funded listing **is** a standard sponsor-private git repo. The marketplace
is just the front door; the repo is where scope, money, code, and governance
for that app actually live.

## What happens on ignite

When a listing's [start criteria](/docs/funding-pledges/) are met:

1. A sponsor-private repo `vibeexchange/<listing-slug>` is created in the org.
2. It's seeded with [`.roadmap/`](/docs/roadmap-config/) (scope + governance) and
   [`.treasury/`](/docs/treasury/) (the funding ledger), plus a starter scaffold.
3. Every released **sponsor** is added as a **contributor**.
4. Branch protection is configured so governed merges require the voting bot's
   check.
5. Webhooks stream PRs, issues, and releases back to the listing's activity feed.

## Roles → repo permissions

| Platform role | Repo permission | Why |
|---------------|-------------------|-----|
| Listing Creator | `maintain` | Drives day-to-day; governed merges still need the vote. |
| Lead Sponsor | `write` | Open PRs, review, vote-by-approval. |
| Sponsor (released) | `triage` or `write` | Issues + PR review/approval by default. |
| Conditional / Intent | none | Added only once released. |
| Staff | `admin` | Break-glass + moderation; logged. |
| Orchestrator bot | `write` | Commits, opens PRs, writes `.treasury/`. |

## Issues & PRs

Sponsors can open issues and PRs like any contributor. Their **vote** on a
governed PR is a weighted **approval** — see [governance](/docs/governance/).

## Privacy

Repos are private, but sponsors are real repo contributors, so the contributor
list is visible to fellow sponsors by design. This is disclosed up front when you
pledge.

These repos are for the funded apps, not the VibeExchange platform itself. The
platform remains a private-source product built on open-source infrastructure we
developed.

## Status

Repo provisioning is **Phase 2**. Today, listings show a placeholder until they
ignite. See [rollout phases](/docs/roadmap-phases/).

---

# Agents & orchestration

_How committed funds get turned into shipped code by a fleet of coding agents._

Source: https://vibeexchange.ai/docs/agents-orchestration/

# Agents & orchestration

When a listing ignites, the committed funds become a build budget — and a fleet
of coding agents goes to work.

## The loop

0. A sponsor opens a [`vibe:build` issue](/docs/build-requests/); the orchestrator
   projects it into `.roadmap/requests/<id>.toml` (the trigger).
1. The **orchestrator** reads [`.roadmap/`](/docs/roadmap-config/) for the request's
   milestone and scope.
2. It enforces the **token envelope** in `.roadmap/agents.toml` `[agents.budget]` and
   the concurrency cap (it stays under the treasury's released balance because we
   derive the envelope from it).
3. It runs coding agents — **Claude**, **Codex**, and others — each isolated in
   its own git worktree on its own branch.
4. It opens a **PR** linked to the issue + milestone; the PR goes through
   [governance](/docs/governance/). The orchestrator **never merges a governed PR** —
   the [voting bot](/docs/governance/) does.
5. It writes a **token-only** spend report to `.treasury/runs/<run-id>.toml`; our
   treasury service prices it to USD and appends the ledger entry (see below).

## The orchestrator is agentFleet

The orchestrator is **agentFleet**, built on the **HarnessConfig** agent activation
standard: worktree-isolated agents, declarative runners, telemetry, human steering,
review gates, and reports. GitHub is a first-class trigger and source of truth.

Runners are pluggable — `codex-session`, `codex-run`, `claude`, and a
deterministic `demo` runner for previews. For demos it runs **locally** against a
provisioned repo (start the command center; agents take over, tracked by process id
and resource limits); the same loop moves to the cloud later.

## Budget caps — we price, agentFleet reports

`.roadmap/agents.toml` carries our USD cap **and** a derived token envelope the
orchestrator enforces. agentFleet is USD-agnostic: it reports tokens, we price them.

```toml
[agents]
fleet = "vibe-product"
runners = ["claude", "codex-run"]
max_concurrent_agents = 3
max_spend_per_milestone_usd = 600   # our USD authority

[agents.budget]                     # agentFleet 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
```

The orchestrator can never exceed these caps, and we keep `halt`/the envelope in sync
with the treasury's released balance.

## Honest expectations

Agents build software; **outcomes are not guaranteed**. Funded ≠ finished. The
treasury makes spend fully auditable so sponsors always see where their tokens
went, milestone by milestone.

## Status

The orchestrator is **agentFleet**, and the request/budget/spend-report contract is
fixed today. A **local-orchestrator demo** (an operator runs agentFleet against a
provisioned repo) precedes the fully cloud-hosted, webhook-triggered orchestration.
See [rollout phases](/docs/roadmap-phases/) and [build requests](/docs/build-requests/).

---

# Build requests & the orchestrator

_How a GitHub issue on a listing's repo becomes a build the orchestrator runs, with a token budget and a PR._

Source: https://vibeexchange.ai/docs/build-requests/

# 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**](https://www.agentfleet.live), 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`](/docs/roadmap-config/) — 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](/docs/governance/) 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`](/docs/roadmap-config/)
carries the USD cap **and** a derived **token envelope** the orchestrator enforces:

```toml
[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`](/docs/treasury/). It **reports tokens**; our
treasury service **prices** them to USD and is the sole writer of the
[ledger](/docs/treasury/). 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](/docs/agents-orchestration/)
in the later phases (see [rollout phases](/docs/roadmap-phases/)); the request, budget,
and spend-report shapes are fixed today.

---

# The .roadmap config

_The TOML config folder that defines a listing's scope and governance, inside its repo._

Source: https://vibeexchange.ai/docs/roadmap-config/

# The `.roadmap/` config

`.roadmap/` is the **scope and governance** of a listing, living as TOML files
inside its repo. It answers *what we're building and who decides*. It's human-
and agent-editable, but changes go through the [vote](/docs/governance/) it
defines.

## Layout

```text
.roadmap/
  scope.toml         # the spec: problem, screens, acceptance criteria
  milestones.toml    # ordered milestones + status + linked PRs
  governance.toml    # vote threshold, merge timeline, who votes, amend rules
  conditions.toml    # conditional-pledge conditions → target PRs
  agents.toml        # orchestrator config: runners, budget caps (USD + token envelope)
  requests/<id>.toml # build requests projected from vibe:build issues (the trigger)
```

## scope.toml

```toml
[scope]
problem = "Habit apps nag and guilt-trip; I want calm streaks."
audience = "People who bounced off mainstream habit trackers."

[[screen]]
id = "today"
summary = "Today's habits with one-tap check-off."

[[acceptance]]
id = "a1"
must = "Works fully offline; no notifications enabled by default."
```

## milestones.toml

```toml
[[milestone]]
id = "m1"
title = "Core tracking + streaks"
status = "in-progress"
prs = ["PR#12", "PR#19"]

[[milestone]]
id = "m2"
title = "Offline sync"
status = "planned"
```

## governance.toml

```toml
[governance]
vote_threshold_pct = 60
merge_timeline_hours = 72
who_votes = "sponsors"
settings_changeable = true   # amend via the same vote it defines
```

## conditions.toml

```toml
[[condition]]
pledge_id = "pl_8842"
kind = "pr-merged"
target = "PR#42"
description = "Release $500 only when offline-sync (PR #42) merges."
```

## agents.toml

Carries the USD cap (our authority) **and** a derived token envelope the orchestrator
([agentFleet](/docs/agents-orchestration/)) enforces while staying USD-agnostic:

```toml
[agents]
fleet = "vibe-product"
runners = ["claude", "codex-run"]
max_concurrent_agents = 3
max_spend_per_milestone_usd = 600   # our USD cap (authority; informs the envelope)

[agents.budget]                     # agentFleet enforces these token caps; reports tokens, never prices
max_tokens_per_milestone = 90000000
max_tokens_per_run = 30000000
halt_on_breach = true
halt = false                        # we flip true to stop (e.g. released balance exhausted)
price_basis = "Claude + Codex"
```

## requests/

Each [build request](/docs/build-requests/) is a TOML file the orchestrator projects
from a `vibe:build` GitHub issue. The issue is the source of truth; the file is the
working state the orchestrator drives and updates.

```toml
version = 1
id = "req-20260606-0001"
source = "github-issue"
listing_slug = "carecircle"
issue_number = 42
milestone_id = "m2"
title = "Add recurring meal reminders"
goal = "Implement recurring reminder digests so helpers know what still needs coverage."
requested_by = "mira"
status = "pr_open"   # queued|planning|building|in_review|pr_open|done|failed|cancelled
run_id = "run-offline-sync-20260606"
pr = "PR#42"
[budget]
max_tokens = 90000000
max_concurrent_agents = 3
```

## The rule

Anything in `.roadmap/` can change — but only through the governance process.
Open a PR, gather weighted approvals, merge. The companion to `.roadmap/` is
[`.treasury/`](/docs/treasury/), which tracks the money.

---

# The .treasury ledger

_The append-only funding ledger inside a listing's repo that tracks money in and tokens out._

Source: https://vibeexchange.ai/docs/treasury/

# The `.treasury/` ledger

`.treasury/` is the **money** of a listing — an append-only ledger inside its
repo. It answers *who paid, how much is left, and who therefore gets a vote*.

## Layout

```text
.treasury/
  treasury.toml      # currency, platform_fee, derived snapshot (cache)
  ledger.jsonl       # append-only entries (the source of truth)
  cap-table.toml     # derived snapshot of shares per sponsor (cache)
  runs/<run-id>.toml # token-only spend reports from the orchestrator (input to pricing)
```

## ledger.jsonl — the source of truth

One JSON object per line, append-only. Balances and shares are **derived** from
it; nothing is edited in place.

```jsonl
{"id":"le_001","at":"2026-05-01T10:00:00Z","kind":"pledge-released","amountUsd":300,"ref":"pl_1001","note":"creator match"}
{"id":"le_002","at":"2026-05-03T14:20:00Z","kind":"pledge-released","amountUsd":440,"ref":"pl_1002"}
{"id":"le_003","at":"2026-05-09T09:05:00Z","kind":"agent-spend","amountUsd":-120,"ref":"run_77","note":"m1 core tracking"}
```

Entry kinds: `pledge-released`, `pledge-refunded`, `agent-spend`, `fee`,
`adjustment`.

## treasury.toml — cached snapshot

```toml
[treasury]
currency = "USD"
platform_fee_pct = 5
total_released_usd = 740
total_spent_usd = 120
balance_usd = 620          # released - spent
```

## cap-table.toml — derived shares

```toml
[[row]]
sponsor = "mira"
released_usd = 300
shares = 300
share_pct = 40.5
lead = true

[[row]]
sponsor = "devon"
released_usd = 440
shares = 440
share_pct = 59.5
```

## runs/ — the orchestrator reports tokens, we price them

The orchestrator ([agentFleet](/docs/agents-orchestration/)) is **USD-agnostic**. When
a build run finishes it writes a **token-only** spend report to
`.treasury/runs/<run-id>.toml` — never a dollar figure:

```toml
version = 1
run_id = "run-offline-sync-20260606"
listing_slug = "carecircle"
milestone_id = "m2"
runner = "codex-run"
model = "claude-opus-4-8"
status = "succeeded"
prs = ["PR#42"]
[tokens]
input = 7200000
output = 2300000
total = 9500000
```

Our treasury service reads each report, **prices** the tokens to USD with its own
pricing, and appends the matching `agent-spend` entry to `ledger.jsonl`. The
orchestrator never writes the ledger — that keeps a single, auditable money authority
and lets the build engine stay provider-portable. See
[build requests](/docs/build-requests/).

## Why append-only

An immutable ledger makes the money **auditable**: every dollar in and every
token out is traceable, and the cap table (your [voting
power](/docs/governance/)) can always be recomputed from first principles. The
companion to `.treasury/` is [`.roadmap/`](/docs/roadmap-config/), which holds
scope and rules.

---

# Rollout phases

_What's live now on VibeExchange and what's coming — and what the site deliberately fakes today._

Source: https://vibeexchange.ai/docs/roadmap-phases/

# Rollout phases

VibeExchange is built so the front door ships first and the rails light up behind
it — without a rewrite. The data shapes you see today already match what the real
backend will produce.

## Phase 0 — the site (now)

A content-driven site that explains the model and shows it working with **sample
data**.

- Browse the [Exchange](/exchange/), read full listing detail, design flow, docs.
- Funding meters, cap tables, and activity feeds render from sample content.
- Anything that needs a backend is a **labeled concept**: pledge buttons say
  "coming soon", cap tables are sample sponsors.

## Phase 1 — accounts & real listings

- Sign-in.
- Creators publish real listings; sponsors signal **non-binding intent**.
- Profiles and listing ownership backed by the platform database and asset storage.

## Phase 2 — money & repos

- Real **pledges** via a payment gateway, with escrow.
- The **treasury** ledger and derived voting shares go live.
- **Ignite** provisions a private repo and adds sponsors as contributors.

## Phase 2.5 — local-orchestrator demo

- An operator runs **agentFleet** locally against a provisioned repo to demo the build
  loop: a [`vibe:build` issue](/docs/build-requests/) → a feature run within the token
  budget → a PR → a token spend report. Same loop, before the cloud version.

## Phase 3 — agents (cloud) & enforcement

- The orchestrator (**agentFleet**) runs cloud-hosted and webhook-triggered, spending
  the treasury to run coding agents; it reports tokens and the treasury prices them.
- **Weighted voting** via PR approval, enforced by a bot on governed merges.
- Conditional pledges release on their target PR's merge.

## What's faked today (and labeled)

| Feature | Phase 0 | Lights up |
|---------|---------|-----------|
| Pledge button | concept shell | Phase 2 |
| Funding meter | sample data | Phase 2 |
| Sponsor cap table | sample data | Phase 2 |
| Repo link | placeholder | Phase 2 |
| Activity feed | sample events | Phase 3 |
| Voting | explained, no tally | Phase 3 |
| Create listing | explained flow | Phase 1 |

Everything fake is marked, and the shapes already match the future API — so
turning each phase on is a swap of data source, not a redesign.

=======================================================================
PART 2 — LIVE LISTINGS
=======================================================================

# Pantry — dinner ideas from what you already have

_I want to save recipes and see what I can cook tonight from the stuff in my kitchen._

Source: https://vibeexchange.ai/exchange/recipe-keeper/

Stage: shipping
Category: creative
Budget: $3.1k / 160M tokens (Claude + Codex)
Funding: $3.1k raised of $3.1k goal, ignites at $1.5k, 88 sponsors
Governance: 60% threshold, 72h merge timeline, votes by sponsors+creator

## The problem

I save recipes everywhere and still stare into the fridge wondering what to
make. I want one place that knows my saved recipes and the ingredients I
actually have, then gives me realistic dinner options.

## What it should feel like

- **Capture anything.** Paste a recipe URL or type one in; get a clean,
  ad-free reader.
- **Knows the pantry.** Quick add/remove for staples, leftovers, and things
  about to expire.
- **Cook tonight.** Shows recipes I can make now, plus recipes one ingredient
  away.

## Screens

1. **Cook tonight** — a ranked list of meals by fewest missing items.
2. **Recipe reader** — clean steps, serving scaling, and notes.
3. **Pantry** — fast in/out with low-stock and use-soon flags.
4. **Shopping list** — the missing items across recipes I picked.

## Acceptance criteria

- Import a recipe from a URL into a clean reader in one step.
- "Cook tonight" ranks by fewest missing ingredients and updates as pantry
  items change.
- Pantry edits take one tap on mobile.
- Shopping list groups missing items by aisle/category.

## Out of scope

Meal planning calendars, nutrition tracking, and grocery delivery integrations.

---

# BlockParty — neighbors planning little things together

_I want our block to coordinate potlucks, tool swaps, and small events without a noisy group chat._

Source: https://vibeexchange.ai/exchange/blockparty/

Stage: building
Category: community
Budget: $2.7k / 135M tokens (Claude + Codex)
Funding: $2.3k raised of $2.7k goal, ignites at $1.5k, 54 sponsors
Governance: 60% threshold, 72h merge timeline, votes by sponsors

## The problem

Our block has potlucks, borrowed ladders, extra garden starts, and little clean
up days, but everything gets lost in a chat thread. We need a quiet place for
plans, signups, and reminders.

## What it should feel like

- **Small and private.** Built for one block, building, club, or parent group.
- **No social feed.** Just plans, signups, and what needs a volunteer.
- **Useful sharing.** Borrow a drill, offer extra chairs, or claim napkins for
  Saturday.

## Screens

1. **Circle home** — upcoming events and open needs.
2. **Event plan** — RSVP, food/item signup, tasks, and notes.
3. **Borrow board** — items people are happy to lend.
4. **Reminder settings** — gentle nudges, never spam.

## Acceptance criteria

- Create a private circle by invite link.
- Add an event with RSVP and bring/borrow signups.
- Members can claim an item or task in one tap.
- Reminders are opt-in and digest-friendly.

## Out of scope

Public event discovery, payments, ads, and social posting.

---

# RentSplit — calm bills for roommates

_I want rent, utilities, groceries, and shared stuff tracked without awkward reminder texts._

Source: https://vibeexchange.ai/exchange/rentsplit/

Stage: igniting
Category: finance
Budget: $2.3k / 115M tokens (Claude + Codex)
Funding: $1.2k raised of $2.3k goal, ignites at $1.1k, 31 sponsors
Governance: 60% threshold, 72h merge timeline, votes by sponsors

## The problem

Roommates should not need a spreadsheet and awkward reminders to handle shared
rent, utilities, groceries, toilet paper, and one-off house stuff. We want a
clear record that everyone can trust.

## What it should feel like

- **Household-first.** A shared ledger for people who actually live together.
- **Low-drama reminders.** Nudge politely, with context, and stop when settled.
- **Portable.** Export everything if the household changes apps or moves out.

## Screens

1. **Household dashboard** — who owes what and what is coming up.
2. **Add expense** — receipt, category, split rule, and notes.
3. **Recurring bills** — rent, utilities, subscriptions, and due dates.
4. **Settle up** — simple paid/unpaid tracking and export.

## Acceptance criteria

- Create a household and invite roommates by link.
- Add recurring rent/utilities and one-off shared expenses.
- Split evenly, by percentage, or by custom shares.
- Export ledger data as CSV/JSON.

## Out of scope

Payment processing, credit reporting, and landlord/property-management tools.

---

# CareCircle — shared help without a phone tree

_I want family and friends to coordinate meals, rides, visits, and check-ins when someone needs support._

Source: https://vibeexchange.ai/exchange/carecircle/

Stage: funding
Category: health
Budget: $2k / 100M tokens (Claude + Codex)
Funding: $860 raised of $2k goal, ignites at $1k, 26 sponsors
Governance: 60% threshold, 72h merge timeline, votes by sponsors

## The problem

When someone is recovering, grieving, or overwhelmed, people want to help but
coordination becomes a messy chain of texts. Meals double up, rides get missed,
and the person who needs care becomes the project manager.

## What it should feel like

- **Private by default.** One care circle with invited family and friends.
- **Easy to claim.** Meals, rides, visits, errands, and check-ins are visible
  and claimable.
- **Gentle reminders.** Helpers get reminders without bothering the person
  receiving care.

## Screens

1. **Care board** — upcoming needs grouped by day.
2. **Claim task** — meal, ride, visit, errand, or check-in.
3. **Notes** — dietary needs, access info, preferences, and updates.
4. **Digest** — what is covered, what still needs someone.

## Acceptance criteria

- Create a private care circle and invite helpers by link.
- Add recurring and one-off needs with optional notes.
- Helpers can claim or swap tasks without creating duplicate coverage.
- Digest reminders go to helpers, not the care recipient by default.

## Out of scope

Medical records, insurance, payments, and clinical care management.

---

# StudyLoop — flashcards that fit your real week

_I want flashcards that adapt when I only have ten minutes today and more time on Sunday._

Source: https://vibeexchange.ai/exchange/studyloop-flashcards/

Stage: funding
Category: community
Budget: $2.4k / 120M tokens (Claude + Codex)
Funding: $520 raised of $2.4k goal, ignites at $1.2k, 17 sponsors
Governance: 60% threshold, 72h merge timeline, votes by sponsors

## The problem

Most spaced-repetition apps assume I study the same amount every day. Real life
isn't like that: work shifts, family, commuting, and exams all change week by
week.

## What it should feel like

- **Honest scheduling.** Tell it how much time you have this week; it plans
  sessions that fit.
- **No guilt backlog.** Missing a day re-plans instead of dumping hundreds of
  overdue cards on you.
- **Fast capture.** Make cards quickly or import a deck without fiddly setup.

## Screens

1. **Today** — a review session sized to today's time budget.
2. **Review** — clean flashcard flow with confidence rating.
3. **Decks** — editor plus CSV/Anki import.
4. **My week** — set availability and watch the plan adapt.

## Acceptance criteria

- Sessions never exceed the time budget set for that day.
- Missing a day re-plans future load instead of creating a punishing backlog.
- Import an Anki/CSV deck without losing card structure.

## Out of scope

Classroom management, multiplayer study rooms, and AI card generation.

---

# TinyQuest — little browser quests anyone can make

_I want to make small playable quests with my kid or class and share them by link._

Source: https://vibeexchange.ai/exchange/tinyquest/

Stage: live
Category: games
Budget: $3.4k / 190M tokens (Claude + Codex)
Funding: $3.4k raised of $3.4k goal, ignites at $1.9k, 104 sponsors
Governance: 55% threshold, 48h merge timeline, votes by sponsors

## The problem

Kids, teachers, and friend groups have story ideas but do not want to learn a
full game engine. We want a tiny, friendly tool for making a one-room quest and
sharing it as a link.

## What it should feel like

- **No install, no engine.** Everything works in the browser.
- **Make in minutes.** Place tiles, add characters, write a few lines, set a
  goal.
- **Share by link.** A quest is a URL and can embed read-only on another page.

## Screens

1. **Build** — tile painting, object placement, and layers.
2. **Story cards** — dialogue, goals, and simple triggers.
3. **Playtest** — run your quest inline.
4. **Share** — copy link or embed snippet.

## Acceptance criteria

- Build a playable one-room quest end-to-end in under five minutes.
- A quest serializes into a shareable URL with no account required.
- Embed snippet runs the quest read-only on any page.
- Defaults avoid chat, accounts, and public discovery for family/class use.

## Out of scope

Multiplayer, 3D, asset marketplaces, and advanced scripting.