Configuration & settings

Your project’s settings are a screen. vibe ui opens the dashboard on 127.0.0.1:4317, and More > Config lists every setting Vibestrate has, grouped, each one editable where it sits.

Three surfaces read the same file, and only one of them writes:

Behind that screen is one committed folder at your project root. vibe init writes all of it except flows/, which appears the first time you write or install a flow:

.vibestrate/
  project.yml      providers, profiles, crews, flows, policies, validation commands
  rules.md         guidance loaded into every turn
  roles/           one file per worker's instructions
  skills/          house rules any role can read
  policies/        deterministic rules
  runs/            per-run artifacts, state and metrics
  flows/           your own and installed flows, once you have any

It is plain YAML inside your repo.

The header names the file being edited and counts what is in it. Below it, two columns of groups: Project, Git, Workflow, Execution, Budget, Supervised runs, Resilience, Session, Validation commands, Permissions, Safety policies, Posture, Scheduler, Editor, Commits and Merge. A group is a key’s own top-level namespace, so supervisorControl has one too, under its raw dotted name rather than a friendly label. Everything with no dot in its name - providers, profiles, crews, personas, defaultCrew, defaultFlow, defaultPersona, flowSizing, adaptiveSpecUp and the rest - lands in General.

Each row carries the dotted key, the description the schema itself supplies, and a control picked from the field’s type: a switch for a boolean, a dropdown for a fixed set of values, a text box that commits on blur or Enter, a JSON box for an array or object. A saved tick confirms the write, and a rejected value rolls back and shows the schema’s own message. What reaches the schema is not quite the characters you typed: true and false arrive as booleans, a numeric string as a number, null as an empty string, and text opening with [, { or " is parsed as JSON. That reading happens first and validation still decides; a value that fails it is not bent into one that passes.

Two kinds of row do not edit in place:

• Records - providers, profiles, crews, personas, permissions.profiles, commands.validationProfiles and scheduler.sourceQuotas. Id-keyed maps with no single value to set, so the row shows a read-only summary. Five of the seven carry a button through to the screen that owns them - Open Providers, Open Profiles, Open Crew, Open Supervisors and Open Settings. commands.validationProfiles and scheduler.sourceQuotas do not: the first is only renameable from the Settings maintenance panel and the second has no editor anywhere, so a button would promise a screen that cannot help.
• Shell commands - commands.validate, editor.command, editor.args. A later run spawns whatever these point at, so the server never accepts a shell command string over HTTP. The row stays read-only and names the vibe config set that writes it.

vibe shell carries a Config page too, opened from the : palette as Go to Config rather than a number key. It renders the grouped, readable projection vibe config view prints, section by section, with arrow keys or j/k to move. It reads rather than edits.

The CLI is the automation path: a setup script, a CI job, or the moment you already know the key you want.

vibe config view          # grouped, readable
vibe config view --json   # the same, as JSON
vibe config show          # raw project.yml
vibe config keys          # every settable key
vibe config validate      # check the schema

vibe config get commands.validate
vibe config set workflow.requireHumanMerge true

Arrays and objects go in as JSON, so the validation commands look like vibe config set commands.validate '["pnpm test"]'.

The three shell-command keys above are read-only in the browser on purpose. Two others are out of its reach for less deliberate reasons: scheduler.sourceQuotas has no editor anywhere in the dashboard, and commands.validationProfiles offers a rename control and nothing else. For those, vibe config set is the path.

The file is split into top-level sections. The Config page groups them for you; this is which concept explains each one.

project, methodologyRoles, budget, resilience, session, scheduler, editor and commits have no concept page. They are described field by field, from the source, in the project.yml reference.

The rest of .vibestrate/ holds files you edit directly: roles/ (one JSON role file each), skills/ (skills that load as extra context), flows/ (your own flow definitions), and policies/ (what the safety engine compiles).

rules.md is your project instructions: advisory guidance read on every agent turn. The enforced rules are policies. Once one page is not enough, add markdown files under rules/ and they compose onto it, sorted by filename and each labelled with its source. Name them for the order you want: 10-style.md, then 20-testing.md. Instructions enter every agent turn of every run, so the composed ruleset is size-bounded, and vibe doctor reports anything truncated or refused rather than letting your rules quietly stop arriving.

runs/ holds per-run artifacts, state and metrics, and is the one part of the folder that should stay out of the repository: it grows without bound, and a run’s state.json carries the raw text of anything you steered onto it. When Vibestrate creates the repository it writes .vibestrate/runs/ into the starter .gitignore. In a project that already had one, add the line yourself - vibe doctor and More > Setup say so if you have not, and say it louder once run files are actually committed.

Beyond the env: rule for provider keys, Vibestrate never reads your .env contents into a prompt, an artifact, or a report. See Safety for the guarantees around what a run may touch.

• project.yml reference - the generated, field-by-field schema.
• Crew configuration, annotated - the providers / profiles / crews block, commented line by line.
• Provider, Profile, Crew - the things you configure most.
• Safety - policies, the enforced half of configuration.