# Workload doors and current limits

Updated: 2026-08-31

VibeCord's intended product has three primary self-service doors over one
project, workload, artifact, proof, payment, and operations spine. The current
source posture lets an external agent bring code or configuration into the
internal dogfood operations path. Public CLI installation, device auth,
autonomous signup, and external-agent self-service are not launched. Where a
lane is admitted, VibeCord is intended to handle supported workload
validation, preview, proof, export, and hosted admission.

The three doors are the shared product direction, but their external-agent and
hosted runtimes must be released and promoted independently.

## Source-only creation contract

The source action grammar includes explicit `project.create` and
`workload.create` requests. Project creation requires its first connected
workload in `metadata.initialWorkload`; a successful receipt returns both the
new `projectId` and `projectWorkloadId`. `workload.create` adds a later
connected row. `initialWorkload.workloadSlug` is deliberately required so an
agent cannot leave the first workload identity to inference. Neither action prompts VibeCord to infer or generate anything.
Their matching server handlers and authenticated action route exist in source,
but deployment, public availability, and release proof remain open.

```sh
vibecord-ops project create --name "Friends Project" \
  --initial-workload-kind luanti_game \
  --initial-workload-slug friends-voxel-world --dry-run --json
vibecord-ops workload create --project-id <project-id> --kind discord_bot \
  --slug friends-bot --dry-run --json
```

## Discord bot

Workload kind: `discord_bot`

- Designated hosted lane with retained runtime proof.
- Current public and paid launch remains unproven.
- Internal CLI dogfood has selected Bot Lab preview and proof evidence.
- A hosted request can still be denied by budget, redacted diagnostics,
  control-plane, capacity, or launch gates.

Use a Discord bot artifact for inspection, staging, preview, proof, export, or
an admitted deploy request. Never place a Discord bot token in the artifact or
agent prompt.

## Minecraft Java

Workload kind: `minecraft_java`

- Generation and ServerPack export are active.
- The paid-hosting feature flag exists, but provider dispatch still requires
  paid-before-spend, capacity, workload proof, and launch admission.
- A successful pack or local server boot does not prove public hosting.

Use an export-ready Paper server pack. The hosted lane is only ready when the
receipt admits the exact workload and retained proof includes real multiplayer,
persistence, billing, isolation, stop, rollback, and provider teardown.

## Luanti custom voxel game

Workload kind: `luanti_game`

- Beta creation, browser preview, local validation, and GamePack export are
  enabled.
- Hosted multiplayer is not admitted in the current source. Any future hosted
  dispatch remains gated by server runtime, paid-before-spend, capacity,
  UDP/provider, sandbox, rollback, support, and launch proof.
- Browser or local GamePack success does not prove a public hosted server.

Use a valid Luanti GamePack. Treat any hosted denial as lane state, not an
instruction to bypass the control plane or call a provider directly.

## Adjacent export lanes

Minecraft Bedrock add-on/server-pack export and Roblox Studio/Open Cloud
publish handoff remain visible adjacent lanes. Do not describe either as one
of the three current hosted workload doors. Roblox hosts its own live runtime.

## Safe no-hosting route

Every workload should retain a useful route that does not buy persistent
customer runtime capacity:

```text
local inspection or validation -> admitted preview or proof -> export/download
```

Free surfaces are preview/export-only or explicitly capped platform-funded
experiments. `A$0` means no new cash or provider action has been authorized. It
does not promise unlimited free preview compute or hosted runtime.

## Required workload scope

Before any workload action, run:

```sh
vibecord-ops workload readiness \
  --project-id <project-id> \
  --workload-id <project-workload-id> \
  --json
```

Spend-bearing or runtime-mutating actions must resolve one concrete
`projectWorkloadId`, or one slug that resolves to exactly one workload row.
Use explicit `--project-slug` or `--workload-slug` flags for slugs; copied UUIDs
go in `--project-id` or `--workload-id` and are never classified heuristically.
Missing, stale, ambiguous, export-only, unavailable, or gated workload scope
must fail closed.

Read [RECEIPTS.md](./RECEIPTS.md) for routing rules and
[PAYMENTS.md](./PAYMENTS.md) for hosted payment boundaries.