Project settings

Settings are per project. This page covers what a project owner changes in the normal course of work; the deployment-level configuration behind them — registries, gateways, credentials on the host — belongs to whoever installed the platform, and is covered in Install with Docker Compose.

Controls only an owner can use say so, rather than failing when you click them.

How work lands: merge mode

The single most consequential setting.

• DIRECT — feature branches merge into the project's integration branch. A merge runs every scenario in the project twice: on the feature branch before it merges, and on the integration branch after. Skip the second full test run when nothing changed, under Direct, skips the second run when the merged code is exactly the code that just passed. Anything that changes the code in between, such as new commits on the integration branch, still runs the full suite. Off by default.
• PR mode — feature branches become pull requests against your own base branch, tracked in the Pull Requests view. Repave never writes to your base branch itself. Configuration it generates — BDD and UAT test configuration, preview dev configuration, sample data seeds and the design system — arrives as a pull request of its own, from a repave-platform/ branch, and the job says which one it opened. In direct mode the preview dev configuration is committed to your integration branch, so every new feature branch starts with it. A feature's BDD run needs the BDD configuration, so until that pull request has merged the run does not start, and says which pull request to merge.

An existing project can be migrated from DIRECT to PR mode. A feature merged before the switch says which branch it merged into, such as Merged to repave branch, until Repave finds its work on your base branch. From then on it reads Merged to main branch (or whichever base branch you set). Repave checks this itself, even for features whose branch was deleted when they merged. A feature whose work has not reached your base branch keeps naming the branch it merged into, and its page says the work is still to land.

Test runs

Landing work runs the project's full test suite automatically, so a broken feature never reaches your base branch untested. Three options under Test runs, in the Merge mode section, leave those runs out. Each applies in both merge modes, and each is off by default:

• Skip the full test suite before work lands. Before a pull request opens, or a Direct merge goes in, Repave merges the base branch in and runs every scenario and the unit tests against the result. With this on, the pull request opens, or the merge goes in, without that run. Create PR, Refresh PR and repave pr create all follow it, and the merge and pull request dialogs say so before you confirm.
• Skip the test run after work lands. After a Direct merge, Repave runs every scenario again on the integration branch. On a project with source repositories, once a feature's pull requests have all merged, it runs the feature's scenarios on the merged combination before marking the feature merged. With this on, neither run happens. A project with a single repository in pull request mode runs nothing after merge, so it is not offered this option. While it is on, Skip the second full test run when nothing changed is hidden, because there is no second run to skip.
• Resolve merge conflicts without running the full test suite. When a merge conflicts, an agent resolves it and then runs every scenario, fixing failures until they pass. With this on, the agent resolves the conflict and stops there. This covers every merge an agent resolves: Create PR, Merge from, Update feature branches, Pull and a Direct merge.

What was skipped stays on record. A pull request opened without a test run says so in its description, and the feature page and the pull request group say so too, even after the option is turned off again. A pull request opened without a test run is still tested after it merges, unless Skip the test run after work lands is on as well.

Implementation gates

What has to be true before an implementation is accepted. Each is a switch, and together they decide how much the platform insists on before it calls a feature done:

• unit tests, and a coverage threshold
• a false-positive review of passing unit tests — off by default, and worth turning on where green tests are not trusted
• UI, API and database-schema checks
• scenario-drift detection
• implementation planning, and scenario-by-scenario implementation
• a maximum number of review cycles

Numeric settings are bounded, so a value that would make no sense is refused at the point you set it.

Models and agents

Agent Defaults is a table with one row per agent the product runs. Per agent you can set:

• the model it runs with, and the advisor model that reviews its work
• its timeout
• how long its prompt cache lives, and what that has cost
• whether it gets a browser
• what memory it captures, uses and is given
• its budget: the most one run of that agent may spend. Empty means no limit of its own. It cannot be more than the maximum per run your administrator sets, and it is read-only when your administrator does not let users set budgets (see Budgets).

To set one of the on/off columns (Browser, Graphify, Capture, Tools, Inject) for every agent at once, use the checkbox in that column's heading. It ticks every agent, or clears every agent when they are all ticked, and shows a dash when they disagree. Agents that are switched off elsewhere in settings are left as they are, and Inject is only ticked for agents that have Tools.

A per-run model an operator picks for one launch overrides the row for that run only.

An agent's model is one of three Claude tiers, and Elite model name, Pro model name and Speed model name say which model each tier runs. A new project starts on Claude Opus 5.5, Claude Sonnet 5.5 and Claude Haiku 5.5; an existing project keeps the models it has until you change them. Claude Haiku 5.5 costs five times as much per token for a turn whose prompt is over 100,000 tokens, cached tokens included, so a Speed agent that reads a lot uses up its budget faster than its short turns suggest.

Changing an agent's model, or which advisor the project uses, turns off any advisor that can no longer advise that agent. When you change the advisor, the page also tells you how many agents it turned off. If you undo the change before you save, those advisors come back. An advisor you picked yourself in the meantime is kept.

Agents can ask you and hear from you, under the table, is on by default: every agent can ask you questions, wait for your approval of commands its safety check hands back, and read what you type in its chat (see Talking to an agent while it runs). Turn it off and agents run without stopping, as before. The change applies to runs started after you save.

Always-allowed commands, below it, lists the commands someone chose Always allow for when an agent asked, with who added each and when. The agent runs those without asking. Remove takes a command off the list for the next run, after which the agent asks again.

Project assistant, a box of its own below that, is off by default. Tick Turn on the project assistant and save to give the project the assistant: a chat beside every project page, opened from the Assistant button in the header (see Project assistant).

Providers

How agent calls reach a model. A new project defaults to direct dispatch; the routed modes are available where your deployment enables them:

• Anthropic API directly
• Vertex AI, running Claude models in your own GCP project
• Gemini, and other providers, through the translation gateway

An agent on a Gemini or Codex model works with as much context as that model accepts and compacts its conversation only as it nears that limit. A model Repave does not yet know the limit of — one you mapped a tier to after it shipped — is treated as having 200K tokens, and the job log names it. Its agents compact at 200K, so a model that accepts more is not fully used, and one that accepts less than 200K can still be sent more than it allows. Longer context also means each turn sends more tokens, so a long run on a large-window model costs more per turn than it did when it compacted sooner.

A project with no key of its own uses the one your administrator set in the Admin portal; its field reads Using organization key. Enter a key here to use a different one for this project.

Provider and memory smoke tests are on this page: run them after changing anything here rather than finding out on your next implementation.

Integrations

• GitHub / Azure DevOps — a personal access token and branch pushes, and for GitHub, creating a repository for the project. The link maintains itself: it pushes on creation, syncs both ways, and pushes again at merge time.
• Team Foundation Server — including trusting a private certificate authority, or skipping TLS verification for one connection.
• GitLab — gitlab.com or a self-managed GitLab. In pull-request mode, features open merge requests on GitLab. A project on a self-managed GitLab shows the Git connection card, where TLS verification can be skipped for that connection, as for Team Foundation Server; a gitlab.com project has no such card, because gitlab.com's certificate is public.
• Source repositories — for a project combining several, managed here.
• Package registries — where agent jobs, test containers and scaffolding resolve dependencies from. Set these for an air-gapped or proxied network.
• Prototypes — Prototype Mode, where each feature's prototype comes from: HTML, Figma, or Storybook (the project's own components, with a story per To-Be state), and whether HTML and Figma designs are also built on your own stack. Choosing Storybook sets it up in your codebase straight away and shows how that is going on this card. A Storybook project also shows the Figma connection, under Figma (optional), so a single feature can be designed in Figma instead of as stories. See UI prototypes.

The code index

Two checkboxes decide whether the code index runs. The page reports what state the index is in and lets you rebuild it. It is what lets agents answer questions about the codebase without reading all of it, so a stale or missing index shows up as agents that seem not to know their way around.

Daily tests

The Daily tests card on the Implementation tab runs the project's whole BDD suite once a day, and starts an agent that fixes whatever fails; see Daily tests for what each run does. Run the full test suite daily is off by default, because a failing run starts an agent. Turn it on and the suite runs at 02:00, or at the time you choose, read in the time zone beside it — the server's by default, or one you pick — exactly as the Repave IDE daily stop below reads its time. The switch cannot be turned on until the project has a BDD test script, set under General.

Repave IDE

The Repave IDE card on the General tab sets when the project's sessions are stopped each day. Stop all Repave IDE sessions daily is off by default, so sessions stay open until someone stops them. Turn it on and every session of the project is stopped at 06:00, or at the time you choose. The time is read in the time zone chosen beside it. By default that is the server's, shown as for example Server time zone — Asia/Singapore (UTC+08:00); pick another zone from the list to read the time in your team's own, for example America/Los_Angeles (UTC-07:00). Daylight saving is followed automatically. The stop runs only when the clock passes the time, so saving a time that has already passed today stops nothing until tomorrow, and a time the server was down for is not made up later.

Earlier versions had the stop on by default. Upgrading turns it off in every project, including one where it had been chosen; the time is kept, so turning the switch back on restores it.

If the card says the server's time zone is not recognised, the REPAVE_HOST_TIMEZONE value in the server's .env is not a valid time zone name. A project that follows the server's time zone stops no sessions until you choose a time zone for the project, or fix the value and restart Repave. If it says this project's time zone is no longer recognised, the server no longer knows the zone the project chose (this can follow an upgrade); the project stops no sessions until you choose another.

Repave IDE sessions

The context window a session's assistant runs with, and how it signs in. See Repave IDE.

A session keeps the sign-in it started with, so a save that changes it — the sign-in mode, or the project's API key or other credential the sessions use — stops the sessions open for this project. Before saving, Repave asks Stop running Repave IDE sessions? and says how many are open. Stop and save saves and stops them: files on disk are kept, but running terminals and processes end. Cancel saves nothing. A save that changes none of these never asks, and if another session opens while you decide, you are asked again with the new count.

Learning categories

After Repave delivers a feature, your developers often change it before they merge it. Once a day Repave reads your repository, with the access it already has, and finds the changes made between its delivery and the merge. It sorts each one, so that Repave learns what it got wrong and how your team works. Nothing is sent anywhere your features' code does not already go.

The Learning categories card at the end of the Context tab lists how those changes are sorted. Every project starts with Repave's three kinds:

• Repave defect, which becomes a check: Repave got something wrong. Repave writes a validation rule for it and keeps the rule only if it catches the mistake in what was delivered and passes your fix. The rule then reports on every later feature.
• Client preference, which becomes a lesson: your conventions, naming, logging and helpers. Repave records it as a lesson for this project, together with the changes it was learned from.
• One-off, which is recorded only: a redesign or extra scope for that one feature.

Each kind has subtypes, such as Authorization or Logging. The description of each kind and subtype is what Repave reads to decide where a change belongs, so write it as a definition. Click ⋯ to edit or remove a kind, click a subtype to edit or remove it, and use Add kind or + Add subtype to add your own. Each change is saved when you click Save or Add in its dialog; Cancel saves nothing. Reset to defaults brings back Repave's list.

Changes you make apply to what is sorted afterwards. A change already sorted keeps the kind it was given, even if you rename or remove that kind later.

Applying what Repave learns

The Repave learning switch above the categories, Apply what Repave learns, is off for every project until you turn it on, and is saved with Save Changes. Repave sorts your developers' changes and works out what it learned either way.

With it on, each lesson about how your team works is written into this project's skills: Repave edits the skill an agent doing that work would load, or adds a new one. Each change shows on the Skills page as made by Repave learning, with the lesson as its note, and can be undone there in one click. A lesson you undo is not applied again. Turning the switch off stops new changes and leaves the ones already made, each still undoable.

Team

Who can see and change this project. Editors can do the work; viewers can read it. Some controls are owner-only.

Inviting someone gives you a link to send them. If your administrator has set up email in the Admin portal, the invitation is also emailed, and the dialog says whether it was sent. The link opens a page where the invitee signs in, or creates an account with the invited address, and accepts. An invitation expires after 7 days.